rfc793.txt

this is a linux pptp software

              +---------------------------+                      
              |   Local Network Protocol  |    Network Level     
              +---------------------------+                      

                         Protocol Relationships

                               Figure 2.

  It is expected that the TCP will be able to support higher level
  protocols efficiently.  It should be easy to interface higher level
  protocols like the ARPANET Telnet or AUTODIN II THP to the TCP.

2.6.  Reliable Communication

  A stream of data sent on a TCP connection is delivered reliably and in
  order at the destination.



                                                                [Page 9]


                                                          September 1981
Transmission Control Protocol
Philosophy



  Transmission is made reliable via the use of sequence numbers and
  acknowledgments.  Conceptually, each octet of data is assigned a
  sequence number.  The sequence number of the first octet of data in a
  segment is transmitted with that segment and is called the segment
  sequence number.  Segments also carry an acknowledgment number which
  is the sequence number of the next expected data octet of
  transmissions in the reverse direction.  When the TCP transmits a
  segment containing data, it puts a copy on a retransmission queue and
  starts a timer; when the acknowledgment for that data is received, the
  segment is deleted from the queue.  If the acknowledgment is not
  received before the timer runs out, the segment is retransmitted.

  An acknowledgment by TCP does not guarantee that the data has been
  delivered to the end user, but only that the receiving TCP has taken
  the responsibility to do so.

  To govern the flow of data between TCPs, a flow control mechanism is
  employed.  The receiving TCP reports a "window" to the sending TCP.
  This window specifies the number of octets, starting with the
  acknowledgment number, that the receiving TCP is currently prepared to
  receive.

2.7.  Connection Establishment and Clearing

  To identify the separate data streams that a TCP may handle, the TCP
  provides a port identifier.  Since port identifiers are selected
  independently by each TCP they might not be unique.  To provide for
  unique addresses within each TCP, we concatenate an internet address
  identifying the TCP with a port identifier to create a socket which
  will be unique throughout all networks connected together.

  A connection is fully specified by the pair of sockets at the ends.  A
  local socket may participate in many connections to different foreign
  sockets.  A connection can be used to carry data in both directions,
  that is, it is "full duplex".

  TCPs are free to associate ports with processes however they choose.
  However, several basic concepts are necessary in any implementation.
  There must be well-known sockets which the TCP associates only with
  the "appropriate" processes by some means.  We envision that processes
  may "own" ports, and that processes can initiate connections only on
  the ports they own.  (Means for implementing ownership is a local
  issue, but we envision a Request Port user command, or a method of
  uniquely allocating a group of ports to a given process, e.g., by
  associating the high order bits of a port name with a given process.)

  A connection is specified in the OPEN call by the local port and
  foreign socket arguments.  In return, the TCP supplies a (short) local


[Page 10]                                                               


September 1981                                                          
                                           Transmission Control Protocol
                                                              Philosophy



  connection name by which the user refers to the connection in
  subsequent calls.  There are several things that must be remembered
  about a connection.  To store this information we imagine that there
  is a data structure called a Transmission Control Block (TCB).  One
  implementation strategy would have the local connection name be a
  pointer to the TCB for this connection.  The OPEN call also specifies
  whether the connection establishment is to be actively pursued, or to
  be passively waited for.

  A passive OPEN request means that the process wants to accept incoming
  connection requests rather than attempting to initiate a connection.
  Often the process requesting a passive OPEN will accept a connection
  request from any caller.  In this case a foreign socket of all zeros
  is used to denote an unspecified socket.  Unspecified foreign sockets
  are allowed only on passive OPENs.

  A service process that wished to provide services for unknown other
  processes would issue a passive OPEN request with an unspecified
  foreign socket.  Then a connection could be made with any process that
  requested a connection to this local socket.  It would help if this
  local socket were known to be associated with this service.

  Well-known sockets are a convenient mechanism for a priori associating
  a socket address with a standard service.  For instance, the
  "Telnet-Server" process is permanently assigned to a particular
  socket, and other sockets are reserved for File Transfer, Remote Job
  Entry, Text Generator, Echoer, and Sink processes (the last three
  being for test purposes).  A socket address might be reserved for
  access to a "Look-Up" service which would return the specific socket
  at which a newly created service would be provided.  The concept of a
  well-known socket is part of the TCP specification, but the assignment
  of sockets to services is outside this specification.  (See [4].)

  Processes can issue passive OPENs and wait for matching active OPENs
  from other processes and be informed by the TCP when connections have
  been established.  Two processes which issue active OPENs to each
  other at the same time will be correctly connected.  This flexibility
  is critical for the support of distributed computing in which
  components act asynchronously with respect to each other.

  There are two principal cases for matching the sockets in the local
  passive OPENs and an foreign active OPENs.  In the first case, the
  local passive OPENs has fully specified the foreign socket.  In this
  case, the match must be exact.  In the second case, the local passive
  OPENs has left the foreign socket unspecified.  In this case, any
  foreign socket is acceptable as long as the local sockets match.
  Other possibilities include partially restricted matches.



                                                               [Page 11]


                                                          September 1981
Transmission Control Protocol
Philosophy



  If there are several pending passive OPENs (recorded in TCBs) with the
  same local socket, an foreign active OPEN will be matched to a TCB
  with the specific foreign socket in the foreign active OPEN, if such a
  TCB exists, before selecting a TCB with an unspecified foreign socket.

  The procedures to establish connections utilize the synchronize (SYN)
  control flag and involves an exchange of three messages.  This
  exchange has been termed a three-way hand shake [3].

  A connection is initiated by the rendezvous of an arriving segment
  containing a SYN and a waiting TCB entry each created by a user OPEN
  command.  The matching of local and foreign sockets determines when a
  connection has been initiated.  The connection becomes "established"
  when sequence numbers have been synchronized in both directions.

  The clearing of a connection also involves the exchange of segments,
  in this case carrying the FIN control flag.

2.8.  Data Communication

  The data that flows on a connection may be thought of as a stream of
  octets.  The sending user indicates in each SEND call whether the data
  in that call (and any preceeding calls) should be immediately pushed
  through to the receiving user by the setting of the PUSH flag.

  A sending TCP is allowed to collect data from the sending user and to
  send that data in segments at its own convenience, until the push
  function is signaled, then it must send all unsent data.  When a
  receiving TCP sees the PUSH flag, it must not wait for more data from
  the sending TCP before passing the data to the receiving process.

  There is no necessary relationship between push functions and segment
  boundaries.  The data in any particular segment may be the result of a
  single SEND call, in whole or part, or of multiple SEND calls.

  The purpose of push function and the PUSH flag is to push data through
  from the sending user to the receiving user.  It does not provide a
  record service.

  There is a coupling between the push function and the use of buffers
  of data that cross the TCP/user interface.  Each time a PUSH flag is
  associated with data placed into the receiving user's buffer, the
  buffer is returned to the user for processing even if the buffer is
  not filled.  If data arrives that fills the user's buffer before a
  PUSH is seen, the data is passed to the user in buffer size units.

  TCP also provides a means to communicate to the receiver of data that
  at some point further along in the data stream than the receiver is


[Page 12]                                                               


September 1981                                                          
                                           Transmission Control Protocol
                                                              Philosophy



  currently reading there is urgent data.  TCP does not attempt to
  define what the user specifically does upon being notified of pending
  urgent data, but the general notion is that the receiving process will
  take action to process the urgent data quickly.

2.9.  Precedence and Security

  The TCP makes use of the internet protocol type of service field and
  security option to provide precedence and security on a per connection
  basis to TCP users.  Not all TCP modules will necessarily function in
  a multilevel secure environment; some may be limited to unclassified
  use only, and others may operate at only one security level and
  compartment.  Consequently, some TCP implementations and services to
  users may be limited to a subset of the multilevel secure case.

  TCP modules which operate in a multilevel secure environment must
  properly mark outgoing segments with the security, compartment, and
  precedence.  Such TCP modules must also provide to their users or
  higher level protocols such as Telnet or THP an interface to allow
  them to specify the desired security level, compartment, and
  precedence of connections.

2.10.  Robustness Principle

  TCP implementations will follow a general principle of robustness:  be
  conservative in what you do, be liberal in what you accept from
  others.

  





















                                                               [Page 13]


                                                          September 1981
Transmission Control Protocol






















































[Page 14]                                                               


September 1981                                                          
                                           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|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            TCP Header 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.