idnits 2.17.1 draft-ietf-avt-crtp-enhance-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2508]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 501 has weird spacing: '...ime pkt upd...' == Line 547 has weird spacing: '...ime pkt upd...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC2508' is mentioned on line 44, but not defined == Missing Reference: 'RFC2119' is mentioned on line 174, but not defined == Unused Reference: 'CRTP' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'KEYW' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RTP' is defined on line 677, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2509 (ref. 'IPCPHC') (Obsoleted by RFC 3544) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Audio/Video Transport Working Group Tmima Koren 2 Internet Draft Cisco Systems 3 July 16, 2001 Stephen Casner 4 Expires March 2002 Packet Design 5 draft-ietf-avt-crtp-enhance-02.txt John Geevarghese 6 Telseon 7 Bruce Thompson 8 Patrick Ruddy 9 Cisco Systems 11 Compressing IP/UDP/RTP headers on links with high delay, 12 packet loss and reordering 14 Status of this memo 16 This document is an Internet Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 Areas, and its Working Groups. Note that other groups may also 20 distribute working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsolete by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as "work in 26 progress". 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.txt 34 This draft is a work item of the IETF Audio/Video Transport working 35 group. The working group mailing list is avt@ietf.org. Subscribe via 36 the web at http://www.ietf.org/mailman/listinfo/avt. 38 Copyright (C) The Internet Society (1999-2001). All Rights Reserved. 40 Abstract 42 This document describes a header compression scheme for point to 43 point links with packet loss and long delays. It is based on CRTP, 44 the IP/UDP/RTP header compression described in [RFC2508]. CRTP does 45 not perform well on such links: packet loss results in context 46 corruption and due to the long delay, many more packets are 47 discarded before the context is repaired. To correct the behavior of 48 CRTP over such links, a few extensions to the protocol are specified 49 here. The extensions aim to reduce context corruption by changing 50 the way the compressor updates the context at the decompressor: 51 updates are repeated and include updates to full and differential 52 context parameters. With these extensions, CRTP performs well over 53 links with packet loss, packet reordering and long delays. 55 The IPCP option 'IP header compression' (described in RFC 2509) is 56 also extended to negotiate using the extended CRTP. 58 1.0 Introduction 60 RTP header compression (CRTP) as described in RFC 2508 was designed 61 to reduce the header overhead of IP/UDP/RTP datagrams by compressing 62 the three headers. The IP/UDP/RTP headers are compressed to 2-4 63 bytes most of the time. 65 CRTP was designed for reliable point to point links with short 66 delays. It does not perform well over links with high rate of packet 67 loss, packet reordering and long delays. 69 An example of such a link is a PPP session that is tunneled using an 70 IP level tunneling protocol such as L2TP. Packets within the tunnel 71 are carried by an IP network and hence may get lost and reordered. 72 The longer the tunnel, the longer the round trip time. 74 Another example is an IP network that uses layer 2 technologies such 75 as ATM and Frame Relay for the access portion of the network. Layer 76 2 transport networks such as ATM and Frame Relay behave like point 77 to point serial links in that they do not reorder packets. In 78 addition, Frame Relay and ATM virtual circuits used as IP access 79 technologies often have a low bit rate associated with them. These 80 virtual circuits differ from low speed serial links in that they may 81 span a larger physical distance than a point to point serial link. 82 Speed of light delays within the layer 2 transport network will 83 result in higher round trip delays between the endpoints of the 84 circuit. In addition, congestion within the layer 2 transport 85 network may result in an effective drop rate for the virtual circuit 86 which is significantly higher than error rates typically experienced 87 on point to point serial links. 89 CRTP is widely deployed and has relatively low computational 90 complexity. It is desirable to extend its usage over such links. 91 This can be achieved with a few simple extensions to the protocol. 93 1.1 CRTP Operation 95 During compression of an RTP stream, a session context is defined. 96 For each context, the session state is established and shared 97 between the compressor and the decompressor. Once the context state 98 is established, compressed packets may be sent. 100 The context state consists of the full IP/UDP/RTP headers, a few 101 first order differential values, a link sequence number, a 102 generation number and a delta encoding table. 104 The headers part of the context is set by the FULL_HEADER packet 105 that always starts a compression session. The first order 106 differential values (delta values) are set by sending COMPRESSED_RTP 107 packets that include updates to the delta values. 109 The context state must be synchronized between compressor and 110 decompressor for successful decompression to take place. If the 111 context gets out of sync, the decompressor is not able to restore 112 the compressed headers accurately. The decompressor invalidates the 113 context and sends a CONTEXT_STATE packet to the compressor 114 indicating that the context has been corrupted. To resume 115 compression, the compressor must reestablish the context. 117 During the time the context is corrupted, the decompressor discards 118 all the packets received for that context. Since the context repair 119 mechanism in CRTP involves feedback from the decompressor, context 120 repair takes at least as much time as the round trip time of the 121 link. If the round trip time of the link is long, and especially if 122 the link bandwidth is high, many packets will be discarded before 123 the context is repaired. On such links it is desirable to minimize 124 context invalidation. 126 1.2 How do contexts get corrupted? 128 As long as the fields in the combined IP/UDP/RTP headers change as 129 expected for the sequence of packets in a session, those headers can 130 be compressed, and the decompressor can fully restore the compressed 131 headers using the context state. When the headers don't change as 132 expected it's necessary to update some of the full or the delta 133 values of the context. For example, the RTP timestamp is expected to 134 increment by delta RTP timestamp (dT). If silence suppression is 135 used, packets are not sent during silence periods. Then when voice 136 activity resumes, packets are sent again, but the RTP timestamp is 137 incremented by a large value and not by dT. In this case an update 138 must be sent. 140 If a packet that includes an update to some context state values is 141 lost, the state at the decompressor is not updated. The shared state 142 is now different at the compressor and decompressor. When the next 143 packet arrives at the decompressor, the decompressor will fail to 144 restore the compressed headers accurately since the context state at 145 the decompressor is different than the state at the compressor. 147 1.3 Preventing context corruption 149 Note that the decompressor fails not when a packet is lost, but when 150 the next compressed packet arrives. If the next packet happens to 151 include the same context update as in the lost packet, the context 152 at the decompressor may be updated successfully and decompression 153 may continue uninterrupted. If the lost packet included an update to 154 a delta field such as the delta RTP timestamp (dT), the next packet 155 can't compensate for the loss since the update of a delta value is 156 relative to the previous packet which was lost. But if the update is 157 for an absolute value such as the full RTP timestamp or the RTP 158 payload type, this update can be repeated in the next packet 159 independently of the lost packet. Hence it is useful to be able to 160 update the absolute values of the context. 162 The next chapter describes several extensions to CRTP that add the 163 capability to selectively update absolute values of the context, 164 rather than sending a FULL_HEADER packet, in addition to the 165 existing updates of the delta values. This enhanced version of CRTP 166 is intended to minimize context invalidation and thus improve the 167 performance over lossy links with a long round trip time. 169 1.4 Specification of Requirements 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 2. Enhanced CRTP 177 This chapter specifies the changes in this enhanced version of CRTP. 178 They are: 180 - Extensions to the COMPRESSED_UDP packet to allow updating the 181 differential RTP values in the decompressor context and to 182 selectively update the absolute IP ID and RTP values. This 183 allows context sync to be maintained even with some packet 184 loss. 186 - A 'headers checksum' to be inserted by the compressor and 187 removed by the decompressor when the UDP checksum is not 188 present so that validation of the decompressed headers is 189 still possible. This allows the decompressor to verify that 190 context sync has not been lost after a packet loss. 192 An algorithm is then described to use these changes with repeated 193 updates to achieve robust operation over links with packet loss and 194 long delay. 196 2.1 Extended COMPRESSED_UDP packet 198 It is possible to accommodate some packet loss between the 199 compressor and decompressor using the "twice" algorithm in RFC 2508 200 so long as the context remains in sync. This requires reliably 201 communicating both the absolute value and the delta value whenever 202 the delta value changes. For many environments, sufficient 203 reliability can be achieved by repeating the update with each of 204 several successive packets. 206 The COMPRESSED_UDP packet satisfies the need to communicate the 207 absolute values of the differential RTP fields, but it is specified 208 in RFC 2508 to reset the delta RTP timestamp. That limitation can be 209 removed with the following simple change: RFC 2508 describes the 210 format of COMPRESSED_UDP as being the same as COMPRESSED_RTP except 211 that the M, S and T bits are always 0 and the corresponding delta 212 fields are never included. This enhanced version of CRTP changes 213 that specification to say that the T bit may be nonzero to indicate 214 that the delta RTP timestamp is included explicitly rather than 215 being reset to zero. 217 A second change adds another byte of flag bits to the COMPRESSED_UDP 218 packet to allow only selected individual uncompressed fields of the 219 RTP header to be included in the packet rather than carrying the 220 full RTP header as part of the UDP data. The additional flags do 221 increase computational complexity somewhat, but the corresponding 222 increase in bit efficiency is important when the differential field 223 updates are communicated multiple times in successive COMPRESSED_UDP 224 packets. With this change, there are flag bits to indicate 225 inclusion of both delta values and absolute values, so the flag 226 nomenclature is changed. The original S, T, I bits which indicate 227 the inclusion of deltas are renamed dS, dT, dI, and the inclusion of 228 absolute values is indicated by S, T, I. The M bit is absolute as 229 before. A new flag P indicates inclusion of the absolute RTP payload 230 type value and, as in the COMPRESSED_RTP packet, a four-bit CC field 231 copies the absolute value of the CC field in the RTP header. 233 The last of the three changes to the COMPRESSED_UDP packet deals 234 with updating the IP ID field. For this field, the COMPRESSED_UDP 235 packet as specified in RFC 2508 can already convey a new value for 236 the delta IP ID, but not the absolute value which is only conveyed 237 by the FULL_HEADER packet. Therefore, a new flag I is added to the 238 COMPRESSED_UDP packet to indicate inclusion of the absolute IP ID 239 value. The I flag replaces the dS flag which is not needed in the 240 COMPRESSED_UDP packet since the delta RTP sequence number always 241 remains 1 in the decompressor context and hence does not need to be 242 updated. 244 The format of the flags/sequence byte for the original 245 COMPRESSED_UDP packet is shown here for reference: 247 +---+---+---+---+---+---+---+---+ 248 | 0 | 0 | 0 |dI | link sequence | 249 +---+---+---+---+---+---+---+---+ 251 The new definition of the flags/sequence byte plus an extension 252 flags byte for the COMPRESSED_UDP packet is as follows, where the 253 new F flag indicates the inclusion of the extension flags byte: 255 +---+---+---+---+---+---+---+---+ 256 | F | I |dT |dI | link sequence | 257 +---+---+---+---+---+---+---+---+ 258 : M : S : T : P : CC : (if F = 1) 259 +...+...+...+...+...............+ 261 dI = delta IP ID 262 dT = delta RTP timestamp 263 I = absolute IP ID 264 F = additional flags byte 265 M = marker bit 266 S = absolute RTP sequence number 267 T = absolute RTP timestamp 268 P = RTP payload type 269 CC = number of CSRC identifiers 270 When F=0, there is only one flags byte, and the only available flags 271 are: dI, dT and I. In this case the packet includes the full RTP 272 header. As in RFC 2508, if dI=0, the decompressor does not change 273 deltaI. If dT=0, the decompressor sets deltaT to 0. 275 Some example packet formats will illustrate the use of the new 276 flags. First, when F=0, the 'traditional' COMPRESSED_UDP packet 277 which carries the full RTP header as part of the UDP data: 279 0 1 2 3 4 5 6 7 280 +...............................+ 281 : msb of session context ID : (if 16-bit CID) 282 +-------------------------------+ 283 | lsb of session context ID | 284 +---+---+---+---+---+---+---+---+ 285 |F=0| I |dT |dI | link sequence | 286 +---+---+---+---+---+---+---+---+ 287 : : 288 + UDP checksum + (if nonzero in context) 289 : : 290 +...............................+ 291 : : 292 + "RANDOM" fields + (if encapsulated) 293 : : 294 +...............................+ 295 : delta IPv4 ID : (if dI = 1) 296 +...............................+ 297 : delta RTP timestamp : (if dT = 1) 298 +...............................+ 299 : : 300 + IPv4 ID + (if I = 1) 301 : : 302 +...............................+ 303 | UDP data | 304 : (uncompressed RTP header) : 306 When F=1, there is an additional flags byte and the available flags 307 are: dI, dT, I, M, S, T, P, CC. In this case the packet does not 308 include the full RTP header, but includes selected fields from the 309 RTP header as specified by the flags. As in RFC 2508, if dI=0 the 310 decompressor does not change deltaI. However, in contrast to RFC 311 2508, if dT=0 the decompressor KEEPS THE CURRENT deltaT in the 312 context (DOES NOT set deltaT to 0). 314 An enhanced COMPRESSED_UDP packet is similar in contents and 315 behavior to a COMPRESSED_RTP packet, but it has more flag bits, some 316 of which correspond to absolute values for RTP header fields. 318 COMPRESSED_UDP with individual RTP fields, when F=1: 320 0 1 2 3 4 5 6 7 321 +...............................+ 322 : msb of session context ID : (if 16-bit CID) 323 +-------------------------------+ 324 | lsb of session context ID | 325 +---+---+---+---+---+---+---+---+ 326 |F=1| I |dT |dI | link sequence | 327 +---+---+---+---+---+---+---+---+ 328 | M | S | T | P | CC | 329 +---+---+---+---+---------------+ 330 : : 331 + UDP checksum + (if nonzero in context) 332 : : 333 +...............................+ 334 : : 335 : "RANDOM" fields : (if encapsulated) 336 : : 337 +...............................+ 338 : delta IPv4 ID : (if dI = 1) 339 +...............................+ 340 : delta RTP timestamp : (if dT = 1) 341 +...............................+ 342 : : 343 + IPv4 ID + (if I = 1) 344 : : 345 +...............................+ 346 : : 347 + RTP sequence number + (if S = 1) 348 : : 349 +...............................+ 350 : : 351 + + 352 : : 353 + RTP timestamp + (if T = 1) 354 : : 355 + + 356 : : 357 +...............................+ 358 : RTP payload type : (if P = 1) 359 +...............................+ 360 : : 361 : CSRC list : (if CC > 0) 362 : : 363 +...............................+ 364 : : 365 : RTP header extension : (if X set in context) 366 : : 367 +-------------------------------+ 368 | | 369 / RTP data / 370 / / 371 | | 372 +-------------------------------+ 373 : padding : (if P set in context) 374 +...............................+ 375 Usage for the enhanced COMPRESSED_UDP packet: 377 It is useful for the compressor to periodically refresh the state of 378 the decompressor to avoid having the decompressor send CONTEXT_STATE 379 messages in the case of unrecoverable packet loss. Using the flags 380 F=0 and I=1, dI=1, dT=1, the COMPRESSED_UDP packet refreshes all the 381 context parameters. 383 When compression is done over a lossy link with a long round trip 384 delay, we want to minimize context invalidation. If the delta values 385 are changing frequently, the context might get invalidated often. In 386 such cases the compressor may choose to always send absolute values 387 and never delta values, using COMPRESSED_UDP packets with the flags 388 F=1, and any of S, T, I as necessary. 390 2.2 CRTP Headers Checksum 392 RFC 2508, in Section 3.3.5, describes how the UDP checksum may be 393 used to validate header reconstruction periodically or when the 394 'twice' algorithm is used. When a UDP checksum is not present (has 395 value zero) in a stream, such validation would not be possible. To 396 cover that case, this enhanced CRTP provides an option whereby the 397 compressor MAY replace the null UDP checksum with a 16-bit headers 398 checksum (HDRCKSUM) which is subsequently removed by the 399 decompressor after validation. 401 A new flag C in the FULL_HEADER packet, as specified below, 402 indicates when set that all COMPRESSED_UDP and COMPRESSED_RTP 403 packets sent in that context will have HDRCKSUM inserted. The 404 compressor MAY set the C flag when UDP packet carried in the 405 FULL_HEADER packet originally contained a checksum value of zero. 406 If the C flag is set, the FULL_HEADER packet itself MUST also have 407 the HDRCKSUM inserted. If a packet in the same stream subsequently 408 arrives at the compressor with a UDP checksum present, then a new 409 FULL_HEADER packet MUST be sent with the flag cleared to re- 410 establish the context. 412 The HDRCKSUM is calculated in the same way as a UDP checksum except 413 that it does not cover all of the UDP data. That is, the HDRCKSUM is 414 the 16-bit one's complement of the one's complement sum of the 415 pseudo-IP header (as defined for UDP), the UDP header, and the first 416 12 bytes of the UDP data which are assumed to hold the fixed part of 417 an RTP header. The extended part of the RTP header and the RTP data 418 will not be included in the HDRCKSUM. The HDRCKSUM is placed in the 419 COMPRESSED_UDP or COMPRESSED_RTP packet where a UDP checksum would 420 have been. The decompressor MUST zero out the UDP checksum field in 421 the reconstructed packets. 423 For a non-RTP context, there may fewer than 12 UDP data bytes 424 present. The IP and UDP headers may still be compressed into a 425 COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated 426 over the pseudo-IP header, the UDP header, and the UDP data bytes 427 that are present. If the number of data bytes is odd, then a zero 428 padding byte is appended for the purpose of calculating the 429 checksum, but not transmitted. 431 The HDRCKSUM does not validate the RTP data. If the link layer is 432 configured to deliver packets without checking for errors, then 433 errors in the RTP data will not be detected. Over such links, the 434 compressor SHOULD add the HDRCKSUM if a UDP checksum is not present, 435 and the decompressor SHOULD validate each reconstructed packet to 436 make sure that at least the headers are correct. This ensures that 437 the packet will be delivered to the right destination. If only 438 HDRCKSUM is available, the RTP data will be delivered even if it 439 includes errors. This might be a desirable feature for applications 440 that can tolerate errors in the RTP data. The same holds for the 441 extended part of the RTP header. 443 Here is the format of the FULL_HEADER length fields with the new 444 flag C to indicate that a header checksum will be added in 445 COMPRESSED_UDP and COMPRESSED_RTP packets: 447 For 8-bit context ID: 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |0|1| Generation| CID | First length field 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | 0 |C| seq | Second length field 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added 457 For 16-bit context ID: 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |1|1| Generation| 0 |C| seq | First length field 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | CID | Second length field 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 2.3 CRTP operation in 'N' mode 469 The 'N' mode is a method of operation where the compressor tries to 470 keep the decompressor in sync by sending changes multiple times. The 471 'N' is a number that represents the quality of the link between the 472 hosts, and it means that the probability of more than N adjacent 473 packets getting lost on this link is small. For every change in a 474 full value or a delta value, if the compressor includes the change 475 in N+1 consecutive packets, there is a very good chance that the 476 compressor and decompressor can stay in sync using the 'twice' 477 algorithm. CONTEXT_STATE packets should also be repeated N+1 times 478 (using the same sequence number). It is up to the implementation to 479 find a scheme to derive an appropriate N for a link. 481 This scheme may be used at any time and does not require 482 negotiation. 484 Some short notations: 486 FH FULL_HEADER 487 CR COMPRESSED_RTP 488 CU COMPRESSED_UDP 490 Here is an example to demonstrate the usage of the N scheme. 491 In this stream the audio codec sends a sample every 10 milliseconds 492 The first talkspurt is 1 second long. Then there are 2 seconds of 493 silence, then another talkspurt. We also assume in this example that 494 the IP ID field does not increment at a constant rate because the 495 host is generating other uncorrelated traffic streams at the same 496 time and therefore the delta IP ID changes for each packet. 498 When there is no loss on the link, we can use COMPRESSED_RTP packets 499 in the following sequence: 501 seq Time pkt updates and comments 502 # type 503 1 10 FH 504 2 20 CR dI dT=10 505 3 30 CR dI 506 4 40 CR dI 507 ... 508 100 1000 CR dI 510 101 3010 CR dI dT=2010 511 102 3020 CR dI dT=10 512 103 3030 CR dI 513 104 3040 CR dI 514 ... 516 In the above sequence, if a packet is lost we cannot recover 517 ('twice' will not work due to the unpredictable IP ID) and the 518 context must be invalidated. 520 Here is the same example in 'N' mode, when N=2. Note that the 521 compressor only sends the absolute IP ID (I) and not the delta IP ID 522 (dI). 524 seq Time pkt CU flags updates and comments 525 # type F I dT dI M S T P 526 1 10 FH 527 2 20 FH repeat constant fields 528 3 30 FH repeat constant fields 529 4 40 CU 1 1 1 0 M 0 1 0 I T=40 dT=10 530 5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10 repeat update T & dT 531 6 60 CU 1 1 1 0 M 0 1 0 I T=60 dT=10 repeat update T & dT 532 7 70 CU 1 1 0 0 M 0 0 0 I 533 8 80 CU 1 1 0 0 M 0 0 0 I 534 ... 535 100 1000 CU 1 1 0 0 M 0 0 0 I 537 101 3010 CU 1 1 0 0 M 0 1 0 I T=3010 T changed, keep deltas 538 102 3020 CU 1 1 0 0 M 0 1 0 I T=3020 repeat updated T 539 103 3030 CU 1 1 0 0 M 0 1 0 I T=3030 repeat updated T 540 104 3040 CU 1 1 0 0 M 0 0 0 I 541 105 3050 CU 1 1 0 0 M 0 0 0 I 542 ... 544 This second example is the same sequence, but assuming the delta IP 545 ID is constant. First the basic CRTP for a lossless link: 547 seq Time pkt updates and comments 548 # type 549 1 10 FH 550 2 20 CR dI dT=10 551 3 30 CR 552 4 40 CR 553 ... 554 100 1000 CR 556 101 3010 CR dT=2010 557 102 3020 CR dT=10 558 103 3030 CR 559 104 3040 CR 560 ... 562 For the equivalent sequence in 'N' mode, the more efficient 563 COMPRESSED_RTP packet can still be used once the deltas are all 564 established: 566 seq Time pkt CU flags updates and comments 567 # type F I dT dI M S T P 568 1 10 FH 569 2 20 FH repeat constant fields 570 3 30 FH repeat constant fields 571 4 40 CU 1 1 1 1 M 0 1 0 I dI T=40 dT=10 572 5 50 CU 1 1 1 1 M 0 1 0 I dI T=50 dT=10 repeat updates 573 6 60 CU 1 1 1 1 M 0 1 0 I dI T=60 dT=10 repeat updates 574 7 70 CR 575 8 80 CR 576 ... 577 100 1000 CR 579 101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas 580 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T 581 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T 582 104 3040 CR 583 105 3050 CR 584 ... 586 3. Negotiating usage of enhanced-CRTP 588 RFC 2509 [IPCPHC] specifies how the use of CRTP is negotiated on PPP 589 links using the IP Compression Protocol option of IPCP: 591 IPCP option 2: IP compression protocol 592 protocol 0x61: indicates RFC 2507 header compression 593 sub-option 1: enables use of COMPRESSED_RTP, COMPRESSED_UDP 594 and CONTEXT_STATE as specified in RFC 2508 596 To use the enhanced CRTP defined in this document, a new sub-option 597 2 is added. The new sup-option 2 is negotiated instead of, not in 598 addition to, sub-option 1. 600 Description 602 Enable use of Protocol Identifiers COMPRESSED_RTP and 603 CONTEXT_STATE as specified in RFC 2508 plus COMPRESSED_UDP with 604 additional flags as defined in this document, and enable use of 605 the C flag with the FULL_HEADER Protocol Identifier as defined in 606 this document to indicate use of HDRCKSUM with COMPRESSED_RTP and 607 COMPRESSED_UDP packets. 609 0 1 610 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Type | Length | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Type 616 2 618 Length 619 2 621 4. Security Considerations 623 Because encryption eliminates the redundancy that this compression 624 scheme tries to exploit, there is some inducement to forego 625 encryption in order to achieve operation over a low-bandwidth link. 626 However, for those cases where encryption of data and not headers is 627 satisfactory, RTP does specify an alternative encryption method in 628 which only the RTP payload is encrypted and the headers are left in 629 the clear. That would allow compression to still be applied. 631 A malfunctioning or malicious compressor could cause the 632 decompressor to reconstitute packets that do not match the original 633 packets but still have valid IP, UDP and RTP headers and possibly 634 even valid UDP check-sums. Such corruption may be detected with 635 end-to-end authentication and integrity mechanisms which will not be 636 affected by the compression. Constant portions of authentication 637 headers will be compressed as described in [IPHCOMP]. 639 No authentication is performed on the CONTEXT_STATE control packet 640 sent by this protocol. An attacker with access to the link between 641 the decompressor and compressor could inject false CONTEXT_STATE 642 packets and cause compression efficiency to be reduced, probably 643 resulting in congestion on the link. However, an attacker with 644 access to the link could also disrupt the traffic in many other 645 ways. 647 A potential denial-of-service threat exists when using compression 648 techniques that have non-uniform receiver-end computational load. 649 The attacker can inject pathological datagrams into the stream which 650 are complex to decompress and cause the receiver to be overloaded 651 and degrading processing of other streams. However, this 652 compression does not exhibit any significant non-uniformity. 654 5. Acknowledgements 656 The authors would like to thank Van Jacobson, co-author of RFC 2508, 657 and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and 658 Stephen Pink. The authors would also like to thank Dana Blair, 659 Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama, 660 Mallik Tatipamula, Mike Thomas, Alex Tweedly, Herb Wildfeuer, and 661 Dan Wing. 663 6. References 665 [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 666 Low-Speed Serial Links", RFC2508, February 1999. 668 [IPHCOMP] M. Degermark, B. Nordgren, S. Pink, 669 "IP Header Compression", RFC2507, February 1999. 671 [IPCPHC] M. Engan, S. Casner, C. Bormann, 672 "IP Header Compression over PPP", RFC2509, February 1999. 674 [KEYW] S. Bradner, "Key words for use in RFCs to Indicate 675 Requirement Levels", RFC2119, BCP 14, March 1997. 677 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 678 "RTP: A Transport Protocol for Real-Time Applications", RFC1889, 679 January 1996. 681 7. Authors' Addresses 683 Tmima Koren 684 Cisco Systems, Inc. 685 170 West Tasman Drive 686 San Jose, CA 95134-1706 687 United States of America 688 Email: tmima@cisco.com 689 Stephen L. Casner 690 Packet Design 691 2465 Latham Street, Third Floor 692 Mountain View, CA 94040 693 United States of America 694 Email: casner@acm.org 696 John Geevarghese 697 Telseon Inc. 698 480 S. California 699 Palo Alto, CA 94306 700 United States of America 701 Email: geevjohn@hotmail.com 703 Bruce Thompson 704 Cisco Systems, Inc. 705 170 West Tasman Drive 706 San Jose, CA 95134-1706 707 United States of America 708 Email: brucet@cisco.com 710 Patrick Ruddy 711 Cisco Systems, Inc. 712 3rd Floor, 96 Commercial Street 713 Edinburgh 714 EH6 6LX 715 Scotland 716 Email: pruddy@cisco.com 718 8. Copyright 720 Copyright (C) The Internet Society 1999-2001. All Rights Reserved. 721 This document and translations of it may be copied and furnished to 722 others, and derivative works that comment on or otherwise explain it 723 or assist in its implementation may be prepared, copied, published 724 and distributed, in whole or in part, without restriction of any 725 kind, provided that the above copyright notice and this paragraph 726 are included on all such copies and derivative works. However, this 727 document itself may not be modified in any way, such as by removing 728 the copyright notice or references to the Internet Society or other 729 Internet organizations, except as needed for the purpose of 730 developing Internet standards in which case the procedures for 731 copyrights defined in the Internet Standards process must be 732 followed, or as required to translate it into languages other than 733 English. 735 The limited permissions granted above are perpetual and will not be 736 revoked by the Internet Society or its successors or assigns. 738 This document and the information contained herein is provided on an 739 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 740 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 741 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 742 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 743 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.