rfc914.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

RFC 914                                                   September 1984
Thinwire Protocol


   template number) would be assigned to this packet.  The number 5 is
   illustrated.  The Length of Packet would be given as 41, and the Type
   Flag set to TCP/IP (1).  The 41 bytes of the packet would follow.

   The transmission of packet 2 requires the specification of Type 1
   (TCP/IP) updating.  There are portions of the packets which will
   always be the same; these are described in the body of the paper, and
   are used to match the template.  These do not need to be transmitted
   for an update.  There are portions of the packet which will always
   (well almost always) change.  These are the IP Header checksum, the
   IP Identification number, and the TCP checksum.  These are
   transmitted, in that order, with each template update immediately
   after the packet length byte/bytes.  Following the invariant portion
   of the header are updates to the fields which change some of the
   time.  Which fields are different is indicated with a bitfield
   describing the changes.

   The Bitfield is used to indicate which fields (of those that may stay
   the same) have changed.  The technique for updating the field varies
   with the field description.  The specifications for TCP/IP are shown
   in Table B-1.

           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thin-  |U|L|Template no| Len of change | Type of Packet|
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|
header:|N N|     5     |          41   |     TCP/IP    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        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
IP     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header:|Version|  IHL  |Type of Service|          Total Length         |
       |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|
P      |   4   |   5   |       0       |               44              |
a      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c      |       Identification          |Flags|      Fragment Offset    |
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|
e      |                1              |  0  |            0            |
t      +~+~+~+~+~.~+~+~+~+~+~+~+~+~+~+.+~+~+~+~+~+~+~+~+~+~+~.~+~+~+~+~+
-                .                    .                      .
1                .                    .                      .
       +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
       |           Checksum            |         Urgent Pointer        |
       |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|
       |             nnn               |               0               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Data       |
       |0 1 1 0 0 0 0 1|
       |        "a"    |
       +-+-+-+-+-+-+-+-+


Farber & Delp & Conte                                          [Page 12]



RFC 914                                                   September 1984
Thinwire Protocol


   The changed field update information is added to the update header in
   the order that the bits appear in the field.  That is, if both the IP
   packet length bit and the Time to Live  bit are set, the 2 new bytes
   of the IP Packet length will precede the 1 new byte of the Time to
   Live field.

   The update for packet 2 is shown below. Note that this is an update
   to template 5, the length of update is 8 bits with a value of 1.  The
   new checksums and IP Identification Number are included, and the
   flags are set to indicate changes to the following fields: Time to
   Live, Add 8 bits to Sequence and Acknowledgement Numbers.  The new
   data is one byte following the header.

   Thinwire II would send this message over the line where it would be
   reassembled into the correct packet.

   Note: For purposes of synchronization, if three 0 length, template 0,
   type 0 packets are received, the next non-zero byte should be treated
   as a start of packet, and the template tables cleared.

  ____________________________________________________________________

     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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|L|Template no| Len of change |   IP  Header  Checksum        |
   |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|
   |Y|N|     5     |       1       |           nnn                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   IP Identification number    |      TCP  Checksum            |
   |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|
   |           2                   |           nnn                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Bitfield     |  Time to Live |add to Seq no. | add to Ack Num|
   |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|
   |    T Ad8      |       1       |        1      |      1        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    data       |                                                
   |0 0 0 1 0 1 1 1|                                                
   |      "d"      |                                                
   +-+-+-+-+-+-+-+-+                                                

                      Packet 2. Thinwire II update

  ____________________________________________________________________







Farber & Delp & Conte                                          [Page 13]



RFC 914                                                   September 1984
Thinwire Protocol


Appendix C -- Tentative Specification for Thinwire III

   Thinwire III, as stated in the body of this paper, provides multiple
   virtual connections over a single physical connection.  As Thinwire
   III is based on a single point to point connection, much of the
   per/datagram information (routing and sequencing) of other transport
   systems can be eliminated.  In the steady state any bytes received by
   thinwire III are sent to the default higher level protocol
   connection.  There are escaped control sequences which allow the
   creation of additional connections, the switching of the default
   connection, the packetizing of datagrams, and the passing of
   information between the gateway and the personal computer.  The
   gateway and the personal computer manage a single full duplex stream,
   multiplexing control requests and streams of data through the use of
   embedded logical switches.

   The ascii character "z" (binary 01011011 ) is used as the escape
   character.  The byte following the "z" is interpreted to determine
   the command.  Table C-1 shows the general classes the  bytes (Request
   codes) can fall into.

   In order to transmit the character "z", two "z"'s are transmitted.
   The first is interpreted as an escape, the second as the lower case
   letter "z" to be transmitted to the default connection.  The letter z
   was chosen as the escape for its low occurrence in text and control
   data streams, because it should pass easily through any lower level
   protocols, and for its generally innocuous behavior.

   Descriptions of specifications of each of the Request codes are
   below.

   Starting with the range 0-31; these Request codes change the default
   connection. After a connection has been established, any characters
   which come across the line that are not part of a Request code
   sequence are transmitted to one of the connections.  To begin with
   this connection defaults to Zero, but when the "Switch Default
   Connection" command is received, characters are sent to the
   connection named in the request until a new request is received.
   Zero is a special diagnostic connection; anything received on
   connection number Zero should be echoed back to the sender on
   connection number One.  Anything received on connection number One
   should be placed on the diagnostic output of the receiving host.  Any
   other connection number indicates data which should be sent out the
   numbered connection.  If the numbered connection has not been opened,
   the data can be thrown away, and an Error Control Message returned to
   the sender.

   Escapes followed by numbers 32 through 255 are for new connections,
   requests for information, and error messages.  The escape will be


Farber & Delp & Conte                                          [Page 14]



RFC 914                                                   September 1984
Thinwire Protocol


   followed by a Request code, a one byte Request Sequence Number (so
   that the Reply to Request can be asynchronously associated with the
   Request), and the arguments for the specific request.  (The length of
   the argument field will be determined by the Request code.)  The
   format of the request will be as pictured below:

      "z" <Request Code> <Request Sequence Number> [ <Arguments> ... ]

   At this time the Request codes 32-63 are reserved.

   The Request codes 64-127 are for stream server open requests.  For
   the purposes of compression, many of the common servers are assigned
   single byte codes.  See Table C-2.

   Request code 68 is to a connection to the default hostname server
   used by the gateway.  It takes 3 bytes for this request. It has the
   form:

      "z" < 68 > < Request Sequence Number >

   Request code 95 is to open any specified TCP Port at the specified
   address.  It takes 9 bytes for this request.  It has the form:

      "z" < 95 > < Request Sequence Number > < 4 bytes of IP address> <
      2 bytes of TCP Port >

   Request codes 96-127  are RESERVED for alternate transport protocols.

   The Request codes 128-191 are used for framing Datagrams and opening
   new Datagram connections.  The code 128 is the Start of Datagram
   code.  The format is:

      "z" <128> <Length of Datagram (2 bytes)> <Socket> Data ...

   As with the Stream opens, there are a number of assigned ports with
   codes for them.  They are listed in Table C-3.

   The Request Codes 192-254 are control, status and informational
   requests.  These are still under development, but will include:

      -flow control
      -get host/server/protocol by entry/name/number.
      -additional error messages
      -overall reset
      -open passive connection

   The Request Code 252 is the request to close a connection.  This
   Code, followed by the connection number, indicates that no more data



Farber & Delp & Conte                                          [Page 15]



RFC 914                                                   September 1984
Thinwire Protocol


   will be sent out this connection number.  A second request with the
   same connection number will indicate that no more data will be
   accepted on this connection.

   The Request Code 253 is the information request for a connection. The
   protocol, status, and port number of the connection should be
   returned. The format of this reply has yet to be specified.

   The Request code 254 is an error notification.  These are to be
   acknowledged with their Request Sequence Numbers.  Error codes are
   under development.

   The Request code 255 is the Reply to Request. The Request Sequence
   Number identifies the request being replied to.  The format is:

      "z" <255> <Request Sequence Number (in reply to)> <Length of reply
      (1 byte)> Reply...

   The Thinwire Drivers on each side will wait at their inbound sockets,
   and relay across the thinwire link
   character-by-character/packet-by-packet for the stream/datagram
   connections.

   Thinwire III is labeled as a tentative specification, because at this
   time, in order to publish this RFC in a timely fashion, several minor
   issues are still unresolved.  An example is the scheduling of serial
   line use. Short messages could be given priority over long packets,
   or priority schemes could be changed during the session, depending
   upon the interactive desire of the user.  Addition issues will be
   resolved in the future.





















Farber & Delp & Conte                                          [Page 16]



RFC 914                                                   September 1984
Thinwire Protocol


Appendix D -- Serial Line Interface Protocol (SLIP)

   Initial Specifications and Implementation Suggestions

   PHILOSOPHY

      The world is a dangerous place for bits.  Data transmission can be
      an time consuming business when one has to make sure that bits
      don't get lost, destroyed, or forgotten.  To reduce such problems,
      the Serial Line Interface Protocol (SLIP) maintains an attitude
      toward the world that includes both a mistrust of serial lines and
      a margin of laziness.  Examples of this approach include how SLIP
      recovers from errors and how SLIP handles the problem of
      resequencing (see PROTOCOL SPECIFICATIONS and IMPLEMENTATION
      SUGGESTIONS).

   THE MESSAGE FORMAT

      Both the Sender Task and the Receiver Task communicate using a
      standard message format and the Sender and Receiver Task of one
      machine's SLIP communicate using a shared buffer.  The message
      begins with a 1 byte Start of Header token (StH, 11111111) and is
      followed by a sequence number of four bits (SEQ) and an
      acknowledgement number of four bits (ACK).  Following the StH, SEQ
      and ACK, is a 5 bit length field which specifies the length of the