brian@sdcsvax.UCSD.EDU (Brian Kantor) (08/26/87)
CLOSE-WAIT STATE Do the same processing as for the ESTABLISHED state. CLOSING STATE In addition to the processing for the ESTABLISHED state, if the ACK acknowledges our FIN then enter the TIME-WAIT state, otherwise ignore the segment. LAST-ACK STATE The only thing that can arrive in this state is an acknowledgment of our FIN. If our FIN is now acknowledged, delete the TCB, enter the CLOSED state, and return. 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. 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. [Page 73] September 1981 Transmission Control Protocol Functional Specification SEGMENT ARRIVES CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT This should not occur, since a FIN has been received from the remote side. Ignore the URG. seventh, process the segment text, ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 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 PUSH flag, then the user is informed, when the buffer is returned, that a PUSH has been received. When the TCP takes responsibility for delivering the data to the user it must also acknowledge the receipt of the data. Once the TCP takes responsibility for the data it advances RCV.NXT over the data accepted, and adjusts RCV.WND as apporopriate to the current buffer availability. The total of RCV.NXT and RCV.WND should not be reduced. Please note the window management suggestions in section 3.7. Send an acknowledgment of the form: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> This acknowledgment should be piggybacked on a segment being transmitted if possible without incurring undue delay. [Page 74] September 1981 Transmission Control Protocol Functional Specification SEGMENT ARRIVES CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-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, Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT since the SEG.SEQ cannot be validated; drop the segment and return. If the FIN bit is set, signal the user "connection closing" and return any pending RECEIVEs with same message, advance RCV.NXT over the FIN, and send an acknowledgment for the FIN. Note that FIN implies PUSH for any segment text not yet delivered to the user. SYN-RECEIVED STATE ESTABLISHED STATE Enter the CLOSE-WAIT state. FIN-WAIT-1 STATE If our FIN has been ACKed (perhaps in this segment), then enter TIME-WAIT, start the time-wait timer, turn off the other timers; otherwise enter the CLOSING state. FIN-WAIT-2 STATE Enter the TIME-WAIT state. Start the time-wait timer, turn off the other timers. CLOSE-WAIT STATE Remain in the CLOSE-WAIT state. CLOSING STATE Remain in the CLOSING state. LAST-ACK STATE Remain in the LAST-ACK state. [Page 75] September 1981 Transmission Control Protocol Functional Specification SEGMENT ARRIVES TIME-WAIT STATE Remain in the TIME-WAIT state. Restart the 2 MSL time-wait timeout. and return. [Page 76] September 1981 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, enter the CLOSED state 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. TIME-WAIT TIMEOUT If the time-wait timeout expires on a connection delete the TCB, enter the CLOSED state and return. [Page 77] September 1981 Transmission Control Protocol [Page 78] September 1981 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). 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. 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. [Page 79] September 1981 Transmission Control Protocol Glossary 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. 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. [Page 80] September 1981 Transmission Control Protocol Glossary 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. 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 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. PUSH A control bit occupying no sequence space, indicating that this segment contains data that must be pushed through to the receiving user. RCV.NXT receive next sequence number [Page 81] September 1981 Transmission Control Protocol Glossary RCV.UP receive urgent pointer RCV.WND receive window 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. 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. SEG.ACK segment acknowledgment SEG.LEN segment length SEG.PRC segment precedence value SEG.SEQ segment sequence SEG.UP segment urgent pointer field [Page 82] September 1981 Transmission Control Protocol Glossary 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. segment sequence The number in the sequence field of the arriving segment. 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 new sequence numbers which may be emitted by a TCP lies between SND.NXT and SND.UNA + SND.WND - 1. (Retransmissions of sequence numbers between SND.UNA and SND.NXT are expected, of course.) SND.NXT send sequence SND.UNA left sequence SND.UP send urgent pointer SND.WL1 segment sequence number at last window update SND.WL2 segment acknowledgment number at last window update [Page 83] September 1981 Transmission Control Protocol Glossary 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. 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 84] September 1981 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.), "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, USC/Information Sciences Institute, September 1981. [3] Dalal, Y. and C. Sunshine, "Connection Management in Transport Protocols", Computer Networks, Vol. 2, No. 6, pp. 454-473, December 1978. [4] Postel, J., "Assigned Numbers", RFC 790, USC/Information Sciences Institute, September 1981. [Page 85]