< draft-ietf-rohc-over-reordering-02.txt   draft-ietf-rohc-over-reordering-03.txt >
Network Working Group Ghyslain Pelletier, Ericsson Network Working Group G. Pelletier
INTERNET-DRAFT Lars-Erik Jonsson, Ericsson INTERNET-DRAFT L-E. Jonsson
Expires: August 2005 Kristofer Sandlund, Effnet Expires: November 2005 K. Sandlund
February 17, 2005 Ericsson
May 16, 2005
RObust Header Compression (ROHC): RObust Header Compression (ROHC):
ROHC over Channels that can Reorder Packets ROHC over Channels that can Reorder Packets
<draft-ietf-rohc-over-reordering-02.txt> <draft-ietf-rohc-over-reordering-03.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3.2. Profiles with Special Considerations........................5 3.2. Profiles with Special Considerations........................5
3.3. Profiles Incompatible with Reordering.......................5 3.3. Profiles Incompatible with Reordering.......................5
4. Background.......................................................6 4. Background.......................................................6
4.1. Reordering Channels.........................................6 4.1. Reordering Channels.........................................6
4.2. Robustness Principles of ROHC...............................6 4.2. Robustness Principles of ROHC...............................6
4.2.1. Optimistic Approach (U/O-mode).........................6 4.2.1. Optimistic Approach (U/O-mode).........................6
4.2.2. Secure Reference Principle (R-mode)....................7 4.2.2. Secure Reference Principle (R-mode)....................7
5. Problem Description..............................................7 5. Problem Description..............................................7
5.1. ROHC and Reordering Channels................................7 5.1. ROHC and Reordering Channels................................7
5.1.1. LSB Interpretation Interval and Reordering.............7 5.1.1. LSB Interpretation Interval and Reordering.............7
5.1.2. Reordering of Packets in R-mode........................8 5.1.2. Reordering of Packets in R-mode........................9
5.1.2.1. Updating Packets..................................8 5.1.2.1. Updating Packets..................................9
5.1.2.2. Non-Updating Packets..............................9 5.1.2.2. Non-Updating Packets..............................9
5.1.3. Reordering of Packets in U/O-mode......................9 5.1.3. Reordering of Packets in U/O-mode.....................10
5.1.4. Reordering on the Feedback Channel....................10 5.1.4. Reordering on the Feedback Channel....................10
5.1.5. List Compression......................................10 5.1.5. List Compression......................................11
5.1.6. Reordering and Mode Transitions.......................11 5.1.6. Reordering and Mode Transitions.......................11
5.2. Consequences of Reordering.................................11 5.2. Consequences of Reordering.................................12
5.2.1. Functionality Incompatible with Reordering............12 5.2.1. Functionality Incompatible with Reordering............12
5.2.2. Context Damage (Loss of Synchronization)..............12 5.2.2. Context Damage (Loss of Synchronization)..............12
5.2.3. Detected Decompression Failures (U/O/R-mode)..........12 5.2.3. Detected Decompression Failures (U/O/R-mode)..........13
5.2.4. Undetected Decompression Failures (R-mode only).......12 5.2.4. Undetected Decompression Failures (R-mode only).......13
6. Making ROHC Tolerant against Reordering.........................13 6. Making ROHC Tolerant against Reordering.........................13
6.1. Properties of ROHC Implementations.........................13 6.1. Properties of ROHC Implementations.........................13
6.1.1. Compressing Headers with Robustness against Reordering13 6.1.1. Compressing Headers with Robustness against Reordering14
6.1.1.1. Reordering and the Optimistic Approach...........13 6.1.1.1. Reordering and the Optimistic Approach...........14
6.1.1.2. Reordering and the Secure Reference Principle....14 6.1.1.2. Reordering and the Secure Reference Principle....14
6.1.1.3. Robust Selection of Compressed Header............14 6.1.1.3. Robust Selection of Compressed Header............14
6.1.2. Implementing a Reordering Tolerant Decompressor.......15 6.1.2. Implementing a Reordering Tolerant Decompressor.......15
6.1.2.1. Bi-directional Reliable Mode (R-mode)............15 6.1.2.1. Decompressor Feedback Considerations.............15
6.1.2.2. Decompressor Feedback Considerations.............15 6.1.2.2. Considerations for Local Repair Mechanisms.......16
6.1.2.3. Considerations for Local Repair Mechanisms.......16
6.2. Specifying ROHC Profiles with Robustness against Reordering16 6.2. Specifying ROHC Profiles with Robustness against Reordering16
6.2.1. Profiles with Interpretation Interval Offset p = -1...16 6.2.1. Profiles with Interpretation Interval Offset p = -1...16
6.2.2. Modifying the Interpretation Interval Offset..........16 6.2.2. Modifying the Interpretation Interval Offset..........17
6.2.2.1. Example profile for handling reordering..........16 6.2.2.1. Example profile for handling reordering..........17
6.2.2.2. Defining the values of p for new profiles........17 6.2.2.2. Defining the values of p for new profiles........17
6.2.3. TCP Profile Considerations............................17 6.2.3. TCP Profile Considerations............................18
7. Security Consideration..........................................18 7. Security Consideration..........................................18
8. IANA Considerations.............................................18 8. IANA Considerations.............................................18
9. Acknowledgments.................................................18 9. Acknowledgments.................................................18
10. Authors' Addresses.............................................18 10. Authors' Addresses.............................................18
11. Informative References.........................................19 11. Informative References.........................................19
1. Introduction 1. Introduction
RObust Header Compression (ROHC), RFC 3095 [2], defines a framework RObust Header Compression (ROHC), RFC 3095 [1], defines a framework
for header compression, along with a number of compression protocols for header compression, along with a number of compression protocols
(profiles). One operating assumption for the profiles defined in RFC (profiles). One operating assumption for the profiles defined in RFC
3095 is that the channel between compressor and decompressor is 3095 is that the channel between compressor and decompressor is
required to maintain packet ordering for each compressed flow. The required to maintain packet ordering for each compressed flow. The
motivation behind this assumption was that the primary candidate motivation behind this assumption was that the primary candidate
channels considered did guarantee in-order delivery of header- channels considered did guarantee in-order delivery of header-
compressed packets; making this assumption made it possible to compressed packets; making this assumption made it possible to
improve the compression efficiency and the tolerance to packet loss, improve the compression efficiency and the tolerance to packet loss,
objectives that were on top of the requirements list at the time. objectives that were on top of the requirements list at the time.
skipping to change at page 3, line 40 skipping to change at page 3, line 40
channels that can reorder header-compressed packets. It explains channels that can reorder header-compressed packets. It explains
different ways of implementing the profiles found in RFC 3095, as different ways of implementing the profiles found in RFC 3095, as
well as other profiles based on those profiles, over reordering well as other profiles based on those profiles, over reordering
channels. This can be achieved either by ensuring that compressor channels. This can be achieved either by ensuring that compressor
implementations use compressed headers that are sufficiently robust implementations use compressed headers that are sufficiently robust
to the expected possible reordering, and/or by modifying decompressor to the expected possible reordering, and/or by modifying decompressor
implementations to tolerate reordered packets. Ideas regarding how implementations to tolerate reordered packets. Ideas regarding how
existing profiles could be updated and how new profiles can be existing profiles could be updated and how new profiles can be
defined to cope efficiently with reordering are also discussed. defined to cope efficiently with reordering are also discussed.
In some scenarios, there might be external means (such as a sequence
number) to detect and potentially correct reordering. That is for
example the case when running compression over an IPsec ESP tunnel.
With such external means to detect reordering, the decompressor can
be modified to make use of the external information provided, and
reordering can then be handled. How to make use of external means to
address reordering is, however, out of scope for this document.
2. Terminology 2. Terminology
This document uses terminology consistent with RFC 3759 [3], and is This document uses terminology consistent with RFC 3759 [2], and is
in itself only informative. Although it does discuss technical in itself only informative. Although it does discuss technical
aspects of implementing the ROHC specifications in particular aspects of implementing the ROHC specifications in particular
environments, it does not specify any new technology. environments, it does not specify any new technology.
However, the document discusses possible ways of modifying existing
ROHC implementations and/or specifications to address its objectives.
In those parts of the document, the key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC 2119 [1].
ROHC ROHC
The term "ROHC" herein refers to the following profiles: The term "ROHC" herein refers to the following profiles:
- 0x0001, 0x0002 and 0x0003 defined in RFC 3095 [2]; - 0x0001, 0x0002 and 0x0003 defined in RFC 3095 [1];
- 0x0004 for compression of IP-only headers [5]; - 0x0004 for compression of IP-only headers [4];
- 0x0007 and 0x0008 for compression of UDP-Lite headers [6]. - 0x0007 and 0x0008 for compression of UDP-Lite headers [5].
The term "ROHC" excludes the following profiles, which are either The term "ROHC" excludes the following profiles, which are either
not affected by reordering or that have the assumption of in-order not affected by reordering or that have the assumption of in-order
delivery as a fundamental requirement for their proper operation: delivery as a fundamental requirement for their proper operation:
- 0x0000 (uncompressed) [2]; - 0x0000 (uncompressed) [1];
- 0x0005 (LLA) [7] and 0x0105 (R-mode extension to LLA) [8]; - 0x0005 (LLA) [6] and 0x0105 (R-mode extension to LLA) [7];
Reordering Reordering
A type of transmission taking place between compressor and A type of transmission taking place between compressor and
decompressor where in-order delivery of header-compressed decompressor where in-order delivery of header-compressed
packets is not guaranteed. packets is not guaranteed.
Reordering Channel Reordering Channel
A connection over which reordering, as defined above, can occur. A connection over which reordering, as defined above, can occur.
skipping to change at page 4, line 46 skipping to change at page 4, line 46
Sequentially late packet Sequentially late packet
A packet is late within its sequence if it reaches the A packet is late within its sequence if it reaches the
decompressor after one or several other packets belonging to the decompressor after one or several other packets belonging to the
same CID have been received, although the sequentially late packet same CID have been received, although the sequentially late packet
was sent from the compressor before the other packet(s). was sent from the compressor before the other packet(s).
Updating packet Updating packet
A packet that updates the context of the decompressor, i.e. all A packet that updates the context of the decompressor, e.g. all
packets carrying a CRC calculated over the uncompressed header. packets except R-0 and R-1* in RFC 3095 [1].
Non-updating packet Non-updating packet
A packet that carries a CRC calculated over the uncompressed A packet that does not update the context of the decompressor,
header updates the context of the decompressor when it is e.g. only R-0 and R-1* in RFC 3095 [1].
successfully decompressed. A packet without such a CRC is thus
referred to as a non-updating packet.
Change packet Change packet
A packet that updates one or more fields of the context other than A packet that updates one or more fields of the context other than
the fields pertaining to the functions established with respect to the fields pertaining to the functions established with respect to
the sequence number (SN). Specifically, it is a packet that the sequence number (SN). Specifically, it is a packet that
updates fields other than the SN, IP-ID or RTP timestamp (TS). updates fields other than the SN, IP-ID or RTP timestamp (TS).
3. Applicability of this Document to ROHC Profiles 3. Applicability of this Document to ROHC Profiles
skipping to change at page 5, line 25 skipping to change at page 5, line 25
The foremost objectives are to ensure that ROHC implementations will The foremost objectives are to ensure that ROHC implementations will
not forward packets with incorrectly decompressed headers to upper not forward packets with incorrectly decompressed headers to upper
layers, as well as to limit the possible increase in the rate of layers, as well as to limit the possible increase in the rate of
decompression failures or in events leading to context damage, when decompression failures or in events leading to context damage, when
compression is applied over reordering channels. compression is applied over reordering channels.
3.1. Profiles within Scope 3.1. Profiles within Scope
The following sections outline solutions that are generally The following sections outline solutions that are generally
applicable to profiles 0x0001 (RTP), 0x0002 (UDP) and 0x0003 (ESP) applicable to profiles 0x0001 (RTP), 0x0002 (UDP) and 0x0003 (ESP)
defined in RFC 3095 [2]. Profile 0x0000 (uncompressed) is not defined in RFC 3095 [1]. Profile 0x0000 (uncompressed) is not
affected by reordering, as the headers are sent uncompressed. The affected by reordering, as the headers are sent uncompressed. The
solutions also apply to profiles for IP-only (0x0004) [5] and for solutions also apply to profiles for IP-only (0x0004) [4] and for
UDP-Lite (0x0007 and 0x0008) [6]. These profiles are based on the UDP-Lite (0x0007 and 0x0008) [5]. These profiles are based on the
profiles of RFC 3095 [2] and inherently make the same in-order profiles of RFC 3095 [1] and inherently make the same in-order
delivery assumption. delivery assumption.
3.2. Profiles with Special Considerations 3.2. Profiles with Special Considerations
Special considerations are needed to make some of the implementation Special considerations are needed to make some of the implementation
solutions of sections 6.1 and 6.2 applicable to profiles 0x0002 (UDP) solutions of sections 6.1 and 6.2 applicable to profiles 0x0002 (UDP)
[2], 0x0004 (IP-only) [5], and 0x0008 (UDP-Lite) [6]. For these [1], 0x0004 (IP-only) [4], and 0x0008 (UDP-Lite) [5]. For these
profiles, the SN is generated at the compressor, as it is not present profiles, the SN is generated at the compressor, as it is not present
in headers being compressed. For the least significant bit (LSB) in headers being compressed. For the least significant bit (LSB)
encoding method, the interpretation interval offset (p) is always encoding method, the interpretation interval offset (p) is always
p = -1 (see section 5.1.1) when interpreting the SN. The SN is thus p = -1 (see section 5.1.1) when interpreting the SN. The SN is thus
required to increase for each packet received at the decompressor, required to increase for each packet received at the decompressor,
which means that reordered packets cannot be decompressed. which means that reordered packets cannot be decompressed.
3.3. Profiles Incompatible with Reordering 3.3. Profiles Incompatible with Reordering
The ROHC LLA profiles defined in RFC 3242 [7] and RFC 3408 [8] have The ROHC LLA profiles defined in RFC 3242 [6] and RFC 3408 [7] have
been explicitly designed with in-order delivery as a fundamental been explicitly designed with in-order delivery as a fundamental
requirement to their proper operation. Profiles 0x0005 and 0x0105 can requirement to their proper operation. Profiles 0x0005 and 0x0105 can
therefore not be implemented over channels where reordering can therefore not be implemented over channels where reordering can
occur; this document therefore does not apply to these profiles. occur; this document therefore does not apply to these profiles.
4. Background 4. Background
ROHC was designed with the assumption that packets are delivered in- ROHC was designed with the assumption that packets are delivered in-
order from compressor to decompressor. This was considered as a order from compressor to decompressor. This was considered as a
reasonable working assumption for links where it was expected that reasonable working assumption for links where it was expected that
ROHC would be used. However, many have expressed that it would be ROHC would be used. However, many have expressed that it would be
desirable to use ROHC also over connections where in-order delivery desirable to use ROHC also over connections where in-order delivery
is not guaranteed [9]. is not guaranteed [8].
4.1. Reordering Channels 4.1. Reordering Channels
The reordering channels that are potential candidates to use ROHC are The reordering channels that are potential candidates to use ROHC are
single-hop channels and multi-hop virtual channels. single-hop channels and multi-hop virtual channels.
A single-hop channel is a point-to-point link that constitutes a A single-hop channel is a point-to-point link that constitutes a
single IP hop. Note that one IP hop could be one or multiple physical single IP hop. Note that one IP hop could be one or multiple physical
links. For example, a single-hop reordering channel could be a links. For example, a single-hop reordering channel could be a
wireless link that applies error detection and performs wireless link that applies error detection and performs
skipping to change at page 6, line 38 skipping to change at page 6, line 38
traverses multiple IP hops. A multi-hop virtual channel would traverses multiple IP hops. A multi-hop virtual channel would
typically be an IP tunnel, where compression is applied over the typically be an IP tunnel, where compression is applied over the
tunnel by the endpoints of the tunnel (not to be confused with single tunnel by the endpoints of the tunnel (not to be confused with single
link compression of tunneled packets). link compression of tunneled packets).
4.2. Robustness Principles of ROHC 4.2. Robustness Principles of ROHC
Robustness is based on the optimistic approach in the unidirectional Robustness is based on the optimistic approach in the unidirectional
and optimistic modes of operation (U/O-mode), and on the secure and optimistic modes of operation (U/O-mode), and on the secure
reference principle in the bi-directional reliable mode (R-mode). reference principle in the bi-directional reliable mode (R-mode).
Both approaches have different characteristics in the presence of Both approaches have different characteristics in the presence of
reordering between compressor and decompressor. However, in any mode, reordering between compressor and decompressor. However, in any mode,
decompression of sequentially early packets will generally be handled decompression of sequentially early packets will generally be handled
quite well since they will be perceived and treated by the quite well since they will be perceived and treated by the
decompressor as if there had been one or more packet losses. decompressor as if there had been one or more packet losses.
4.2.1. Optimistic Approach (U/O-mode) 4.2.1. Optimistic Approach (U/O-mode)
A ROHC compressor uses the optimistic approach to reduce header A ROHC compressor uses the optimistic approach to reduce header
overhead when performing context updates in U/O-mode. The compressor overhead when performing context updates in U/O-mode. The compressor
normally repeats the same update until it is fairly confident that normally repeats the same update until it is fairly confident that
the decompressor has successfully received the information. The the decompressor has successfully received the information. The
number of consecutive packets needed to obtain this confidence is number of consecutive packets needed to obtain this confidence is
open to implementations, and this number is normally related to the open to implementations, and this number is normally related to the
packet loss characteristics of the link where header compression is packet loss characteristics of the link where header compression is
used (see also [2], section 5.3.1.1.1). All packet types used in U/O- used (see also [1], section 5.3.1.1.1).
mode are context updating.
All packet types used in U/O-mode are context updating.
4.2.2. Secure Reference Principle (R-mode) 4.2.2. Secure Reference Principle (R-mode)
A ROHC compressor uses the secure reference principle in R-mode, to A ROHC compressor uses the secure reference principle in R-mode, to
ensure that context synchronization between ROHC peers cannot be lost ensure that context synchronization between ROHC peers cannot be lost
due to packet losses. The compressor obtains its confidence that the due to packet losses. The compressor obtains its confidence that the
decompressor has successfully updated the context from a packet decompressor has successfully updated the context from a packet
carrying a 7- or 8-bit CRC based on acknowledgements received from carrying a 7- or 8-bit CRC based on acknowledgements received from
the decompressor (see also [2], section 5.5.1.2). the decompressor (see also [1], section 5.5.1.2).
The secure reference principle makes it possible for a compressor to The secure reference principle makes it possible for a compressor to
use packets that do not update the context (i.e. R-0 and R-1* [2]). use packets that do not update the context (i.e. R-0 and R-1* [1]).
5. Problem Description 5. Problem Description
5.1. ROHC and Reordering Channels 5.1. ROHC and Reordering Channels
This section reviews different aspects of ROHC susceptible of being This section reviews different aspects of ROHC susceptible of being
impacted by reordering of compressed packets between ROHC peers. impacted by reordering of compressed packets between ROHC peers.
5.1.1. LSB Interpretation Interval and Reordering 5.1.1. LSB Interpretation Interval and Reordering
The LSB encoding method defined in RFC 3095 ([2], section 5.7) The LSB encoding method defined in RFC 3095 ([1], section 5.7)
specifies the interpretation interval offset, called p, as follow: specifies the interpretation interval offset, called p, as follow:
For profiles 0x0001, 0x0003 and 0x0007: For profiles 0x0001, 0x0003 and 0x0007:
p = 1, when bits(SN) <= 4; p = 1, when bits(SN) <= 4;
p = 2^(bits(SN)-5) - 1 otherwise. p = 2^(bits(SN)-5) - 1 otherwise.
The resulting table describing the interpretation interval is: The resulting table describing the interpretation interval is:
+-----------+--------------+--------------+ +-----------+--------------+--------------+
skipping to change at page 8, line 47 skipping to change at page 8, line 47
max delta(SN) = p max delta(SN) = (2^k-1) - p max delta(SN) = p max delta(SN) = (2^k-1) - p
where v_ref is the reference value as per [2]. where v_ref is the reference value as per [2].
In practice, the maximum variation in SN value (max delta(SN)) In practice, the maximum variation in SN value (max delta(SN))
due to reordering that can be handled will normally correspond to due to reordering that can be handled will normally correspond to
the maximum number of packets that can be reordered. The same the maximum number of packets that can be reordered. The same
applies to the maximum number of consecutive packet losses covered applies to the maximum number of consecutive packet losses covered
by the robustness interval. by the robustness interval.
Timer-based compression of RTP TS (see [1], section 4.5.4) provides
means to reduce the number of timestamp bits needed in compressed
headers after longer gaps in the packet stream (typically due to
silence suppression). To use timer-based compression, an upper limit
on the inter-arrival jitter must be reliably estimated by the
compressor. It should be noted that although the risk of reordering
of course means there is a more significant jitter on the path
between the compressor and the decompressor, there are no special
reordering considerations for timer-based compression. It all still
boils down to the task of estimating the jitter, requiring channel
characteristics knowledge at the compressor, and/or jitter estimation
figures received from the decompressor.
5.1.2. Reordering of Packets in R-mode 5.1.2. Reordering of Packets in R-mode
5.1.2.1. Updating Packets 5.1.2.1. Updating Packets
The compressor always adds references in the sliding window for all The compressor always adds references in the sliding window for all
updating packets sent. The compressor removes values smaller than updating packets sent. The compressor removes values older than
values for which it has received an acknowledgement, to shrink the values for which it has received an acknowledgement, to shrink the
window and thereby increase the compression efficiency. window and thereby increase the compression efficiency.
The decompressor always updates the context when receiving an The decompressor always updates the context when receiving an
updating packet, and uses the new reference for decompression. updating packet, and uses the new reference for decompression.
Acknowledgements are sent to allow the compressor to shrink its Acknowledgements are sent to allow the compressor to shrink its
sliding window. sliding window.
Reordering between updating packets Reordering between updating packets
skipping to change at page 9, line 49 skipping to change at page 10, line 11
packet is received. It is thus possible for a non-updating packet packet is received. It is thus possible for a non-updating packet
to be decompressed based on the wrong reference because of to be decompressed based on the wrong reference because of
reordering when operating in R-mode. reordering when operating in R-mode.
Since decompression of non-updating packets cannot be verified, Since decompression of non-updating packets cannot be verified,
this can lead to a packet erroneously decompressed being forwarded this can lead to a packet erroneously decompressed being forwarded
to upper layers. to upper layers.
5.1.3. Reordering of Packets in U/O-mode 5.1.3. Reordering of Packets in U/O-mode
Sequentially late packets Reordering between non-change packets only
The ability to decompress sequentially late packets is limited by When only non-change packets are reordered with respect to each
other, decompression of sequentially late packets is limited by
the offset p of the interpretation interval (see section 5.1.1). the offset p of the interpretation interval (see section 5.1.1).
Decompression of a sequentially late packet with SN = x is Decompression of a sequentially late packet with SN = x is
possible if the value of the SN of the packet that last updated possible if the value of the SN of the packet that last updated
the context was less than or equal to x + p. the context was less than or equal to x + p.
Problems occur if context(SN) has increased by more than p with Problems occur if context(SN) has increased by more than p with
respect to field(SN) carried within the packet to decompress. respect to field(SN) carried within the packet to decompress.
This means that for a well-behaved stream with a constant unit This means that for a well-behaved stream with a constant unit
increase in the RTP SN, a packet can arrive up to p packets out of increase in the RTP SN, a packet can arrive up to p packets out of
sequence and still be correctly decompressed. Otherwise, it cannot sequence and still be correctly decompressed. Otherwise, it cannot
be properly decompressed. It also means that if the compressor be properly decompressed. It also means that if the compressor
sends two consecutive packets with SN(packet1)=100 and sends two consecutive packets with SN(packet1)=100 and
SN(packet2)=108 when p=7, packet1 cannot be decompressed if it SN(packet2)=108 when p=7, packet1 cannot be decompressed if it
arrives even one packet late due to reordering. arrives even one packet late due to reordering.
Reordering involving change packets
When a packet is reordered and becomes sequentially late with
respect to a change packet, decompression of the late packet may
eventually fail, as the context information required for
successful decompression may not be available anymore.
Decompression can always be verified since all U/O-mode packet types Decompression can always be verified since all U/O-mode packet types
are context updating. Consequently, reordering of packets is not are context updating. Consequently, a failure to decompress a packet
deemed problematic when operating in U/O-mode. For channels known to that is caused by reordering can be detected, and context
reorder packets, the U/O-mode should therefore be the preferred mode invalidation due to reordering can thus be avoided. The risk of
of operation. The additional risk of losing context synchronization, forwarding incorrectly decompressed packets to upper layers is
or for erroneous packet to be delivered to upper layers, is limited. therefore small when operating in U/O-mode. For channels known to
reorder packets, U/O-mode should therefore be the preferred mode of
operation. The additional risk of losing context synchronization, or
for erroneous packet to be delivered to upper layers, is limited.
5.1.4. Reordering on the Feedback Channel 5.1.4. Reordering on the Feedback Channel
For R-mode, upon reception of an acknowledgement, the compressor For R-mode, upon reception of an acknowledgement, the compressor
searches the sliding window to locate an updating packet with the searches the sliding window to locate an updating packet with the
corresponding SN; if it is not found, the acknowledgement is invalid corresponding SN; if it is not found, the acknowledgement is invalid
and is discarded ([2], section 5.5.1.2). In other words, feedback and is discarded ([1], section 5.5.1.2). In other words, feedback
received out-of-order either is still useful or is discarded. received out-of-order either is still useful or is discarded.
In U/O-mode, if the compressor updates its context based on feedback, In U/O-mode, if the compressor updates its context based on feedback,
the same logic as for R-mode applies in practice. the same logic as for R-mode applies in practice.
Reordering on the feedback channel has thus no impact in either mode. Reordering on the feedback channel has thus no impact in either mode.
5.1.5. List Compression 5.1.5. List Compression
List compression in ROHC is a compression scheme for RTP CSRC lists ROHC list compression is an additional compression scheme for RTP
and IP extension header chains, which is almost completely CSRC lists and IP extension header chains, which is almost completely
independent from the ordinary ROHC operation. The base is called independent from the ordinary ROHC operation. The base is called
table-based item compression, and this part of the scheme does not table-based item compression, and this part of the scheme does not
exhibit any special vulnerability when it comes to reordering, exhibit any special vulnerabilities when it comes to reordering,
assuming a reasonable optimistic approach is used in U/O-mode. When assuming a reasonable optimistic approach is used in U/O-mode.
operating in R-mode, table-based item compression does not suffer Specifically, it does not suffer significantly from the "missing
significantly from the "missing reference" problem. reference" problem when operating in R-mode.
On top of the table-based item compression mechanism, an additional On top of the table-based item compression mechanism, an additional
compression technique may be used, called reference based list compression technique may be used, called reference based list
compression. Reference based list compression has a logic that is compression. Reference based list compression has a logic that is
similar to most other compression methods used by ROHC; therefore it similar to ordinary ROHC compression, and therefore it suffers from
suffers from similar reordering vulnerabilities, especially with similar reordering vulnerabilities, especially the "missing
respect to the "missing reference" problem of R-mode. Note however reference" problem of R-mode. Note however that the generation
that the generation identifier used in U/O-mode makes the U/O-mode identifier used in U/O-mode makes that scheme more robust to
scheme more robust to reordering. reordering.
List encoding of type 1, 2, or 3 makes use of reference lists. When
using these types of list encoding, decompression will only succeed
if all individual items are known by the decompressor, along with the
specific reference list referred.
List compression using the "Generic scheme", also known as "List When using list encoding type 1,2, or 3, which makes use of reference
encoding type 0", does not use reference based list compression; lists, decompression will only succeed if all individual items are
decompression with list encoding type 0 will thus succeed as long as known by the decompressor, along with the specific reference list
all individual items are known by the decompressor. Because of this, referred. List compression using the "Generic scheme", also known as
list compression type 0 should be the preferred method used when "Encoding type 0", is not using reference based list compression, and
operating over reordering channels. type 0 decompression will thus succeed as long as all individual
items are known by the decompressor. Because of this, type 0 list
compression should be the preferred method used when operating over
reordering channels.
5.1.6. Reordering and Mode Transitions 5.1.6. Reordering and Mode Transitions
Transition from U/O-mode to R-mode Transition from U/O-mode to R-mode
This transition can be affected by reordering if a packet type 0 This transition can be affected by reordering if a packet type 0
(UO-0) is reordered and delayed by at least one round-trip time (UO-0) is reordered and delayed by at least one round-trip time
(RTT). If the decompressor initiates a mode change request to R- (RTT). If the decompressor initiates a mode change request to R-
mode in the meantime, the reordered UO-0 packet may be handled as mode in the meantime, the reordered UO-0 packet may be handled as
an R-0 packet; it can be erroneously decompressed and forwarded to an R-0 packet; it can be erroneously decompressed and forwarded to
upper layers. This is because the decompressor can switch to upper layers. This is because the decompressor can switch to
R-Mode as soon as it sends the acknowledgement Ack(SN, R) to the R-Mode as soon as it sends the acknowledgement Ack(SN, R) to the
compressor (see also [2], section 5.6). compressor (see also [1], section 5.6).
Transition from R-mode to U/O-mode Transition from R-mode to U/O-mode
A similar situation as above can occur during this transition. A similar situation as above can occur during this transition.
However, because the outcome of the decompression is always However, because the outcome of the decompression is always
verified using a CRC verification in U/O-mode, the reordered verified using a CRC verification in U/O-mode, the reordered
packet will most likely fail decompression and will be discarded. packet will most likely fail decompression and will be discarded.
The above situation, while it is not deemed to occur frequently, is The above situation, while it is not deemed to occur frequently, is
still possible; thus mode transitions from U/O-mode to R-mode should still possible; thus mode transitions from U/O-mode to R-mode should
skipping to change at page 12, line 7 skipping to change at page 12, line 32
The effects of reordering on ROHC can be summarized as follow: The effects of reordering on ROHC can be summarized as follow:
- Functionality incompatible with reordering; - Functionality incompatible with reordering;
- Increased probability of context damage (loss of synchronization); - Increased probability of context damage (loss of synchronization);
- Increased number of decompression failures - Detected (U/O/R-mode); - Increased number of decompression failures - Detected (U/O/R-mode);
- Increased number of decompression failures - Undetected (R-mode). - Increased number of decompression failures - Undetected (R-mode).
5.2.1. Functionality Incompatible with Reordering 5.2.1. Functionality Incompatible with Reordering
There are some optional ROHC functions that cannot work in the There is one optional ROHC function that cannot work in the presence
presence of reordering between ROHC peers. of reordering between ROHC peers.
The ROHC segmentation scheme (see [2], section 5.2.5) relies entirely The ROHC segmentation scheme (see [1], section 5.2.5) relies entirely
on the in-order delivery of each segment, as there is no sequencing on the in-order delivery of each segment, as there is no sequencing
information in the segments. A segmented packet for which one (or information in the segments. A segmented packet for which one (or
more) segment is received out-of-order cannot be decompressed, and is more) segment is received out-of-order cannot be decompressed, and is
discarded by the decompressor. Therefore segmentation should not be discarded by the decompressor. Therefore segmentation should not be
used if there can be reordering between the ROHC peers. used if there can be reordering between the ROHC peers.
Timer-based compression of RTP TS (see [2], section 4.5.4) is built The use of this optional feature is open to implementations and is
on an assumption of timely (minimal jitter) delivery. When using this
encoding method, the decompressor discards packets arriving with an
arrival time that is outside the estimated upper bound for the
estimated jitter. Therefore it should be used with care over links
where reordering can occur, with respect to the amount of jitter that
can be introduced by reordering.
The use of these optional features is open to implementations and is
local to the compressor only; it does not impact the decompressor. local to the compressor only; it does not impact the decompressor.
5.2.2. Context Damage (Loss of Synchronization) 5.2.2. Context Damage (Loss of Synchronization)
Reordering of packets between ROHC peers can impact the robustness Reordering of packets between ROHC peers can impact the robustness
properties of the optimistic approach (U/O-mode) as well as the properties of the optimistic approach (U/O-mode) as well as the
reliability of the secure reference principle (R-mode). reliability of the secure reference principle (R-mode).
The successful decompression of a sequentially late change packet The successful decompression of a sequentially late change packet
(U/O-mode) and/or updating packet (R-mode) can update the context of (U/O-mode) and/or updating packet (R-mode) can update the context of
the decompressor in a manner unexpected by the compressor. This can the decompressor in a manner unexpected by the compressor. This can
lead to a loss of context synchronization between the ROHC peers. lead to a loss of context synchronization between the ROHC peers.
5.2.3. Detected Decompression Failures (U/O/R-mode) 5.2.3. Detected Decompression Failures (U/O/R-mode)
Reordering of packets between ROHC peers can lead to an increase in Reordering of packets between ROHC peers can lead to an increase in
the number of decompression failures for context updating packets the number of decompression failures for context updating packets
(see sections 5.1.2.1 and 5.1.3). Fortunately, as the outcome of the (see sections 5.1.2.1 and 5.1.3). Fortunately, as the outcome of the
decompression of updating packets can be verified, the decompressor decompression of updating packets can be verified, the decompressor
can reliably detect decompression failures caused by reordering and can reliably detect decompression failures, including those caused by
discard the packet. Note that local repairs, subject to the reordering, and discard the packet. Note that local repairs, subject
limitations stated in [2] section 5.3.2.3, can still be performed. to the limitations stated in [1] section 5.3.2.2.3, can still be
performed.
5.2.4. Undetected Decompression Failures (R-mode only) 5.2.4. Undetected Decompression Failures (R-mode only)
Reordering of packets between ROHC peers can lead to an increase in Reordering of packets between ROHC peers can lead to an increase in
the number of decompression errors for non-updating packets. For R- the number of decompression errors for non-updating packets. For R-
mode, decompression of R-0 and R-1* packets cannot be verified. If mode, decompression of R-0 and R-1* packets cannot be verified. If
reordering occurs and decompression is performed using the wrong reordering occurs and decompression is performed using the wrong
secure reference (see section 5.1.2.1 and 5.1.2.2), the decompressor secure reference (see section 5.1.2.1 and 5.1.2.2), the decompressor
cannot reliably detect such errors. As a result, erroneous packets cannot reliably detect such errors. As a result, erroneous packets
may be forwarded to upper layers. may be forwarded to upper layers.
skipping to change at page 13, line 26 skipping to change at page 13, line 45
6.1. Properties of ROHC Implementations 6.1. Properties of ROHC Implementations
Existing ROHC profiles can be implemented with the capability to Existing ROHC profiles can be implemented with the capability to
properly handle packet reordering. The methods described in this properly handle packet reordering. The methods described in this
section conform with, and thus do not require any modifications to, section conform with, and thus do not require any modifications to,
the ROHC specifications within scope of this document (see section the ROHC specifications within scope of this document (see section
3). Specifically, the methods presented in this section can be 3). Specifically, the methods presented in this section can be
implemented without any impairment to interoperability with other implemented without any impairment to interoperability with other
ROHC implementations that do not use these methods. ROHC implementations that do not use these methods.
The methods suggested here may however lower compression efficiency, The methods suggested here may, however, lower compression
and these modifications should not be used when reordering is known efficiency, and these modifications should not be used when
not to occur. Some of these methods aim to increase the decompression reordering is known not to occur. Some of these methods aim to
success rate at the decompressor, while others aim to avoid context increase the decompression success rate at the decompressor, while
damages causing loss of context synchronization between compressor others aim to avoid context damages causing loss of context
and decompressor. synchronization between compressor and decompressor.
The methods proposed are each addressing specific issues listed in The methods proposed are each addressing specific issues listed in
section 5, and can be combined to achieve better robustness against section 5, and can be combined to achieve better robustness against
reordering. reordering.
6.1.1. Compressing Headers with Robustness against Reordering 6.1.1. Compressing Headers with Robustness against Reordering
The methods described in this section are methods local only to the The methods described in this section are methods local only to the
compressor implementation. They can be used without modifications or compressor implementation. They can be used without modifications or
impact to the decompressor. impact to the decompressor.
skipping to change at page 14, line 30 skipping to change at page 14, line 47
to the secure reference is sufficient for correct decompression, but to the secure reference is sufficient for correct decompression, but
only when in-order delivery between ROHC peers is guaranteed. only when in-order delivery between ROHC peers is guaranteed.
Avoiding the "missing reference" problem (section 5.1.2.1) Avoiding the "missing reference" problem (section 5.1.2.1)
A compressor implementation can delay the advance in the sliding A compressor implementation can delay the advance in the sliding
window to a reference acknowledged by the decompressor, until it window to a reference acknowledged by the decompressor, until it
has confidence that no acknowledgement for any of the values that has confidence that no acknowledgement for any of the values that
could be discarded can be received. This confidence can be based could be discarded can be received. This confidence can be based
on the maximum delay that reordering can introduce over the on the maximum delay that reordering can introduce over the
channel. It can also be based on the knowledge that the channel.
decompressor implements the context updating logic of section
6.1.2.1 (e.g. by means of standardization).
6.1.1.3. Robust Selection of Compressed Header 6.1.1.3. Robust Selection of Compressed Header
The interpretation interval for the LSB encoded sequence number can Packet formats could be chosen with an interpretation interval for
be adjusted to allow for larger negative offsets (see section 5.1.1). the LSB encoded sequence number that allow for larger negative
This would provide the capability to decompress sequentially late offsets (see section 5.1.1). This would provide the capability to
packets with a greater amount of reordering. decompress sequentially late packets with a greater amount of
reordering.
To achieve this, the compressor should be implemented conservatively To achieve this, the compressor should be implemented conservatively
in terms of the choice of packet types to send, by transmitting in terms of the choice of packet types to send, by transmitting
packets with more sequence number bits. As shown in the table of packets with more sequence number bits. As shown in the table of
section 5.1.1, using eight bits of SN allows a packet to be section 5.1.1, using eight bits of SN allows a packet to be
decompressed when the reordering leads to up to seven units in decompressed when the reordering leads to up to seven units in
sequence number variation (i.e. delta(SN)). Increasing the number of sequence number variation (i.e. delta(SN)). Increasing the number of
SN bits (i.e. using a larger SN_k [2]) transmitted will make ROHC SN bits (i.e. using a larger SN_k [1]) transmitted will make ROHC
even more tolerant to reordering. even more tolerant to reordering.
For example, a conservative compressor implementation could use the For example, a conservative compressor implementation could use the
packet types as shown in the table below: packet types as shown in the table below:
+----------------------+-------------------------+ +----------------------+-------------------------+
| Optimal Packet Type | Alternative Packet Type | | Optimal Packet Type | Alternative Packet Type |
| (without reordering) | (reordering possible) | | (without reordering) | (reordering possible) |
+----------------------+-------------------------+ +----------------------+-------------------------+
| UO-0 | UOR-2*-ext0 | | UO-0 | UOR-2*-ext0 |
skipping to change at page 15, line 36 skipping to change at page 15, line 48
0x0004 and 0x0008 is always p = -1 independently of bits(SN), the 0x0004 and 0x0008 is always p = -1 independently of bits(SN), the
methods suggested in this section will not work for these profiles methods suggested in this section will not work for these profiles
unless this value is modified (section 6.2.1). unless this value is modified (section 6.2.1).
6.1.2. Implementing a Reordering Tolerant Decompressor 6.1.2. Implementing a Reordering Tolerant Decompressor
The methods described in this section are methods local only to the The methods described in this section are methods local only to the
decompressor implementation. They can be used without modifications decompressor implementation. They can be used without modifications
or impact to the compressor. or impact to the compressor.
6.1.2.1. Bi-directional Reliable Mode (R-mode) 6.1.2.1. Decompressor Feedback Considerations
The "missing reference" problem described in section 5.1.2.1 can be
avoided. If the decompressor can detect when two updating packets
(packets including CRCs) are reordered with respect to each other, it
should not update the context with the values of the sequentially
late update packet.
6.1.2.2. Decompressor Feedback Considerations
Reducing the feedback rate when the flow behaves linearly Reducing the feedback rate when the flow behaves linearly
The decompressor should reduce its feedback rate when a large The decompressor should reduce its feedback rate when a large
number of UOR-2 packets with extensions are received, when the number of UOR-2 packets with extensions are received, when the
flow behaves linearly (i.e. when only fields pertaining to the flow behaves linearly (i.e. when only fields pertaining to the
functions established with respect to the sequence number are functions established with respect to the sequence number are
changing. changing.
In particular, if the compressor implementation makes a more In particular, if the compressor implementation makes a more
conservative selection of packet types (section 6.1.1.3) in order conservative selection of packet types (section 6.1.1.3) in order
to handle reordering, the decompressor should try to avoid sending to handle reordering, the decompressor should try to avoid sending
more feedback than it would for the case where the more optimal more feedback than it would for the case where the more optimal
packet types are used. This can be useful to minimize the usage of packet types are used. This can be useful to minimize the usage of
the feedback channel, thereby improving effiency of the link. the feedback channel, thereby improving efficiency of the link.
Note that if the decompressor does not make this adjustment to its Note that even if the decompressor does not make this adjustment
feedback rate, packet losses or context damages will not increase. to its feedback rate, packet losses or context damages will not
increase.
Acknowledgements and sequentially late packets Acknowledgements and sequentially late packets
Reordered feedback (or feedback for packets received out-of-order) Reordered feedback (or feedback for packets received out-of-order)
will not cause problems (see section 5.1.4). However, the will not cause problems (see section 5.1.4). However, the
decompressor should not send feedback for sequentially late decompressor should not send acknowledging feedback for a packet
packets, as the current state of the context will better reflect if it is reasonable to believe it is sequentially late (e.g. by
the compressor context than the content of the reordered packet. just looking at the sequence number of the packet), as the current
state of the context will better reflect the compressor context
than the content of the reordered packet.
6.1.2.3. Considerations for Local Repair Mechanisms 6.1.2.2. Considerations for Local Repair Mechanisms
When decompression fails, and if reordering can be the cause of this When decompression fails, and if reordering is believed to be cause
failure, a local repair may be attempted for the sequentially late of this failure, subsequent decompressions may be attempted for
packet by going backward in the interpretation interval (as opposed sequentially late packets by going backwards in the interpretation
to moving forward as for packet losses). interval (as opposed to moving forward for local repair). If one of
the decompression attempt is successful, the late packet may be
passed on to upper layers with or without updating the decompressor
context. If the subsequent decompression attempt fails, the packet
should be handled according to [2] section 5.3.2.2.3.
6.2. Specifying ROHC Profiles with Robustness against Reordering 6.2. Specifying ROHC Profiles with Robustness against Reordering
6.2.1. Profiles with Interpretation Interval Offset p = -1 6.2.1. Profiles with Interpretation Interval Offset p = -1
New revisions of profiles 0x0002 (UDP) [2], 0x0004 (IP-only) [5], and New revisions of profiles 0x0002 (UDP) [1], 0x0004 (IP-only) [4], and
0x0008 (UDP-Lite) [6] should redefine how the value of the offset p 0x0008 (UDP-Lite) [5] should redefine how the value of the offset p
is determined, and use the same algorithm as in profile 0x0001 [2] is determined, and use the same algorithm as in profile 0x0001 [1]
instead of p = -1 independently of bits(SN) (section 5.1.1). instead of p = -1 independently of bits(SN) (section 5.1.1).
While such a change would make these updated profiles slightly less While such a change would make these updated profiles slightly less
robust to packet losses, they would still be no less robust than robust to packet losses, they would still be no less robust than
profile 0x0001. profile 0x0001.
6.2.2. Modifying the Interpretation Interval Offset 6.2.2. Modifying the Interpretation Interval Offset
The interpretation interval offset p could be modified for existing The interpretation interval offset p could be modified for existing
profile to handle reordering while improving the compression profile to handle reordering while improving the compression
skipping to change at page 17, line 30 skipping to change at page 17, line 42
| 8 | 85 | 170 | | 8 | 85 | 170 |
| 9 | 170 | 341 | | 9 | 170 | 341 |
+-----------+--------------+----------------+ +-----------+--------------+----------------+
Using this value for p, a fair amount of reordering can be handled Using this value for p, a fair amount of reordering can be handled
without having to send UOR-2 packets most of the time. The trade-off without having to send UOR-2 packets most of the time. The trade-off
is that this is at the expense of robustness against packet losses. is that this is at the expense of robustness against packet losses.
6.2.2.2. Defining the values of p for new profiles 6.2.2.2. Defining the values of p for new profiles
As described in RFC3095, the interpretation interval when sending k As described in RFC3095 [1], the interpretation interval when sending
bits of SN is defined as: k bits of SN is defined as:
f(v_ref, k) = [v_ref - p, v_ref + (2^k - 1) - p] f(v_ref, k) = [v_ref - p, v_ref + (2^k - 1) - p]
The negative bound (v_ref - p) limits the ability to handle The negative bound (v_ref - p) limits the ability to handle
reordering, while the positive bound (v_ref + (2^k - 1) - p) limits reordering, while the positive bound (v_ref + (2^k - 1) - p) limits
the ability to handle packet losses. the ability to handle packet losses.
Adjusting p will increase one of these ranges, while the other range Adjusting p will increase one of these ranges, while the other range
will decrease. This trade-off between the capability to handle will decrease. This trade-off between the capability to handle
reordering and packet losses, including how these correlate with each reordering and packet losses, including how these correlate with each
other, should be considered when a ROHC profile that is meant to other, should be considered when a ROHC profile that is meant to
handle reordering. handle reordering.
For example, if it is desirable for a profile to be as robust against For example, if it is desirable for a profile to be as robust against
reordering (negative range) and against packet losses (positive reordering (negative range) and against packet losses (positive
range), this range can be made equal by setting p near (2^k / 2). range), this range can be made equal by setting p near (2^k / 2).
6.2.3. TCP Profile Considerations 6.2.3. TCP Profile Considerations
The current draft for the ROHC TCP profile [4] contains packet The current draft for the ROHC TCP profile [3] contains packet
formats that allow sending as little as 1 bit of MSN (master sequence formats that allow sending as little as 1 bit of MSN (master sequence
number). Since the MSN is used in the same fashion as the sequence number). Since the MSN is used in the same fashion as the sequence
number in profile 0x0002, it will not be possible to decompress number in profile 0x0002, it will not be possible to decompress
reordered packets if used over a reordering channel. reordered packets if used over a reordering channel.
The work on the ROHC-TCP profile should consider using more bits of The work on the ROHC-TCP profile should consider using more bits of
MSN to enable simple implementation modifications when operating over MSN to enable simple implementation modifications when operating over
a reordering channel. a reordering channel.
7. Security Consideration 7. Security Consideration
This document does not include additional security risks to [2]. In This document does not include additional security risks to [1]. In
addition, it may lower risks related to context damage in R-mode with addition, it may lower risks related to context damage in R-mode with
injected packets when sequentially late packets do not update the injected packets when sequentially late packets do not update the
context (section 6.1.2.1). context (section 6.1.2.1).
8. IANA Considerations 8. IANA Considerations
This document does not require any IANA action. This document does not require any IANA action.
9. Acknowledgments 9. Acknowledgments
Thanks to Ramin Rezaiifar and to Gorry Fairhurst for their comments. Thanks to the committed WG document reviewers, Carl Knutsson and Mark
West, for their review efforts. Thanks also to Aniruddha Kulkarni,
Ramin Rezaiifar and Gorry Fairhurst for their constructive comments.
10. Authors' Addresses 10. Authors' Addresses
Ghyslain Pelletier Ghyslain Pelletier
Ericsson AB Ericsson AB
Box 920 Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43 Phone: +46 8 404 29 43
Fax: +46 920 996 21 Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com EMail: ghyslain.pelletier@ericsson.com
skipping to change at page 18, line 41 skipping to change at page 19, line 4
Fax: +46 920 996 21 Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com EMail: ghyslain.pelletier@ericsson.com
Lars-Erik Jonsson Lars-Erik Jonsson
Ericsson AB Ericsson AB
Box 920 Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61 Phone: +46 8 404 29 61
Fax: +46 920 996 21 Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com EMail: lars-erik.jonsson@ericsson.com
Kristofer Sandlund Kristofer Sandlund
Effnet AB Ericsson AB
Stationsgatan 69 Box 920
S-972 34 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 920 609 17 Phone: +46 8 404 41 58
Fax: +46 920 609 27 Fax: +46 920 996 21
EMail: kristofer.sandlund@effnet.com EMail: kristofer.sandlund@ericsson.com
11. Informative References 11. Informative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bormann, C., et al., "RObust Header Compression (ROHC):
Levels", RFC 2119, March 1997.
[2] Bormann, C., et al., "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed", Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
[3] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology [2] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology
and Channel Mapping Examples", RFC 3759, April 2004. and Channel Mapping Examples", RFC 3759, April 2004.
[4] Pelletier, G., et al., "RObust Header Compression (ROHC): TCP/IP [3] Pelletier, G., et al., "RObust Header Compression (ROHC): TCP/IP
Profile (ROHC-TCP)", Internet-Draft (work in progress), Profile (ROHC-TCP)", Internet-Draft (work in progress),
<draft-ietf-rohc-tcp-08.txt>, October 2004. <draft-ietf-rohc-tcp-09.txt>, February 2005.
[5] Jonsson, L-E., and G. Pelletier, "RObust Header Compression [4] Jonsson, L-E., and G. Pelletier, "RObust Header Compression
(ROHC): A compression profile for IP", RFC 3843, June 2004. (ROHC): A compression profile for IP", RFC 3843, June 2004.
[6] Pelletier, G., "RObust Header Compression (ROHC): Profiles for [5] Pelletier, G., "RObust Header Compression (ROHC): Profiles for
UDP-Lite", Internet draft (work in progress), UDP-Lite", RFC 4019, April 2005.
<draft-ietf-rohc-udp-lite-04.txt>, June 2004.
[7] Jonsson, L-E., and G. Pelletier, "RObust Header Compression [6] Jonsson, L-E., and G. Pelletier, "RObust Header Compression
(ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242,
April 2002. April 2002.
[8] Liu, Z., and K. Le, "Zero-byte Support for Bidirectional [7] Liu, Z., and K. Le, "Zero-byte Support for Bidirectional
Reliable Mode (R-mode) in Extended Link-Layer Assisted Profile Reliable Mode (R-mode) in Extended Link-Layer Assisted Profile
for RObust Header Compression (ROHC) Profile", RFC 3408, for RObust Header Compression (ROHC) Profile", RFC 3408,
December 2002. December 2002.
[9] Ash, J., Goode, B., and J. Hand, "Requirements for Header [8] Ash, J., Goode, B., and J. Hand, "Requirements for Header
Compression over MPLS", Internet draft (work in progress), Compression over MPLS", Internet draft (work in progress),
<draft-ietf-avt-hc-mpls-reqs-03.txt>, June 2004. <draft-ietf-avt-hc-mpls-reqs-03.txt>, June 2004.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
skipping to change at page 20, line 31 skipping to change at page 20, line 31
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires August 17, 2005. This Internet-Draft expires November 16, 2005.
 End of changes. 74 change blocks. 
165 lines changed or deleted 174 lines changed or added

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