January 1980
Transmission Control Protocol

[Page 14]                                                              

January 1980                                                           
                                           Transmission Control Protocol

                      3.  FUNCTIONAL SPECIFICATION

3.1.  Header Format

  TCP segments are sent as internet datagrams.  The Internet Protocol
  header carries several information fields, including the source and
  destination host addresses [2].  A TCP header follows the internet
  header, supplying information specific to the TCP protocol.  This
  division allows for the existence of host level protocols other than
  TCP.

  TCP Header Format

    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 Format

          Note that one tick mark represents one bit position.

                               Figure 3.

  Source Port:  16 bits

    The source port number.

  Destination Port:  16 bits

    The destination port number.

                                                               [Page 15]

                                                            January 1980
Transmission Control Protocol
Functional Specification

  Sequence Number:  32 bits

    The sequence number of the first data octet in this segment (except
    when SYN is present).

  Acknowledgment Number:  32 bits

    If the ACK control bit is set this field contains the value of the
    next sequence number the sender of the segment is expecting to
    receive.  Once a connection is established this is always sent.

  Data Offset:  4 bits

    The number of 32 bit words in the TCP Header.  This indicates where
    the data begins.  The TCP header including options is an integral
    number of 32 bits long.

  Reserved:  6 bits

    Reserved for future use.  Must be zero.

  Control Bits:  8 bits (from left to right):

    URG:  Urgent Pointer field significant
    ACK:  Acknowledgment field significant
    EOL:  End of Letter
    RST:  Reset the connection
    SYN:  Synchronize sequence numbers
    FIN:  No more data from sender

  Window:  16 bits

    The number of data octets beginning with the one indicated in the
    acknowledgment field which the sender of this segment is willing to
    accept.

  Checksum:  16 bits

    The checksum field is the 16 bit one's complement of the one's
    complement sum of all 16 bit words in the header and text.  If a
    segment contains an odd number of header and text octets to be
    checksummed, the last octet is padded on the right with zeros to
    form a 16 bit word for checksum purposes.  The pad is not
    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 conceptually
    prefixed to the TCP header.  This pseudo header contains the Source

[Page 16]                                                              

January 1980                                                           
                                           Transmission Control Protocol
                                                Functional Specification

    Address, the Destination Address, the Protocol, and TCP length.
    This gives the TCP protection against misrouted segments.  This
    information is carried in the Internet Protocol and is transferred
    across the TCP/Network interface in the arguments or results of
    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 octets
      (this is not an explicitly transmitted quantity, but is computed
      from the total length, and the header length).

  Urgent Pointer:  16 bits

    This field communicates the current value of the urgent pointer as a
    positive offset from the sequence number in this segment.  The
    urgent pointer points to the sequence number of the octet following
    the urgent data.  This field should only be interpreted in segments
    with the URG control bit set.

  Options:  variable

    Options may occupy space at the end of the TCP header and are a
    multiple of 8 bits in length.  All options are included in the
    checksum.  An option may begin on any octet boundary.  There are two
    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, and
               the actual option-data octets.

    The option-length counts the two octets of option-kind and
    option-length as well as the option-data octets.

    Note that the list of options may be shorter than the data offset
    field might imply.  The content of the header beyond the
    End-of-Option option should be header padding (i.e., zero).

    A TCP must implement all options.

                                                               [Page 17]

                                                            January 1980
Transmission Control Protocol
Functional Specification

    Currently defined options include (kind indicated in octal):

      Kind     Length    Meaning
      ----     ------    -------
       0         -       End of option list.
       1         -       No-Operation.
      100        -       Reserved.
      105        4       Buffer Size.

    Specific Option Definitions

      End of Option List

        +--------+
        |00000000|
        +--------+
         Kind=0

        This option code indicates the end of the option list.  This
        might not coincide with the end of the TCP header according to
        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 of
        the options would not otherwise coincide with the end of the TCP
        header.

      No-Operation

        +--------+
        |00000001|
        +--------+
         Kind=1

        This option code may be used between options, for example, to
        align the beginning of a subsequent option on a word boundary.
        There is no guarantee that senders will use this option, so
        receivers must be prepared to process options even if they do
        not begin on a word boundary.

      Buffer Size

        +--------+--------+---------+--------+
        |01000101|00000100|    buffer size   |
        +--------+--------+---------+--------+
         Kind=105 Length=4

[Page 18]                                                              

January 1980                                                           
                                           Transmission Control Protocol
                                                Functional Specification

        Buffer Size Option Data:  16 bits

          If this option is present, then it communicates the receive
          buffer size at the TCP which sends this segment.  This field
          should only be sent in the initial connection request (i.e.,
          in segments with the SYN control bit set).  If this option is
          not used, the default buffer size of one octet is assumed.

  Padding:  variable

    The TCP header padding is used to ensure that the TCP header ends
    and data begins on a 32 bit boundary.  The padding is composed of
    zeros.

3.2.  Terminology

  Before we can discuss very much about the operation of the TCP we need
  to introduce some detailed terminology.  The maintenance of a TCP
  connection requires the remembering of several variables.  We conceive
  of these variables being stored in a connection record called a
  Transmission Control Block or TCB.  Among the variables stored in the
  TCB are the local and remote socket numbers, the security and
  precedence of the connection, pointers to the user's send and receive
  buffers, pointers to the retransmit queue and to the current segment.
  In addition several variables relating to the send and receive
  sequence numbers are stored in the TCB.

    Send Sequence Variables

      SND.UNA - send unacknowledged
      SND.NXT - send sequence
      SND.WND - send window
      SND.BS  - send buffer size
      SND.UP  - send urgent pointer
      SND.WL  - send sequence number used for last window update
      SND.LBB - send last buffer beginning
      ISS     - initial send sequence number

    Receive Sequence Variables

      RCV.NXT - receive sequence
      RCV.WND - receive window
      RCV.BS  - receive buffer size
      RCV.UP  - receive urgent pointer
      RCV.LBB - receive last buffer beginning
      IRS     - initial receive sequence number

                                                               [Page 19]

                                                            January 1980
Transmission Control Protocol
Functional Specification

  The following diagrams may help to relate some of these variables to
  the sequence space.

  Send Sequence Space

                   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 Space

                               Figure 4.

  Receive Sequence Space

                       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 Space

                               Figure 5.

  There are also some variables used frequently in the discussion that
  take their values from the fields of the current segment.

[Page 20]                                                              

January 1980                                                           
                                           Transmission Control Protocol
                                                Functional Specification

    Current Segment Variables

      SEG.SEQ - segment sequence number
      SEG.ACK - segment acknowledgment number
      SEG.LEN - segment length
      SEG.WND - segment window
      SEG.UP  - segment urgent pointer
      SEG.PRC - segment precedence value

  A connection progresses through a series of states during its
  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 it
  represents the state when there is no TCB, and therefore, no
  connection.  Briefly the meanings of the states are:

    LISTEN - represents waiting for a connection request from any remote
    TCP and port.

    SYN-SENT - represents waiting for a matching connection request
    after having sent a connection request.

    SYN-RECEIVED - represents waiting for a confirming connection
    request acknowledgment after having both received and sent a
    connection request.

    ESTABLISHED - represents an open connection, ready to transmit and
    receive data segments.

    FIN-WAIT-1 - represents waiting for a connection termination request
    from the remote TCP, or an acknowledgment of the connection
    termination request previously sent.

    FIN-WAIT-2 - represents waiting for a connection termination request
    from the remote TCP.

    TIME-WAIT - represents waiting for enough time to pass to be sure
    the remote TCP received the acknowledgment of its connection
    termination request.

    CLOSE-WAIT - represents waiting for a connection termination request
    from the local user.

    CLOSING - represents waiting for a connection termination request
    acknowledgment from the remote TCP.

    CLOSED - represents no connection state at all.

                                                               [Page 21]

                                                            January 1980
Transmission Control Protocol
Functional Specification

  A TCP connection progresses from one state to another in response to
  events.  The events are the user calls, OPEN, SEND, RECEIVE, CLOSE,
  ABORT, and STATUS; the incoming segments, particularly those
  containing the SYN and FIN flags; and timeouts.

  The Glossary contains a more complete list of terms and their
  definitions.

  The state diagram in figure 6 only illustrates state changes, together
  with the causing events and resulting actions, but addresses neither
  error conditions nor actions which are not connected with state
  changes.  In a later section, more detail is offered with respect to
  the reaction of the TCP to events.

[Page 22]                                                              

January 1980                                                           
                                           Transmission Control Protocol
                                                Functional Specification

                              +---------+ ---------\      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 Diagram
                               Figure 6.

                                                               [Page 23]

                                                            January 1980
Transmission Control Protocol
Functional Specification

3.3.  Sequence Numbers

  A fundamental notion in the design is that every octet of data sent
  over a TCP connection has a sequence number.  Since every octet is
  sequenced, each of them can be acknowledged.  The acknowledgment
  mechanism employed is cumulative so that an acknowledgment of sequence
  number X indicates that all octets up to but not including X have been
  received.  This mechanism allows for straight-forward duplicate
  detection in the presence of retransmission.  Numbering of octets
  within a segment is that the first data octet immediately following
  the header is the lowest numbered, and the following octets are
  numbered consecutively.

  It is essential to remember that the actual sequence number space is
  finite, though very large.  This space ranges from 0 to 2**32 - 1.
  Since the space is finite, all arithmetic dealing with sequence
  numbers must be performed modulo 2**32.  This unsigned arithmetic
  preserves the relationship of sequence numbers as they cycle from
  2**32 - 1 to 0 again.  There are some subtleties to computer modulo
  arithmetic, so great care should be taken in programming the
  comparison of such values.  The typical kinds of sequence number
  comparisons which the TCP must perform include:

    (a)  Determining that an acknowledgment refers to some sequence
         number sent but not yet acknowledged.

    (b)  Determining that all sequence numbers occupied by a segment
         have been acknowledged (e.g., to remove the segment from a
         retransmission queue).

    (c)  Determining that an incoming segment contains sequence numbers
         which are expected (i.e., that the segment "overlaps" the
         receive window).

[Page 24]                                                              

January 1980                                                           
                                           Transmission Control Protocol
                                                Functional Specification

  On send connections the following comparisons are needed:

    older sequence numbers                        newer sequence numbers

        SND.UNA                SEG.ACK                 SND.NXT 
           |                      |                       |    
       ----|----XXXXXXX------XXXXXXXXXX---------XXXXXX----|----
           |    |            |    |             |         |    
                |            |                  |              
             Segment 1    Segment 2          Segment 3         

                      <----- sequence space ----->

                   Sending Sequence Space Information

                               Figure 7.

    SND.UNA = oldest unacknowledged sequence number

    SND.NXT = next sequence number to be sent

    SEG.ACK = acknowledgment (next sequence number expected by the
              acknowledging TCP)

    SEG.SEQ = first sequence number of a segment

    SEG.SEQ+SEG.LEN-1 = last sequence number of a segment

  A new acknowledgment (called an "acceptable ack"), is one for which
  the inequality below holds:

    SND.UNA < SEG.ACK =< SND.NXT

  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 sum
  of its sequence number and length is less than the acknowledgment
  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 which
  do not occupy any sequence space (e.g., empty acknowledgment segments)
  are never placed on the retransmission queue, so would not go through
  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]