Specification of Internet Transmission Control Program
RFC 675

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                        Vinton Cerf
Request for Comments: 675                                    Yogen Dalal
NIC: 2                                                     Carl Sunshine
INWG: 72                                                   December 1974

         SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM

                         December 1974 Version

1.  INTRODUCTION

   This document describes the functions to be performed by the
   internetwork Transmission Control Program [TCP] and its interface to
   programs or users that require its services. Several basic
   assumptions are made about process to process communication and these
   are listed here without further justification. The interested reader
   is referred to [CEKA74, TOML74, BELS74, DALA74, SUNS74] for further
   discussion.

   The authors would like to acknowledge the contributions of R.
   Tomlinson (three way handshake and Initial Sequence Number
   Selection), D. Belsnes, J. Burchfiel, M. Galland, R. Kahn, D. Lloyd,
   W. Plummer, and J. Postel all of whose good ideas and counsel have
   had a beneficial effect (we hope) on this protocol design.  In the
   early phases of the design work, R. Metcalfe, A. McKenzie, H.
   Zimmerman, G. LeLann, and M. Elie were most helpful in explicating
   the various issues to be resolved. Of course, we remain responsible
   for the remaining errors and misstatements which no doubt lurk in the
   nooks and crannies of the text.

   Processes are viewed as the active elements of all HOST computers in
   a network. Even terminals and files or other I/O media are viewed as
   communicating through the use of processes. Thus, all network
   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.

   Since port names are selected independently by each operating system,
   TCP, or user, they may not be unique. To provide for unique names at
   each TCP, we concatenate a NETWORK identifier, and a TCP identifier
   with a port name to create a SOCKET name which will be unique
   throughout all networks connected together.

Cerf, Dalal & Sunshine                                          [Page 1]
RFC 675              Specification of Internet TCP         December 1974

   A pair of sockets form a CONNECTION which can be used to carry data
   in either direction [i.e. full duplex]. The connection is uniquely
   identified by the <local socket, foreign socket> address pair, and
   the same local socket can participate in multiple connections to
   different foreign sockets [see Section 2.2].

   Processes exchange finite length LETTERS as a way of communicating;
   thus, letter boundaries are significant. However, the length of a
   letter may be such that it must be broken into FRAGMENTS before it
   can be transmitted to its destination. We assume that the fragments
   will normally be reassembled into a letter before being passed to the
   receiving process. Throughout this document, it is legitimate to
   assume that a fragment contains all or a part of a letter, but that a
   fragment never contains parts of more than one letter.

   We specifically assume that fragments are transmitted from Host to
   Host through means of a PACKET SWITCHING NETWORK [PSN] [ROWE70,
   POUZ73]. This assumption is probably unnecessary, since a circuit
   switched network could also be used, but for concreteness, we
   explicitly assume that the hosts are connected to one or more PACKET
   SWITCHES [PS] of a PSN [HEKA7O, POUZ74, SCWI71].

   Processes make use of the TCP by handing it letters. The TCP breaks
   these into fragments, if necessary, and then embeds each fragment in
   an INTERNETWORK PACKET. Each internetwork packet is in turn embedded
   in a LOCAL PACKET suitable for transmission from the host to one of
   its serving PS. The packet switches may perform further formatting or
   other operations to achieve the delivery of the local packet to the
   destination Host.

   The term LOCAL PACKET is used generically here to mean the formatted
   bit string exchanged between a host and a packet switch. The format
   of bit strings exchanged between the packet switches in a PSN will
   generally not be of concern to us. If an internetwork packet is
   destined for a TCP in a foreign PSN, the packet is routed to a
   GATEWAY which connects the origin PSN with an intermediate or the
   destination PSN. Routing of internetwork packets to the GATEWAY may
   be the responsibility of the source TCP or the local PSN, depending
   upon the PSN Implementation.

   One model of TCP operation is to imagine that there is a basic
   GATEWAY associated with each TCP which provides an interface to the
   local network. This basic GATEWAY performs routing and packet