this particular test.
[Page 25]
January 1980
Transmission Control Protocol
Functional Specification
On receive connections the following comparisons are needed:
older sequence numbers newer sequence numbers
RCV.NXT RCV.NXT+RCV.WND
| |
---------XXX|XXX------XXXXXXXXXX---------XXX|XX---------
| | | | |
| | |
Segment 1 Segment 2 Segment 3
<----- sequence space ----->
Receiving Sequence Space Information
Figure 8.
RCV.NXT = next sequence number expected on incoming segments
RCV.NXT+RCV.WND = last sequence number expected on incoming
segments, plus one
SEG.SEQ = first sequence number occupied by the incoming segment
SEG.SEQ+SEG.LEN-1 = last sequence number occupied by the incoming
segment
A segment is judged to occupy a portion of valid receive sequence
space if
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 zero
windows and zero length segments, we have four cases for the
acceptability of an incoming segment:
[Page 26]
January 1980
Transmission Control Protocol
Functional Specification
Segment Receive Test
Length Window
------- ------- -------------------------------------------
0 0 SEG.SEQ = RCV.NXT
0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
>0 0 not acceptable
>0 >0 RCV.NXT < SEG.SEQ+SEG.LEN =< RCV.NXT+RCV.WND
Note that the acceptance test for a segment, since it requires the end
of a segment to lie in the window, is somewhat more restrictive than
is absolutely necessary. If at least the first sequence number of the
segment lies in the receive window, or if some part of the segment
lies in the receive window, then the segment might be judged
acceptable. Thus, in figure 8, at least segments 1 and 2 are
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 be
acceptable except ACK segments. Thus, it should be possible for a TCP
to maintain a zero receive window while transmitting data and
receiving ACKs.
We have taken advantage of the numbering scheme to protect certain
control information as well. This is achieved by implicitly including
some control flags in the sequence space so they can be retransmitted
and acknowledged without confusion (i.e., one and only one copy of the
control will be acted upon). Control information is not physically
carried in the segment data space. Consequently, we must adopt rules
for implicitly assigning sequence numbers to control. The SYN and FIN
are the only controls requiring this protection, and these controls
are used only at connection opening and closing. For sequence number
purposes, the SYN is considered to occur before the first actual data
octet of the segment in which it occurs, while the FIN is considered
to occur after the last actual data octet in a segment in which it
occurs. The segment length includes both data and sequence space
occupying controls. When a SYN is present then SEG.SEQ is the
sequence number of the SYN.
Initial Sequence Number Selection
The protocol places no restriction on a particular connection being
used over and over again. A connection is defined by a pair of
sockets. New instances of a connection will be referred to as
incarnations of the connection. The problem that arises owing to this
[Page 27]
January 1980
Transmission Control Protocol
Functional Specification
is -- "how does the TCP identify duplicate segments from previous
incarnations of the connection?" This problem becomes apparent if the
connection is being opened and closed in quick succession, or if the
connection breaks with loss of memory and is then reestablished.
To avoid confusion we must prevent segments from one incarnation of a
connection from being used while the same sequence numbers may still
be present in the network from an earlier incarnation. We want to
assure this, even if a TCP crashes and loses all knowledge of the
sequence numbers it has been using. When new connections are created,
an initial sequence number (ISN) generator is employed which selects a
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 than
tens of seconds or minutes, at worst, we can reasonably assume that
ISN's will be unique.
For each connection there is a send sequence number and a receive
sequence number. The initial send sequence number (ISS) is chosen by
the data sending TCP, and the initial receive sequence number (IRS) is
learned during the connection establishing procedure.
For a connection to be established or initialized, the two TCPs must
synchronize on each other's initial sequence numbers. This is done in
an exchange of connection establishing messages carrying a control bit
called "SYN" (for synchronize) and the initial sequence numbers. As a
shorthand, messages carrying the SYN bit are also called "SYNs".
Hence, the solution requires a suitable mechanism for picking an
initial sequence number and a slightly involved handshake to exchange
the ISN's. A "three way handshake" is necessary because sequence
numbers are not tied to a global clock in the network, and TCPs may
have different mechanisms for picking the ISN's. The receiver of the
first SYN has no way of knowing whether the segment was an old delayed
one or not, unless it remembers the last sequence number used on the
connection (which is not always possible), and so it must ask the
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 Quiet
To be sure that a TCP does not create a segment that carries a
sequence number which may be duplicated by an old segment remaining in
the network, the TCP must keep quiet for a maximum segment lifetime
(MSL) before assigning any sequence numbers upon starting up or
recovering from a crash in which memory of sequence numbers in use was
[Page 28]
January 1980
Transmission Control Protocol
Functional Specification
lost. For this specification the MSL is taken to be 2 minutes. This
is an engineering choice, and may be changed if experience indicates
it is desirable to do so. Note that if a TCP is reinitialized in some
sense, yet retains its memory of sequence numbers in use, then it need
not wait at all; it must only be sure to use sequence numbers larger
than those recently used.
It should be noted that this strategy does not protect against
spoofing or other replay type duplicate message problems.
3.4. Establishing a connection
The "three-way handshake" is the procedure used to establish a
connection. This procedure normally is initiated by one TCP and
responded to by another TCP. The procedure also works if two TCP
simultaneously initiate the procedure. When simultaneous attempt
occurs, the TCP receives a "SYN" segment which carries no
acknowledgment after it has sent a "SYN". Of course, the arrival of
an old duplicate "SYN" segment can potentially make it appear, to the
recipient, that a simultaneous connection initiation is in progress.
Proper use of "reset" segments can disambiguate these cases. Several
examples of connection initiation follow. Although these examples do
not show connection synchronization using data-carrying segments, this
is perfectly legitimate, so long as the receiving TCP doesn't deliver
the data to the user until it is clear the data is valid (i.e., the
data must be buffered at the receiver until the connection reaches the
ESTABLISHED state). The three-way handshake reduces the possibility
of false connections. It is the implementation of a trade-off between
memory and messages to provide information for this checking.
The simplest three-way handshake is shown in figure 9 below. The
figures should be interpreted in the following way. Each line is
numbered for reference purposes. Right arrows (-->) indicate
departure of a TCP segment from TCP A to TCP B, or arrival of a
segment at B from A. Left arrows (<--), indicate the reverse.
Ellipsis (...) indicates a segment which is still in the network
(delayed). An "XXX" indicates a segment which is lost or rejected.
Comments appear in parentheses. TCP states represent the state AFTER
the departure or arrival of the segment (whose contents are shown in
the center of each line). Segment contents are shown in abbreviated
form, with sequence number, control flags, and ACK field. Other
fields such as window, addresses, lengths, and text have been left out
in the interest of clarity.
[Page 29]
January 1980
Transmission Control Protocol
Functional Specification
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
Basic 3-Way Handshake for Connection Synchronization
Figure 9.
In line 2 of figure 9, TCP A begins by sending a SYN segment
indicating that it will use sequence numbers starting with sequence
number 100. In line 3, TCP B sends a SYN and acknowledges the SYN it
received from TCP A. Note that the acknowledgment field indicates TCP
B is now expecting to hear sequence 101, acknowledging the SYN which
occupied sequence 100.
At line 4, TCP A responds with an empty segment containing an ACK for
TCP B's SYN; and in line 5, TCP A sends some data. Note that the
sequence number of the segment in line 5 is the same as in line 4
because the ACK does not occupy sequence number space (if it did, we
would wind up ACKing ACK's!).
Simultaneous initiation is only slightly more complex, as is shown in
figure 10. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to
ESTABLISHED.
The principle reason for the three-way handshake is to prevent old
duplicate connection initiations from causing confusion. To deal with
this, a special control message, reset, has been devised. If the
receiving TCP is in a non-synchronized state (i.e., SYN-SENT,
SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset.
If the TCP is in one of the synchronized states (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, TIME-WAIT, CLOSE-WAIT, CLOSING), it aborts the
connection and informs its user. We discuss this latter case under
"half-open" connections below.
[Page 30]
January 1980
Transmission Control Protocol
Functional Specification
TCP A TCP B
1. CLOSED CLOSED
2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT
4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
5. SYN-RECEIVED --> <SEQ=101><ACK=301><CTL=ACK> ...
6. ESTABLISHED <-- <SEQ=301><ACK=101><CTL=ACK> <-- SYN-RECEIVED
7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
Simultaneous Connection Synchronization
Figure 10.
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
3. (duplicate) ... <SEQ=1000><CTL=SYN> --> SYN-RECEIVED
4. SYN-SENT <-- <SEQ=300><ACK=1001><CTL=SYN,ACK> <-- SYN-RECEIVED
5. SYN-SENT --> <SEQ=1001><CTL=RST> --> LISTEN
6. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
7. SYN-SENT <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
8. ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> ESTABLISHED
Recovery from Old Duplicate SYN
Figure 11.
As a simple example of recovery from old duplicates, consider
[Page 31]
January 1980
Transmission Control Protocol
Functional Specification
figure 11. At line 3, an old duplicate SYN arrives at TCP B. TCP B
cannot tell that this is an old duplicate, so it responds normally
(line 4). TCP A detects that the ACK field is incorrect and returns a
RST (reset) with its SEQ field selected to make the segment
believable. TCP B, on receiving the RST, returns to the LISTEN state.
When the original SYN (pun intended) finally arrives at line 6, the
synchronization proceeds normally. If the SYN at line 6 had arrived
before the RST, a more complex exchange might have occurred with RST's
sent in both directions.
Half-Open Connections and Other Anomalies
An established connection is said to be "half-open" if one of the
TCPs has closed or aborted the connection at its end without the
knowledge of the other, or if the two ends of the connection have
become desynchronized owing to a crash that resulted in loss of
memory. Such connections will automatically become reset if an
attempt is made to send data in either direction. However, half-open
connections are expected to be unusual, and the recovery procedure is
mildly involved.
If at site A the connection no longer exists, then an attempt by the
user at site B to send any data on it will result in the site B TCP
receiving a reset control message. Such a message should indicate to
the site B TCP that something is wrong, and it is expected to abort
the connection.
Assume that two user processes A and B are communicating with one
another when a crash occurs causing loss of memory to A's TCP.
Depending on the operating system supporting A's TCP, it is likely
that some error recovery mechanism exists. When the TCP is up again,
A is likely to start again from the beginning or from a recovery
point. As a result, A will probably try to OPEN the connection again
or try to SEND on the connection it believes open. In the latter
case, it receives the error message "connection not open" from the
local (A's) TCP. In an attempt to establish the connection, A's TCP
will send a segment containing SYN. This scenario leads to the
example shown in figure 12. After TCP A crashes, the user attempts to
re-open the connection. TCP B, in the meantime, thinks the connection
is open.
[Page 32]
January 1980
Transmission Control Protocol
Functional Specification
TCP A TCP B
1. (CRASH) (send 300,receive 100)
2. CLOSED ESTABLISHED
3. SYN-SENT --> <SEQ=400><CTL=SYN> --> (??)
4. (!!) <-- <SEQ=300><ACK=100><CTL=ACK> <-- ESTABLISHED
5. SYN-SENT --> <SEQ=100><CTL=RST> --> (Abort!!)
6. CLOSED
7. SYN-SENT --> <SEQ=400><CTL=SYN> -->
Half-Open Connection Discovery
Figure 12.
When the SYN arrives at line 3, TCP B, being in a synchronized state,
responds with an acknowledgment indicating what sequence it next
expects to hear (ACK 100). TCP A sees that this segment does not
acknowledge anything it sent and, being unsynchronized, sends a reset
(RST) because it has detected a half-open connection. TCP B aborts at
line 5. TCP A will continue to try to establish the connection; the
problem is now reduced to the basic 3-way handshake of figure 9.
An interesting alternative case occurs when TCP A crashes and TCP B
tries to send data on what it thinks is a synchronized connection.
This is illustrated in figure 13. In this case, the data arriving at
TCP A from TCP B (line 2) is unacceptable because no such connection
exists, so TCP A sends a RST. The RST is acceptable so TCP B
processes it and aborts the connection.
[Page 33]
January 1980
Transmission Control Protocol
Functional Specification
TCP A TCP B
1. (CRASH) (send 300,receive 100)
2. (??) <-- <SEQ=300><ACK=100><DATA=10><CTL=ACK> <-- ESTABLISHED
3. --> <SEQ=100><CTL=RST> --> (ABORT!!)
Active Side Causes Half-Open Connection Discovery
Figure 13.
In figure 14, we find the two TCPs A and B with passive connections
waiting for SYN. An old duplicate arriving at TCP B (line 2) stirs B
into action. A SYN-ACK is returned (line 3) and causes TCP A to
generate a RST (the ACK in line 3 is not acceptable). TCP B accepts
the reset and returns to its passive LISTEN state.
TCP A TCP B
1. LISTEN LISTEN
2. ... <SEQ=Z><CTL=SYN> --> SYN-RECEIVED
3. (??) <-- <SEQ=X><ACK=Z+1><CTL=SYN,ACK> <-- SYN-RECEIVED
4. --> <SEQ=Z+1><CTL=RST> --> (return to LISTEN!)
5. LISTEN LISTEN
Old Duplicate SYN Initiates a Reset on two Passive Sockets
Figure 14.
A variety of other cases are possible, all of which are accounted for
by the following rules for RST generation and processing.
Reset Generation
As a general rule, reset (RST) should be sent whenever a segment
arrives which apparently is not intended for the current or a future
incarnation of the connection. A reset should not be sent if it is
not clear that this is the case. Thus, if any segment arrives for a
nonexistent connection, a reset should be sent. If a segment ACKs
[Page 34]
January 1980
Transmission Control Protocol
Functional Specification
something which has never been sent on the current connection, then
one of the following two cases applies.
1. If the connection is in any non-synchronized state (LISTEN,
SYN-SENT, SYN-RECEIVED) or if the connection does not exist, a reset
(RST) should be formed and sent for any segment that acknowledges
something not yet sent. The RST should take its SEQ field from the
ACK field of the offending segment (if the ACK control bit was set),
and its ACK bit should be reset (zero), except to refuse a initial
SYN. A reset is also sent if an incoming segment has a security level
or compartment which does not exactly match the level and compartment
requested for the connection. If the precedence of the incoming
segment is less than the precedence level requested a reset is sent.
2. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, TIME-WAIT, CLOSE-WAIT, CLOSING), any
unacceptable segment should elicit only an empty acknowledgment
segment containing the current send-sequence number and an
acknowledgment indicating the next sequence number expected to be
received.
Reset Processing
All reset (RST) segments are validated by checking their SEQ-fields.
A reset is valid if its sequence number is in the window. In the case
of a RST received in response to an initial SYN any sequence number is
acceptable if the ACK field acknowledges the SYN.
The receiver of a RST first validates it, then changes state. If the
receiver was in the LISTEN state, it ignores it. If the receiver was
in SYN-RECEIVED state and had previously been in the LISTEN state,
then the receiver returns to the LISTEN state, otherwise the receiver
aborts the connection and goes to the CLOSED state. If the receiver
was in any other state, it aborts the connection and advises the user
and goes to the CLOSED state.
3.5. Closing a Connection
CLOSE is an operation meaning "I have no more data to send." The
notion of closing a full-duplex connection is subject to ambiguous
interpretation, of course, since it may not be obvious how to treat
the receiving side of the connection. We have chosen to treat CLOSE
in a simplex fashion. The user who CLOSEs may continue to RECEIVE
until he is told that the other side has CLOSED also. Thus, a program
could initiate several SENDs followed by a CLOSE, and then continue to
RECEIVE until signaled that a RECEIVE failed because the other side
has CLOSED. We assume that the TCP will signal a user, even if no
RECEIVEs are outstanding, that the other side has closed, so the user
[Page 35]
January 1980
Transmission Control Protocol
Functional Specification
can terminate his side gracefully. A TCP will reliably deliver all
buffers SENT before the connection was CLOSED so a user who expects no
data in return need only wait to hear the connection was CLOSED
successfully to know that all his data was received at the destination
TCP.
There are essentially three cases:
1) The user initiates by telling the TCP to CLOSE the connection
2) The remote TCP initiates by sending a FIN control signal
3) Both users CLOSE simultaneously
Case 1: Local user initiates the close
In this case, a FIN segment can be constructed and placed on the
outgoing segment queue. No further SENDs from the user will be
accepted by the TCP, and it enters the FIN-WAIT-1 state. RECEIVEs
are allowed in this state. All segments preceding and including FIN
will be retransmitted until acknowledged. When the other TCP has
both acknowledged the FIN and sent a FIN of its own, the first TCP
can ACK this FIN. It should be noted that a TCP receiving a FIN
will ACK but not send its own FIN until its user has CLOSED the
connection also.
Case 2: TCP receives a FIN from the network
If an unsolicited FIN arrives from the network, the receiving TCP
can ACK it and tell the user that the connection is closing. The
user should respond with a CLOSE, upon which the TCP can send a FIN
to the other TCP. The TCP then waits until its own FIN is
acknowledged whereupon it deletes the connection. If an ACK is not
forthcoming, after a timeout the connection is aborted and the user
is told.
Case 3: both users close simultaneously
A simultaneous CLOSE by users at both ends of a connection causes
FIN segments to be exchanged. When all segments preceding the FINs
have been processed and acknowledged, each TCP can ACK the FIN it
has received. Both will, upon receiving these ACKs, delete the
connection.
[Page 36]
January 1980
Transmission Control Protocol
Functional Specification
TCP A TCP B
1. ESTABLISHED ESTABLISHED
2. (Close)
FIN-WAIT-1 --> <SEQ=100><CTL=FIN> --> CLOSE-WAIT
3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
4. (Close)
TIME-WAIT <-- <SEQ=301><CTL=FIN> <-- CLOSING
5. TIME-WAIT --> <SEQ=100><ACK=301><CTL=ACK> --> CLOSED
6. (2 MSL)
CLOSED
Normal Close Sequence
Figure 15.
TCP A TCP B
1. ESTABLISHED ESTABLISHED
2. (Close) (Close)
FIN-WAIT-1 --> <SEQ=100><CTL=FIN> ... FIN-WAIT-1
<-- <SEQ=300><CTL=FIN> <--
... <SEQ=100><CTL=FIN> -->
3. CLOSING --> <SEQ=100><ACK=301><CTL=ACK> ... CLOSING
<-- <SEQ=300><ACK=101><CTL=ACK> <--
... <SEQ=100><ACK=301><CTL=ACK> -->
4. CLOSED CLOSED
Simultaneous Close Sequence
Figure 16.
[Page 37]
January 1980
Transmission Control Protocol
Functional Specification
3.6. Precedence and Security
The intent is that connection be allowed only between ports operating
with exactly the same security and compartment values and at the
higher of the precedence level requested by the two parts.
The precedence levels are:
flash override - 111
flash - 110
immediate - 10X
priority - 01X
routine - 00X
The security levels are:
top secret - 11
secret - 10
confidential - 01
unclassified - 00
The compartments are assigned by the Defense Communications Agency.
The defaults are precedence: routine, security: unclassified,
compartment: zero. A host which does not implement precedence or
security feature should clear these fields to zero for segments it
sends.
A connection attempt with mismatched security/compartment values or a
lower precedence value should be rejected by sending a reset.
Note that TCP modules which operate only at the default value of
precedence will still have to check the precedence of incoming
segments and possibly raise the precedence level they use on the
connection.
3.7. Data Communication
Once the connection is established data is communicated by the
exchange of segments. Because segments may be lost due to errors
(checksum test failure), or network congestion, TCP uses
retransmission (after a timeout) to ensure delivery of every segment.
Duplicate segments may arrive due to network or TCP retransmission.
As discussed in the section on sequence numbers the TCP performs
certain tests on the sequence and acknowledgment numbers in the
segments to verify their acceptability.
The sender of data keeps track of the next sequence number to use in
the variable SND.NXT. The receiver of data keeps track of the next
[Page 38]
January 1980
Transmission Control Protocol
Functional Specification
sequence number to expect in the variable RCV.NXT. The sender of data
keeps track of the oldest unacknowledged sequence number in the
variable SND.UNA. If the data flow is momentarily idle and all data
sent has been acknowledged then the three variables will be equal.
When the sender creates a segment and transmits it the sender advances
SND.NXT. When the receiver accepts a segment it advances RCV.NXT and
sends an acknowledgment. When the data sender receives an
acknowledgment it advances SND.UNA. The extent to which the values of
these variables differ is a measure of the delay in the communication.
Normally the amount by which the variables are advanced is the length
of the data in the segment. However, when letters are used there are
special provisions for coordination the sequence numbers, the letter
boundaries, and the receive buffer boundaries.
End of Letter Sequence Number Adjustments
There is provision in TCP for the receiver of data to optionally
communicate to the sender of data on a connection at the time of the
connection synchronization the receiver's buffer size. If this is
done the receiver must use this fixed size of buffers for the lifetime
of the connection. If a buffer size is communicated then there is a
coordination between receive buffers, letters, and sequence numbers.
Each time a buffer is completed either due to being filled or due to
an end of letter, the sequence number is incremented through the end
of that buffer.
That is, whenever an EOL is transmitted, the sender advances its send
sequence number, SND.NXT, by an amount sufficient to consume all the
unused space in the receiver's buffer. The amount of space consumed
in this fashion is subtracted from the send window just as is the
space consumed by actual data.
And, whenever an EOL is received, the receiver advances its receive
sequence number, RCV.NXT, by an amount sufficient to consume all the
unused space in the receiver's buffer. The amount of space consumed
in this fashion is subtracted from the receive window just as is the
space consumed by actual data.
[Page 39]
January 1980
Transmission Control Protocol
Functional Specification
older sequence numbers newer sequence numbers
| Buffer 1 | Buffer 2
| |
----+-------------------------------+-----------------
XXXXXXXXXXXXXXXXXXXXX+++++++++++
| | |
|<-----SEG.LEN------>| |
| | |
| | |
SEG.SEQ A B
XXX - data octets from segment
+++ - phantom data
<----- sequence space ----->
End of Letter Adjustment
Figure 17.
In the case illustrated above, if the segment does not carry an EOL
flag, the next value of SND.NXT or RCV.NXT will be A. If it does
carry an EOL flag, the next value will be B.
The exchange of buffer size and sequencing information is done in
units of octets. If no buffer size is stated, then the buffer size is
assumed to be 1 octet. The receiver tells the sender the size of the
buffer in a SYN segment that contains the 16 bit buffer size data in
an option field in the TCP header.
Each EOL advances the sequence number (SN) to the next buffer boundary
While LBB < SEG.SEQ+SEG.LEN
Do LBB <- LBB + BS End
SN <- LBB
where LBB is the Last Buffer Beginning, and BS is the buffer size.
The CLOSE user call implies an end of letter, as does the FIN control
flag in an incoming segment.
The Communication of Urgent Information
The objective of the TCP urgent mechanism is to allow the sending user
to stimulate the receiving user to accept some urgent data and to
permit the receiving TCP to indicate to the receiving user when all
the currently known urgent data has been received by the user.
[Page 40]
January 1980
Transmission Control Protocol
Functional Specification
This mechanism permits a point in the data stream to be designated as
the end of "urgent" information. Whenever this point is in advance of
the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
should tell the user to go into "urgent mode"; when the receive
sequence number catches up to the urgent pointer, the TCP should tell
user to go into "normal mode". If the urgent pointer is updated while
the user is in "read fast" mode, the update will be invisible to the
user.
The method employs a urgent field which is carried in all segments
transmitted. The URG control flag indicates that the urgent field is
meaningful and should be added to the segment sequence number to yield
the urgent pointer. The absence of this flag indicates that the
urgent pointer has not changed.
To send an urgent indication the user must also send at least one data
octet. If the sending user also indicates end of letter, timely
delivery of the urgent information to the destination process is
enhanced.
Managing the Window
The window sent in each segment indicates the range of sequence number
the sender of the window (the data receiver) is currently prepared to
accept. There is an assumption that this is related to the currently
available data buffer space available for this connection. The window
information is a guideline to be aimed at.
Indicating a large window encourages transmissions. If more data
arrives than can be accepted, it will be discarded. This will result
in excessive retransmissions, adding unnecessarily to the load on the
network and the TCPs. Indicating a small window may restrict the
transmission of data to the point of introducing a round trip delay
between each new segment transmitted.
The mechanisms provided allow a TCP to advertise a large window and to
subsequently advertise a much smaller window without having accepted
that much data. This, so called "shrinking the window," is strongly
discouraged. The robustness principle dictates that TCPs will not
shrink the window themselves, but will be prepared for such behavior
on the part of other TCPs.
The sending TCP must be prepared to accept and send at least one octet
of new data even if the send window is zero. The sending TCP should
regularly retransmit to the receiving TCP even when the window is
zero. Two minutes is recommended for the retransmission interval when
the window is zero. This retransmission is essential to guarantee
[Page 41]
January 1980
Transmission Control Protocol
Functional Specification
that when either TCP has a zero window the re-opening of the window
will be reliably reported to the other.
The sending TCP packages the data to be transmitted into segments
which fit the current window, and may repackage segments on the
retransmission queue. Such repackaging is not required, but may be
helpful.
Users must keep reading connections they close for sending until the
TCP says no more data.
In a connection with a one-way data flow, the window information will
be carried in acknowledgment segments that all have the same sequence
number so there will be no way to reorder them if they arrive out of
order. This is not a serious problem, but it will allow the window
information to be on occasion temporarily based on old reports from
the data receiver.
3.8. Interfaces
There are of course two interfaces of concern: the user/TCP interface
and the TCP/IP interface. We have a fairly elaborate model of the
user/TCP interface, but only a sketch of the interface to the lower
level protocol module.
User/TCP Interface
The functional description of user commands to the TCP is, at best,
fictional, since every operating system will have different
facilities. Consequently, we must warn readers that different TCP
implementations may have different user interfaces. However, all
TCPs must provide a certain minimum set of services to guarantee
that all TCP implementations can support the same protocol
hierarchy. This section specifies the functional interfaces
required of all TCP implementations.
TCP User Commands
The following sections functionally characterize a USER/TCP
interface. The notation used is similar to most procedure or
function calls in high level languages, but this usage is not
meant to rule out trap type service calls (e.g., SVCs, UUOs,
EMTs).
The user commands described below specify the basic functions the
TCP must perform to support interprocess communication.
Individual implementations should define their own exact format,
and may provide combinations or subsets of the basic functions in
[Page 42]
January 1980
Transmission Control Protocol
Functional Specification
single calls. In particular, some implementations may wish to
automatically OPEN a connection on the first SEND or RECEIVE
issued by the user for a given connection.
In providing interprocess communication facilities, the TCP must
not only accept commands, but must also return information to the
processes it serves. The latter consists of:
(a) general information about a connection (e.g., interrupts,
remote close, binding of unspecified foreign socket).
(b) replies to specific user commands indicating success or
various types of failure.
Open
Format: OPEN (local port, foreign socket, active/passive
[, buffer size] [, timeout] [, precedence]
[, security/compartment]) -> local connection name
We assume that the local TCP is aware of the identity of the
processes it serves and will check the authority of the process
to use the connection specified. Depending upon the
implementation of the TCP, the local network and TCP identifiers
for the source address will either be supplied by the TCP or by
the processes that serve it (e.g., the program which interfaces
the TCP network). These considerations are the result of
concern about security, to the extent that no TCP be able to
masquerade as another one, and so on. Similarly, no process can
masquerade as another without the collusion of the TCP.
If the active/passive flag is set to passive, then this is a
call to LISTEN for an incoming connection. A passive open may
have either a fully specified foreign socket to wait for a
particular connection or an unspecified foreign socket to wait
for any call. A fully specified passive call can be made active
by the subsequent execution of a SEND.
A full-duplex transmission control block (TCB) is created and
partially filled in with data from the OPEN command parameters.
On an active OPEN command, the TCP will begin the procedure to
synchronize (i.e., establish) the connection at once.
The buffer size, if present, indicates that the caller will
always receive data from the connection in that size of buffers.
This buffer size is a measure of the buffer between the user and
[Page 43]
January 1980
Transmission Control Protocol
Functional Specification
the local TCP. The buffer size between the two TCPs may be
different.
The timeout, if present, permits the caller to set up a timeout
for all buffers transmitted on the connection. If a buffer is
not successfully delivered to the destination within the timeout
period, the TCP will abort the connection. The present global
default is 30 seconds. The buffer retransmission rate may vary;
most likely, it will be related to the measured time for
responses from the remote TCP.
The TCP or some component of the operating system will verify
the users authority to open a connection with the specified
precedence or security/compartment. The absence of precedence
or security/compartment specification in the OPEN call indicates
the default values should be used.
TCP will accept incoming requests as matching only if the
security/compartment information is exactly the same and only if
the precedence is equal to or higher than the precedence
requested in the OPEN call.
The precedence for the connection is the higher of the values
requested in the OPEN call and received from the incoming
request, and fixed at that value for the life of the connection.
Depending on the TCP implementation, either a local connection
name will be returned to the user by the TCP, or the user will
specify this local connection name (in which case another
parameter is needed in the call). The local connection name can
then be used as a short hand term for the connection defined by
the <local socket, foreign socket> pair.
Send
Format: SEND(local connection name, buffer address, byte count,
EOL flag, URGENT flag [, timeout])
This call causes the data contained in the indicated user buffer
to be sent on the indicated connection. If the connection has
not been opened, the SEND is considered an error. Some
implementations may allow users to SEND first; in which case, an
automatic OPEN would be done. If the calling process is not
authorized to use this connection, an error is returned.
If the EOL flag is set, the data is the End Of a Letter, and the
EOL bit will be set in the last TCP segment created from the
[Page 44]
January 1980
Transmission Control Protocol
Functional Specification
buffer. If the EOL flag is not set, subsequent SENDs will
appear to be part of the same letter.
If the URGENT flag is set, segments resulting from this call
will have the urgent pointer set to indicate that some of the
data associated with this call is urgent. This facility, for
example, can be used to simulate "break" signals from terminals
or error or completion codes from I/O devices. The semantics of
this signal to the receiving process are unspecified. The
receiving TCP will signal the urgent condition to the receiving
process as long as the urgent pointer indicates that data
preceding the urgent pointer has not been consumed by the
receiving process. The purpose of urgent is to stimulate the
receiver to accept some urgent data and to indicate to the
receiver when all the currently known urgent data has been
received.
The number of times the sending user's TCP signals urgent will
not necessarily be equal to the number of times the receiving
user will be notified of the presence of urgent data.
If no foreign socket was specified in the OPEN, but the
connection is established (e.g., because a LISTENing connection
has become specific due to a foreign segment arriving for the
local socket), then the designated buffer is sent to the implied
foreign socket. In general, users who make use of OPEN with an
unspecified foreign socket can make use of SEND without ever
explicitly knowing the foreign socket address.
However, if a SEND is attempted before the foreign socket
becomes specified, an error will be returned. Users can use the
STATUS call to determine the status of the connection. In some
implementations the TCP may notify the user when an unspecified
socket is bound.
If a timeout is specified, then the current timeout for this
connection is changed to the new one.
In the simplest implementation, SEND would not return control to
the sending process until either the transmission was complete
or the timeout had been exceeded. However, this simple method
is both subject to deadlocks (for example, both sides of the
connection might try to do SENDs before doing any RECEIVEs) and
offers poor performance, so it is not recommended. A more
sophisticated implementation would return immediately to allow
the process to run concurrently with network I/O, and,
furthermore, to allow multiple SENDs to be in progress.
[Page 45]
January 1980
Transmission Control Protocol
Functional Specification
Multiple SENDs are served in first come, first served order, so
the TCP will queue those it cannot service immediately.
We have implicitly assumed an asynchronous user interface in
which a SEND later elicits some kind of SIGNAL or
pseudo-interrupt from the serving TCP. An alternative is to
return a response immediately. For instance, SENDs might return
immediate local acknowledgment, even if the segment sent had not
been acknowledged by the distant TCP. We could optimistically
assume eventual success. If we are wrong, the connection will
close anyway due to the timeout. In implementations of this
kind (synchronous), there will still be some asynchronous
signals, but these will deal with the connection itself, and not
with specific segments or letters.
NOTA BENE: In order for the process to distinguish among error
or success indications for different SENDs, it might be
appropriate for the buffer address to be returned along with the
coded response to the SEND request. TCP-to-user signals are
discussed below, indicating the information which should be
returned to the calling process.
Receive
Format: RECEIVE (local connection name, buffer address, byte
count)
This command allocates a receiving buffer associated with the
specified connection. If no OPEN precedes this command or the
calling process is not authorized to use this connection, an
error is returned.
In the simplest implementation, control would not return to the
calling program until either the buffer was filled, or some
error occurred, but this scheme is highly subject to deadlocks.
A more sophisticated implementation would permit several
RECEIVEs to be outstanding at once. These would be filled as,
segments arrive. This strategy permits increased throughput at
the cost of a more elaborate scheme (possibly asynchronous) to
notify the calling program that a letter has been received or a
buffer filled.
If insufficient buffer space is given to reassemble a complete
letter, the EOL flag will not be set in the response to the
RECEIVE. The buffer will be filled with as much data as it can
hold. The last buffer required to hold the letter is returned
with EOL signaled.
[Page 46]
January 1980
Transmission Control Protocol
Functional Specification
The remaining parts of a partly delivered letter will be placed
in buffers as they are made available via successive RECEIVEs.
If a number of RECEIVEs are outstanding, they may be filled with
parts of a single long letter or with at most one letter each.
The return codes associated with each RECEIVE will indicate what
is contained in the buffer.
If a buffer size was given in the OPEN call, then all buffers
presented in RECEIVE calls must be of exactly that size, or an
error indication will be returned.
The URGENT flag will be set only if the receiving user has
previously been informed via a TCP-to-user signal, that urgent
data is waiting. The receiving user should thus be in
"read-fast" mode. If the URGENT flag is on, additional urgent
data remains. If the URGENT flag is off, this call to RECEIVE
has returned all the urgent data, and the user may now leave
"read-fast" mode.
To distinguish among several outstanding RECEIVEs and to take
care of the case that a letter is smaller than the buffer
supplied, the return code is accompanied by both a buffer
pointer and a byte count indicating the actual length of the
letter received.
Alternative implementations of RECEIVE might have the TCP
allocate buffer storage, or the TCP might share a ring buffer
with the user. Variations of this kind will produce obvious
variation in user interface to the TCP.
Close
Format: CLOSE(local connection name)
This command causes the connection specified to be closed. If
the connection is not open or the calling process is not
authorized to use this connection, an error is returned.
Closing connections is intended to be a graceful operation in
the sense that outstanding SENDs will be transmitted (and
retransmitted), as flow control permits, until all have been
serviced. Thus, it should be acceptable to make several SEND
calls, followed by a CLOSE, and expect all the data to be sent
to the destination. It should also be clear that users should
continue to RECEIVE on CLOSING connections, since the other side
may be trying to transmit the last of its data. Thus, CLOSE
means "I have no more to send" but does not mean "I will not
receive any more." It may happen (if the user level protocol is
not well thought out) that the closing side is unable to get rid
[Page 47]
January 1980
Transmission Control Protocol
Functional Specification
of all its data before timing out. In this event, CLOSE turns
into ABORT, and the closing TCP gives up.
The user may CLOSE the connection at any time on his own
initiative, or in response to various prompts from the TCP
(e.g., remote close executed, transmission timeout exceeded,
destination inaccessible).
Because closing a connection requires communication with the
foreign TCP, connections may remain in the closing state for a
short time. Attempts to reopen the connection before the TCP
replies to the CLOSE command will result in error responses.
Close also implies end of letter.
Status
Format: STATUS(local connection name)
This is an implementation dependent user command and could be
excluded without adverse effect. Information returned would
typically come from the TCB associated with the connection.
This command returns a data block containing the following
information:
local socket,
foreign socket,
local connection name,
receive window,
send window,
connection state,
number of buffers awaiting acknowledgment,
number of buffers pending receipt (including partial ones),
receive buffer size,
urgent state,
precedence,
security/compartment,
and default transmission timeout.
Depending on the state of the connection, or on the
implementation itself, some of this information may not be
available or meaningful. If the calling process is not
authorized to use this connection, an error is returned. This
prevents unauthorized processes from gaining information about a
connection.
[Page 48]
January 1980
Transmission Control Protocol
Functional Specification
Abort
Format: ABORT (local connection name)
This command causes all pending SENDs and RECEIVES to be
aborted, the TCB to be removed, and a special RESET message to
be sent to the TCP on the other side of the connection.
Depending on the implementation, users may receive abort
indications for each outstanding SEND or RECEIVE, or may simply
receive an ABORT-acknowledgment.
TCP-to-User Messages
It is assumed that the operating system environment provides a
means for the TCP to asynchronously signal the user program. When
the TCP does signal a user program, certain information is passed
to the user. Often in the specification the information will be
an error message. In other cases there will be information
relating to the completion of processing a SEND or RECEIVE or
other user call.
The following information is provided: