Blame view

Documentation/networking/udplite.txt 11.3 KB
ba4e58eca   Gerrit Renker   [NET]: Supporting...
1
2
3
4
5
6
7
8
9
10
11
12
    ===========================================================================
                        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:
0ea6e6112   Justin P. Mattock   Documentation: up...
13
14
     o The UDP-Lite Homepage:
  	http://web.archive.org/web/*/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/ 
01dd2fbf0   Matt LaPlante   typo fixes
15
         From here you can also download some example application source code.
ba4e58eca   Gerrit Renker   [NET]: Supporting...
16
17
  
     o The UDP-Lite HOWTO on
0ea6e6112   Justin P. Mattock   Documentation: up...
18
19
         http://web.archive.org/web/*/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
  	files/UDP-Lite-HOWTO.txt
ba4e58eca   Gerrit Renker   [NET]: Supporting...
20
21
  
     o The Wireshark UDP-Lite WiKi (with capture files):
b07d49617   Masanari Iida   Doc: networking: ...
22
         https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
ba4e58eca   Gerrit Renker   [NET]: Supporting...
23
24
25
26
27
28
29
  
     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
0ea6e6112   Justin P. Mattock   Documentation: up...
30
    (now called wireshark) has UDP-Litev4/v6 support by default. 
ba4e58eca   Gerrit Renker   [NET]: Supporting...
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
    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
a982ac06b   Matt LaPlante   misc doc and kcon...
138
    and cannot be disabled using SO_NO_CHECK. Thus
ba4e58eca   Gerrit Renker   [NET]: Supporting...
139
140
141
142
143
144
145
146
  
          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
47112e25d   Gerrit Renker   udplite: Protecti...
147
    illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.
ba4e58eca   Gerrit Renker   [NET]: Supporting...
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
  
    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
01dd2fbf0   Matt LaPlante   typo fixes
222
    coverage lengths are likely to be expected.
ba4e58eca   Gerrit Renker   [NET]: Supporting...
223
224
225
226
227
228
229
230
231
232
233
  
  
    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.
cb75994ec   Wang Chen   [UDP]: Defer InDa...
234
     InDatagrams:     The total number of datagrams delivered to users.
ba4e58eca   Gerrit Renker   [NET]: Supporting...
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
  
     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.
01dd2fbf0   Matt LaPlante   typo fixes
257
    If you copy and paste the following line into /etc/protocols,
ba4e58eca   Gerrit Renker   [NET]: Supporting...
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
  
    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>.