doc: Add RFC documents

1 files changed, 5185 insertions, 0 deletions

diff --git a/doc/rfc/rfc761.txt b/doc/rfc/rfc761.txt
new file mode 100644
index 0000000..6e02a8d
--- /dev/null
+++ b/doc/rfc/rfc761.txt
@@ -0,0 +1,5185 @@
+
+
+RFC: 761
+IEN: 129
+                                    
+                                    
+                                    
+                                    
+                                    
+                                    
+                                    
+                              DOD STANDARD
+                                    
+                     TRANSMISSION CONTROL PROTOCOL
+                                    
+                                    
+                                    
+                              January 1980
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              prepared for
+                                    
+               Defense Advanced Research Projects Agency
+                Information Processing Techniques Office
+                         1400 Wilson Boulevard
+                       Arlington, Virginia  22209
+
+
+
+
+
+
+
+                                   by
+
+                     Information Sciences Institute
+                   University of Southern California
+                           4676 Admiralty Way
+                   Marina del Rey, California  90291
+
+January 1980                                                            
+                                           Transmission Control Protocol
+
+
+
+                           TABLE OF CONTENTS
+
+    PREFACE ........................................................ iii
+
+1.  INTRODUCTION ..................................................... 1
+
+  1.1  Motivation .................................................... 1
+  1.2  Scope ......................................................... 2
+  1.3  About This Document ........................................... 2
+  1.4  Interfaces .................................................... 3
+  1.5  Operation ..................................................... 3
+
+2.  PHILOSOPHY ....................................................... 7
+
+  2.1  Elements of the Internetwork System ........................... 7
+  2.2  Model of Operation ............................................ 7
+  2.3  The Host Environment .......................................... 8
+  2.4  Interfaces .................................................... 9
+  2.5  Relation to Other Protocols ................................... 9
+  2.6  Reliable Communication ....................................... 10
+  2.7  Connection Establishment and Clearing ........................ 10
+  2.8  Data Communication ........................................... 12
+  2.9  Precedence and Security ...................................... 13
+  2.10 Robustness Principle ......................................... 13
+
+3.  FUNCTIONAL SPECIFICATION ........................................ 15
+
+  3.1  Header Format ................................................ 15
+  3.2  Terminology .................................................. 19
+  3.3  Sequence Numbers ............................................. 24
+  3.4  Establishing a connection .................................... 29
+  3.5  Closing a Connection ......................................... 35
+  3.6  Precedence and Security ...................................... 38
+  3.7  Data Communication ........................................... 38
+  3.8  Interfaces ................................................... 42
+  3.9  Event Processing ............................................. 52
+
+GLOSSARY ............................................................ 75
+
+REFERENCES .......................................................... 83
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page i]
+
+
+                                                            January 1980
+Transmission Control Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page ii]                                                               
+
+
+January 1980                                                            
+                                           Transmission Control Protocol
+
+
+
+                                PREFACE
+
+
+
+This document describes the DoD Standard Transmission Control Protocol
+(TCP).  There have been eight earlier editions of the ARPA TCP
+specification on which this standard is based, and the present text
+draws heavily from them.  There have been many contributors to this work
+both in terms of concepts and in terms of text.  This edition
+incorporates the addition of security, compartmentation, and precedence
+concepts into the TCP specification.
+
+                                                           Jon Postel
+
+                                                           Editor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                              [Page iii]
+
+
+January 1980 
+RFC:761
+IEN:129
+Replaces:  IENs 124, 112,
+81, 55, 44, 40, 27, 21, 5
+
+                              DOD STANDARD
+
+                     TRANSMISSION CONTROL PROTOCOL
+
+
+
+                            1.  INTRODUCTION
+
+The Transmission Control Protocol (TCP) is intended for use as a highly
+reliable host-to-host protocol between hosts in packet-switched computer
+communication networks, and especially in interconnected systems of such
+networks.
+
+This document describes the functions to be performed by the
+Transmission Control Protocol, the program that implements it, and its
+interface to programs or users that require its services.
+
+1.1.  Motivation
+
+  Computer communication systems are playing an increasingly important
+  role in military, government, and civilian environments.  This
+  document primarily focuses its attention on military computer
+  communication requirements, especially robustness in the presence of
+  communication unreliability and availability in the presence of
+  congestion, but many of these problems are found in the civilian and
+  government sector as well.
+
+  As strategic and tactical computer communication networks are
+  developed and deployed, it is essential to provide means of
+  interconnecting them and to provide standard interprocess
+  communication protocols which can support a broad range of
+  applications.  In anticipation of the need for such standards, the
+  Deputy Undersecretary of Defense for Research and Engineering has
+  declared the Transmission Control Protocol (TCP) described herein to
+  be a basis for DoD-wide inter-process communication protocol
+  standardization.
+
+  TCP is a connection-oriented, end-to-end reliable protocol designed to
+  fit into a layered hierarchy of protocols which support multi-network
+  applications.  The TCP provides for reliable inter-process
+  communication between pairs of processes in host computers attached to
+  distinct but interconnected computer communication networks.  Very few
+  assumptions are made as to the reliability of the communication
+  protocols below the TCP layer.  TCP assumes it can obtain a simple,
+  potentially unreliable datagram service from the lower level
+  protocols.  In principle, the TCP should be able to operate above a
+  wide spectrum of communication systems ranging from hard-wired
+  connections to packet-switched or circuit-switched networks.
+
+
+                                                                [Page 1]
+
+
+                                                            January 1980
+Transmission Control Protocol
+Introduction
+
+
+
+  TCP is based on concepts first described by Cerf and Kahn in [1].  The
+  TCP fits into a layered protocol architecture just above a basic
+  Internet Protocol [2] which provides a way for the TCP to send and
+  receive variable-length segments of information enclosed in internet
+  datagram "envelopes".  The internet datagram provides a means for
+  addressing source and destination TCPs in different networks.  The
+  internet protocol also deals with any fragmentation or reassembly of
+  the TCP segments required to achieve transport and delivery through
+  multiple networks and interconnecting gateways.  The internet protocol
+  also carries information on the precedence, security classification
+  and compartmentation of the TCP segments, so this information can be
+  communicated end-to-end across multiple networks.
+
+                           Protocol Layering
+
+                        +---------------------+
+                        |     higher-level    |
+                        +---------------------+
+                        |        TCP          |
+                        +---------------------+
+                        |  internet protocol  |
+                        +---------------------+
+                        |communication network|
+                        +---------------------+
+
+                                Figure 1
+
+  Much of this document is written in the context of TCP implementations
+  which are co-resident with higher level protocols in the host
+  computer.  As a practical matter, many computer systems will be
+  connected to networks via front-end computers which house the TCP and
+  internet protocol layers, as well as network specific software.  The
+  TCP specification describes an interface to the higher level protocols
+  which appears to be implementable even for the front-end case, as long
+  as a suitable host-to-front end protocol is implemented.
+
+1.2.  Scope
+
+  The TCP is intended to provide a reliable process-to-process
+  communication service in a multinetwork environment.  The TCP is
+  intended to be a host-to-host protocol in common use in multiple
+  networks.
+
+1.3.  About this Document
+
+  This document represents a specification of the behavior required of
+  any TCP implementation, both in its interactions with higher level
+  protocols and in its interactions with other TCPs.  The rest of this
+
+
+[Page 2]                                                                
+
+
+January 1980                                                            
+                                           Transmission Control Protocol
+                                                            Introduction
+
+
+
+  section offers a very brief view of the protocol interfaces and
+  operation.  Section 2 summarizes the philosophical basis for the TCP
+  design.  Section 3 offers both a detailed description of the actions
+  required of TCP when various events occur (arrival of new segments,
+  user calls, errors, etc.) and the details of the formats of TCP
+  segments.
+
+1.4.  Interfaces
+
+  The TCP interfaces on one side to user or application processes and on
+  the other side to a lower level protocol such as Internet Protocol.
+
+  The interface between an application process and the TCP is
+  illustrated in reasonable detail.  This interface consists of a set of
+  calls much like the calls an operating system provides to an
+  application process for manipulating files.  For example, there are
+  calls to open and close connections and to send and receive letters on
+  established connections.  It is also expected that the TCP can
+  asynchronously communicate with application programs.  Although
+  considerable freedom is permitted to TCP implementors to design
+  interfaces which are appropriate to a particular operating system
+  environment, a minimum functionality is required at the TCP/user
+  interface for any valid implementation.
+
+  The interface between TCP and lower level protocol is essentially
+  unspecified except that it is assumed there is a mechanism whereby the
+  two levels can asynchronously pass information to each other.
+  Typically, one expects the lower level protocol to specify this
+  interface.  TCP is designed to work in a very general environment of
+  interconnected networks.  The lower level protocol which is assumed
+  throughout this document is the Internet Protocol [2].
+
+1.5.  Operation
+
+  As noted above, the primary purpose of the TCP is to provide reliable,
+  securable logical circuit or connection service between pairs of
+  processes.  To provide this service on top of a less reliable internet
+  communication system requires facilities in the following areas:
+
+    Basic Data Transfer
+    Reliability
+    Flow Control
+    Multiplexing
+    Connections
+    Precedence and Security
+
+  The basic operation of the TCP in each of these areas is described in
+  the following paragraphs.
+
+
+                                                                [Page 3]
+
+
+                                                            January 1980
+Transmission Control Protocol
+Introduction
+
+
+
+  Basic Data Transfer:
+
+    The TCP is able to transfer a continuous stream of octets in each
+    direction between its users by packaging some number of octets into
+    segments for transmission through the internet system.  In this
+    stream mode, the TCPs decide when to block and forward data at their
+    own convenience.
+
+    For users who desire a record-oriented service, the TCP also permits
+    the user to submit records, called letters, for transmission.  When
+    the sending user indicates a record boundary (end-of-letter), this
+    causes the TCPs to promptly forward and deliver data up to that
+    point to the receiver.
+
+  Reliability:
+
+    The TCP must recover from data that is damaged, lost, duplicated, or
+    delivered out of order by the internet communication system.  This
+    is achieved by assigning a sequence number to each octet
+    transmitted, and requiring a positive acknowledgment (ACK) from the
+    receiving TCP.  If the ACK is not received within a timeout
+    interval, the data is retransmitted.  At the receiver, the sequence
+    numbers are used to correctly order segments that may be received
+    out of order and to eliminate duplicates.  Damage is handled by
+    adding a checksum to each segment transmitted, checking it at the
+    receiver, and discarding damaged segments.
+
+    As long as the TCPs continue to function properly and the internet
+    system does not become completely partitioned, no transmission
+    errors will affect the users.  TCP recovers from internet
+    communication system errors.
+
+  Flow Control:
+
+    TCP provides a means for the receiver to govern the amount of data
+    sent by the sender.  This is achieved by returning a "window" with
+    every ACK indicating a range of acceptable sequence numbers beyond
+    the last segment successfully received.  For stream mode, the window
+    indicates an allowed number of octets that the sender may transmit
+    before receiving further permission.  For record mode, the window
+    indicates an allowed amount of buffer space the sender may consume,
+    this may be more than the number of data octets transmitted if there
+    is a mismatch between letter size and buffer size.
+
+
+
+
+
+
+
+[Page 4]                                                                
+
+
+January 1980                                                            
+                                           Transmission Control Protocol
+                                                            Introduction
+
+
+
+  Multiplexing:
+
+    To allow for many processes within a single Host to use TCP
+    communication facilities simultaneously, the TCP provides a set of
+    addresses or ports within each host.  Concatenated with the network
+    and host addresses from the internet communication layer, this forms
+    a socket.  A pair of sockets uniquely identifies each connection.
+    That is, a socket may be simultaneously used in multiple
+    connections.
+
+    The binding of ports to processes is handled independently by each
+    Host.  However, it proves useful to attach frequently used processes
+    (e.g., a "logger" or timesharing service) to fixed sockets which are
+    made known to the public.  These services can then be accessed
+    through the known addresses.  Establishing and learning the port
+    addresses of other processes may involve more dynamic mechanisms.
+
+  Connections:
+
+    The reliability and flow control mechanisms described above require
+    that TCPs initialize and maintain certain status information for
+    each data stream.  The combination of this information, including
+    sockets, sequence numbers, and window sizes, is called a connection.
+    Each connection is uniquely specified by a pair of sockets
+    identifying its two sides.
+
+    When two processes wish to communicate, their TCP's must first
+    establish a connection (initialize the status information on each
+    side).  When their communication is complete, the connection is
+    terminated or closed to free the resources for other uses.
+
+    Since connections must be established between unreliable hosts and
+    over the unreliable internet communication system, a handshake
+    mechanism with clock-based sequence numbers is used to avoid
+    erroneous initialization of connections.
+
+  Precedence and Security:
+
+    The users of TCP may indicate the security and precedence of their
+    communication.  Provision is made for default values to be used when
+    these features are not needed.
+
+    
+
+
+
+
+
+
+
+                                                                [Page 5]
+
+
+                                                            January 1980
+Transmission Control Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 6]                                                                
+
+
+January 1980                                                            
+                                           Transmission Control Protocol
+
+
+
+                             2.  PHILOSOPHY
+
+2.1.  Elements of the Internetwork System
+
+  The internetwork environment consists of hosts connected to networks
+  which are in turn interconnected via gateways.  It is assumed here
+  that the networks may be either local networks (e.g., the ETHERNET) or
+  large networks (e.g., the ARPANET), but in any case are based on
+  packet switching technology.  The active agents that produce and
+  consume messages are processes.  Various levels of protocols in the
+  networks, the gateways, and the hosts support an interprocess
+  communication system that provides two-way data flow on logical
+  connections between process ports.
+
+  We specifically assume that data is transmitted from host to host
+  through means of a set of  networks.  When we say network, we have in
+  mind a packet switched network (PSN).  This assumption is probably
+  unnecessary, since a circuit switched network or a hybrid combination
+  of the two could also be used; but for concreteness, we explicitly
+  assume that the hosts are connected to one or more packet switches of
+  a PSN.
+
+  The term packet is used generically here to mean the data of one
+  transaction between a host and a packet switch.  The format of data
+  blocks exchanged between the packet switches in a network will
+  generally not be of concern to us.
+
+  Hosts are computers attached to a network, and from the communication
+  network's point of view, are the sources and destinations of packets.
+  Processes are viewed as the active elements in host computers (in
+  accordance with the fairly common definition of a process as a program
+  in execution).  Even terminals and files or other I/O devices are
+  viewed as communicating with each other through the use of processes.
+  Thus, all communication is viewed as inter-process communication.
+
+  Since a process may need to distinguish among several communication
+  streams between itself and another process (or processes), we imagine
+  that each process may have a number of ports through which it
+  communicates with the ports of other processes.
+
+2.2.  Model of Operation
+
+  Processes transmit data by calling on the TCP and passing buffers of
+  data as arguments.  The TCP packages the data from these buffers into
+  segments and calls on the internet module to transmit each segment to
+  the destination TCP.  The receiving TCP places the data from a segment
+  into the receiving user's buffer and notifies the receiving user.  The
+  TCPs include control information in the segments which they use to
+  ensure reliable ordered data transmission.
+
+
+                                                                [Page 7]
+
+
+                                                            January 1980
+Transmission Control Protocol
+Philosophy
+
+
+
+  The model of internet communication is that there is an internet
+  protocol module associated with each TCP which provides an interface
+  to the local network.  This internet module packages TCP segments
+  inside internet datagrams and routes these datagrams to a destination
+  internet module or intermediate gateway.  To transmit the datagram
+  through the local network, it is embedded in a local network packet.
+
+  The packet switches may perform further packaging, fragmentation, or
+  other operations to achieve the delivery of the local packet to the
+  destination internet module.
+
+  At a gateway between networks, the internet datagram is "unwrapped"
+  from its local packet and examined to determine through which network
+  the internet datagram should travel next.  The internet datagram is
+  then "wrapped" in a local packet suitable to the next network and
+  routed to the next gateway, or to the final destination.
+
+  A gateway is permitted to break up an internet datagram into smaller
+  internet datagram fragments if this is necessary for transmission
+  through the next network.  To do this, the gateway produces a set of
+  internet datagrams; each carrying a fragment.  Fragments may be broken
+  into smaller ones at intermediate gateways.  The internet datagram
+  fragment format is designed so that the destination internet module
+  can reassemble fragments into internet datagrams.
+
+  A destination internet module unwraps the segment from the datagram
+  (after reassembling the datagram, if necessary) and passes it to the
+  destination TCP.
+
+  This simple model of the operation glosses over many details.  One
+  important feature is the type of service.  This provides information
+  to the gateway (or internet module) to guide it in selecting the
+  service parameters to be used in traversing the next network.
+  Included in the type of service information is the precedence of the
+  datagram.  Datagrams may also carry security information to permit
+  host and gateways that operate in multilevel secure environments to
+  properly segregate datagrams for security considerations.
+
+2.3.  The Host Environment
+
+  The TCP is assumed to be a module in a time sharing operating system.
+  The users access the TCP much like they would access the file system.
+  The TCP may call on other operating system functions, for example, to
+  manage data structures.  The actual interface to the network is
+  assumed to be controlled by a device driver module.  The TCP does not
+  call on the network device driver directly, but rather calls on the
+  internet datagram protocol module which may in turn call on the device
+  driver.
+
+
+[Page 8]                                                                
+
+
+January 1980                                                            
+                                           Transmission Control Protocol
+                                                              Philosophy
+
+
+
+  Though it is assumed here that processes are supported by the host
+  operating system, the mechanisms of TCP do not preclude implementation
+  of the TCP in a front-end processor.  However, in such an
+  implementation, a host-to-front-end protocol must provide the
+  functionality to support the type of TCP-user interface described
+  above.
+
+2.4.  Interfaces
+
+  The TCP/user interface provides for calls made by the user on the TCP
+  to OPEN or CLOSE a connection, to SEND or RECEIVE data, or to obtain
+  STATUS about a connection.  These calls are like other calls from user
+  programs on the operating system, for example, the calls to open, read
+  from, and close a file.
+
+  The TCP/internet interface provides calls to send and receive
+  datagrams addressed to TCP modules in hosts anywhere in the internet
+  system.  These calls have parameters for passing the address, type of
+  service, precedence, security, and other control information.
+
+2.5.  Relation to Other Protocols
+
+  The following diagram illustrates the place of the TCP in the protocol
+  hierarchy:
+
+                                    
+       +------+ +-----+ +-----+       +-----+                    
+       |Telnet| | FTP | |Voice|  ...  |     |  Application Level 
+       +------+ +-----+ +-----+       +-----+                    
+             |   |         |             |                       
+            +-----+     +-----+       +-----+                    
+            | TCP |     | RTP |  ...  |     |  Host Level        
+            +-----+     +-----+       +-----+                    
+               |           |             |                       
+            +-------------------------------+                    
+            |      Internet Protocol        |  Gateway Level     
+            +-------------------------------+                    
+                           |                                     
+              +---------------------------+                      
+              |   Local Network Protocol  |    Network Level     
+              +---------------------------+                      
+                           |                                     
+
+
+
+                         Protocol Relationships
+
+                               Figure 2.
+
+
+                                                                [Page 9]
+
+
+                                                            January 1980
+Transmission Control Protocol
+Philosophy
+
+
+
+  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 [3] 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.
+
+  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 the sequence number 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, 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 into a TCP, a flow control mechanism is
+  employed.  The the data receiving TCP reports a window to the sending
+  TCP.  This window specifies the number of octets, starting with the
+  acknowledgment number that the data 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 operating system, TCP, or user, they might not
+  be unique.  To provide for unique addresses at 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 seem necessary in any implementation.
+
+
+[Page 10]                                                               
+
+
+January 1980                                                            
+                                           Transmission Control Protocol
+                                                              Philosophy
+
+
+
+  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 only initiate connections 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
+  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 could 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 might be permanently assigned to a particular
+  socket, and other sockets might be 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.
+
+  Processes can issue passive OPENs and wait for matching calls from
+  other processes and be informed by the TCP when connections have been
+  established.  Two processes which issue calls to each other at the
+  same time are correctly connected.  This flexibility is critical for
+
+
+
+                                                               [Page 11]
+
+
+                                                            January 1980
+Transmission Control Protocol
+Philosophy
+
+
+
+  the support of distributed computing in which components act
+  asynchronously with respect to each other.
+
+  There are two cases for matching the sockets in the local request and
+  an incoming segment.  In the first case, the local request has fully
+  specified the foreign socket.  In this case, the match must be exact.
+  In the second case, the local request has left the foreign socket
+  unspecified.  In this case, any foreign socket is acceptable as long
+  as the local sockets match.
+
+  If there are several pending passive OPENs (recorded in TCBs) with the
+  same local socket, an incoming segment should be matched to a request
+  with the specific foreign socket in the segment, if such a request
+  exists, before selecting a request with an unspecified foreign socket.
+
+  The procedures to establish and clear connections utilize synchronize
+  (SYN) and finis (FIN) control flags and involve an exchange of three
+  messages.  This exchange has been termed a three-way hand shake [4].
+
+  A connection is initiated by the rendezvous of an arriving segment
+  containing a SYN and a waiting TCB entry 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, or as a sequence of records.  In TCP the records are called
+  letters and are of variable length.  The sending user indicates in
+  each SEND call whether the data in that call completes a letter by the
+  setting of the end-of-letter parameter.
+
+  The length of a letter may be such that it must be broken into
+  segments before it can be transmitted to its destination.  We assume
+  that the segments will normally be reassembled into a letter before
+  being passed to the receiving process.  A segment may contain all or a
+  part of a letter, but a segment never contains parts of more than one
+  letter.  The end of a letter is marked by the appearance of an EOL
+  control flag in a segment.  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 end of letter is signaled then it must send all
+  unsent data.  When a receiving TCP has a complete letter, it must not
+  wait for more data from the sending TCP before passing the letter to
+  the receiving process.
+
+
+[Page 12]                                                               
+
+
+January 1980                                                            
+                                           Transmission Control Protocol
+                                                              Philosophy
+
+
+
+  There is a coupling between letters as sent and the use of buffers of
+  data that cross the TCP/user interface.  Each time an end-of-letter
+  (EOL) 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 a letter is longer than the user's buffer,
+  the letter is passed to the user in buffer size units, the last of
+  which may be only partly full.  The receiving TCP's buffer size may be
+  communicated to the sending TCP when the connection is being
+  established.
+
+  The TCP is responsible for regulating the flow of segments on the
+  connections, as a way of preventing itself from becoming saturated or
+  overloaded with traffic.  This is done using a window flow control
+  mechanism.  The data receiving TCP reports to the data sending TCP a
+  window which is the range of sequence numbers of data octets that data
+  receiving TCP is currently prepared to accept.
+
+  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
+  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
+  should take action to read through the end 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 should
+  properly mark outgoing segments with the security, compartment, and
+  precedence.  Such TCP modules should 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 should follow a general principle of robustness:
+  be conservative in what you do, be liberal in what you accept from
+  others.
+
+  
+
+
+                                                               [Page 13]
+
+
+                                                            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]
+
+
+                                                            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:
+
+        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, RFC 760, 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 84]                                                               
+