123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278 |
- ===========================================================================
- The UDP-Lite protocol (RFC 3828)
- ===========================================================================
- UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
- is a variable-length checksum. This has advantages for transport of multimedia
- (video, VoIP) over wireless networks, as partly damaged packets can still be
- fed into the codec instead of being discarded due to a failed checksum test.
- This file briefly describes the existing kernel support and the socket API.
- For in-depth information, you can consult:
- o The UDP-Lite Homepage:
- http://web.archive.org/web/*/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
- From here you can also download some example application source code.
- o The UDP-Lite HOWTO on
- http://web.archive.org/web/*/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
- files/UDP-Lite-HOWTO.txt
- o The Wireshark UDP-Lite WiKi (with capture files):
- https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
- o The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
- I) APPLICATIONS
- Several applications have been ported successfully to UDP-Lite. Ethereal
- (now called wireshark) has UDP-Litev4/v6 support by default.
- Porting applications to UDP-Lite is straightforward: only socket level and
- IPPROTO need to be changed; senders additionally set the checksum coverage
- length (default = header length = 8). Details are in the next section.
- II) PROGRAMMING API
- UDP-Lite provides a connectionless, unreliable datagram service and hence
- uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
- very easy: simply add `IPPROTO_UDPLITE' as the last argument of the socket(2)
- call so that the statement looks like:
- s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
- or, respectively,
- s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);
- With just the above change you are able to run UDP-Lite services or connect
- to UDP-Lite servers. The kernel will assume that you are not interested in
- using partial checksum coverage and so emulate UDP mode (full coverage).
- To make use of the partial checksum coverage facilities requires setting a
- single socket option, which takes an integer specifying the coverage length:
- * Sender checksum coverage: UDPLITE_SEND_CSCOV
- For example,
- int val = 20;
- setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
- sets the checksum coverage length to 20 bytes (12b data + 8b header).
- Of each packet only the first 20 bytes (plus the pseudo-header) will be
- checksummed. This is useful for RTP applications which have a 12-byte
- base header.
- * Receiver checksum coverage: UDPLITE_RECV_CSCOV
- This option is the receiver-side analogue. It is truly optional, i.e. not
- required to enable traffic with partial checksum coverage. Its function is
- that of a traffic filter: when enabled, it instructs the kernel to drop
- all packets which have a coverage _less_ than this value. For example, if
- RTP and UDP headers are to be protected, a receiver can enforce that only
- packets with a minimum coverage of 20 are admitted:
- int min = 20;
- setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
- The calls to getsockopt(2) are analogous. Being an extension and not a stand-
- alone protocol, all socket options known from UDP can be used in exactly the
- same manner as before, e.g. UDP_CORK or UDP_ENCAP.
- A detailed discussion of UDP-Lite checksum coverage options is in section IV.
- III) HEADER FILES
- The socket API requires support through header files in /usr/include:
- * /usr/include/netinet/in.h
- to define IPPROTO_UDPLITE
- * /usr/include/netinet/udplite.h
- for UDP-Lite header fields and protocol constants
- For testing purposes, the following can serve as a `mini' header file:
- #define IPPROTO_UDPLITE 136
- #define SOL_UDPLITE 136
- #define UDPLITE_SEND_CSCOV 10
- #define UDPLITE_RECV_CSCOV 11
- Ready-made header files for various distros are in the UDP-Lite tarball.
- IV) KERNEL BEHAVIOUR WITH REGARD TO THE VARIOUS SOCKET OPTIONS
- To enable debugging messages, the log level need to be set to 8, as most
- messages use the KERN_DEBUG level (7).
- 1) Sender Socket Options
- If the sender specifies a value of 0 as coverage length, the module
- assumes full coverage, transmits a packet with coverage length of 0
- and according checksum. If the sender specifies a coverage < 8 and
- different from 0, the kernel assumes 8 as default value. Finally,
- if the specified coverage length exceeds the packet length, the packet
- length is used instead as coverage length.
- 2) Receiver Socket Options
- The receiver specifies the minimum value of the coverage length it
- is willing to accept. A value of 0 here indicates that the receiver
- always wants the whole of the packet covered. In this case, all
- partially covered packets are dropped and an error is logged.
- It is not possible to specify illegal values (<0 and <8); in these
- cases the default of 8 is assumed.
- All packets arriving with a coverage value less than the specified
- threshold are discarded, these events are also logged.
- 3) Disabling the Checksum Computation
- On both sender and receiver, checksumming will always be performed
- and cannot be disabled using SO_NO_CHECK. Thus
- setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, ... );
- will always will be ignored, while the value of
- getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
- is meaningless (as in TCP). Packets with a zero checksum field are
- illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.
- 4) Fragmentation
- The checksum computation respects both buffersize and MTU. The size
- of UDP-Lite packets is determined by the size of the send buffer. The
- minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
- in include/net/sock.h), the default value is configurable as
- net.core.wmem_default or via setting the SO_SNDBUF socket(7)
- option. The maximum upper bound for the send buffer is determined
- by net.core.wmem_max.
- Given a payload size larger than the send buffer size, UDP-Lite will
- split the payload into several individual packets, filling up the
- send buffer size in each case.
- The precise value also depends on the interface MTU. The interface MTU,
- in turn, may trigger IP fragmentation. In this case, the generated
- UDP-Lite packet is split into several IP packets, of which only the
- first one contains the L4 header.
- The send buffer size has implications on the checksum coverage length.
- Consider the following example:
- Payload: 1536 bytes Send Buffer: 1024 bytes
- MTU: 1500 bytes Coverage Length: 856 bytes
- UDP-Lite will ship the 1536 bytes in two separate packets:
- Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
- Packet 2: 512 payload + 8 byte header + 20 byte IP header = 540 bytes
- The coverage packet covers the UDP-Lite header and 848 bytes of the
- payload in the first packet, the second packet is fully covered. Note
- that for the second packet, the coverage length exceeds the packet
- length. The kernel always re-adjusts the coverage length to the packet
- length in such cases.
- As an example of what happens when one UDP-Lite packet is split into
- several tiny fragments, consider the following example.
- Payload: 1024 bytes Send buffer size: 1024 bytes
- MTU: 300 bytes Coverage length: 575 bytes
- +-+-----------+--------------+--------------+--------------+
- |8| 272 | 280 | 280 | 280 |
- +-+-----------+--------------+--------------+--------------+
- 280 560 840 1032
- ^
- *****checksum coverage*************
- The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
- header). According to the interface MTU, these are split into 4 IP
- packets (280 byte IP payload + 20 byte IP header). The kernel module
- sums the contents of the entire first two packets, plus 15 bytes of
- the last packet before releasing the fragments to the IP module.
- To see the analogous case for IPv6 fragmentation, consider a link
- MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
- coverage is less than 1232 bytes (MTU minus IPv6/fragment header
- lengths), only the first fragment needs to be considered. When using
- larger checksum coverage lengths, each eligible fragment needs to be
- checksummed. Suppose we have a checksum coverage of 3062. The buffer
- of 3356 bytes will be split into the following fragments:
- Fragment 1: 1280 bytes carrying 1232 bytes of UDP-Lite data
- Fragment 2: 1280 bytes carrying 1232 bytes of UDP-Lite data
- Fragment 3: 948 bytes carrying 900 bytes of UDP-Lite data
- The first two fragments have to be checksummed in full, of the last
- fragment only 598 (= 3062 - 2*1232) bytes are checksummed.
- While it is important that such cases are dealt with correctly, they
- are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
- performance over wireless (or generally noisy) links and thus smaller
- coverage lengths are likely to be expected.
- V) UDP-LITE RUNTIME STATISTICS AND THEIR MEANING
- Exceptional and error conditions are logged to syslog at the KERN_DEBUG
- level. Live statistics about UDP-Lite are available in /proc/net/snmp
- and can (with newer versions of netstat) be viewed using
- netstat -svu
- This displays UDP-Lite statistics variables, whose meaning is as follows.
- InDatagrams: The total number of datagrams delivered to users.
- NoPorts: Number of packets received to an unknown port.
- These cases are counted separately (not as InErrors).
- InErrors: Number of erroneous UDP-Lite packets. Errors include:
- * internal socket queue receive errors
- * packet too short (less than 8 bytes or stated
- coverage length exceeds received length)
- * xfrm4_policy_check() returned with error
- * application has specified larger min. coverage
- length than that of incoming packet
- * checksum coverage violated
- * bad checksum
- OutDatagrams: Total number of sent datagrams.
- These statistics derive from the UDP MIB (RFC 2013).
- VI) IPTABLES
- There is packet match support for UDP-Lite as well as support for the LOG target.
- If you copy and paste the following line into /etc/protocols,
- udplite 136 UDP-Lite # UDP-Lite [RFC 3828]
- then
- iptables -A INPUT -p udplite -j LOG
- will produce logging output to syslog. Dropping and rejecting packets also works.
- VII) MAINTAINER ADDRESS
- The UDP-Lite patch was developed at
- University of Aberdeen
- Electronics Research Group
- Department of Engineering
- Fraser Noble Building
- Aberdeen AB24 3UE; UK
- The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
- code was developed by William Stanislaus, <william@erg.abdn.ac.uk>.
|