The Lightweight User Datagram Protocol (UDP-Lite)
RFC 3828

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                        L-A. Larzon
Request for Comments: 3828                Lulea University of Technology
Category: Standards Track                                   M. Degermark
                                                                 S. Pink
                                               The University of Arizona
                                                       L-E. Jonsson, Ed.
                                                                Ericsson
                                                       G. Fairhurst, Ed.
                                                  University of Aberdeen
                                                               July 2004

           The Lightweight User Datagram Protocol (UDP-Lite)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes the Lightweight User Datagram Protocol (UDP-
   Lite), which is similar to the User Datagram Protocol (UDP) (RFC
   768), but can also serve applications in error-prone network
   environments that prefer to have partially damaged payloads delivered
   rather than discarded.  If this feature is not used, UDP-Lite is
   semantically identical to UDP.

Larzon, et al.              Standards Track                     [Page 1]
RFC 3828                   UDP-Lite Protocol                   July 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  3
       3.1.  Fields . . . . . . . . . . . . . . . . . . . . . . . . .  4
       3.2.  Pseudo Header. . . . . . . . . . . . . . . . . . . . . .  5
       3.3.  Application Interface. . . . . . . . . . . . . . . . . .  5
       3.4.  IP Interface . . . . . . . . . . . . . . . . . . . . . .  6
       3.5.  Jumbograms . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Lower Layer Considerations . . . . . . . . . . . . . . . . . .  6
   5.  Compatibility with UDP . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       8.1.  Normative References . . . . . . . . . . . . . . . . . .  9
       8.2.  Informative References . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12

1.  Introduction

   This document describes a new transport protocol, UDP-Lite, (also
   known as UDPLite).  This new protocol is based on three observations:

   First, there is a class of applications that benefit from having
   damaged data delivered rather than discarded by the network.  A
   number of codecs for voice and video fall into this class (e.g., the
   AMR speech codec [RFC-3267], the Internet Low Bit Rate Codec [ILBRC],
   and error resilient H.263+ [ITU-H.263], H.264 [ITU-H.264; H.264], and
   MPEG-4 [ISO-14496] video codecs).  These codecs may be designed to
   cope better with errors in the payload than with loss of entire
   packets.

   Second, all links that support IP transmission should use a strong
   link layer integrity check (e.g., CRC-32 [RFC-3819]), and this MUST
   be used by default for IP traffic.  When the under-lying link
   supports it, certain types of traffic (e.g., UDP-Lite) may benefit
   from a different link behavior that permits partially damaged IP
   packets to be forwarded when requested [RFC-3819].  Several radio
   technologies (e.g., [3GPP]) support this link behavior when operating
   at a point where cost and delay are sufficiently low.  If error-prone
   links are aware of the error sensitive portion of a packet, it is
   also possible for the physical link to provide greater protection to
   reduce the probability of corruption of these error sensitive bytes
   (e.g., the use of unequal Forward Error Correction).

Larzon, et al.              Standards Track                     [Page 2]
RFC 3828                   UDP-Lite Protocol                   July 2004

   Third, intermediate layers (i.e., IP and the transport layer
   protocols) should not prevent error-tolerant applications from
   running well in the presence of such links.  IP is not a problem in
   this regard, since the IP header has no checksum that covers the IP