As per Relevance of the word specific, we have this rfc below:
RFC: 793
TRANSMISSION CONTROL
DARPA INTERNET
PROTOCOL
September 1981
prepared
Defense Advanced Research Projects
Information Processing Techniques
1400 Wilson
Arlington, Virginia 22209
Information Sciences
University of Southern
4676 Admiralty
Marina del Rey, California 90291
September 1981
Transmission Control
TABLE OF
PREFACE ........................................................
1. INTRODUCTION ..................................................... 1
1.1 Motivation .................................................... 1
1.2 Scope ......................................................... 2
1.3 About This Document ........................................... 2
1.4 Interfaces .................................................... 3
1.5 Operation ..................................................... 3
2. PHILOSOPHY ....................................................... 7
2.1 Elements of the Internetwork System ........................... 7
2.2 Model of Operation ............................................ 7
2.3 The Host Environment .......................................... 8
2.4 Interfaces .................................................... 9
2.5 Relation to Other Protocols ................................... 9
2.6 Reliable Communication ........................................ 9
2.7 Connection Establishment and Clearing ........................ 10
2.8 Data Communication ........................................... 12
2.9 Precedence and Security ...................................... 13
2.10 Robustness Principle ......................................... 13
3. FUNCTIONAL SPECIFICATION ........................................ 15
3.1 Header Format ................................................ 15
3.2 Terminology .................................................. 19
3.3 Sequence Numbers ............................................. 24
3.4 Establishing a connection .................................... 30
3.5 Closing a Connection ......................................... 37
3.6 Precedence and Security ...................................... 40
3.7 Data Communication ........................................... 40
3.8 Interfaces ................................................... 44
3.9 Event Processing ............................................. 52
GLOSSARY ............................................................ 79
REFERENCES .......................................................... 85
[Page i
September 1981
Transmission Control
[Page ii]
September 1981
Transmission Control
This document describes the DoD Standard Transmission Control
(TCP). There have been nine earlier editions of the ARPA
specification on which this standard is based, and the present
draws heavily from them. There have been many contributors to this
both in terms of concepts and in terms of text. This edition
several details and removes the end-of-letter buffer-size adjustments
and redescribes the letter mechanism as a push function
Jon
[Page iii
RFC: 793
Replaces: RFC 761
IENs: 129, 124, 112, 81,
55, 44, 40, 27, 21, 5
TRANSMISSION CONTROL
DARPA INTERNET
PROTOCOL
1.
The Transmission Control Protocol (TCP) is intended for use as a
reliable host-to-host protocol between hosts in packet-switched
communication networks, and in interconnected systems of such networks
This document describes the functions to be performed by
Transmission Control Protocol, the program that implements it, and
interface to programs or users that require its services
1.1.
Computer communication systems are playing an increasingly
role in military, government, and civilian environments.
document focuses its attention primarily on military
communication requirements, especially robustness in the presence
communication unreliability and availability in the presence
congestion, but many of these problems are found in the civilian
government sector as well
As strategic and tactical computer communication networks
developed and deployed, it is essential to provide means
interconnecting them and to provide standard
communication protocols which can support a broad range
applications. In anticipation of the need for such standards,
Deputy Undersecretary of Defense for Research and Engineering
declared the Transmission Control Protocol (TCP) described herein
be a basis for DoD-wide inter-process communication
standardization
TCP is a connection-oriented, end-to-end reliable protocol designed
fit into a layered hierarchy of protocols which support multi-
applications. The TCP provides for reliable inter-
communication between pairs of processes in host computers attached
distinct but interconnected computer communication networks. Very
assumptions are made as to the reliability of the
protocols below the TCP layer. TCP assumes it can obtain a simple
potentially unreliable datagram service from the lower
protocols. In principle, the TCP should be able to operate above
wide spectrum of communication systems ranging from hard-
connections to packet-switched or circuit-switched networks
[Page 1]
September 1981
Transmission Control
TCP is based on concepts first described by Cerf and Kahn in [1].
TCP fits into a layered protocol architecture just above a
Internet Protocol [2] which provides a way for the TCP to send
receive variable-length segments of information enclosed in
datagram "envelopes". The internet datagram provides a means
addressing source and destination TCPs in different networks.
internet protocol also deals with any fragmentation or reassembly
the TCP segments required to achieve transport and delivery
multiple networks and interconnecting gateways. The internet
also carries information on the precedence, security
and compartmentation of the TCP segments, so this information can
communicated end-to-end across multiple networks
Protocol
+---------------------+
| higher-level |
+---------------------+
| TCP |
+---------------------+
| internet protocol |
+---------------------+
|communication network
+---------------------+
Figure 1
Much of this document is written in the context of TCP
which are co-resident with higher level protocols in the
computer. Some computer systems will be connected to networks
front-end computers which house the TCP and internet protocol layers
as well as network specific software. The TCP specification
an interface to the higher level protocols which appears to
implementable even for the front-end case, as long as a
host-to-front end protocol is implemented
1.2.
The TCP is intended to provide a reliable process-to-
communication service in a multinetwork environment. The TCP
intended to be a host-to-host protocol in common use in
networks
1.3. About this
This document represents a specification of the behavior required
any TCP implementation, both in its interactions with higher
protocols and in its interactions with other TCPs. The rest of
[Page 2]
September 1981
Transmission Control
section offers a very brief view of the protocol interfaces
operation. Section 2 summarizes the philosophical basis for the
design. Section 3 offers both a detailed description of the
required of TCP when various events occur (arrival of new segments
user calls, errors, etc.) and the details of the formats of
segments
1.4.
The TCP interfaces on one side to user or application processes and
the other side to a lower level protocol such as Internet Protocol
The interface between an application process and the TCP
illustrated in reasonable detail. This interface consists of a set
calls much like the calls an operating system provides to
application process for manipulating files. For example, there
calls to open and close connections and to send and receive data
established connections. It is also expected that the TCP
asynchronously communicate with application programs.
considerable freedom is permitted to TCP implementors to
interfaces which are appropriate to a particular operating
environment, a minimum functionality is required at the TCP/
interface for any valid implementation
The interface between TCP and lower level protocol is
unspecified except that it is assumed there is a mechanism whereby
two levels can asynchronously pass information to each other
Typically, one expects the lower level protocol to specify
interface. TCP is designed to work in a very general environment
interconnected networks. The lower level protocol which is
throughout this document is the Internet Protocol [2].
1.5.
As noted above, the primary purpose of the TCP is to provide reliable
securable logical circuit or connection service between pairs
processes. To provide this service on top of a less reliable
communication system requires facilities in the following areas
Basic Data
Flow
Precedence and
The basic operation of the TCP in each of these areas is described
the following paragraphs
[Page 3]
September 1981
Transmission Control
Basic Data Transfer
The TCP is able to transfer a continuous stream of octets in
direction between its users by packaging some number of octets
segments for transmission through the internet system. In general
the TCPs decide when to block and forward data at their
convenience
Sometimes users need to be sure that all the data they
submitted to the TCP has been transmitted. For this purpose a
function is defined. To assure that data submitted to a TCP
actually transmitted the sending user indicates that it should
pushed through to the receiving user. A push causes the TCPs
promptly forward and deliver data up to that point to the receiver
The exact push point might not be visible to the receiving user
the push function does not supply a record boundary marker
Reliability
The TCP must recover from data that is damaged, lost, duplicated,
delivered out of order by the internet communication system.
is achieved by assigning a sequence number to each
transmitted, and requiring a positive acknowledgment (ACK) from
receiving TCP. If the ACK is not received within a
interval, the data is retransmitted. At the receiver, the
numbers are used to correctly order segments that may be
out of order and to eliminate duplicates. Damage is handled
adding a checksum to each segment transmitted, checking it at
receiver, and discarding damaged segments
As long as the TCPs continue to function properly and the
system does not become completely partitioned, no
errors will affect the correct delivery of data. TCP recovers
internet communication system errors
Flow Control
TCP provides a means for the receiver to govern the amount of
sent by the sender. This is achieved by returning a "window"
every ACK indicating a range of acceptable sequence numbers
the last segment successfully received. The window indicates
allowed number of octets that the sender may transmit
receiving further permission
[Page 4]
September 1981
Transmission Control
Multiplexing
To allow for many processes within a single Host to use
communication facilities simultaneously, the TCP provides a set
addresses or ports within each host. Concatenated with the
and host addresses from the internet communication layer, this
a socket. A pair of sockets uniquely identifies each connection
That is, a socket may be simultaneously used in
connections
The binding of ports to processes is handled independently by
Host. However, it proves useful to attach frequently used
(e.g., a "logger" or timesharing service) to fixed sockets which
made known to the public. These services can then be
through the known addresses. Establishing and learning the
addresses of other processes may involve more dynamic mechanisms
Connections
The reliability and flow control mechanisms described above
that TCPs initialize and maintain certain status information
each data stream. The combination of this information,
sockets, sequence numbers, and window sizes, is called a connection
Each connection is uniquely specified by a pair of
identifying its two sides
When two processes wish to communicate, their TCP's must
establish a connection (initialize the status information on
side). When their communication is complete, the connection
terminated or closed to free the resources for other uses
Since connections must be established between unreliable hosts
over the unreliable internet communication system, a
mechanism with clock-based sequence numbers is used to
erroneous initialization of connections
Precedence and Security
The users of TCP may indicate the security and precedence of
communication. Provision is made for default values to be used
these features are not needed
[Page 5]
September 1981
Transmission Control
[Page 6]
September 1981
Transmission Control
2.
2.1. Elements of the Internetwork
The internetwork environment consists of hosts connected to
which are in turn interconnected via gateways. It is assumed
that the networks may be either local networks (e.g., the ETHERNET)
large networks (e.g., the ARPANET), but in any case are based
packet switching technology. The active agents that produce
consume messages are processes. Various levels of protocols in
networks, the gateways, and the hosts support an
communication system that provides two-way data flow on
connections between process ports
The term packet is used generically here to mean the data of
transaction between a host and its network. The format of data
exchanged within the a network will generally not be of concern to us
Hosts are computers attached to a network, and from the
network's point of view, are the sources and destinations of packets
Processes are viewed as the active elements in host computers (
accordance with the fairly common definition of a process as a
in execution). Even terminals and files or other I/O devices
viewed as communicating with each other through the use of processes
Thus, all communication is viewed as inter-process communication
Since a process may need to distinguish among several
streams between itself and another process (or processes), we
that each process may have a number of ports through which
communicates with the ports of other processes
2.2. Model of
Processes transmit data by calling on the TCP and passing buffers
data as arguments. The TCP packages the data from these buffers
segments and calls on the internet module to transmit each segment
the destination TCP. The receiving TCP places the data from a
into the receiving user's buffer and notifies the receiving user.
TCPs include control information in the segments which they use
ensure reliable ordered data transmission
The model of internet communication is that there is an
protocol module associated with each TCP which provides an
to the local network. This internet module packages TCP
inside internet datagrams and routes these datagrams to a
internet module or intermediate gateway. To transmit the
through the local network, it is embedded in a local network packet
The packet switches may perform further packaging, fragmentation,
[Page 7]
September 1981
Transmission Control
other operations to achieve the delivery of the local packet to
destination internet module
At a gateway between networks, the internet datagram is "unwrapped
from its local packet and examined to determine through which
the internet datagram should travel next. The internet datagram
then "wrapped" in a local packet suitable to the next network
routed to the next gateway, or to the final destination
A gateway is permitted to break up an internet datagram into
internet datagram fragments if this is necessary for
through the next network. To do this, the gateway produces a set
internet datagrams; each carrying a fragment. Fragments may
further broken into smaller fragments at subsequent gateways.
internet datagram fragment format is designed so that the
internet module can reassemble fragments into internet datagrams
A destination internet module unwraps the segment from the
(after reassembling the datagram, if necessary) and passes it to
destination TCP
This simple model of the operation glosses over many details.
important feature is the type of service. This provides
to the gateway (or internet module) to guide it in selecting
service parameters to be used in traversing the next network
Included in the type of service information is the precedence of
datagram. Datagrams may also carry security information to
host and gateways that operate in multilevel secure environments
properly segregate datagrams for security considerations
2.3. The Host
The TCP is assumed to be a module in an operating system. The
access the TCP much like they would access the file system. The
may call on other operating system functions, for example, to
data structures. The actual interface to the network is assumed to
controlled by a device driver module. The TCP does not call on
network device driver directly, but rather calls on the
datagram protocol module which may in turn call on the device driver
The mechanisms of TCP do not preclude implementation of the TCP in
front-end processor. However, in such an implementation,
host-to-front-end protocol must provide the functionality to
the type of TCP-user interface described in this document
[Page 8]
September 1981
Transmission Control
2.4.
The TCP/user interface provides for calls made by the user on the
to OPEN or CLOSE a connection, to SEND or RECEIVE data, or to
STATUS about a connection. These calls are like other calls from
programs on the operating system, for example, the calls to open,
from, and close a file
The TCP/internet interface provides calls to send and
datagrams addressed to TCP modules in hosts anywhere in the
system. These calls have parameters for passing the address, type
service, precedence, security, and other control information
2.5. Relation to Other
The following diagram illustrates the place of the TCP in the
hierarchy
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | |Voice| ... | | Application Level
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | | Host Level
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Gateway Level
+-------------------------------+
|
+---------------------------+
| Local Network Protocol | Network Level
+---------------------------+
Protocol
Figure 2.
It is expected that the TCP will be able to support higher
protocols efficiently. It should be easy to interface higher
protocols like the ARPANET Telnet or AUTODIN II THP to the TCP
2.6. Reliable
A stream of data sent on a TCP connection is delivered reliably and
order at the destination
[Page 9]
September 1981
Transmission Control
Transmission is made reliable via the use of sequence numbers
acknowledgments. Conceptually, each octet of data is assigned
sequence number. The sequence number of the first octet of data in
segment is transmitted with that segment and is called the
sequence number. Segments also carry an acknowledgment number
is the sequence number of the next expected data octet
transmissions in the reverse direction. When the TCP transmits
segment containing data, it puts a copy on a retransmission queue
starts a timer; when the acknowledgment for that data is received,
segment is deleted from the queue. If the acknowledgment is
received before the timer runs out, the segment is retransmitted
An acknowledgment by TCP does not guarantee that the data has
delivered to the end user, but only that the receiving TCP has
the responsibility to do so
To govern the flow of data between TCPs, a flow control mechanism
employed. The receiving TCP reports a "window" to the sending TCP
This window specifies the number of octets, starting with
acknowledgment number, that the receiving TCP is currently prepared
receive
2.7. Connection Establishment and
To identify the separate data streams that a TCP may handle, the
provides a port identifier. Since port identifiers are
independently by each TCP they might not be unique. To provide
unique addresses within each TCP, we concatenate an internet
identifying the TCP with a port identifier to create a socket
will be unique throughout all networks connected together
A connection is fully specified by the pair of sockets at the ends.
local socket may participate in many connections to different
sockets. A connection can be used to carry data in both directions
that is, it is "full duplex".
TCPs are free to associate ports with processes however they choose
However, several basic concepts are necessary in any implementation
There must be well-known sockets which the TCP associates only
the "appropriate" processes by some means. We envision that
may "own" ports, and that processes can initiate connections only
the ports they own. (Means for implementing ownership is a
issue, but we envision a Request Port user command, or a method
uniquely allocating a group of ports to a given process, e.g.,
associating the high order bits of a port name with a given process.)
A connection is specified in the OPEN call by the local port
foreign socket arguments. In return, the TCP supplies a (short)
[Page 10]
September 1981
Transmission Control
connection name by which the user refers to the connection
subsequent calls. There are several things that must be
about a connection. To store this information we imagine that
is a data structure called a Transmission Control Block (TCB).
implementation strategy would have the local connection name be
pointer to the TCB for this connection. The OPEN call also
whether the connection establishment is to be actively pursued, or
be passively waited for
A passive OPEN request means that the process wants to accept
connection requests rather than attempting to initiate a connection
Often the process requesting a passive OPEN will accept a
request from any caller. In this case a foreign socket of all
is used to denote an unspecified socket. Unspecified foreign
are allowed only on passive OPENs
A service process that wished to provide services for unknown
processes would issue a passive OPEN request with an
foreign socket. Then a connection could be made with any process
requested a connection to this local socket. It would help if
local socket were known to be associated with this service
Well-known sockets are a convenient mechanism for a priori
a socket address with a standard service. For instance,
"Telnet-Server" process is permanently assigned to a
socket, and other sockets are reserved for File Transfer, Remote
Entry, Text Generator, Echoer, and Sink processes (the last
being for test purposes). A socket address might be reserved
access to a "Look-Up" service which would return the specific
at which a newly created service would be provided. The concept of
well-known socket is part of the TCP specification, but the
of sockets to services is outside this specification. (See [4].)
Processes can issue passive OPENs and wait for matching active
from other processes and be informed by the TCP when connections
been established. Two processes which issue active OPENs to
other at the same time will be correctly connected. This
is critical for the support of distributed computing in
components act asynchronously with respect to each other
There are two principal cases for matching the sockets in the
passive OPENs and an foreign active OPENs. In the first case,
local passive OPENs has fully specified the foreign socket. In
case, the match must be exact. In the second case, the local
OPENs has left the foreign socket unspecified. In this case,
foreign socket is acceptable as long as the local sockets match
Other possibilities include partially restricted matches
[Page 11]
September 1981
Transmission Control
If there are several pending passive OPENs (recorded in TCBs) with
same local socket, an foreign active OPEN will be matched to a
with the specific foreign socket in the foreign active OPEN, if such
TCB exists, before selecting a TCB with an unspecified foreign socket
The procedures to establish connections utilize the synchronize (SYN
control flag and involves an exchange of three messages.
exchange has been termed a three-way hand shake [3].
A connection is initiated by the rendezvous of an arriving
containing a SYN and a waiting TCB entry each created by a user
command. The matching of local and foreign sockets determines when
connection has been initiated. The connection becomes "established
when sequence numbers have been synchronized in both directions
The clearing of a connection also involves the exchange of segments
in this case carrying the FIN control flag
2.8. Data
The data that flows on a connection may be thought of as a stream
octets. The sending user indicates in each SEND call whether the
in that call (and any preceeding calls) should be immediately
through to the receiving user by the setting of the PUSH flag
A sending TCP is allowed to collect data from the sending user and
send that data in segments at its own convenience, until the
function is signaled, then it must send all unsent data. When
receiving TCP sees the PUSH flag, it must not wait for more data
the sending TCP before passing the data to the receiving process
There is no necessary relationship between push functions and
boundaries. The data in any particular segment may be the result of
single SEND call, in whole or part, or of multiple SEND calls
The purpose of push function and the PUSH flag is to push data
from the sending user to the receiving user. It does not provide
record service
There is a coupling between the push function and the use of
of data that cross the TCP/user interface. Each time a PUSH flag
associated with data placed into the receiving user's buffer,
buffer is returned to the user for processing even if the buffer
not filled. If data arrives that fills the user's buffer before
PUSH is seen, the data is passed to the user in buffer size units
TCP also provides a means to communicate to the receiver of data
at some point further along in the data stream than the receiver
[Page 12]
September 1981
Transmission Control
currently reading there is urgent data. TCP does not attempt
define what the user specifically does upon being notified of
urgent data, but the general notion is that the receiving process
take action to process the urgent data quickly
2.9. Precedence and
The TCP makes use of the internet protocol type of service field
security option to provide precedence and security on a per
basis to TCP users. Not all TCP modules will necessarily function
a multilevel secure environment; some may be limited to
use only, and others may operate at only one security level
compartment. Consequently, some TCP implementations and services
users may be limited to a subset of the multilevel secure case
TCP modules which operate in a multilevel secure environment
properly mark outgoing segments with the security, compartment,
precedence. Such TCP modules must also provide to their users
higher level protocols such as Telnet or THP an interface to
them to specify the desired security level, compartment,
precedence of connections
2.10. Robustness
TCP implementations will follow a general principle of robustness:
conservative in what you do, be liberal in what you accept
others
[Page 13]
September 1981
Transmission Control
[Page 14]
September 1981
Transmission Control
3. FUNCTIONAL
3.1. Header
TCP segments are sent as internet datagrams. The Internet
header carries several information fields, including the source
destination host addresses [2]. A TCP header follows the
header, supplying information specific to the TCP protocol.
division allows for the existence of host level protocols other
TCP
TCP Header
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header
Note that one tick mark represents one bit position
Figure 3.
Source Port: 16
The source port number
Destination Port: 16
The destination port number
[Page 15]
September 1981
Transmission Control
Functional
Sequence Number: 32
The sequence number of the first data octet in this segment (
when SYN is present). If SYN is present the sequence number is
initial sequence number (ISN) and the first data octet is ISN+1.
Acknowledgment Number: 32
If the ACK control bit is set this field contains the value of
next sequence number the sender of the segment is expecting
receive. Once a connection is established this is always sent
Data Offset: 4
The number of 32 bit words in the TCP Header. This indicates
the data begins. The TCP header (even one including options) is
integral number of 32 bits long
Reserved: 6
Reserved for future use. Must be zero
Control Bits: 6 bits (from left to right):
URG: Urgent Pointer field
ACK: Acknowledgment field
PSH: Push
RST: Reset the
SYN: Synchronize sequence
FIN: No more data from
Window: 16
The number of data octets beginning with the one indicated in
acknowledgment field which the sender of this segment is willing
accept
Checksum: 16
The checksum field is the 16 bit one's complement of the one'
complement sum of all 16 bit words in the header and text. If
segment contains an odd number of header and text octets to
checksummed, the last octet is padded on the right with zeros
form a 16 bit word for checksum purposes. The pad is
transmitted as part of the segment. While computing the checksum
the checksum field itself is replaced with zeros
The checksum also covers a 96 bit pseudo header
[Page 16]
September 1981
Transmission Control
Functional
prefixed to the TCP header. This pseudo header contains the
Address, the Destination Address, the Protocol, and TCP length
This gives the TCP protection against misrouted segments.
information is carried in the Internet Protocol and is
across the TCP/Network interface in the arguments or results
calls by the TCP on the IP
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
The TCP Length is the TCP header length plus the data length
octets (this is not an explicitly transmitted quantity, but
computed), and it does not count the 12 octets of the
header
Urgent Pointer: 16
This field communicates the current value of the urgent pointer as
positive offset from the sequence number in this segment.
urgent pointer points to the sequence number of the octet
the urgent data. This field is only be interpreted in segments
the URG control bit set
Options:
Options may occupy space at the end of the TCP header and are
multiple of 8 bits in length. All options are included in
checksum. An option may begin on any octet boundary. There are
cases for the format of an option
Case 1: A single octet of option-kind
Case 2: An octet of option-kind, an octet of option-length,
the actual option-data octets
The option-length counts the two octets of option-kind
option-length as well as the option-data octets
Note that the list of options may be shorter than the data
field might imply. The content of the header beyond
End-of-Option option must be header padding (i.e., zero).
A TCP must implement all options
[Page 17]
September 1981
Transmission Control
Functional
Currently defined options include (kind indicated in octal):
Kind Length
---- ------ -------
0 - End of option list
1 - No-Operation
2 4 Maximum Segment Size
Specific Option
End of Option
+--------+
|00000000|
+--------+
Kind=0
This option code indicates the end of the option list.
might not coincide with the end of the TCP header according
the Data Offset field. This is used at the end of all options
not the end of each option, and need only be used if the end
the options would not otherwise coincide with the end of the
header
No-
+--------+
|00000001|
+--------+
Kind=1
This option code may be used between options, for example,
align the beginning of a subsequent option on a word boundary
There is no guarantee that senders will use this option,
receivers must be prepared to process options even if they
not begin on a word boundary
Maximum Segment
+--------+--------+---------+--------+
|00000010|00000100| max seg size |
+--------+--------+---------+--------+
Kind=2 Length=4
[Page 18]
September 1981
Transmission Control
Functional
Maximum Segment Size Option Data: 16
If this option is present, then it communicates the
receive segment size at the TCP which sends this segment
This field must only be sent in the initial connection
(i.e., in segments with the SYN control bit set). If
option is not used, any segment size is allowed
Padding:
The TCP header padding is used to ensure that the TCP header
and data begins on a 32 bit boundary. The padding is composed
zeros
3.2.
Before we can discuss very much about the operation of the TCP we
to introduce some detailed terminology. The maintenance of a
connection requires the remembering of several variables. We
of these variables being stored in a connection record called
Transmission Control Block or TCB. Among the variables stored in
TCB are the local and remote socket numbers, the security
precedence of the connection, pointers to the user's send and
buffers, pointers to the retransmit queue and to the current segment
In addition several variables relating to the send and
sequence numbers are stored in the TCB
Send Sequence
SND.UNA - send
SND.NXT - send
SND.WND - send
SND.UP - send urgent
SND.WL1 - segment sequence number used for last window
SND.WL2 - segment acknowledgment number used for last
ISS - initial send sequence
Receive Sequence
RCV.NXT - receive
RCV.WND - receive
RCV.UP - receive urgent
IRS - initial receive sequence
[Page 19]
September 1981
Transmission Control
Functional
The following diagrams may help to relate some of these variables
the sequence space
Send Sequence
1 2 3 4
----------|----------|----------|----------
SND.UNA SND.NXT SND.UNA
+SND.WND
1 - old sequence numbers which have been acknowledged
2 - sequence numbers of unacknowledged data
3 - sequence numbers allowed for new data transmission
4 - future sequence numbers which are not yet allowed
Send Sequence
Figure 4.
The send window is the portion of the sequence space labeled 3
figure 4.
Receive Sequence
1 2 3
----------|----------|----------
RCV.NXT RCV.NXT
+RCV.WND
1 - old sequence numbers which have been acknowledged
2 - sequence numbers allowed for new reception
3 - future sequence numbers which are not yet allowed
Receive Sequence
Figure 5.
The receive window is the portion of the sequence space labeled 2
figure 5.
There are also some variables used frequently in the discussion
take their values from the fields of the current segment
[Page 20]
September 1981
Transmission Control
Functional
Current Segment
SEG.SEQ - segment sequence
SEG.ACK - segment acknowledgment
SEG.LEN - segment
SEG.WND - segment
SEG.UP - segment urgent
SEG.PRC - segment precedence
A connection progresses through a series of states during
lifetime. The states are: LISTEN, SYN-SENT, SYN-RECEIVED
ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK
TIME-WAIT, and the fictional state CLOSED. CLOSED is
because it represents the state when there is no TCB, and therefore
no connection. Briefly the meanings of the states are
LISTEN - represents waiting for a connection request from any
TCP and port
SYN-SENT - represents waiting for a matching connection
after having sent a connection request
SYN-RECEIVED - represents waiting for a confirming
request acknowledgment after having both received and sent
connection request
ESTABLISHED - represents an open connection, data received can
delivered to the user. The normal state for the data transfer
of the connection
FIN-WAIT-1 - represents waiting for a connection termination
from the remote TCP, or an acknowledgment of the
termination request previously sent
FIN-WAIT-2 - represents waiting for a connection termination
from the remote TCP
CLOSE-WAIT - represents waiting for a connection termination
from the local user
CLOSING - represents waiting for a connection termination
acknowledgment from the remote TCP
LAST-ACK - represents waiting for an acknowledgment of
connection termination request previously sent to the remote
(which includes an acknowledgment of its connection
request).
[Page 21]
September 1981
Transmission Control
Functional
TIME-WAIT - represents waiting for enough time to pass to be
the remote TCP received the acknowledgment of its
termination request
CLOSED - represents no connection state at all
A TCP connection progresses from one state to another in response
events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE
ABORT, and STATUS; the incoming segments, particularly
containing the SYN, ACK, RST and FIN flags; and timeouts
The state diagram in figure 6 illustrates only state changes,
with the causing events and resulting actions, but addresses
error conditions nor actions which are not connected with
changes. In a later section, more detail is offered with respect
the reaction of the TCP to events
NOTE BENE: this diagram is only a summary and must not be taken
the total specification
[Page 22]
September 1981
Transmission Control
Functional
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- |
V x V snd FIN V
+---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK
+---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+ +---------+
TCP Connection State
Figure 6.
[Page 23]
September 1981
Transmission Control
Functional
3.3. Sequence
A fundamental notion in the design is that every octet of data
over a TCP connection has a sequence number. Since every octet
sequenced, each of them can be acknowledged. The
mechanism employed is cumulative so that an acknowledgment of
number X indicates that all octets up to but not including X have
received. This mechanism allows for straight-forward
detection in the presence of retransmission. Numbering of
within a segment is that the first data octet immediately
the header is the lowest numbered, and the following octets
numbered consecutively
It is essential to remember that the actual sequence number space
finite, though very large. This space ranges from 0 to 2**32 - 1.
Since the space is finite, all arithmetic dealing with
numbers must be performed modulo 2**32. This unsigned
preserves the relationship of sequence numbers as they cycle
2**32 - 1 to 0 again. There are some subtleties to computer
arithmetic, so great care should be taken in programming
comparison of such values. The symbol "=<" means "less than or equal
(modulo 2**32).
The typical kinds of sequence number comparisons which the TCP
perform include
(a) Determining that an acknowledgment refers to some
number sent but not yet acknowledged
(b) Determining that all sequence numbers occupied by a
have been acknowledged (e.g., to remove the segment from
retransmission queue).
(c) Determining that an incoming segment contains sequence
which are expected (i.e., that the segment "overlaps"
receive window).
[Page 24]
September 1981
Transmission Control
Functional
In response to sending data the TCP will receive acknowledgments.
following comparisons are needed to process the acknowledgments
SND.UNA = oldest unacknowledged sequence
SND.NXT = next sequence number to be
SEG.ACK = acknowledgment from the receiving TCP (next
number expected by the receiving TCP
SEG.SEQ = first sequence number of a
SEG.LEN = the number of octets occupied by the data in the
(counting SYN and FIN
SEG.SEQ+SEG.LEN-1 = last sequence number of a
A new acknowledgment (called an "acceptable ack"), is one for
the inequality below holds
SND.UNA < SEG.ACK =< SND.
A segment on the retransmission queue is fully acknowledged if the
of its sequence number and length is less or equal than
acknowledgment value in the incoming segment
When data is received the following comparisons are needed
RCV.NXT = next sequence number expected on an incoming segments,
is the left or lower edge of the receive
RCV.NXT+RCV.WND-1 = last sequence number expected on an
segment, and is the right or upper edge of the receive
SEG.SEQ = first sequence number occupied by the incoming
SEG.SEQ+SEG.LEN-1 = last sequence number occupied by the
A segment is judged to occupy a portion of valid receive
space
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.
RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.
[Page 25]
September 1981
Transmission Control
Functional
The first part of this test checks to see if the beginning of
segment falls in the window, the second part of the test checks to
if the end of the segment falls in the window; if the segment
either part of the test it contains data in the window
Actually, it is a little more complicated than this. Due to
windows and zero length segments, we have four cases for
acceptability of an incoming segment
Segment Receive
Length
------- ------- -------------------------------------------
0 0 SEG.SEQ = RCV.
0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.
>0 0 not
>0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.
or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.
Note that when the receive window is zero no segments should
acceptable except ACK segments. Thus, it is be possible for a TCP
maintain a zero receive window while transmitting data and
ACKs. However, even when the receive window is zero, a TCP
process the RST and URG fields of all incoming segments
We have taken advantage of the numbering scheme to protect
control information as well. This is achieved by implicitly
some control flags in the sequence space so they can be
and acknowledged without confusion (i.e., one and only one copy of
control will be acted upon). Control information is not
carried in the segment data space. Consequently, we must adopt
for implicitly assigning sequence numbers to control. The SYN and
are the only controls requiring this protection, and these
are used only at connection opening and closing. For sequence
purposes, the SYN is considered to occur before the first actual
octet of the segment in which it occurs, while the FIN is
to occur after the last actual data octet in a segment in which
occurs. The segment length (SEG.LEN) includes both data and
space occupying controls. When a SYN is present then SEG.SEQ is
sequence number of the SYN
[Page 26]
September 1981
Transmission Control
Functional
Initial Sequence Number
The protocol places no restriction on a particular connection
used over and over again. A connection is defined by a pair
sockets. New instances of a connection will be referred to
incarnations of the connection. The problem that arises from this
-- "how does the TCP identify duplicate segments from
incarnations of the connection?" This problem becomes apparent if
connection is being opened and closed in quick succession, or if
connection breaks with loss of memory and is then reestablished
To avoid confusion we must prevent segments from one incarnation of
connection from being used while the same sequence numbers may
be present in the network from an earlier incarnation. We want
assure this, even if a TCP crashes and loses all knowledge of
sequence numbers it has been using. When new connections are created
an initial sequence number (ISN) generator is employed which selects
new 32 bit ISN. The generator is bound to a (possibly fictitious) 32
bit clock whose low order bit is incremented roughly every 4
microseconds. Thus, the ISN cycles approximately every 4.55 hours
Since we assume that segments will stay in the network no more
the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
hours we can reasonably assume that ISN's will be unique
For each connection there is a send sequence number and a
sequence number. The initial send sequence number (ISS) is chosen
the data sending TCP, and the initial receive sequence number (IRS)
learned during the connection establishing procedure
For a connection to be established or initialized, the two TCPs
synchronize on each other's initial sequence numbers. This is done
an exchange of connection establishing segments carrying a control
called "SYN" (for synchronize) and the initial sequence numbers. As
shorthand, segments carrying the SYN bit are also called "SYNs".
Hence, the solution requires a suitable mechanism for picking
initial sequence number and a slightly involved handshake to
the ISN's
The synchronization requires each side to send it's own
sequence number and to receive a confirmation of it in
from the other side. Each side must also receive the other side'
initial sequence number and send a confirming acknowledgment
1) A --> B SYN my sequence number is
2) A <-- B ACK your sequence number is
3) A <-- B SYN my sequence number is
4) A --> B ACK your sequence number is
[Page 27]
September 1981
Transmission Control
Functional
Because steps 2 and 3 can be combined in a single message this
called the three way (or three message) handshake
A three way handshake is necessary because sequence numbers are
tied to a global clock in the network, and TCPs may have
mechanisms for picking the ISN's. The receiver of the first SYN
no way of knowing whether the segment was an old delayed one or not
unless it remembers the last sequence number used on the
(which is not always possible), and so it must ask the sender
verify this SYN. The three way handshake and the advantages of
clock-driven scheme are discussed in [3].
Knowing When to Keep
To be sure that a TCP does not create a segment that carries
sequence number which may be duplicated by an old segment remaining
the network, the TCP must keep quiet for a maximum segment
(MSL) before assigning any sequence numbers upon starting up
recovering from a crash in which memory of sequence numbers in use
lost. For this specification the MSL is taken to be 2 minutes.
is an engineering choice, and may be changed if experience
it is desirable to do so. Note that if a TCP is reinitialized in
sense, yet retains its memory of sequence numbers in use, then it
not wait at all; it must only be sure to use sequence numbers
than those recently used
The TCP Quiet Time
This specification provides that hosts which "crash"
retaining any knowledge of the last sequence numbers transmitted
each active (i.e., not closed) connection shall delay emitting
TCP segments for at least the agreed Maximum Segment Lifetime (MSL
in the internet system of which the host is a part. In
paragraphs below, an explanation for this specification is given
TCP implementors may violate the "quiet time" restriction, but
at the risk of causing some old data to be accepted as new or
data rejected as old duplicated by some receivers in the
system
TCPs consume sequence number space each time a segment is formed
entered into the network output queue at a source host.
duplicate detection and sequencing algorithm in the TCP
relies on the unique binding of segment data to sequence space
the extent that sequence numbers will not cycle through all 2**32
values before the segment data bound to those sequence numbers
been delivered and acknowledged by the receiver and all
copies of the segments have "drained" from the internet.
such an assumption, two distinct TCP segments could conceivably
[Page 28]
September 1981
Transmission Control
Functional
assigned the same or overlapping sequence numbers, causing
at the receiver as to which data is new and which is old.
that each segment is bound to as many consecutive sequence
as there are octets of data in the segment
Under normal conditions, TCPs keep track of the next sequence
to emit and the oldest awaiting acknowledgment so as to
mistakenly using a sequence number over before its first use
been acknowledged. This alone does not guarantee that old
data is drained from the net, so the sequence space has been
very large to reduce the probability that a wandering duplicate
cause trouble upon arrival. At 2 megabits/sec. it takes 4.5
to use up 2**32 octets of sequence space. Since the maximum
lifetime in the net is not likely to exceed a few tens of seconds
this is deemed ample protection for foreseeable nets, even if
rates escalate to l0's of megabits/sec. At 100 megabits/sec,
cycle time is 5.4 minutes which may be a little short, but
within reason
The basic duplicate detection and sequencing algorithm in TCP can
defeated, however, if a source TCP does not have any memory of
sequence numbers it last used on a given connection. For example,
the TCP w