As per Relevance of the word knowledge, we have this rfc below:
Reliable Data
RFC-908
David
Robert
Jack
BBN Communications
July 1984
Status of This
This RFC specifies a proposed protocol for the ARPA
community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
RDP Specification
Table of
1 Introduction.......................................... 1
2 General Description................................... 3
2.1 Motivation.......................................... 3
2.2 Relation to Other Protocols......................... 5
3 Protocol Operation.................................... 7
3.1 Protocol Service Objectives......................... 7
3.2 RDP Connection Management........................... 7
3.2.1 Opening a Connection.............................. 8
3.2.2 Ports............................................. 8
3.2.3 Connection States................................. 8
3.2.4 Connection Record................................ 11
3.2.5 Closing a Connection............................. 13
3.2.6 Detecting an Half-Open Connection................ 14
3.3 Data Communication................................. 14
3.4 Reliable Communication............................. 15
3.4.1 Segment Sequence Numbers......................... 15
3.4.2 Checksums........................................ 16
3.4.3 Positive Acknowledgement of Segments............. 16
3.4.4 Retransmission Timeout........................... 17
3.5 Flow Control and Window Management................. 17
3.6 User Interface..................................... 19
3.7 Event Processing................................... 20
3.7.1 User Request Events.............................. 21
3.7.2 Segment Arrival Events........................... 24
3.7.3 Timeout Events................................... 29
4 RDP Segments and Formats............................. 31
4.1 IP Header Format................................... 31
4.2 RDP Header Format.................................. 32
4.2.1 RDP Header Fields................................ 33
4.3 SYN Segment........................................ 36
4.3.1 SYN Segment Format............................... 36
4.3.2 SYN Segment Fields............................... 37
4.4 ACK Segment........................................ 38
4.4.1 ACK Segment Format............................... 38
4.4.2 ACK Segment Fields............................... 39
4.5 Extended ACK Segment............................... 40
4.5.1 EACK Segment Format.............................. 40
4.5.2 EACK Segment Fields.............................. 40
Page
RFC-908 July 1984
4.6 RST Segment........................................ 42
4.6.1 RST Segment Format............................... 42
4.7 NUL Segment........................................ 43
4.7.1 NUL segment format............................... 43
5 Examples of Operation................................ 45
5.1 Connection Establishment........................... 45
5.2 Simultaneous Connection Establishment.............. 46
5.3 Lost Segments...................................... 47
5.4 Segments Received Out of Order..................... 48
5.5 Communication Over Long Delay Path................. 49
5.6 Communication Over Long Delay Path With
.................................................... 50
5.7 Detecting a Half-Open Connection on
.................................................... 51
5.8 Detecting a Half-Open Connection from
Active
.................................................... 52
A Implementing a Minimal RDP........................... 53
Page
RDP Specification
1 Relation to Other Protocols............................ 5
2 Form of Data Exchange Between Layers................... 6
3 RDP Connection State Diagram.......................... 10
4 Segment Format........................................ 31
5 RDP Header Format..................................... 32
6 SYN Segment Format.................................... 37
7 ACK Segment Format.................................... 38
8 EACK Segment Format................................... 41
9 RST Segment Format.................................... 42
10 NUL Segment Format................................... 43
Page
CHAPTER 1
The Reliable Data Protocol (RDP) is designed to provide
reliable data transport service for packet-based
such as remote loading and debugging. The protocol is
to be simple to implement but still be efficient in
where there may be long transmission delays and loss or non
sequential delivery of message segments
Although this protocol was designed with applications
as remote loading and debugging in mind, it may be suitable
other applications that require reliable message services,
as computer mail, file transfer, transaction processing, etc
Some of the concepts used come from a variety of sources
The authors wish credit to be given to Eric Rosen, Rob Gurwitz
Jack Haverty, and to acknowledge material adapted from "RFC-793,
The Transmission Control Protocol", edited by Jon Postel.
to John Linn for the checksum algorithm
Page 1
RFC-908 July 1984
Page 2
RDP Specification General
CHAPTER 2
General
2.1
RDP is a transport protocol designed to efficiently
the bulk transfer of data for such host monitoring and
applications as loading/dumping and remote debugging.
attempts to provide only those services necessary, in order to
efficient in operation and small in size. Before designing
protocol, it was necessary to consider what minimum set
transport functions would satisfy the requirements of
intended applications
The following is a list of requirements for such a
protocol
o Reliable delivery of packets is required. When
or dumping a memory image, it is necessary that
memory segments be delivered. A 'hole' left in
memory image is not acceptable. However, the
environment is a lossy one in which packets can
damaged or lost. So a positive acknowledgement
retransmission mechanism is a necessary component of
protocol
o Since loading and dumping of memory images over
internet involves the bulk transfer of large amounts
data over a lossy network with potentially long delays
it is necessary that the protocol move data efficiently
In particular, unnecessary retransmission of
should be avoided. If a single segment has been lost
succeeding segments correctly received, the
should not require the retransmission of all of
segments
o Loading and dumping are applications that do
necessarily require sequenced delivery of segments,
long as all segments eventually are delivered. So
protocol need not force sequenced delivery. For
types of applications, segments may be delivered in
order in which they arrive
Page 3
RFC-908 July 1984
o However, some applications may need to know that
particular piece of data has been delivered
sending the next. For example, a debugger will want
know that a command inserting a breakpoint into a
memory image has been delivered before sending
"proceed" command. If those segments arrived out
sequence, the intended results would not be achieved
The protocol should allow a user to optionally
that a connection must deliver segments in sequence
number order
o The loading/dumping and debugging applications are well
defined and lend themselves to easy packetization of
transferred data. They do not require a complex byte
stream transfer mechanism
In order to combine the requirements for bulk transfers
data and reliable delivery, it is necessary to design
connection-oriented protocol using a three-way handshake
synchronize sequence numbers. The protocol seems to
approaching TCP in complexity, so why was TCP not, in fact
chosen? The answer is that TCP has some disadvantages for
applications. In particular
o TCP is oriented toward a more general environment
supporting the transfer of a stream of bytes between
communicating parties. TCP is best suited to
environment where there is no obvious demarcation of
in a communications exchange. Much of the difficulty
developing a TCP implementation stems from the
of supporting this general byte-stream transfer, and
a significant amount of complexity can be avoided
using another protocol. This is not just
implementation consideration, but also one of efficiency
o Since TCP does not allow a byte to be acknowledged
all prior bytes have been acknowledged, it often
unnecessary retransmission of data. Therefore, it
not meet another of the requirements stated above
o TCP provides sequenced delivery of data to
application. If the application does not require
sequenced delivery, a large amount of resources
wasted in providing it. For example, buffers may be
up buffering data until a segment with an
sequence number arrives. The protocol should not
its segment-sequencing desires on the application
Page 4
RDP Specification General
RDP supports a much simpler set of functions than TCP.
flow control, buffering, and connection management schemes of
are considerably simpler and less complex. The goal is
protocol that can be easily and efficiently implemented and
will serve a range of applications
RDP functions can also be subset to further reduce the
of a particular implementation. For example, a target
requiring down-loading from another host might implement an
module supporting only the passive Open function and a
connection. The module might also choose not to implement out
of-sequence acknowledgements
2.2 Relation to Other
RDP is a transport protocol that fits into the
internet protocol environment. Figure 1 illustrates the place
RDP in the protocol hierarchy
+------+ +-----+ +-----+ +------+
|TELNET| | FTP | |Debug| ... |Loader| Application
+------+ +-----+ +-----+ +------+
| | | |
+-----+----+ +------+------+
| |
+------+ +-------+
| TCP | | RDP | Transport
+------+ +-------+
| |
+--------------------------------+
| Internet Protocol & ICMP | Internetwork
+--------------------------------+
|
+-------------------------+
| Network Access Protocol | Network
+-------------------------+
Relation to Other
Figure 1
Page 5
RFC-908 July 1984
RDP provides the application layer with a reliable
transport service. The interface between users and RDP
data in units of messages. When implemented in the
environment, RDP is layered on the Internet Protocol (IP),
provides an unreliable datagram service to RDP. Data is
across the RDP/IP interface in the form of segments. RDP
the standard IP interface primitives to send and receive
segments as IP datagrams. At the internet level, IP
datagrams with the network layer. An internet packet may
an entire datagram or a fragment of a datagram
# %
? * !
@ )
+------+ +-----+ +----+ $ = ^ +
| |Messages | |Segments | | Datagrams *
| User |<------->| RDP |<------->| IP |<------->
| | | | | | , ?
+------+ +-----+ +----+ ! )
* % $
@ ^ !
Form of Data Exchange Between
Figure 2
If internetwork services are not required, it should
possible to use the RDP without the IP layer. As long as
encapsulating protocol provides the RDP with such
information as addressing and protocol demultiplexing, it
be possible to run RDP layered on a variety of
protocols
Page 6
RDP Specification Protocol
CHAPTER 3
Protocol
3.1 Protocol Service
The RDP protocol has the following goals
o RDP will provide a full-duplex communications
between the two ports of each transport connection
o RDP will attempt to reliably deliver all user
and will report a failure to the user if it
deliver a message. RDP extends the datagram service
IP to include reliable delivery
o RDP will attempt to detect and discard all damaged
duplicate segments. It will use a checksum and
number in each segment header to achieve this goal
o RDP will optionally provide sequenced delivery
segments. Sequenced delivery of segments must
specified when the connection is established
o RDP will acknowledge segments received out of sequence
as they arrive. This will free up resources on
sending side
3.2 RDP Connection
RDP is a connection-oriented protocol in which
connection acts as a full-duplex communication channel
two processes. Segments from a sender are directed to a port
the destination host. The two 8-bit source and destination
identifiers in the RDP header are used in conjunction with
network source and destination addresses to uniquely
each connection
Page 7
RFC-908 July 1984
3.2.1 Opening a
Connections are opened by issuing the Open request,
can be either active or passive. A passive Open request puts
into the Listen state, during which it passively listens for
request to open a connection from a remote site. The active
request attempts to establish a connection with a specified
at a remote site
The active Open request requires that a specific remote
and host address be specified with the request. The passive
may optionally specify a specific remote port and
address, or it may specify that an open be accepted from anyone
If a specific remote port and host address were specified,
arriving request to open a connection must exactly match
specified remote port and address
3.2.2
Valid port numbers range from 1 to 255 (decimal). There
two types of ports: "well known" ports and "allocable" ports
Well-known ports have numbers in the range 1 to 63 (decimal)
allocable ports are given numbers in the range 64 to 255.
The user, when issuing an active Open request, must
both the remote host and port and may optionally specify
local port. If the local port was not specified, RDP will
an unused port from the range of allocable ports. When issuing
passive Open request, the user must specify the local
number. Generally, in this case the local port will be a well
known port
3.2.3 Connection
An RDP connection will progress through a series of
during its lifetime. The states are shown in Figure 3 and
individually described below. In Figure 3, the boxes
the states of the RDP FSM and the arcs represent changes
state. Each arc is annotated with the event causing the
change and the resulting output
Page 8
RDP Specification Protocol
The CLOSED state exists when no connection exists and
is no connection record allocated
The LISTEN state is entered after a passive Open request
processed. A connection record is allocated and RDP
for an active request to establish a connection from
remote site
SYN-
The SYN-SENT state is entered after processing an
Open request. A connection record is allocated, an
sequence number is generated, and a SYN segment is sent
the remote site. RDP then waits in the SYN-SENT state
acknowledgement of its Open request
SYN-
The SYN-RCVD state may be reached from either the
state or from the SYN-SENT state. SYN-RCVD is reached
the LISTEN state when a SYN segment requesting a
is received from a remote host. In reply, the local
generates an initial sequence number for its side of
connection, and then sends the sequence number and
acknowledgement of the SYN segment to the remote site.
then waits for an acknowledgement
The SYN-RCVD state is reached from the SYN-SENT state when
SYN segment is received from the remote host without
accompanying acknowledgement of the SYN segment sent to
remote host by the local RDP. This situation is caused
simultaneous attempts to open a connection, with the
segments passing each other in transit. The action is
repeat the SYN segment with the same sequence number,
now including an ACK of the remote host's SYN segment
indicate acceptance of the Open request
Page 9
RFC-908 July 1984
+------------+
Passive Open | |<-------------------------+
+----------------| CLOSED | |
| Request | |---------------+ |
V +------------+ | |
+------------+ | |
| | | |
| LISTEN | | |
| | | |
+------------+ | |
| Active | |
| rcv SYN Open Request | |
| ----------- ------------ | |
| snd SYN,ACK snd SYN | |
V rcv SYN V |
+------------+ ----------- +------------+ |
| | snd SYN,ACK | | |
| SYN-RCVD |<-------------------------------| SYN-SENT | |
| | | | |
+------------+ +------------+ |
| rcv ACK rcv SYN,ACK | |
| ---------- ------------- | |
| xxx +------------+ snd ACK | |
| | | | |
+--------------->| OPEN |<--------------+ |
| | |
+------------+ |
rcv RST | Close request |
----------- | --------------- |
xxx | snd RST |
V |
+------------+ |
| | |
| CLOSE-WAIT |--------------------------+
| | After a
+------------+
RDP Connection State
Figure 3
Page 10
RDP Specification Protocol
The OPEN state exists when a connection has been
by the successful exchange of state information between
two sides of the connection. Each side has exchanged
received such data as initial sequence number,
segment size, and maximum number of unacknowledged
that may be outstanding. In the Open state data may be
between the two parties of the connection
CLOSE-
The CLOSE-WAIT state is entered from either a Close
or from the receipt of an RST segment from the remote site
RDP has sent an RST segment and is waiting a delay
for activity on the connection to complete
3.2.4 Connection
The variables that define the state of a connection
stored in a connection record maintained for each connection
The following describes some of the variables that would
stored in a typical RDP connection record. It is not intended
be an implementation specification nor is it a
description. The purpose of naming and describing some of
connection record fields is to simplify the description of
protocol operation, particularly event processing
The connection record fields and their descriptions follow
The current state of the connection. Legal values are OPEN
LISTEN, CLOSED, SYN-SENT, SYN-RCVD, and CLOSE-WAIT
Send Sequence Number Variables
SND.
The sequence number of the next segment that is to be sent
Page 11
RFC-908 July 1984
SND.
The sequence number of the oldest unacknowledged segment
SND.
The maximum number of outstanding (unacknowledged)
that can be sent. The sender should not send more than
number of segments without getting an acknowledgement
SND.
The initial send sequence number. This is the
number that was sent in the SYN segment
Receive Sequence Number Variables
RCV.
The sequence number of the last segment received
and in sequence
RCV.
The maximum number of segments that can be buffered for
connection
RCV.
The initial receive sequence number. This is the
number of the SYN segment that established this connection
RCVDSEQNO[n
The array of sequence numbers of segments that have
received and acknowledged out of sequence
Other Variables
A timer used to time out the CLOSE-WAIT state
SBUF.
The largest possible segment (in octets) that can legally
sent. This variable is specified by the foreign host in
Page 12
RDP Specification Protocol
SYN segment during connection establishment
RBUF.
The largest possible segment (in octets) that can
received. This variable is specified by the user when
connection is opened. The variable is sent to the
host in the SYN segment
Variables from Current Segment
SEG.
The sequence number of the segment currently
processed
SEG.
The acknowledgement sequence number in the segment
being processed
SEG.
The maximum number of outstanding segments the receiver
willing to hold, as specified in the SYN segment
established the connection
SEG.
The maximum segment size (in octets) accepted by the
host on a connection, as specified in the SYN segment
established the connection
3.2.5 Closing a
The closing of a connection can be initiated by a
request from the user process or by receipt of an RST
from the other end of the connection. In the case of the
request, RDP will send an RST segment to the other side of
connection and then enter the CLOSE-WAIT state for a period
time. While in the CLOSE-WAIT state, RDP will discard
received from the other side of the connection. When the time
out period expires, the connection record is deallocated and
connection ceases to exist. This simple connection
facility requires that users determine that all data has
Page 13
RFC-908 July 1984
reliably delivered before requesting a close of the connection
3.2.6 Detecting an Half-Open
If one side of a connection crashes, the connection may
left with the other side still active. This situation is
to be an half-open connection. For many cases, the active
will eventually detect the half-open connection and reset.
examples of recovery from half-open connections are provided
sections 5.7 and 5.8. Recovery is usually achieved by
activity or by the crashed host's attempts to re-establish
connection
However, there are cases where recovery is not
without action by the RDP itself. For example, if all
blocks are in use, attempts to re-establish a broken
will be rejected. In this case, the RDP may attempt to
resources by verifying that connections are fully open. It
this by sending a NUL segment to each of the other RDPs.
acknowledgement indicates the connection is still open and valid
To minimize network overhead, verification of
should only be done when necessary to prevent a
situation. Only inactive connections should be verified.
inactive connection is defined to be a connection that has
outstanding unacknowledged segments, has no segments in the
input or output queues, and that has not had any traffic for
period of time
3.3 Data
Data flows through an RDP connection in the form
segments. Each user message submitted with a Send request
packaged for transport as a single RDP segment. Each RDP
is packaged as an RDP header and one or more octets of data.
will not attempt to fragment a large user message into
segments and re-assemble the message on the receiving end.
differs from a byte-stream protocol such as TCP which
the transfer of an indeterminate length stream of data
ports, buffering data until it is requested by the receiver
Page 14
RDP Specification Protocol
At the RDP level, outgoing segments, as they are created
are queued as input to the IP layer. Each segment is held by
sending RDP until it is acknowledged by the foreign host
Incoming segments are queued as input to the user process
the user interface. Segments are acknowledged when they
been accepted by the receiving RDP
The receiving end of each connection specifies the
segment size it will accept. Any attempt by the sender
transmit a larger segment is an error. If RDP determines that
buffer submitted with a Send request exceeds the maximum
segment permitted on the connection, RDP will return an error
the user. In addition, RDP will abort a connection with an
segment if an incoming segment contains more data than
maximum acceptable segment size. No attempt will be made
recover from or otherwise overcome this error condition
If sequenced delivery of segments is necessary for
connection, the requirement must be stated when the connection
established. Sequenced delivery is specified when the
request is made. Sequenced delivery of segments will then be
mode of delivery for the life of the connection
3.4 Reliable
RDP implements a reliable message service through a
of mechanisms. These include the insertion of sequence
and checksums into segments, the positive acknowledgement
segment receipt, and timeout and retransmission of
segments
3.4.1 Segment Sequence
Each segment transporting data has a sequence number
uniquely identifies it among all other segments in the
connection. The initial sequence number is chosen when
connection is opened and is selected by reading a value from
monotonically increasing clock. Each time a segment
data is transmitted, the sequence number is incremented
Segments containing no data do not increment the sequence number
However, the SYN and NUL segments, which cannot contain data,
exceptions. The SYN segment is always sent with a
sequence number, the initial sequence number. The NUL segment
Page 15
RFC-908 July 1984
sent with the next valid sequence number
3.4.2
Each RDP segment contains a checksum to allow the
to detect damaged segments. RDP uses a non-linear
algorithm to compute a checksum that is 32-bits wide and
on data in units of four octets (32 bits). The area that
covered by the checksum includes both the RDP header and the
data area
If a segment contains a number of header and data
that is not an integral multiple of 4 octets, the last octet
padded on the right with zeros to form a 32-bit quantity
computation purposes. The padding zeros are not transmitted
part of the segment. While computing the checksum, the
field itself is replaced with zeros. The actual algorithm
described in Section 4.2.1.
3.4.3 Positive Acknowledgement of
RDP assumes it has only an unreliable datagram service
deliver segments. To guarantee delivery of segments in
environment, RDP uses positive acknowledgement and
of segments. Each segment containing data and the SYN and
segments are acknowledged when they are correctly received
accepted by the destination host. Segments containing only
acknowledgement are not acknowledged. Damaged segments
discarded and are not acknowledged. Segments are
when there is no timely acknowledgement of the segment by
destination host
RDP allows two types of acknowledgement. A
acknowledgement is used to acknowledge all segments up to
specified sequence number. This type of acknowledgement can
sent using fixed length fields within the RDP header
Specifically, the ACK control flag is set and the
acknowledged sequence number is placed in the
Number field
The extended or non-cumulative acknowledgement allows
receiver to acknowledge segments out of sequence. This type
acknowledgement is sent using the EACK control flag and
Page 16
RDP Specification Protocol
variable length fields in the RDP segment header. The
length header fields are used to hold the sequence numbers of
acknowledged out-of-sequence segments
The type of acknowledgement used is simply a function of
order in which segments arrive. Whenever possible, segments
acknowledged using the cumulative acknowledgement segment.
out-of-sequence segments are acknowledged using the
acknowledgement option
The user process, when initiating the connection,
restrict the type of acknowledgement used on the connection.
receiver may choose not to implement out-of-
acknowledgements. On the other hand, the sender may choose
ignore out-of-sequence acknowledgements
3.4.4 Retransmission
Segments may be lost in transmission for two reasons:
may be lost or damaged due to the effects of the
transmission media; or they may be discarded by the
RDP. The positive acknowledgement policy requires the
to acknowledge a segment only when the segment has been
received and accepted
To detect missing segments, the sending RDP must use
retransmission timer for each segment transmitted. The timer
set to a value approximating the transmission time of the
in the network. When an acknowledgement is received for
segment, the timer is cancelled for that segment. If the
expires before an acknowledgement is received for a segment,
segment is retransmitted and the timer is restarted
3.5 Flow Control and Window
RDP employs a simple flow control mechanism that is based
the number of unacknowledged segments sent and the
allowed number of outstanding (unacknowledged) segments.
RDP connection has an associated set of flow control
that include the maximum number of outstanding segments for
side of a connection. These parameters are specified when
connection is opened with the Open request, with each side of
connection specifying its own parameters. The parameters
Page 17
RFC-908 July 1984
passed from one host to another in the initial
segments
The values specified for these parameters should be based
the amount and size of buffers that the RDP is willing
allocate to a connection. The particular RDP implementation
set the parameters to values that are optimal for its
scheme. Once these parameters are set they remain
throughout the life of the connection
RDP employs the concept of a sequence number window
acceptable segment sequence numbers. The left edge of the
is the number of the last in-sequence acknowledged
number plus one. The right edge of the window is equal to
left edge plus twice the allowed maximum number of
segments. The allowed maximum number of outstanding segments
the number of segments the transmitting RDP software is
to send without receiving any acknowledgement
The flow control and window management parameters are
as follows. The RDP module in the transmitting host
segments until it reaches the connection's segment
specified by the receiving process. Once this limit is reached
the transmitting RDP module may only send a new segment for
acknowledged segment
When a received segment has a sequence number that
within the acceptance window, it is acknowledged. If
sequence number is equal to the left-hand edge (i.e., it is
next sequence number expected), the segment is acknowledged
a cumulative acknowledgement (ACK). The acceptance window
adjusted by adding one to the value of the edges. If
sequence number is within the acceptance window but is out
sequence, it is acknowledged with a non-
acknowledgement (EACK). The window is not adjusted, but
receipt of the out-of-sequence segment is recorded
When segments are acknowledged out of order,
transmitting RDP module must not transmit beyond the
window. This could occur if one segment is not acknowledged
all subsequent segments are received and acknowledged.
condition will fix the left edge of the window at the
number of the unacknowledged segment. As additional segments
transmitted, the next segment to be sent will approach
eventually overtake the right window edge. At this point
transmission of new segments will cease until the
segment is acknowledged
Page 18
RDP Specification Protocol
3.6 User
The user interface to RDP is implementation dependent
may use system calls, function calls or some other mechanism
The list of requests that follows is not intended to suggest
particular implementation
OPEN
Opens a connection. Parameters include type (active
passive), local port, remote port, remote host address
maximum segment size, maximum number of
segments, delivery mode (sequenced or non-sequenced).
connection id, including any allocated port number,
returned to the user
SEND
Sends a user message. Parameters include
identifier, buffer address and data count
RECEIVE
Receives a user message. Parameters include
identifier, buffer address and data count
CLOSE
Closes a specified connection. The single parameter is
connection identifier
STATUS
Returns the status of a connection. The parameters
the connection identifier and the address of the
buffer
Page 19
RFC-908 July 1984
3.7 Event
This section describes one possible sequence for
events. It is not intended to suggest a
implementation, but any actual implementation should vary
this description only in detail and not significantly
substance. The following are the kinds of events that may occur
USER
ARRIVING
Segment
Retransmission
Close-Wait
User request processing always terminates with a return
the caller, with a possible error indication. Error
are given as a character string. A delayed response is
possible in some situations and is returned to the user
whatever event or pseudo interrupt mechanism is available.
term "signal" is used to refer to delayed responses
Processing of arriving segments usually follows this
sequence: the sequence number is checked for validity and,
valid, the segment is queued and processed in sequence-
order. For all events, unless a state change is specified,
remains in the same state
Page 20
RDP Specification Protocol
3.7.1 User Request
The following scenarios demonstrate the processing of
caused by the issuance of user requests
Open
CLOSED
Create a connection
If none
Return "Error - insufficient resources
If passive
If local port not
Return "Error - local port not specified
Generate SND.
Set SND.NXT = SND.ISS + 1
SND.UNA = SND.
Fill in SND.MAX, RMAX.BUF from Open
Set State =
If active
If remote port not
Return "Error - remote port not specified
Generate SND.
Set SND.NXT = SND.ISS + 1
SND.UNA = SND.
Fill in SND.MAX, RMAX.BUF from Open
If local port not
Allocate a local
Send
Set State = SYN-
Return (local port, connection identifier
Page 21
RFC-908 July 1984
LISTEN
SYN-SENT
SYN-RCVD
OPEN
CLOSE-WAIT
Return "Error - connection already open
Close
OPEN
Send
Set State = CLOSE-
Start TIMWAIT
LISTEN
Set State =
Deallocate connection
SYN-RCVD
SYN-SENT
Send
Set State =
CLOSE-WAIT
Return "Error - connection closing
CLOSE
Return "Error - connection not open
Page 22
RDP Specification Protocol
Receive
OPEN
If Data is
Return with
Return with "no data"
LISTEN
SYN-RCVD
SYN-SENT
Return with "no data"
CLOSE
CLOSE-WAIT
Return "Error - connection not open
Send
OPEN
If SND.NXT < SND.UNA + SND.
Send
Set SND.NXT = SND.NXT + 1
Return "Error - insufficient resources to send data
LISTEN
SYN-RCVD
SYN-SENT
CLOSE
CLOSE-WAIT
Return "Error - connection not open
Status
Return with
Page 23
RFC-908 July 1984
State of connection (OPEN, LISTEN, etc.)
Number of segments
Number of segments received not given to
Maximum segment size for the send side of the
Maximum segment size for the receive side of the
3.7.2 Segment Arrival
The following scenarios describe the processing of the
caused by the arrival of a RDP segment from a remote host.
assumption is made that the segment was addressed to the
port associated with the connection record
If State =
If RST
Discard
If ACK or NUL
Send
Discard
Send
Discard
If State = CLOSE-
If RST
Set State =
Discard
Cancel TIMWAIT
Deallocate connection
Discard
Page 24
RDP Specification Protocol
If State =
If RST
Discard the
If ACK or NUL
Send
If SYN
Set RCV.CUR = SEG.
RCV.IRS = SEG.
SND.MAX = SEG.
SBUF.MAX = SEG.
Send
Set State = SYN-
If anything else (should never get here
Discard
If State = SYN-
If ACK
If RST clear and SEG.ACK != SND.
Send
Discard segment;
If RST
If ACK
Signal "Connection Refused
Set State =
Deallocate connection
Discard
Page 25
RFC-908 July 1984
If SYN
Set RCV.CUR = SEG.
RCV.IRS = SEG.
SND.MAX = SEG.
RBUF.MAX = SEG.
If ACK
Set SND.UNA = SEG.
State =
Send
Set State = SYN-
Send
If anything
Discard
If State = SYN-
If RCV.IRS < SEG.SEQ =< RCV.CUR + (RCV.MAX * 2)
Segment sequence number
Send
Discard
If RST
If passive
Set State =
Set State =
Signal "Connection Refused
Discard
Deallocate connection
Page 26
RDP Specification Protocol
If SYN
Send
Set State =
Signal "Connection Reset
Discard
Deallocate connection
If EACK
Send
Discard
If ACK
If SEG.ACK = SND.
Set State =
Send
Discard
Discard
If Data in segment or NUL
If the received segment is in
Copy the data (if any) to user
Set RCV.CUR=SEG.
Send
If out-of-sequence delivery
Copy the data (if any) to user
Send
...
Page 27
RFC-908 July 1984
If State =
If RCV.CUR < SEG.SEQ =< RCV.CUR + (RCV.MAX * 2)
Segment sequence number
Send
Discard segment and
If RST
Set State = CLOSE-
Signal "Connection Reset
If NUL
Set RCV.CUR=SEG.
Send
Discard
If SYN
Send
Set State =
Signal "Connection Reset
Discard
Deallocate connection
If ACK
If SND.UNA =< SEG.ACK < SND.
Set SND.UNA = SEG.
Flush acknowledged
If EACK
Flush acknowledged
Page 28
RDP Specification Protocol
If Data in
If the received segment is in
Copy the data to user
Set RCV.CUR=SEG.
Send
If out-of-sequence delivery
Copy the data to user
Send
...
3.7.3 Timeout
Timeout events occur when a timer expires and signals
RDP. Two types of timeout events can occur, as described below
RETRANSMISSION
If timeout on segment at head of retransmission
Resend the segment at head of
Restart the retransmission timer for the
Requeue the segment on retransmission
CLOSE-WAIT
Set State =
Deallocate connection
Page 29
RFC-908 July 1984
Page 30
RDP Specification RDP Segments and
CHAPTER 4
RDP Segments and
The segments sent by the application layer are
in headers by the transport, internet and network layers,
follows
+----------------+
| Network Access |
| Header |
+----------------+
| IP Header |
+----------------+
| RDP Header |
+----------------+
| D |
| A |
| T |
| A |
+----------------+
Segment
Figure 4
4.1 IP Header
When used in the internet environment, RDP segments are
using the version 4 IP header as described in RFC791, "
Protocol." The RDP protocol number is ??? (decimal). The time
to-live field should be set to a reasonable value for
network
All other fields should be set as specified in RFC-791.
Page 31
RFC-908 July 1984
4.2 RDP Header
Every RDP segment is prefaced with an RDP header.
format of the header is shown in Figure 5 below. The RDP
is variable in length and its size is indicated by a field in
fixed location within the header
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
|S|A|E|R|N| |Ver| Header |
0 |Y|C|A|S|U|0|No.| Length |
|N|K|K|T|L| | | |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
9 | Variable Header Area |
. .
. .
| |
+---------------+---------------+
RDP Header
Figure 5
Page 32
RDP Specification RDP Segments and
4.2.1 RDP Header
Control
This 8-bit field occupies the first octet of word one in
header. It is bit encoded with the following bits
defined
Bit # Bit Name
0 SYN Establish connection
synchronize sequence numbers
1 ACK Acknowledge field significant
2 EACK Non-cumulative (Extended) acknowledgement
3 RST Reset the connection
4 NUL This is a null (zero data length) segment
5 Unused
Note that the SYN and RST are sent as separate segments
may not contain any data. The ACK may accompany
message. The NUL segment must have a zero data length,
may be accompanied by ACK and EACK information. The
control bit is currently unused and is defined to be zero
Version
This field occupies bits 6-7 of the first octet.
contains the version number of the protocol described
this document. Current value is one (1).
Header
The length of the RDP header in units of two (2) octets
including this field. This field allows RDP to find
start of the Data field, given a pointer to the head of
segment. This field is 8 bits in length. For a
with no variable header section, the header length
will have the value 9.
Source and Destination
The Source and Destination Ports are used to identify
processes in the two hosts that are communicating with
other. The combination of the port identifiers with
source and destination addresses in the network
Page 33
RFC-908 July 1984
protocol header serves to fully qualify the connection
constitutes the connection identifier. This permits RDP
distinguish multiple connections between two hosts.
field is 8 bits in length, allowing port numbers from 0
255 (decimal).
Data
The length in octets of the data in this segment. The
length does not include the RDP header. This field is 16
bits in length
Sequence
The sequence number of this segment. This field is 32
in length
Acknowledgement
If the ACK bit is set in the header, this is the
number of the segment that the sender of this segment
received correctly and in sequence. Once a connection
established this should always be sent. This field is 32
bits in length
This field is a 32-bit checksum of the segment header
data. The algorithm description below includes
variables, the checksum accumulator and the
pointer. The checksum accumulator is an actual 32-
register in which the checksum is formed. The
pointer is included for purposes of description,
represent the operation of advancing through the data
octets (32-bits) at a time. It need not be maintained in
register by an implementation
1) The checksum pointer is set to zero, to correspond to
beginning of the area to be checksummed. The
accumulator is also initialized to zero before beginning
computation of the checksum
2) The 32-bit memory word located at the address
by the checksum pointer is added arithmetically to
checksum accumulator. Any carry propagated out of
checksum accumulator is ignored. The checksum field
is replaced with zeros when being added to the
Page 34
RDP Specification RDP Segments and
accumulator
3) The checksum accumulator is rotated left one
position. The checksum pointer is advanced to correspond
the address of the next 32-bit word in the segment
4) Steps 2 and 3 are repeated until the entire segment
been summed. If a segment contains a number of header
data octets that is not an integral multiple of 4 octets
the last octet is padded on the right with zeros to form
32-bit quantity for computation purposes
Variable Header
This area is used to transmit parameters for the SYN
EACK segments
Page 35
RFC-908 July 1984
4.3 SYN
The SYN is used to establish a connection and
sequence numbers between two hosts. The SYN segment
contains information to inform the remote host of the
number of segments the local RDP is willing to accept and
maximum segment size it can accept. The SYN may be combined
an ACK in a segment but is never combined with user data
4.3.1 SYN Segment
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |1|0|0|0|0|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length = 0 |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
9 | Max. # of Outstanding Segments
+---------------+---------------+
10 | Max. Segment Size |
+-------------------------------+
11 | Options Flag Field |
+---------------+---------------+
SYN Segment
Figure 6
Page 36
RDP Specification RDP Segments and
4.3.2 SYN Segment
Sequence
Contains the initial sequence number selected for
connection
Acknowledgement
This field is valid only if the ACK flag is set. In
case, this field will contain the sequence number of the
segment received from the other RDP
Maximum Number of Outstanding
The maximum number of segments that should be sent
getting an acknowledgement. This is used by the receiver
a means of flow control. The number is selected
connection initiation and may not be changed later in
life of the connection
Maximum Segment
The maximum size segment in octets that the sender
send. It informs the sender how big the receiver's
are. The specified size includes the length of the
header, RDP header, and data. It does not include
network access layer's header length
Options Flag
This field of two octets contains a set of options
that specify the set of optional functions that are
for this connection. The flags are defined as follows
Bit # Bit Name
0 SDM Sequenced delivery mode
The sequenced delivery mode flag specifies whether
of segments to the user is sequenced (delivered
sequence-number order) or non-sequenced (delivered
arrival order, regardless of sequence number). A value of 0
specifies non-sequenced delivery of segments, and a value
1 specifies sequenced delivery
Page 37
RFC-908 July 1984
4.4 ACK
The ACK segment is used to acknowledge in-sequence segments
It contains both the next send sequence number and
acknowledgement sequence number in the RDP header. The
segment may be sent as a separate segment, but it should
combined with data whenever possible. Data segments must
include the ACK bit and Acknowledgement Number field
4.4.1 ACK Segment
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|1|0|0|0|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
| |
| Data |
. .
. .
+---------------+---------------+
ACK Segment
Figure 7
Page 38
RDP Specification RDP Segments and
4.4.2 ACK Segment
Data
A non-zero Data Length field indicates that there is
present in the segment
Sequence
The value of the Sequence Number field is advanced to
next sequence number only if there is data present in
segment. An ACK segment without data does not use
number space
Acknowledgement
The Acknowledgement Number field contains the
number of the last segment received in sequential order
Page 39
RFC-908 July 1984
4.5 Extended ACK
The EACK segment is used to acknowledge segments
out of sequence. It contains the sequence numbers of one or
segments received with a correct checksum, but out of sequence
The EACK is always combined with an ACK in the segment,
the sequence number of the last segment received in sequence
The EACK segment may also include user data
4.5.1 EACK Segment
The 