home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc914 < prev    next >
Text File  |  1991-04-21  |  57KB  |  1,299 lines

  1.  
  2.  
  3. Network Working Group                                    David J. Farber
  4. Request for Comments: 914                                   Gary S. Delp
  5.                                                          Thomas M. Conte
  6.                                                   University of Delaware
  7.                                                           September 1984
  8.  
  9.                           A Thinwire Protocol
  10.                    for connecting personal computers
  11.                             to the INTERNET
  12.  
  13. Status of this Memo
  14.  
  15.    This RFC focuses discussion on the particular problems in the
  16.    ARPA-Internet of low speed network interconnection with personal
  17.    computers, and possible methods of solution.  None of the proposed
  18.    solutions in this document are intended as standards for the
  19.    ARPA-Internet.  Rather, it is hoped that a general consensus will
  20.    emerge as to the appropriate solution to the problems, leading
  21.    eventually to the adoption of standards.  Distribution of this memo
  22.    unlimited.
  23.  
  24. What is the Problem Anyway ?
  25.  
  26.    As we connect workstations and personal computers to the INTERNET,
  27.    many of the cost/speed communication tradeoffs change.  This has made
  28.    us reconsider the way we juggle the protocol and hardware design
  29.    tradeoffs.  With substantial computing power available in the $3--10K
  30.    range, it is feasible to locate computers at their point of use,
  31.    including in buildings, in our homes, and other places remote from
  32.    the existing high speed connections.  Dedicated 56k baud lines are
  33.    costly, have limited availability, and long lead time for
  34.    installation.  High speed LAN's are not an applicable interconnection
  35.    solution.  These two facts ensure that readily available 1200 / 2400
  36.    baud phone modems over dialed or leased telephone lines will be an
  37.    important part of the interconnection scheme in the near future.
  38.    This paper will consider some of the problems and possibilities
  39.    involved with using a "thin" (less than 9600 baud) data path.  A trio
  40.    of "THINWIRE"  protocols for connecting a personal computer to the
  41.    INTERNET are presented for discussion.
  42.  
  43.    Although the cost and flexibility of telephone modems is very
  44.    attractive, their low speed produces some major problems.  As an
  45.    example, a minimum TCP/IP Telnet packet (one character) is 41 bytes
  46.    long.  At 1200 baud, the transmission time for such a packet would be
  47.    around 0.3 seconds.  This is equivalent to using a 30 baud line for
  48.    single character transmission.  (Throughout the paper, the assumption
  49.    is made that the transmission speed is limited only by the speed of
  50.    the communication line.  We also assume that the line will act as a
  51.    synchronous link when calculating speed.  In reality, with interrupt,
  52.    computational, and framing overhead, the times could be 10-50%
  53.    worse.)
  54.  
  55.    In many cases, local echo and line editing can allow acceptable
  56.  
  57.  
  58. Farber & Delp & Conte                                           [Page 1]
  59.  
  60.  
  61.  
  62. RFC 914                                                   September 1984
  63. Thinwire Protocol
  64.  
  65.  
  66.    Telnet behavior, but many applications will work only with character
  67.    at a time transmission.  In addition, multiple data streams can be
  68.    very useful for fully taking advantage of the personal
  69.    computer/Internet link.  Thus this proposal.
  70.  
  71.    There are several forms that a solution to this problem can take.
  72.    Three of these are listed below, followed by descriptions of possible
  73.    solutions of each form.
  74.  
  75.    o    As a non-solution, one can learn to live with the slow
  76.         communication (possibly a reasonable thing to do for background
  77.         file transfer and one-time inquiries to time, date, or
  78.         quote-of-the-day servers).
  79.  
  80.    o    Using TCP/IP, one can intercept the link level transmissions,
  81.         and try various kinds of compression algorithms.  This provides
  82.         for a symmetrical structure on either side of the "Thinwire".
  83.  
  84.    o    One could build an "asymmetrical" gateway which takes some of
  85.         the transport and network communication overhead away from both
  86.         the serial link and the personal computer.  The object would be
  87.         to make the PC do the local work, and to make the
  88.         interconnection with the extended network a benefit to the PC
  89.         and not a drain on the facilities of the PC.
  90.  
  91.    The first form has the advantage of simplicity and ease of
  92.    implementation. The disadvantages have been discussed above.  The
  93.    second form, compression at link level, can be exploited in two ways.
  94.  
  95.       Thinwire I is a simple robust compressor, which will reduce the 41
  96.       byte minimum TCP/IP Telnet packets to a series of 17 byte update
  97.       packets.  This would improve the effective baud rate from 30 baud
  98.       to 70 baud over a 1200 baud line (for single character packets).
  99.  
  100.       Thinwire II uses a considerably more complex technique, and takes
  101.       advantage of the storage and processing power on either side of
  102.       the thinwire link.  Thinwire II will compress packets from
  103.       multiple TCP/IP connections from 41 bytes down to 13 bytes.  The
  104.       increased communication rate is 95 (effective) baud for single
  105.       character packets.
  106.  
  107.    The third form balances the characteristics of the personal computer,
  108.    the communications line, the gateway, and the Internet protocols to
  109.    optimize the utility of the communications and the workstation
  110.    itself.  Instead of running full transport and internet layers on the
  111.    PC, the PC and the gateway manage a single reliable stream,
  112.    multiplexing data on this stream with control requests.  Without the
  113.    interneting and flow control structures traveling over the
  114.    communications line on a per/packet basis, the data flow can be
  115.  
  116.  
  117. Farber & Delp & Conte                                           [Page 2]
  118.  
  119.  
  120.  
  121. RFC 914                                                   September 1984
  122. Thinwire Protocol
  123.  
  124.  
  125.    compressed a great deal.  As there is some switching overhead, and a
  126.    reliable link level protocol is needed on the serial line, the
  127.    average effective baud rate would be in the 900 baud range.
  128.  
  129.    Each of these Thinwire possibilities will be explored in detail.
  130.  
  131. Thinwire I
  132.  
  133.    The simplest technique for the compression of packets which have
  134.    similar headers is for both the transmitting and receiving host to
  135.    store the most recent packet and transmit just the changes from one
  136.    packet to the next.  The updated information is transmitted by
  137.    sending a packet including the updated information along with a
  138.    description of where the information should be placed.  A series of
  139.    descriptor-data blocks would make up the update packet.  The
  140.    descriptor consists of the offset from the last byte changed to the
  141.    start of the data to be changed and a count of the number of data
  142.    bytes to be substituted into the old template.  The descriptor is one
  143.    byte long, with two four bit fields; offsets and counts of up to 15
  144.    bytes can be described. In the most pathological case the descriptor
  145.    adds an extra byte for every 15 bytes (or a 6% expansion).
  146.  
  147.    An example of Thinwire I in action is shown in Appendix A.  A
  148.    sequence of two single character TCP/IP Telnet packets is shown.  The
  149.    "update" packet which would actually be transmitted is shown
  150.    following them.  Each Telnet packet is 41 bytes long; the typical
  151.    update is 17 bytes.  This technique is a useful improvement over
  152.    sending entire packets.  It is also computationally simple.  It
  153.    suffers from two problems: the compression is modest, and, if there
  154.    is more than one class of packets being handled, the assumption of
  155.    common header information breaks down, causing the compression of
  156.    each class to suffer.
  157.  
  158. Thinwire II
  159.  
  160.    Both of the problems described above suggest that a more
  161.    computationally complex protocol may be appropriate.  Any major
  162.    improvement in data compression must depend on knowledge of the
  163.    protocols being used.  Thinwire II uses this knowledge to accomplish
  164.    two things.  First, the packets are sorted into classes.  The packets
  165.    from each TCP connection using the thinwire link, would, because of
  166.    their header similarities, make up a class of packets.  Recognizing
  167.    these classes and sorting by them is called "matching templates".
  168.    Second, knowledge of the protocols is used to compress the updates.
  169.    A bitfield indicating which fields in the header have changed,
  170.    followed only by the changed fields, is much shorter than the general
  171.    form of change notices.  Simple arithmetic is allowed, so 32 bit
  172.  
  173.  
  174.  
  175.  
  176. Farber & Delp & Conte                                           [Page 3]
  177.  
  178.  
  179.  
  180. RFC 914                                                   September 1984
  181. Thinwire Protocol
  182.  
  183.  
  184.    fields can often be updated in 8 or 16 bits.  By using the sorting,
  185.    protocol-specific updating, Thinwire II provides significant
  186.    compression.
  187.  
  188.    A typical transaction is described in Appendix B.  The "template
  189.    matching" is based on the unchanging fields in each class of packet.
  190.    A TCP/IP packet would match on the following fields: network type
  191.    field(IP), version, type of service, protocol(TCP), and source and
  192.    destination address and port.  Note that the 41 bytes have been
  193.    reduced to 13 bytes.  An additional advantage is that  multiple
  194.    classes of packets can be transported across the same line without
  195.    affecting the compression of each other, just by matching and storing
  196.    multiple templates.
  197.  
  198.    Some of the implications of this system are:
  199.  
  200.       o    The necessity of saving several templates (one for each
  201.            TCP/IP connection ) means that there will be a relatively
  202.            large memory requirement.  This requirement for current
  203.            personal computers is reasonable.  In addition, the gateway
  204.            must keep tables for several connections at a time.
  205.  
  206.       o    The Thinwire links are slow (that's why we call them thin);
  207.            much slower than normal disk access.  There is no reason that
  208.            inactive templates cannot be swapped out to disk and
  209.            retrieved when needed if memory is limited.  (Note that as
  210.            memory density increases, this is less and less of a
  211.            problem.)
  212.  
  213.       o    There is state information in the connections.  If the two
  214.            sides get out of synchronization with each other, data flow
  215.            stops.  This means that some method of error detection and
  216.            recovery must be provided.
  217.  
  218.       o    To minimize the problem described above, the protocol used on
  219.            the serial line must be reliable.  See Appendix D for details
  220.            of SLIP, Serial Line Interface Protocol, as an example of
  221.            such a protocol.  There must also be periodic
  222.            resynchronization.  (For example, every Nth packet would be
  223.            transmitted in full).
  224.  
  225.       o    The asynchronous link is not, by its nature, a packet
  226.            oriented system; a packet structure will need to be layered
  227.            on the character at a time transfer.  However, if the
  228.            protocol layer below thinwire (SLIP) can be trusted, the
  229.            formation of packets is a simple matter.
  230.  
  231.       o    Thinwire II will need to be enhanced for each new protocol
  232.  
  233.  
  234.  
  235. Farber & Delp & Conte                                           [Page 4]
  236.  
  237.  
  238.  
  239. RFC 914                                                   September 1984
  240. Thinwire Protocol
  241.  
  242.  
  243.            (TCP, UDP, TP4) it is called upon to service.  Any packet
  244.            type not recognized by the Thinwire connection will be
  245.            transmitted in full.
  246.  
  247.    For maintaining full network service, Thinwire II or a close variant
  248.    seems to be the solution.
  249.  
  250. Thinwire III
  251.  
  252.    When transmissions at the local network (link) level are not
  253.    required, if only the available services are desired, then a solution
  254.    based on Thinwire III may be appropriate.  A star network with a
  255.    gateway in the center serving as the connection between a number of
  256.    Personal Computers and the Internet is the key of Thinwire III.
  257.    Rather than providing connections at the network/link level, Thinwire
  258.    III assumes that there is a reliable serial link (SLIP or equivalent)
  259.    beneath it and that the workstation/personal computer has better
  260.    things to do than manage TCP state tables, timeouts, etc.  It also
  261.    assumes that the gateway supporting the Thinwire III connections is
  262.    powerful enough to run many TCP connections and several SLIP's at the
  263.    same time.  The gateway fills in for the limitations of the
  264.    communications line and the personal computer.  It provides a gateway
  265.    to the INTERNET, managing the transport and network functions,
  266.    providing both reliable stream and datagram service.
  267.  
  268.    In Thinwire III, the gateway starts an interpreter for each SLIP
  269.    connection from a personal computer.  The gateway will open TCP, UDP,
  270.    and later TP4 connections on the request of the personal computer.
  271.    Acting as the agent for the personal computer, it will manage the
  272.    remote negotiations and the data flow to and from the personal
  273.    computer.  Multiple connections can be opened, with inline logical
  274.    switches in the reliable data flow indicating which connection the
  275.    data is destined for.  Additional escaped sequences will send error
  276.    and informational data between the two Thinwire III communicators.
  277.  
  278.    This protocol is not symmetric.  The gateway will open connections to
  279.    the INTERNET world as an agent for the personal computer, but the
  280.    gateway will not be able to open inbound connections to the personal
  281.    computer, as the personal computer is perceived as a stub host.  The
  282.    personal computer may however passively open connections on the
  283.    gateway to act as a server.  Extended control sequences are specified
  284.    to handle the multiple connection negotiation that this server
  285.    ability will entail.
  286.  
  287.    This protocol seems to ignore the problem of flow control. Our
  288.    thought is that the processing on either side of the communication
  289.    link will be much speedier than the link itself.  The buffering for
  290.    the communication line and the user process blocking for this will
  291.  
  292.  
  293.  
  294. Farber & Delp & Conte                                           [Page 5]
  295.  
  296.  
  297.  
  298. RFC 914                                                   September 1984
  299. Thinwire Protocol
  300.  
  301.  
  302.    provide most of the flow control.  For the rare instances that this
  303.    is not sufficient, there are control messages to delay the flow to a
  304.    port or all data flow.
  305.  
  306.    A tentative specification for Thinwire III is attached as Appendix C.
  307.  
  308. The authors acknowledge the shoulders upon which they stand, and
  309. apologize for the toes they step on.  Ongoing work is being done by Eric
  310. Thayer, Guru Parulkar, and John Jaggers.  Special thanks are extended to
  311. Peter vonGlahn, Jon Postel and Helen Delp for their helpful comments on
  312. earlier drafts.  Responses will be greatly appreciated at the following
  313. addresses:
  314.  
  315.    Dave Farber <Farber@udel-ee>
  316.    Gary Delp <Delp@udel-ee>
  317.    Tom Conte <Conte@udel-ee>
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353. Farber & Delp & Conte                                           [Page 6]
  354.  
  355.  
  356.  
  357. RFC 914                                                   September 1984
  358. Thinwire Protocol
  359.  
  360.  
  361. Appendix A -- Example of Thinwire I Compression
  362.  
  363.    Here is an example of how Thinwire I would operate in a common
  364.    situation.  The connection is a TCP/IP Telnet connection.  The first
  365.    TCP/IP Telnet packet is on the next page; it simulates the typing of
  366.    the character "a".  The second packet would be produced by typing
  367.    "d"; it is shown on the following page.  The compressed version is on
  368.    the third page following.
  369.  
  370.    [NOTE: The checksums pictured have not been calculated.  Binary in
  371.    MSB to LSB format]
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412. Farber & Delp & Conte                                           [Page 7]
  413.  
  414.  
  415.  
  416. RFC 914                                                   September 1984
  417. Thinwire Protocol
  418.  
  419.  
  420.         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  421. IP     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  422. header:|Version|  IHL  |Type of Service|          Total Length         |
  423.        |0 1 0 0|0 1 0 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 0|
  424. P      |   4   |   5   |       0       |               41              |
  425. a      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  426. c      |       Identification          |Flags|      Fragment Offset    |
  427. k      |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0|
  428. e      |                1              |  0  |            0            |
  429. t      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  430. -      |  Time to live |   Protocol    |       Header Checksum         |
  431. 1      |0 1 1 0 0 1 0 1|0 0 0 0 0 1 1 0|0 1 1 1 0 1 1 1 0 0 0 1 0 1 0 0|
  432.        |      101      |       6       |             nnn               |
  433.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  434.        |                     Source Address                            |
  435.        |1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 0 1 1 1 0 0 0 1 0 1 0 0|
  436.        |    192.       |       5.      |     39.       |      20       |
  437.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  438.        |                   Destination Address                         |
  439.        |0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0|
  440.        |     10.       |       2.      |      0.       |      52       |
  441.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  442.         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  443. TCP    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  444. header:|         Source Port           |       Destination Port        |
  445.        |0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1|
  446.        |             1025              |               27              |
  447.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  448.        |                        Sequence Number                        |
  449.        |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 0 0|
  450.        |                              300                              |
  451.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  452.        |                     Acknowledgement Number                    |
  453.        |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0|
  454.        |                              100                              |
  455.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  456.        |offset | Reserved  |U A P R S F|            Window             |
  457.        |0 1 0 1|0 0 0 0 0 0|0 1 0 0 0 0|0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
  458.        |   5   |     0     |     16    |             512               |
  459.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  460.        |           Checksum            |         Urgent Pointer        |
  461.        |0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
  462.        |             nnn               |               0               |
  463.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  464.        |                            Data                               |
  465.        |0 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
  466.        |        "a"                                                    |
  467.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  468.  
  469.  
  470.  
  471. Farber & Delp & Conte                                           [Page 8]
  472.  
  473.  
  474.  
  475. RFC 914                                                   September 1984
  476. Thinwire Protocol
  477.  
  478.  
  479.         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  480. IP     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  481. header:|Version|  IHL  |Type of Service|          Total Length         |
  482.        |0 1 0 0|0 1 0 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 0|
  483.        |   4   |   5   |       0       |               41              |
  484.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  485. P      |       Identification*         |Flags|      Fragment Offset    |
  486. a      |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0|
  487. c      |                2              |  0  |            0            |
  488. k      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  489. e      |  Time to live*|   Protocol    |       Header Checksum*        |
  490. t      |0 1 1 0 0 1 1 0|0 0 0 0 0 1 1 0|0 1 1 1 0 1 1 1 0 0 0 1 0 1 0 0|
  491. -      |      102      |       6       |             nnn               |
  492. 2      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  493.        |                     Source Address                            |
  494.        |1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 0 1 1 1 0 0 0 1 0 1 0 0|
  495.        |    192.       |       5.      |     39.       |      20       |
  496.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  497.        |                   Destination Address                         |
  498.        |0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0|
  499.        |     10.       |       2.      |      0.       |      52       |
  500.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  501.         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  502. TCP    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  503. header:|         Source Port           |       Destination Port        |
  504.        |0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1|
  505.        |             1025              |               27              |
  506. * 's   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  507. show   |                        Sequence Number*                       |
  508. changed|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 0 1|
  509. fields |                              301                              |
  510.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  511.        |                     Acknowledgement Number*                   |
  512.        |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 1|
  513.        |                              101                              |
  514.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  515.        |offset | Reserved  |U A P R S F|            Window             |
  516.        |0 1 0 1|0 0 0 0 0 0|0 1 0 0 0 0|0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
  517.        |   5   |     0     |     16    |             512               |
  518.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  519.        |           Checksum*           |         Urgent Pointer        |
  520.        |0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
  521.        |             nnn               |               0               |
  522.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  523.        |                            Data*                              |
  524.        |0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
  525.        |        "d"                                                    |
  526.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  527.  
  528.  
  529.  
  530. Farber & Delp & Conte                                           [Page 9]
  531.  
  532.  
  533.  
  534. RFC 914                                                   September 1984
  535. Thinwire Protocol
  536.  
  537.  
  538.    The Thinwire Driver finds the template (which is the previous packet
  539.    sent), compares the template to the packet and creates a change
  540.    message (field names of change record data have been added for
  541.    comparison):
  542.  
  543.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  544.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  545.       |Descriptor byte|   Data:       |Descriptor byte|  Data:        |
  546.       |offset |length | Identification|offset |length |  Time to live |
  547.       |0 0 1 0|0 0 0 1|0 0 0 0 0 0 1 0|0 0 1 0|0 0 0 1|0 1 1 1 0 1 1 0|
  548.       |   2   |   1   |      2        |   2   |   1   |     102       |
  549.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  550.       |Descriptor byte|   Data:                       |Descriptor byte|
  551.       | offset| length|         Header Checksum       |offset |length |
  552.       |0 0 1 0|0 0 1 0|1 1 1 1 0 0 1 0 1 0 1 1 0 1 0 0|1 1 1 1|0 0 1 0|
  553.       |    2  |   2   |              nn               |  15   |   2   |
  554.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  555.       |   Data:       |Descriptor byte|   Data:       |Descriptor byte|
  556.       |   Seq Number  |offset |length |   Ack Number  |offset |length |
  557.       |0 0 1 0 1 1 0 1|0 0 1 1|0 0 0 1|0 1 1 0 0 1 0 1|0 1 1 1|0 0 1 0|
  558.       |      301      |   3   |   1   |      101      |   7   |   2   |
  559.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  560.       |   Data:                       |Descriptor byte|   Data:       |
  561.       |       -- TCP Checksum --      |offset |length |     data      |
  562.       |0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0|0 0 1 0|0 0 0 1|0 1 1 0 0 1 0 0|
  563.       |             nn                |   2   |   1   |     "d"       |
  564.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  565.       |Descriptor byte|
  566.       |offset |length |
  567.       |0 0 0 0|0 0 0 0|  the 0 0 offset/length record ends the update.
  568.       |   0   |   0   |
  569.       +-+-+-+-+-+-+-+-+
  570.  
  571.    Thinwire I then sends this message over the line where the previous
  572.    packet is updated to form the new packet.  Note: One can see that a
  573.    series of null descriptor bytes will reset the connection.
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589. Farber & Delp & Conte                                          [Page 10]
  590.  
  591.  
  592.  
  593. RFC 914                                                   September 1984
  594. Thinwire Protocol
  595.  
  596.  
  597. Appendix B -- Examples of Thinwire II Compression
  598.  
  599.    This Appendix provides an example of how the Thinwire II would
  600.    operate in a common situation.  The same original packets are used as
  601.    in Appendix A, so only the updates are shown.
  602.  
  603.    As the later field definitions depend on the contents of earlier
  604.    fields, a field by field analysis of the update packets will be
  605.    useful.
  606.  
  607.                     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  608.                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  609.       Thinwire II  |U|L|Template no| Len of change | Type of Packet|
  610.        minimum     |0|0|0 0 0 1 0 1|0 0 0 1 1 0 0 1|0 0 0 0 0 0 0 1|
  611.        header:     |N N|     5     |          41   |     TCP/IP    |
  612.                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  613.  
  614.       The first bit is the UPDATE bit. If it is a 0 this packet
  615.       describes a new template, and the entire new packet is included,
  616.       following the header.  If there was a previous template with the
  617.       same number, it will be cleared and replaced by the new template.
  618.       If the UPDATE bit is a 1, then this packet should be used to
  619.       update the template with the number given in the template number
  620.       field.
  621.  
  622.       The second bit is the LONG bit. If it is a 1 it indicates a LONG
  623.       packet.  This means that the update length field will be 16 bits
  624.       instead of 8 bits.
  625.  
  626.       The remaining 6 bits in the first byte indicate the template
  627.       number that this packet is an update to.
  628.  
  629.       The template number is followed by 1 or 2 bytes (depending on the
  630.       value of the LONG bit) which give the length of the packet. This
  631.       is the number of data bytes following the variable length header.
  632.  
  633.       If the UPDATE bit is 0 on this packet, the next byte will be a
  634.       flag telling what type of packet the sender thinks this packet is.
  635.       The flag will be saved by the receiver to interpret the update
  636.       packets.  Type 0 is for unknown types. If the type 0 flag is set,
  637.       there will be no updates to this template number.  Type 1 is
  638.       TCP/IP; the method of updating will be described below.  Type 2 is
  639.       UDP/IP; the method of update is not described at this time.
  640.  
  641.    At this time we have enough information to encode packet 1 of the
  642.    example. Assuming for the moment that this is the first packet for
  643.    this connection, the UPDATE bit would be set to 0.  As the packet has
  644.    a length of 41 and so can be described in 8 bits, the LONG bit would
  645.    be set to 0.  A template number not in use (or the oldest in use
  646.  
  647.  
  648. Farber & Delp & Conte                                          [Page 11]
  649.  
  650.  
  651.  
  652. RFC 914                                                   September 1984
  653. Thinwire Protocol
  654.  
  655.  
  656.    template number) would be assigned to this packet.  The number 5 is
  657.    illustrated.  The Length of Packet would be given as 41, and the Type
  658.    Flag set to TCP/IP (1).  The 41 bytes of the packet would follow.
  659.  
  660.    The transmission of packet 2 requires the specification of Type 1
  661.    (TCP/IP) updating.  There are portions of the packets which will
  662.    always be the same; these are described in the body of the paper, and
  663.    are used to match the template.  These do not need to be transmitted
  664.    for an update.  There are portions of the packet which will always
  665.    (well almost always) change.  These are the IP Header checksum, the
  666.    IP Identification number, and the TCP checksum.  These are
  667.    transmitted, in that order, with each template update immediately
  668.    after the packet length byte/bytes.  Following the invariant portion
  669.    of the header are updates to the fields which change some of the
  670.    time.  Which fields are different is indicated with a bitfield
  671.    describing the changes.
  672.  
  673.    The Bitfield is used to indicate which fields (of those that may stay
  674.    the same) have changed.  The technique for updating the field varies
  675.    with the field description.  The specifications for TCP/IP are shown
  676.    in Table B-1.
  677.  
  678.            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  679.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  680. Thin-  |U|L|Template no| Len of change | Type of Packet|
  681. wire II|0|0|0 0 0 1 0 1|0 0 0 1 1 0 0 1|0 0 0 0 0 0 0 1|
  682. header:|N N|     5     |          41   |     TCP/IP    |
  683.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  684.         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  685. IP     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  686. header:|Version|  IHL  |Type of Service|          Total Length         |
  687.        |0 1 0 0|0 1 0 1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 0|
  688. P      |   4   |   5   |       0       |               44              |
  689. a      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  690. c      |       Identification          |Flags|      Fragment Offset    |
  691. k      |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0|
  692. e      |                1              |  0  |            0            |
  693. t      +~+~+~+~+~.~+~+~+~+~+~+~+~+~+~+.+~+~+~+~+~+~+~+~+~+~+~.~+~+~+~+~+
  694. -                .                    .                      .
  695. 1                .                    .                      .
  696.        +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
  697.        |           Checksum            |         Urgent Pointer        |
  698.        |0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
  699.        |             nnn               |               0               |
  700.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  701.        |    Data       |
  702.        |0 1 1 0 0 0 0 1|
  703.        |        "a"    |
  704.        +-+-+-+-+-+-+-+-+
  705.  
  706.  
  707. Farber & Delp & Conte                                          [Page 12]
  708.  
  709.  
  710.  
  711. RFC 914                                                   September 1984
  712. Thinwire Protocol
  713.  
  714.  
  715.    The changed field update information is added to the update header in
  716.    the order that the bits appear in the field.  That is, if both the IP
  717.    packet length bit and the Time to Live  bit are set, the 2 new bytes
  718.    of the IP Packet length will precede the 1 new byte of the Time to
  719.    Live field.
  720.  
  721.    The update for packet 2 is shown below. Note that this is an update
  722.    to template 5, the length of update is 8 bits with a value of 1.  The
  723.    new checksums and IP Identification Number are included, and the
  724.    flags are set to indicate changes to the following fields: Time to
  725.    Live, Add 8 bits to Sequence and Acknowledgement Numbers.  The new
  726.    data is one byte following the header.
  727.  
  728.    Thinwire II would send this message over the line where it would be
  729.    reassembled into the correct packet.
  730.  
  731.    Note: For purposes of synchronization, if three 0 length, template 0,
  732.    type 0 packets are received, the next non-zero byte should be treated
  733.    as a start of packet, and the template tables cleared.
  734.  
  735.   ____________________________________________________________________
  736.  
  737.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  738.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  739.    |U|L|Template no| Len of change |   IP  Header  Checksum        |
  740.    |1|0|0 0 0 1 0 1|0 0 0 0 0 0 0 1|0 1 1 1 0 1 1 1 0 0 0 1 0 1 0 0|
  741.    |Y|N|     5     |       1       |           nnn                 |
  742.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  743.    |   IP Identification number    |      TCP  Checksum            |
  744.    |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|0 0 0 0 0 1 0 0 1 0 1 1 0 0 0 0|
  745.    |           2                   |           nnn                 |
  746.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  747.    |  Bitfield     |  Time to Live |add to Seq no. | add to Ack Num|
  748.    |0 0 1 0 1 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1|
  749.    |    T Ad8      |       1       |        1      |      1        |
  750.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  751.    |    data       |                                                
  752.    |0 0 0 1 0 1 1 1|                                                
  753.    |      "d"      |                                                
  754.    +-+-+-+-+-+-+-+-+                                                
  755.  
  756.                       Packet 2. Thinwire II update
  757.  
  758.   ____________________________________________________________________
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766. Farber & Delp & Conte                                          [Page 13]
  767.  
  768.  
  769.  
  770. RFC 914                                                   September 1984
  771. Thinwire Protocol
  772.  
  773.  
  774. Appendix C -- Tentative Specification for Thinwire III
  775.  
  776.    Thinwire III, as stated in the body of this paper, provides multiple
  777.    virtual connections over a single physical connection.  As Thinwire
  778.    III is based on a single point to point connection, much of the
  779.    per/datagram information (routing and sequencing) of other transport
  780.    systems can be eliminated.  In the steady state any bytes received by
  781.    thinwire III are sent to the default higher level protocol
  782.    connection.  There are escaped control sequences which allow the
  783.    creation of additional connections, the switching of the default
  784.    connection, the packetizing of datagrams, and the passing of
  785.    information between the gateway and the personal computer.  The
  786.    gateway and the personal computer manage a single full duplex stream,
  787.    multiplexing control requests and streams of data through the use of
  788.    embedded logical switches.
  789.  
  790.    The ascii character "z" (binary 01011011 ) is used as the escape
  791.    character.  The byte following the "z" is interpreted to determine
  792.    the command.  Table C-1 shows the general classes the  bytes (Request
  793.    codes) can fall into.
  794.  
  795.    In order to transmit the character "z", two "z"'s are transmitted.
  796.    The first is interpreted as an escape, the second as the lower case
  797.    letter "z" to be transmitted to the default connection.  The letter z
  798.    was chosen as the escape for its low occurrence in text and control
  799.    data streams, because it should pass easily through any lower level
  800.    protocols, and for its generally innocuous behavior.
  801.  
  802.    Descriptions of specifications of each of the Request codes are
  803.    below.
  804.  
  805.    Starting with the range 0-31; these Request codes change the default
  806.    connection. After a connection has been established, any characters
  807.    which come across the line that are not part of a Request code
  808.    sequence are transmitted to one of the connections.  To begin with
  809.    this connection defaults to Zero, but when the "Switch Default
  810.    Connection" command is received, characters are sent to the
  811.    connection named in the request until a new request is received.
  812.    Zero is a special diagnostic connection; anything received on
  813.    connection number Zero should be echoed back to the sender on
  814.    connection number One.  Anything received on connection number One
  815.    should be placed on the diagnostic output of the receiving host.  Any
  816.    other connection number indicates data which should be sent out the
  817.    numbered connection.  If the numbered connection has not been opened,
  818.    the data can be thrown away, and an Error Control Message returned to
  819.    the sender.
  820.  
  821.    Escapes followed by numbers 32 through 255 are for new connections,
  822.    requests for information, and error messages.  The escape will be
  823.  
  824.  
  825. Farber & Delp & Conte                                          [Page 14]
  826.  
  827.  
  828.  
  829. RFC 914                                                   September 1984
  830. Thinwire Protocol
  831.  
  832.  
  833.    followed by a Request code, a one byte Request Sequence Number (so
  834.    that the Reply to Request can be asynchronously associated with the
  835.    Request), and the arguments for the specific request.  (The length of
  836.    the argument field will be determined by the Request code.)  The
  837.    format of the request will be as pictured below:
  838.  
  839.       "z" <Request Code> <Request Sequence Number> [ <Arguments> ... ]
  840.  
  841.    At this time the Request codes 32-63 are reserved.
  842.  
  843.    The Request codes 64-127 are for stream server open requests.  For
  844.    the purposes of compression, many of the common servers are assigned
  845.    single byte codes.  See Table C-2.
  846.  
  847.    Request code 68 is to a connection to the default hostname server
  848.    used by the gateway.  It takes 3 bytes for this request. It has the
  849.    form:
  850.  
  851.       "z" < 68 > < Request Sequence Number >
  852.  
  853.    Request code 95 is to open any specified TCP Port at the specified
  854.    address.  It takes 9 bytes for this request.  It has the form:
  855.  
  856.       "z" < 95 > < Request Sequence Number > < 4 bytes of IP address> <
  857.       2 bytes of TCP Port >
  858.  
  859.    Request codes 96-127  are RESERVED for alternate transport protocols.
  860.  
  861.    The Request codes 128-191 are used for framing Datagrams and opening
  862.    new Datagram connections.  The code 128 is the Start of Datagram
  863.    code.  The format is:
  864.  
  865.       "z" <128> <Length of Datagram (2 bytes)> <Socket> Data ...
  866.  
  867.    As with the Stream opens, there are a number of assigned ports with
  868.    codes for them.  They are listed in Table C-3.
  869.  
  870.    The Request Codes 192-254 are control, status and informational
  871.    requests.  These are still under development, but will include:
  872.  
  873.       -flow control
  874.       -get host/server/protocol by entry/name/number.
  875.       -additional error messages
  876.       -overall reset
  877.       -open passive connection
  878.  
  879.    The Request Code 252 is the request to close a connection.  This
  880.    Code, followed by the connection number, indicates that no more data
  881.  
  882.  
  883.  
  884. Farber & Delp & Conte                                          [Page 15]
  885.  
  886.  
  887.  
  888. RFC 914                                                   September 1984
  889. Thinwire Protocol
  890.  
  891.  
  892.    will be sent out this connection number.  A second request with the
  893.    same connection number will indicate that no more data will be
  894.    accepted on this connection.
  895.  
  896.    The Request Code 253 is the information request for a connection. The
  897.    protocol, status, and port number of the connection should be
  898.    returned. The format of this reply has yet to be specified.
  899.  
  900.    The Request code 254 is an error notification.  These are to be
  901.    acknowledged with their Request Sequence Numbers.  Error codes are
  902.    under development.
  903.  
  904.    The Request code 255 is the Reply to Request. The Request Sequence
  905.    Number identifies the request being replied to.  The format is:
  906.  
  907.       "z" <255> <Request Sequence Number (in reply to)> <Length of reply
  908.       (1 byte)> Reply...
  909.  
  910.    The Thinwire Drivers on each side will wait at their inbound sockets,
  911.    and relay across the thinwire link
  912.    character-by-character/packet-by-packet for the stream/datagram
  913.    connections.
  914.  
  915.    Thinwire III is labeled as a tentative specification, because at this
  916.    time, in order to publish this RFC in a timely fashion, several minor
  917.    issues are still unresolved.  An example is the scheduling of serial
  918.    line use. Short messages could be given priority over long packets,
  919.    or priority schemes could be changed during the session, depending
  920.    upon the interactive desire of the user.  Addition issues will be
  921.    resolved in the future.
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943. Farber & Delp & Conte                                          [Page 16]
  944.  
  945.  
  946.  
  947. RFC 914                                                   September 1984
  948. Thinwire Protocol
  949.  
  950.  
  951. Appendix D -- Serial Line Interface Protocol (SLIP)
  952.  
  953.    Initial Specifications and Implementation Suggestions
  954.  
  955.    PHILOSOPHY
  956.  
  957.       The world is a dangerous place for bits.  Data transmission can be
  958.       an time consuming business when one has to make sure that bits
  959.       don't get lost, destroyed, or forgotten.  To reduce such problems,
  960.       the Serial Line Interface Protocol (SLIP) maintains an attitude
  961.       toward the world that includes both a mistrust of serial lines and
  962.       a margin of laziness.  Examples of this approach include how SLIP
  963.       recovers from errors and how SLIP handles the problem of
  964.       resequencing (see PROTOCOL SPECIFICATIONS and IMPLEMENTATION
  965.       SUGGESTIONS).
  966.  
  967.    THE MESSAGE FORMAT
  968.  
  969.       Both the Sender Task and the Receiver Task communicate using a
  970.       standard message format and the Sender and Receiver Task of one
  971.       machine's SLIP communicate using a shared buffer.  The message
  972.       begins with a 1 byte Start of Header token (StH, 11111111) and is
  973.       followed by a sequence number of four bits (SEQ) and an
  974.       acknowledgement number of four bits (ACK).  Following the StH, SEQ
  975.       and ACK, is a 5 bit length field which specifies the length of the
  976.       data contained in the message. Following the length is a three bit
  977.       field of flags.  The first bit is used to indicate that the a
  978.       receive error has occurred, and the ACK is actually a repeat of
  979.       the Last Acknowledged message (a LACK).  The second bit is used to
  980.       indicate a Synchronize Sequence Numbers message (SSNM), and the
  981.       third bit is used to indicate a Start of Control Message (SOCM);
  982.       all three of these flags are explained below. Finally, at the end
  983.       of the message is an exclusive-or checksum.  The message format is
  984.       shown in figure D-1.
  985.  
  986.             ________________________________________________
  987.  
  988.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  989. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
  990. |     StH       |  SEQ  |  ACK  |  Length |Flags|...Data...
  991. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
  992. The maximum data length is 32 bytes.                0 1 2 3 4 5 6 7
  993. This limits the vulnerability of receiver       ...-+-+-+-+-+-+-+-+-+-+
  994. timeout errors occurring because of bit error .Data...|   Checksum    |
  995. in the length field.                            ...-+-+-+-+-+-+-+-+-+-+
  996.  
  997.                     Figure D-1. SLIP Message Format
  998.  
  999.             ________________________________________________
  1000.  
  1001.  
  1002. Farber & Delp & Conte                                          [Page 17]
  1003.  
  1004.  
  1005.  
  1006. RFC 914                                                   September 1984
  1007. Thinwire Protocol
  1008.  
  1009.  
  1010.       The Sender, when idle but needing to acknowledge, will send out
  1011.       short messages of the same format as a regular message but with
  1012.       the SOCM flag set and the data field omitted.  ( This short
  1013.       message is called a SOCM, and is used instead of a zero length
  1014.       message to avoid the problem of continually ACK'ing ACK's ). The
  1015.       Sender Task, when originating a connection (see STARTING UP AND
  1016.       FINISHING OFF COMMUNICATIONS), will send out another short message
  1017.       but with the SSNM flag set and the data omitted.  This message (a
  1018.       SSNM) used for a TCP-style 3 way startup handshake.
  1019.  
  1020.    PROTOCOL SPECIFICATIONS and SUGGESTIONS
  1021.  
  1022.       The SLIP module, when called with data to send, prepends its
  1023.       header (SEE ABOVE) to the data, calculates a checksum and appends
  1024.       the checksum at the end.  (This creates a message.)  The message
  1025.       has a sequence number associated with it which represents the
  1026.       position of the message in the Sender SLIP's buffers.  The
  1027.       sequence number for the message can range from 0 to 15 and is
  1028.       returned in the ACK field of the other machine's Sender SLIP
  1029.       messages to acknowledge receipt.
  1030.  
  1031.       There are two scenarios for transmission.  In the first, both
  1032.       SLIP's will be transmitting to each other.  To send an
  1033.       acknowledgement, the Receiver SLIP uses the ACK field in its next
  1034.       outgoing message. To receive an acknowledgement, the Sender checks
  1035.       the ACK field of its Receiver's incoming messages.  In the second
  1036.       scenario, one SLIP may have no data to transmit for a long time.
  1037.       Then, as stated above, to acknowledge a received message, the
  1038.       Receiver has its Sender send out a short message, the SOCM (SEE
  1039.       ABOVE) which specifies the message it is acknowledging.  The SOCM
  1040.       includes a checksum of its total contents.  If there is a checksum
  1041.       error, THE SOCM IS IGNORED.
  1042.  
  1043.       When there is a checksum error on a received normal message, the
  1044.       Receiver asks its Sender to send out a SOCM with the LACK flag
  1045.       set, or set the LACK flag on its next message.  The Sender sends
  1046.       this flag ONCE then ceases to increment the acknowledgement number
  1047.       (the ACK) while the Receiver continues to check incoming messages
  1048.       for the sequence number of the message with a checksum error.
  1049.       (Note that it continues to react to the acknowledgement field in
  1050.       the incoming messages.) When it finds the needed message, it
  1051.       resumes accepting the data in new messages and increments the
  1052.       acknowledgement number transmitted accordingly.
  1053.  
  1054.       The sending SLIP must never send a message greater than four past
  1055.       the last message for which it has received an acknowledgement
  1056.       (effectively a window size of four). Under normal processing
  1057.       loads, a window size greater than four should not be needed, and
  1058.       this decreases the probability of random errors creating valid
  1059.  
  1060.  
  1061. Farber & Delp & Conte                                          [Page 18]
  1062.  
  1063.  
  1064.  
  1065. RFC 914                                                   September 1984
  1066. Thinwire Protocol
  1067.  
  1068.  
  1069.       acknowledgement or sequence numbers.  If the Sender has four
  1070.       unacknowledged messages outstanding, it will retransmit the old
  1071.       messages, starting from the oldest unacknowledged message.  If it
  1072.       receives an acknowledgement with the LACK flag set, it transmits
  1073.       the message following the LACK number and continues to transmit
  1074.       the messages from that one on.  Thus a LACK is a message asking
  1075.       the Sender to please the Receiver.  If the Sender times out on any
  1076.       message not logically greater than four past the last acknowledged
  1077.       message, it should retransmit the message that timed out and then
  1078.       continues to transmit messages following the timed out message.
  1079.  
  1080.       The following describes a partial implementation of SLIP.  System
  1081.       dependent subjects like buffer management, timer handling and
  1082.       calling conventions are discussed.
  1083.  
  1084.       The SLIP implementation is subdivided into four modules and two
  1085.       sets of input/output interfaces.  The four modules are: The Sender
  1086.       Task, The Receiver Task, the buffer Manager, and SLIPTIME (the
  1087.       timer). The two interfaces are to the higher protocol and to the
  1088.       lower protocol (the UARTian, an interrupt driven device driver for
  1089.       the serial lines).
  1090.  
  1091.    OPERATIONS OF THE SENDER TASK
  1092.  
  1093.       The Sender Task takes a relatively noncomplex approach to
  1094.       transmitting.  It sends message zero, sets a timer (using the
  1095.       SLIPTIME Task) on the message, and proceeds to send and set timers
  1096.       for messages one, two, and three.  When the Receiver Task tells
  1097.       the Sender Task that a message has been acknowledged, the Sender
  1098.       Task then clears the timer for that message, and marks it
  1099.       acknowledged.  When the Sender Task has finished sending a
  1100.       message, it checks several conditions to decide what to do next.
  1101.       It first checks to see if a LACK has been received. If it has then
  1102.       it clears all the timers, and begins retransmitting messages
  1103.       (updating the acknowledgement field and checksum) starting from
  1104.       the one after the LACK'ed message.  If there is not a LACK waiting
  1105.       for the Sender Task, it checks to see if any messages have timed
  1106.       out.  If a message has timed out, the Sender Task again will clear
  1107.       the timers and begin retransmitting from the message number which
  1108.       timed out.  If neither of these conditions are true, the Sender
  1109.       Task checks to see if, because it has looped back to retransmit,
  1110.       it has any previously formulated messages to send.  If so, it send
  1111.       the first of these messages. If it does not have previously
  1112.       formulated messages, it checks to see if it is more than three
  1113.       past the last acknowledged message.  If so, it restarts from the
  1114.       message after the last acknowledged message.  If none of these are
  1115.       true, then it checks to see if there is more data waiting to be
  1116.       transmitted.  If there is more data available, it forms the
  1117.       largest packet it can, and begins to transmit it.  If there is no
  1118.  
  1119.  
  1120. Farber & Delp & Conte                                          [Page 19]
  1121.  
  1122.  
  1123.  
  1124. RFC 914                                                   September 1984
  1125. Thinwire Protocol
  1126.  
  1127.  
  1128.       more data to transmit, it checks to see if it needs to acknowledge
  1129.       a message received from the other side.  If so then it sends a
  1130.       SOCM.  If none of the above conditions create work for the Sender
  1131.       Task, the task suspends itself.
  1132.  
  1133.       Note that the Sender Task uses the Receiver Task to find out about
  1134.       acknowledgements and the Receiver Task uses the Sender Task to
  1135.       send acknowledgements to the other SLIP on the other side (via the
  1136.       ACK field in the Sender Task's message). The two tasks on one
  1137.       machine communicate through a small buffer. Because
  1138.       acknowledgements need to be passed back to the Sender Task
  1139.       quickly, the Receiver Task can wake up the Sender Task (unblock
  1140.       it).
  1141.  
  1142.    OPERATIONS OF THE RECEIVER TASK
  1143.  
  1144.       The Receiver Task checks the checksums of the messages coming into
  1145.       it.  When it gets a checksum error, it tells the Sender Task to
  1146.       mark the next acknowledgement as a LACK.  It then throws away all
  1147.       messages coming into it that don't match the message it wants and
  1148.       continues to acknowledge with the last ACK until it gets the
  1149.       message it wants.  As a checksum error could be the result of a
  1150.       crashed packet, and the StH character can occur within the packet,
  1151.       when a checksum error does occur, the recovery includes scanning
  1152.       forward from the last StH character for the next StH character
  1153.       then attempting to verify a packet beginning from it.  A valid
  1154.       message includes a valid checksum, and sequence and
  1155.       acknowledgement numbers within the active window of numbers.  This
  1156.       eliminates the need for the resequencing of messages, because the
  1157.       Receiver Task throws away anything that would make information in
  1158.       its buffers out of sequence.
  1159.  
  1160.    OPERATIONS OF SLIPTIME
  1161.  
  1162.       The timer task will maintain and update a table of timers for each
  1163.       request.  Its functions should be called with the timer length and
  1164.       the sequence number to associate with the timer.  Its functions
  1165.       can also be called with a request to delete a timer.  An
  1166.       interrupt-driven mechanism is used to update the running timers
  1167.       and to wake up the Sender when an alarm goes off.
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179. Farber & Delp & Conte                                          [Page 20]
  1180.  
  1181.  
  1182.  
  1183. RFC 914                                                   September 1984
  1184. Thinwire Protocol
  1185.  
  1186.  
  1187.    THE INPUT AND OUTPUT INTERFACES
  1188.  
  1189.       To force SLIP to do something, the higher protocol should create a
  1190.       buffer and then call SLIP, passing it a pointer to the buffer.
  1191.       SLIP will then read the buffer and begin sending it.  The call to
  1192.       SLIP will return the number of bytes written, negative number
  1193.       indicates to the caller that SLIP could not do the request.  Exact
  1194.       error numbers will be assigned in the future.  To ask SLIP to
  1195.       receive something, one would call SLIP and SLIP would immediately
  1196.       return the number of bytes received or a negative number for an
  1197.       error (nothing ready to receive, for example).
  1198.  
  1199.       SLIP, when it wants to talk to the underworld of the serial
  1200.       interface, will do much the same thing only through a buffer
  1201.       written to by the UARTian (for received data) and read from by the
  1202.       UARTian (for sent data).
  1203.  
  1204.    OPERATIONS OF THE BUFFER/WINDOW MANAGER
  1205.  
  1206.       The Manager tends a continuous, circular buffer for the Sender
  1207.       Task in which data to be sent (from the downcalling protocol) is
  1208.       stored.  This buffer is called the INPUT-DATA BUFFER (IDBuff).
  1209.       The Manager also manages a SENDER TASK'S OUTPUT-DATA BUFFER
  1210.       (SODBuff), which is its output buffer to the UARTian.
  1211.  
  1212.       The IDBuff has associated with it some parameters.  These
  1213.       parameters include: START OF MEMORY (SOM), the start of memory
  1214.       reserved for the IDBuff; END OF MEMORY (EOM), the end of memory
  1215.       reserved; START OF DATA (SOD), the beginning of the used portion
  1216.       of the IDBuff; and END OF DATA (EOD), the end of data in the
  1217.       IDBuff.  The SOM and EOM are constants whereas the SOD and EOD are
  1218.       variables.
  1219.  
  1220.       The SODBuff is composed of four buffers for four outbound messages
  1221.       (less the checksum).  The buffers can be freed up to be
  1222.       overwritten when the message that they contain is acknowledged by
  1223.       the SLIP on the other side of the line.  When a message is in the
  1224.       SODBuff, it has associated with it a sequence number (which is the
  1225.       message's sequence number).  The Sender Task can reference the
  1226.       data in the SODBuff and reference acknowledgements via this
  1227.       sequence number.
  1228.  
  1229.       When the application has data to be transmitted, it is placed in
  1230.       the IDBuff by the application using functions from the Manager and
  1231.       the EOD is incremented.  If the data the application wants to send
  1232.       won't fit in the buffer, no data is written, and the application
  1233.       can either sleep, or continue to attempt to write data until the
  1234.  
  1235.  
  1236.  
  1237.  
  1238. Farber & Delp & Conte                                          [Page 21]
  1239.  
  1240.  
  1241.  
  1242. RFC 914                                                   September 1984
  1243. Thinwire Protocol
  1244.  
  1245.  
  1246.       data will fit. The Sender Task calls a Manager function to fill a
  1247.       message slot in the SODBuff.  The Sender Task then sends its
  1248.       message from the SODBuff.
  1249.  
  1250.       The Manager also maintains a buffer set for the Receiver Task. The
  1251.       buffers are similar to those of the Sender Task.  There is a
  1252.       CHECKSUMMED OUTPUT-DATA BUFFER (CODBuff), which is the final
  1253.       output from SLIP that the higher level protocol may read.  The
  1254.       CODBuff is also controlled by the four parameters START OF MEMORY,
  1255.       END OF MEMORY, START OF DATA, and END OF DATA (SOM, EOM, SOD, and
  1256.       EOD).
  1257.  
  1258.       There is also an inbound circular buffer the analog of the
  1259.       SODBuff, called the RECEIVER TASK'S INPUT-DATA BUFFER (RIDBuff).
  1260.  
  1261.       When the UARTian gets data, it places the data in the RIDBuff.
  1262.       After this, the Receiver Task checksums the data.  If the checksum
  1263.       is good and the Receiver Task opts to acknowledge the message, it
  1264.       moves the data to the CODBuff, increments EOD, and frees up space
  1265.       in the RIDBuff.  The higher level application can then take data
  1266.       off on the CODBuff, incrementing SOD as it does so.
  1267.  
  1268.    STARTING UP AND FINISHING OFF COMMUNICATIONS
  1269.  
  1270.       The problem is that the SLIP's on either side need to know (and
  1271.       keep knowing) the sequence number of the other SLIP.  The easiest
  1272.       way to solve most of these problems is to have the SLIP check the
  1273.       Request to Send and Clear to Send Lines to see if the other SLIP
  1274.       is active. On startup, or if it has reason to believe the other
  1275.       side has died, the SLIP assumes: all connections are closed, no
  1276.       data from any connection has been sent, and both its SEQ and the
  1277.       SEQ of the other SLIP are zero.  To start up a connection, the
  1278.       instigating SLIP sends a SSNM with its starting sequence number in
  1279.       it.  The receiving SLIP acknowledges this SSNM and replies with
  1280.       its starting sequence number (combined into one message).  Then
  1281.       the sending SLIP acknowledges the receiving SLIP's starting
  1282.       sequence number and the transmission commences.  This is the three
  1283.       way handshake taken from TCP, After which data transmission can
  1284.       begin.
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294.  
  1295.  
  1296.  
  1297. Farber & Delp & Conte                                          [Page 22]
  1298.  
  1299.