idnits 2.17.1 draft-ietf-avt-crtp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 27, 1998) is 9404 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 961 looks like a reference -- Missing reference section? '2' on line 964 looks like a reference -- Missing reference section? '3' on line 991 looks like a reference -- Missing reference section? '4' on line 970 looks like a reference -- Missing reference section? '5' on line 972 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio/Video Transport Working Group 3 INTERNET-DRAFT S. Casner / Cisco Systems 4 draft-ietf-avt-crtp-05.txt V. Jacobson / LBNL 5 July 27, 1998 6 Expires: January 1999 8 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference material 20 or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 Abstract 32 This document describes a method for compressing the headers of 33 IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. 34 In many cases, all three headers can be compressed to 2-4 bytes. 36 Comments are solicited and should be addressed to the working group 37 mailing list rem-conf@es.net and/or the author(s). 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 41 this document are to be interpreted as described in RFC 2119. 43 1. Introduction 45 Since the Real-time Transport Protocol was published as an RFC [1], 46 there has been growing interest in using RTP as one step to achieve 47 interoperability among different implementations of network audio/video 48 applications. However, there is also concern that the 12-byte RTP 49 header is too large an overhead for 20-byte payloads when operating over 50 low speed lines such as dial-up modems at 14.4 or 28.8 kb/s. (Some 51 existing applications operating in this environment use an application- 52 specific protocol with a header of a few bytes that has reduced func- 53 tionality relative to RTP.) 55 Header size may be reduced through compression techniques as has been 56 done with great success for TCP [2]. In this case, compression might be 57 applied to the RTP header alone, on an end-to-end basis, or to the com- 58 bination of IP, UDP and RTP headers on a link-by-link basis. Compress- 59 ing the 40 bytes of combined headers together provides substantially 60 more gain than compressing 12 bytes of RTP header alone because the 61 resulting size is approximately the same (2-4 bytes) in either case. 62 Compressing on a link-by-link basis also provides better performance 63 because the delay and loss rate are lower. Therefore, the method 64 defined here is for combined compression of IP, UDP and RTP headers on a 65 link-by-link basis. 67 This document defines a compression scheme that may be used with IPv4, 68 IPv6 or packets encapsulated with more than one IP header, though the 69 initial focus is on IPv4. The IP/UDP/RTP compression defined here is 70 intended to fit within the more general compression framework specified 71 in [3] for use with both IPv6 and IPv4. That framework defines TCP and 72 non-TCP as two classes of transport above IP. This specification 73 creates IP/UDP/RTP as a third class extracted from the non-TCP class. 75 2. Assumptions and Tradeoffs 77 The goal of this compression scheme is to reduce the IP/UDP/RTP headers 78 to two bytes for most packets in the case where no UDP checksums are 79 being sent, or four bytes with checksums. It is motivated primarily by 80 the specific problem of sending audio and video over 14.4 and 28.8 81 dialup modems. These links tend to provide full-duplex communication, 82 so the protocol takes advantage of that fact, though the protocol may 83 also be used with reduced performance on simplex links. This compres- 84 sion scheme performs best on local links with low round-trip-time. 86 This specification does not address segmentation and preemption of large 87 packets to reduce the delay across the slow link experienced by small 88 real-time packets, except to identify in Section 4 some interactions 89 between segmentation and compression that may occur. Segmentation 90 schemes may be defined separately and used in conjunction with the 91 compression defined here. 93 It should be noted that implementation simplicity is an important factor 94 to consider in evaluating a compression scheme. Communications servers 95 may need to support compression over perhaps as many as 100 dial-up 96 modem lines using a single processor. Therefore, it may be appropriate 97 to make some simplifications in the design at the expense of generality, 98 or to produce a flexible design that is general but can be subsetted for 99 simplicity. Higher compression gain might be achieved by communicating 100 more complex models for the changing header fields from the compressor 101 to the decompressor, but that complexity is deemed unnecessary. The 102 next sections discuss some of the tradeoffs listed here. 104 2.1. Simplex vs. Full Duplex 106 In the absence of other constraints, a compression scheme that worked 107 over simplex links would be preferred over one that did not. However, 108 operation over a simplex link requires periodic refreshes with an 109 uncompressed packet header to restore compression state in case of 110 error. If an explicit error signal can be returned instead, the delay 111 to recovery may be shortened substantially. The overhead in the no- 112 error case is also reduced. To gain these performance improvements, 113 this specification includes an explicit error indication sent on the 114 reverse path. 116 On a simplex link, it would be possible to use a periodic refresh 117 instead. Whenever the decompressor detected an error in a particular 118 packet stream, it would simply discard all packets in that stream until 119 an uncompressed header was received for that stream, and then resume 120 decompression. The penalty would be the potentially large number of 121 packets discarded. The periodic refresh method described in Section 3.3 122 of [3] applies to IP/UDP/RTP compression on simplex links or links with 123 high delay as well as to other non-TCP packet streams. 125 2.2. Segmentation and Layering 127 Delay induced by the time required to send a large packet over the slow 128 link is not a problem for one-way audio, for example, because the 129 receiver can adapt to the variance in delay. However, for interactive 130 conversations, minimizing the end-to-end delay is critical. Segmenta- 131 tion of large, non-real-time packets to allow small real-time packets to 132 be transmitted between segments can reduce the delay. 134 This specification deals only with compression and assumes segmentation, 135 if included, will be handled as a separate layer. It would be inap- 136 propriate to integrate segmentation and compression in such a way that 137 the compression could not be used by itself in situations where segmen- 138 tation was deemed unnecessary or impractical. Similarly, one would like 139 to avoid any requirements for a reservation protocol. The compression 140 scheme can be applied locally on the two ends of a link independent of 141 any other mechanisms except for the requirements that the link layer 142 provide some packet type codes, a packet length indication, and good 143 error detection. 145 Conversely, separately compressing the IP/UDP and RTP layers loses too 146 much of the compression gain that is possible by treating them together. 147 Crossing these protocol layer boundaries is appropriate because the same 148 function is being applied across all layers. 150 3. The Compression Algorithm 152 The compression algorithm defined in this document draws heavily upon 153 the design of TCP/IP header compression as described in RFC 1144 [2]. 154 Readers are referred to that RFC for more information on the underlying 155 motivations and general principles of header compression. 157 3.1. The basic idea 159 In TCP header compression, the first factor-of-two reduction in data 160 rate comes from the observation that half of the bytes in the IP and TCP 161 headers remain constant over the life of the connection. After sending 162 the uncompressed header once, these fields may be elided from the 163 compressed headers that follow. The remaining compression comes from 164 differential coding on the changing fields to reduce their size, and 165 from eliminating the changing fields entirely for common cases by calcu- 166 lating the changes from the length of the packet. This length is indi- 167 cated by the link-level protocol. 169 For RTP header compression, some of the same techniques may be applied. 170 However, the big gain comes from the observation that although several 171 fields change in every packet, the difference from packet to packet is 172 often constant and therefore the second-order difference is zero. By 173 maintaining both the uncompressed header and the first-order differences 174 in the session state shared between the compressor and decompressor, all 175 that must be communicated is an indication that the second-order differ- 176 ence was zero. In that case, the decompressor can reconstruct the ori- 177 ginal header without any loss of information simply by adding the 178 first-order differences to the saved uncompressed header as each 179 compressed packet is received. 181 Just as TCP/IP header compression maintains shared state for multiple 182 simultaneous TCP connections, this IP/UDP/RTP compression SHOULD main- 183 tain state for multiple session contexts. A session context is defined 184 by the combination of the IP source and destination addresses, the UDP 185 source and destination ports, and the RTP SSRC field. A compressor 186 implementation might use a hash function on these fields to index a 187 table of stored session contexts. The compressed packet carries a small 188 integer, called the session context identifier or CID, to indicate in 189 which session context that packet should be interpreted. The decompres- 190 sor can use the CID to index its table of stored session contexts 191 directly. 193 Because the RTP compression is lossless, it may be applied to any UDP 194 traffic that benefits from it. Most likely, the only packets that will 195 benefit are RTP packets, but it is acceptable to use heuristics to 196 determine whether or not the packet is an RTP packet because no harm is 197 done if the heuristic gives the wrong answer. This does require execut- 198 ing the compression algorithm for all UDP packets, or at least those 199 with even port numbers (see section 3.4). 201 Most compressor implementations will need to maintain a "negative cache" 202 of packet streams that have failed to compress as RTP packets for some 203 number of attempts in order to avoid further attempts. Failing to 204 compress means that some fields in the potential RTP header that are 205 expected to remain constant most of the time, such as the payload type 206 field, keep changing. Even if the other such fields remain constant, a 207 packet stream with a constantly changing SSRC field SHOULD be entered in 208 the negative cache to avoid consuming all of the available session con- 209 texts. The negative cache is indexed by the source and destination IP 210 address and UDP port pairs but not the RTP SSRC field since the latter 211 may be changing. When RTP compression fails, the IP and UDP headers MAY 212 still be compressed. 214 Fragmented IP Packets that are not initial fragments and packets that 215 are not long enough to contain a complete UDP header MUST NOT be sent as 216 FULL_HEADER packets. Furthermore, packets that do not additionally con- 217 tain at least 12 bytes of UDP data MUST NOT be used to establish RTP 218 context. If such a packet is sent as a FULL_HEADER packet, it MAY be 219 followed by COMPRESSED_UDP packets but MUST NOT be followed by 220 COMPRESSED_RTP packets. 222 3.2. Header Compression for RTP Data Packets 224 In the IPv4 header, only the total length, packet ID, and header check- 225 sum fields will normally change. The total length is redundant with the 226 length provided by the link layer, and since this compression scheme 227 must depend upon the link layer to provide good error detection (e.g., 228 PPP's CRC [4]), the header checksum may also be elided. This leaves 229 only the packet ID, which, assuming no IP fragmentation, would not need 230 to be communicated. However, in order to maintain lossless compression, 231 changes in the packet ID will be transmitted. The packet ID usually 232 increments by one or a small number for each packet. (Some systems 233 increment the ID with the bytes swapped, which results in slightly less 234 compression.) In the IPv6 base header, there is no packet ID nor header 235 checksum and only the payload length field changes. 237 In the UDP header, the length field is redundant with the IP total 238 length field and the length indicated by the link layer. The UDP check- 239 sum field will be a constant zero if the source elects not to generate 240 UDP checksums. Otherwise, the checksum must be communicated intact in 241 order to preserve the lossless compression. Maintaining end-to-end 242 error detection for applications that require it is an important princi- 243 ple. 245 In the RTP header, the SSRC identifier is constant in a given context 246 since that is part of what identifies the particular context. For most 247 packets, only the sequence number and the timestamp will change from 248 packet to packet. If packets are not lost or misordered upstream from 249 the compressor, the sequence number will increment by one for each 250 packet. For audio packets of constant duration, the timestamp will 251 increment by the number of sample periods conveyed in each packet. For 252 video, the timestamp will change on the first packet of each frame, but 253 then stay constant for any additional packets in the frame. If each 254 video frame occupies only one packet, but the video frames are generated 255 at a constant rate, then again the change in the timestamp from frame to 256 frame is constant. Note that in each of these cases the second-order 257 difference of the sequence number and timestamp fields is zero, so the 258 next packet header can be constructed from the previous packet header by 259 adding the first-order differences for these fields that are stored in 260 the session context along with the previous uncompressed header. When 261 the second-order difference is not zero, the magnitude of the change is 262 usually much smaller than the full number of bits in the field, so the 263 size can be reduced by encoding the new first-order difference and 264 transmitting it rather than the absolute value. 266 The M bit will be set on the first packet of an audio talkspurt and the 267 last packet of a video frame. If it were treated as a constant field 268 such that each change required sending the full RTP header, this would 269 reduce the compression significantly. Therefore, one bit in the 270 compressed header will carry the M bit explicitly. 272 If the packets are flowing through an RTP mixer, most commonly for 273 audio, then the CSRC list and CC count will also change. However, the 274 CSRC list will typically remain constant during a talkspurt or longer, 275 so it need be sent only when it changes. 277 3.3. The protocol 279 The compression protocol must maintain a collection of shared informa- 280 tion in a consistent state between the compressor and decompressor. 281 There is a separate session context for each IP/UDP/RTP packet stream, 282 as defined by a particular combination of the IP source and destination 283 addresses, UDP source and destination ports, and the RTP SSRC field. 284 The number of session contexts to be maintained MAY be negotiated 285 between the compressor and decompressor. Each context is identified by 286 an 8- or 16-bit identifier, depending upon the number of contexts nego- 287 tiated, so the maximum number is 65536. Both uncompressed and 288 compressed packets MUST carry the context ID and a 4-bit sequence number 289 used to detect packet loss between the compressor and decompressor. 290 Each context has its own separate sequence number space so that a single 291 packet loss need only invalidate one context. 293 The shared information in each context consists of the following items: 295 o The full IP, UDP and RTP headers, possibly including a CSRC list, 296 for the last packet sent by the compressor or reconstructed by the 297 decompressor. 298 o The first-order difference for the IPv4 ID field, initialized to 1 299 whenever an uncompressed IP header for this context is received and 300 updated each time a delta IPv4 ID field is received in a compressed 301 packet. 302 o The first-order difference for the RTP timestamp field, initialized 303 to 0 whenever an uncompressed packet for this context is received 304 and updated each time a delta RTP timestamp field is received in a 305 compressed packet. 306 o The last value of the 4-bit sequence number, which is used to detect 307 packet loss between the compressor and decompressor. 308 o The current generation number for non-differential coding of UDP 309 packets with IPv6(see [3]). For IPv4, the generation number may be 310 set to zero if the COMPRESSED_NON_TCP packet type, defined below, is 311 never used. 312 o A context-specific delta encoding table (see section 3.3.4) may 313 optionally be negotiated for each context. 315 In order to communicate packets in the various uncompressed and 316 compressed forms, this protocol depends upon the link layer being able 317 to provide an indication of four new packet formats in addition to the 318 normal IPv4 and IPv6 packet formats: 320 FULL_HEADER - communicates the uncompressed IP header plus any fol- 321 lowing headers and data to establish the uncompressed header state 322 in the decompressor for a particular context. The FULL-HEADER 323 packet also carries the 8- or 16-bit session context identifier and 324 the 4-bit sequence number to establish synchronization between the 325 compressor and decompressor. The format is shown in section 3.3.1. 327 COMPRESSED_UDP - communicates the IP and UDP headers compressed to 328 6 or fewer bytes (often 2 if UDP checksums are disabled), followed 329 by any subsequent headers (possibly RTP) in uncompressed form, plus 330 data. This packet type is used when there are differences in the 331 usually constant fields of the (potential) RTP header. The RTP 332 header includes a potentially changed value of the SSRC field, so 333 this packet may redefine the session context. The format is shown 334 in section 3.3.3. 336 COMPRESSED_RTP - indicates that the RTP header is compressed along 337 with the IP and UDP headers. The size of this header may still be 338 just two bytes, or more if differences must be communicated. This 339 packet type is used when the second-order difference (at least in 340 the usually constant fields) is zero. It includes delta encodings 341 for those fields that have changed by other than the expected 342 amount to establish the first-order differences after an 343 uncompressed RTP header is sent and whenever they change. The for- 344 mat is shown in section 3.3.2. 346 CONTEXT_STATE - indicates a special packet sent from the decompres- 347 sor to the compressor to communicate a list of context IDs for 348 which synchronization has or may have been lost. This packet is 349 only sent across the point-to-point link so it requires no IP 350 header. The format is shown in section 3.3.5. 352 When this compression scheme is used with IPv6 as part of the general 353 header compression framework specified in [3], another packet type MAY 354 be used: 356 COMPRESSED_NON_TCP - communicates the compressed IP and UDP headers 357 as defined in [3] without differential encoding. If it were used 358 for IPv4, it would require one or two bytes more than the 359 COMPRESSED_UDP form listed above in order to carry the IPv4 ID 360 field. For IPv6, there is no ID field and this non-differential 361 compression is more resilient to packet loss. 363 Assignments of numeric codes for these packet formats in the Point-to- 364 Point Protocol [4] are to be made by the Internet Assigned Numbers 365 Authority. 367 3.3.1. FULL_HEADER (uncompressed) packet format 369 The definition of the FULL_HEADER packet given here is intended to be 370 the consistent with the definition given in [3]. Full details on design 371 choices are given there. 373 The format of the FULL_HEADER packet is the same as that of the original 374 packet. In the IPv4 case, this is usually an IP header, followed by a 375 UDP header and UDP payload that may be an RTP header and its payload. 376 However, the FULL_HEADER packet may also carry IP encapsulated packets, 377 in which case there would be two IP headers followed by UDP and possibly 378 RTP. Or in the case of IPv6, the packet may be built of some 379 combination of IPv6 and IPv4 headers. Each successive header is indi- 380 cated by the type field of the previous header, as usual. 382 The FULL_HEADER packet differs from the corresponding normal IPv4 or 383 IPv6 packet in that it must also carry the compression context ID and 384 the 4-bit sequence number. In order to avoid expanding the size of the 385 header, these values are inserted into length fields in the IP and UDP 386 headers since the actual length may be inferred from the length provided 387 by the link layer. Two 16-bit length fields are needed; these are taken 388 from the first two available headers in the packet. That is, for an 389 IPv4/UDP packet, the first length field is the total length field of the 390 IPv4 header, and the second is the length field of the UDP header. For 391 an IPv4 encapsulated packet, the first length field would come from the 392 total length field of the first IP header, and the second length field 393 would come from the total length field of the second IP header. 395 As specified in Sections 5.3.2 of [3], the position of the context ID 396 (CID) and 4-bit sequence number varies depending upon whether 8- or 16- 397 bit context IDs have been selected, as shown in the following diagram 398 (16 bits wide, with the most-significant bit is to the left): 400 For 8-bit context ID: 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |0|1| Generation| CID | First length field 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | 0 | seq | Second length field 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 For 16-bit context ID: 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |1|1| Generation| 0 | seq | First length field 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | CID | Second length field 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 The first bit in the first length field indicates the length of the CID. 421 The length of the CID MUST either be constant for all contexts or two 422 additional distinct packet types MUST be provided to separately indicate 423 COMPRESSED_UDP and COMPRESSED_RTP packet formats with 8- and 16-bit 424 CIDs. The second bit in the first length field is 1 to indicate that 425 the 4-bit sequence number is present, as is always the case for this 426 IP/UDP/RTP compression scheme. 428 The generation field is used with IPv6 for COMPRESSED_NON_TCP packets as 429 described in [3]. For IPv4-only implementations that do not use 430 COMPRESSED_NON_TCP packets, the compressor SHOULD set the generation 431 value to zero. For consistent operation between IPv4 and IPv6, the gen- 432 eration value is stored in the context when it is received by the 433 decompressor, and the most recent value is returned in the CONTEXT_STATE 434 packet. 436 When a FULL_HEADER packet is received, the complete set of headers is 437 stored into the context selected by the context ID. The 4-bit sequence 438 number is also stored in the context, thereby resynchronizing the 439 decompressor to the compressor. 441 When COMPRESSED_NON_TCP packets are used, the 4-bit sequence number is 442 inserted into the "Data Field" of that packet and the D bit is set as 443 described in Section 6 of [3]. When a COMPRESSED_NON_TCP packet is 444 received, the generation number is compared to the value stored in the 445 context. If they are not the same, the context is not up to date and 446 MUST be refreshed by a FULL_HEADER packet. If the generation does 447 match, then the compressed IP and UDP header information, the 4-bit 448 sequence number, and the (potential) RTP header are all stored into the 449 saved context. 451 The amount of memory required to store the context will vary depending 452 upon how many encapsulating headers are included in the FULL_HEADER 453 packet. The compressor and decompressor MAY negotiate a maximum header 454 size. 456 3.3.2. COMPRESSED_RTP packet format 458 When the second-order difference of the RTP header from packet to packet 459 is zero, the decompressor can reconstruct a packet simply by adding the 460 stored first-order differences to the stored uncompressed header 461 representing the previous packet. All that need be communicated is the 462 session context identifier and a small sequence number (not related to 463 the RTP sequence number) to maintain synchronization and detect packet 464 loss between the compressor and decompressor. 466 If the second-order difference of the RTP header is not zero for some 467 fields, the new first-order difference for just those fields is communi- 468 cated using a compact encoding. The new first-order difference values 469 are added to the corresponding fields in the uncompressed header in the 470 decompressor's session context, and are also stored explicitly in the 471 context to be added to the corresponding fields again on each subsequent 472 packet in which the second-order difference is zero. Each time the 473 first-order difference changes, it is transmitted and stored in the con- 474 text. 476 In practice, the only fields for which it is useful to store the first- 477 order difference are the IPv4 ID field and the RTP timestamp. For the 478 RTP sequence number field, the usual increment is 1. If the sequence 479 number changes by other than 1, the difference must be communicated but 480 does not set the expected difference for the next packet. Instead, the 481 expected first-order difference remains fixed at 1 so that the differ- 482 ence need not be explicitly communicated on the next packet assuming it 483 is in order. 485 For the RTP timestamp, when a FULL_HEADER, COMPRESSED_NON_TCP or 486 COMPRESSED_UDP packet is sent to refresh the RTP state, the stored 487 first-order difference is initialized to zero. If the timestamp is the 488 same on the next packet (e.g., same video frame), then the second-order 489 difference is zero. Otherwise, the difference between the timestamps of 490 the two packets is transmitted as the new first-order difference to be 491 added to the timestamp in the uncompressed header stored in the 492 decompressor's context and also stored as the first-order difference in 493 that context. Each time the first-order difference changes on subse- 494 quent packets, that difference is again transmitted and used to update 495 the context. 497 Similarly, since the IPv4 ID field frequently increments by one, the 498 first-order difference for that field is initialized to one when the 499 state is refreshed by a FULL_HEADER packet, or when a COMPRESSED_NON_TCP 500 packet is sent since it carries the ID field in uncompressed form. 501 Thereafter, whenever the first-order difference changes, it is transmit- 502 ted and stored in the context. 504 A bit mask will be used to indicate which fields have changed by other 505 than the expected difference. In addition to the small link sequence 506 number, the list of items to be conditionally communicated in the 507 compressed IP/UDP/RTP header is as follows: 509 I = IPv4 packet ID (always 0 if no IPv4 header) 510 U = UDP checksum 511 M = RTP marker bit 512 S = RTP sequence number 513 T = RTP timestamp 514 L = RTP CSRC count and list 516 If 4 bits are needed for the link sequence number to get a reasonable 517 probability of loss detection, there are too few bits remaining to 518 assign one bit to each of these items and still fit them all into a sin- 519 gle byte to go along with the context ID. 521 It is not necessary to explicitly carry the U bit to indicate the pres- 522 ence of the UDP checksum because a source will typically include check- 523 sums on all packets of a session or none of them. When the session 524 state is initialized with an uncompressed header, if there is a nonzero 525 checksum present, an unencoded 16-bit checksum will be inserted into the 526 compressed header in all subsequent packets until this setting is 527 changed by sending another uncompressed packet. 529 Of the remaining items, the L bit for the CSRC count and list may be the 530 one least frequently used. Rather than dedicating a bit in the mask to 531 indicate CSRC change, an unusual combination of the other bits may be 532 used instead. This bit combination is denoted MSTI. If all four of the 533 bits for the IP packet ID, RTP marker bit, RTP sequence number and RTP 534 timestamp are set, this is a special case indicating an extended form of 535 the compressed RTP header will follow. That header will include an 536 additional byte containing the real values of the four bits plus the CC 537 count. The CSRC list, of length indicated by the CC count, will be 538 included just as it appears in the uncompressed RTP header. 540 The other fields of the RTP header (version, P bit, X bit, payload type 541 and SSRC identifier) are assumed to remain relatively constant. In par- 542 ticular, the SSRC identifier is defined to be constant for a given con- 543 text because it is one of the factors selecting the context. If any of 544 the other fields change, the uncompressed RTP header MUST sent as 545 described in Section 3.3.3. 547 The following diagram shows the compressed IP/UDP/RTP header with dotted 548 lines indicating fields that are conditionally present. The most signi- 549 ficant bit is numbered 0. Multi-byte fields are sent in network byte 550 order (most significant byte first). The delta fields are often a sin- 551 gle byte as shown but may be two or three bytes depending upon the delta 552 value as explained in Section 3.3.4. 554 0 1 2 3 4 5 6 7 555 +...............................+ 556 : msb of session context ID : (if 16-bit CID) 557 +-------------------------------+ 558 | lsb of session context ID | 559 +---+---+---+---+---+---+---+---+ 560 | M | S | T | I | link sequence | 561 +---+---+---+---+---+---+---+---+ 562 : : 563 + UDP checksum + (if nonzero in context) 564 : : 565 +...............................+ 566 : : 567 + "RANDOM" fields + (if encapsulated) 568 : : 569 +...............................+ 570 : M'| S'| T'| I'| CC : (if MSTI = 1111) 571 +...............................+ 572 : delta IPv4 ID : (if I or I' = 1) 573 +...............................+ 574 : delta RTP sequence : (if S or S' = 1) 575 +...............................+ 576 : delta RTP timestamp : (if T or T' = 1) 577 +...............................+ 578 : : 579 : CSRC list : (if MSTI = 1111 580 : : and CC nonzero) 581 : : 582 +...............................+ 583 : : 584 : RTP header extension : (if X set in context) 585 : : 586 : : 587 +-------------------------------+ 588 | | 589 | RTP data | 590 / / 591 / / 592 | | 593 +-------------------------------+ 594 : padding : (if P set in context) 595 +...............................+ 597 When more than one IPv4 header is present in the context as 598 initialized by the FULL_HEADER packet, then the IP ID fields of 599 encapsulating headers MUST be sent as absolute values as described in 600 [3]. These fields are identified as "RANDOM" fields. They are 601 inserted into the COMPRESSED_RTP packet in the same order as they 602 appear in the original headers, immediately following the UDP checksum 603 if present or the MSTI byte if not, as shown in the diagram. Only if 604 an IPv4 packet immediately precedes the UDP header will the IP ID of 605 that header be sent differentially, i.e., potentially with no bits if 606 the second difference is zero, or as a delta IPv4 ID field if not. If 607 there is not an IPv4 header immediately preceding the UDP header, then 608 the I bit MUST be 0 and no delta IPv4 ID field will be present. 610 3.3.3. COMPRESSED_UDP packet format 612 If there is a change in any of the fields of the RTP header that are 613 normally constant (such as the payload type field), then an uncompressed 614 RTP header MUST be sent. If the IP and UDP headers do not also require 615 updating, this RTP header MAY be carried in a COMPRESSED_UDP packet 616 rather than a FULL_HEADER packet. The COMPRESSED_UDP packet has the 617 same format as the COMPRESSED_RTP packet except that the M, S and T bits 618 are always 0 and the corresponding delta fields are never included: 620 0 1 2 3 4 5 6 7 621 +...............................+ 622 : msb of session context ID : (if 16-bit CID) 623 +-------------------------------+ 624 | lsb of session context ID | 625 +---+---+---+---+---+---+---+---+ 626 | 0 | 0 | 0 | I | link sequence | 627 +---+---+---+---+---+---+---+---+ 628 : : 629 + UDP checksum + (if nonzero in context) 630 : : 631 +...............................+ 632 : : 633 + "RANDOM" fields + (if encapsulated) 634 : : 635 +...............................+ 636 : delta IPv4 ID : (if I = 1) 637 +-------------------------------+ 638 | UDP data | 639 : (uncompressed RTP header) : 641 Note that this constitutes a form of IP/UDP header compression different 642 from COMPRESSED_NON_TCP packet type defined in [3]. The motivation is 643 to allow reaching the target of two bytes when UDP checksums are dis- 644 abled, as IPv4 allows. The protocol in [3] does not use differential 645 coding for UDP packets, so in the IPv4 case, two bytes of IP ID, and two 646 bytes of UDP checksum if nonzero, would always be transmitted in 647 addition to two bytes of compression prefix. For IPv6, the 648 COMPRESSED_NON_TCP packet type MAY be used instead. 650 3.3.4. Encoding of differences 652 The delta fields in the COMPRESSED_RTP and COMPRESSED_UDP packets are 653 encoded with a variable-length mapping for compactness of the more 654 commonly-used values. A default encoding is specified below, but it is 655 RECOMMENDED that implementations use a table-driven delta encoder and 656 decoder to allow negotiation of a table specific for each session if 657 appropriate, possibly even an optimal Huffman encoding. Encodings based 658 on sequential interpretation of the bit stream, of which this default 659 table and Huffman encoding are examples, allow a reasonable table size 660 and may result in an execution speed faster than a non-table-driven 661 implementation with explicit tests for ranges of values. 663 The default delta encoding is specified in the following table. This 664 encoding was designed to efficiently encode the small changes that may 665 occur in the IP ID and in RTP sequence number when packets are lost 666 upstream from the compressor, yet still handling most audio and video 667 deltas in two bytes. The column on the left is the decimal value to be 668 encoded, and the column on the right is the resulting sequence of bytes 669 shown in hexadecimal and in the order in which they are transmitted 670 (network byte order). The first and last values in each contiguous 671 range are shown, with ellipses in between: 673 Decimal Hex 675 -16384 C0 00 00 676 : : 677 -129 C0 3F 7F 678 -128 80 00 679 : : 680 -1 80 7F 681 0 00 682 : : 683 127 7F 684 128 80 80 685 : : 686 16383 BF FF 687 16384 C0 40 00 688 : : 689 4194303 FF FF FF 691 For positive values, a change of zero through 127 is represented 692 directly in one byte. If the most significant two bits of the byte are 693 10 or 11, this signals an extension to a two- or three-byte value, 694 respectively. The least significant six bits of the first byte are 695 combined, in decreasing order of significance, with the next one or two 696 bytes to form a 14- or 22- bit value. 698 Negative deltas may occur when packets are misordered or in the inten- 699 tionally out-of-order RTP timestamps on MPEG video [5]. These events 700 are less likely, so a smaller range of negative values is encoded using 701 otherwise redundant portions of the positive part of the table. 703 A change in the RTP timestamp value less than -16384 or greater than 704 4194303 forces the RTP header to be sent uncompressed using a 705 FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet type. The IP 706 ID and RTP sequence number fields are only 16 bits, so negative deltas 707 for those fields SHOULD be masked to 16 bits and then encoded (as large 708 positive 16-bit numbers). 710 3.3.5. Error Recovery 712 Whenever the 4-bit sequence number for a particular context increments 713 by other than 1, except when set by a FULL_HEADER or COMPRESSED_NON_TCP 714 packet, the decompressor MUST invalidate that context and send a 715 CONTEXT_STATE packet back to the compressor indicating that the context 716 has been invalidated. All packets for the invalid context MUST be dis- 717 carded until a FULL_HEADER or COMPRESSED_NON_TCP packet is received for 718 that context to re-establish consistent state (unless the "twice" algo- 719 rithm is used as described later in this section). Since multiple 720 compressed packets may arrive in the interim, the decompressor SHOULD 721 NOT retransmit the CONTEXT_STATE packet for every compressed packet 722 received, but instead SHOULD limit the rate of retransmission to avoid 723 flooding the reverse channel. 725 When an error occurs on the link, the link layer will usually discard 726 the packet that was damaged (if any), but may provide an indication of 727 the error. Some time may elapse before another packet is delivered for 728 the same context, and then that packet would have to be discarded by the 729 decompressor when it is observed to be out of sequence, resulting in at 730 least two packets lost. To allow faster recovery if the link does pro- 731 vide an explicit error indication, the decompressor MAY optionally send 732 an advisory CONTEXT_STATE packet listing the last valid sequence number 733 and generation number for one or more recently active contexts (not 734 necessarily all). For a given context, if the compressor has sent no 735 compressed packet with a higher sequence number, and if the generation 736 number matches the current generation, no corrective action is required. 737 Otherwise, the compressor MAY choose to mark the context invalid so that 738 the next packet is sent in FULL_HEADER or COMPRESSED_NON_TCP mode 739 (FULL_HEADER is required if the generation doesn't match). However, 740 note that if the link round-trip-time is large compared to the inter- 741 packet spacing, there may be several packets from multiple contexts in 742 flight across the link, increasing the probability that the sequence 743 numbers will already have advanced when the CONTEXT_STATE packet is 744 received by the compressor. The result could be that some contexts are 745 invalidated unnecessarily, causing extra bandwidth to be consumed. 747 The format of the CONTEXT_STATE packet is shown in the following 748 diagrams. The first byte is a type code to allow the CONTEXT_STATE 749 packet type to be shared by multiple compression schemes within the gen- 750 eral compression framework specified in [3]. The contents of the 751 remainder of the packet depends upon the compression scheme. For the 752 IP/UDP/RTP compression scheme specified here, the remainder of the 753 CONTEXT_STATE packet is structured as a list of blocks to allow the 754 state for multiple contexts to be indicated, preceded by a one-byte 755 count of the number of blocks. 757 Two type code values are used for the IP/UDP/RTP compression scheme. The 758 value 1 indicates that 8-bit session context IDs are being used: 760 0 1 2 3 4 5 6 7 761 +---+---+---+---+---+---+---+---+ 762 | 1 = IP/UDP/RTP with 8-bit CID | 763 +---+---+---+---+---+---+---+---+ 764 | context count | 765 +---+---+---+---+---+---+---+---+ 766 +---+---+---+---+---+---+---+---+ 767 | session context ID | 768 +---+---+---+---+---+---+---+---+ 769 | I | 0 | 0 | 0 | sequence | 770 +---+---+---+---+---+---+---+---+ 771 | 0 | 0 | generation | 772 +---+---+---+---+---+---+---+---+ 773 ... 774 +---+---+---+---+---+---+---+---+ 775 | session context ID | 776 +---+---+---+---+---+---+---+---+ 777 | I | 0 | 0 | 0 | sequence | 778 +---+---+---+---+---+---+---+---+ 779 | 0 | 0 | generation | 780 +---+---+---+---+---+---+---+---+ 782 The value 2 indicates that 16-bit session context IDs are being used. 783 The session context ID is sent in network byte order (most significant 784 byte first): 786 0 1 2 3 4 5 6 7 787 +---+---+---+---+---+---+---+---+ 788 | 2 = IP/UDP/RTP with 16-bit CID| 789 +---+---+---+---+---+---+---+---+ 790 | context count | 791 +---+---+---+---+---+---+---+---+ 792 +---+---+---+---+---+---+---+---+ 793 | | 794 + session context ID + 795 | | 796 +---+---+---+---+---+---+---+---+ 797 | I | 0 | 0 | 0 | sequence | 798 +---+---+---+---+---+---+---+---+ 799 | 0 | 0 | generation | 800 +---+---+---+---+---+---+---+---+ 801 ... 802 +---+---+---+---+---+---+---+---+ 803 | | 804 + session context ID + 805 | | 806 +---+---+---+---+---+---+---+---+ 807 | I | 0 | 0 | 0 | sequence | 808 +---+---+---+---+---+---+---+---+ 809 | 0 | 0 | generation | 810 +---+---+---+---+---+---+---+---+ 812 The bit labeled "I" is set to one for contexts that have been marked 813 invalid and require a FULL_HEADER of COMPRESSED_NON_TCP packet to be 814 transmitted. If the I bit is zero, the context state is advisory. The 815 I bit is set to zero to indicate advisory context state that MAY be sent 816 following a link error indication. 818 Since the CONTEXT_STATE packet itself may be lost, retransmission of one 819 or more blocks is allowed. It is expected that retransmission will be 820 triggered only by receipt of another packet, but if the line is near 821 idle, retransmission MAY be triggered by a relatively long timer (on the 822 order of 1 second). 824 If a CONTEXT_STATE block for a given context is retransmitted, it may 825 cross paths with the FULL_HEADER or COMPRESSED_NON_TCP packet intended 826 to refresh that context. In that case, the compressor MAY choose to 827 ignore the error indication. 829 In the case where UDP checksums are being transmitted, the decompressor 830 MAY attempt to use the "twice" algorithm described in section 10.1 of 831 [3]. In this algorithm, the delta is applied more than once on the 832 assumption that the delta may have been the same on the missing 833 packet(s) and the one subsequently received. Success is indicated by a 834 checksum match. For the scheme defined here, the difference in the 4- 835 bit sequence number tells number of times the delta must be applied. 836 Note, however, that there is a nontrivial risk of an incorrect positive 837 indication. It may be advisable to request a FULL_HEADER or 838 COMPRESSED_NON_TCP packet even if the "twice" algorithm succeeds. 840 Some errors may not be detected, for example if 16 packets are lost in a 841 row and the link level does not provide an error indication. In that 842 case, the decompressor will generate packets that are not valid. If UDP 843 checksums are being transmitted, the receiver will probably detect the 844 invalid packets and discard them, but the receiver does not have any 845 means to signal the decompressor. Therefore, it is RECOMMENDED that the 846 decompressor verify the UDP checksum periodically, perhaps one out of 16 847 packets. If an error is detected, the decompressor would invalidate the 848 context and signal the compressor with a CONTEXT_STATE packet. 850 3.4. Compression of RTCP Control Packets 852 By relying on the RTP convention that data is carried on an even port 853 number and the corresponding RTCP packets are carried on the next higher 854 (odd) port number, one could tailor separate compression schemes to be 855 applied to RTP and RTCP packets. For RTCP, the compression could apply 856 not only to the header but also the "data", that is, the contents of the 857 different packet types. The numbers in Sender Report (SR) and Receiver 858 Report (RR) RTCP packets would not compress well, but the text informa- 859 tion in the Source Description (SDES) packets could be compressed down 860 to a bit mask indicating each item that was present but compressed out 861 (for timing purposes on the SDES NOTE item and to allow the end system 862 to measure the average RTCP packet size for the interval calculation). 864 However, in the compression scheme defined here, no compression will be 865 done on the RTCP headers and "data" for several reasons (though compres- 866 sion SHOULD still be applied to the IP and UDP headers). Since the RTP 867 protocol specification suggests that the RTCP packet interval be scaled 868 so that the aggregate RTCP bandwidth used by all participants in a ses- 869 sion will be no more than 5% of the session bandwidth, there is not much 870 to be gained from RTCP compression. Compressing out the SDES items 871 would require a significant increase in the shared state that must be 872 stored for each context ID. And, in order to allow compression when 873 SDES information for several sources was sent through an RTP "mixer", it 874 would be necessary to maintain a separate RTCP session context for each 875 SSRC identifier. In a session with more than 255 participants, this 876 would cause perfect thrashing of the context cache even when only one 877 participant was sending data. 879 Even though RTCP is not compressed, the fraction of the total bandwidth 880 occupied by RTCP packets on the compressed link remains no more than 5% 881 in most cases, assuming that the RTCP packets are sent as COMPRESSED_UDP 882 packets. Given that the uncompressed RTCP traffic consumes no more than 883 5% of the total session bandwidth, then for a typical RTCP packet length 884 of 90 bytes, the portion of the compressed bandwidth used by RTCP will 885 be no more than 5% if the size of the payload in RTP data packets is at 886 least 108 bytes. If the size of the RTP data payload is smaller, the 887 fraction will increase, but is still less than 7% for a payload size of 888 37 bytes. For large data payloads, the compressed RTCP fraction is less 889 than the uncompressed RTCP fraction (for example, 4% at 1000 bytes). 891 3.5. Compression of non-RTP UDP Packets 893 As described earlier, the COMPRESSED_UDP packet MAY be used to compress 894 UDP packets that don't carry RTP. Whatever data follows the UDP header 895 is unlikely to have some constant values in the bits that correspond to 896 usually constant fields in the RTP header. In particular, the SSRC 897 field would likely change. Therefore, it is necessary to keep track of 898 the non-RTP UDP packet streams to avoid using up all the context slots 899 as the "SSRC field" changes (since that field is part of what identifies 900 a particular RTP context). Those streams may each be given a context, 901 but the encoder would set a flag in the context to indicate that the 902 changing SSRC field should be ignored and COMPRESSED_UDP packets should 903 always be sent instead of COMPRESSED_RTP packets. 905 4. Interaction With Segmentation 907 A segmentation scheme may be used in conjunction with RTP header 908 compression to allow small, real-time packets to interrupt large, 909 presumably non-real-time packets in order to reduce delay. It is 910 assumed that the large packets bypass the compressor and decompressor 911 since the interleaving would modify the sequencing of packets at the 912 decompressor and cause the appearance of errors. Header compression 913 should be less important for large packets since the overhead ratio is 914 smaller. 916 If some packets from an RTP session context are selected for segmenta- 917 tion (perhaps based on size) and some are not, there is a possibility of 918 re-ordering. This would reduce the compression efficiency because the 919 large packets would appear as lost packets in the sequence space. How- 920 ever, this should not cause more serious problems because the RTP 921 sequence numbers should be reconstructed correctly and will allow the 922 application to correct the ordering. 924 Link errors detected by the segmentation scheme using its own sequencing 925 information MAY be indicated to the compressor with an advisory 926 CONTEXT_STATE message just as for link errors detected by the link layer 927 itself. 929 The context ID byte is placed first in the COMPRESSED_RTP header so that 930 this byte MAY be shared with the segmentation layer if such sharing is 931 feasible and has been negotiated. Since the compressor may assign con- 932 text ID values arbitrarily, the value can be set to match the context 933 identifier from the segmentation layer. 935 5. Negotiating Compression 937 The use of IP/UDP/RTP compression over a particular link is a function 938 of the link-layer protocol. It is expected that such negotiation will 939 be defined separately for PPP [4], for example. The following items MAY 940 be negotiated: 942 o The size of the context ID. 943 o The maximum size of the stack of headers in the context. 944 o A context-specific table for decoding of delta values. 946 6. Acknowledgments 948 Several people have contributed to the design of this compression scheme 949 and related problems. Scott Petrack initiated discussion of RTP header 950 compression in the AVT working group at Los Angeles in March, 1996. 951 Carsten Bormann has developed an overall architecture for compression in 952 combination with traffic control across a low-speed link, and made 953 several specific contributions to the scheme described here. David Oran 954 independently developed a note based on similar ideas, and suggested the 955 use of PPP Multilink protocol for segmentation. Mikael Degermark has 956 contributed advice on integration of this compression scheme with the 957 IPv6 compression framework. 959 7. References: 961 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 962 A Transport Protocol for real-time applications," RFC 1889. 964 [2] V. Jacobson, "TCP/IP Compression for Low-Speed Serial Links," 965 RFC 1144. 967 [3] M. Degermark, B. Nordgren, and S. Pink, "Header Compression for 968 IPv6," work in progress. 970 [4] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1548. 972 [5] D. Hoffman, G. Fernando, V. Goyal, M. Civanlar, "RTP Payload 973 Format for MPEG1/MPEG2 Video", RFC 2250. 975 8. Security Considerations 977 Because encryption eliminates the redundancy that this compression 978 scheme tries to exploit, there is some inducement to forego encryption 979 in order to achieve operation over a low-bandwidth link. However, for 980 those cases where encryption of data and not headers is satisfactory, 981 RTP does specify an alternative encryption method in which only the RTP 982 payload is encrypted and the headers are left in the clear. That would 983 allow compression to still be applied. 985 A malfunctioning or malicious compressor could cause the decompressor to 986 reconstitute packets that do not match the original packets but still 987 have valid IP, UDP and RTP headers and possibly even valid UDP check- 988 sums. Such corruption may be detected with end-to-end authentication 989 and integrity mechanisms which will not be affected by the compression. 990 Constant portions of authentication headers will be compressed as 991 described in [3]. 993 No authentication is performed on the CONTEXT_STATE control packet sent 994 by this protocol. An attacker with access to the link between the 995 decompressor and compressor could inject false CONTEXT_STATE packets and 996 cause compression efficiency to be reduced, probably resulting in 997 congestion on the link. However, an attacker with access to the link 998 could also disrupt the traffic in many other ways. 1000 A potential denial-of-service threat exists when using compression tech- 1001 niques that have non-uniform receiver-end computational load. The 1002 attacker can inject pathological datagrams into the stream which are 1003 complex to decompress and cause the receiver to be overloaded and 1004 degrading processing of other streams. However, this compression does 1005 not exhibit any significant non-uniformity. 1007 A security review of this protocol found no additional security con- 1008 siderations. 1010 9. Authors' Addresses 1012 Stephen L. Casner 1013 Cisco Systems, Inc. 1014 1072 Arastradero Road 1015 Palo Alto, CA 94304 1016 United States 1017 EMail: casner@cisco.com 1019 Van Jacobson 1020 MS 50A-3111 1021 Lawrence Berkeley National Laboratory 1022 Berkeley, CA 94720 1023 United States 1024 EMail: van@ee.lbl.gov