Local Connection Name Always
Response String Always
Buffer Address Send & Receive
Byte count (counts bytes received) Receive
End-of-Letter flag Receive
End-of-Urgent flag Receive
TCP/Network Interface
The TCP calls on a lower level protocol module to actually send and
receive information over a network. One case is that of the ARPA
internetwork system where the lower level module is the Internet
Protocol [2]. In most cases the following simple interface would be
adequate.
[Page 49]
January 1980
Transmission Control Protocol
Functional Specification
The following two calls satisfy the requirements for the TCP to
internet protocol module communication:
SEND (dest, TOS, TTL, BufPTR, len, Id, DF, options => result)
where:
dest = destination address
TOS = type of service
TTL = time to live
BufPTR = buffer pointer
len = length of buffer
Id = Identifier
DF = Don't Fragment
options = internet option data
result = response
OK = datagram sent ok
Error = error in arguments or local network error
Note that the precedence is included in the TOS and the
security/compartment is passed as an option.
RECV (BufPTR => result, source, dest, prot, TOS, len)
where:
BufPTR = buffer pointer
result = response
OK = datagram received ok
Error = error in arguments
source = source address
dest = destination address
prot = protocol
TOS = type of service
options = internet option data
len = length of buffer
Note that the precedence is in the TOS, and the
security/compartment is an option.
When the TCP sends a segment, it executes the SEND call supplying
all the arguments. The internet protocol module, on receiving
this call, checks the arguments and prepares and sends the
message. If the arguments are good and the segment is accepted by
the local network, the call returns successfully. If either the
arguments are bad, or the segment is not accepted by the local
network, the call returns unsuccessfully. On unsuccessful
returns, a reasonable report should be made as to the cause of the
[Page 50]
January 1980
Transmission Control Protocol
Functional Specification
problem, but the details of such reports are up to individual
implementations.
When a segment arrives at the internet protocol module from the
local network, either there is a pending RECV call from TCP or
there is not. In the first case, the pending call is satisfied by
passing the information from the segment to the TCP. In the
second case, the TCP is notified of a pending segment.
The notification of a TCP may be via a pseudo interrupt or similar
mechanism, as appropriate in the particular operating system
environment of the implementation.
A TCP's RECV call may then either be immediately satisfied by a
pending segment, or the call may be pending until a segment
arrives.
We note that the Internet Protocol provides arguments for a type
of service and for a time to live. TCP uses the following
settings for these parameters:
Type of Service = Precedence: none, Package: stream,
Reliability: higher, Preference: speed, Speed: higher; or
00011111.
Time to Live = one minute, or 00111100.
Note that the assumed maximum segment lifetime is two minutes.
Here we explicitly ask that a segment be destroyed if it
cannot be delivered by the internet system within one minute.
[Page 51]
January 1980
Transmission Control Protocol
Functional Specification
3.9. Event Processing
The activity of the TCP can be characterized as responding to events.
The events that occur can be cast into three categories: user calls,
arriving segments, and timeouts. This section describes the
processing the TCP does in response to each of the events. In many
cases the processing required depends on the state of the connection.
Events that occur:
User Calls
OPEN
SEND
RECEIVE
CLOSE
ABORT
STATUS
Arriving Segments
SEGMENT ARRIVES
Timeouts
USER TIMEOUT
RETRANSMISSION TIMEOUT
The model of the TCP/user interface is that user commands receive an
immediate return and possibly a delayed response via an event or
pseudo interrupt. In the following descriptions, the term "signal"
means cause a delayed response.
Error responses are given as character strings. For example, user
commands referencing connections that do not exist receive "error:
connection not open".
Please note in the following that all arithmetic on sequence numbers,
acknowledgment numbers, windows, et cetera, is modulo 2**32 the size
of the sequence number space. Also note that "=<" means less than or
equal to.
A natural way to think about processing incoming segments is to
imagine that they are first tested for proper sequence number (i.e.,
that their contents lie in the range of the expected "receive window"
in the sequence number space) and then that they are generally queued
and processed in sequence number order.
[Page 52]
January 1980
Transmission Control Protocol
Functional Specification
When a segment overlaps other already received segments we reconstruct
the segment to contain just the new data, and adjust the header fields
to be consistent.
[Page 53]
January 1980
Transmission Control Protocol
Functional Specification
OPEN Call
OPEN Call
CLOSED STATE (i.e., TCB does not exist)
Create a new transmission control block (TCB) to hold connection
state information. Fill in local socket identifier, foreign
socket, precedence, security/compartment, and user timeout
information. Verify the security and precedence requested are
allowed for this user, if not return "error: precedence not
allowed" or "error: security/compartment not allowed." If active
and the foreign socket is unspecified, return "error: foreign
socket unspecified"; if active and the foreign socket is
specified, issue a SYN segment. An initial send sequence number
(ISS) is selected and the TCP receive buffer size is selected (if
applicable). A SYN segment of the form <SEQ=ISS><CTL=SYN> is sent
(this may include the buffer size option if applicable). Set
SND.UNA to ISS, SND.NXT to ISS+1, SND.LBB to ISS+1, enter SYN-SENT
state, and return.
If the caller does not have access to the local socket specified,
return "error: connection illegal for this process". If there is
no room to create a new connection, return "error: insufficient
resources".
LISTEN STATE
SYN-SENT STATE
SYN-RECEIVED STATE
ESTABLISHED STATE
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
TIME-WAIT STATE
CLOSE-WAIT STATE
CLOSING STATE
Return "error: connection already exists".
[Page 54]
January 1980
Transmission Control Protocol
Functional Specification
SEND Call
SEND Call
CLOSED STATE (i.e., TCB does not exist)
If the user should no have access to such a connection, then
return "error: connection illegal for this process".
Otherwise, return "error: connection does not exist".
LISTEN STATE
If the foreign socket is specified, then change the connection
from passive to active, select an ISS, and select the receive
buffer size. Send a SYN segment, set SND.UNA to ISS, SND.NXT to
ISS+1 and SND.LBB to ISS+1. Enter SYN-SENT state. Data
associated with SEND may be sent with SYN segment or queued for
transmission after entering ESTABLISHED state. The urgent bit if
requested in the command should be sent with the first data
segment sent as a result of this command. If there is no room to
queue the request, respond with "error: insufficient resources".
If Foreign socket was not specified, then return "error: foreign
socket unspecified".
SYN-SENT STATE
Queue for processing after the connection is ESTABLISHED.
Typically, nothing can be sent yet, anyway, because the send
window has not yet been set by the other side. If no space,
return "error: insufficient resources".
SYN-RECEIVED STATE
Queue for later processing after entering ESTABLISHED state. If
no space to queue, respond with "error: insufficient resources".
ESTABLISHED STATE
Segmentize the buffer, send or queue it for output, with a
piggybacked acknowledgment (acknowledgment value = RCV.NXT) with
the data. If there is insufficient space to remember this buffer,
simply return "error: insufficient resources".
If remote buffer size is not one octet, and, if this is the end of
a letter, do the following end-of-letter/buffer-size adjustment
processing:
[Page 55]
January 1980
Transmission Control Protocol
Functional Specification
SEND Call
if EOL = 0 then
SND.NXT <- SEG.SEQ + SEG.LEN
if EOL = 1 then
While SND.LBB < SEG.SEQ + SEG.LEN
Do SND.LBB <- SND.LBB + SND.BS End
SND.NXT <- SND.LBB
If the urgent flag is set, then SND.UP <- SND.NXT-1 and set the
urgent pointer in the outgoing segment.
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
TIME-WAIT STATE
Return "error: connection closing" and do not service request.
CLOSE-WAIT STATE
Segmentize any text to be sent and queue for output. If there is
insufficient space to remember the SEND, return "error:
insufficient resources"
CLOSING STATE
Respond with "error: connection closing"
[Page 56]
January 1980
Transmission Control Protocol
Functional Specification
RECEIVE Call
RECEIVE Call
CLOSED STATE (i.e., TCB does not exist)
If the user should no have access to such a connection, return
"error: connection illegal for this process".
Otherwise return "error: connection does not exist".
LISTEN STATE
SYN-SENT STATE
SYN-RECEIVED STATE
Queue for processing after entering ESTABLISHED state. If there
is no room to queue this request, respond with "error:
insufficient resources".
ESTABLISHED STATE
If insufficient incoming segments are queued to satisfy the
request, queue the request. If there is no queue space to
remember the RECEIVE, respond with "error: insufficient
resources".
Reassemble queued incoming segments into receive buffer and return
to user. Mark "end of letter" (EOL) if this is the case.
If RCV.UP is in advance of the data currently being passed to the
user notify the user of the presence of urgent data.
When the TCP takes responsibility for delivering data to the user
that fact must be communicated to the sender via an
acknowledgment. The formation of such an acknowledgment is
described below in the discussion of processing an incoming
segment.
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
Reassemble and return a letter, or as much as will fit, in the
user buffer. Queue the request if it cannot be serviced
immediately.
[Page 57]
January 1980
Transmission Control Protocol
Functional Specification
RECEIVE Call
TIME-WAIT STATE
CLOSE-WAIT STATE
Since the remote side has already sent FIN, RECEIVEs must be
satisfied by text already reassembled, but not yet delivered to
the user. If no reassembled segment text is awaiting delivery,
the RECEIVE should get a "error: connection closing" response.
Otherwise, any remaining text can be used to satisfy the RECEIVE.
CLOSING STATE
Return "error: connection closing"
[Page 58]
January 1980
Transmission Control Protocol
Functional Specification
CLOSE Call
CLOSE Call
CLOSED STATE (i.e., TCB does not exist)
If the user should no have access to such a connection, return
"error: connection illegal for this process".
Otherwise, return "error: connection does not exist".
LISTEN STATE
Any outstanding RECEIVEs should be returned with "error: closing"
responses. Delete TCB, return "ok".
SYN-SENT STATE
Delete the TCB and return "error: closing" responses to any
queued SENDs, or RECEIVEs.
SYN-RECEIVED STATE
Queue for processing after entering ESTABLISHED state or
segmentize and send FIN segment. If the latter, enter FIN-WAIT-1
state.
ESTABLISHED STATE
Queue this until all preceding SENDs have been segmentized, then
form a FIN segment and send it. In any case, enter FIN-WAIT-1
state.
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
Strictly speaking, this is an error and should receive a "error:
connection closing" response. An "ok" response would be
acceptable, too, as long as a second FIN is not emitted (the first
FIN may be retransmitted though).
[Page 59]
January 1980
Transmission Control Protocol
Functional Specification
CLOSE Call
TIME-WAIT STATE
Strictly speaking, this is an error and should receive a "error:
connection closing" response. An "ok" response would be
acceptable, too. However, since the FIN has been sent and
acknowledged, nothing should be sent (or retransmitted).
CLOSE-WAIT STATE
Queue this request until all preceding SENDs have been
segmentized; then send a FIN segment, enter CLOSING state.
CLOSING STATE
Respond with "error: connection closing"
[Page 60]
January 1980
Transmission Control Protocol
Functional Specification
ABORT Call
ABORT Call
CLOSED STATE (i.e., TCB does not exist)
If the user should no have access to such a connection, return
"error: connection illegal for this process".
Otherwise return "error: connection does not exist".
LISTEN STATE
Any outstanding RECEIVEs should be returned with "error:
connection reset" responses. Delete TCB, return "ok".
SYN-SENT STATE
Delete the TCB and return "reset" responses to any queued SENDs,
or RECEIVEs.
SYN-RECEIVED STATE
Send a RST of the form:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=RST,ACK>
and return any unprocessed SENDs, or RECEIVEs with "reset" code,
delete the TCB.
ESTABLISHED STATE
Send a reset segment:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=RST,ACK>
All queued SENDs and RECEIVEs should be given "reset" responses;
all segments queued for transmission (except for the RST formed
above) or retransmission should be flushed, delete the TCB.
[Page 61]
January 1980
Transmission Control Protocol
Functional Specification
ABORT Call
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
A reset segment (RST) should be formed and sent:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=RST,ACK>
Outstanding SENDs, RECEIVEs, CLOSEs, and/or segments queued for
retransmission, or segmentizing, should be flushed, with
"connection reset" notification to the user, delete the TCB.
TIME-WAIT STATE
Respond with "ok" and delete the TCB.
CLOSE-WAIT STATE
Flush any pending SENDs and RECEIVEs, returning "connection reset"
responses for them. Form and send a RST segment:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=RST,ACK>
Flush all segment queues and delete the TCB.
CLOSING STATE
Respond with "ok" and delete the TCB; flush any remaining segment
queues. If a CLOSE command is still pending, respond "error:
connection reset".
[Page 62]
January 1980
Transmission Control Protocol
Functional Specification
STATUS Call
STATUS Call
CLOSED STATE (i.e., TCB does not exist)
If the user should no have access to such a connection, return
"error: connection illegal for this process".
Otherwise return "error: connection does not exist".
LISTEN STATE
Return "state = LISTEN", and the TCB pointer.
SYN-SENT STATE
Return "state = SYN-SENT", and the TCB pointer.
SYN-RECEIVED STATE
Return "state = SYN-RECEIVED", and the TCB pointer.
ESTABLISHED STATE
Return "state = ESTABLISHED", and the TCB pointer.
FIN-WAIT-1 STATE
Return "state = FIN-WAIT-1", and the TCB pointer.
FIN-WAIT-2 STATE
Return "state = FIN-WAIT-2", and the TCB pointer.
TIME-WAIT STATE
Return "state = TIME-WAIT and the TCB pointer.
CLOSE-WAIT STATE
Return "state = CLOSE-WAIT", and the TCB pointer.
CLOSING STATE
Return "state = CLOSING", and the TCB pointer.
[Page 63]
January 1980
Transmission Control Protocol
Functional Specification
SEGMENT ARRIVES
SEGMENT ARRIVES
If the state is CLOSED (i.e., TCB does not exist) then
all data in the incoming segment is discarded. An incoming
segment containing a RST is discarded. An incoming segment not
containing a RST causes a RST to be sent in response. The
acknowledgment and sequence field values are selected to make the
reset sequence acceptable to the TCP that sent the offending
segment.
If the ACK bit is off, sequence number zero is used,
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
If the ACK bit is on,
<SEQ=SEG.ACK><CTL=RST>
Return.
If the state is LISTEN then
first check for an ACK
Any acknowledgment is bad if it arrives on a connection still in
the LISTEN state. An acceptable reset segment should be formed
for any arriving ACK-bearing segment, except another RST. The
RST should be formatted as follows:
<SEQ=SEG.ACK><CTL=RST>
Return.
An incoming RST should be ignored. Return.
if there was no ACK then check for a SYN
If the SYN bit is set, check the security. If the
security/compartment on the incoming segment does not exactly
match the security/compartment in the TCB then send a reset and
return. If the SEG.PRC is less than the TCB.PRC then send a
reset and return. If the SEG.PRC is greater than the TCB.PRC
then set TCB.PRC<-SEG.PRC. Now RCV.NXT and RCV.LBB are set to
SEG.SEQ+1, IRS is set to SEG.SEQ and any other control or text
should be queued for processing later. ISS should be selected
and a SYN segment sent of the form:
[Page 64]
January 1980
Transmission Control Protocol
Functional Specification
SEGMENT ARRIVES
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
SND.NXT and SND.LBB are set to ISS+1 and SND.UNA to ISS. The
connection state should be changed to SYN-RECEIVED. Note that
any other incoming control or data (combined with SYN) will be
processed in the SYN-RECEIVED state, but processing of SYN and
ACK should not be repeated. If the listen was not fully
specified (i.e., the foreign socket was not fully specified),
then the unspecified fields should be filled in now.
if there was no SYN but there was other text or control
Any other control or text-bearing segment (not containing SYN)
must have an ACK and thus would be discarded by the ACK
processing. An incoming RST segment could not be valid, since
it could not have been sent in response to anything sent by this
incarnation of the connection. So you are unlikely to get here,
but if you do, drop the segment, and return.
If the state is SYN-SENT then
first check for an ACK
If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, or the
security/compartment in the segment does not exactly match the
security/compartment in the TCB, or the precedence in the
segment is less than the precedence in the TCB, send a reset
<SEQ=SEG.ACK><CTL=RST>
and discard the segment. Return.
If SND.UNA =< SEG.ACK =< SND.NXT and the security/compartment
and precedence are acceptable then the ACK is acceptable.
SND.UNA should be advanced to equal SEG.ACK, and any segments on
the retransmission queue which are thereby acknowledged should
be removed.
if the ACK is ok (or there is no ACK), check the RST bit
If the RST bit is set then signal the user "error: connection
reset", enter CLOSED state, drop the segment, delete TCB, and
return.
if the ACK is ok (or there is no ACK) and it was not a RST, check
the SYN bit
[Page 65]
January 1980
Transmission Control Protocol
Functional Specification
SEGMENT ARRIVES
If the SYN bit is on and the security/compartment and precedence
are acceptable then, RCV.NXT and RCV.LBB are set to SEG.SEQ+1,
IRS is set to SEG.SEQ. If SND.UNA > ISS (our SYN has been
ACKed), change the connection state to ESTABLISHED, otherwise
enter SYN-RECEIVED. In any case, form an ACK segment:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
and send it. Data or controls which were queued for
transmission may be included.
If SEG.PRC is greater than TCB.PRC set TCB.PRC<-SEG.PRC.
If there are other controls or text in the segment then continue
processing at the fifth step below where the URG bit is checked,
otherwise return.
[Page 66]
January 1980
Transmission Control Protocol
Functional Specification
SEGMENT ARRIVES
Otherwise,
first check sequence number
SYN-RECEIVED STATE
ESTABLISHED STATE
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
TIME-WAIT STATE
CLOSE-WAIT STATE
CLOSING STATE
Segments are processed in sequence. Initial tests on arrival
are used to discard old duplicates, but further processing is
done in SEG.SEQ order. If a segment's contents straddle the
boundary between old and new, only the new parts should be
processed.
There are four cases for the acceptability test for an incoming
segment:
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 test above guarantees that the last sequence
number used by the segment lies in the receive-window. If the
RCV.WND is zero, no segments will be acceptable, but special
allowance should be made to accept valid ACKs, URGs and RSTs.
If an incoming segment is not acceptable, an acknowledgment
should be sent in reply:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
If the incoming segment is unacceptable, drop it and return.
[Page 67]
January 1980
Transmission Control Protocol
Functional Specification
SEGMENT ARRIVES
second check security and precedence
If the security/compartment and precedence in the segment do not
exactly match the security/compartment and precedence in the TCB
then form a reset and return.
Note this check is placed following the sequence check to prevent
a segment from an old connection between these parts with a
different security or precedence from causing an abort of the
current connection.
third check the ACK field,
SYN-RECEIVED STATE
If the RST bit is off and SND.UNA < SEG.ACK =< SND.NXT then set
SND.UNA <- SEG.ACK, remove any acknowledged segments from the
retransmission queue, and enter ESTABLISHED state.
If the segment acknowledgment is not acceptable, form a reset
segment,
<SEQ=SEG.ACK><CTL=RST>
and send it, unless the incoming segment is an RST (or there is
no ACK), in which case, it should be discarded, then return.
ESTABLISHED STATE
If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK.
Any segments on the retransmission queue which are thereby
entirely acknowledged are removed. Users should receive
positive acknowledgments for buffers which have been SENT and
fully acknowledged (i.e., SEND buffer should be returned with
"ok" response). If the ACK is a duplicate, it can be ignored.
If the segment passes the sequence number and acknowledgment
number tests, the send window should be updated. If
SND.WL =< SEG.SEQ, set SND.WND <- SEG.WND and set
SND.WL <- SEG.SEQ.
If the remote buffer size is not one, then the
end-of-letter/buffer-size adjustment to sequence numbers may
have an effect on the next expected sequence number to be
acknowledged. It is possible that the remote TCP will
acknowledge with a SEG.ACK equal to a sequence number of an
[Page 68]
January 1980
Transmission Control Protocol
Functional Specification
SEGMENT ARRIVES
octet that was skipped over at the end of a letter. This a mild
error on the remote TCPs part, but not cause for alarm.
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
In addition to the processing for the ESTABLISHED state, if the
retransmission queue is empty, the user's CLOSE can be
acknowledged ("ok") but do not delete the TCB.
TIME-WAIT STATE
The only thing that can arrive in this state is a retransmission
of the remote FIN. Acknowledge it, and restart the 2 MSL
timeout.
CLOSE-WAIT STATE
Do the same processing as for the ESTABLISHED state.
CLOSING STATE
If the ACK acknowledges our FIN then delete the TCB (enter the
CLOSED state), otherwise ignore the segment.
fourth check the RST bit,
SYN-RECEIVED STATE
If the RST bit is set then, if the segment has passed sequence
and acknowledgment tests, it is valid. If this connection was
initiated with a passive OPEN (i.e., came from the LISTEN
state), then return this connection to LISTEN state. The user
need not be informed. If this connection was initiated with an
active OPEN (i.e., came from SYN-SENT state) then the connection
was refused, signal the user "connection refused". In either
case, all segments on the retransmission queue should be
removed.
[Page 69]
January 1980
Transmission Control Protocol
Functional Specification
SEGMENT ARRIVES
ESTABLISHED
FIN-WAIT-1
FIN-WAIT-2
CLOSE-WAIT
CLOSING STATE
If the RST bit is set then, any outstanding RECEIVEs and SEND
should receive "reset" responses. All segment queues should be
flushed. Users should also receive an unsolicited general
"connection reset" signal. Enter the CLOSED state, delete the
TCB, and return.
TIME-WAIT
Enter the CLOSED state, delete the TCB, and return.
fifth, check the SYN bit,
SYN-RECEIVED
ESTABLISHED STATE
If the SYN bit is set, check the segment sequence number against
the receive window. The segment sequence number must be in the
receive window; if not, ignore the segment. If the SYN is on
and SEG.SEQ = IRS then everything is ok and no action is needed;
but if they are not equal, there is an error and a reset must be
sent.
If a reset must be sent it is formed as follows:
<SEQ=SEG.ACK><CTL=RST>
The connection must be aborted as if a RST had been received.
FIN-WAIT STATE-1
FIN-WAIT STATE-2
TIME-WAIT STATE
CLOSE-WAIT STATE
CLOSING STATE
This case should not occur, since a duplicate of the SYN which
started the current connection incarnation will have been
filtered in the SEG.SEQ processing. Other SYN's will have been
rejected by this test as well (see SYN processing for
ESTABLISHED state).
[Page 70]
January 1980
Transmission Control Protocol
Functional Specification
SEGMENT ARRIVES
sixth, check the URG bit,
ESTABLISHED STATE
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
If the URG bit is set, RCV.UP <- max(RCV.UP,SEG.UP), and signal
the user that the remote side has urgent data if the urgent
pointer (RCV.UP) is in advance of the data consumed. If the
user has already been signaled (or is still in the "urgent
mode") for this continuous sequence of urgent data, do not
signal the user again.
TIME-WAIT STATE
CLOSE-WAIT STATE
CLOSING
This should not occur, since a FIN has been received from the
remote side. Ignore the URG.
seventh, process the segment text,
ESTABLISHED STATE
Once in the ESTABLISHED state, it is possible to deliver segment
text to user RECEIVE buffers. Text from segments can be moved
into buffers until either the buffer is full or the segment is
empty. If the segment empties and carries an EOL flag, then the
user is informed, when the buffer is returned, that an EOL has
been received.
If buffer size is not one octet, then do the following
end-of-letter/buffer-size adjustment processing:
if EOL = 0 then
RCV.NXT <- SEG.SEQ + SEG.LEN
if EOL = 1 then
While RCV.LBB < SEG.SEQ+SEG.LEN
Do RCV.LBB <- RCV.LBB + RCV.BS End
RCV.NXT <- RCV.LBB
When the TCP takes responsibility for delivering the data to the
user it must also acknowledge the receipt of the data. Send an
acknowledgment of the form:
[Page 71]
January 1980
Transmission Control Protocol
Functional Specification
SEGMENT ARRIVES
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
This acknowledgment should be piggybacked on a segment being
transmitted if possible without incurring undue delay.
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
If there are outstanding RECEIVEs, they should be satisfied, if
possible, with the text of this segment; remaining text should
be queued for further processing. If a RECEIVE is satisfied,
the user should be notified, with "end-of-letter" (EOL) signal,
if appropriate.
TIME-WAIT STATE
CLOSE-WAIT STATE
This should not occur, since a FIN has been received from the
remote side. Ignore the segment text.
eighth, check the FIN bit,
Send an acknowledgment for the FIN. Signal the user "connection
closing", and return any pending RECEIVEs with same message. Note
that FIN implies EOL for any segment text not yet delivered to the
user. If the current state is ESTABLISHED, enter the CLOSE-WAIT
state. If the current state is FIN-WAIT-1, enter the CLOSING
state. If the current state is FIN-WAIT-2, enter the TIME-WAIT
state.
and return.
[Page 72]
January 1980
Transmission Control Protocol
Functional Specification
USER TIMEOUT
USER TIMEOUT
For any state if the user timeout expires, flush all queues, signal
the user "error: connection aborted due to user timeout" in general
and for any outstanding calls, delete the TCB, and return.
RETRANSMISSION TIMEOUT
For any state if the retransmission timeout expires on a segment in
the retransmission queue, send the segment at the front of the
retransmission queue again, reinitialize the retransmission timer,
and return.
[Page 73]
January 1980
Transmission Control Protocol
[Page 74]
January 1980
Transmission Control Protocol
GLOSSARY
1822
BBN Report 1822, "The Specification of the Interconnection of
a Host and an IMP". The specification of interface between a
host and the ARPANET.
ACK
A control bit (acknowledge) occupying no sequence space, which
indicates that the acknowledgment field of this segment
specifies the next sequence number the sender of this segment
is expecting to receive, hence acknowledging receipt of all
previous sequence numbers.
ARPANET message
The unit of transmission between a host and an IMP in the
ARPANET. The maximum size is about 1012 octets (8096 bits).
ARPANET packet
A unit of transmission used internally in the ARPANET between
IMPs. The maximum size is about 126 octets (1008 bits).
buffer size
An option (buffer size) used to state the receive data buffer
size of the sender of this option. May only be sent in a
segment that also carries a SYN.
connection
A logical communication path identified by a pair of sockets.
datagram
A message sent in a packet switched computer communications
network.
Destination Address
The destination address, usually the network and host
identifiers.
EOL
A control bit (End of Letter) occupying no sequence space,
indicating that this segment ends a logical letter with the
last data octet in the segment. If this end of letter causes
a less than full buffer to be released to the user and the
connection buffer size is not one octet then the
end-of-letter/buffer-size adjustment to the receive sequence
number must be made.
[Page 75]
January 1980
Transmission Control Protocol
Glossary
FIN
A control bit (finis) occupying one sequence number, which
indicates that the sender will send no more data or control
occupying sequence space.
fragment
A portion of a logical unit of data, in particular an internet
fragment is a portion of an internet datagram.
FTP
A file transfer protocol.
header
Control information at the beginning of a message, segment,
fragment, packet or block of data.
host
A computer. In particular a source or destination of messages
from the point of view of the communication network.
Identification
An Internet Protocol field. This identifying value assigned
by the sender aids in assembling the fragments of a datagram.
IMP
The Interface Message Processor, the packet switch of the
ARPANET.
internet address
A source or destination address specific to the host level.
internet datagram
The unit of data exchanged between an internet module and the
higher level protocol together with the internet header.
internet fragment
A portion of the data of an internet datagram with an internet
header.
IP
Internet Protocol.
IRS
The Initial Receive Sequence number. The first sequence
number used by the sender on a connection.
[Page 76]
January 1980
Transmission Control Protocol
Glossary
ISN
The Initial Sequence Number. The first sequence number used
on a connection, (either ISS or IRS). Selected on a clock
based procedure.
ISS
The Initial Send Sequence number. The first sequence number
used by the sender on a connection.
leader
Control information at the beginning of a message or block of
data. In particular, in the ARPANET, the control information
on an ARPANET message at the host-IMP interface.
left sequence
This is the next sequence number to be acknowledged by the
data receiving TCP (or the lowest currently unacknowledged
sequence number) and is sometimes referred to as the left edge
of the send window.
letter
A logical unit of data, in particular the logical unit of data
transmitted between processes via TCP.
local packet
The unit of transmission within a local network.
module
An implementation, usually in software, of a protocol or other
procedure.
MSL
Maximum Segment Lifetime, the time a TCP segment can exist in
the internetwork system. Arbitrarily defined to be 2 minutes.
octet
An eight bit byte.
Options
An Option field may contain several options, and each option
may be several octets in length. The options are used
primarily in testing situations; for example, to carry
timestamps. Both the Internet Protocol and TCP provide for
options fields.
packet
A package of data with a header which may or may not be
[Page 77]
January 1980
Transmission Control Protocol
Glossary
logically complete. More often a physical packaging than a
logical packaging of data.
port
The portion of a socket that specifies which logical input or
output channel of a process is associated with the data.
process
A program in execution. A source or destination of data from
the point of view of the TCP or other host-to-host protocol.
PSN
A Packet Switched Network. For example, the ARPANET.
RCV.BS
receive buffer size, the remote buffer size
RCV.LBB
receive last buffer beginning
RCV.NXT
receive next sequence number
RCV.UP
receive urgent pointer
RCV.WND
receive window
receive last buffer beginning
This is the sequence number of the first octet of the most
recent buffer. This value is use in calculating the next
sequence number when a segment contains an end of letter
indication.
receive next sequence number
This is the next sequence number the local TCP is expecting to
receive.
receive window
This represents the sequence numbers the local (receiving) TCP
is willing to receive. Thus, the local TCP considers that
segments overlapping the range RCV.NXT to
RCV.NXT + RCV.WND - 1 carry acceptable data or control.
Segments containing sequence numbers entirely outside of this
range are considered duplicates and discarded.
[Page 78]
January 1980
Transmission Control Protocol
Glossary
RST
A control bit (reset), occupying no sequence space, indicating
that the receiver should delete the connection without further
interaction. The receiver can determine, based on the
sequence number and acknowledgment fields of the incoming
segment, whether it should honor the reset command or ignore
it. In no case does receipt of a segment containing RST give
rise to a RST in response.
RTP
Real Time Protocol: A host-to-host protocol for communication
of time critical information.
Rubber EOL
An end of letter (EOL) requiring a sequence number adjustment
to align the beginning of the next letter on a buffer
boundary.
SEG.ACK
segment acknowledgment
SEG.LEN
segment length
SEG.PRC
segment precedence value
SEG.SEQ
segment sequence
SEG.UP
segment urgent pointer field
SEG.WND
segment window field
segment
A logical unit of data, in particular a TCP segment is the
unit of data transfered between a pair of TCP modules.
segment acknowledgment
The sequence number in the acknowledgment field of the
arriving segment.
segment length
The amount of sequence number space occupied by a segment,
including any controls which occupy sequence space.
[Page 79]
January 1980
Transmission Control Protocol
Glossary
segment sequence
The number in the sequence field of the arriving segment.
send last buffer beginning
This is the sequence number of the first octet of the most
recent buffer. This value is used in calculating the next
sequence number when a segment contains an end of letter
indication.
send sequence
This is the next sequence number the local (sending) TCP will
use on the connection. It is initially selected from an
initial sequence number curve (ISN) and is incremented for
each octet of data or sequenced control transmitted.
send window
This represents the sequence numbers which the remote
(receiving) TCP is willing to receive. It is the value of the
window field specified in segments from the remote (data
receiving) TCP. The range of sequence numbers which may be
emitted by a TCP lies between SND.NXT and
SND.UNA + SND.WND - 1.
SND.BS
send buffer size, the local buffer size
SND.LBB
send last buffer beginning
SND.NXT
send sequence
SND.UNA
left sequence
SND.UP
send urgent pointer
SND.WL
send sequence number at last window update
SND.WND
send window
socket
An address which specifically includes a port identifier, that
is, the concatenation of an Internet Address with a TCP port.
[Page 80]
January 1980
Transmission Control Protocol
Glossary
Source Address
The source address, usually the network and host identifiers.
SYN
A control bit in the incoming segment, occupying one sequence
number, used at the initiation of a connection, to indicate
where the sequence numbering will start.
TCB
Transmission control block, the data structure that records
the state of a connection.
TCB.PRC
The precedence of the connection.
TCP
Transmission Control Protocol: A host-to-host protocol for
reliable communication in internetwork environments.
TOS
Type of Service, an Internet Protocol field.
Type of Service
An Internet Protocol field which indicates the type of service
for this internet fragment.
URG
A control bit (urgent), occupying no sequence space, used to
indicate that the receiving user should be notified to do
urgent processing as long as there is data to be consumed with
sequence numbers less than the value indicated in the urgent
pointer.
urgent pointer
A control field meaningful only when the URG bit is on. This
field communicates the value of the urgent pointer which
indicates the data octet associated with the sending user's
urgent call.
[Page 81]
January 1980
Transmission Control Protocol
[Page 82]
January 1980
Transmission Control Protocol
REFERENCES
[1] Cerf, V., and R. Kahn, "A Protocol for Packet Network
Intercommunication," IEEE Transactions on Communications,
Vol. COM-22, No. 5, pp 637-648, May 1974.
[2] Postel, J. (ed.), "DOD Standard Internet Protocol," Defense
Advanced Research Projects Agency, Information Processing
Techniques Office, RFC760, IEN 128, January 1980.
[3] Feinler, E. and J. Postel, ARPANET Protocol Handbook, Network
Information Center, SRI International, Menlo Park, CA,
January 1978.
[4] Dalal, Y. and C. Sunshine, "Connection Management in Transport
Protocols," Computer Networks, Vol. 2, No. 6, pp. 454-473,
December 1978.
[Page 83]
January 1980
Transmission Control Protocol