📄 rfc914.txt
字号:
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -