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]
`
`Google Ex. 1012, pg 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
` reformatting or embedding, and may also implement congestion and
` error control between the TCP and GATEWAYS at or intermediate to the
` destination TCP.
`
`Cerf, Dalal & Sunshine [Page 2]
`
`Google Ex. 1012, pg 2
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
` At a GATEWAY between networks, the internetwork packet is unwrapped
` from its local packet format and examined to determine through which
` network the internetwork packet should travel next. The internetwork
` packet is then wrapped in a local packet format suitable to the next
` network and passed on to a new packet switch.
`
` A GATEWAY is permitted to break up the fragment carried by an
` internetwork packet into smaller fragments if this is necessary for
` transmission through the next network. To do this, the GATEWAY
` produces a set of internetwork packets, each carrying a new fragment.
` The packet format is designed so that the destination TCP may treat
` fragments created by the source TCP or by intermediate GATEWAYS
` nearly identically.
`
` The TCP is responsible for regulating the flow of internetwork
` packets to and from the processes it serves, as a way of preventing
` its host from becoming saturated or overloaded with traffic. The TCP
` is also responsible for retransmitting unacknowledged packets, and
` for detecting duplicates. A consequence of this error
` detection/retransmission scheme is that the order of letters received
` on a given connection is also maintained [CEKA74, SUNS74]. To perform
` these functions, the TCP opens and closes connections between ports
` as described in Section 4.3. The TCP performs retransmission,
` duplicate detection, sequencing, and flow control on all
` communication among the processes it serves.
`
`2. The TCP INTERFACE to the USER
`
`2.1 The TCP as a POST OFFICE
`
` The TCP acts in many ways like a postal service since it provides a
` way for processes to exchange letters with each other. It sometimes
` happens that a process may offer some service, but not know in
` advance what its correspondents’ addresses are. The analogy can be
` drawn with a mail order house which opens a post office box which can
` accept mail from any source. Unlike the post box, however, once a
` letter from a particular correspondent arrives, a port becomes
` specific to the correspondent until the owner of the port declares
` otherwise.
`
` In addition to acting like a postal service, the TCP insures end-to-
` end acknowledgment, error correction, duplicate detection,
` sequencing, and flow control.
`
`Cerf, Dalal & Sunshine [Page 3]
`
`Google Ex. 1012, pg 3
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
`2.2 Sockets and Addressing
`
` We have borrowed the term SOCKET from the ARPANET terminology
` [CACR70, MCKE73]. In general, a socket is the concatenation of a
` NETWORK identifier, TCP identifier, and PORT identifier. A CONNECTION
` is fully specified by the pair of SOCKETS at each end since the same
` local socket may participate in many connections to different foreign
` sockets.
`
` Once the connections is specified in the OPEN command [see section
` 2.3.2], the TCP supplies a [short] Local Connection Name by which the
` user refers to the connection in subsequent commands. In particular
` this facilitates using connections with initially unspecified foreign
` sockets.
`
` TCP’s are free to associate ports with processes however they choose.
` However, several basic concepts seem necessary in an implementation.
` There must be well known sockets [WKS] which the TCP associates only
` with the "appropriate" processes by some means. We envision that
` processes may "own" sockets, and that processes can only initiate
` connections on the sockets they own [means for implementing ownership
` is a local issue, but we envision a Request Port user call, 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.]
`
` Once initiated, a connection may be passed to another process that
` does not own the local socket [e.g. from logger to service process].
` Strictly speaking this is a reconnection issue which might be more
` elegantly handled by a general reconnection protocol as discussed in
` section 3.3. To simplify passing a connection within a single TCP,
` such "invisible" switches may be allowed as in TENEX systems.
`
` Of course, each connection is associated with exactly one process,
` and any attempt to reference that connection by another process will
` be signaled as an error by the TCP. This prevents stealing data from
` or inserting data into another process’ data stream.
`
` A connection is initiated by the rendezvous of an arriving
` internetwork packet and a waiting Transmission Control Block [TCB]
` created by a user OPEN, SEND, INTERPUPT, or RECEIVE call [see section
` 2.3]. The matching of local and foreign socket identifiers determines
` when a successful connection has been initiated. The connection
` becomes established when sequence numbers have been synchronized in
` both directions as described in section 4.3.2.
`
`Cerf, Dalal & Sunshine [Page 4]
`
`Google Ex. 1012, pg 4
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
` It is possible to specify a socket only partially by setting the PORT
` identifier to zero or setting both the TCP and PORT identifiers to
` zero. A socket of all zero is called UNSPECIFIED. The purpose behind
` unspecified sockets is to provide a sort of "general delivery"
` facility [useful for logger type processes with well known sockets].
`
` There are bounds on the degree of unspecificity of socket
` identifiers. TCB’s must have fully specified local sockets, although
` the foreign socket may be fully or partly unspecified. Arriving
` packets must have fully specified sockets.
`
` We employ the following notation:
`
` x.y.z = fully specified socket with x=net, y=TCP, z=port
`
` x.y.u = as above, but unspecified port
`
` x.u.u = as above, but unspecified TCP and port
`
` u.u.u = completely unspecified
`
` with respect to implementation, u = 0 [zero]
`
` We illustrate the principles of matching by giving all cases of
` incoming packets which match with existing TCB’s. Generally, both
` the local (foreign) socket of the TCB and the foreign (local) socket
` of the packet must match.
`
` TCB local TCB foreign Packet local Packet foreign
`
` (a) a.b.c e.f.g e.f.g a.b.c
`
` (b) a.b.c e.f.u e.f.g a.b.c
`
` (c) a.b.c e.u.u e.f.g a.b.c
`
` (d) a.b.c u.u.u e.f.g a.b.c
`
` There are no other legal combinations of socket identifiers which
` match. Case (d) is typical of the ARPANET well known socket idea in
` which the well known socket (a.b.c) LISTENS for a connection from
` any (u.u.u) socket. Cases (b) and (c) can be used to restrict
` matching to a particular TCP or net.
`
`Cerf, Dalal & Sunshine [Page 5]
`
`Google Ex. 1012, pg 5
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
`2.3 TCP USER CALLS
`
`2.3.1 A Note on Style
`
` The following sections functionally define the 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. SVC’s, UUO’s, EMT’s,...].
`
` The user calls described below specify the basic functions the TCP
` will perform to support interprocess communication. Individual
` implementations should define their own exact format, and may
` provide combinations or subsets of the basic functions in single
` calls. In particular, some implementations may wish to automatically
` OPEN a connection on the first SEND, RECEIVE, or INTERRUPT issued by
` the user for a given connection.
`
` In providing interprocess communication facilities, the TCP must not
` only accept commands, but also return information to the processes
` it serves. This communication consists of:
`
` (a) general information about a connection [interrupts, remote
` close, binding of unspecified foreign socket].
`
` (b) replies to specific user commands indicating success or various
` types of failure.
`
` Although the means for signaling user processes and the exact format
` of replies will vary from one implementation to another, it would
` promote common understanding and testing if a common set of codes
` were adopted. Such a set of Event Codes is described in section 2.4.
`
` With respect to error messages, references to "local" and "foreign"
` are ambiguous unless it is known whether these refer to the world as
` seen by the sender or receiver of the error message. The authors
` attempted several different approaches and finally settled on the
` convention that these references would be as seen by the receiver of
` the message.
`
`2.3.2 OPEN CONNECTION
`
` Format: OPEN(local port, foreign socket [, timeout])
`
` 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 source network and TCP identifiers will either be
` supplied by the TCP or by the processes that serve it [e.g. the
`
`Cerf, Dalal & Sunshine [Page 6]
`
`Google Ex. 1012, pg 6
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
` program which interfaces the TCP to its packet switch or the packet
` switch itself]. 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 no foreign socket is specified [i.e. the foreign socket parameter
` is 0 or not present], then this constitutes a LISTENING local socket
` which can accept communication from any foreign socket. Provision is
` also made for partial specification of foreign sockets as described
` in section 2.2.
`
` If the specified connection is already OPEN, an error is returned,
` otherwise a full-duplex transmission control block [TCB] is created
` and partially filled in with data from the OPEN command parameters.
` The TCB format is described in more detail in section 4.2.2.
`
` No network traffic is generated by the OPEN command. The first SEND
` or INTERRUPT by the local user or the foreign user will cause the TCP
` to synchronize the connection.
`
` The timeout, if present, permits the caller to set up a timeout for
` all letters transmitted on the connection. If a letter is not
` successfully transmitted within the timeout period, the user is
` notified and may ignore the condition [TCP will continue trying to
` transmit] or direct the TCP to close the connection. The present
` global default is 30 seconds, and connections which are set up
` without specifying another timeout will retransmit every letter for
` at least 30 seconds before notifying the user. The retransmission
` rate may vary, and is the responsibility of the TCP and not the user.
` Most likely, it will be related to the measured time for responses to
` return from letters sent.
`
` 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.
`
` Responses from the TCP which may occur as a result of this call are
` detailed in section 2.4.
`
`2.3.3 SEND LETTER
`
` Format: SEND(local connection name, buffer address, byte count, EOL
` flag [, timeout])
`
`Cerf, Dalal & Sunshine [Page 7]
`
`Google Ex. 1012, pg 7
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
` 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 packet created from the buffer. If the
` EOL f1ag is not set, subsequent SEND’s will appear as part of the
` same letter. This extended letter facility should be used sparingly
` because some TCP’s may delay processing packets until an entire
` letter is received.
`
` 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 letter arriving for the local port] then the
` designated letter 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 the timeout is specified, then the current default timeout for
` this connection is changed to the new one. This can affect not only
` all letters sent including and after this one, but also those which
` have not yet been sent, since the timeout is kept in the TCB and not
` associated with each letter sent. Of course, a time is maintained for
` each internetwork packet formed so as to determine how long each of
` these has been on the retransmission queue.
`
` 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. This simple method is highly subject to
` deadlocks and is not recommended. [For example both sides of the
` connection try to do SEND’s before doing any RECEIVE’s.] 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 concurrently. Multiple SENDs
` are served in first come, first served order, so the TCP will queue
` those it cannot service immediately.
`
`Cerf, Dalal & Sunshine [Page 8]
`
`Google Ex. 1012, pg 8
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
` NOTA BENE: In order for the process to distinguish among error or
` success indications for different letters, the buffer address should
` be returned along with the coded response to the SEND request. We
` will offer an example event code format in section 2.4, showing the
` information which should be returned to the calling process.
`
` The semantics of the INTERRUPT call are described later, but this
` call can have an effect on letters which have been given to the TCP
` but not yet sent. In particular, all such letters are flushed by the
` source TCP. Thus one of the responses to a SEND may be "flushed due
` to interrupt."
`
` Responses from the TCP which may occur as a result of this call are
` detailed in section 2.4.
`
`2.3.4 RECEIVE LETTER
`
` 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 a letter was received, or some error
` occurred, but this scheme is highly subject to deadlocks [see section
` 2.3.3]. A more sophisticated implementation would permit several
` RECEIVE’s to be outstanding at once, These would be filled as letters
` 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.
`
` If insufficient buffer space is given to reassemble a complete
` letter, an indication that the buffer holds a partial letter will be
` given; the buffer will be filled with as much data as it can hold.
`
` 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 event codes
` associated with each RECEIVE will indicate what is contained in the
` buffer.
`
` To distinguish among several outstanding RECEIVES, and to take care
` of the case that a letter is smaller than the buffer supplied, the
` event code is accompanied by both a buffer pointer and a byte count
` indicating the actual length of the letter received.
`
`Cerf, Dalal & Sunshine [Page 9]
`
`Google Ex. 1012, pg 9
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
` The semantics of the INTERRUPT system call are discussed later, but
` this call can have an effect on outstanding RECEIVES. When the TCP
` receives an INTERRUPT, it will flush all data currently queued up
` awaiting receipt by the receiving process. If no data is waiting, but
` several buffers have been made available by anticipatory RECEIVE
` commands, these buffers are returned to the process with an error
` indicating that any data that might have been placed in those buffers
` has been flushed. This enables the receiving process to synchronize
` its RECEIVES with the interrupt. That is, the process can distinguish
` between RECEIVES issued before the receipt of the INTERRUPT and these
` issued afterwards.
`
` Responses from the TCP which may occur as a result of this call are
` detailed in section 2.4.
`
`2.3.5 CLOSE CONNECTION
`
` 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. Any unfilled receive
` buffers or pending send buffers will be returned to the user with
` event codes indicating they were aborted due to the CLOSE. Users
` should wait for event codes for each SEND before closing the
` connection if they wish to be certain that all letters were
` successfully delivered.
`
` The user may CLOSE the connection at any time on his own initiative,
` or in response to various prompts from the TCP [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 errors.
`
` Responses from the TCP which may occur as a result of this call are
` detailed in section 2.4.
`
`2.3.6 INTERRUPT
`
` Format: INTERRUPT(local connection name)
`
` A special control signal is sent to the destination indicating an
` interrupt condition. This facility can be used to simulate "break"
` signals from terminals or error or completion codes from I/O devices,
` for example. The semantics of this signal to the receiving process
`
`Cerf, Dalal & Sunshine [Page 10]
`
`Google Ex. 1012, pg 10
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
` are unspecified. The receiving TCP will signal the interrupt to the
` receiving process immediately upon receipt, and will also flush any
` outstanding letters waiting to be delivered. Since it is possib1e to
` tell where in the letter stream this command was invoked, it is
` possible for the receiving TCP to flush only preceding data. The
` sending TCP will flush any letters pending transmission, returning a
` special error code to indicate the flush.
`
` If the connection is not open or the calling process is not
` authorized to use this connection, an error is returned.
`
` Responses from the TCP which may occur as a result of this call are
` detailed in section 2.4.
`
`2.3.7 STATUS
`
` Format: STATUS(local connection name)
`
` 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 letters awaiting
` acknowledgment, number of letters pending receipt [including partial
` ones], default transmission timeout
`
` Depending on the state of the connection, 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.
`
` Responses from the TCP which may occur as a result of this call are
` detailed in section 2.4.
`
`2.4 TCP TO USER MESSAGES
`
`2.4.1 TYPE CODES
`
` All messages include a type code which identifies the type of user
` call to which the message applies. Types are:
`
` 0 - General message, does not apply to a particular user call
`
` 1 - Applies to OPEN
`
` 2 - Applies to CLOSE
`
`Cerf, Dalal & Sunshine [Page 11]
`
`Google Ex. 1012, pg 11
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
` 3 - Applies to INTERRUPT
`
` 10 - Applies to SEND
`
` 20 - Applies to RECEIVE
`
` 30 - Applies to STATUS
`
`2.4.2 MESSAGE FORMAT [notional]
`
` All messages include the following three fields:
`
` Type code
`
` Local connection name
`
` Event code
`
` For message types 0-3 [General, Open, Close, Interrupt] only these
` three fields are necessary.
`
` For message type 10 [Send] one additional field is necessary:
`
` Buffer address
`
` For message type 20 [Receive] three additional fields are necessary:
`
` Buffer address
`
` Byte count
`
` End-of-letter flag
`
` For message type 30 [status] additional data might include;
`
` Local socket, foreign socket
`
` Send window [measures buffer space at foreign TCP]
`
` Receive window [measures buffer space at local TCP]
`
` Connection state [see section 4.3.6]
`
` Number of letters awaiting acknowledgment
`
` Number of letters awaiting receipt
`
` Retransmission timeout
`
`Cerf, Dalal & Sunshine [Page 12]
`
`Google Ex. 1012, pg 12
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
`2.4.3 EVENT CODES
`
` The event code specifies the particular event that the TCP wishes to
` communicate to the user.
`
` In addition to the event code, three flags may be useful to classify
` the event into major categories and facilitate event processing by
` the user:
`
` E flag: set if event is an error
`
` L/F flag: indicates whether event was generated by Local TCP, or
` Foreign TCP or network
`
` P/T flag: indicates whether the event is Permanent or Temporary
` [retry may succeed]
`
` Events are encoded into 8 bits with the high order bits set to
` indicate the state of the E, L/F, and P/T flags, respectively.
`
` Events specified so far are listed below with their codes and flag
` settings. A * means a flag does not apply or can take both values for
` this event. Additional events may be defined in the course of
` experimentation.
`
` 0 0** general success
`
` 1 ELP connection illegal for this process
`
` 2 OF* unspecified foreign socket has become bound
`
` 3 ELP connection not open
`
` 4 ELT no room for TCB
`
` 5 ELT foreign socket unspecified
`
` 6 ELP connection already open
` EFP unacceptable SYN [or SYN/ACK] arrived at foreign
` TCP. Note: This is not a misprint, the local meaning is different
` from foreign.
`
` 7 EFP connection does not exist at foreign TCP
`
` 8 EFT foreign TCP inaccessible [may have subcases]
`
` 9 ELT retransmission timeout
`
`Cerf, Dalal & Sunshine [Page 13]
`
`Google Ex. 1012, pg 13
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
` 10 E*P buffer flushed due to interrupt
`
` 11 OF* interrupt to user
`
` 12 **P connection closing
`
` 13 E** general error
`
` 14 E*P connection reset
`
` Possible events for each message type are as follows:
`
` Type 0[general]: 2,11,12,14
`
` Type 1[open]: 0,1,4,6,13
`
` Type 2[close]: 0,1,3,13
`
` Type 3[interrupt]: 0,1,3,5,7,8,9,12,13
`
` Type 10[send]: 0,1,3,5,7,8,9,10,11,12,13
`
` Type 20[receive]: 0,1,3,10,12,13
`
` Type 30[status]: 0,1,13
`
` Note that events 6(foreign), 7, 8 are generated at the foreign TCP or
` in the network[s], and these same codes are used in the error field
` of the internet packet [see section 4.2.1].
`
`3. HIGHER LEVEL PROTOCOLS
`
`3.1 INTRODUCTION
`
` It is envisioned that the TCP will be able to support higher level
` protocols efficiently. It should be easy to interface existing
` ARPANET protocols like TELNET and FTP to the TCP.
`
`3.2 WELL KNOWN SOCKETS
`
` At some point, a set of well known 24 bit port numbers must be
` picked. The type of service associated with the well known ports
` might include:
`
` (a) Logger
`
` (b) FTP (File transfer protocol)
`
`Cerf, Dalal & Sunshine [Page 14]
`
`Google Ex. 1012, pg 14
`
`

`

`RFC 675 Specification of Internet TCP December 1974
`
` (c) RJE (Remote job entry)
`
` (d) Host status
`
` (e) TTY Test
`
` (f) HELP - descriptive, interactive system documentation
`
` WE RESERVE WELL KNOWN SOCKET 0 (24 bits of 0) for global messages
` destined for a particular TCP but not related to any particular
` connection. We imagine that this socket would be used for unusual TCP
` synchronization (e.g. RESET ALL) or for testing purposes (e.g.
` sending letters to TRASHCAN or ECHO). This does not conflict with the
` usage that if a socket is 0, it is unspecified, since no user can
` SEND, CLOSE, or INTERRUPT on socket 0.
`
`3.3 RECONNECTION PROTOCOL (RCP)
`
` Port identifiers fall into two categories: permanent and transient.
` For example, a Logger process is generally assigned a port identifier
` that is fixed and well known. Transient processes will in general
` have ID’s which are dynamically assigned.
`
` In the distributed processing environment of the network, two
` processes that don’t have well known port identifiers may often wish
` to communicate. This can be achieved with the help of a well known
` process using a reconnection protocol. Such a protocol is briefly
` outlined using the communication facilities provided by the TCP. It
` essentially provides a mechanism by which port identifiers are
` exch