< draft-ietf-rohc-rfc4995bis-02.txt   draft-ietf-rohc-rfc4995bis-03.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: June 10, 2010 December 7, 2009 Expires: July 17, 2010 January 13, 2010
The RObust Header Compression (ROHC) Framework The RObust Header Compression (ROHC) Framework
draft-ietf-rohc-rfc4995bis-02 draft-ietf-rohc-rfc4995bis-03
Abstract Abstract
The Robust Header Compression (ROHC) protocol provides an efficient, The Robust Header Compression (ROHC) protocol provides an efficient,
flexible, and future-proof header compression concept. It is flexible, and future-proof header compression concept. It is
designed to operate efficiently and robustly over various link designed to operate efficiently and robustly over various link
technologies with different characteristics. technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was The ROHC framework, along with a set of compression profiles, was
initially defined in RFC 3095. To improve and simplify the ROHC initially defined in RFC 3095. To improve and simplify the ROHC
skipping to change at page 1, line 33 skipping to change at page 1, line 33
definition of the framework does not modify or update the definition definition of the framework does not modify or update the definition
of the framework specified by RFC 3095. of the framework specified by RFC 3095.
This specification obsoletes RFC 4995. It fixes one interoperability This specification obsoletes RFC 4995. It fixes one interoperability
issue that was erroneously introduced in RFC 4995, and adds some issue that was erroneously introduced in RFC 4995, and adds some
minor clarifications. 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.
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
than English.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. 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."
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 June 10, 2010. This Internet-Draft will expire on July 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. ROHC Terminology . . . . . . . . . . . . . . . . . . . . . 5 2.2. ROHC Terminology . . . . . . . . . . . . . . . . . . . . . 5
3. Background (Informative) . . . . . . . . . . . . . . . . . . . 8 3. Background (Informative) . . . . . . . . . . . . . . . . . . . 8
3.1. Header Compression Fundamentals . . . . . . . . . . . . . 8 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
skipping to change at page 36, line 29 skipping to change at page 36, line 29
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
8 least significant bits of the profile identifier have a special 8 least significant bits of the profile identifier have a special
significance: Two profile identifiers with identical 8 LSBs should be significance: Two profile identifiers with identical 8 LSBs should be
assigned only if the higher-numbered one is intended to supersede the assigned only if the higher-numbered one is intended to supersede the
lower-numbered one. To highlight this relationship, profile lower-numbered one. To highlight this relationship, profile
identifiers should be given in hexadecimal (as in 0x1234, which would identifiers should be given in hexadecimal (as in 0x1234, which would
for example supersede 0x0A34). for example supersede 0x0A34).
Following the policies outlined in [RFC2434], the IANA policy for Following the policies outlined in [RFC5226], the IANA policy for
assigning new values for the profile identifier shall be assigning new values for the profile identifier shall be
Specification Required: values and their meanings must be documented Specification Required: values and their meanings must be documented
in an RFC or in some other permanent and readily available reference, in an RFC or in some other permanent and readily available reference,
in sufficient detail that interoperability between independent in sufficient detail that interoperability between independent
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.
skipping to change at page 38, line 32 skipping to change at page 38, line 32
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed
serial links", RFC 1144, February 1990. serial links", RFC 1144, February 1990.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994. July 1994.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999. Compression", RFC 2507, February 1999.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
February 1999. February 1999.
skipping to change at page 39, line 43 skipping to change at page 39, line 40
Header Compression (ROHC) Framework", RFC 4995, July 2007. Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, [RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West,
"RObust Header Compression (ROHC): A Profile for TCP/IP "RObust Header Compression (ROHC): A Profile for TCP/IP
(ROHC-TCP)", RFC 4996, July 2007. (ROHC-TCP)", RFC 4996, July 2007.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
UDP-Lite", RFC 5225, April 2008. UDP-Lite", RFC 5225, April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[ROHC-ids] [ROHC-ids]
IANA Registry, "RObust Header Compression (ROHC) Profile IANA Registry, "RObust Header Compression (ROHC) Profile
Identifiers", 2001, Identifiers", 2001,
<http://www.iana.org/assignments/rohc-pro-ids>. <http://www.iana.org/assignments/rohc-pro-ids>.
Appendix A. CRC Algorithm Appendix A. CRC Algorithm
#!/usr/bin/perl -w #!/usr/bin/perl -w
use strict; use strict;
#================================= #=================================
# #
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
# #
# This little demo shows the four types of CRC in use in RFC 3095, # This little demo shows the four types of CRC in use in RFC 3095,
# the specification for robust header compression. Type your data in # the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D. # hexadecimal form and then press Control+D.
# #
#--------------------------------- #---------------------------------
 End of changes. 10 change blocks. 
13 lines changed or deleted 23 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/