The Lightweight User Datagram Protocol (UDP-Lite)
draft-ietf-tsvwg-udp-lite-02

Versions: 00 01 02 rfc3828                                              
INTERNET-DRAFT                                           Lars-Ake Larzon
TSV WG                            Lulea University of Technology, Sweden
January 24, 2002                                        Mikael Degermark
Expires: July 24, 2002                                     Stephen Pink
                                          The University of Arizona, USA


                         The UDP Lite Protocol
                   <draft-ietf-tsvwg-udp-lite-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].

   This document is an Internet-Draft. 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.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Please direct comments to the TSV WG mailing list: tsvwg@ietf.org

Abstract

   This document describes the UDP Lite protocol, which is similar to
   classic UDP [RFC-768], but can also serve applications which in lossy
   network environments prefer to have partially damaged payloads
   delivered rather than discarded.  If this feature is not used, UDP
   Lite is semantically identical to classic UDP.

Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].




Larzon, Degermark, Pink                                         [Page 1]


INTERNET-DRAFT                  UDP Lite                January 24, 2002


Introduction


   Why another transport protocol?

   First, there is a class of applications which prefer to have damaged
   data delivered rather than discarded by the network. A number of
   codecs for voice and video fall into this class. These codecs are
   designed to cope better with errors in the payload than with loss of
   entire packets.

   Second, there are a number of link technologies where data can be
   partially damaged. Several radio technologies exhibit this behavior
   when operating at a point where cost and delay is sufficiently low.

   Third, intermediate layers should not prevent such applications to
   run well over such links.  The intermediate layers are IP and the
   transport layer.  IP is not a problem in this regard since the IP
   header has no checksum which covers the IP payload. The generally
   available transport protocol best suited for these applications is
   UDP, since it has no overhead for retransmission of erroneous
   packets, in-order delivery or error correction.  However, the UDP
   checksum either covers the entire datagram or nothing at all.
   Moreover, in the next version of IP, IPv6 [RFC-2460], the UDP
   checksum is mandatory and must not be disabled.  The IPv6 header does
   not have a header checksum and it was deemed necessary to always
   protect the IP addressing information by making the UDP checksum
   mandatory.

   A transport protocol is needed that conforms with the properties of
   link layers and applications described above.  The error-detection
   mechanism of the transport layer must be able to protect vital
   information such as headers, but also to optionally ignore errors
   best dealt with by the application.  What should be verified by the
   checksum is best specified by the sending application.

   UDP Lite provides a checksum with optionally partial coverage.  When
   using this option, a datagram is divided into a sensitive part
   (covered by checksum) and an insensitive part (not covered by
   checksum).  Errors in the insensitive part will not cause the
   datagram to be discarded.  When the checksum covers the entire
   datagram, which SHOULD be the default, UDP Lite is semantically
   identical to UDP.

   Compared to UDP (hereafter referred to as "classic UDP"), the partial
   checksum provides extra flexibility for applications with partially
   insensitive data.




Larzon, Degermark, Pink                                         [Page 2]


INTERNET-DRAFT                  UDP Lite                January 24, 2002


Protocol description

   The UDP Lite header is shown in figure 1. Its format differs from
   classic UDP in that the Length field has been replaced with a
   Checksum Coverage field. This can be done since information about UDP
   packet length can be provided by the IP module in the same manner as
   for TCP [rfc-793].

                     0              15 16             31
                   +--------+--------+--------+--------+
                   |     Source      |   Destination   |
                   |      Port       |      Port       |
                   +--------+--------+--------+--------+
                   |    Checksum     |                 |
                   |    Coverage     |    Checksum     |
                   +--------+--------+--------+--------+
                   |                                   |
                   |           data bytes ...          |
                   +---------------- ...---------------+

                      Figure 1: New UDP Header Format

Fields

   The fields ``Source Port'' and ``Destination port'' are defined as in
   the UDP specification [RFC-768].

   Checksum Coverage is the number of bytes, counting from the first
   byte of the new UDP header, that are covered by the checksum. The UDP
   Lite header MUST always be included in the checksum. Despite this
   requirement, the Checksum Coverage is expressed in bytes from the
   beginning of the UDP Lite header in order to preserve compatibility
   with classic UDP. A Checksum Coverage of zero indicates that the
   entire new UDP packet is included in the checksum. This means that
   the value of the Checksum Coverage field MUST be either zero or at
   least eight.

   Checksum is the 16-bit one's complement of the one's complement sum
   of a pseudo-header of information from the IP header, the number of
   bytes specified by the Checksum Coverage (starting at the first byte
   in the new UDP header), virtually padded with zero bytes at the end
   (if necessary) to make a multiple of two bytes. If the computed
   checksum is zero, it is transmitted as all ones (the equivalent in
   one's complement arithmetic). The transmitted checksum MUST NOT be
   all zeroes.






Larzon, Degermark, Pink                                         [Page 3]


INTERNET-DRAFT                  UDP Lite                January 24, 2002


Pseudo header

   Similar to classic UDP, UDP Lite uses a conceptually prefixed pseudo
   header from the IP layer for checksumming purposes.  The format of
   the pseudo header is the same as for classic UDP, and differs for
   different versions of IP.  The pseudo header of UDP Lite is different
   from the pseudo header of classic UDP in one way: The value of the
   length field of the pseudo header is not taken from the UDP Lite
   header, but rather from information provided by the IP module.  This
   computation is done in the same manner as for TCP [RFC-793], and
   implies that the length field of the pseudo header includes the UDP
   Lite header and all subsequent bytes in the IP payload.

User Interface

   A user interface should allow the same operations as for classic UDP.
   In addition to this, it SHOULD provide a way for the sending
   application to pass the checksum coverage value to the UDP Lite
   module. There SHOULD also be a way to pass the checksum coverage
   value to the receiving application, or at least let the receiving
   application block delivery of packets with coverage values less than
   a value provided by the application.

   We RECOMMEND that the default behaviour of UDP Lite is to mimic
   classic UDP by having the coverage field match the length of the UDP
   Lite datagram and verifying the entire packet. Applications that want
   to define the payload as partially insensitive to bit errors SHOULD
   do that by a separate system call on the sender side.  Applications
   that wish to receive payloads which were only partially covered by a
   checksum SHOULD inform the system by a separate system call.

IP Interface

   As for classic UDP, the UDP Lite module must pass the pseudo header
   to the UDP Lite module.  The UDP Lite pseudo header contains the IP
   addresses and protocol fields of the IP header, and also the length
   of the IP payload which is derived from the length field of the IP
   header.

   The IP module MUST NOT pad the IP payload with extra bytes since the
   length of the UDP Lite payload delivered to the receiver depends on
   the length of the IP payload.

Lower layer considerations

   Since UDP Lite can deliver packets with damaged payloads to an
   application that wants them, frames carrying UDP Lite packets need
   not be discarded by lower layers when there are errors only in the



Larzon, Degermark, Pink                                         [Page 4]


INTERNET-DRAFT                  UDP Lite                January 24, 2002


   insensitive part.  For a link layer that supports partial error
   detection, the Coverage field in the UDP Lite header MAY be used as a
   hint of where errors should be detected.  Link layers that do not
   support partial checksums SHOULD detect errors in the entire frame.
   In general, lower layers SHOULD detect errors at least in the
   sensitive part of the frame using strong error detection mechanisms,
   but need not do so for the insensitive part.

   Note that it is usually only over links where errors are frequent
   that the partial checksum feature of UDP Lite can make a difference
   to the application. On links where errors are infrequent it is
   RECOMMENDED that lower layeers detect errors in the entire packet.

Jumbograms

   The Checksum Coverage field is 16 bits and can represent checksum
   coverage up to 65535 octets. This allows arbitrary checksum coverage
   for IP datagrams, unless they are Jumbograms. For Jumbograms, the
   Checksum can cover either the entire payload (when the Checksum
   Coverage field has the value zero), or else at most the initial 65535
   octets of the UDP Lite datagram.

Backwards compatibility

   The syntactic and semantic similarity between UDP Lite and classic
   UDP suggests that they might share the same protocol identifier.
   This section explores some consequences of doing so.

   There are no known interoperability problems between classic UDP and
   UDP Lite if they were to share the protocol identifier of classic
   UDP. To be more precise: there is no case where a potentially
   problematic packet is delivered to an unsuspecting application; a UDP
   Lite payload with partial checksum coverage cannot be delivered to
   UDP applications, and UDP datagrams which only partially fills the IP
   payload cannot be delivered to UDP Lite applications.

   If the protocol identifier was shared between UDP and UDP Lite and a
   UDP Lite implementation sends UDP Lite packets with partial checksums
   to a classic UDP implementation, the classic UDP implementation would
   silently discard them because a mismatching pseudo header would cause
   the UDP checksum to mismatch. Neither the sending nor the receiving
   application would be notified.  The obvious solutions to this include

   1) explicit application in-band signaling (not using the partial
   checksum coverage option) to enable the sender to learn whether the
   receiver is UDP Lite enabled or not, or

   2) use of out-of-band signaling such as H.323, SIP, or RTCP to convey



Larzon, Degermark, Pink                                         [Page 5]


INTERNET-DRAFT                  UDP Lite                January 24, 2002


   whether the receiver is UDP Lite enabled.

   If UDP Lite has its own separate protocol identifier, on the other
   hand, a system unaware of UDP Lite would return ICMP Protocol
   Unreachable error messages to the sender. This simple method of
   detecting UDP Lite unaware systems is the primary benefit of having
   separate protocol identifiers.

   Therefore, this draft proposes to allocate a new protocol identifier
   for UDP Lite.

Security considerations

   The security impact of UDP Lite is twofold. First, applications who
   do not expect damaged payloads are bound to malfunction if damaged
   payloads are delivered to them. To avoid this, we RECOMMEND that the
   sending and the receiving side application both explicitly enable the
   partial checksum option.  Packets with partial checksums SHOULD NOT
   be delivered to applications that have not enabled the partial
   checksum option.

   Second, there is the question of how UDP Lite interacts with
   authentication and encryption mechanisms.  When the partial checksum
   option of UDP Lite is enabled, it is fine with the application if the
   insensitive part of a packet changes in transit.  This is contrary to
   the idea behind most authentication mechanisms; authentication
   succeeds when the packet has not changed in transit.  Unless
   authentication mechanisms that operate only on the sensitive part of
   packets are developed, authentication will always fail on UDP Lite
   packets where the insensitive part has been damaged.

   Encryption is also an issue when using UDP Lite.  If a few bits of an
   encrypted packet are damaged, the decryption transform will typically
   spread this error so that the packet becomes too damaged to be of
   use. Most strong encryption transforms today exhibit this behaviour,
   for good reason.  It might be possible to develop encryption
   transforms which would not spread damage in this way when the damage
   occurs in the insensitive part of the packet.  A class of such
   transforms would be transforms where the sensitive part is encrypted
   using a strong transform as usual, and the insensitive part is
   encrypted by XORing it with a cryptographic hash computed over the
   cleartext of the sensitive part.  However, it is clear that with most
   transforms in use today, encryption eliminates the benefits that the
   partial checksum coverage option of the UDP Lite might bring.

IANA considerations

   We request that a new ip protocol identifier is allocated for UDP



Larzon, Degermark, Pink                                         [Page 6]


INTERNET-DRAFT                  UDP Lite                January 24, 2002


   Lite.

Conclusions

   We have presented the UDP Lite protocol. The main motivation for this
   new variant of the classic UDP transport protocol is decreased packet
   error rates for damage-tolerant applications today using classic UDP
   in harsh network environments.  UDP Lite provides optionally partial
   checksum coverage which increases the flexibility of classic UDP by
   making it possible to define a packet as partially insensitive to bit
   errors on a per-packet basis. If no part of a packet is defined as
   insensitive, UDP Lite is semantically identical to classic UDP.







































Larzon, Degermark, Pink                                         [Page 7]


INTERNET-DRAFT                  UDP Lite                January 24, 2002


Contact info

   Lars-Ake Larzon
   Department of CS & EE
   Lulea University of Technology
   S-971 87 Lulea, Sweden
   Email: lln@cdt.luth.se

   Mikael Degermark
   Department of Computer Science
   The University of Arizona
   P.O. Box 210077
   Tucson, AZ 85721-0077
   Email: micke@cs.arizona.edu

   Stephen Pink
   The University of Arizona
   P.O. Box 210077
   Tucson, AZ 85721-0077
   Email: steve@cs.arizona.edu



Normative References

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

   [RFC-793]   Postel, J., "Transmission Control Protocol," RFC 793,
               Information Sciences Institute, September 1981.

   [RFC-2460]  Deering, S., Hinden, R., "Internet Protocol, Version 6
               (IPv6) Specification," RFC 2460, IETF, December 1998.


Informative References

   [RFC-2026]  Bradner, S., "The Internet Standards Process," RFC 2026,
               Harvard University, October 1996.

   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels," Harvard University, March 1997.


This draft expires July 24, 2002






Larzon, Degermark, Pink                                         [Page 8]