The Lightweight User Datagram Protocol (UDP-Lite)
RFC 3828
Document | Type |
RFC - Proposed Standard
(July 2004; No errata)
Updated by RFC 6335
|
|
---|---|---|---|
Authors | Lars-Erik Jonsson , Lars-Åke Larzon , Gorry Fairhurst , Stephen Pink , Mikael Degermark | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3828 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | <mankin@psg.com>, <jon.peterson@neustar.biz> |
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 IPShow full document text