Date  : 05-Jul 06:34
Subject : LEVEL 3-4 PROTOCOL (1)

de DL1MEN @ DC6LK

NORD><LINK e.V.
Hinter dem berge 5

3300 Braunschweig


Appendix to the Users Manual for TheNet Networking Software.
Reprint for noncommercial purposes allowed if credit given.


                    The Interlink Protocol
                    ======================

0. Preface

    A specific protocol is used for internode communications.  The
frames of this protocol contain 0xCF as level-2 protocol ID.  Every
frame contains a special transport header, which follows the level-2
(AX.25) header.  This header consists of 20 bytes.  Since the AX.25
protocol only allws a maximum of 256 bytes of information per frame,
user frames longer than 236 bytes must be split in two.  TheNet
ensures that such split frames are reassembled at their destination.
In order to make the most efficient use of the network, however,
frames with more than 256 info bytes should not be transmitted by
users.  Please note that the level-2 frames between nodes contain
only the call signs of the two nodes involved (there is no
digipeater list), the transport header, however, always contains the
call sign of the level-4 partners.

    Example:  DB0FD receives a frame from DB0FC to be routed to
DB0KH.  Since DB0FE is the closest neighbor, it must be sent there.
The level-2 header contains, therefore, DB0FD as sender and DB0FE as
receiver.  In the transport header, however, DB0FC is listed as
sender and DB0KH as receiver.


1. Transport Header Format

The first 15 bytes are evaluated by all nodes involved and are used
to find the best path.  The remaining 5 bytes contain error checking
information.  While AX.25 is inherently error-free, this additional
error checking is required since level-2 frames are acknowledged
immediately, but the node cannot know at that time whether the
complete path is still functional.  In case of a required routing
change (due to sudden communication failure on part of the path),
the receiver must have a means of requesting retransmission from the
sender.


1.1. Call sign of source node
Length 7 bytes, normal AX.25 (shifted) format.


1.2. Call sign of destination node
Length 7 bytes, normal AX.25 (shifted) format, EOA bit set.


1.3. Remaining lifetime of packet (1 byte)
The packet lifetime is initialized by the originating node and
every node involved decrements this value by 1.  When lifetime 0 is
reached, the packet is discarded.  No error message is generated.
One disadvantage is, that one-way-routes can occur.  Example:  DB0FC
initializes its packets with a lifetime of 64, DF6LN uses 10.  The
path from DB0FC to DF6LN contains 15 intermediate nodes.  A packet
sent by DB0FC arrives at DF6LN with a remaining lifetime of 54, the
acknowledge frame is, however, discarded along the way due to
expiration of its lifetime (10 - 15 is < 0).  Therefore, one cannot
connect straight through.  Lifetime limitation is necessary,
however, since "erroneous" parameters or other adverse conditions
during a communication loss ca generate infinite loops.


1.4. Four bytes with different meaning, depending on the opcode.
These bytes are labelled B1, B2, B3, and B4 in their order of
appearance in a frame.
In order to correlate every frame to the corresponding virtual
channel, every channel is assigned two identification bytes at the
time of channel setup (connect on level-4).  One byte, the index, is
the sequence number of the circuit list entry.  The other byte, the
ID, is a random number.  This eliminates the possibility of remnant
frames being assigned to a new connect (using the same call sign and
the same circuit list entry).


1.5. Flags and Opcode (1 byte)
The lower 4 bits constitute the opcode, while the upper 4 bits are
flags.


1.5.1. Opcode
At this time, only six of the possible 16 opcodes are defined.


1.5.1.1. Opcode 1: Connect Request
Request to initiate a level-4 connect.

    B1 = my index
    B2 = my ID
    B3 = undefined
    B4 = undefined

The frame contains the following information:

    - proposed level-4 window size (1 byte)
      For better channel utilization, level 4 can store multiple frames
      out of sequence.  This, of course, uses up RAM.  Every SYSOP must,
      considering traffic volume and RAM usage in his node, set this
      parameter manually.

    - end user call sign (7 bytes, shifted AX.25 format)

    - call sign of originating node (7 bytes, shifted AX.25 format)


1.5.1.2. Opcode 2: Connect Acknowledge
Response to a connect request.  The ckoke bit (see below) is set if
there is no more room in the circuit table and the connect request
has been rejected.


The frame contains the following information:

    - accepted level 4 window size (1 byte)
      the accepted window size is never larger than the proposed
      window size.


1.5.1.3. Opcode 3: Disconnect Request
Request to terminate the level 4 connect.  Either node may transmit
this request.  The receiver is instructed to immediately transmit
any remaining information then to acknowledge the disconnect.

    B1 = your index
    B2 = your ID
    B3 = undefined
    B4 = undefined

This frame contains no further information.


1.5.1.4. Opcode 4: Disconnect Acknowledge
Acknowledges a level 4 disconnect.

    B1 = your index
    B2 = your ID
    B3 = undefined
    B4 = undefined

This frame contains no further information.


1.5.1.5. Opcode 5: Information
This frame is used to transmit information.

    B1 = your index
    B2 = your ID
    B3 = transmit sequence number
    B4 = receive sequence number

Transmitted frames are numbered sequentially using B3.  They also
constitute acknowledgement for frames up to (B4 - 1).  This
procedure is identical to the one used during level 2 connects with
the exception that the sequence runs from 0..255, not from 0..7.


1.5.1.6. Opcode 6: Information Acknowledge
Despite acknowledgement is implied in reception of the info frame,
it may nevertheless be necessary to transmit a separate
acknowledgement if data flow is one-way.

    B1 = your index
    B2 = your ID
    B3 = undefined
    B4 = receive sequence number

This frame contains no further information.


1.5.1.7. undefined Opcodes
All other opcodes result in destruction of the frame at the
receiving node.


1.5.2. Flags
The upper 4 bits of the opcode are reserved for flags.


1.5.2.1. Bit 7: Choke Flag
The node has insufficient memory to receive further information for
this level 4 connect.


1.5.2.2. Bit 6: NAK Flag
Contrary to the above, the receive sequence count is not to be used
as acknowledgement, but rather as a request to retransmit the thusly
numbered frame.


1.5.2.3. Bit 5: More Follows Flag
The current frame had to be split.  All following frames, including
the first one without this flag set, are to be reassembled to one
single frame at the receiving node.


1.5.2.4. Bit 4: undefined


End of part 1

73, Georg, DF2AU

Translated by DL1MEN