As per Relevance of the word knowledge, we have this rfc below:
Network Working Group David J.
Request for Comments: 914 Gary S.
Thomas M.
University of
September 1984
A Thinwire
for connecting personal
to the
Status of this
This RFC focuses discussion on the particular problems in
ARPA-Internet of low speed network interconnection with
computers, and possible methods of solution. None of the
solutions in this document are intended as standards for
ARPA-Internet. Rather, it is hoped that a general consensus
emerge as to the appropriate solution to the problems,
eventually to the adoption of standards. Distribution of this
unlimited
What is the Problem Anyway ?
As we connect workstations and personal computers to the INTERNET
many of the cost/speed communication tradeoffs change. This has
us reconsider the way we juggle the protocol and hardware
tradeoffs. With substantial computing power available in the $3--10
range, it is feasible to locate computers at their point of use
including in buildings, in our homes, and other places remote
the existing high speed connections. Dedicated 56k baud lines
costly, have limited availability, and long lead time
installation. High speed LAN's are not an applicable
solution. These two facts ensure that readily available 1200 / 2400
baud phone modems over dialed or leased telephone lines will be
important part of the interconnection scheme in the near future
This paper will consider some of the problems and
involved with using a "thin" (less than 9600 baud) data path. A
of "THINWIRE" protocols for connecting a personal computer to
INTERNET are presented for discussion
Although the cost and flexibility of telephone modems is
attractive, their low speed produces some major problems. As
example, a minimum TCP/IP Telnet packet (one character) is 41
long. At 1200 baud, the transmission time for such a packet would
around 0.3 seconds. This is equivalent to using a 30 baud line
single character transmission. (Throughout the paper, the
is made that the transmission speed is limited only by the speed
the communication line. We also assume that the line will act as
synchronous link when calculating speed. In reality, with interrupt
computational, and framing overhead, the times could be 10-50%
worse.)
In many cases, local echo and line editing can allow
Farber & Delp & Conte [Page 1]
RFC 914 September 1984
Thinwire
Telnet behavior, but many applications will work only with
at a time transmission. In addition, multiple data streams can
very useful for fully taking advantage of the
computer/Internet link. Thus this proposal
There are several forms that a solution to this problem can take
Three of these are listed below, followed by descriptions of
solutions of each form
o As a non-solution, one can learn to live with the
communication (possibly a reasonable thing to do for
file transfer and one-time inquiries to time, date,
quote-of-the-day servers).
o Using TCP/IP, one can intercept the link level transmissions
and try various kinds of compression algorithms. This
for a symmetrical structure on either side of the "Thinwire".
o One could build an "asymmetrical" gateway which takes some
the transport and network communication overhead away from
the serial link and the personal computer. The object would
to make the PC do the local work, and to make
interconnection with the extended network a benefit to the
and not a drain on the facilities of the PC
The first form has the advantage of simplicity and ease
implementation. The disadvantages have been discussed above.
second form, compression at link level, can be exploited in two ways
Thinwire I is a simple robust compressor, which will reduce the 41
byte minimum TCP/IP Telnet packets to a series of 17 byte
packets. This would improve the effective baud rate from 30
to 70 baud over a 1200 baud line (for single character packets).
Thinwire II uses a considerably more complex technique, and
advantage of the storage and processing power on either side
the thinwire link. Thinwire II will compress packets
multiple TCP/IP connections from 41 bytes down to 13 bytes.
increased communication rate is 95 (effective) baud for
character packets
The third form balances the characteristics of the personal computer
the communications line, the gateway, and the Internet protocols
optimize the utility of the communications and the
itself. Instead of running full transport and internet layers on
PC, the PC and the gateway manage a single reliable stream
multiplexing data on this stream with control requests. Without
interneting and flow control structures traveling over
communications line on a per/packet basis, the data flow can
Farber & Delp & Conte [Page 2]
RFC 914 September 1984
Thinwire
compressed a great deal. As there is some switching overhead, and
reliable link level protocol is needed on the serial line,
average effective baud rate would be in the 900 baud range
Each of these Thinwire possibilities will be explored in detail
Thinwire
The simplest technique for the compression of packets which
similar headers is for both the transmitting and receiving host
store the most recent packet and transmit just the changes from
packet to the next. The updated information is transmitted
sending a packet including the updated information along with
description of where the information should be placed. A series
descriptor-data blocks would make up the update packet.
descriptor consists of the offset from the last byte changed to
start of the data to be changed and a count of the number of
bytes to be substituted into the old template. The descriptor is
byte long, with two four bit fields; offsets and counts of up to 15
bytes can be described. In the most pathological case the
adds an extra byte for every 15 bytes (or a 6% expansion).
An example of Thinwire I in action is shown in Appendix A.
sequence of two single character TCP/IP Telnet packets is shown.
"update" packet which would actually be transmitted is
following them. Each Telnet packet is 41 bytes long; the
update is 17 bytes. This technique is a useful improvement
sending entire packets. It is also computationally simple.
suffers from two problems: the compression is modest, and, if
is more than one class of packets being handled, the assumption
common header information breaks down, causing the compression
each class to suffer
Thinwire
Both of the problems described above suggest that a
computationally complex protocol may be appropriate. Any
improvement in data compression must depend on knowledge of
protocols being used. Thinwire II uses this knowledge to
two things. First, the packets are sorted into classes. The
from each TCP connection using the thinwire link, would, because
their header similarities, make up a class of packets.
these classes and sorting by them is called "matching templates".
Second, knowledge of the protocols is used to compress the updates
A bitfield indicating which fields in the header have changed
followed only by the changed fields, is much shorter than the
form of change notices. Simple arithmetic is allowed, so 32
Farber & Delp & Conte [Page 3]
RFC 914 September 1984
Thinwire
fields can often be updated in 8 or 16 bits. By using the sorting
protocol-specific updating, Thinwire II provides
compression
A typical transaction is described in Appendix B. The "
matching" is based on the unchanging fields in each class of packet
A TCP/IP packet would match on the following fields: network
field(IP), version, type of service, protocol(TCP), and source
destination address and port. Note that the 41 bytes have
reduced to 13 bytes. An additional advantage is that
classes of packets can be transported across the same line
affecting the compression of each other, just by matching and
multiple templates
Some of the implications of this system are
o The necessity of saving several templates (one for
TCP/IP connection ) means that there will be a
large memory requirement. This requirement for
personal computers is reasonable. In addition, the
must keep tables for several connections at a time
o The Thinwire links are slow (that's why we call them thin);
much slower than normal disk access. There is no reason
inactive templates cannot be swapped out to disk
retrieved when needed if memory is limited. (Note that
memory density increases, this is less and less of
problem.)
o There is state information in the connections. If the
sides get out of synchronization with each other, data
stops. This means that some method of error detection
recovery must be provided
o To minimize the problem described above, the protocol used
the serial line must be reliable. See Appendix D for
of SLIP, Serial Line Interface Protocol, as an example
such a protocol. There must also be
resynchronization. (For example, every Nth packet would
transmitted in full).
o The asynchronous link is not, by its nature, a
oriented system; a packet structure will need to be
on the character at a time transfer. However, if
protocol layer below thinwire (SLIP) can be trusted,
formation of packets is a simple matter
o Thinwire II will need to be enhanced for each new
Farber & Delp & Conte [Page 4]
RFC 914 September 1984
Thinwire
(TCP, UDP, TP4) it is called upon to service. Any
type not recognized by the Thinwire connection will
transmitted in full
For maintaining full network service, Thinwire II or a close
seems to be the solution
Thinwire
When transmissions at the local network (link) level are
required, if only the available services are desired, then a
based on Thinwire III may be appropriate. A star network with
gateway in the center serving as the connection between a number
Personal Computers and the Internet is the key of Thinwire III
Rather than providing connections at the network/link level,
III assumes that there is a reliable serial link (SLIP or equivalent
beneath it and that the workstation/personal computer has
things to do than manage TCP state tables, timeouts, etc. It
assumes that the gateway supporting the Thinwire III connections
powerful enough to run many TCP connections and several SLIP's at
same time. The gateway fills in for the limitations of
communications line and the personal computer. It provides a
to the INTERNET, managing the transport and network functions
providing both reliable stream and datagram service
In Thinwire III, the gateway starts an interpreter for each
connection from a personal computer. The gateway will open TCP, UDP
and later TP4 connections on the request of the personal computer
Acting as the agent for the personal computer, it will manage
remote negotiations and the data flow to and from the
computer. Multiple connections can be opened, with inline
switches in the reliable data flow indicating which connection
data is destined for. Additional escaped sequences will send
and informational data between the two Thinwire III communicators
This protocol is not symmetric. The gateway will open connections
the INTERNET world as an agent for the personal computer, but
gateway will not be able to open inbound connections to the
computer, as the personal computer is perceived as a stub host.
personal computer may however passively open connections on
gateway to act as a server. Extended control sequences are
to handle the multiple connection negotiation that this
ability will entail
This protocol seems to ignore the problem of flow control.
thought is that the processing on either side of the
link will be much speedier than the link itself. The buffering
the communication line and the user process blocking for this
Farber & Delp & Conte [Page 5]
RFC 914 September 1984
Thinwire
provide most of the flow control. For the rare instances that
is not sufficient, there are control messages to delay the flow to
port or all data flow
A tentative specification for Thinwire III is attached as Appendix C
The authors acknowledge the shoulders upon which they stand,
apologize for the toes they step on. Ongoing work is being done by
Thayer, Guru Parulkar, and John Jaggers. Special thanks are extended
Peter vonGlahn, Jon Postel and Helen Delp for their helpful comments
earlier drafts. Responses will be greatly appreciated at the
addresses
Dave Farber
Gary Delp
Tom Conte
Farber & Delp & Conte [Page 6]
RFC 914 September 1984
Thinwire
Appendix A -- Example of Thinwire I
Here is an example of how Thinwire I would operate in a
situation. The connection is a TCP/IP Telnet connection. The
TCP/IP Telnet packet is on the next page; it simulates the typing
the character "a". The second packet would be produced by
"d"; it is shown on the following page. The compressed version is
the third page following
[NOTE: The checksums pictured have not been calculated. Binary
MSB to LSB format
Farber & Delp & Conte [Page 7]
RFC 914 September 1984
Thinwire
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 | 41 |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Time to live | Protocol | Header Checksum |
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|
| 101 | 6 | nnn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
|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|
| 192. | 5. | 39. | 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
|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|
| 10. | 2. | 0. | 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
TCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header:| Source Port | Destination Port |
|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|
| 1025 | 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
|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|
| 300 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Number |
|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|
| 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|offset | Reserved |U A P R S F| Window |
|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|
| 5 | 0 | 16 | 512 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
| "a" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Farber & Delp & Conte [Page 8]
RFC 914 September 1984
Thinwire
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|
| 4 | 5 | 0 | 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P | Identification* |Flags| Fragment Offset |
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|
c | 2 | 0 | 0 |
k +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
e | Time to live*| Protocol | Header Checksum* |
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|
- | 102 | 6 | nnn |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
|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|
| 192. | 5. | 39. | 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
|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|
| 10. | 2. | 0. | 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
TCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header:| Source Port | Destination Port |
|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|
| 1025 | 27 |
* 's +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
show | Sequence Number* |
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|
fields | 301 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Number* |
|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|
| 101 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|offset | Reserved |U A P R S F| Window |
|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|
| 5 | 0 | 16 | 512 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 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|
| "d" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Farber & Delp & Conte [Page 9]
RFC 914 September 1984
Thinwire
The Thinwire Driver finds the template (which is the previous
sent), compares the template to the packet and creates a
message (field names of change record data have been added
comparison):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Descriptor byte| Data: |Descriptor byte| Data: |
|offset |length | Identification|offset |length | Time to live |
|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|
| 2 | 1 | 2 | 2 | 1 | 102 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Descriptor byte| Data: |Descriptor byte
| offset| length| Header Checksum |offset |length |
|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|
| 2 | 2 | nn | 15 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data: |Descriptor byte| Data: |Descriptor byte
| Seq Number |offset |length | Ack Number |offset |length |
|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|
| 301 | 3 | 1 | 101 | 7 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data: |Descriptor byte| Data: |
| -- TCP Checksum -- |offset |length | data |
|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|
| nn | 2 | 1 | "d" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Descriptor byte
|offset |length |
|0 0 0 0|0 0 0 0| the 0 0 offset/length record ends the update
| 0 | 0 |
+-+-+-+-+-+-+-+-+
Thinwire I then sends this message over the line where the
packet is updated to form the new packet. Note: One can see that
series of null descriptor bytes will reset the connection
Farber & Delp & Conte [Page 10]
RFC 914 September 1984
Thinwire
Appendix B -- Examples of Thinwire II
This Appendix provides an example of how the Thinwire II
operate in a common situation. The same original packets are used
in Appendix A, so only the updates are shown
As the later field definitions depend on the contents of
fields, a field by field analysis of the update packets will
useful
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thinwire II |U|L|Template no| Len of change | Type of Packet
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|
header: |N N| 5 | 41 | TCP/IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit is the UPDATE bit. If it is a 0 this
describes a new template, and the entire new packet is included
following the header. If there was a previous template with
same number, it will be cleared and replaced by the new template
If the UPDATE bit is a 1, then this packet should be used
update the template with the number given in the template
field
The second bit is the LONG bit. If it is a 1 it indicates a
packet. This means that the update length field will be 16
instead of 8 bits
The remaining 6 bits in the first byte indicate the
number that this packet is an update to
The template number is followed by 1 or 2 bytes (depending on
value of the LONG bit) which give the length of the packet.
is the number of data bytes following the variable length header
If the UPDATE bit is 0 on this packet, the next byte will be
flag telling what type of packet the sender thinks this packet is
The flag will be saved by the receiver to interpret the
packets. Type 0 is for unknown types. If the type 0 flag is set
there will be no updates to this template number. Type 1
TCP/IP; the method of updating will be described below. Type 2
UDP/IP; the method of update is not described at this time
At this time we have enough information to encode packet 1 of
example. Assuming for the moment that this is the first packet
this connection, the UPDATE bit would be set to 0. As the packet
a length of 41 and so can be described in 8 bits, the LONG bit
be set to 0. A template number not in use (or the oldest in
Farber & Delp & Conte [Page 11]
RFC 914 September 1984
Thinwire
template number) would be assigned to this packet. The number 5
illustrated. The Length of Packet would be given as 41, and the
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
always be the same; these are described in the body of the paper,
are used to match the template. These do not need to be
for an update. There are portions of the packet which will
(well almost always) change. These are the IP Header checksum,
IP Identification number, and the TCP checksum. These
transmitted, in that order, with each template update
after the packet length byte/bytes. Following the invariant
of the header are updates to the fields which change some of
time. Which fields are different is indicated with a
describing the changes
The Bitfield is used to indicate which fields (of those that may
the same) have changed. The technique for updating the field
with the field description. The specifications for TCP/IP are
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
The changed field update information is added to the update header
the order that the bits appear in the field. That is, if both the
packet length bit and the Time to Live bit are set, the 2 new
of the IP Packet length will precede the 1 new byte of the Time
Live field
The update for packet 2 is shown below. Note that this is an
to template 5, the length of update is 8 bits with a value of 1.
new checksums and IP Identification Number are included, and
flags are set to indicate changes to the following fields: Time
Live, Add 8 bits to Sequence and Acknowledgement Numbers. The
data is one byte following the header
Thinwire II would send this message over the line where it would
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
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
____________________________________________________________________
Farber & Delp & Conte [Page 13]
RFC 914 September 1984
Thinwire
Appendix C -- Tentative Specification for Thinwire
Thinwire III, as stated in the body of this paper, provides
virtual connections over a single physical connection. As
III is based on a single point to point connection, much of
per/datagram information (routing and sequencing) of other
systems can be eliminated. In the steady state any bytes received
thinwire III are sent to the default higher level
connection. There are escaped control sequences which allow
creation of additional connections, the switching of the
connection, the packetizing of datagrams, and the passing
information between the gateway and the personal computer.
gateway and the personal computer manage a single full duplex stream
multiplexing control requests and streams of data through the use
embedded logical switches
The ascii character "z" (binary 01011011 ) is used as the
character. The byte following the "z" is interpreted to
the command. Table C-1 shows the general classes the bytes (
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
letter "z" to be transmitted to the default connection. The letter
was chosen as the escape for its low occurrence in text and
data streams, because it should pass easily through any lower
protocols, and for its generally innocuous behavior
Descriptions of specifications of each of the Request codes
below
Starting with the range 0-31; these Request codes change the
connection. After a connection has been established, any
which come across the line that are not part of a Request
sequence are transmitted to one of the connections. To begin
this connection defaults to Zero, but when the "Switch
Connection" command is received, characters are sent to
connection named in the request until a new request is received
Zero is a special diagnostic connection; anything received
connection number Zero should be echoed back to the sender
connection number One. Anything received on connection number
should be placed on the diagnostic output of the receiving host.
other connection number indicates data which should be sent out
numbered connection. If the numbered connection has not been opened
the data can be thrown away, and an Error Control Message returned
the sender
Escapes followed by numbers 32 through 255 are for new connections
requests for information, and error messages. The escape will
Farber & Delp & Conte [Page 14]
RFC 914 September 1984
Thinwire
followed by a Request code, a one byte Request Sequence Number (
that the Reply to Request can be asynchronously associated with
Request), and the arguments for the specific request. (The length
the argument field will be determined by the Request code.)
format of the request will be as pictured below
"z" Sequence Number> [ ... ]
At this time the Request codes 32-63 are reserved
The Request codes 64-127 are for stream server open requests.
the purposes of compression, many of the common servers are
single byte codes. See Table C-2.
Request code 68 is to a connection to the default hostname
used by the gateway. It takes 3 bytes for this request. It has
form
"z" < 68 > < Request Sequence Number >
Request code 95 is to open any specified TCP Port at the
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
new Datagram connections. The code 128 is the Start of
code. The format is
"z" <128> Datagram (2 bytes)> Data ...
As with the Stream opens, there are a number of assigned ports
codes for them. They are listed in Table C-3.
The Request Codes 192-254 are control, status and
requests. These are still under development, but will include
-flow
-get host/server/protocol by entry/name/number
-additional error
-overall
-open passive
The Request Code 252 is the request to close a connection.
Code, followed by the connection number, indicates that no more
Farber & Delp & Conte [Page 15]
RFC 914 September 1984
Thinwire
will be sent out this connection number. A second request with
same connection number will indicate that no more data will
accepted on this connection
The Request Code 253 is the information request for a connection.
protocol, status, and port number of the connection should
returned. The format of this reply has yet to be specified
The Request code 254 is an error notification. These are to
acknowledged with their Request Sequence Numbers. Error codes
under development
The Request code 255 is the Reply to Request. The Request
Number identifies the request being replied to. The format is
"z" <255> Sequence Number (in reply to)>
(1 byte)> Reply...
The Thinwire Drivers on each side will wait at their inbound sockets
and relay across the thinwire
character-by-character/packet-by-packet for the stream/
connections
Thinwire III is labeled as a tentative specification, because at
time, in order to publish this RFC in a timely fashion, several
issues are still unresolved. An example is the scheduling of
line use. Short messages could be given priority over long packets
or priority schemes could be changed during the session,
upon the interactive desire of the user. Addition issues will
resolved in the future
Farber & Delp & Conte [Page 16]
RFC 914 September 1984
Thinwire
Appendix D -- Serial Line Interface Protocol (SLIP
Initial Specifications and Implementation
The world is a dangerous place for bits. Data transmission can
an time consuming business when one has to make sure that
don't get lost, destroyed, or forgotten. To reduce such problems
the Serial Line Interface Protocol (SLIP) maintains an
toward the world that includes both a mistrust of serial lines
a margin of laziness. Examples of this approach include how
recovers from errors and how SLIP handles the problem
resequencing (see PROTOCOL SPECIFICATIONS and
SUGGESTIONS).
THE MESSAGE
Both the Sender Task and the Receiver Task communicate using
standard message format and the Sender and Receiver Task of
machine's SLIP communicate using a shared buffer. The
begins with a 1 byte Start of Header token (StH, 11111111) and
followed by a sequence number of four bits (SEQ) and
acknowledgement number of four bits (ACK). Following the StH,
and ACK, is a 5 bit length field which specifies the length of
data contained in the message. Following the length is a three
field of flags. The first bit is used to indicate that the
receive error has occurred, and the ACK is actually a repeat
the Last Acknowledged message (a LACK). The second bit is used
indicate a Synchronize Sequence Numbers message (SSNM), and
third bit is used to indicate a Start of Control Message (SOCM);
all three of these flags are explained below. Finally, at the
of the message is an exclusive-or checksum. The message format
shown in figure D-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| StH | SEQ | ACK | Length |Flags|...Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
The maximum data length is 32 bytes. 0 1 2 3 4 5 6 7
This limits the vulnerability of receiver ...-+-+-+-+-+-+-+-+-+-+
timeout errors occurring because of bit error .Data...| Checksum |
in the length field. ...-+-+-+-+-+-+-+-+-+-+
Figure D-1. SLIP Message
________________________________________________
Farber & Delp & Conte [Page 17]
RFC 914 September 1984
Thinwire
The Sender, when idle but needing to acknowledge, will send
short messages of the same format as a regular message but
the SOCM flag set and the data field omitted. ( This
message is called a SOCM, and is used instead of a zero
message to avoid the problem of continually ACK'ing ACK's ).
Sender Task, when originating a connection (see STARTING UP
FINISHING OFF COMMUNICATIONS), will send out another short
but with the SSNM flag set and the data omitted. This message (
SSNM) used for a TCP-style 3 way startup handshake
PROTOCOL SPECIFICATIONS and
The SLIP module, when called with data to send, prepends
header (SEE ABOVE) to the data, calculates a checksum and
the checksum at the end. (This creates a message.) The
has a sequence number associated with it which represents
position of the message in the Sender SLIP's buffers.
sequence number for the message can range from 0 to 15 and
returned in the ACK field of the other machine's Sender
messages to acknowledge receipt
There are two scenarios for transmission. In the first,
SLIP's will be transmitting to each other. To send
acknowledgement, the Receiver SLIP uses the ACK field in its
outgoing message. To receive an acknowledgement, the Sender
the ACK field of its Receiver's incoming messages. In the
scenario, one SLIP may have no data to transmit for a long time
Then, as stated above, to acknowledge a received message,
Receiver has its Sender send out a short message, the SOCM (
ABOVE) which specifies the message it is acknowledging. The
includes a checksum of its total contents. If there is a
error, THE SOCM IS IGNORED
When there is a checksum error on a received normal message,
Receiver asks its Sender to send out a SOCM with the LACK
set, or set the LACK flag on its next message. The Sender
this flag ONCE then ceases to increment the acknowledgement
(the ACK) while the Receiver continues to check incoming
for the sequence number of the message with a checksum error
(Note that it continues to react to the acknowledgement field
the incoming messages.) When it finds the needed message,
resumes accepting the data in new messages and increments
acknowledgement number transmitted accordingly
The sending SLIP must never send a message greater than four
the last message for which it has received an
(effectively a window size of four). Under normal
loads, a window size greater than four should not be needed,
this decreases the probability of random errors creating
Farber & Delp & Conte [Page 18]
RFC 914 September 1984
Thinwire
acknowledgement or sequence numbers. If the Sender has
unacknowledged messages outstanding, it will retransmit the
messages, starting from the oldest unacknowledged message. If
receives an acknowledgement with the LACK flag set, it
the message following the LACK number and continues to
the messages from that one on. Thus a LACK is a message
the Sender to please the Receiver. If the Sender times out on
message not logically greater than four past the last
message, it should retransmit the message that timed out and
continues to transmit messages following the timed out message
The following describes a partial implementation of SLIP.
dependent subjects like buffer management, timer handling
calling conventions are discussed
The SLIP implementation is subdivided into four modules and
sets of input/output interfaces. The four modules are: The
Task, The Receiver Task, the buffer Manager, and SLIPTIME (
timer). The two interfaces are to the higher protocol and to
lower protocol (the UARTian, an interrupt driven device driver
the serial lines).
OPERATIONS OF THE SENDER
The Sender Task takes a relatively noncomplex approach
transmitting. It sends message zero, sets a timer (using
SLIPTIME Task) on the message, and proceeds to send and set
for messages one, two, and three. When the Receiver Task
the Sender Task that a message has been acknowledged, the
Task then clears the timer for that message, and marks
acknowledged. When the Sender Task has finished sending
message, it checks several conditions to decide what to do next
It first checks to see if a LACK has been received. If it has
it clears all the timers, and begins retransmitting
(updating the acknowledgement field and checksum) starting
the one after the LACK'ed message. If there is not a LACK
for the Sender Task, it checks to see if any messages have
out. If a message has timed out, the Sender Task again will
the timers and begin retransmitting from the message number
timed out. If neither of these conditions are true, the
Task checks to see if, because it has looped back to retransmit
it has any previously formulated messages to send. If so, it
the first of these messages. If it does not have
formulated messages, it checks to see if it is more than
past the last acknowledged message. If so, it restarts from
message after the last acknowledged message. If none of these
true, then it checks to see if there is more data waiting to
transmitted. If there is more data available, it forms
largest packet it can, and begins to transmit it. If there is
Farber & Delp & Conte [Page 19]
RFC 914 September 1984
Thinwire
more data to transmit, it checks to see if it needs to
a message received from the other side. If so then it sends
SOCM. If none of the above conditions create work for the
Task, the task suspends itself
Note that the Sender Task uses the Receiver Task to find out
acknowledgements and the Receiver Task uses the Sender Task
send acknowledgements to the other SLIP on the other side (via
ACK field in the Sender Task's message). The two tasks on
machine communicate through a small buffer.
acknowledgements need to be passed back to the Sender
quickly, the Receiver Task can wake up the Sender Task (
it).
OPERATIONS OF THE RECEIVER
The Receiver Task checks the checksums of the messages coming
it. When it gets a checksum error, it tells the Sender Task
mark the next acknowledgement as a LACK. It then throws away
messages coming into it that don't match the message it wants
continues to acknowledge with the last ACK until it gets
message it wants. As a checksum error could be the result of
crashed packet, and the StH character can occur within the packet
when a checksum error does occur, the recovery includes
forward from the last StH character for the next StH
then attempting to verify a packet beginning from it. A
message includes a valid checksum, and sequence
acknowledgement numbers within the active window of numbers.
eliminates the need for the resequencing of messages, because
Receiver Task throws away anything that would make information
its buffers out of sequence
OPERATIONS OF
The timer task will maintain and update a table of timers for
request. Its functions should be called with the timer length
the sequence number to associate with the timer. Its
can also be called with a request to delete a timer.
interrupt-driven mechanism is used to update the running
and to wake up the Sender when an alarm goes off
Farber & Delp & Conte [Page 20]
RFC 914 September 1984
Thinwire
THE INPUT AND OUTPUT
To force SLIP to do something, the higher protocol should create
buffer and then call SLIP, passing it a pointer to the buffer
SLIP will then read the buffer and begin sending it. The call
SLIP will return the number of bytes written, negative
indicates to the caller that SLIP could not do the request.
error numbers will be assigned in the future. To ask SLIP
receive something, one would call SLIP and SLIP would
return the number of bytes received or a negative number for
error (nothing ready to receive, for example).
SLIP, when it wants to talk to the underworld of the
interface, will do much the same thing only through a
written to by the UARTian (for received data) and read from by
UARTian (for sent data).
OPERATIONS OF THE BUFFER/WINDOW
The Manager tends a continuous, circular buffer for the
Task in which data to be sent (from the downcalling protocol)
stored. This buffer is called the INPUT-DATA BUFFER (IDBuff).
The Manager also manages a SENDER TASK'S OUTPUT-DATA
(SODBuff), which is its output buffer to the UARTian
The IDBuff has associated with it some parameters.
parameters include: START OF MEMORY (SOM), the start of
reserved for the IDBuff; END OF MEMORY (EOM), the end of
reserved; START OF DATA (SOD), the beginning of the used
of the IDBuff; and END OF DATA (EOD), the end of data in
IDBuff. The SOM and EOM are constants whereas the SOD and EOD
variables
The SODBuff is composed of four buffers for four outbound
(less the checksum). The buffers can be freed up to
overwritten when the message that they contain is acknowledged
the SLIP on the other side of the line. When a message is in
SODBuff, it has associated with it a sequence number (which is
message's sequence number). The Sender Task can reference
data in the SODBuff and reference acknowledgements via
sequence number
When the application has data to be transmitted, it is placed
the IDBuff by the application using functions from the Manager
the EOD is incremented. If the data the application wants to
won't fit in the buffer, no data is written, and the
can either sleep, or continue to attempt to write data until
Farber & Delp & Conte [Page 21]
RFC 914 September 1984
Thinwire
data will fit. The Sender Task calls a Manager function to fill
message slot in the SODBuff. The Sender Task then sends
message from the SODBuff
The Manager also maintains a buffer set for the Receiver Task.
buffers are similar to those of the Sender Task. There is
CHECKSUMMED OUTPUT-DATA BUFFER (CODBuff), which is the
output from SLIP that the higher level protocol may read.
CODBuff is also controlled by the four parameters START OF MEMORY
END OF MEMORY, START OF DATA, and END OF DATA (SOM, EOM, SOD,
EOD).
There is also an inbound circular buffer the analog of
SODBuff, called the RECEIVER TASK'S INPUT-DATA BUFFER (RIDBuff).
When the UARTian gets data, it places the data in the RIDBuff
After this, the Receiver Task checksums the data. If the
is good and the Receiver Task opts to acknowledge the message,
moves the data to the CODBuff, increments EOD, and frees up
in the RIDBuff. The higher level application can then take
off on the CODBuff, incrementing SOD as it does so
STARTING UP AND FINISHING OFF
The problem is that the SLIP's on either side need to know (
keep knowing) the sequence number of the other SLIP. The
way to solve most of these problems is to have the SLIP check
Request to Send and Clear to Send Lines to see if the other
is active. On startup, or if it has reason to believe the
side has died, the SLIP assumes: all connections are closed,
data from any connection has been sent, and both its SEQ and
SEQ of the other SLIP are zero. To start up a connection,
instigating SLIP sends a SSNM with its starting sequence number
it. The receiving SLIP acknowledges this SSNM and replies
its starting sequence number (combined into one message).
the sending SLIP acknowledges the receiving SLIP's
sequence number and the transmission commences. This is the
way handshake taken from TCP, After which data transmission
begin
Farber & Delp & Conte [Page 22]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
