One document matched: draft-kapoor-rohc-profiles-reordering-00.txt
Robust Header Compression R. Kapoor, Qualcomm
Internet-Draft C. Trabelsi, Lucent
Q. Zhang, Lucent
Expires: January 14, 2007 July 14, 2006
RObust Header Compression: RTP, UDP, ESP Profiles with Efficient
Support for Reordering
draft-kapoor-rohc-profiles-reordering-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Kapoor, et. al. Expires January 14, 2007 [Page 1]
Internet-Draft RoHC Profiles with Reordering July 2006
Abstract
This document specifies ROHC (Robust Header Compression) profiles
for compression of RTP/UDP/IP (Real-Time Transport Protocol, User
Datagram Protocol, Internet Protocol), UDP/IP and ESP/IP
(Encapsulating Security Payload) headers. These profiles inherit
most of their functionality from the RFC 3095 profiles, with the
exception that efficient support for out-of-order delivery of
packets is added to these new profiles. The profiles defined in
this document do not provide mechanisms to alleviate the issues
with reordering in the R mode, and these profiles SHOULD be used
only in the U/O modes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Tradeoff between Robustness to Losses and Reordering . . . . . 3
4. Changes from RFC 3095 profiles . . . . . . . . . . . . . . . . 4
4.1. Change to IR packet . . . . . . . . . . . . . . . . . . . 4
5. Recommendations for Use of Profiles . . . . . . . . . . . . . 6
5.1 RoHC Segmentation . . . . . . . . . . . . . . . . . . . . . 6
5.2 List Compression . . . . . . . . . . . . . . . . . . . . . 6
5.3 R-Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . 9
1. Introduction
RFC 3095 [1] defines profiles for compression of RTP/UDP/IP (Real-
Time Transport Protocol, User Datagram Protocol, Internet Protocol),
UDP/IP, ESP/IP (Encapsulating Security Payload) headers. The
profiles defined in [1] have been adopted for use by standardization
bodies such as 3GPP2.
While the performance of profiles defined in [1] has been found to
be robust and efficient, one key element missing from these profiles
is the ability to efficiently handle out-of-order delivery of packets
over the RoHC channel. In systems such as HRPD Rev A (standardized by
3GPP2), packets may arrive out-of-order on the air interface due to
the use of Automatic Retransmission Request (ARQ) techniques such as
Hybrid ARQ (H-ARQ) and/or handoffs. It is imperative for 3GPP2
Kapoor, et. al. Expires January 14, 2007 [Page 2]
Internet-Draft RoHC Profiles with Reordering July 2006
systems that RoHC profiles be able to efficiently handle such out-of
-order delivery.
This document specifies updated versions of the following profiles
from [1], updated for efficient out-of-order support:
o RTP/UDP/IP : profile 0x0011 (updates profile 0x0001 [RFC3095])
o UDP/IP : profile 0x0012 (updates profile 0x0002 [RFC3095])
o ESP/IP : profile 0x0013 (updates profile 0x0003 [RFC3095])
These updated profiles inherit most of the functionality of the RFC
3095 profiles, with the exception that efficient support for out-of
-order delivery packets is added to these new profiles. The profiles
defined in this document do not provide mechanisms to alleviate the
issues with reordering in the R mode (as described in [2]), and as
such, these profiles SHOULD be used only in the U/O modes.
2. Terminology
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 RFC 2119 [3].
3. Tradeoff between Robustness to Losses and Reordering
As explained clearly in [2], there is an inherent trade-off between
the ability of RoHC to handle losses and the degree of out-of-order
packets. Figure 1 below shows the interpretation interval of RoHC,
divided into two parts: the right hand side for handling losses and
the left hand side for handling reordering. The size of the
interpretation interval is defined by the number of bits k, carried
for a particular field in the compressed packet.
<--- interpretation interval (size is 2^k) ---->
|------------------+---------------------------|
v_ref-p v_ref v_ref + (2^k-1) - p
<--- reordering --> <--------- losses --------->
The value of p defines the degree of reordering that can be
tolerated by the decompressor, while the rest of the interpretation
interval with size (2^k-1) - p defines the degree of tolerance to
Kapoor, et. al. Expires January 14, 2007 [Page 3]
Internet-Draft RoHC Profiles with Reordering July 2006
consecutive losses. Note that the value of p can be increased to
increase robustness to reordering at the cost of decreasing
robustness to consecutive losses, and vice versa.
If behavior of a particular link in terms of degree of reordering
and consecutive losses is known, it will be possible to configure
the appropriate value of p, which achieves the best performance.
This ability to configure the value of p will be of particular use
to 3GPP2 systems, where behavior of airlink is well characterized.
On the other hand, for the profiles defined in [1], the p value is
defined as follows in RFC 3095:
--- For the RTP profile, Section 5.7 defines the interpretation
interval for the RTP Sequence Number as:
p = 1 if bits(SN) <= 4
p = 2^(bits(SN)-5) - 1 if bits(SN) > 4
--- The UDP profile always uses p = -1 when interpreting the
Sequence Number (Section 5.11 of [1]).
--- The value of p for the ESP-based Sequence Number is defined in
a similar way as the RTP Sequence Number in the ROHC RTP profile
(Section 5.12 of [1]).
Thus, the profiles defined in [1] do not allow systems using RoHC
to configure the appropriate value of p based on their particular
requirements. This draft adds this functionality to the RoHC
profiles defined in this document.
4. Changes from RFC 3095 Profiles
In order to support a configurable p value, mechanisms to
communicate this value from compressor to decompressor need to be
defined. This section lists the changes to the new profiles for
support of such functionality. It should be noted that the
configured p value only defines the p values for Sequence Numbers
(i.e., RTP SN for the RTP profile, UDP SN for the UDP profile and
ESP SN for the ESP profile). All other fields such as RTP Timestamp
(RTP TS) and IP Identification (IP-ID) have the same definition of
p as in [1].
4.1 Change to IR packet
The IR packet for the new profiles defined in this document has the
same properties as that defined in [1]. The structure of the IR
packet for the new profiles is shown below:
Kapoor, et. al. Expires January 14, 2007 [Page 4]
Internet-Draft RoHC Profiles with Reordering July 2006
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
| Add-CID octet | if for small CIDs and CID != 0
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | D |
+---+---+---+---+---+---+---+---+
| |
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
| |
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 | RR | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
| Static chain | variable length
| |
+---+---+---+---+---+---+---+---+
| |
| Dynamic chain | present if D = 1, variable length
| |
- - - - - - - - - - - - - - - -
| |
| Payload | variable length
| |
RR: Reorder Ratio. This defines the part of the interpretation
interval that handles out-of-order packets. RR can take the
following values, with p taking the corresponding values:
0: REORDERING_NONE; p = -1
1: REORDERING_QUARTER; p = ((2^k) / 4) - 1
2: REORDERING_HALF; p = ((2^k) / 2) - 1
3: REORDERING_THREEQUARTERS; p = ((2^k) * 3) / 4) - 1
where 2^k is the size of the interpretation interval.
Note that the calculation of the CRC now also includes the RR bits
(the CRC is calculated in the same way as in [1]). Also, note that
the only difference between this IR packet and that defined in [1]
is the addition of the octet carrying the RR field.
The profile field can take the value of any of the 3 new profiles
defined in this document (the profile field is represented in an IR
packet as defined in Section 5.2.3 of [1]).
Kapoor, et. al. Expires January 14, 2007 [Page 5]
Internet-Draft RoHC Profiles with Reordering July 2006
5. Recommendations for Use of Profiles
This section provides recommendations for use of the profiles
defined in this document. These recommendations follow from the
discussion presented in [2].
5.1 RoHC Segmentation
The segmentation functionality, defined in Section 5.2.5 of [1],
relies on in-order delivery of segments. Thus, RoHC segmentation
should not be used with the profiles defined in this document.
5.2 List Compression
Reference-based list compression, as defined in Section 5.8 of [1],
may suffer from reordering vulnerabilities (as described in [2]).
It is thus, recommended, that for the profiles defined in this
document, only the "Generic Scheme" for list encoding be used.
5.3 R-Mode
[2] points out a number of issues related to packets being
reordered in the R-mode. For example, if updating packets were
reordered, this can cause the compressor and decompressor to lose
synchronization with each other, referred to as the "missing
reference" problem. Also, if non-updating and updating packets were
reordered, this can cause packets to be erroneously decompressed.
Moreover, in this case, since decompression of R-0 and R-1* packets
cannot be verified due to lack of a CRC, erroneous packets may be
forwarded to the upper layers.
The profiles defined in this document do not provide for any
mechanism to alleviate such issues with reordering in the R-Mode.
It should be noted here that the intention when defining these
profiles is to operate them only in the U/O modes. Thus, these
profiles SHOULD be used only in the U/O modes.
6. Security Considerations
This document does not introduce additional security risks to [1].
Kapoor, et. al. Expires January 14, 2007 [Page 6]
Internet-Draft RoHC Profiles with Reordering July 2006
7. IANA Considerations
The ROHC profile identifiers 0x00XX <# Editor's Note: To be replaced
before publication #> have been reserved by the IANA for the profiles
defined in this document.
<# Editor's Note: To be removed before publication #>
The following is the suggested registration in the "RObust Header
Compression (ROHC) Profile Identifiers" name space for the profiles
defined in this document:
Profile Usage Document
0x0011 ROHC RTP-reordering RFCXXXX
0x0012 ROHC UDP-reordering RFCXXXX
0x0013 ROHC ESP-reordering RFCXXXX
8. Acknowledgements
The authors would like to thank the people who have contributed to
the RoHC specifications.
9. Normative References
[1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[2] Pelletier, G., Jonsson, L-E., and Sandlund, K., "RObust Header
Compression (ROHC): ROHC over Channels That Can Reorder
Packets", RFC 4224, June 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Kapoor, et. al. Expires January 14, 2007 [Page 7]
Internet-Draft RoHC Profiles with Reordering July 2006
Authors' Addresses
Rohit Kapoor
Qualcomm
5775, Morehouse Drive,
San Diego, USA
Phone: 1-858-845-1161
Email: rkapoor@qualcomm.com
Chokri Trabelsi
Lucent Technologies
67 Whippany Rd
Whippany NJ, USA
Phone: 1-973-386-2309
Email: ctrabelsi@lucent.com
Qinqing Zhang
Lucent Technologies
67 Whippany Rd
Whippany NJ, USA
Phone: 1-973-428-7835
Email: qinqing@lucent.com
Kapoor, et. al. Expires January 14, 2007 [Page 8]
Internet-Draft RoHC Profiles with Reordering July 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Kapoor, et. al. Expires January 14, 2007 [Page 9]| PAFTECH AB 2003-2026 | 2026-04-22 19:14:47 |