UDP Lite is a new standardized IP transport protocol (RFC 3828
error-prone network environments. It offers to applications such as streaming media
to use the `good
parts' of a partially corrupted packet.
Usually, UDP datagrams are always discarded
checksum (which is a simple one's complement bit sum) does not pass.
This means that the corruption of just one byte leads to the whole
packet being dropped. If the packet is large, (UDP packets
support sizes up to 64kB
this can have a clear impact on audio/video/game quality.
makes it possible to
reuse useful information in such cases by limiting the scope of the
Availability and applications
UDP-Lite is now part of the Linux kernel since version 2.6.20.
Several applications for testing are included in the tarball:
- a client-server
application in C to test the connectivity and features
- W. Richard Stevens' sock program
ported to UDP Lite (many more testing options)
- a patched version of the ttcp network
- a patch for the Video LAN client for streaming MPEG, DVD, DVB ....
over UDP Lite
- UDP-Lite programs in Perl: two client / server applications
here the latest tarball
, including all
applications and instructions how to set these up. A HOWTO
is included in the
Thanks to the work of Jaap Keuter, Wireshark (formerly known as Ethereal) can now decode UDP-Lite,
there is also a WiKi
with capture files. The following shows Ethereal in action, using the
file which traced the transfer of "hello world\n".
The protocol type shows as 0x88 (136 in decimal). The
following decodes the data
highlighted above. Our payload is 12 bytes including CR/LF (0xa), the
total is 20bytes.
|Checksum coverage length
|8 bytes (header only)
|UDP Lite checksum
|correct (see below)
|hello + ' '
The checksum coverage is set to the minimum here, 8 bytes, which
covers only the header. The actual checksum calculation uses the same algorithm as TCP
and UDP, i.e. the one's complement of all the octets plus a pre-fixed
pseudo header (see example below) .
In the minimal case, the UDP checksum covers only the header (8 bytes),
in the other extreme the
checksum covers the entire packet -- in this case UDP Lite does exactly
the same as UDP. To achieve compatibility with the 8-byte UDP header
format (RFC 768
Length field of the UDP header is re-interpreted
as `checksum coverage length'. The UDP length field is redundant:
can be retrieved from the IP payload length(s). For comparison, here is
0 7 8 15 16 23 24 31
| Source | Destination |
| Port | Port |
| | |
| Length | Checksum |
: Payload :
And this is the UDP Lite header (RFC 3828
0 15 16 31
| Source | Destination |
| Port | Port |
| Checksum | |
| Coverage | Checksum |
: Payload :
As can be seen, if Checksum Coverage
, there is virtually
difference between UDP and UDP Lite.
If the checksum coverage field is 0, this means that the entire packet
is covered by the checksum field, otherwise the value is minimally 8.
Packets with a coverage length less than 8 must
discarded, the same goes for packets whose coverage length exceeds the
packet length. A failure to do so in the latter case can result
in reading beyond the end of the packet buffer (i.e. illegal memory
access by the driver).
Checksum computation example
With regard to the above figure
, we here
show how the checksum is computed. Like IP, TCP, and UDP, UDP Lite uses
the 1's complement of the 1's complement sum of 16-bit integers. This
is slightly unusual, since most computers use 2's complement
representation of integers. Practically, the 1's complement sum of
16-bit integers can be achieved by summing these up as a 32-bit
integer, and then add the carry (i.e. the value obtained by and-ing
with 0xFFFF0000) to the lower two bytes. The process is described in
detail, and with algorithms, in RFC 1071
. Here we show
how it works for UDP Lite on the above trace.
The first set of 16-bit words is the pseudo header, which contains the
hex values for source/destination IP, total IP payload length, and
protocol type. The following table shows the values for the above trace.
|136 (UDP Lite)
The sum of these words is 0002 B10D
The UDP Lite packet from above in hex looks like this (header is marked
|8000 04D2 0008 0000
6865 6C6C 6F20 776F 726C 640A
Note that the checksum field (last two octets of the header)
is set to zero. This is required for the checksum computation.
The third field, 0008, denotes the checksum
. It is set to 8 in this example which means that
only the header
With regard to the checksum
we thus have to add
04D2 + 0008 + 0000 = 84DA
To this we add the sum over the
B10D + 84DA
= 0003 35E7
This is a 32-bit value, to obtain the 16-bit one's complement
sum, we add the (`end-around') carry:
+ 35E7 = 35EA
We are almost done: it remains to create the one's complement
of this sum, by
subtracting it from FFFF:
- 35EA = CA15
Compare with the above - this is the value showing up in the checksum
field of the UDP Lite header. This kind of arithmetic can very easily
be done using the bc(1)
calculator, by setting `obase=16;
' at the beginning and only using capital letters for
the hex values. More checksum computation examples
can be found on this page
- RFC 3828 - UDP
WiKi with information and sample capture files
- Stanislaus, Fairhurst and Radzik:
Cross-Layer techniques for flexible transport protocols (UDP-Lite and
DCCP) over a satellite network. Proceedings of the International
Workshop on Satellite and Space Communications (IWSSC-05). [PDF]
- Hammer et al.: Corrupted Speech Data Considered Useful.
Proc. 1st ISCA Tutorial and Research Workshop on Auditory Quality of
Systems, Mont Cenis, Germany, April 2003. [PDF]
- Singh, Konrad, Joseph: Performance
Evaluation of UDP Lite for Cellular Video. Proc. 11th Int.
Workshop on Network and Operating Systems Support for Digital Audio and
Video, 2001. [PDF]
- Larzon, Degermark, Pink:
Efficient use of Wireless Bandwidth for Multimedia Applications.
IEEE MoMuC '99. [Citeseer]
- Larzon, Degermark, Pink: UDP
Lite for Real-Time Multimedia Applications. Proc. IEEE ICC-99.
- RFC 4019 - G.
Pelletier. RObust Header
Compression (ROHC) Profiles for UDP-Lite.