Robust Header Compression C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track February 2007
Expires: August 5, 2007
A ROHC Profile for CRTP (ROHC-CRTP)
draft-bormann-rohc-avt-crtp-profile-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 August 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document specifies a ROHC (Robust Header Compression) profile
for header compression of packets using the legacy header compression
schemes defined by IP compression (RFC 2507), CRTP (RFC 2508), and
ECRTP (RFC 3545). The profile, called ROHC-CRTP, enables the use of
these legacy header compression schemes in the context of a ROHC
channel, making use of the mechanisms offered by the ROHC framework.
$Id: draft-bormann-rohc-avt-crtp-profile.xml,v 1.5 2007/03/20
Bormann Expires August 5, 2007 [Page 1]
Internet-Draft ROHC-CRTP February 2007
23:20:59 cabo Exp $
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Profile Operation . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Creating Contexts . . . . . . . . . . . . . . . . . . . . . 3
2.2. Using Contexts . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Compressed Packet Formats . . . . . . . . . . . . . . . . . . . 5
4. Parameter Values . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Bormann Expires August 5, 2007 [Page 2]
Internet-Draft ROHC-CRTP February 2007
1. Introduction
Work on the original ROHC standard [RFC3095] was started to obtain a
higher-performance replacement for previous header compression
standards for voice over IP applications such as RFC 2508. ROHC was
defined as the combination of (1) a framework, now separately defined
in [I-D.ietf-rohc-rfc3095bis-framework], which specifies the
management of a ROHC channel for the transmission of multiple header
compressed flows of possible different characteristics, and (2) a
number of profiles, which specify the specific header compression
schemes in use.
Now that ROHC has sprouted more than a dozen profiles and variants of
profiles, it is the obvious framework to use when undertaking new
work on integrating header compression into an environment. However,
some of the header compression schemes used previous to ROHC are
still popular, and it would be beneficial to be able to transport
them on a ROHC channel together with its more modern siblings.
This specification defines how to transport flows compressed by IP
compression (RFC 2507), CRTP (RFC 2508), and/or ECRTP (RFC 3545) in a
ROHC channel. To this end, it defines a new ROHC profile, called the
legacy profile or ROHC-CRTP for short, as well as RFC 3241
negotiation suboptions to negotiate non-default parameters for the
compression schemes.
Note that, as the usage of TCP and TCP options has significantly
moved on since 1990, there is very little reason to continue using
RFC 1144 in a modern network when newer alternatives are available;
this legacy header compression scheme is therefore not supported by
this specification.
2. Profile Operation
This section gives an overview of the operation of ROHC-CRTP.
The ROHC-CRTP protocol operates by mapping legacy header compression
packet types into the ROHC framework. The actual protocol operation
of the legacy schemes is not affected, but the encoding of the first
few bytes of the legacy headers sometimes has to be adapted.
2.1. Creating Contexts
A ROHC-CRTP context is created using an IR (initialization/refresh)
packet, which contains a ROHC framework header followed by the ROHC-
CRTP packet type FULL_HEADER, modified as follows:
Bormann Expires August 5, 2007 [Page 3]
Internet-Draft ROHC-CRTP February 2007
If the x bit is set to 1, all bytes that would have carried CID bits
or been entirely set to 0 by section 5.3.1 in RFC2507 are elided. If
the x bit is set to 0, all these bytes are transmitted as zero.
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
: :
/ FULL-HEADER / Legacy FULL-HEADER Packet
: :
+---+---+---+---+---+---+---+---+
The profile ID is chosen based on the nature of the packet: If it is
a TCP packet (and will thus entertain COMPRESSED_TCP and
COMPRESSED_TCP_NODELTA headers), the profile ID is 0x0074; otherwise
(Non-TCP), the profile ID is 0x0075.
The 8-bit CRC foreseen by the ROHC framework for IR headers is
defined in this profile to only cover the framework header (the
minimum range as defined in section 5.3.1.1 of
[I-D.ietf-rohc-rfc3095bis-framework]). (Note that this means the CRC
does not protect the legacy full header; there is no change in the
protection of this header from the legacy operation.)
Legacy CIDs and ROHC CIDs are mapped to each other in an appropriate,
locally defined way. Note that the CID number used in the ROHC
framework is unique in the channel; the trick used by RFC2507 for
separating a TCP and a non-TCP number space does not apply in ROHC.
(Where an existing implementation cannot easily be changed, legacy
TCP CIDs n can be translated into ROHC CIDs 2n, and legacy UDP CIDs n
can be translated into ROHC CIDs 2n+1 for CIDs allocated by this
implementation.)
2.2. Using Contexts
ROHC-CRTP packets with headers whose names start with COMPRESSED are
sent with profile-specific CO headers, as detailed in Section 3.
Bormann Expires August 5, 2007 [Page 4]
Internet-Draft ROHC-CRTP February 2007
2.3. Feedback
CONTEXT_STATE ROHC-CRTP packets are carried in ROHC feedback
messages. The CONTEXT_STATE packets are disassembled into the
context state items; each of the two-byte state items is sent within
a separate ROHC FEEDBACK-2 message, preceded by one byte composed of
the Acktype (ROHC framework) and the 6 LSBs of the type code (1 or 2
for the basic types; note that the difference between 1 and 2 is
insignificant here).
3. Compressed Packet Formats
This section defines the transmission of the various COMPRESSED_X
packet formats used in ROHC-CRTP.
The general prodecure for encapsulating a COMPRESSED_X packet in ROHC
is as follows:
1. Remove the packet type identifier and any leading legacy CID
bytes.
2. Use the profile-specific format as defined below.
3. Encapsulate the result into the framework standard structure,
filling the type-indication/body bytes by the bytes outlined
below.
0 x-1 x 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CIDs
+--- --- --- --- ---+--- --- ---+
| type indication | body | 1 octet (8-x bits of body)
+--- --- --- --- ---+--- --- ---+
: :
/ 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ body / variable length
+---+---+---+---+---+---+---+---+
COMPRESSED_TCP headers are only supported in profile 0x0074. If the
R-bit is zero, the header (as modified by removing CID bytes) is
encapsulated as is (the zero bit serves as the type indication
discriminator). If the R-bit is one, the discriminator byte
0b11000001 is prefixed to the CID-less legcay compressed packet.
COMPRESSED_TCP_NODELTA headers are only supported in profile 0x0074.
A discriminator byte 0b11000010 is prefixed to the CID-less legcay
compressed packet.
Bormann Expires August 5, 2007 [Page 5]
Internet-Draft ROHC-CRTP February 2007
COMPRESSED_NON_TCP headers are only supported in profile 0x0075. A
discriminator byte 0b1000100 is prefixed to the CID-less legcay
compressed packet.
COMPRESSED_RTP_8 and COMPRESSED_RTP_16 packets are only supported in
profile 0x0075; they look the same after removing the CIDs. If the
M-bit is zero, the header (as modified by removing CID bytes) is
encapsulated as is (the zero bit serves as the type indication
discriminator). If the M-bit is one, the discriminator byte
0b10000001 is prefixed to the CID-less legcay compressed packet.
COMPRESSED_UDP_8 and COMPRESSED_UDP_16 packets are only supported in
profile 0x0075; they look the same after removing the CIDs. A
discriminator byte 0b10000010 is prefixed to the CID-less legcay
compressed packet.
4. Parameter Values
RFC 3544 defines a number of parameter values that can be negotiated
for IP compression, CRTP, and ECRTP. These parameters can be
explicitly set by the CRTP suboption (see below), or they can be
derived from the respective ROHC parameters. In the absence of the
CRTP suboption, the following CRTP parameters are considered
negotiated by ROHC-CRTP:
1. TCP_SPACE(CRTP) = MAX_CID(ROHC)
2. NON_TCP_SPACE(CRTP) = MAX_CID(ROHC)
3. F_MAX_PERIOD(CRTP) = 256
4. F_MAX_TIME(CRTP) = 5
5. MAX_HEADER(CRTP) = MAX_HEADER(ROHC)
The ROHC CRTP suboption, if present, looks exactly like the RFC 3544
configuration option, except that the "Type" value (2, taken out of
the NCP configuration option space) is replaced by the value
__IANA__TYPE__ (taken out of the ROHC configuration suboption space).
5. Security considerations
The security considerations of [RFC3095] apply.
6. IANA Considerations
The ROHC profile identifiers 0x0074 and 0x0075 [# Editor's Note: To
be replaced before publication #] have been reserved by the IANA for
the profile defined in this document.
Bormann Expires August 5, 2007 [Page 6]
Internet-Draft ROHC-CRTP February 2007
The ROHC-CRTP suboption identifier __IANA__TYPE__ has been reserved
by the IANA for the configuration suboption defined in this document.
[# Editor's Note: rest of this section to be removed before
publication: #]
Two ROHC profile identifiers must be reserved by the IANA for the new
profile defined in this document. A suggested registration in the
"RObust Header Compression (ROHC) Profile Identifiers" name space
would then be:
Profile Usage Reference
0x0074 ROHC CRTP (TCP) [RFC XXXX (this)]
0x0075 ROHC CRTP (non-TCP) [RFC XXXX (this)]
Author's note: This suggestion must be updated before sending to
IANA.
The suggested value for the ROHC-CRTP suboption identifier
__IANA__TYPE__ is 2, as this would minimize the effort of translating
a legacy configuration option into a ROHC configuration suboption.
7. Contributors
The author would like to thank Ghyslain Pelletier, who opposed
defining this profile from day 1 and in the ensuing protracted
discussions helped the author sharpen the requirements for this
profile.
8. Acknowledgements
This document was prompted by the work on HCoIPsec by Emre Ertekin,
Chris Christou, and others.
The suggested profile numbers 0x0074 and 0x0075 have been inspired by
the nostalgic song "'74 - '75" by The Connells.
9. References
9.1. Normative References
[I-D.ietf-rohc-rfc3095bis-framework]
Jonsson, L., "The RObust Header Compression (ROHC)
Framework", draft-ietf-rohc-rfc3095bis-framework-01 (work
in progress), July 2006.
Bormann Expires August 5, 2007 [Page 7]
Internet-Draft ROHC-CRTP February 2007
9.2. Informative References
[RFC3095] 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.
Author's Address
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28334
Germany
Phone: +49 421 218 7024
Fax: +49 421 218 7000
Email: cabo@tzi.org
Bormann Expires August 5, 2007 [Page 8]
Internet-Draft ROHC-CRTP February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bormann Expires August 5, 2007 [Page 9]