INTERNET-DRAFT Lars-Ake Larzon Expires: December 14, 2000 Mikael Degermark Stephen Pink Lulea University of Technology July 14, 2000 The UDP Lite Protocol 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. Abstract This document describes the UDP Lite Protocol, which is similar to classic UDP [RFC-768], but aimed at applications which can handle a partially damaged payload in lossy network environments. If this feature is not used, it 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 The UDP Lite Protocol July 14, 2000 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. They 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 since there is no checksum over the IP payload in the IP header. 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 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 optionally provides a partial checksum. 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 The UDP Lite Protocol July 14, 2000 Protocol description The UDP Lite header is shown in figure 1. Its format differs from classic UDP in that the UDP Length field has been replaced with a Checksum Coverage field. This can be done since information about the UDP Lite packet length can be found in the length field of the IP pseudo-header. 0 15 16 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | Checksum | | | Coverage | Checksum | +--------+--------+--------+--------+ | | | data bytes ... | +---------------- ...---------------+ Figure 1: UDP Lite Datagram Header Format Fields The fields ``Source Port'' and ``Destination port'' are defined as in [RFC-768]. Checksum Coverage is the number of bytes, counting from the first byte of the UDP Lite 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 UDP Lite 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 UDP Lite 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 zero. UDP Lite uses the same conceptually prefixed pseudo header from the IP layer as classic UDP for checksumming purposes. The length of the UDP Lite packet is the value of the length field in the pseudo header. The format of the pseudo header differs for different versions of IP. Larzon, Degermark, Pink [Page 3] INTERNET-DRAFT The UDP Lite Protocol July 14, 2000 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. We RECOMMEND that the default behaviour of UDP Lite is to mimic classic UDP by 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. IP Interface As for classic UDP, the IP module must pass the pseudo header to the UDP Lite module. The IP layer 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 passed in the pseudo header. UDP Lite and different versions of IP For IP version 4 (IPv4), the classic UDP protocol is too well-established and widely spread to be replaced; UDP Lite could only be deployed as a seperate protocol with its own protocol ID. For IP version 6 (IPv6), it can be argued that classic UDP for IPv6 can be replaced by UDP Lite since a UDP Lite packet with a Checksum Coverage equal to the packet length is sematically identical to a classic UDP packet. UDP Lite MUST, however, have a protocol ID different from the one of classic UDP to support communication with IPv4 nodes. Link layer support Since UDP Lite can deliver packets with damaged payload to an application, frames carrying UDP Lite packets should not be discarded by the link layer on links with frequent errors. Link layers that do not support partial checksums should protect the entire frame. For a link layer that supports a partial checksum, the Coverage field in the UDP Lite header could be used as a hint of what data to protect. Conclusions We have presented the UDP Lite protocol. The main motivation for this new transport protocol is decreased packet error rates for error-tolerant applications today Larzon, Degermark, Pink [Page 4] INTERNET-DRAFT The UDP Lite Protocol July 14, 2000 using classic UDP in harsh network environments. UDP Lite provides a partial checksum 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. Due to this similarity between classic UDP and UDP Lite, we argue that classic UDP for IPv6 could be replaced by UDP Lite. 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 CS & EE Lulea University of Technology S-971 87 Lulea, Sweden Email: micke@cdt.luth.se Stephen Pink Department of CS & EE Lulea University of Technology S-971 87 Lulea, Sweden Email: steve@cdt.luth.se References [RFC-768] Postel, J., "User Datagram Protocol," RFC 768, Information Sciences Institute, August 1980. [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. [RFC-2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, IETF, December 1998. This draft expires December 14, 2000 Larzon, Degermark, Pink [Page 5]