INTERNET-DRAFT Lars-Ake Larzon Expires: August 26, 1999 Mikael Degermark Stephen Pink Lulea University of Technology February 26, 1999 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]. Introduction The UDP Lite protocol is designed to provide flexible checksumming policies for applications that today use Larzon, Degermark, Pink [Page 1] INTERNET-DRAFT UDP Lite February 26, 1999 UDP. UDP Lite is particularly useful for real-time multimedia applications sending data over links with high bit-error rates, e.g., many kinds of wireless links. This is a class of applications with delay bounds that leave little time to repair damage caused by transmission errors over the link. Many codecs for voice and video cope better with errors in the data payload than with loss of entire packets. However, no errors are allowed in the protocol headers. UDPs checksumming policy, where the checksum either covers the entire datagram or nothing at all, is therefore not adequate. A transport protocol is needed where a checksum can protect vital information such as headers and can ignore errors best dealt with by the application. UDP Lite provides a partial checksum. Each packet can be divided into a sensitive and an insensitive part. The checksum only covers the sensitive part. Errors in the insensitive part will therefore not cause packets to be discarded. Compared to classic UDP, the partial checksum provides extra flexibility for applications with partially insensitive data. If the checksum is configured to cover the entire packet, UDP Lite is semantically identical to classic UDP, provided there is no padding of the IP datagram after the UDP payload. 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. 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]. Larzon, Degermark, Pink [Page 2] INTERNET-DRAFT UDP Lite February 26, 1999 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, which means that the value of the Checksum Coverage field MUST be 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), 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). Like classic UDP, UDP Lite has the conceptually prefixed pseudo-header shown in figure 2. 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | source address | +--------+--------+--------+--------+ | destination address | +--------+--------+--------+--------+ | zero |protocol| UDP Lite length | +--------+--------+--------+--------+ Figure 2: The pseudo header User Interface A user interface should allow the same operations as for classic UDP. In addition to this, it must provide a way for the sending application to pass the checksum coverage value to the UDP Lite module. IP Interface As for classic UDP, the IP module must pass the pseudo header to the UDP Lite module. The IP MUST NOT pad the IP payload with extra bytes since the length of the UDP Lite payload delivered to the receiver depends on the UDP Lite length passed in the pseudo header. 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. Larzon, Degermark, Pink [Page 3] INTERNET-DRAFT UDP Lite February 26, 1999 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," Harvard University, March 1997. This draft expires August 26, 1999. Larzon, Degermark, Pink [Page 4]