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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/