home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 2 / HACKER2.BIN / 475.KISS.DOC < prev    next >
Text File  |  1987-06-11  |  8KB  |  156 lines

  1. Date: Wed 1 Oct 86 18:55:40-EDT
  2. From: Mike Chepponis <cadre!C.CS.CMU.EDU!Michael.Chepponis@pitt.UUCP>
  3.  
  4.         Proposed "Raw" TNC Functional Spec - 6 August 1986
  5.                 Phil Karn, KA9Q
  6.  
  7. 1. Introduction
  8.  
  9. The purpose of the "Raw" (aka "KISS") TNC is to facilitate the use of
  10. amateur packet radio controllers (TNCs) with host computers, particularly in
  11. the development of experimental protocols and multi-user servers (e.g.,
  12. "bulletin boards").
  13.  
  14. Current TNC software was written with human users in mind; unfortunately,
  15. commands and responses well suited for human use are ill-adapted for host
  16. computer use, and vice versa. This is especially true for multi-user
  17. servers such as bulletin boards which must multiplex data from several network
  18. connections across the single host/TNC link.  In addition, experimentation
  19. with new link level protocols is greatly hampered because there may very
  20. well be no way at all to generate or receive frames in the desired format
  21. without reprogramming the TNC.
  22.  
  23. The Raw TNC solves these problems by eliminating as much as possible from
  24. the TNC software, giving the attached host complete control over and access
  25. to the contents of the HDLC frames transmitted and received over the air.
  26. The AX.25 protocol is removed entirely from the TNC, as are all command
  27. interpreters and the like.  The TNC simply converts between synchronous
  28. HDLC, spoken on the half duplex radio channel, and a special asynchronous,
  29. full duplex frame format spoken on the host/TNC link.  Every frame received
  30. on the HDLC link is passed intact to the host once it has been translated to
  31. the asynchronous format; likewise, asynchronous frames from the host are
  32. transmitted on the radio channel once they have been converted to HDLC
  33. format.
  34.  
  35. Of course, this means that the bulk of AX.25 (or another protocol) must now be
  36. implemented on the host system. This is acceptable, however, considering the
  37. greatly increased flexibility and reduced overall complexity that comes from
  38. allowing the protocol to reside on the same machine with the applications to
  39. which it is closely coupled.
  40.  
  41. 2. Asynchronous frame format
  42.  
  43. The "asynchronous packet protocol" spoken between the host and TNC is very
  44. simple, since its only function is delimiting frames. Each frame is both
  45. preceeded and followed by a special FEND (frame end) character, analogous to
  46. an HDLC flag.  No CRC or checksum is provided.
  47.  
  48. The reason for both preceeding and ending frames with FENDs is to improve
  49. performance when there is noise on the asynch line. The FEND at the
  50. beginning of a frame serves to "flush out" any accumulated garbage into a
  51. separate frame (which will be discarded by the upper layer protocol) instead
  52. of prepending it to an otherwise good frame.  As with back-to-back FLAGs in
  53. HDLC, two FEND characters in a row should not be interpreted as delimiting
  54. an empty frame.
  55.  
  56. 2.1 Transparency
  57.  
  58. Frames are sent in 8-bit binary; if an FEND ever appears in the data, it is
  59. translated into the two byte sequence FESC TFEND (frame escape, transposed
  60. frame end).  Likewise, if the FESC character ever appears in the user data,
  61. it is replaced with the two character sequence FESC TFESC (frame escape,
  62. transposed frame escape).
  63.  
  64. As characters arrive at the receiver, they are appended to a buffer
  65. containing the current frame. Receiving a FEND marks the end of the current
  66. frame.  Receipt of a FESC puts the receiver into "escaped mode", which
  67. causes the receiver to translate a following TFESC or TFEND back to FESC or
  68. FEND, respectively, before adding it to the receive buffer and leaving
  69. escaped mode.  (Receipt of any character other than TFESC or TFEND while in
  70. escaped mode is an error; no action is taken and frame assembly continues.
  71. A TFEND or TESC received while not in escaped mode is treated as an ordinary
  72. data character.)
  73.  
  74. This procedure may seem somewhat complicated, but it is easy to implement
  75. and recovers quickly from errors. In particular, the FEND character is never
  76. sent over the channel except as an actual end-of-frame indication. This
  77. ensures that any intact frame (properly delimited by FEND characters) will
  78. always be received properly regardless of the starting state of the receiver
  79. or corruption of the preceeding frame.
  80.  
  81. The special characters are:
  82.  
  83. FEND    (frame end)            300 (octal)
  84. FESC    (frame escape)            333 (octal)
  85. TFEND    (transposed frame end)        334 (octal)
  86. TFESC    (transposed frame escape)    335 (octal)
  87.  
  88. (ARPA Internet hackers will recognize this protocol as identical to SLIP, a
  89. popular method for sending IP datagrams across ordinary dialup modems).
  90.  
  91. 3. Control of the Raw TNC
  92.  
  93. Each asynchronous data frame sent to the TNC is converted back into "pure"
  94. form and queued for transmission as a separate HDLC frame.  Although
  95. removing the human interface and the AX.25 protocol from the TNC makes most
  96. existing TNC commands unnecessary (i.e., they become host functions), the
  97. TNC is still responsible for keying the transmitter's PTT line and deferring
  98. to other activity on the radio channel. It is therefore necessary to allow
  99. the host to control a few TNC parameters, namely the transmitter keyup delay
  100. and the transmitter persistence variables.
  101.  
  102. It is therefore necessary to distinguish between command and data frames on
  103. the host/TNC link. This is done by defining the first byte of each
  104. asynchronous frame between host and TNC as a "type" indicator.  The
  105. following types are defined in frames to the TNC:
  106.  
  107. Type    Function    Comments
  108. 0    Data frame     Rest of frame is data to be sent on the HDLC channel
  109. 1    TXDELAY        Second byte is transmitter keyup delay in 10 ms units
  110. 2    P        Second byte of frame is persistence parameter, p:
  111.             0: p = (0+1)/256, 255: p = (255+1)/256 = 1.0
  112. 3    SLOTTIME    Second byte of frame is slot interval in 10 ms units
  113. 4    TXtail        Second byte of frame is time to hold up the TX after
  114.             the FCS has been sent (the time allowed to send the
  115.             HDLC flag character; should be at least 2 for 1200 bps
  116.             operation).  In 10 ms units.
  117.  
  118. The following types are defined in frames to the host:
  119.  
  120. Type    Function    Comments
  121. 0    Data frame    Rest of frame is data from the HDLC channel
  122.  
  123. (No other types are defined; in particular, there is no provision for
  124. acknowledging data or command frames sent to the TNC.)
  125.  
  126. 4. Persistence
  127.  
  128. The P and SLOTTIME parameters are used to implement true p-persistent CSMA.
  129. This works as follows:
  130.  
  131. Whenever the host has queued data for transmission, the TNC begins
  132. monitoring the carrier detect signal from the modem. It waits indefinitely
  133. for this signal to go inactive. Once the channel is clear, the TNC generates
  134. a random number between 0 and 255. If this number is less than or equal to P,
  135. the TNC asserts the transmitter PTT line, waits .01 * TXDELAY seconds, and
  136. transmits all frames in its queue. The TNC then releases PTT and goes back to
  137. the idle state.  If the random number is greater than  P, the TNC delays
  138. .01 * SLOTTIME seconds and repeats the procedure. (If the carrier detect
  139. signal has gone active in the meantime, the TNC again waits for it to clear
  140. before continuing).  Note that P=255 means always transmit as soon as possible,
  141. regardless of the random number.
  142.  
  143. The result is that the TNC waits for an exponentially-distributed random
  144. interval after sensing that the channel has gone clear before attempting to
  145. transmit. The idea here is that with proper tuning of the parameters P and
  146. SLOTTIME, several stations with traffic to send are much less likely to
  147. collide with each other when they simultaneously see the channel go clear.
  148.  
  149. Comments on this spec are welcome.
  150.  
  151. Phil Karn, KA9Q
  152.  
  153. (Slightly modified to describe the TNC-2 implementation by Mike Chepponis, K3MC
  154. on 1 Oct 86.)
  155.  
  156.