Network Working Group L-E. Jonsson Request for Comments: 4995 G. Pelletier Category: Standards Track K. Sandlund Ericsson July 2007 The RObust Header Compression (ROHC) Framework
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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.
Table of Contents
1. Introduction (3)
2. Terminology (4)
2.1. Acronyms (4)
2.2. ROHC Terminology (4)
3. Background (Informative) (7)
3.1. Header Compression Fundamentals (7)
3.2. A Short History of Header Compression (7)
4. Overview of Robust Header Compression (ROHC) (Informative) (8)
4.1. General Principles (8)
4.2. Compression Efficiency, Robustness, and Transparency (10)
4.3. Developing the ROHC Protocol (10)
Jonsson, et al. Standards Track [Page 1]
4.4. Operational Characteristics of the ROHC Channel (11)
4.5. Compression and Master Sequence Number (MSN) (13)
4.6. Static and Dynamic Parts of a Context (13)
5. The ROHC Framework (Normative) (14)
5.1. The ROHC Channel (14)
5.1.1. Contexts and Context Identifiers (14)
5.1.2. Per-Channel Parameters (15)
5.1.3. Persistence of Decompressor Contexts (16)
5.2. ROHC Packets and Packet Types (16)
5.2.1. General Format of ROHC Packets (17)
5.2.1.1. Format of the Padding Octet (17)
5.2.1.2. Format of the Add-CID Octet (18)
5.2.1.3. General Format of Header (18)
5.2.2. Initialization and Refresh (IR) Packet Types (19)
5.2.2.1. ROHC IR Packet Type (20)
5.2.2.2. ROHC IR-DYN Packet Type (20)
5.2.3. ROHC Initial Decompressor Processing (21)
5.2.4. ROHC Feedback (22)
5.2.4.1. ROHC Feedback Format (23)
5.2.5. ROHC Segmentation (25)
5.2.5.1. Segmentation Usage Considerations (25)
5.2.5.2. Segmentation Protocol (26)
5.3. General Encoding Methods (27)
5.3.1. Header Compression CRCs, Coverage and Polynomials ..27 5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers (27)
5.3.1.2. 3-bit CRC in Compressed Headers (27)
5.3.1.3. 7-bit CRC in Compressed Headers (28)
5.3.1.4. 32-bit Segmentation CRC (28)
5.3.2. Self-Describing Variable-Length Values (29)
5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) (29)
5.4.1. IR Packet (30)
姜异康姜大明5.4.2. Normal Packet (31)
5.4.3. Decompressor Operation (31)
5.4.4. Feedback (32)
6. Overview of a ROHC Profile (Informative) (32)
7. Security Considerations (33)
8. IANA Considerations (34)
9. Acknowledgments (35)
10. References (35)
10.1. Normative References (35)
10.2. Informative References (35)
Appendix A. CRC Algorithm (37)
Jonsson, et al. Standards Track [Page 2]
For many types of networks, reducing the deployment and operational
costs by improving the usage of the bandwidth resources is of vital
importance. Header compression over a link is possible because some of the information carried within the header of a packet becomes
compressible between packets belonging to the same flow.
For links where the overhead of the IP header(s) is problematic, the total size of the header may be significant. Applications carrying
data carried within RTP [13] will then, in addition to link-layer
framing, have an IPv4 [10] header (20 octets), a UDP [12] header (8
octets), and an RTP header (12 octets), for a total of 40 octets.
With IPv6 [11], the IPv6 header is 40 octets for a total of 60
octets. Applications transferring data using TCP [14] will have 20
octets for the transport header, for a total size of 40 octets for
IPv4 and 60 octets for IPv6.
The relative gain for specific flows (or applications) depends on the size of the payload used in each packet. For applications such as
Voice-over-IP, where the size of the payload containing coded speech can be as small as 15-20 octets, this gain will be quite significant. Similarly, relative gains for TCP flows carrying large payloads (such as file transfers) will be less than for flows carrying smaller
payloads (such as application signaling, e.g., session initiation).
As more and more wireless link technologies are being deployed to
秋天的图画
教学设计carry IP traffic, care must be taken to address the specificcharacteristics of these technologies within the header compression
oltc
algorithms. Legacy header compression schemes, such as those defined in [16] and [17], have been shown to perform inadequately over links where both the lossy behavior and the round-trip times are non-
negligible, such as those observed for example in wireless links and IP tunnels.
In addition, a header compression scheme should handle the often
non-trivial residual errors, i.e., where the lower layer may pass a
packet that contains undetected bit errors to the decompressor. It
should also handle loss and reordering before the compression point, as well as on the link between the compression and decompression
points [7].
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.
Jonsson, et al. Standards Track [Page 3]
RFC 3095 [3] defines the ROHC framework along with an initial set of compression profiles. To im
prove and simplify the specification, the framework and the profiles’ parts have been split into separate
documents. This document explicitly defines the ROHC framework, but it does not modify or update the definition of the framework
specified by RFC 3095; both documents can be used independently of
each other. This also implies that implementations based on either
definition will be compatible and interoperable with each other.
However, it is the intent to let this specification replace RFC 3095 as the base specification for all profiles defined in the future.
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 [1].
2.1. Acronyms
This section lists most acronyms used for reference.
ACK Acknowledgment.
CID Context Identifier.
CO Compressed Packet Format.
CRC Cyclic Redundancy Check.
IR Initialization and Refresh.
IR-DYN Initialization and Refresh, Dynamic part.
LSB Least Significant Bit(s).
MRRU Maximum Reconstructed Reception Unit.
MSB Most Significant Bit(s).
MSN Master Sequence Number.
NACK Negative Acknowledgment.
ROHC RObust Header Compression.
2.2. ROHC Terminology
Context
The context of the compressor is the state it uses to compress a
header. The context of the decompressor is the state it uses to
decompress a header. Either of these or the two in combination
are usually referred to as "context", when it is clear which is
intended. The context contains relevant information from previous headers in the packet flow, such as static fields and possible
reference values for compression and decompression. Moreover,
additional information describing the packet flow is also part of Jonsson, et al. Standards Track [Page 4]
the context, for example, information about the change behavior of fields (e.g., the IP Identifier behavior, or the typical inter-
packet increase in sequence numbers and timestamps).
Context damage
When the context of the decompressor is not consistent with the
context of the compressor, decompression may fail to reproduce the original header. This situation can occur when the context of the decompressor has not been initialized properly or when packets
have been lost or damaged between the compressor and decompressor. Packets which cannot be decompressed due to inconsistent contexts are said to be lost due to context damage. Packets that are
decompressed but contain errors due to inconsistent contexts are
said to be damaged due to context damage.
Context repair mechanism
Context repair mechanisms are used to resynchronize the contexts, an important task since context damage causes loss propagation.
Examples of such mechanisms are NACK-based mechanisms, and the
periodic refreshes of important context information, usually done in unidirectional operation. There are also mechanisms that can
reduce the context inconsistency probability, for example,
repetition of the same type of information in multiple packets and CRCs that protect context-updating information.
CRC-8 validation
dat文件
The CRC-8 validation refers to the validation of the integrity
日本九二式重机
against bit error(s) in a received IR and IR-DYN header using the 8-bit CRC included in the IR/IR-DYN header.
CRC verification
The CRC verification refers to the verification of the result of a decompression attempt using the 3-bit CRC or 7-bit CRC included in the header of a compressed packet format.
Damage propagation
Delivery of incorrect decompressed headers due to context damage, that is, due to errors in (i.e., loss of or damage to) previous
header(s) or feedback.
Jonsson, et al. Standards Track [Page 5]
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议