draft-ietf-rohc-rfc4995bis-01.txt   draft-ietf-rohc-rfc4995bis-02.txt 
Network Working Group K. Sandlund Network Working Group K. Sandlund
Internet-Draft G. Pelletier Internet-Draft G. Pelletier
Obsoletes: 4995 (if approved) Ericsson Obsoletes: 4995 (if approved) Ericsson
Intended status: Standards Track L-E. Jonsson Intended status: Standards Track L-E. Jonsson
Expires: January 14, 2010 July 13, 2009 Expires: June 10, 2010 December 7, 2009
The RObust Header Compression (ROHC) Framework The RObust Header Compression (ROHC) Framework
draft-ietf-rohc-rfc4995bis-01 draft-ietf-rohc-rfc4995bis-02
Abstract
The Robust Header Compression (ROHC) protocol provides an efficient,
flexible, and future-proof header compression concept. It is
designed to operate efficiently and robustly over various link
technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was
initially defined in RFC 3095. To improve and simplify the ROHC
specifications, this document explicitly defines the ROHC framework
and the profile for uncompressed separately. More specifically, the
definition of the framework does not modify or update the definition
of the framework specified by RFC 3095.
This specification obsoletes RFC 4995. It fixes one interoperability
issue that was erroneously introduced in RFC 4995, and adds some
minor clarifications.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other for publication as an RFC or to translate it into languages other
than English. than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 36 skipping to change at page 2, line 8
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on June 10, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Robust Header Compression (ROHC) protocol provides an efficient, described in the BSD License.
flexible, and future-proof header compression concept. It is
designed to operate efficiently and robustly over various link
technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was
initially defined in RFC 3095. To improve and simplify the ROHC
specifications, this document explicitly defines the ROHC framework
and the profile for uncompressed separately. More specifically, the
definition of the framework does not modify or update the definition
of the framework specified by RFC 3095.
This specification obsoletes RFC 4995. It fixes one interoperability
issue that was erroneously introduced in RFC 4995, and adds some
minor clarifications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. ROHC Terminology . . . . . . . . . . . . . . . . . . . . . 6 2.2. ROHC Terminology . . . . . . . . . . . . . . . . . . . . . 5
3. Background (Informative) . . . . . . . . . . . . . . . . . . . 9 3. Background (Informative) . . . . . . . . . . . . . . . . . . . 8
3.1. Header Compression Fundamentals . . . . . . . . . . . . . 9 3.1. Header Compression Fundamentals . . . . . . . . . . . . . 8
3.2. A Short History of Header Compression . . . . . . . . . . 9 3.2. A Short History of Header Compression . . . . . . . . . . 9
4. Overview of Robust Header Compression (ROHC) (Informative) . . 10 4. Overview of Robust Header Compression (ROHC) (Informative) . . 10
4.1. General Principles . . . . . . . . . . . . . . . . . . . . 10 4.1. General Principles . . . . . . . . . . . . . . . . . . . . 10
4.2. Compression Efficiency, Robustness, and Transparency . . . 12 4.2. Compression Efficiency, Robustness, and Transparency . . . 11
4.3. Developing the ROHC Protocol . . . . . . . . . . . . . . . 12 4.3. Developing the ROHC Protocol . . . . . . . . . . . . . . . 12
4.4. Operational Characteristics of the ROHC Channel . . . . . 13 4.4. Operational Characteristics of the ROHC Channel . . . . . 13
4.5. Compression and Master Sequence Number (MSN) . . . . . . . 15 4.5. Compression and Master Sequence Number (MSN) . . . . . . . 14
4.6. Static and Dynamic Parts of a Context . . . . . . . . . . 15 4.6. Static and Dynamic Parts of a Context . . . . . . . . . . 15
5. The ROHC Framework (Normative) . . . . . . . . . . . . . . . . 16 5. The ROHC Framework (Normative) . . . . . . . . . . . . . . . . 15
5.1. The ROHC Channel . . . . . . . . . . . . . . . . . . . . . 16 5.1. The ROHC Channel . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. Contexts and Context Identifiers . . . . . . . . . . . 16 5.1.1. Contexts and Context Identifiers . . . . . . . . . . . 16
5.1.2. Per-Channel Parameters . . . . . . . . . . . . . . . . 17 5.1.2. Per-Channel Parameters . . . . . . . . . . . . . . . . 16
5.1.3. Persistence of Decompressor Contexts . . . . . . . . . 18 5.1.3. Persistence of Decompressor Contexts . . . . . . . . . 17
5.2. ROHC Packets and Packet Types . . . . . . . . . . . . . . 18 5.2. ROHC Packets and Packet Types . . . . . . . . . . . . . . 17
5.2.1. General Format of ROHC Packets . . . . . . . . . . . . 18 5.2.1. General Format of ROHC Packets . . . . . . . . . . . . 18
5.2.1.1. Format of the Padding Octet . . . . . . . . . . . 19 5.2.1.1. Format of the Padding Octet . . . . . . . . . . . 19
5.2.1.2. Format of the Add-CID Octet . . . . . . . . . . . 19 5.2.1.2. Format of the Add-CID Octet . . . . . . . . . . . 19
5.2.1.3. General Format of Header . . . . . . . . . . . . . 20 5.2.1.3. General Format of Header . . . . . . . . . . . . . 19
5.2.2. Initialization and Refresh (IR) Packet Types . . . . . 21 5.2.2. Initialization and Refresh (IR) Packet Types . . . . . 20
5.2.2.1. ROHC IR Header Format . . . . . . . . . . . . . . 21 5.2.2.1. ROHC IR Header Format . . . . . . . . . . . . . . 20
5.2.2.2. ROHC IR-DYN Header Format . . . . . . . . . . . . 22 5.2.2.2. ROHC IR-DYN Header Format . . . . . . . . . . . . 21
5.2.3. ROHC Initial Decompressor Processing . . . . . . . . . 22 5.2.3. ROHC Initial Decompressor Processing . . . . . . . . . 22
5.2.4. ROHC Feedback . . . . . . . . . . . . . . . . . . . . 24 5.2.4. ROHC Feedback . . . . . . . . . . . . . . . . . . . . 23
5.2.4.1. ROHC Feedback Format . . . . . . . . . . . . . . . 25 5.2.4.1. ROHC Feedback Format . . . . . . . . . . . . . . . 24
5.2.5. ROHC Segmentation . . . . . . . . . . . . . . . . . . 26 5.2.5. ROHC Segmentation . . . . . . . . . . . . . . . . . . 26
5.2.5.1. Segmentation Usage Considerations . . . . . . . . 26 5.2.5.1. Segmentation Usage Considerations . . . . . . . . 26
5.2.5.2. Segmentation Protocol . . . . . . . . . . . . . . 27 5.2.5.2. Segmentation Protocol . . . . . . . . . . . . . . 27
5.3. General Encoding Methods . . . . . . . . . . . . . . . . . 28 5.3. General Encoding Methods . . . . . . . . . . . . . . . . . 28
5.3.1. Header Compression CRCs, Coverage and Polynomials . . 28 5.3.1. Header Compression CRCs, Coverage and Polynomials . . 28
5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers . . . . . . . 28 5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers . . . . . . . 28
5.3.1.2. 3-bit CRC in Compressed Headers . . . . . . . . . 29 5.3.1.2. 3-bit CRC in Compressed Headers . . . . . . . . . 28
5.3.1.3. 7-bit CRC in Compressed Headers . . . . . . . . . 29 5.3.1.3. 7-bit CRC in Compressed Headers . . . . . . . . . 29
5.3.1.4. 32-bit Segmentation CRC . . . . . . . . . . . . . 30 5.3.1.4. 32-bit Segmentation CRC . . . . . . . . . . . . . 29
5.3.2. Self-Describing Variable-Length Values . . . . . . . . 30 5.3.2. Self-Describing Variable-Length Values . . . . . . . . 30
5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) . . 31 5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) . . 30
5.4.1. IR Packet . . . . . . . . . . . . . . . . . . . . . . 31 5.4.1. IR Packet . . . . . . . . . . . . . . . . . . . . . . 31
5.4.2. Normal Packet . . . . . . . . . . . . . . . . . . . . 32 5.4.2. Normal Packet . . . . . . . . . . . . . . . . . . . . 31
5.4.3. Context Initialization . . . . . . . . . . . . . . . . 32 5.4.3. Context Initialization . . . . . . . . . . . . . . . . 32
5.4.4. Decompressor Operation . . . . . . . . . . . . . . . . 33 5.4.4. Decompressor Operation . . . . . . . . . . . . . . . . 32
5.4.5. Feedback . . . . . . . . . . . . . . . . . . . . . . . 33 5.4.5. Feedback . . . . . . . . . . . . . . . . . . . . . . . 33
6. Overview of a ROHC Profile (Informative) . . . . . . . . . . . 33 6. Overview of a ROHC Profile (Informative) . . . . . . . . . . . 33
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. CRC Algorithm . . . . . . . . . . . . . . . . . . . . 39 Appendix A. CRC Algorithm . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
For many types of networks, reducing the deployment and operational For many types of networks, reducing the deployment and operational
costs by improving the usage of the bandwidth resources is of vital costs by improving the usage of the bandwidth resources is of vital
importance. Header compression over a link is possible because some importance. Header compression over a link is possible because some
of the information carried within the header of a packet becomes of the information carried within the header of a packet becomes
compressible between packets belonging to the same flow. compressible between packets belonging to the same flow.
skipping to change at page 6, line 15 skipping to change at page 6, line 15
specification, the framework and the profiles' parts have been split specification, the framework and the profiles' parts have been split
into separate documents. This document explicitly defines the ROHC into separate documents. This document explicitly defines the ROHC
framework, but it does not modify or update the definition of the framework, but it does not modify or update the definition of the
framework specified by RFC 3095; both documents can be used framework specified by RFC 3095; both documents can be used
independently of each other. This also implies that implementations independently of each other. This also implies that implementations
based on either definition will be compatible and interoperable with based on either definition will be compatible and interoperable with
each other. However, it is the intent to let this specification each other. However, it is the intent to let this specification
replace RFC 3095 as the base specification for all profiles defined replace RFC 3095 as the base specification for all profiles defined
in the future. in the future.
This document fixes one interoperability issue that was erroneously
introduced in RFC 4995. The fix for this issue is located in
Section 5.2.4.1 and clarifies the interpretation of the Size field in
ROHC feedback.
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2.1. Acronyms 2.1. Acronyms
This section lists most acronyms used for reference. This section lists most acronyms used for reference.
skipping to change at page 35, line 20 skipping to change at page 36, line 6
including feedback logic if used. including feedback logic if used.
7. Acknowledgments 7. Acknowledgments
The authors would like to acknowledge all who have contributed to The authors would like to acknowledge all who have contributed to
previous ROHC work, and especially to the authors of RFC 3095 previous ROHC work, and especially to the authors of RFC 3095
[RFC3095], which is the technical basis for this document. Thanks [RFC3095], which is the technical basis for this document. Thanks
also to the various individuals who contributed to the RFC 3095 also to the various individuals who contributed to the RFC 3095
corrections and clarifications document [RFC4815], from which corrections and clarifications document [RFC4815], from which
technical contents, when applicable, have been incorporated into this technical contents, when applicable, have been incorporated into this
document. Committed WG document reviewers were Carl Knutsson and document. Committed WG document reviewers were Carl Knutsson, Biplab
Biplab Sarkar, who reviewed the document during working group last- Sarkar and Robert Stangarone, who reviewed the document during
call. Also thanks to Jani Juvan for discovering the error in the working group last-calls. Additional thanks to Bert Wijnen and Brian
feedback structure in [RFC4995] which made this document necessary. Carpenter for comments during IETF last-call. Also thanks to Jani
Juvan for discovering the error in the feedback structure in
[RFC4995] which made this document necessary.
8. IANA Considerations 8. IANA Considerations
An IANA registry for "RObust Header Compression (ROHC) Profile An IANA registry for "RObust Header Compression (ROHC) Profile
Identifiers" [ROHC-ids] was created by RFC 3095 [RFC3095]. The Identifiers" [ROHC-ids] was created by RFC 3095 [RFC3095]. The
assignment policy, as outlined by RFC 3095, is the following: assignment policy, as outlined by RFC 3095, is the following:
The ROHC profile identifier is a non-negative integer. In many The ROHC profile identifier is a non-negative integer. In many
negotiation protocols, it will be represented as a 16-bit value. Due negotiation protocols, it will be represented as a 16-bit value. Due
to the way the profile identifier is abbreviated in ROHC packets, the to the way the profile identifier is abbreviated in ROHC packets, the
skipping to change at page 36, line 9 skipping to change at page 37, line 7
implementations is possible. In the 8 LSBs, the range 0 to 127 is implementations is possible. In the 8 LSBs, the range 0 to 127 is
reserved for IETF standard-track specifications; the range 128 to 254 reserved for IETF standard-track specifications; the range 128 to 254
is available for other specifications that meet this requirement is available for other specifications that meet this requirement
(such as Informational RFCs). The LSB value 255 is reserved for (such as Informational RFCs). The LSB value 255 is reserved for
future extensibility of the present specification. future extensibility of the present specification.
The following profile identifiers have so far been allocated: The following profile identifiers have so far been allocated:
Profile Identifier Usage Reference Profile Identifier Usage Reference
------------------ ---------------------- --------- ------------------ ---------------------- ---------
0x0000 ROHC uncompressed RFC 4995 0x0000 ROHC uncompressed RFC XXXX [RFC-ed]
0x0001 ROHC RTP RFC 3095 0x0001 ROHC RTP RFC 3095
0x0002 ROHC UDP RFC 3095 0x0002 ROHC UDP RFC 3095
0x0003 ROHC ESP RFC 3095 0x0003 ROHC ESP RFC 3095
0x0004 ROHC IP RFC 3843 0x0004 ROHC IP RFC 3843
0x0005 ROHC LLA RFC 3242 0x0005 ROHC LLA RFC 3242
0x0105 ROHC LLA with R-mode RFC 3408 0x0105 ROHC LLA with R-mode RFC 3408
0x0006 ROHC TCP RFC 4996 0x0006 ROHC TCP RFC 4996
0x0007 ROHC RTP/UDP-Lite RFC 4019 0x0007 ROHC RTP/UDP-Lite RFC 4019
0x0008 ROHC UDP-Lite RFC 4019 0x0008 ROHC UDP-Lite RFC 4019
0x0101 ROHCv2 RTP RFC 5225 0x0101 ROHCv2 RTP RFC 5225
 End of changes. 21 change blocks. 
55 lines changed or deleted 66 lines changed or added

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