UDP-Lite

UDP-Lite (Lightweight User Datagram Protocol,[1] sometimes UDP Lite) is a connectionless protocol that allows a potentially damaged data payload to be delivered to an application rather than being discarded by the receiving station. This is useful as it allows decisions about the integrity of the data to be made in the application or the codec, where the significance of the bits is understood. UDP-Lite is described in RFC 3828.[1]

UDP-Lite is based on User Datagram Protocol (UDP), but unlike UDP, where either all or none of a packet is protected by a checksum, UDP-Lite allows for partial checksums that only covers part of a datagram (an arbitrary count of octets at the beginning of the packet), and will therefore deliver packets that have been partially corrupted. It is designed for multimedia protocols, such as Voice over IP (VoIP) or streamed video, in which receiving a packet with a damaged payload is better than receiving no packet at all. For conventional UDP and Transmission Control Protocol (TCP), a single bit in error will cause a "bad" checksum, meaning that the whole packet must be discarded: in this way, bit errors are "promoted" to entire packet errors even where the damage to the data is trivial. For computing the checksum UDP-Lite uses the same checksum algorithm used for UDP (and TCP).[2]

Modern multimedia codecs, like G.718 and Adaptive Multi-Rate (AMR) for audio and H.264 and MPEG-4 for video, have resilience features already built into the syntax and structure of the stream. This allows the codec to (a) detect errors in the stream and (b) potentially correct, or at least conceal, the error during playback. These codecs are ideal partners for UDP-Lite, since they are designed to work with a damaged data stream, and it is better for these codecs to receive perhaps 200 bytes where a few bits are damaged rather than have to conceal the loss of an entire packet that was discarded due to a bad checksum. The application layer understands the significance of the data, where the transport only sees UDP packets. This means that error protection can be added if necessary at a higher layer, for example with a forward error correction scheme. The application is the best place to decide which parts of the stream are most sensitive to error and protect them accordingly, rather than have a single "brute force" checksum that covers everything equally. An example of this can be seen in research by Hammer et al. where UDP-Lite is coupled with the AMR codec to give improved speech quality in lossy network conditions.[3]

Since most modern link layers protect the carried data with a strong cyclic redundancy check (CRC) and will discard damaged frames, making effective use of UDP Lite requires the link layer to be aware of the network layer data being carried. Since no current IP stacks implement such cross-layer interactions, making effective use of UDP-Lite currently requires specially modified device drivers.

The IP protocol identifier is 136. UDP-Lite uses the same set of port numbers assigned by the Internet Assigned Numbers Authority (IANA) for use by UDP.

Support for UDP-Lite was added in the Linux kernel version 2.6.20.

Support for UDP-Lite was added in the FreeBSD kernel from r264212.[4] The changeset was also MFC'ed back to stable/10[5] and became available in FreeBSD 10.1-RELEASE.[6]

The BSD socket API is extended to support UDP-Lite by the third parameter of the socket system call: Set it to IPPROTO_UDPLITE to request a UDP-Lite socket:[7]

int fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);

One can also easily set what part of the packet will be covered by the checksum (starting from the beginning including header):

int val = 20; /* 8 octets of header + 12 octets of the application protocol. */
(void)setsockopt(fd, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof val);

If a packet smaller than 12 octets is sent in such a setup, the checksum will cover the whole packet.

On the receiving side a socket will by default drop all packets which are not covered completely (UDP emulation.) To permit for smaller coverage one can use:

int val = 20; /* 8 octets of header + 12 octets of the application protocol. */
(void)setsockopt(fd, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &val, sizeof val);

This will allow for packets where at minimum 12 octets of user data are checksummed. Any packet with a smaller coverage will be silently dropped as bad. If a packet has a coverage length of at least 20 octets (including header) and its checksum is correct, it will be delivered to application (whole or part of the payload can still be corrupted, because it could be not covered by checksum or because the checksum was correct incidentally, but the latter is very unlikely.) If the checksum is incorrect the packet will be dropped, because it is actually impossible to know if the error was inside the payload data or in the UDP-Lite header, so the packet could actually be destined for a different program.

The smallest possible coverage is 8 octets. Headers need to be included in checksum. Packets with a smaller length of coverage will always be dropped independent of any settings (ignoring sniffers which are interested in all traffic) as not conforming to standard.

Support

UDP-Lite is supported by the following operating systems:

References

  1. 1 2 "The Lightweight User Datagram Protocol (UDP-Lite), RFC 3828". Retrieved 2012-01-12.
  2. "Computing the Internet Checksum, RFC 1071". Retrieved 2012-01-12.
  3. "Corrupted Speech Data Considered Useful, 2003". Retrieved 2012-01-12.
  4. "Commit message for introduction into CURRENT". Retrieved 2014-07-26.
  5. "Commit message for MFC from CURRENT". Retrieved 2014-10-05.
  6. https://www.freebsd.org/releases/10.1R/relnotes.html
  7. "UDP-Lite Howto (kernel and userland applications)". Retrieved 2015-10-11.
  8. Laurent Guillo, Cécile Marc (10 January 2005). "WULL: A Windows UDP-Lite library" (PDF). IRISA. Retrieved 2015-12-15.

External links

This article is issued from Wikipedia - version of the 12/1/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.