PROTOCOL FOR COMMUNICATION ON THE RS232 CUT POINT
1. Host - Terminal Interlink distinctions
Because and RS232 cut point can act as a node and as a terminal,
some means for distinguishing the two modes must be provided.
This is done simply at the input to the DCD of the SIO channel B.
Normally, the RS232 cut point is in the terminal mode. Following
instructions given in the hand book, a negative potential is
provided to the DCD connection, and Interlink mode is indicated
by this.
2. Frame Format in Interlink Mode
All frames are sent as on an HDLC channel. The software makes
no adjustments at Level-2 and higher. In Level-1, just the
HDLC flag needs to be reset. Thereby, a simple variant of the
HDLC protocol is attained.
All frames begin with STX = 0x02 and end with ETX = 0x03.
Inside a frame STX is replaced DLE-STX and ETX is
replaced by DLE-ETX. DLE (0x10) is extended to DLE-DLE.
For fault detection, the common CRC is not used. Since
faults on an RS232 link are not very likely, a simple check sum is
appended to the ETX. The check sum is 8 bits long and applies to
all the information in the frame (without STX-ETX). The trailing
DLE's are not included.
3. Collision Avoidance.
With only two TNC's on an RS232, no protocol, obviously, is
needed. All transmittals run quasi-full duplex. With more than
two TNC's, a CSMA-CD driver (or controller) is used, which is
controlled over RTS-CTS. Each TNC may only begin a send-cycle if
it has through the CTS determined that the bus is free. It
asserts RTS and loads the bus. Then a randomly determined time
(from 2.5 to 25 milliseconds) is allowed to pass so that any
other TNC's who are ready to send can recognize the change in
channel status. If, during this wait time, some other TNC asserts
RTS, then the send-cycle is broken.
THE INTERLINK PROTOCOL
0. Foreword
The nodes exchange a special protocol for information display.
The frames of the protocol have a 0xCF as Level-2 protocol
identifier. Each frame contains a special Transport Header after
this Level-2 Header (AX.25), which consists of 20 bytes. Because
the AX.25 protocol permits only 256 bytes of information, overly
long User Frames are divided into two sections. TheNet takes care
of this, so that the original size is retained. To keep best use
of the network, no frames longer than 236 bytes are allowed
(Mailboxes). Please note that the Level-2 frames used between two
nodes have the call signs of both parties included (because there
is no digipeater list), whereas in the Transport Header, the call
sign of the level 4 partner appears.
Examples: DB0FD contains a frame for DB0KH from DB0FC, which must
be sent to DB0FE, because DB0FE is the next neighbor on the path
list. DBFD, then, appears in the Level 2 Header as the Sender,
and DB0FE appears as the receiver. In the transport header,
DB0FC is the Sender and DB0KH is the Receiver.
1. Construction of the Transport Headers
The first 15 bytes are evaluated by all parties to find the
optimum path. The remaining five bytes take care of failures
between sender and receiver. (AX.25 is by definition failure
free.) The error provision is necessary, because at Level 2, the
system cannot know if the entire path exists or not. In case of
sudden loss of path, the Receiver must have some means of sending
back frames to the sender for reclaiming.
1.1 Originating Node's Call Sign
Length, 7 bytes, normal AX.25 (packed bytes) format
1.2 Target Node's Call Sign
Length, 7 bytes, normal AX.25 (packed bytes) format, EOA bit set.
1.3 Remaining Packet Life Time
The Remaining Packet Life Time is initially set by the
originating node, and it is reduced by one by each transporting
node. When the value reaches zero, the packet is destroyed. No
error message results. This leads to one-way-paths. For example:
DB0FC initializes its packet to a remaining life of 64, but DF6LN
uses 10. The path between DB0FC and DF6LN has 15 intermediate
nodes. A packet from DB0FC arrives with a remaining life of 49,
but the reverse message is destroyed in passage because 15 > 10.
A life time limit is necessary to forestall perpetual loops in
the system.
1.4 Four bytes with meaning depending upon each Opcode
These bytes are called B1, B2, B3, B4, in the order they appear in
the frame. In each virtual channel, two bytes are used by the
sender and receiver for identification, at the time that the
channel is constructed at Level-4. One of the bytes of the index
is the running count in the circuit list. The other, ID, byte, is
a random number, to prevent ghost frames from a prior message
from circuilating in the system.
1.5 Flags and Opcodes (1 Byte)
The lower four bits give the Opcode. The upper four bits are
flags.
1.5.1 Opcodes
Presently, only six of the possible 16 Opcodes are defined.
1.5.1.1 Opcode = 1 Connect Request
Created for a Level-4 Connection.
B1 = My Index
B2 = My Id
B3 = not defined
B4 = not defined
The frame has the following information:
Proposed Window Size, Level-4 (1 Byte)
For better utilization of the system at Level-4, to
permit more frames to be interjected. This costs RAM. Each Sysop
on the system must make his own choice.
Call sign of the End User. (7 Bytes, AX.25 format with
packed bytes)
Call sign of the Sender Node, (7 Bytes, AX.25 format with
packed bytes)
1.5.1.2 Opcodes = 2 Connect Acknowledge
Answer to a connect request. The choke bit shows, in this case,
that no free places exist on the free list, and the connect
request is declined.
The information in the frame is:
Unified (or agreed) window size, Level 4 (1 Byte)
The unified (or agree) window size is never greater than
the proposed window size.
1.5.1.3 Opcode = 3 Disconnect Request
A directive to relese the Level-4 connection. The order can
come from either end of the connection. The Receiver is ordered
to send along any intermediate information and then to disconnect.
B1 = Your Index
B2 = Your Id
B3 = not defined
B4 = not defined
The frame contains no information.
1.5.1.4 Opcode = 4 Disconnect Acknowledge
Assers that a Level-4 connection has been cut.
B1 = Your Index
B2 = Your Id
B3 = not defined
B4 = not defined
1.5.1.5 Opcode = 5 Information
In these frames, information is translated.
B1 = Your Index
B2 = Your Id
B3 = Running number "send sequence"
B4 = Running number "receive sequence"
Each frame is given a B3 number as it is sent. This serves as
the value for the receiving frame of the same Level-4
connection to (B4 - 1). This value corresponds to the Level-2
value with the change that the "send sequence" does not run from
0..7 but rather from 0..255.
1.5.1.6 Opcode = 6 Information Acknowledge
While the status of the contained information is implicit in the
Info Frame, in one-sided data flow, this item is still necessary,
acting as an extra confirmation.
B1 = Your Index
B2 = Your Id
B3 = not defined
B4 = Running "receive sequence" number
This frame contain no information.
1.5.1.7 Not Defined Opcodes
All other Opcodes indicate that the frame has been destroyed by
the Receiver.
1.5.2 Flags
The upper four bits in the Opcode Byte are reserved for flags.
1.5.2.1 Bit-7 Choke Flag
The node does not have enough memory free to take in more
information for the present Level-4 connection.
1.5.2.2 Bit-6 NAK Flag
Contrary to what was said above, the Receive Sequence is not used
as confirmation but as a directive that the Frame having this
number is to be retained.
1.5.2.3 Bit-5 More Follows Flag
The current frame must be divided. All following frames
including the first one not having this flag are to be
concatenated into one by the receiver.
1.5.2.4 Bit-4 Not Defined