[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                            T. Bova
INTERNET-DRAFT                                            T. Krivoruchka
                                                           Cisco Systems

Expires in six months                                   25 Feburary 1999



                     RELIABLE UDP PROTOCOL
                 <draft-ietf-sigtran-reliable-udp-00.txt>


Status of This Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).




Abstract

This Internet Draft discusses Reliable UDP (RUDP).  RUDP is a simple
packet based transport protocol.  RUDP is based on RFCs 1151 and 908 -
Reliable Data Protocol.  RUDP is layered on the UDP/IP Protocols and
provides reliable in-order delivery (up to a maximum number of
retransmissions) for virtual connections.  RUDP has a very flexible
design that would make it suitable for a variety of transport uses.
One such use would be to transport telecommunication signaling
protocols.








Bova & Krivoruchka                                             [Page  1]


Internet Draft             Reliable UDP Protocol                Feb 1999


                        TABLE OF CONTENTS

1.  Introduction...............................................3
     1.1 System Overview.......................................3
     1.2 Background............................................5
     1.3 Data Structure Format.................................5
     1.4 Feature Negotiation..................................16
2.  Future Potential Enhancements.............................16
3.  References................................................17
4.  Author's Addresses........................................17








































Bova & Krivoruchka                                             [Page  2]


Internet Draft             Reliable UDP Protocol                Feb 1999


1.  Introduction

This Internet Draft discusses a simple packet based transport
protocol designed to support applications that require a
reliable, sequenced packet based transport protocol.  RUDP is based
on RFCs 1151 and 908 - Reliable Data Protocol.  RUDP is layered on
the UDP/IP Protocols and provides reliable in-order delivery (up to
a maximum number of retransmissions) for virtual connections.

1.1 Background

A reliable transport protocol is needed to transport of telephony signaling
across IP networks. This reliable transport must be able to provide an
architecture for a variety of applications (i.e. signaling protocols)
requiring transport over IP.

Existing IP protocols have been scrutinized and it has been concluded that
a new reliable transport mechanism for telecommunication signaling
protocols is needed.  This protocol should meet the following criteria:

*  transport should provide reliable delivery up to a maximum number of
   retransmissions (i.e. avoid stale signaling messages).
*  transport should provide in-order delivery.
*  transport should be a message based.
*  transport should provide flow control mechanism.
*  transport should have low overhead, high performance.
*  characteristics of each virtual connection should be configurable
   (i.e. timers).
*  transport should provide a keep-alive mechanism.
*  transport should provide error detection.
*  transport should provide for secure transmission.

RUDP is designed to allow characteristics of each connection to be
   individually configured so that many protocols with different transport
   requirements can be implemented simultaneously on the same platform.

1.3  Data Structure Format

1. Six octet minimum RUDP header for data transmissions

Each UDP packet sent by RUDP must start with at least a six octet header.
The first octet contains a series of single bit flags. The next three
fields are each one octet in size. They are: Header length, Sequence


Bova & Krivoruchka                                             [Page  3]


Internet Draft             Reliable UDP Protocol                Feb 1999


number, and Acknowledgment number.  These three octets are followed by a
two octet checksum.


    0 1 2 3 4 5 6 7 8            15
   +-+-+-+-+-+-+-+-+---------------+
   |S|A|E|R|N|C|T| |    Header     |
   |Y|C|A|S|U|H|C|0|    Length     |
   |N|K|K|T|L|K|S| |               |
   +-+-+-+-+-+-+-+-+---------------+
   |  Sequence #   +   Ack Number  |
   +---------------+---------------+
   |            Checksum           |
   +---------------+---------------+

        Figure 1, RUDP Header


Control bits

The control bits indicate what is present in the packet. The SYN bit
indicate a synchronization segment is present. The ACK bit indicates the
acknowledgment number in the header is valid.  The EACK bit indicates an
extended acknowledge segment is present.  The RST bit indicates the packet
is a reset segment.  The NUL bit indicates the packet is a null segment.
The TCS bit indicates the packet is a transfer connection state segment.
The SYN, EACK, RST, and TCS bits are mutually exclusive.  The ACK bit is
always set when the NUL bit is set.  The CHK bit indicates whether the
Checksum field contains the checksum of just the header or the header
and the body (data).  If the CHK bit is zero, the Checksum field only
contains the checksum of the header.  If the CHK bit is one, the
Checksum field contains the checksum of the header and data.

Header length.

The Header length field indicates where user data begins in the packet.
If total length of the packet is greater than the value of the header
length field, user data exists in the packet. User data cannot be present
in packets with the EACK, NULL, or RST bits set.  A packet with user data
in it always has the ACK bit set and is called a data segment.

Sequence number.

Each packet contains a sequence number. When a connection is first opened,
each peer randomly picks an initial sequence number. This sequence number
is used in the SYN segments to open the connection.  Each transmitter
increments the sequence number before sending a data, null, or reset
segment.


Bova & Krivoruchka                                             [Page  4]


Internet Draft             Reliable UDP Protocol                Feb 1999


Acknowledgment Number.

The acknowledgment number field indicates to a transmitter the last in-
sequence packet the receiver has received.

Checksum.

A checksum is always calculated on the RUDP header to ensure integrity.
In addition, the checksum can be calculated on the header and body
if the CHK bit is set to one.  The checksum algorithm used in RUDP is
the same algorithm used in UDP and TCP headers which is the 16-bit
one's complement of the one's complement sum of bytes being checksumed.

2.  SYN Segment

The SYN is used to establish a connection and synchronize sequence numbers
between two hosts.  The SYN segment also contains the negotiable parameters
of the connection.  All configurable parameters that the peer must know
about are contained in this segment.  This includes the maximum number of
segments the local RUDP is willing to accept and option flags that indicate
the features of the connection being established.  A SYN segment must not
be combined with user data.  A SYN segment is also used to perform an auto
reset on a connection.  Auto reset is described later.

Figure 2 shows a SYN segment.
























Bova & Krivoruchka                                             [Page  5]


Internet Draft             Reliable UDP Protocol                Feb 1999


    0             7 8            15
   +-+-+-+-+-+-+-+-+---------------+
   | |A| | | | | | |               |
   |1|C|0|0|0|0|0|0|       28      |
   | |K| | | | | | |               |
   +-+-+-+-+-+-+-+-+---------------+
   +  Sequence #   +   Ack Number  |
   +---------------+---------------+
   | Vers  | Spare | Max # of Out  |
   |       |       | standing Segs |
   +---------------+---------------+
   | Option Flags  |     Spare     |
   +---------------+---------------+
   |      Maximum Segment Size       |
   +---------------+---------------+
   | Retransmission Timeout Value  |
   +---------------+---------------+
   | Cumulative Ack Timeout Value  |
   +---------------+---------------+
   |   Null Segment Timeout Value  |
   +---------------+---------------+
   | Transfer State Timeout Value  |
   +---------------+---------------+
   |  Max Retrans  | Max Cum Ack   |
   +---------------+---------------+
   | Max Out of Seq| Max Auto Reset|
   +---------------+---------------+
   |    Connection Identifier      |
   +                               +
   |      (32 bits in length)      |
   +---------------+---------------+
   |           Checksum            |
   +---------------+---------------+

        Figure 2, SYN segment

Sequence Number

The sequence number field contains the initial sequence number selected for
this connection.

Acknowledgment 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 RUDP.

Version

The version field contains the version of RUDP.  The initial version is
one (1).


Bova & Krivoruchka                                             [Page  6]


Internet Draft             Reliable UDP Protocol                Feb 1999


Maximum Number of Outstanding Segments

The maximum number of segments that should be sent without getting an
acknowledgment.  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.  This is not a negotiable
parameter.  Each side must use the value provided by its peer when
sending data.

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.
A preliminary subset of flags are defined as follows:

   Bit #        Bit Name        Description
    0       not used          not used, must always be set to 1.
    1       CHK               Data Checksum enable. If this bit is set
                              then the checksum field will contain a
                              checksum of the entire RUDP packet (header
                              and data).  This is a negotiable
                              parameter.
    2       REUSE             This bit must be set during an auto reset to
                              indicate the previous negotiable parameters
                              should be used.  When this bit is set the
                              following fields of the SYN should be set to
                              zero by the sender and must be ignored by the
                              receiver:  Maximum Segment Size,
                              Retransmission Timeout Value, Cumulative Ack
                              Timeout Value, Max Retransmissions, Max
                              Cumulative Ack, Max Out of Sequence, and Max
                              Auto Reset.
    3-7     Spare

Maximum Segment Size

The maximum number of octets that can be received by the peer sending the
SYN segment.  Each peer may specify a different value.  Each peer must not
send packets greater than the value of this field received from its peer
during connection negotiation.  This number includes the size of the RUDP
header. This is not a negotiable parameter.

Retransmission Timeout Value

The timeout value for retransmission of unacknowledged packets.  This value
is specified in milliseconds. The valid range is 100 to 65536.  This is a
negotiable parameter, both peers must agree on the same value for this
parameter.


Bova & Krivoruchka                                             [Page  7]


Internet Draft             Reliable UDP Protocol                Feb 1999


Cumulative Ack Timeout Value

The timeout value for sending an acknowledgment segment if another segment
is not sent.  This value is specified in milliseconds. The valid range is
100 to 65536.  This is a negotiable parameter, both peers must agree on the
same value for this parameter.  In addition, this parameter should be
smaller than the Retransmission Timeout Value.

Null Segment Timeout Value

The timeout value for sending a null segment if a data segment has not
been sent.  Thus, the null segment acts as a keep-alive mechanism.
This value is specified in milliseconds.  The valid range is 0 to 65536.
A value of 0 disables null segments. This is a negotiable parameter, both
peers must agree on the same value for this parameter.

Transfer State Timeout Value

This timeout value indicate the amount of time the state information will
be  saved for a connection before an auto reset occurs.  This value is
specified in milliseconds.  The valid range is 0 to 65536.  This is a
negotiable parameter, both peers must agree on the same value for this
parameter.  A value of 0 indicates the connection will be auto-reset
immediately.

Max Retrans

The maximum number of times consecutive retransmission(s) will be attempted
before the connection is considered broken.  The valid range for this value
is 0 to 255.  A value of 0 indicates retransmission should be attempted
forever.  This is a negotiable parameter, both peers must agree on the same
value for this parameter.

Max Cum Ack

The maximum number of acknowledgments that will be accumulated before
sending an acknowledgment if another segment is not sent. The valid range
for this value is 0 to 255.  A value of 0 indicates an acknowledgment
segment will be send immediately when a data, null, or reset segment is
received.  This is a negotiable parameter, both peers must agree on the
same value for this parameter.

Max Out of Seq

The maximum number of out of sequence packets that will be accumulated
before an EACK (Extended Acknowledgement) segment is sent. The valid range
for this value is 0 to 255.  A value of 0 indicates an EACK will be sent
immediately if an out of order segment is received.  This is a negotiable
parameter, both peers must agree on the same value for this parameter.


Bova & Krivoruchka                                             [Page 8]

Internet Draft             Reliable UDP Protocol                Feb 1999


Max Auto Reset

The maximum number of consecutive auto reset that will performed before
a connection is reset.  The valid range for this value is 0 to 255.  A
value of 0 indicates that an auto reset will not be attempted, the
connection will be reset immediately if an auto reset condition occurs.
This is a negotiable parameter, both peers must agree on the same value
for this parameter.  The consecutive auto reset counter is cleared once
a connection is opened.

Connection Identifier

When opening a new connection each peer transmits a connection identifier
that is unique among all RUDP current connections.  Each side then saves
the connection ID received.  When an auto reset is performed, the peer
shall send the saved connection ID originally received to indicate that
an auto reset is being performed on the connection.

3.  ACK Segment

The ACK Segment is used to acknowledge in-sequence segments.  It contains
both the next send sequence number and the acknowledgment sequence number
in the RUDP header.  The ACK segment may be sent as a separate segment, but
it should be combined with data whenever possible.  Data and Null segments
must always include the ACK bit and Acknowledgment Number field.  The size
of a stand-alone ACK segment is six octets.  Figure 3 shows a stand-alone
ACK segment.

    0 1 2 3 4 5 6 7 8            15
   +-+-+-+-+-+-+-+-+---------------+
   |0|1|0|0|0|0|0|0|       6       |
   +-+-+-+-+-+-+-+-+---------------+
   | Sequence #    |   Ack Number  |
   +---------------+---------------+
   |           Checksum            |
   +---------------+---------------+

    Figure 3, Stand-alone ACK segment

4.  EACK segment

The EACK segment is used to acknowledge segments received out of sequence.
It contains the sequence numbers of one or more segments received 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 header
length is variable for the EACK segment.  Its minimum value is seven and
its maximum value depends on the maximum receive queue length.  Figure 4
shows a stand-alone EACK segment.



Bova & Krivoruchka                                             [Page 9]

Internet Draft             Reliable UDP Protocol                Feb 1999


    0 1 2 3 4 5 6 7 8            15
   +-+-+-+-+-+-+-+-+---------------+
   |0|1|1|0|0|0|0|0|     N + 6     |
   +-+-+-+-+-+-+-+-+---------------+
   | Sequence #    |   Ack Number  |
   +---------------+---------------+
   |1st out of seq |2nd out of seq |
   |  ack number   |   ack number  |
   +---------------+---------------+
   |  . . .            |Nth out of seq |
   |                     |   ack number  |
   +---------------+---------------+
   |            Checksum           |
   +---------------+---------------+

       Figure 4, EACK segment

5.  RST segment

The RST segment is used to close or reset a connection.  Upon receipt of an
RST segment, the sender must stop sending new packets, but must continue
to attempt delivery of packets already accepted from the API.  The RST is
sent as a separate segment and does not include any data.  Figure 5 shows
a RST segment.


    0 1 2 3 4 5 6 7 8            15
   +-+-+-+-+-+-+-+-+---------------+
   | |A| | | | | | |               |
   |0|C|0|1|0|0|0|0|        6      |
   | |K| | | | | | |               |
   +-+-+-+-+-+-+-+-+---------------+
   | Sequence #    |   Ack Number  |
   +---------------+---------------+
   |         Header Checksum       |
   +---------------+---------------+

          Figure 5, RST segment


6.  NUL segment

The NUL segment is used to determine if the other side of a connection
is still active.  Thus, the NUL segment performs a keep-alive function.
When a NUL segment is received, an RUDP implementation must immediately
acknowledge the segment if a valid connection exists and the segment
sequence number is the next one in sequence.  The segment is then
discarded.  The NUL must be combined with an ACK in a segment but never
combined with user data.  Figure 6 shows a NUL segment.


Bova & Krivoruchka                                             [Page 10]

Internet Draft             Reliable UDP Protocol                Feb 1999


    0 1 2 3 4 5 6 7 8            15
   +-+-+-+-+-+-+-+-+---------------+
   |0|1|0|0|1|0|0|0|       6       |
   +-+-+-+-+-+-+-+-+---------------+
   | Sequence #    |  Ack Number   |
   +---------------+---------------+
   |            Checksum           |
   +---------------+---------------+

        Figure 6, NUL segment

7.  TCS Segment

The TCS is used to transfer the state of connection.  Figure 7 shows a TCS
segment.

    0 1 2 3 4 5 6 7 8            15
   +-+-+-+-+-+-+-+-+---------------+
   | |A| | | | | | |               |
   |0|C|0|0|0|0|1|0|       12      |
   | |K| | | | | | |               |
   +-+-+-+-+-+-+-+-+---------------+
   | Sequence #    |   Ack Number  |
   +---------------+---------------+
   | Seq Adj Factor|      Spare    |
   +---------------+---------------+
   |      Connection Identifier    |
   +                               +                                                                                                                     +
   |       (32 bits in length)     |
   +---------------+---------------+
   |            Checksum           |
   +---------------+---------------+

          Figure 7, TCS segment

Sequence Number

The sequence number field contains the initial sequence number selected for
this connection.

Acknowledgment Number

The acknowledgment number field indicates to a transmitted that last in-
sequence packet the receiver has received.

Seq Adj Factor

This field is used during transfer of state to adjust sequence numbers
between the old and current connections.


Bova & Krivoruchka                                             [Page 11]

Internet Draft             Reliable UDP Protocol                Feb 1999


Connection Identifier

When opening a new connection each peer transmits a  connection identifier
that is unique among all current RUDP connections. Each side then saves
the connection ID received.  This field is used to inform the peer connection
of the connection record that is being transferred to this connection.

1.3.1    Detailed Design

A separate internet draft is being prepared which details in connections
state transitions in Specification and Description Language (SDL) format.
It also contains more details on the internal design of RUDP.

1.3.2  Feature Description

The following features are supported by RUDP.  In the following description,
transmitter and receiver refer to either clients or servers that are sending
or receiving a data segment respectively on a connection.  Client refers to
the peer that initiates the connection and Server refers to the peer that
listened for a connection.  A connection is defined as an interface that
serves a unique peer IP address/UDP port pair.  A server or a client can
have multiple connections on a particular IP address/UDP port, each
connection will be with a unique peer IP address/UDP port pair.

1.  Retransmission timer.

The transmitter has a retransmission timer with a configurable time-
out value.  This timer is initialized every time a data, null, or
reset segment is sent and there is not a segment currently being timed.
If an acknowledgment for this data segment is not received by the time
the timer expires, all segments that have been sent but not acknowledged
are retransmitted.  The Retransmission timer is re-started when the
timed segment is received, if there is still one or more packets that
have been sent but not acknowledged.  The recommended value of the
retransmission timer is 600 milliseconds.

2.  Retransmission Counter.

The transmitter maintains a counter of the number of times a segment
has been retransmitted.  The maximum value of this counter is configurable
with a recommended value is 2.  If this counter exceeds its maximum, the
connection will be considered broken.  Refer to paragraph item 14 below,
Broken Connection Handling, for a description of how RUDP handles a
broken connection.

3.  Stand-alone acknowledgments.

A stand-alone acknowledgment segment is a segment that contains only
acknowledgment information.  Its sequence number field contains the
sequence number of the next data, null, or reset segment to be sent.



Bova & Krivoruchka                                             [Page 12]

Internet Draft             Reliable UDP Protocol                Feb 1999


4.  Piggyback acknowledgments.

Whenever a receiver sends a data, null, or reset segment to the transmitter,
the receiver includes the sequence number of the last in-sequence data,
null, or reset segment received from the transmitter in the acknowledgment
number field of the header of the segment being sent by the receiver.

5.  Cumulative acknowledge counter.

The receiver maintains a counter of unacknowledged segments received
without an acknowledgment being sent to the transmitter.  The maximum
value of this counter is configurable.  If this counter's maximum is
exceeded, the receiver sends either a stand-alone acknowledgment, or an
extended acknowledgment if there are currently any out-of-sequence
segments.  The recommended value for the cumulative acknowledge counter
is 3.

6.  Out-of-sequence acknowledgments counter.

The receiver maintains a counter of the number of segments that have arrived
out-of-sequence.  Each time this counter exceeds its configurable maximum,
an extended acknowledgment segment containing the sequence numbers of all
current out-of-sequence segments that have been received is sent to
the transmitter.  The counter is then reset to zero.  The recommended
value for the out-of-sequence acknowledgements counter is 3.

When a transmitter receives an Extended Acknowledgment, it retransmits
the missing data segments to the receiver.

7.  Cumulative acknowledge timer.

When a receiver has any segments that it has not acknowledged or if it has
segments on its out-of-sequence queue, it waits a maximum amount of
time before sending a stand-alone acknowledgment or an extended acknowledg-
ment, respectively.  When this timer expires, if there are segments on the
out-of-sequence queue, an extended acknowledgment is sent.  Otherwise,
if there are any segments currently unacknowledged, a stand-alone
acknowledgment is sent.  The recommended value of the cumulative
acknowledgement timer is 300 milliseconds.

The cumulative acknowledge timer is restarted whenever an acknowledgment is
sent in a data, null, or reset segment, provided that there are no segments
currently on the out-of-sequence queue.  If there are segments on the out-
of-sequence queue, the timer is not restarted, so that another extended
acknowledgment will be sent when it expires again.

8.  Null segment timer

The client maintains a timer which is started when the connection is opened
and is reset every time a data segment is sent.  If the client's null
segment timer expires, the client sends a null segment to the server.


Bova & Krivoruchka                                             [Page 13]

Internet Draft             Reliable UDP Protocol                Feb 1999


The null segment is acknowledged by the server if its sequence number
is valid.  The server maintains a null segment timer with a time-out
value of twice the client's time-out value.  The server's timer is reset
whenever a data or null segment is received from the client.  If the
server's null segment timer expires, the connection is considered broken.
Refer to paragraph item 14 below, Broken Connection Handling, for a
description of how RUDP handles a broken connection.  The recommended
value of the Null segment timer is 2 seconds.

9.  Auto Reset

Either side of a connection can initiate an auto reset.  An auto reset
can be caused by the retransmission count exceeding its maximum, the
the expiration of the server's Null segment timer, or the expiration
of the transfer state timer.  An auto reset will cause both peers to
reset their current states including flushing retransmission and
out-of-sequence queues and then reset their initial sequence number
and re-negotiate the connection.  Each peer will notify its Upper Layer
Protocol (ULP) of the auto reset.  There is a consecutive reset counter
that sets the maximum number of auto-reset that can occur without the
connection opening.  If this counter exceeds its maximum the connection
is reset.  The recommended value for the consecutive reset counter is 3.

10.  Receiver Input Queue Size

The size of the receiver's input queue is a configurable parameter.
The recommended value of the receiver input queue size is 32 packets.  The
input queue size acts as a flow control mechanism.

11.  Congestion control and slow start

RUDP does not provide any congestion control or slow start algorithms.

12.  UDP port numbers

RUDP doesn't place any restrictions on which UDP port numbers are used.
Valid port numbers are ports not defined in RFC 1700.

13.  Support for redundant connections

If an RUDP connection fails, the Upper Layer Protocol will be signaled
and the transfer state timer will be started. The ULP can initiate the
transfer of this state to another RUDP connection via an API call and
RUDP will transfer the state information to the new connection ensuring
that packets are not duplicated or lost.  If the ULP does not transfer
the state to another connection before the Transfer State Timer expires,
the connection state is lost and buffers of the queues of the
connection are freed.  The time-out value for the Transfer State
timer is configurable.  The recommended value for the Transfer State
timer is 1 second.



Bova & Krivoruchka                                             [Page 14]

Internet Draft             Reliable UDP Protocol                Feb 1999


14.  Broken connection handling

An RUDP connection is considered broken if either of the following
situations occur:

 - The Retransmission Timer expires and the Retransmission Count has
   been exceeded its maximum.

 - A server's Null Segment Timer expires.

If either of the above two situations occur and the Transfer State
timeout value is non-zero, the ULP will be notified of the connection
failure via the Connection failure signal of the API and the Transfer
State Timer will be started.  If the Transfer State Timer expires, an
Auto Reset is performed and the ULP is notified via the Connection auto
reset signal of the API.

If the transfer state timeout value is zero, then an auto reset will be
performed immediately when either of the above two situlations occur.
The ULP will be notified of a connection failure via the Connection
auto reset signal of the API.

15.  Retransmission Algorithm

Retransmission occurs as a result of receiving an EACK segment or the
time-out of the Retransmission timer.

When an EACK segment is received.  The segments specified in the message
are removed from the unacknowledged sent queue.  The segments to be
retransmitted are determined by examining the Ack Number and the last out
of seq ack number in the EACK segment.  All segments between but not
including these two sequence numbers that are on the unacknowledged sent
queue are retransmitted.

When a retransmission time-out occurs, all messages on the unacknowledged
sent queue are retransmitted.

16.   Signals to Upper Layer Protocol (ULP)

The following signals are sent to the ULP via the API.  These are used to
signal asynchronous events to the ULP:

   Connection open - This signal is generated when the state of the
                     connection transitions to Open.
   Connection refused - This signal is generated when the state of a
                     connection transitions to the Closed state from other
                     than the Close Wait state.
   Connection closed - This signal is generated when the state of a
                     connection transitions from the Close Wait state to
                     the Closed state.

Bova & Krivoruchka                                             [Page 15]

Internet Draft             Reliable UDP Protocol                Feb 1999


   Connection failure - This signal is generated when a connection is
                     declared broken, as described in section 1.3.2,
                     item 15 (Retransmission Algorithm) above.
   Connection auto reset - This signal is generated when a connection auto
                     resets.  This is an indication to the ULP that data
                     may have been lost and RUDP is attempting to return
                     the connection to the Open state.

17.  Checksum Algorithm

The checksum algorithm used in RUDP is the same algorithm used in UDP and
TCP headers which is the 16-bit one's complement of the one's complement
sum of data being checksumed.  The checksum is calculated over the entire
RUDP packet if negotiated at the time the connection was opened.  The
negotiation is based on setting the CHK bit of the options field in the
SYN segment used to open the connection.  Otherwise, the checksum is
calculated over the RUDP header only.  Refer to RFC 1071 for implementation
information for this algorithm.

18.  FEC

RUDP does not define a procedure for generate Forward Error Correction
(FEC).  It is compatible with FEC algorithms that generate duplicate
packets because it will throw away any duplicate packets it receives.

19.  Security

RUDP will be compatible with the IPsec standard for secure IP
communications.

1.4  Feature Negotiation

When client initiates a connection its sends a SYN segment which contains
the negotiable parameters defined by the ULP via the API.  The server can
accept these parameters by echoing them back in its SYN with ACK response
or propose different parameters in its SYN with ACK response.  The client
can then choose to accept the parameters sent by the server by sending an
ACK to establish the connection or it can refuse the connection by sending
send a RST.  Features cannot be re-negotiated during an auto reset.

2.0  Future Potential Enhancements

RUDP should support a symmetrical mode of operation in addition to the
current client/server mode of operation.  This would allow both sides to
actively start the connection.

RUDP should support the ability to expand the sequence and acknowledge
fields from their current one octet length to two octets.  This will allow
transmission windows of greater than 255 buffer to be used.

Investigate use of the Nagle algorithm to improve network efficiency.



Bova & Krivoruchka                                             [Page 16]
Internet Draft             Reliable UDP Protocol                Feb 1999


3.0  References

[1]  Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
     Protocol Specification", RFC 791, USC/Information Sciences Institute,
     September 1981.

[2]  Postel, J., "User Datagram Protocol", RFC 768, USC/Information
     Sciences Institute, August 1980.

[3]  Postel, J. (ed.), "Transmission Control Protocol", RFC 793,
     USC/Information Sciences Institute, September 1981.

[4]  Velten, D., Hinden, R. and Sax, J., "Reliable Data Protocol", RFC
     908, BBN Communications Corporation, July 1984.

[5]  Partridge, C. and Hinden, R., "Version 2 of the Reliable Data
     Protocol", RFC 1151, BBN Corporation, April 1990.

[6]  Braden, R., "Computing the Internet Checksum", RFC 1071, ISI,
     September 1988

[7]  V. Jacobson, "Congestion Avoidance and Control," Computer
     Communication Review, Val. 18, no. 4, pp. 314-329, Aug. 1988.

[8]  W. Stevens, RFC 2001 “TCP Slow Start, Congestion Avoidance, Fast
     Retransmit, and Fast Recovery Algorithms”, January 1997

[9]  V. Jacobson, "Modified TCP Congestion Avoidance Algorithm", April
     30, 1990.

[10] Z. Wang, J. Crowcroft, A Dual-Window Model for Flow and Congestion
     Control, The Distributed Computing Engineering Journal, Institute
     of Physics/British Computer Society/IEEE, Vol 1, No 3, page 162-172,
     May 1994.

[11] Romanow, Allyn, "TCP over ATM: Some Performance Results",
     ATM Forum/93-784

4.0  Author's Addresses

Tom Bova                               Tel:  +1-703-484-3331
Cisco Systems                          Email:  tbova@cisco.com
13615 Dulles Technology Drive
Herndon, VA  20171
USA

Ted Krivoruchka                        Tel:  +1-703-484-3325
Cisco Systems                          Email:  tedk@cisco.com
13615 Dulles Technology Drive
Herndon, VA  20171
USA


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/