diff options
Diffstat (limited to 'doc/rfc/rfc3545.txt')
| -rw-r--r-- | doc/rfc/rfc3545.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc3545.txt b/doc/rfc/rfc3545.txt new file mode 100644 index 0000000..91df50b --- /dev/null +++ b/doc/rfc/rfc3545.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group T. Koren +Request for Comments: 3545 Cisco Systems +Category: Standards Track S. Casner + Packet Design + J. Geevarghese + Motorola India Electronics Ltd. + B. Thompson + P. Ruddy + Cisco Systems + July 2003 + + + Enhanced Compressed RTP (CRTP) for Links with High Delay, + Packet Loss and Reordering + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes a header compression scheme for point to + point links with packet loss and long delays. It is based on + Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header + compression described in RFC 2508. CRTP does not perform well on + such links: packet loss results in context corruption and due to the + long delay, many more packets are discarded before the context is + repaired. To correct the behavior of CRTP over such links, a few + extensions to the protocol are specified here. The extensions aim to + reduce context corruption by changing the way the compressor updates + the context at the decompressor: updates are repeated and include + updates to full and differential context parameters. With these + extensions, CRTP performs well over links with packet loss, packet + reordering and long delays. + + + + + + + + + +Koren, et al. Standards Track [Page 1] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + +Table of Contents + + 1. Introduction ................................................. 2 + 1.1. CRTP Operation ......................................... 4 + 1.2. How do contexts get corrupted? ......................... 4 + 1.3. Preventing context corruption .......................... 5 + 1.4. Specification of Requirements .......................... 5 + 2. Enhanced CRTP ................................................ 5 + 2.1. Extended COMPRESSED_UDP packet ......................... 6 + 2.2. CRTP Headers Checksum .................................. 11 + 2.3. Achieving robust operation ............................. 13 + 2.3.1. Examples ....................................... 15 + 3. Negotiating usage of enhanced-CRTP ........................... 18 + 4. Security Considerations ...................................... 18 + 5. Acknowledgements ............................................. 19 + 6. References ................................................... 19 + 6.1. Normative References ................................... 19 + 6.2. Informative References ................................. 20 + 7. Intellectual Property Rights Notice .......................... 20 + 8. Authors' Addresses ........................................... 21 + 9. Full Copyright Statement ..................................... 22 + +1. Introduction + + RTP header compression (CRTP) as described in RFC 2508 was designed + to reduce the header overhead of IP/UDP/RTP datagrams by compressing + the three headers. The IP/UDP/RTP headers are compressed to 2-4 + bytes most of the time. + + CRTP was designed for reliable point to point links with short + delays. It does not perform well over links with high rate of packet + loss, packet reordering and long delays. + + An example of such a link is a PPP session that is tunneled using an + IP level tunneling protocol such as L2TP. Packets within the tunnel + are carried by an IP network and hence may get lost and reordered. + The longer the tunnel, the longer the round trip time. + + Another example is an IP network that uses layer 2 technologies such + as ATM and Frame Relay for the access portion of the network. Layer + 2 transport networks such as ATM and Frame Relay behave like point to + point serial links in that they do not reorder packets. In addition, + Frame Relay and ATM virtual circuits used as IP access technologies + often have a low bit rate associated with them. These virtual + circuits differ from low speed serial links in that they may span a + larger physical distance than a point to point serial link. Speed of + light delays within the layer 2 transport network will result in + higher round trip delays between the endpoints of the circuit. In + + + +Koren, et al. Standards Track [Page 2] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + addition, congestion within the layer 2 transport network may result + in an effective drop rate for the virtual circuit which is + significantly higher than error rates typically experienced on point + to point serial links. + + It may be desirable to extend existing CRTP implementations for use + also over IP tunnels and other virtual circuits, where packet losses, + reordering, and long delays are common characteristics. To address + these scenarios, this document defines modifications and extensions + to CRTP to increase robustness to both packet loss and misordering + between the compressor and the decompressor. This is achieved by + repeating updates and allowing the sending of absolute (uncompressed) + values in addition to delta values for selected context parameters. + Although these new mechanisms impose some additional overhead, the + overall compression is still substantial. The enhanced CRTP, as + defined in this document, is thus suitable for many applications in + the scenarios discussed above, e.g., tunneling and other virtual + circuits. + + RFC 3095 defines another RTP header compression scheme called Robust + Header Compression [ROHC]. ROHC was developed with wireless links as + the main target, and introduced new compression mechanisms with the + primary objective to achieve the combination of robustness against + packet loss and maximal compression efficiency. ROHC is expected to + be the preferred compression mechanism over links where compression + efficiency is important. However, ROHC was designed with the same + link assumptions as CRTP, e.g., that the compression scheme should + not have to tolerate misordering of compressed packets between the + compressor and decompressor, which may occur when packets are carried + in an IP tunnel across multiple hops. + + At some time in the future, enhancements may be defined for ROHC to + allow it to perform well in the presence of misordering of compressed + packets. The result might be more efficient than the compression + protocol specified in this document. However, there are many + environments for which the enhanced CRTP defined here may be the + preferred choice. In particular, for those environments where CRTP + is already implemented, the additional effort required to implement + the extensions defined here is expected to be small. There are also + cases where the implementation simplicity of this enhanced CRTP + relative to ROHC is more important than the performance advantages of + ROHC. + + + + + + + + + +Koren, et al. Standards Track [Page 3] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + +1.1. CRTP Operation + + During compression of an RTP stream, a session context is defined. + For each context, the session state is established and shared between + the compressor and the decompressor. Once the context state is + established, compressed packets may be sent. + + The context state consists of the full IP/UDP/RTP headers, a few + first order differential values, a link sequence number, a generation + number and a delta encoding table. + + The headers part of the context is set by the FULL_HEADER packet that + always starts a compression session. The first order differential + values (delta values) are set by sending COMPRESSED_RTP packets that + include updates to the delta values. + + The context state must be synchronized between compressor and + decompressor for successful decompression to take place. If the + context gets out of sync, the decompressor is not able to restore the + compressed headers accurately. The decompressor invalidates the + context and sends a CONTEXT_STATE packet to the compressor indicating + that the context has been corrupted. To resume compression, the + compressor must re-establish the context. + + During the time the context is corrupted, the decompressor discards + all the packets received for that context. Since the context repair + mechanism in CRTP involves feedback from the decompressor, context + repair takes at least as much time as the round trip time of the + link. If the round trip time of the link is long, and especially if + the link bandwidth is high, many packets will be discarded before the + context is repaired. On such links it is desirable to minimize + context invalidation. + +1.2. How do contexts get corrupted? + + As long as the fields in the combined IP/UDP/RTP headers change as + expected for the sequence of packets in a session, those headers can + be compressed, and the decompressor can fully restore the compressed + headers using the context state. When the headers don't change as + expected it's necessary to update some of the full or the delta + values of the context. For example, the RTP timestamp is expected to + increment by delta RTP timestamp (dT). If silence suppression is + used, packets are not sent during silence periods. Then when voice + activity resumes, packets are sent again, but the RTP timestamp is + incremented by a large value and not by dT. In this case an update + must be sent. + + + + + +Koren, et al. Standards Track [Page 4] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + If a packet that includes an update to some context state values is + lost, the state at the decompressor is not updated. The shared state + is now different at the compressor and decompressor. When the next + packet arrives at the decompressor, the decompressor will fail to + restore the compressed headers accurately since the context state at + the decompressor is different than the state at the compressor. + +1.3. Preventing context corruption + + Note that the decompressor fails not when a packet is lost, but when + the next compressed packet arrives. If the next packet happens to + include the same context update as in the lost packet, the context at + the decompressor may be updated successfully and decompression may + continue uninterrupted. If the lost packet included an update to a + delta field such as the delta RTP timestamp (dT), the next packet + can't compensate for the loss since the update of a delta value is + relative to the previous packet which was lost. But if the update is + for an absolute value such as the full RTP timestamp or the RTP + payload type, this update can be repeated in the next packet + independently of the lost packet. Hence it is useful to be able to + update the absolute values of the context. + + The next chapter describes several extensions to CRTP that add the + capability to selectively update absolute values of the context, + rather than sending a FULL_HEADER packet, in addition to the existing + updates of the delta values. This enhanced version of CRTP is + intended to minimize context invalidation and thus improve the + performance over lossy links with a long round trip time. + +1.4. Specification of Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Enhanced CRTP + + This chapter specifies the changes in this enhanced version of CRTP. + They are: + + - Extensions to the COMPRESSED_UDP packet to allow updating the + differential RTP values in the decompressor context and to + selectively update the absolute IPv4 ID and the following RTP + values: sequence number, timestamp, payload type, CSRC count and + CSRC list. This allows context sync to be maintained even with + some packet loss. + + + + + +Koren, et al. Standards Track [Page 5] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + - A "headers checksum" to be inserted by the compressor and removed + by the decompressor when the UDP checksum is not present so that + validation of the decompressed headers is still possible. This + allows the decompressor to verify that context sync has not been + lost after a packet loss. + + An algorithm is then described to use these changes with repeated + updates to achieve robust operation over links with packet loss and + long delay. + +2.1. Extended COMPRESSED_UDP packet + + It is possible to accommodate some packet loss between the compressor + and decompressor using the "twice" algorithm in RFC 2508 so long as + the context remains in sync. In that algorithm, the delta values are + added to the previous context twice (or more) to effect the change + that would have occurred if the missing packets had arrived. The + result is verified with the UDP checksum. Keeping the context in + sync requires reliably communicating both the absolute value and the + delta value whenever the delta value changes. For many environments, + sufficient reliability can be achieved by repeating the update with + each of several successive packets. + + The COMPRESSED_UDP packet satisfies the need to communicate the + absolute values of the differential RTP fields, but it is specified + in RFC 2508 to reset the delta RTP timestamp. That limitation can be + removed with the following simple change: RFC 2508 describes the + format of COMPRESSED_UDP as being the same as COMPRESSED_RTP except + that the M, S and T bits are always 0 and the corresponding delta + fields are never included. This enhanced version of CRTP changes + that specification to say that the T bit MAY be nonzero to indicate + that the delta RTP timestamp is included explicitly rather than being + reset to zero. + + A second change adds another byte of flag bits to the COMPRESSED_UDP + packet to allow only selected individual uncompressed fields of the + RTP header to be included in the packet rather than carrying the full + RTP header as part of the UDP data. The additional flags do increase + computational complexity somewhat, but the corresponding increase in + bit efficiency is important when the differential field updates are + communicated multiple times in successive COMPRESSED_UDP packets. + With this change, there are flag bits to indicate inclusion of both + delta values and absolute values, so the flag nomenclature is + changed. The original S, T, I bits which indicate the inclusion of + deltas are renamed dS, dT, dI, and the inclusion of absolute values + is indicated by S, T, I. The M bit is absolute as before. A new + + + + + +Koren, et al. Standards Track [Page 6] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + flag P indicates inclusion of the absolute RTP payload type value and + another flag C indicates the inclusion of the CSRC count. When C=1, + an additional byte is added following the two flag bytes to include + the absolute value of the four-bit CC field in the RTP header. + + The last of the three changes to the COMPRESSED_UDP packet deals with + updating the IPv4 ID field. For this field, the COMPRESSED_UDP + packet as specified in RFC 2508 can already convey a new value for + the delta IPv4 ID, but not the absolute value which is only conveyed + by the FULL_HEADER packet. Therefore, a new flag I is added to the + COMPRESSED_UDP packet to indicate inclusion of the absolute IPv4 ID + value. The I flag replaces the dS flag which is not needed in the + COMPRESSED_UDP packet since the delta RTP sequence number always + remains 1 in the decompressor context and hence does not need to be + updated. Note that IPv6 does not have an IP ID field, so when + compressing IPv6 packets both the I and the dI flags are always set + to 0. + + The format of the flags/sequence byte for the original COMPRESSED_UDP + packet is shown here for reference: + + +---+---+---+---+---+---+---+---+ + | 0 | 0 | 0 |dI | link sequence | + +---+---+---+---+---+---+---+---+ + + The new definition of the flags/sequence byte plus an extension flags + byte for the COMPRESSED_UDP packet is as follows, where the new F + flag indicates the inclusion of the extension flags byte: + + +---+---+---+---+---+---+---+---+ + | F | I |dT |dI | link sequence | + +---+---+---+---+---+---+---+---+ + : M : S : T : P : C : 0 : 0 : 0 : (if F = 1) + +...+...+...+...+...+...+...+...+ + + dI = delta IPv4 ID + dT = delta RTP timestamp + I = absolute IPv4 ID + F = additional flags byte + M = marker bit + S = absolute RTP sequence number + T = absolute RTP timestamp + P = RTP payload type + C = CSRC count + CID = Context ID + + + + + + +Koren, et al. Standards Track [Page 7] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + When F=0, there is only one flags byte, and the only available flags + are: dI, dT and I. In this case the packet includes the full RTP + header. As in RFC 2508, if dI=0, the decompressor does not change + deltaI. If dT=0, the decompressor sets deltaT to 0. + + When C=1, an additional byte is added following the two flag bytes. + This byte includes the CC, the count of CSRC identifiers, in its + lower 4 bits: + + +---+---+---+---+---+---+---+---+ + | F | I |dT |dI | link sequence | + +---+---+---+---+---+---+---+---+ + : M : S : T : P : C : 0 : 0 : 0 : (if F = 1) + +...+...+...+...+...+...+...+...+ + : 0 : 0 : 0 : 0 : CC : (if C = 1) + +...+...+...+...+...............+ + + The bits marked "0" in the second flag byte and the CC byte SHOULD be + set to zero by the sender and SHOULD be ignored by the receiver. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 8] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + Some example packet formats will illustrate the use of the new flags. + First, when F=0, the "traditional" COMPRESSED_UDP packet which + carries the full RTP header as part of the UDP data: + + 0 1 2 3 4 5 6 7 + +...............................+ + : msb of session context ID : (if 16-bit CID) + +-------------------------------+ + | lsb of session context ID | + +---+---+---+---+---+---+---+---+ + |F=0| I |dT |dI | link sequence | + +---+---+---+---+---+---+---+---+ + : : + + UDP checksum + (if nonzero in context) + : : + +...............................+ + : : + + "RANDOM" fields + (if encapsulated) + : : + +...............................+ + : delta IPv4 ID : (if dI = 1) + +...............................+ + : delta RTP timestamp : (if dT = 1) + +...............................+ + : : + + IPv4 ID + (if I = 1) + : : + +...............................+ + | UDP data | + : (uncompressed RTP header) : + + When F=1, there is an additional flags byte and the available flags + are: dI, dT, I, M, S, T, P, C. If C=1, there is an additional byte + that includes the number of CSRC identifiers. When F=1, the packet + does not include the full RTP header, but includes selected fields + from the RTP header as specified by the flags. As in RFC 2508, if + dI=0 the decompressor does not change deltaI. However, in contrast + to RFC 2508, if dT=0 the decompressor KEEPS THE CURRENT deltaT in the + context (DOES NOT set deltaT to 0). + + An enhanced COMPRESSED_UDP packet is similar in contents and behavior + to a COMPRESSED_RTP packet, but it has more flag bits, some of which + correspond to absolute values for RTP header fields. + + + + + + + + +Koren, et al. Standards Track [Page 9] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + COMPRESSED_UDP with individual RTP fields, when F=1: + + 0 1 2 3 4 5 6 7 + +...............................+ + : msb of session context ID : (if 16-bit CID) + +-------------------------------+ + | lsb of session context ID | + +---+---+---+---+---+---+---+---+ + |F=1| I |dT |dI | link sequence | + +---+---+---+---+---+---+---+---+ + | M | S | T | P | C | 0 | 0 | 0 | + +---+---+---+---+---+---+---+---+ + : 0 : 0 : 0 : 0 : CC : (if C = 1) + +...+...+...+...+...............+ + : : + + UDP checksum + (if nonzero in context) + : : + +...............................+ + : : + : "RANDOM" fields : (if encapsulated) + : : + +...............................+ + : delta IPv4 ID : (if dI = 1) + +...............................+ + : delta RTP timestamp : (if dT = 1) + +...............................+ + : : + + IPv4 ID + (if I = 1) + : : + +...............................+ + : : + + RTP sequence number + (if S = 1) + : : + +...............................+ + : : + + + + : : + + RTP timestamp + (if T = 1) + : : + + + + : : + +...............................+ + : RTP payload type : (if P = 1) + +...............................+ + : : + : CSRC list : (if CC > 0) + : : + +...............................+ + + + +Koren, et al. Standards Track [Page 10] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + : : + : RTP header extension : (if X set in context) + : : + +-------------------------------+ + | | + / RTP data / + / / + | | + +-------------------------------+ + : padding : (if P set in context) + +...............................+ + + Usage for the enhanced COMPRESSED_UDP packet: + + It is useful for the compressor to periodically refresh the state of + the decompressor to avoid having the decompressor send CONTEXT_STATE + messages in the case of unrecoverable packet loss. Using the flags + F=0 and I=1, dI=1, dT=1, the COMPRESSED_UDP packet refreshes all the + context parameters. + + When compression is done over a lossy link with a long round trip + delay, we want to minimize context invalidation. If the delta values + are changing frequently, the context might get invalidated often. In + such cases the compressor MAY choose to always send absolute values + and never delta values, using COMPRESSED_UDP packets with the flags + F=1, and any of S, T, I as necessary. + +2.2. CRTP Headers Checksum + + RFC 2508, in Section 3.3.5, describes how the UDP checksum may be + used to validate header reconstruction periodically or when the + "twice" algorithm is used. When a UDP checksum is not present (has + value zero) in a stream, such validation would not be possible. To + cover that case, this enhanced CRTP provides an option whereby the + compressor MAY replace the null UDP checksum with a 16-bit headers + checksum (HDRCKSUM) which is subsequently removed by the decompressor + after validation. Note that this option is never used with IPv6 + since a null UDP checksum is not allowed. + + A new flag C in the FULL_HEADER packet, as specified below, indicates + when set that all COMPRESSED_UDP and COMPRESSED_RTP packets sent in + that context will have HDRCKSUM inserted. The compressor MAY set the + C flag when UDP packet carried in the FULL_HEADER packet originally + contained a checksum value of zero. If the C flag is set, the + FULL_HEADER packet itself MUST also have the HDRCKSUM inserted. If a + packet in the same stream subsequently arrives at the compressor with + a UDP checksum present, then a new FULL_HEADER packet MUST be sent + with the flag cleared to re-establish the context. + + + +Koren, et al. Standards Track [Page 11] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + The HDRCKSUM is calculated in the same way as a UDP checksum except + that it does not cover all of the UDP data. That is, the HDRCKSUM is + the 16-bit one's complement of the one's complement sum of the + pseudo-IP header (as defined for UDP), the UDP header, the first 12 + bytes of the UDP data which are assumed to hold the fixed part of an + RTP header, and the CSRC list. The extended part of the RTP header + beyond the CSRC list and the RTP data will not be included in the + HDRCKSUM. The HDRCKSUM is placed in the COMPRESSED_UDP or + COMPRESSED_RTP packet where a UDP checksum would have been. The + decompressor MUST zero out the UDP checksum field in the + reconstructed packets. + + For a non-RTP context, there may be fewer than 12 UDP data bytes + present. The IP and UDP headers can still be compressed into a + COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated + over the pseudo-IP header, the UDP header, and the UDP data bytes + that are present. If the number of data bytes is odd, then a zero + padding byte is appended for the purpose of calculating the checksum, + but not transmitted. + + The HDRCKSUM does not validate the RTP data. If the link layer is + configured to deliver packets without checking for errors, then + errors in the RTP data will not be detected. Over such links, the + compressor SHOULD add the HDRCKSUM if a UDP checksum is not present, + and the decompressor SHOULD validate each reconstructed packet to + make sure that at least the headers are correct. This ensures that + the packet will be delivered to the right destination. If only + HDRCKSUM is available, the RTP data will be delivered even if it + includes errors. This might be a desirable feature for applications + that can tolerate errors in the RTP data. The same holds for the + extended part of the RTP header beyond the CSRC list. + + Here is the format of the FULL_HEADER length fields with the new flag + C to indicate that a header checksum will be added in COMPRESSED_UDP + and COMPRESSED_RTP packets: + + For 8-bit context ID: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0|1| Generation| CID | First length field + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 |C| seq | Second length field + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added + + + + + + +Koren, et al. Standards Track [Page 12] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + For 16-bit context ID: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1|1| Generation| 0 |C| seq | First length field + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CID | Second length field + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.3. Achieving robust operation + + Enhanced CRTP achieves robust operation by sending changes multiple + times to keep the compressor and decompressor in sync. This method + is characterized by a number "N" that represents the quality of the + link between the hosts. What it means is that the probability of + more than N adjacent packets getting lost on this link is small. For + every change in a full value or a delta value, if the compressor + includes the change in N+1 consecutive packets, then the decompressor + can keep its context state in sync with the compressor using the + "twice" algorithm so long as no more than N adjacent packets are + lost. + + Since updates are repeated in N+1 packets, if at least one of these + N+1 update packets is received by the decompressor, both the full and + delta values in the context at the decompressor will get updated and + its context will stay synchronized with the context at the + compressor. We can conclude that as long as less than N+1 adjacent + packets are lost, the context at the decompressor is guaranteed to be + synchronized with the context at the compressor, and use of the + "twice" algorithm to recover from packet loss will successfully + update the context and restore the compressed packets. + + The link sequence number cycles in 16 packets, so it's not always + clear how many packets were lost. For example, if the previous link + sequence number was 5 and the current number is 4, one possibility is + that 15 packets were lost, but another possibility is that due to + misordering packet 5 arrived before packet 4 and they are really + adjacent. If there is an interpretation of the link sequence numbers + that could be a gap of less than N+1, the "twice" algorithm may be + applied that many times and verified with the UDP checksum (or the + HDRCKSUM). + + When more than N packets are lost, all of the repetitions of an + update might have been lost. The context state may then be different + at the compressor and decompressor. The decompressor can still try + to recover by making one or more guesses for how many packets were + lost and then applying the "twice" algorithm that many times. + + + +Koren, et al. Standards Track [Page 13] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + However, since the IPv4 ID field is not included in the checksum, + this does not validate the IPv4 ID. + + The conclusion is that for IPv4 if more than N packets were lost, the + decompressor SHOULD NOT try to recover using the "twice" algorithm + and instead SHOULD invalidate the context and send a CONTEXT_STATE + packet. In IPv6 the decompressor MAY always try to recover from + packet loss by using the "twice" algorithm and verifying the result + with the UDP checksum. + + It is up to the implementation to derive an appropriate N for a link. + The value is maintained independently for each context and is not + required to be the same for all contexts. When compressing a new + stream, the compressor sets a value of N for that context and sends + N+1 FULL_HEADER packets. The compressor MUST also repeat each + subsequent COMPRESSED_UDP update N+1 times. The value of N may be + changed for an existing context by sending a new sequence of + FULL_HEADER packets. + + The decompressor learns the value of N by counting the number of + times the FULL_HEADER packet is repeated and storing the resulting + value in the corresponding context. If some of the FULL_HEADER + packets are lost, the decompressor may still be able to determine the + correct value of N by observing the change in the 4-bit sequence + number carried in the FULL_HEADER packets. Any inaccuracy in the + counting will lead the decompressor to assume a smaller value of N + than the compressor is sending. This is safe in that the only + negative consequence is that the decompressor might send a + CONTEXT_STATE packet when it was not really necessary to do so. In + response, the compressor will send FULL_HEADER packets again, + providing another opportunity for the decompressor to count the + correct N. + + The sending of FULL_HEADER packets is also triggered by a change in + one of the fields held constant in the context, such as the IP TOS. + If such a change should occur while the compressor is in the middle + of sending the N+1 FULL_HEADER packets, then the compressor MUST send + N+1 FULL_HEADER packets after making the change. This could cause + the decompressor to receive more than N+1 FULL_HEADER packets in a + row with the result that it assumes a larger value for N than is + correct. That could lead to an undetected loss of context + synchronization. Therefore, the compressor MUST change the + "generation" number in the context and in the FULL_HEADER packet when + it begins sending the sequence of N+1 FULL_HEADER packets so the + decompressor can detect the new sequence. For IPv4, this is a change + in behavior relative to RFC 2508. + + + + + +Koren, et al. Standards Track [Page 14] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + CONTEXT_STATE packets SHOULD also be repeated N+1 times (using the + same sequence number for each context) to provide a similar measure + of robustness against packet loss. Here N can be the largest N of + all contexts included in the CONTEXT_STATE packet, or any number the + decompressor finds necessary in order to ensure robustness. + +2.3.1. Examples + + Here are some examples to demonstrate the robust operation of + enhanced CRTP using N+1 repetitions of updates. In this stream the + audio codec sends a sample every 10 milliseconds. The first + talkspurt is 1 second long. Then there are 2 seconds of silence, + then another talkspurt. We also assume in this first example that + the IPv4 ID field does not increment at a constant rate because the + host is generating other uncorrelated traffic streams at the same + time and therefore the delta IPv4 ID changes for each packet. + + In these examples, we will use some short notations: + + FH FULL_HEADER + CR COMPRESSED_RTP + CU COMPRESSED_UDP + + When operating on a link with low loss, we can just use + COMPRESSED_RTP packets in the basic CRTP method specified in RFC + 2508. We might have the following packet sequence: + + seq Time pkt updates and comments + # type + 1 10 FH + 2 20 CR dI dT=10 + 3 30 CR dI + 4 40 CR dI + ... + 100 1000 CR dI + + 101 3010 CR dI dT=2010 + 102 3020 CR dI dT=10 + 103 3030 CR dI + 104 3040 CR dI + ... + + In the above sequence, if a packet is lost we cannot recover ("twice" + will not work due to the unpredictable IPv4 ID) and the context must + be invalidated. + + + + + + +Koren, et al. Standards Track [Page 15] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + Here is the same example using the enhanced CRTP method specified in + this document, when N=2. Note that the compressor only sends the + absolute IPv4 ID (I) and not the delta IPv4 ID (dI). + + seq Time pkt CU flags updates and comments + # type F I dT dI M S T P + 1 10 FH + 2 20 FH repeat constant fields + 3 30 FH repeat constant fields + 4 40 CU 1 1 1 0 M 0 1 0 I T=40 dT=10 + 5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10 repeat update T & dT + 6 60 CU 1 1 1 0 M 0 1 0 I T=60 dT=10 repeat update T & dT + 7 70 CU 1 1 0 0 M 0 0 0 I + 8 80 CU 1 1 0 0 M 0 0 0 I + ... + 100 1000 CU 1 1 0 0 M 0 0 0 I + + 101 3010 CU 1 1 0 0 M 0 1 0 I T=3010 T changed, keep deltas + 102 3020 CU 1 1 0 0 M 0 1 0 I T=3020 repeat updated T + 103 3030 CU 1 1 0 0 M 0 1 0 I T=3030 repeat updated T + 104 3040 CU 1 1 0 0 M 0 0 0 I + 105 3050 CU 1 1 0 0 M 0 0 0 I + ... + + This second example is the same sequence, but assuming the delta IP + ID is constant. First the basic CRTP for a lossless link: + + seq Time pkt updates and comments + # type + 1 10 FH + 2 20 CR dI dT=10 + 3 30 CR + 4 40 CR + ... + 100 1000 CR + + 101 3010 CR dT=2010 + 102 3020 CR dT=10 + 103 3030 CR + 104 3040 CR + ... + + + + + + + + + + +Koren, et al. Standards Track [Page 16] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + For the equivalent sequence in enhanced CRTP, the more efficient + COMPRESSED_RTP packet can still be used once the deltas are all + established: + + seq Time pkt CU flags updates and comments + # type F I dT dI M S T P + 1 10 FH + 2 20 FH repeat constant fields + 3 30 FH repeat constant fields + 4 40 CU 1 1 1 1 M 0 1 0 I dI T=40 dT=10 + 5 50 CU 1 1 1 1 M 0 1 0 I dI T=50 dT=10 repeat updates + 6 60 CU 1 1 1 1 M 0 1 0 I dI T=60 dT=10 repeat updates + 7 70 CR + 8 80 CR + ... + 100 1000 CR + + 101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas + 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T + 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T + 104 3040 CR + 105 3050 CR + ... + + Here is the second example when using IPv6. First the basic CRTP for + a lossless link: + + seq Time pkt updates and comments + # type + 1 10 FH + 2 20 CR dT=10 + 3 30 CR + 4 40 CR + ... + 100 1000 CR + + 101 3010 CR dT=2010 + 102 3020 CR dT=10 + 103 3030 CR + 104 3040 CR + ... + + + + + + + + + + +Koren, et al. Standards Track [Page 17] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + For the equivalent sequence in enhanced CRTP, the more efficient + COMPRESSED_RTP packet can still be used once the deltas are all + established: + + seq Time pkt CU flags updates and comments + # type F I dT dI M S T P + 1 10 FH + 2 20 FH repeat constant fields + 3 30 FH repeat constant fields + 4 40 CU 1 0 1 0 M 0 1 0 T=40 dT=10 + 5 50 CU 1 0 1 0 M 0 1 0 T=50 dT=10 repeat updates + 6 60 CU 1 0 1 0 M 0 1 0 T=60 dT=10 repeat updates + 7 70 CR + 8 80 CR + ... + 100 1000 CR + + 101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas + 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T + 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T + 104 3040 CR + 105 3050 CR + ... + +3. Negotiating usage of enhanced-CRTP + + The use of IP/UDP/RTP compression (CRTP) over a particular link is a + function of the link-layer protocol. It is expected that negotiation + of the use of CRTP will be defined separately for each link layer. + + For link layers that already have defined a negotiation for the use + of CRTP as specified in RFC 2508, an extension to that negotiation + will be required to indicate use of the enhanced CRTP defined in this + document since the syntax of the existing packet formats has been + extended. + +4. Security Considerations + + Because encryption eliminates the redundancy that this compression + scheme tries to exploit, there is some inducement to forego + encryption in order to achieve operation over a low-bandwidth link. + However, for those cases where encryption of data and not headers is + satisfactory, RTP does specify an alternative encryption method in + which only the RTP payload is encrypted and the headers are left in + the clear [SRTP]. That would allow compression to still be applied. + + + + + + +Koren, et al. Standards Track [Page 18] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + A malfunctioning or malicious compressor could cause the decompressor + to reconstitute packets that do not match the original packets but + still have valid IP, UDP and RTP headers and possibly even valid UDP + check-sums. Such corruption may be detected with end-to-end + authentication and integrity mechanisms which will not be affected by + the compression. Constant portions of authentication headers will be + compressed as described in [IPHCOMP]. + + No authentication is performed on the CONTEXT_STATE control packet + sent by this protocol. An attacker with access to the link between + the decompressor and compressor could inject false CONTEXT_STATE + packets and cause compression efficiency to be reduced, probably + resulting in congestion on the link. However, an attacker with + access to the link could also disrupt the traffic in many other ways. + + A potential denial-of-service threat exists when using compression + techniques that have non-uniform receiver-end computational load. The + attacker can inject pathological datagrams into the stream which are + complex to decompress and cause the receiver to be overloaded and + degrading processing of other streams. However, this compression + does not exhibit any significant non-uniformity. + +5. Acknowledgements + + The authors would like to thank Van Jacobson, co-author of RFC 2508, + and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and + Stephen Pink. The authors would also like to thank Dana Blair, + Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama, + Mallik Tatipamula, Mike Thomas, Alex Tweedly, Herb Wildfeuer, + Andrew Johnson, and Dan Wing. + +6. References + +6.1. Normative References + + [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers + for Low-Speed Serial Links", RFC 2508, February 1999. + + [IPHCOMP] Degermark, M., Nordgren, B. and S. Pink, "IP Header + Compression", RFC 2507, February 1999. + + [IPCPHC] Koren, T., Casner, S. and C. Bormann, "IP Header + Compression over PPP", RFC 3544, July 2003. + + [KEYW] Bradner, S. "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + +Koren, et al. Standards Track [Page 19] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + + [RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", RFC + 3550, July 2003. + +6.2. Informative References + + [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., + Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., + Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, + T., Yoshimura, T. and H. Zheng, "RObust Header Compression + (ROHC): Framework and four profiles: RTP, UDP, ESP, and + uncompressed", RFC 3095, July 2001. + + [SRTP] Baugher, M., McGrew, D., Carrara, E., Naslund, M. and K. + Norrman, "The Secure Real-time Transport Protocol", Work in + Progress. + +7. Intellectual Property Rights Notice + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 20] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + +8. Authors' Addresses + + Tmima Koren + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + USA + + EMail: tmima@cisco.com + + + Stephen L. Casner + Packet Design + 3400 Hillview Avenue, Building 3 + Palo Alto, CA 94304 + USA + + EMail: casner@acm.org + + + John Geevarghese + Motorola India Electronics Ltd. + No. 33 A Ulsoor Road + Bangalore, India + + EMail: geevjohn@hotmail.com + + + Bruce Thompson + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + USA + + EMail: brucet@cisco.com + + + Patrick Ruddy + Cisco Systems, Inc. + 3rd Floor + 96 Commercial Street + Leith, Edinburgh EH6 6LX + Scotland + + EMail: pruddy@cisco.com + + + + + + +Koren, et al. Standards Track [Page 21] + +RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 22] + |