including this field. This field allows RDP to find the
start of the Data field, given a pointer to the head of the
segment. This field is 8 bits in length. For a segment
with no variable header section, the header length field
will have the value 9.
Source and Destination Ports
The Source and Destination Ports are used to identify the
processes in the two hosts that are communicating with each
other. The combination of the port identifiers with the
source and destination addresses in the network access
Page 33
RFC-908 July 1984
protocol header serves to fully qualify the connection and
constitutes the connection identifier. This permits RDP to
distinguish multiple connections between two hosts. Each
field is 8 bits in length, allowing port numbers from 0 to
255 (decimal).
Data Length
The length in octets of the data in this segment. The data
length does not include the RDP header. This field is 16
bits in length.
Sequence Number
The sequence number of this segment. This field is 32 bits
in length.
Acknowledgement Number
If the ACK bit is set in the header, this is the sequence
number of the segment that the sender of this segment last
received correctly and in sequence. Once a connection is
established this should always be sent. This field is 32
bits in length.
Checksum
This field is a 32-bit checksum of the segment header and
data. The algorithm description below includes two
variables, the checksum accumulator and the checksum
pointer. The checksum accumulator is an actual 32-bit
register in which the checksum is formed. The checksum
pointer is included for purposes of description, to
represent the operation of advancing through the data four
octets (32-bits) at a time. It need not be maintained in a
register by an implementation.
1) The checksum pointer is set to zero, to correspond to the
beginning of the area to be checksummed. The checksum
accumulator is also initialized to zero before beginning the
computation of the checksum.
2) The 32-bit memory word located at the address referenced
by the checksum pointer is added arithmetically to the
checksum accumulator. Any carry propagated out of the
checksum accumulator is ignored. The checksum field itself
is replaced with zeros when being added to the checksum
Page 34
RDP Specification RDP Segments and Formats
accumulator.
3) The checksum accumulator is rotated left one bit
position. The checksum pointer is advanced to correspond to
the address of the next 32-bit word in the segment.
4) Steps 2 and 3 are repeated until the entire segment has
been summed. If a segment contains a number of header and
data octets that is not an integral multiple of 4 octets,
the last octet is padded on the right with zeros to form a
32-bit quantity for computation purposes.
Variable Header Area
This area is used to transmit parameters for the SYN and
EACK segments.
Page 35
RFC-908 July 1984
4.3 SYN Segment
The SYN is used to establish a connection and synchronize
sequence numbers between two hosts. The SYN segment also
contains information to inform the remote host of the maximum
number of segments the local RDP is willing to accept and the
maximum segment size it can accept. The SYN may be combined with
an ACK in a segment but is never combined with user data.
4.3.1 SYN Segment Format
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 Format
Figure 6
Page 36
RDP Specification RDP Segments and Formats
4.3.2 SYN Segment Fields
Sequence Number
Contains the initial sequence number selected for this
connection.
Acknowledgement Number
This field is valid only if the ACK flag is set. In that
case, this field will contain the sequence number of the SYN
segment received from the other RDP.
Maximum Number of Outstanding Segments
The maximum number of segments that should be sent without
getting an acknowledgement. This is used by the receiver as
a means of flow control. The number is selected during
connection initiation and may not be changed later in the
life of the connection.
Maximum Segment Size
The maximum size segment in octets that the sender should
send. It informs the sender how big the receiver's buffers
are. The specified size includes the length of the IP
header, RDP header, and data. It does not include the
network access layer's header length.
Options Flag Field
This field of two octets contains a set of options flags
that specify the set of optional functions that are desired
for this connection. The flags are defined as follows:
Bit # Bit Name Description
0 SDM Sequenced delivery mode.
The sequenced delivery mode flag specifies whether delivery
of segments to the user is sequenced (delivered in
sequence-number order) or non-sequenced (delivered in
arrival order, regardless of sequence number). A value of 0
specifies non-sequenced delivery of segments, and a value of
1 specifies sequenced delivery.
Page 37
RFC-908 July 1984
4.4 ACK Segment
The ACK segment is used to acknowledge in-sequence segments.
It contains both the next send sequence number and the
acknowledgement sequence number in the RDP header. The ACK
segment may be sent as a separate segment, but it should be
combined with data whenever possible. Data segments must always
include the ACK bit and Acknowledgement Number field.
4.4.1 ACK Segment Format
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 Format
Figure 7
Page 38
RDP Specification RDP Segments and Formats
4.4.2 ACK Segment Fields
Data Length
A non-zero Data Length field indicates that there is data
present in the segment.
Sequence Number
The value of the Sequence Number field is advanced to the
next sequence number only if there is data present in the
segment. An ACK segment without data does not use sequence
number space.
Acknowledgement Number
The Acknowledgement Number field contains the sequence
number of the last segment received in sequential order.
Page 39
RFC-908 July 1984
4.5 Extended ACK Segment
The EACK segment is used to acknowledge segments received
out of sequence. It contains the sequence numbers of one or more
segments received with a correct checksum, but out of sequence.
The EACK is always combined with an ACK in the segment, giving
the sequence number of the last segment received in sequence.
The EACK segment may also include user data.
4.5.1 EACK Segment Format
The EACK segment has the format shown in Figure 8.
4.5.2 EACK Segment Fields
Data Length
A non-zero Data Length field indicates that there is data
present in the segment.
Sequence Number
The value of the Sequence Number field is advanced to the
next sequence number only if there is data present in the
segment. An EACK segment without data does not use sequence
number space.
Acknowledgement Number
The Acknowledgement Number field contains the sequence
number of the last segment received in sequential order.
Sequence # Received OK
Each entry is the sequence number of a segment that was
received with a correct checksum, but out of sequence.
Page 40
RDP Specification RDP Segments and Formats
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|1|1|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 | |
+---------------+---------------+
9 | |
+--- Sequence # Received OK ---+
10 | |
+---------------+---------------+
11 | |
+--- Sequence # Received OK ---+
12 | |
+---------------+---------------+
: . :
: . :
: . :
+---------------+---------------+
| |
| Data |
| |
+---------------+---------------+
EACK Segment Format
Figure 8
Page 41
RFC-908 July 1984
4.6 RST Segment
The RST segment is used to close or reset a connection.
Upon receipt of an RST segment, the sender must stop sending and
must abort any unserviced requests. The RST is sent as a
separate segment and does not include any data.
4.6.1 RST Segment Format
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|0|0|1|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 | |
+-------------------------------+
RST Segment Format
Figure 9
Page 42
RDP Specification RDP Segments and Formats
4.7 NUL Segment
The NUL segment is used to determine if the other side of a
connection is still active. When a NUL segment is received, an
RDP implementation must acknowledge the segment if a valid
connection exists and the segment sequence number falls within
the acceptance window. The segment is then discarded. The NUL
may be combined with an ACK in a segment but is never combined
with user data.
4.7.1 NUL segment format
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|0|0|0|1|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 | |
+-------------------------------+
NUL Segment Format
Figure 10
Page 43
RFC-908 July 1984
Page 44
RDP Specification Examples of Operation
CHAPTER 5
Examples of Operation
5.1 Connection Establishment
This is an example of a connection being established between
Host A and Host B. Host B has done a passive Open and is in
LISTEN state. Host A does an active Open to establish the
connection.
Host A Host B
Time State State
1. CLOSED LISTEN
2. SYN-SENT <SEQ=100><SYN> --->
3. <--- <SEQ=200><ACK=100><SYN,ACK>
SYN-RCVD
4. OPEN <SEQ=101><ACK=200> ---> OPEN
5. <SEQ=101><ACK=200><Data> --->
6. <--- <SEQ=201><ACK=101>
Page 45
RFC-908 July 1984
5.2 Simultaneous Connection Establishment
This is an example of two hosts trying to establishing
connections to each other at the same time. Host A sends a SYN
request to Host B at the same time Host B sends a SYN request to
Host A.
Host A Host B
Time State State
1. CLOSED CLOSED
2. SYN-SENT <SEQ=100><SYN> --->
<--- <SEQ=200><SYN> SYN-SENT
3. SYN-RCVD SYN-RCVD
<SEQ=100><ACK=200><SYN,ACK> --->
<--- <SEQ=200><ACK=100><SYN,ACK>
4. OPEN OPEN
Page 46
RDP Specification Examples of Operation
5.3 Lost Segments
This is an example of what happens when a segment is lost.
It shows how segments can be acknowledged out of sequence and
that only the missing segment need be retransmitted. Note that
in this and the following examples "EA" stands for "Out of
Sequence Acknowledgement."
Time Host A Host B
1. <SEQ=100><ACK=200><Data> --->
2. <--- <SEQ=201><ACK=100>
3. <SEQ=101><ACK=200><Data> (segment lost)
4.
5. <SEQ=102><ACK=200><Data> --->
6. <-- <SEQ=201><ACK=100><EA=102>
7. <SEQ=103><ACK=200><Data> --->
8. <--- <SEQ=201><ACK=100>
<EA=102,103>
9. <SEQ=101><ACK=200><Data> --->
10. <--- <SEQ=201><ACK=103>
11. <SEQ=104><ACK=200><Data> --->
12. <--- <SEQ=201><ACK=104>
Page 47
RFC-908 July 1984
5.4 Segments Received Out of Order
This an example of segments received out of order. It
further illustrates the use of acknowledging segments out of
order to prevent needless retransmissions.
Time Host A Host B
1. <SEQ=100><ACK=200><Data> --->
2. <--- <SEQ=201><ACK=100>
3. <SEQ=101><ACK=200><Data> (delayed)
4.
5. <SEQ=102><ACK=200><Data> --->
6. <--- <SEQ=201><ACK=100><EA=102>
7. <SEQ=103><ACK=200><Data> --->
---> (delayed segment 101 arrives)
8. <--- <SEQ=201><ACK=103>
9. <SEQ=104><ACK=200><Data> --->
10. <--- <SEQ=201><ACK=104>
Page 48
RDP Specification Examples of Operation
5.5 Communication Over Long Delay Path
This is an example of a data transfer over a long delay
path. In this example, Host A is permitted to have as many as
five unacknowledged segments. The example shows that it is not
necessary to wait for an acknowledgement in order to send
additional data.
Time Host A Host B
1. <SEQ=100><ACK=200><Data> -1->
2. <SEQ=101><ACK=200><Data> -2->
3. <SEQ=102><ACK=200><Data> -3->
-1-> (received)
4. <-4- <SEQ=201><ACK=100>
5. <SEQ=103><ACK=200><Data> -5->
-2-> (received)
6. <-6- <SEQ=201><ACK=101>
7. <SEQ=104><ACK=200><Data> -7->
-3-> (received)
8. <-8- <SEQ=201><ACK=102>
(received) <-4-
9. <SEQ=105><ACK=200><Data> -9->
-5-> (received)
10. <-10- <SEQ=201><ACK=103>
(received) <-6-
11. <SEQ=106><ACK=200><Data> -11->
-7-> (received)
12. <-12- <SEQ=201><ACK=104>
(received) <-8-
13. -9-> (received)
14. <-13- <SEQ=201><ACK=105>
(received) <-10-
15. -11-> (received)
16. <-14- <SEQ=201><ACK=106>
(received) <-12-
17. (received) <-13-
18. (received) <-14-
Page 49
RFC-908 July 1984
5.6 Communication Over Long Delay Path With Lost Segments
This is an example of communication over a long delay path
with a lost segment. It shows that by acknowledging segments out
of sequence, only the lost segment need be retransmitted.
Time Host A Host B
1. <SEQ=100><ACK=200><Data> -1->
2. <SEQ=101><ACK=200><Data> -2->
3. <SEQ=102><ACK=200><Data> -3->
-1-> (received)
4. <-4- <SEQ=201><ACK=100>
5. <SEQ=103><ACK=200><Data> (segment lost)
-2-> (received)
6. <-5- <SEQ=201><ACK=101>
7. <SEQ=104><ACK=200><Data> -6->
-3-> (received)
8. <-7- <SEQ=201><ACK=102>
(received) <-4-
9. <SEQ=105><ACK=200><Data> -8->
10.
(received) <-5-
11. <SEQ=106><ACK=200><Data> -10->
-6-> (received)
12. <-11- <SEQ=201><ACK=102><EA=104>
(received) <-7-
-8-> (received)
13. <-12- <SEQ=201><ACK=102><EA=104,105>
-10-> (received)
14. <-13- <SEQ=201><ACK=102><EA=104-106>
(received) <-11-
15. <SEQ=103><ACK=200><Data> -14->
(received) <-12-
16. (received) <-13-
-14-> (received)
17. <-15- <SEQ=201><ACK=106>
18.
19. (received) <-15-
Page 50
RDP Specification Examples of Operation
5.7 Detecting a Half-Open Connection on Crash Recovery
This is an example of a host detecting a half-open
connection due to the crash and subsequent restart of the host.
In this example, Host A crashes during a communication session,
then recovers and tries to reopen the connection. During the
reopen attempt, it discovers that a half-open connection still
exists and it then resets the other side. Both sides were in the
OPEN state prior to the crash.
Host A Host B
Time
1. OPEN OPEN
(crash!) <--- <SEQ=200><ACK=100><ACK>
2. CLOSED OPEN
(recover)
3. SYN-SENT OPEN
<SEQ=400><SYN> ---> (?)
4. SYN-SENT OPEN
(!) <--- <SEQ=200><ACK=100><ACK>
5. SYN-SENT OPEN
<SEQ=101><RST> ---> (abort)
6. SYN-SENT CLOSED
7. SYN-SENT <SEQ=400><SYN> --->
Page 51
RFC-908 July 1984
5.8 Detecting a Half-Open Connection from the Active Side
This is another example of detecting a half-open connection
due to the crash and restart of a host involved in a connection.
In this example, host A again crashes and restarts. Host B is
still active and tries to send data to host A. Since host A has
no knowledge of the connection, it rejects the data with an RST
segment, causing host B to reset the connection.
Host A Host B
Time
1. (crash!) OPEN
2. CLOSED <--- <SEQ=200><ACK=100><Data> OPEN
3. CLOSED <SEQ=101><RST> ---> (abort)
4. CLOSED CLOSED
Page 52
RDP Specification Examples of Operation
APPENDIX A
Implementing a Minimal RDP
It is not necessary to implement the entire RDP
specification to be able to use RDP. For simple applications
such as a loader, where size of the protocol module may be
important, a subset of RDP may be used. For example, an
implementation of RDP for loading may employ the following
restrictions:
o Only one connection and connection record is supported.
This is the connection used to load the device.
o A single, well-known port is used as the loader port.
Allocable ports are not implemented.
o Only the passive Open request is implemented. Active Opens
are not supported.
o The sequenced delivery option is not supported. Messages
arriving out of order are delivered in the order they
arrive.
o If efficiency is less important than protocol size, the
extended acknowledgement feature need not be supported.
Page 53
RFC-908 July 1984
INDEX
ACK.......................................... 16, 33, 34, 38
ACK segment format....................................... 38
acknowledgement number field......... 16, 34, 37, 38, 39, 40
byte-stream protocols................................. 4, 14
checksum................................................. 16
checksum field........................................... 34
Close request............................................ 13
Closed state.......................................... 9, 10
CLOSEWAIT................................................ 12
Close-Wait state................................. 10, 11, 13
CLOSE-WAIT timeouts...................................... 29
connection, closing of............................... 13, 42
connection, establishment of...................... 8, 11, 45
connection identifier................................. 7, 33
connection management..................................... 7
connection record..................................... 9, 11
connection state diagram................................. 10
connection states......................................... 8
control flags field...................................... 33
cumulative acknowledgement............................... 16
data communication....................................... 14
data length field................................ 34, 39, 40
datagrams................................................. 6
debugging.............................................. 1, 3
dumping................................................... 3
EACK......................................... 16, 33, 35, 40
EACK segment format...................................... 40
event processing......................................... 20
extended acknowledgement................................. 16
flow control............................................. 17
half-open connection, detection of............... 14, 51, 52
initial sequence number....................... 9, 11, 12, 15
internet protocols........................................ 5
IP................................................ 6, 15, 31
IP header............................................ 31, 37
Listen state................................... 8, 9, 10, 45
loading................................................ 1, 3
maximum segment size..................... 11, 12, 13, 15, 37
maximum unacknowledged segments.............. 11, 12, 17, 37
message fragmentation.................................... 14
non-cumulative acknowledgement........................... 16
Page 54
RDP Specification Examples of Operation
NUL.................................................. 33, 43
NUL segment format....................................... 43
Open request.......................................... 8, 17
Open request, active................................... 8, 9
Open request, passive.................................. 8, 9
Open state....................................... 10, 11, 45
options flag field....................................... 37
out-of-sequence acknowledgement.................. 12, 16, 18
ports................................................. 7, 33
ports, well-known......................................... 8
positive acknowledgement............................. 15, 16
RBUF.MAX................................................. 13
RCV.CUR.................................................. 12
RCVDSEQNO................................................ 12
RCV.IRS.................................................. 12
RCV.MAX.................................................. 12
RDP connection........................................... 14
RDP header................................... 14, 16, 32, 37
RDP header length........................................ 33
RDP segment format....................................... 31
reliable communication................................... 15
retransmission of segments....................... 15, 16, 17
retransmission timeout............................... 17, 29
RST.................................................. 33, 42
RST segment.......................................... 13, 52
RST segment format....................................... 42
SBUF.MAX................................................. 12
SDM...................................................... 37
SEG.ACK.................................................. 13
SEG.BMAX................................................. 13
SEG.MAX.................................................. 13
segment arrival events............................... 20, 24
segments................................................. 14
SEG.SEQ.................................................. 13
Send request......................................... 14, 15
sequence number...................................... 12, 15
sequence number acceptance window........................ 18
sequence number field........................ 34, 37, 39, 40
sequenced delivery................................. 3, 4, 37
sequential acknowledgement................................ 4
SND.ISS.................................................. 12
SND.MAX.................................................. 12
SND.NXT.................................................. 11
SND.UNA.................................................. 12
STATE.................................................... 11
SYN.................................. 12, 13, 15, 33, 35, 36
SYN segment........................................... 9, 36
Page 55
RFC-908 July 1984
Syn-Rcvd state........................................ 9, 10
Syn-Sent state........................................ 9, 10
TCP................................................... 4, 14
three-way handshake....................................... 4
user request events.................................. 20, 21
version number field..................................... 33
Page 56
RDP Specification Examples of Operation