As per Relevance of the word connection, we have this rfc below:
RFC: 761
IEN: 129
DOD
TRANSMISSION CONTROL
January 1980
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
January 1980
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 ....................................... 10
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 .................................... 29
3.5 Closing a Connection ......................................... 35
3.6 Precedence and Security ...................................... 38
3.7 Data Communication ........................................... 38
3.8 Interfaces ................................................... 42
3.9 Event Processing ............................................. 52
GLOSSARY ............................................................ 75
REFERENCES .......................................................... 83
[Page i
January 1980
Transmission Control
[Page ii]
January 1980
Transmission Control
This document describes the DoD Standard Transmission Control
(TCP). There have been eight 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
incorporates the addition of security, compartmentation, and
concepts into the TCP specification
Jon
[Page iii
January 1980
RFC:761
IEN:129
Replaces: IENs 124, 112,
81, 55, 44, 40, 27, 21, 5
DOD
TRANSMISSION CONTROL
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 especially in interconnected systems of
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 primarily focuses its attention 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]
January 1980
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. As a practical matter, many computer systems will
connected to networks via front-end computers which house the TCP
internet protocol layers, as well as network specific software.
TCP specification describes an interface to the higher level
which appears to be implementable even for the front-end case, as
as a suitable 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]
January 1980
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 letters
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]
January 1980
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
stream mode, the TCPs decide when to block and forward data at
own convenience
For users who desire a record-oriented service, the TCP also
the user to submit records, called letters, for transmission.
the sending user indicates a record boundary (end-of-letter),
causes the TCPs to promptly forward and deliver data up to
point to the receiver
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 users. TCP recovers from
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. For stream mode, the
indicates an allowed number of octets that the sender may
before receiving further permission. For record mode, the
indicates an allowed amount of buffer space the sender may consume
this may be more than the number of data octets transmitted if
is a mismatch between letter size and buffer size
[Page 4]
January 1980
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]
January 1980
Transmission Control
[Page 6]
January 1980
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
We specifically assume that data is transmitted from host to
through means of a set of networks. When we say network, we have
mind a packet switched network (PSN). This assumption is
unnecessary, since a circuit switched network or a hybrid
of the two could also be used; but for concreteness, we
assume that the hosts are connected to one or more packet switches
a PSN
The term packet is used generically here to mean the data of
transaction between a host and a packet switch. The format of
blocks exchanged between the packet switches in a network
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
[Page 7]
January 1980
Transmission Control
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,
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 be
into smaller ones at intermediate gateways. The internet
fragment format is designed so that the destination internet
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 a time sharing operating system
The users access the TCP much like they would access the file system
The TCP may call on other operating system functions, for example,
manage data structures. The actual interface to the network
assumed to be controlled by a device driver module. The TCP does
call on the network device driver directly, but rather calls on
internet datagram protocol module which may in turn call on the
driver
[Page 8]
January 1980
Transmission Control
Though it is assumed here that processes are supported by the
operating system, the mechanisms of TCP do not preclude
of the TCP in a front-end processor. However, in such
implementation, a host-to-front-end protocol must provide
functionality to support the type of TCP-user interface
above
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 | Gateway Level
+-------------------------------+
|
+---------------------------+
| Local Network Protocol | Network Level
+---------------------------+
|
Protocol
Figure 2.
[Page 9]
January 1980
Transmission Control
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 [3] 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
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 the sequence number transmitted with that segment and
called the segment sequence number. Segments also carry
acknowledgment number which is the sequence number of the
expected data octet of transmissions in the reverse direction.
the TCP transmits a segment, it puts a copy on a retransmission
and starts a timer; when the acknowledgment for that data is received
the 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 into a TCP, a flow control mechanism
employed. The the data receiving TCP reports a window to the
TCP. This window specifies the number of octets, starting with
acknowledgment number that the data receiving TCP is
prepared to 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 operating system, TCP, or user, they might
be unique. To provide for unique addresses at each TCP,
concatenate an internet address identifying the TCP with a
identifier to create a socket which will be unique throughout
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 seem necessary in any implementation
[Page 10]
January 1980
Transmission Control
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 only initiate connections
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)
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 could 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 might be permanently assigned to a
socket, and other sockets might be reserved for File Transfer,
Job 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
Processes can issue passive OPENs and wait for matching calls
other processes and be informed by the TCP when connections have
established. Two processes which issue calls to each other at
same time are correctly connected. This flexibility is critical
[Page 11]
January 1980
Transmission Control
the support of distributed computing in which components
asynchronously with respect to each other
There are two cases for matching the sockets in the local request
an incoming segment. In the first case, the local request has
specified the foreign socket. In this case, the match must be exact
In the second case, the local request has left the foreign
unspecified. In this case, any foreign socket is acceptable as
as the local sockets match
If there are several pending passive OPENs (recorded in TCBs) with
same local socket, an incoming segment should be matched to a
with the specific foreign socket in the segment, if such a
exists, before selecting a request with an unspecified foreign socket
The procedures to establish and clear connections utilize
(SYN) and finis (FIN) control flags and involve an exchange of
messages. This exchange has been termed a three-way hand shake [4].
A connection is initiated by the rendezvous of an arriving
containing a SYN and a waiting TCB entry 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, or as a sequence of records. In TCP the records are
letters and are of variable length. The sending user indicates
each SEND call whether the data in that call completes a letter by
setting of the end-of-letter parameter
The length of a letter may be such that it must be broken
segments before it can be transmitted to its destination. We
that the segments will normally be reassembled into a letter
being passed to the receiving process. A segment may contain all or
part of a letter, but a segment never contains parts of more than
letter. The end of a letter is marked by the appearance of an
control flag in a segment. A sending TCP is allowed to collect
from the sending user and to send that data in segments at its
convenience, until the end of letter is signaled then it must send
unsent data. When a receiving TCP has a complete letter, it must
wait for more data from the sending TCP before passing the letter
the receiving process
[Page 12]
January 1980
Transmission Control
There is a coupling between letters as sent and the use of buffers
data that cross the TCP/user interface. Each time an end-of-
(EOL) flag is associated with data placed into the receiving user'
buffer, the buffer is returned to the user for processing even if
buffer is not filled. If a letter is longer than the user's buffer
the letter is passed to the user in buffer size units, the last
which may be only partly full. The receiving TCP's buffer size may
communicated to the sending TCP when the connection is
established
The TCP is responsible for regulating the flow of segments on
connections, as a way of preventing itself from becoming saturated
overloaded with traffic. This is done using a window flow
mechanism. The data receiving TCP reports to the data sending TCP
window which is the range of sequence numbers of data octets that
receiving TCP is currently prepared to accept
TCP also provides a means to communicate to the receiver of data
at some point further along in the data stream than the receiver
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
should take action to read through the end 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 should 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 should follow a general principle of robustness
be conservative in what you do, be liberal in what you accept
others
[Page 13]
January 1980
Transmission Control
[Page 14]
January 1980
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|E|R|S|F| |
| Offset| Reserved |R|C|O|S|Y|I| Window |
| | |G|K|L|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]
January 1980
Transmission Control
Functional
Sequence Number: 32
The sequence number of the first data octet in this segment (
when SYN is present).
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 including options is an
number of 32 bits long
Reserved: 6
Reserved for future use. Must be zero
Control Bits: 8 bits (from left to right):
URG: Urgent Pointer field
ACK: Acknowledgment field
EOL: End of
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
prefixed to the TCP header. This pseudo header contains the
[Page 16]
January 1980
Transmission Control
Functional
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 plus the data length in
(this is not an explicitly transmitted quantity, but is
from the total length, and the header length).
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 should only be interpreted in
with 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 should be header padding (i.e., zero).
A TCP must implement all options
[Page 17]
January 1980
Transmission Control
Functional
Currently defined options include (kind indicated in octal):
Kind Length
---- ------ -------
0 - End of option list
1 - No-Operation
100 - Reserved
105 4 Buffer 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
Buffer
+--------+--------+---------+--------+
|01000101|00000100| buffer size |
+--------+--------+---------+--------+
Kind=105 Length=4
[Page 18]
January 1980
Transmission Control
Functional
Buffer Size Option Data: 16
If this option is present, then it communicates the
buffer size at the TCP which sends this segment. This
should only be sent in the initial connection request (i.e.,
in segments with the SYN control bit set). If this option
not used, the default buffer size of one octet is assumed
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.BS - send buffer
SND.UP - send urgent
SND.WL - send sequence number used for last window
SND.LBB - send last buffer
ISS - initial send sequence
Receive Sequence
RCV.NXT - receive
RCV.WND - receive
RCV.BS - receive buffer
RCV.UP - receive urgent
RCV.LBB - receive last buffer
IRS - initial receive sequence
[Page 19]
January 1980
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.
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.
There are also some variables used frequently in the discussion
take their values from the fields of the current segment
[Page 20]
January 1980
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, TIME-WAIT, CLOSE-WAIT, CLOSING
and the fictional state CLOSED. CLOSED is fictional because
represents the state when there is no TCB, and therefore,
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, ready to transmit
receive data segments
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
TIME-WAIT - represents waiting for enough time to pass to be
the remote TCP received the acknowledgment of its
termination request
CLOSE-WAIT - represents waiting for a connection termination
from the local user
CLOSING - represents waiting for a connection termination
acknowledgment from the remote TCP
CLOSED - represents no connection state at all
[Page 21]
January 1980
Transmission Control
Functional
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 and FIN flags; and timeouts
The Glossary contains a more complete list of terms and
definitions
The state diagram in figure 6 only illustrates 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
[Page 22]
January 1980
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 \ / CLOSE +---------+
| rcv ACK of FIN ------- | | -------
| -------------- snd ACK | | snd FIN
V x V V
+---------+ +---------+
|FINWAIT-2| | CLOSING |
+---------+ +---------+
| rcv FIN | rcv ACK of FIN
| ------- Timeout=2MSL | --------------
V snd ACK ------------ V delete TCB
+---------+ delete TCB +---------+
|TIME WAIT|----------------->| CLOSED |
+---------+ +---------+
TCP Connection State
Figure 6.
[Page 23]
January 1980
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 typical kinds of sequence
comparisons which the TCP must 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]
January 1980
Transmission Control
Functional
On send connections the following comparisons are needed
older sequence numbers newer sequence
SND.UNA SEG.ACK SND.NXT
| | |
----|----XXXXXXX------XXXXXXXXXX---------XXXXXX----|----
| | | | | |
| | |
Segment 1 Segment 2 Segment 3
<----- sequence space ----->
Sending Sequence Space
Figure 7.
SND.UNA = oldest unacknowledged sequence
SND.NXT = next sequence number to be
SEG.ACK = acknowledgment (next sequence number expected by
acknowledging TCP
SEG.SEQ = first sequence number of a
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.
All arithmetic is modulo 2**32 and that comparisons are unsigned
"=<" means "less than or equal".
A segment on the retransmission queue is fully acknowledged if the
of its sequence number and length is less than the
value in the incoming segment
SEG.LEN is the number of octets occupied by the data in the segment
It is important to note that SEG.LEN must be non-zero; segments
do not occupy any sequence space (e.g., empty acknowledgment segments
are never placed on the retransmission queue, so would not go
this particular test
[Page 25]
January 1980
Transmission Control
Functional
On receive connections the following comparisons are needed
older sequence numbers newer sequence
RCV.NXT RCV.NXT+RCV.WND
| |
---------XXX|XXX------XXXXXXXXXX---------XXX|XX---------
| | | | |
| | |
Segment 1 Segment 2 Segment 3
<----- sequence space ----->
Receiving Sequence Space
Figure 8.
RCV.NXT = next sequence number expected on incoming
RCV.NXT+RCV.WND = last sequence number expected on
segments, plus
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
0 =< (SEG.SEQ+SEG.LEN-1 - RCV.NXT) < (RCV.NXT+RCV.WND - RCV.NXT
SEG.SEQ+SEG.LEN-1 is the last sequence number occupied by the segment
RCV.NXT is the next sequence number expected on an incoming segment
and RCV.NXT+RCV.WND is the right edge of the receive 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
[Page 26]
January 1980
Transmission Control
Functional
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+SEG.LEN =< RCV.NXT+RCV.
Note that the acceptance test for a segment, since it requires the
of a segment to lie in the window, is somewhat more restrictive
is absolutely necessary. If at least the first sequence number of
segment lies in the receive window, or if some part of the
lies in the receive window, then the segment might be
acceptable. Thus, in figure 8, at least segments 1 and 2
acceptable by the strict rule, and segment 3 may or may not be
depending on the strictness of interpretation of the rule
Note that when the receive window is zero no segments should
acceptable except ACK segments. Thus, it should be possible for a
to maintain a zero receive window while transmitting data
receiving ACKs
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 includes both data and sequence
occupying controls. When a SYN is present then SEG.SEQ is
sequence number of the SYN
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 owing to
[Page 27]
January 1980
Transmission Control
Functional
is -- "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
tens of seconds or minutes, at worst, we can reasonably assume
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 messages carrying a control
called "SYN" (for synchronize) and the initial sequence numbers. As
shorthand, messages 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. A "three way handshake" is necessary because
numbers are not tied to a global clock in the network, and TCPs
have different mechanisms for picking the ISN's. The receiver of
first SYN has no way of knowing whether the segment was an old
one or not, unless it remembers the last sequence number used on
connection (which is not always possible), and so it must ask
sender to verify this SYN
The "three way handshake" and the advantages of a "clock-driven
scheme are discussed in [4].
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
[Page 28]
January 1980
Transmission Control
Functional
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
It should be noted that this strategy does not protect
spoofing or other replay type duplicate message problems
3.4. Establishing a
The "three-way handshake" is the procedure used to establish
connection. This procedure normally is initiated by one TCP
responded to by another TCP. The procedure also works if two
simultaneously initiate the procedure. When simultaneous
occurs, the TCP receives a "SYN" segment which carries
acknowledgment after it has sent a "SYN". Of course, the arrival
an old duplicate "SYN" segment can potentially make it appear, to
recipient, that a simultaneous connection initiation is in progress
Proper use of "reset" segments can disambiguate these cases.
examples of connection initiation follow. Although these examples
not show connection synchronization using data-carrying segments,
is perfectly legitimate, so long as the receiving TCP doesn't
the data to the user until it is clear the data is valid (i.e.,
data must be buffered at the receiver until the connection reaches
ESTABLISHED state). The three-way handshake reduces the
of false connections. It is the implementation of a trade-off
memory and messages to provide information for this checking
The simplest three-way handshake is shown in figure 9 below.
figures should be interpreted in the following way. Each line
numbered for reference purposes. Right arrows (-->)
departure of a TCP segment from TCP A to TCP B, or arrival of
segment at B from A. Left arrows (<--), indicate the reverse
Ellipsis (...) indicates a segment which is still in the
(delayed). An "XXX" indicates a segment which is lost or rejected
Comments appear in parentheses. TCP states represent the state
the departure or arrival of 