< draft-ietf-rohc-rfc3242bis-00.txt   draft-ietf-rohc-rfc3242bis-01.txt >
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT G. Pelletier INTERNET-DRAFT G. Pelletier
Expires: November 2005 K. Sandlund Expires: March 2006 K. Sandlund
Ericsson Ericsson
May 20, 2005 September 9, 2005
RObust Header Compression (ROHC): RObust Header Compression (ROHC):
A Link-Layer Assisted Profile for IP/UDP/RTP A Link-Layer Assisted Profile for IP/UDP/RTP
<draft-ietf-rohc-rfc3242bis-00.txt> <draft-ietf-rohc-rfc3242bis-01.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 BCP 79. 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
skipping to change at page 2, line 8 skipping to change at page 2, line 8
during optimal operation. The profile is built as an extension to during optimal operation. The profile is built as an extension to
the ROHC RTP profile. It defines additional mechanisms needed in the ROHC RTP profile. It defines additional mechanisms needed in
ROHC, states requirements on the assisting layer to guarantee ROHC, states requirements on the assisting layer to guarantee
transparency, and specifies general logic for compression and transparency, and specifies general logic for compression and
decompression making use of this header-free packet. This document decompression making use of this header-free packet. This document
is a replacement for RFC 3242, which it obsoletes. is a replacement for RFC 3242, which it obsoletes.
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction.....................................................2
2. Terminology......................................................4 1.1. Differences from RFC 3242...................................4
3. Overview of the Link-Layer Assisted Profile......................5 2. Terminology......................................................5
3. Overview of the Link-Layer Assisted Profile......................6
3.1. Providing Packet Type Identification........................6 3.1. Providing Packet Type Identification........................6
3.2. Replacing the Sequence Number...............................6 3.2. Replacing the Sequence Number...............................7
3.3. CRC Replacement.............................................7 3.3. CRC Replacement.............................................7
3.4. Applicability of This Profile...............................7 3.4. Applicability of This Profile...............................8
4. Additions and Exceptions Compared to ROHC RTP....................8 4. Additions and Exceptions Compared to ROHC RTP....................8
4.1. Additional Packet Types.....................................8 4.1. Additional Packet Types.....................................8
4.1.1. No-Header Packet (NHP).................................8 4.1.1. No-Header Packet (NHP).................................8
4.1.2. Context Synchronization Packet (CSP)...................8 4.1.2. Context Synchronization Packet (CSP)...................9
4.1.3. Context Check Packet (CCP)............................10 4.1.3. Context Check Packet (CCP)............................10
4.2. Interfaces Towards the Assisting Layer.....................11 4.2. Interfaces Towards the Assisting Layer.....................11
4.2.1. Interface, Compressor to Assisting Layer..............12 4.2.1. Interface, Compressor to Assisting Layer..............12
4.2.2. Interface, Assisting Layer to Decompressor............12 4.2.2. Interface, Assisting Layer to Decompressor............13
4.3. Optimistic Approach Agreement..............................13 4.3. Optimistic Approach Agreement..............................13
4.4. Fast Context Initialization, IR Redefinition...............13 4.4. Fast Context Initialization, IR Redefinition...............14
4.5. Feedback Option, CV-REQUEST................................14 4.5. Feedback Option, CV-REQUEST................................14
4.6. Periodic Context Verification..............................15 4.6. Periodic Context Verification..............................15
4.7. Use of Context Identifier..................................15 4.7. Use of Context Identifier..................................15
5. Implementation Issues...........................................15 5. Implementation Issues...........................................15
5.1. Implementation Parameters and Signals......................15 5.1. Implementation Parameters and Signals......................15
5.1.1. Implementation Parameters at the Compressor...........16 5.1.1. Implementation Parameters at the Compressor...........16
5.1.2. Implementation Parameters at the Decompressor.........17 5.1.2. Implementation Parameters at the Decompressor.........17
5.2. Implementation over Various Link Technologies..............18 5.2. Implementation over Various Link Technologies..............18
6. IANA Considerations.............................................18 6. IANA Considerations.............................................18
7. Security Consideration..........................................18 7. Security Consideration..........................................18
8. Acknowledgments.................................................18 8. Acknowledgments.................................................18
9. References......................................................19 9. References......................................................19
9.1. Normative References.......................................19 9.1. Normative References.......................................19
9.2. Informative References.....................................19 9.2. Informative References.....................................19
10. Authors' Addresses.............................................20
1. Introduction 1. Introduction
Header compression is a technique used to compress and transparently Header compression is a technique used to compress and transparently
decompress the header information of a packet on a per-hop basis, decompress the header information of a packet on a per-hop basis,
utilizing redundancy within individual packets and between utilizing redundancy within individual packets and between
consecutive packets within a packet stream. Over the years, several consecutive packets within a packet stream. Over the years, several
protocols [VJHC, IPHC] have been developed to compress the network protocols [VJHC, IPHC] have been developed to compress the network
and transport protocol headers [IPv4, IPv6, UDP, TCP], and these and transport protocol headers [IPv4, IPv6, UDP, TCP], and these
schemes have been successful in improving efficiency over many wired schemes have been successful in improving efficiency over many wired
skipping to change at page 3, line 10 skipping to change at page 3, line 10
In addition to IP, UDP, and TCP compression, an additional In addition to IP, UDP, and TCP compression, an additional
compression scheme called Compressed RTP [CRTP] has been developed to compression scheme called Compressed RTP [CRTP] has been developed to
further improve compression efficiency for the case of real-time further improve compression efficiency for the case of real-time
traffic using the Real-Time Transport Protocol [RTP]. traffic using the Real-Time Transport Protocol [RTP].
The schemes mentioned above have all been designed taking into The schemes mentioned above have all been designed taking into
account normal assumptions about link characteristics, which account normal assumptions about link characteristics, which
traditionally have been based on wired links only. However, with an traditionally have been based on wired links only. However, with an
increasing number of wireless links in the Internet paths, these increasing number of wireless links in the Internet paths, these
assumptions are no longer generally valid. In wireless environments, assumptions are no longer generally valid. In wireless environments,
specially wide coverage cellular environments, relatively high error especially wide coverage cellular environments, relatively high error
rates are tolerated in order to allow efficient usage of the radio rates are tolerated in order to allow efficient usage of the radio
resources. For real-time traffic, which is more sensitive to delays resources. For real-time traffic, which is more sensitive to delays
than to errors, such operating conditions will be norm over, for than to errors, such operating conditions will be norm over, for
example, 3rd generation cellular links, and header compression must example, 3rd generation cellular links, and header compression must
therefore tolerate packet loss. However, with the previously therefore tolerate packet loss. However, with the previously
mentioned schemes, especially for real-time traffic compressed by mentioned schemes, especially for real-time traffic compressed by
CRTP, high error rates have been shown to significantly degrade CRTP, high error rates have been shown to significantly degrade
header compression performance [CRTPC]. This problem was the driving header compression performance [CRTPC]. This problem was the driving
force behind the creation of the RObust Header Compression (ROHC) WG force behind the creation of the RObust Header Compression (ROHC) WG
in the IETF. in the IETF.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
the spectrum efficiency over these links will thus be low compared to the spectrum efficiency over these links will thus be low compared to
existing circuit switched solutions. To achieve high spectrum existing circuit switched solutions. To achieve high spectrum
efficiency overall with any application, more flexible air interfaces efficiency overall with any application, more flexible air interfaces
must be deployed, and then the ROHC RTP scheme will perform must be deployed, and then the ROHC RTP scheme will perform
excellently, as shown for WCDMA [MOMUC01]. However, for deployment excellently, as shown for WCDMA [MOMUC01]. However, for deployment
reasons, it is however important to also provide a suitable header reasons, it is however important to also provide a suitable header
compression strategy for already existing vocoders and air compression strategy for already existing vocoders and air
interfaces, such as for GERAN and for CDMA2000, with minimal effects interfaces, such as for GERAN and for CDMA2000, with minimal effects
on spectral efficiency. on spectral efficiency.
This document defines a new link-layer assisted ROHC RTP profile This document describes a link-layer assisted ROHC RTP profile,
extending ROHC RTP (profile 0x0001) [ROHC], compliant with the ROHC originally defined by [LLA], extending ROHC RTP (profile 0x0001)
0-byte requirements [0B-REQ]. The purpose of this new profile is to [ROHC], and compliant with the ROHC 0-byte requirements [0B-REQ].
provide a header-free packet format that, for a certain application The purpose of this profile is to provide a header-free packet format
behavior, can replace a majority of the 1-octet header ROHC RTP that, for a certain application behavior, can replace a majority of
packets during normal U/O-mode operation, while still being fully the 1-octet header ROHC RTP packets during normal U/O-mode operation,
transparent and complying with all the requirements of ROHC RTP while still being fully transparent and complying with all the
[RTP-REQ]. For other applications, compression will be carried out requirements of ROHC RTP [RTP-REQ]. For other applications,
as with normal ROHC RTP. compression will be carried out as with normal ROHC RTP.
To completely eliminate the compressed header, all functionality To completely eliminate the compressed header, all functionality
normally provided by the 1-octet header has to be provided by other normally provided by the 1-octet header has to be provided by other
means, typically by utilizing functionality provided by the lower means, typically by utilizing functionality provided by the lower
layers and sacrificing efficiency for less frequently occurring layers and sacrificing efficiency for less frequently occurring
larger compressed headers. The latter is not a contradiction since larger compressed headers. The latter is not a contradiction since
the argument for eliminating the last octet for most packets is not the argument for eliminating the last octet for most packets is not
overall efficiency in general. It is important to remember that the overall efficiency in general. It is important to remember that the
purpose of this profile is to provide efficient matching of existing purpose of this profile is to provide efficient matching of existing
applications to existing link technologies, not efficiency in applications to existing link technologies, not efficiency in
skipping to change at page 4, line 45 skipping to change at page 4, line 45
must be taken to guarantee that all the functionality needed is must be taken to guarantee that all the functionality needed is
provided by ROHC and the lower layers together. Therefore, provided by ROHC and the lower layers together. Therefore,
additional documents should specify how to incorporate this profile additional documents should specify how to incorporate this profile
on top of various link technologies. on top of various link technologies.
The profile defined by this document was originally specified by RFC The profile defined by this document was originally specified by RFC
3242 [LLA], but to address one technical flaw and clarify one 3242 [LLA], but to address one technical flaw and clarify one
implementation issue, this document has been issued to replace RFC implementation issue, this document has been issued to replace RFC
3242, which becomes obsolete. 3242, which becomes obsolete.
1.1. Differences from RFC 3242
This section briefly summarizes the differences in this document from
RFC 3242. Acronyms and terminology can be found in section 2.
The format of the CSP packet, as defined in [LLA], was identified as
non-interoperable when carrying a RHP header with a 3-bit or 7-bit
CRC. This problem occurs due to the payload having been dropped by
the compressor, while the decompressor is supposed to use the payload
length to infer certain fields in the uncompressed header. These
fields are the IPv4 total length, the IPv6 payload length, the UDP
length and the IPv4 header checksum field (all INFERRED fields in
[ROHC]). To correct this flaw, the CSP packet must carry information
about the payload length of the RHP packet. Therefore the length of
the RTP payload has been included in the CSP packet.
This document also clarifies an unclear referencing in RFC 3242,
where section 4.1.3 of [LLA] states that upon CRC failure, the
actions of [ROHC] section 5.3.2.2.3 MUST be taken. That section
specifies that detection of SN wraparound and local repair must be
performed, while neither of these steps apply when the failing packet
is a CCP. Therefore, upon CRC failure, actions to be taken are the
ones specified in section 5.3.2.2.3, but steps a-d only.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
CCP Context Check Packet CCP Context Check Packet
CRC Cyclic Redundancy Check CRC Cyclic Redundancy Check
CSP Context Synchronization Packet CSP Context Synchronization Packet
LLA Link Layer Assisted ROHC RTP profile LLA Link Layer Assisted ROHC RTP profile
skipping to change at page 5, line 30 skipping to change at page 5, line 54
compressor, operating with the LLA profile, and its associated compressor, operating with the LLA profile, and its associated
assisting layer. assisting layer.
Lower layers Lower layers
"Lower layers" in this document refers to entities located below "Lower layers" in this document refers to entities located below
ROHC in the protocol stack, including the assisting layer. ROHC in the protocol stack, including the assisting layer.
ROHC RTP ROHC RTP
"ROHC RTP" in this document refers to the IP/UDP/RTP profile "ROHC RTP" refers to the IP/UDP/RTP profile as defined in [ROHC].
(profile 0x0001) as defined in [ROHC].
3. Overview of the Link-Layer Assisted Profile 3. Overview of the Link-Layer Assisted Profile
The ROHC IP/UDP/RTP profile defined in this document, profile 0x0005 The ROHC IP/UDP/RTP profile defined in [LLA] and updated by this
(hex), is designed to be used over channels that have been optimized document, profile 0x0005 (hex), is designed to be used over channels
for specific payload sizes and therefore cannot efficiently that have been optimized for specific payload sizes and therefore
accommodate header information when transmitted together with cannot efficiently accommodate header information when transmitted
payloads corresponding to these optimal sizes. together with payloads corresponding to these optimal sizes.
The LLA profile extends, and thus also inherits all functionality The LLA profile extends, and thus also inherits all functionality
from, the ROCH RTP profile by defining some additional functionality from, the ROCH RTP profile by defining some additional functionality
and an interface from the ROHC component towards an assisting lower and an interface from the ROHC component towards an assisting lower
layer. layer.
+---------------------------------------+ +---------------------------------------+
| | | |
The LLA | ROHC RTP, | The LLA | ROHC RTP, |
profile | Profile #1 +-----------------+ profile | Profile #1 +-----------------+
skipping to change at page 20, line 5 skipping to change at page 20, line 5
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, February Headers for Low-Speed Serial Links", RFC 2508, February
1999. 1999.
[CRTPC] Degermark, M., Hannu, H., Jonsson, L-E. and K. Svanbro, [CRTPC] Degermark, M., Hannu, H., Jonsson, L-E. and K. Svanbro,
"Evaluation of CRTP Performance over Cellular Radio "Evaluation of CRTP Performance over Cellular Radio
Networks", IEEE Personal Communications Magazine, Volume Networks", IEEE Personal Communications Magazine, Volume
7, number 4, pp. 20-25, August 2000. 7, number 4, pp. 20-25, August 2000.
10. Authors' Addresses Authors' Addresses
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
Ghyslain Pelletier Ghyslain Pelletier
skipping to change at page 21, line 45 skipping to change at page 21, line 45
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 November 20, 2005. This Internet-Draft expires March 9, 2006.
 End of changes. 17 change blocks. 
29 lines changed or deleted 52 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/