Internet DRAFT - draft-jonsson-rohc-rfc3095bis-framework
draft-jonsson-rohc-rfc3095bis-framework
Network Working Group L-E. Jonsson
INTERNET-DRAFT G. Pelletier
Expires: May 2006 K. Sandlund
Ericsson
November 11, 2005
The RObust Header Compression (ROHC) Framework
<draft-jonsson-rohc-rfc3095bis-framework-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.
By submitting this Internet-Draft, each author accepts the provisions
of Section 3 of BCP 78.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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. RFC 3095 defined the ROHC framework
along with an initial set of compression profiles. To improve and
simplify the specification, it has been agreed that the framework and
the profiles parts of RFC 3095 be split into separate documents.
This document explicitly defines the ROHC framework, and thus
replaces the framework specification of RFC 3095.
Jonsson, et al. [Page 1]
INTERNET-DRAFT The ROHC Framework November 11, 2005
Table of Contents
1. Introduction.....................................................2
2. Terminology......................................................4
2.1. ROHC Terminology............................................4
2.2. Acronyms....................................................6
3. Background (Informative).........................................6
3.1. Header Compression Fundamentals.............................6
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.........9
4.3. Developing the ROHC protocol................................9
5. The ROHC Framework (Normative)..................................10
5.1. The ROHC Channel...........................................10
5.1.1. Contexts and Context Identifiers......................10
5.1.2. Per-Channel Parameters................................11
5.2. ROHC Packets and Packet Types..............................12
5.2.1. General Format of ROHC Packets........................12
5.2.2. Initialization and Refresh (IR) Packet Types..........14
5.2.2.1. ROHC IR Packet Type..............................14
5.2.2.2. ROHC IR-DYN Packet Type..........................15
5.2.2.3. ROHC Initial Decompressor Processing.............16
5.2.3. ROHC Feedback.........................................17
5.2.3.1. ROHC Feedback Format.............................18
5.2.4. ROHC segmentation.....................................20
5.2.4.1. Segmentation Usage Considerations................20
5.2.4.2. Segmentation Protocol............................20
5.3. General encoding methods...................................21
5.3.1. Header compression CRCs, coverage and polynomials.....21
5.3.1.1. IR and IR-DYN packet CRCs........................21
5.3.1.2. CRCs in compressed headers.......................22
5.3.2. Self-describing variable-length values................22
6. Overview of a ROHC Profile (Informative)........................22
7. Security Considerations.........................................24
8. IANA Considerations.............................................24
9. Acknowledgment..................................................25
10. References.....................................................25
10.1. Normative References......................................25
10.2. Informative References....................................25
11. Authors' Addresses.............................................27
1. Introduction
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.
Jonsson, et. al [Page 2]
INTERNET-DRAFT The ROHC Framework November 11, 2005
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 [12] will then, in addition to link layer
framing, have an IPv4 [9] header (20 octets), a UDP [11] header (8
octets), and an RTP header (12 octets) for a total of 40 octets. With
IPv6 [10], the IPv6 header is 40 octets for a total of 60 octets.
Applications transferring data using TCP [13] will have 20 octets for
the transport header, for a total size of 40 octets for IPv4 and 60
octets for IPv6.
Obviously, 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 FTP transfers) will be less than for
flows carrying smaller payloads (such as application signaling with
e.g. SIP).
As more and more wireless link technologies are being deployed to
carry IP traffic, care must be taken to address the specific
characteristics of these technologies within the header compression
algorithms. Legacy header compression schemes, such as those defined
in [15] and [16], have been shown to perform inadequately over links
where both the lossy behavior and the round-trip times (RTT) are non-
negligible, such as those observed for example in wireless links and
IP tunnels.
In addition, a header compression scheme must handle the often non-
trivial residual errors, i.e. where the lower link may pass a packet
that contains undetected bit errors to the decompressor. It must 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 is designed to address
efficient compression over links showing problematic characteristics
as explained above, and it is expected to perform very efficiently
over any type of link technology. ROHC 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. In particular, from the robustness
characteristics built into the protocol itself, it is especially well
suited for wireless links and tunnels.
RFC 3095 defined the ROHC framework along with an initial set of
compression profiles. To improve and simplify the specification, it
has been agreed that the framework and the profiles parts of RFC 3095
be split into separate documents.
This document explicitly defines the ROHC framework, and thus
replaces the framework specification of RFC 3095.
Jonsson, et. al [Page 3]
INTERNET-DRAFT The ROHC Framework November 11, 2005
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. 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 the context, for example information about how the IP
Identifier field changes and the typical inter-packet increase in
sequence numbers or 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 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 bring the contexts back in
sync when they were not, an important task since context damage
causes excessive loss propagation. Examples of such mechanisms are
the context request mechanism of CRTP, NACK-based mechanisms, and
periodic refreshes used in unidirectional operation. Note that
there are also mechanisms that can prevent context inconsistencies
from occurring, for example repetitions of extra information after
changes, and CRCs that protect context-updating information.
Damage propagation
Delivery of incorrect decompressed headers due to context damage,
i.e. due to errors in (i.e., loss of or damage to) previous
header(s) or feedback.
Jonsson, et. al [Page 4]
INTERNET-DRAFT The ROHC Framework November 11, 2005
Error detection
Detection of errors by lower layers. If error detection is not
perfect, there will be residual errors.
Error propagation
Damage propagation or loss propagation.
Header compression profile
A header compression profile is a compression algorithm, which
Specifies how to compress specific header combination(s). A
compression profile may be tailored to handle a specific set of
link characteristics, e.g. loss characteristics, reordering
between compression points, etc. Compression profiles provide the
details of the header compression framework introduced in this
document. The profile concept makes use of profile identifiers to
separate the different profiles that are used over the same
channel. These identifiers are each associated with one
compression context when setting up the compression scheme.
Link
A physical transmission path that constitutes a single IP hop.
Link RTT
The link RTT (round-trip time) is the time elapsing from the
moment the compressor sends a packet until it receives feedback
related to that packet (when such feedback is sent).
Loss propagation
Loss of headers, due to errors in (i.e., loss of or damage to)
previous header(s)or feedback.
Packet flow
A sequence of packets where the field values and change patterns
of field values are such that the headers can be compressed using
the same context.
Residual error
Error introduced during transmission and not detected by lower-
layer error detection schemes.
Jonsson, et. al [Page 5]
INTERNET-DRAFT The ROHC Framework November 11, 2005
ROHC channel
A logical unidirectional point-to-point channel carrying ROHC
packets from the compressor to the decompressor, optionally
carrying ROHC feedback information on the behalf of another
compressor-decompressor pair operating on a separate ROHC channel
in the opposite direction. See also [5].
This document also makes use of the conceptual terminology defined by
"ROHC Terminology and Channel Mapping Examples", RFC 3759 [5].
2.2. Acronyms
This section lists most acronyms used for reference.
CID Context Identifier.
CRC Cyclic Redundancy Check, an error detection mechanism.
IR Initialization and Refresh.
MRRU Maximum Reconstructed Reception Unit.
ROHC RObust Header Compression.
3. Background (Informative)
This chapter provides a background to the subject of header
compression. The fundamental ideas are described together with a
discussion about the history of header compression schemes. The
motivations driving development of the various schemes are discussed,
and their drawbacks identified, thereby providing the foundations for
the design of the ROHC framework and profiles [3].
3.1. Header Compression Fundamentals
Header compression is possible because there is significant
redundancy between header fields; both within the same packet header
but in particular between consecutive packets belonging to the same
flow. On the path end-to-end, the entire header information is
necessary for all packets in the flow, but over a single link some of
it becomes redundant and can be reduced, as long as it is
transparently recovered at the receiving end of the link. The header
size can be reduced by first sending field information that is
expected to remain static for (at least most of) the lifetime of the
flow. Further compression is achieved for the fields carrying
information changing more dynamically by using compression methods
tailored to their respective assumed change behavior.
To achieve compression and decompression, some necessary information
from past packets is maintained in a context. The compressor and the
decompressor update their respective contexts upon certain, not
necessarily synchronized, events. Impairment events may lead to
inconsistencies in the decompressor context (i.e. context damage),
which in turn may cause incorrect decompression. A robust header
Jonsson, et. al [Page 6]
INTERNET-DRAFT The ROHC Framework November 11, 2005
compression scheme needs mechanisms to minimize the possibility of
context damage, in combination with mechanisms for context repair.
3.2. A Short History of Header Compression
The first header compression scheme, CTCP [14], was introduced by Van
Jacobson. CTCP, also often referred to as VJ compression, compresses
the 40 octets of the TCP/IP header down to 4 octets. CTCP uses delta
encoding for sequentially changing fields. The CTCP compressor
detects transport-level retransmissions and sends a header that
updates the entire context when they occur. This repair mechanism
does not require any explicit signaling between compressor and
decompressor.
A general IP header compression scheme, IP header compression [15],
improves somewhat on CTCP. IPHC can compress arbitrary IP, TCP, and
UDP headers. When compressing non-TCP headers, IPHC does not use
delta encoding and is robust. The repair mechanism of CTCP is
augmented with negative acknowledgements, called CONTEXT_STATE
messages, which speeds up the repair. This context repair mechanism
is thus limited by the round-trip time of the link. IPHC does not
compress RTP headers.
CRTP [16] is an RTP extension to IPHC. CRTP compresses the 40 octets
of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP
Checksum is not enabled. If the UDP Checksum is enabled, the minimum
CRTP header is 4 octets.
On lossy links with long round-trip times, such as most cellular
wireless links and IP tunnels, CRTP does not perform well [19]. Each
packet lost over the link causes decompression of several subsequent
packets to fail, because the context becomes out of sync during at
least one link round-trip time from the lost packet. Unfortunately,
the large headers that CRTP sends when updating the context waste
additional bandwidth. This behavior is documented in [19].
CRTP uses a local repair mechanism known as TWICE, which was
introduced by IPHC. TWICE derives its name from the observation that
when the flow of compressed packets is regular, the correct guess
when one packet is lost between the compression points is to apply
the update in the current packet twice. While TWICE improves CRTP
performance significantly, [19] also found that even with TWICE, CRTP
doubled the number of lost packets.
An enhanced variant of CRTP, called eCRTP [18], means to improve the
robustness of CRTP in the presence of reordering and packet losses,
while keeping the protocol almost unchanged from CRTP. As a result,
eCRTP does provide better means to implement some degree of
robustness, albeit at the expense of additional overhead leading to a
reduction in compression efficiency in comparison to CRTP.
Jonsson, et. al [Page 7]
INTERNET-DRAFT The ROHC Framework November 11, 2005
4. Overview of Robust Header compression (ROHC) (Informative)
4.1. General Principles
As mentioned earlier, header compression is possible per link due to
the fact that there is much redundancy between header field values
within packets, and especially between consecutive packets of a
packet flow. To utilize these properties for header compression,
there are a few essential steps to consider.
The first step consists in identifying and grouping packets together
into different "flows", so that packet-to-packet redundancy is
maximized in order to improve the compression ratio. Grouping packets
into flows is usually based on source and destination host (IP)
addresses, transport protocol type (e.g. UDP or TCP), process (port)
numbers and potentially additional unique application identifiers,
such as the SSRC in RTP [12]. For each flow, the compressor and the
decompressor each establish a context for the flow, and identify the
context with a CID included in each compressed header.
The second step is to understand the change patterns of the various
header fields. On a high level, header fields fall into one of the
following classes:
INFERRED These fields contain values that can be inferred from
other fields or external sources, for example the size
of the frame carrying the packet can often be derived
from the link layer protocol, and thus does not have
to be transmitted at all by the compression scheme.
STATIC Fields classified as STATIC are assumed to be constant
throughout the lifetime of the packet flow. Their
value are therefore only communicated initially.
STATIC-DEF Fields classified as STATIC-DEF are used to define a
packet flow, as discussed above. Packets for which
respective values of these fields differ are treated
as belonging to different flows. They are in general
compressed as STATIC fields.
STATIC-KNOWN Fields classified as STATIC-KNOWN are expected to have
well-known values, and therefore their values do not
need to be communicated at all.
CHANGING These fields are expected to vary randomly, within
a limited value set or range, or in some other manner.
CHANGING fields are usually handled in various
sophisticated ways, based on a more detailed
classification of their expected change patterns.
Jonsson, et. al [Page 8]
INTERNET-DRAFT The ROHC Framework November 11, 2005
Finally, the last step is to choose the encoding method(s) that will
be applied onto different fields, based on the classification. The
encoding methods, in combination with the identified field behavior,
provide the input to the design of the compressed header formats. The
analysis of the probability distribution of the identified change
patterns then provide the means to optimize the packet formats, where
the most frequently occurring change patterns for a field should be
encoded within the most efficient format(s).
However, compression efficiency has to be traded against two other
properties: the robustness of the encoding to losses and errors
between the compressor and the decompressor, and the ability to
detect and cope with errors in the decompression process.
4.2. Compression Efficiency, Robustness and Transparency
The performance of a header compression scheme can be described with
three parameters: its compression efficiency, its robustness and its
compression transparency.
Compression efficiency
The compression efficiency is determined by how much the header
sizes are reduced by the compression scheme.
Robustness
A robust scheme tolerates loss and residual errors on the link over
which header compression takes place without losing additional
packets or introducing additional errors in decompressed headers.
Compression transparency
The compression transparency is a measure of the extent to which
the scheme maintains the semantics of the original headers. If all
decompressed headers are semantically identical to the
corresponding original headers, the scheme is transparent.
4.3. Developing the ROHC protocol
The challenge in developing a header compression protocol is to
conciliate compression efficiency and robustness, while maintaining
transparency. Increasing robustness should not come at the expense of
a lower compression efficiency, and vice-versa. The scheme should
also be flexible enough in its design to minimize the impacts from
the varying round-trip times and loss patterns of links where header
compression will be used.
To achieve this, the header compression scheme must provide
facilities for the decompressor to verify decompression and detect
potential context damage, as well as facilities to perform local
Jonsson, et. al [Page 9]
INTERNET-DRAFT The ROHC Framework November 11, 2005
repairs and to send context repair requests when possible. Header
compression schemes prior to the ones developed by the RObust Header
Compression (ROHC) WG were not designed with the above high-level
objectives in mind.
The ROHC WG has developed header compression solutions to meet the
needs of today's and future link technologies. While special
attention has been put towards meeting the more stringent
requirements stemming out from the characteristics of wireless links,
the results are equally applicable to many other link technologies.
RFC 3095 [3], "RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed", was published 2001, as
the first output of the ROHC WG. ROHC is a general and extendable
framework for header compression, on top of which profiles can be
defined for compression of different protocols headers. RFC 3095
introduced a number of new compression techniques, and was successful
at living up to the requirements on it, as described in [17].
Interoperability testing of RFC 3095 confirms the capabilities of
ROHC to meet its purposes, but feedback from implementers have also
indicated that the protocol specification is complex and sometimes
obscure. Most importantly, a clear distinction between framework and
profiles is not obvious, which also makes development of additional
profiles troublesome. This document therefore aims at explicitly
specifying the ROHC framework, while a companion document [8]
specifies revised versions of the compression profiles of RFC 3095.
5. The ROHC Framework (Normative)
This section normatively defines the parts common to all ROHC
profiles, i.e. the framework. The framework specifies the
requirements and functionality of the ROHC channel, including how to
handle multiple compressed flows over the same channel.
Finally, this section specifies encoding methods used in the packet
formats that are common to all profiles. These encoding methods may
be reused within profile specifications for encoding fields in
profile-specific parts of a packet format, without requiring their
redefinition.
5.1. The ROHC Channel
5.1.1. Contexts and Context Identifiers
Associated with each compressed flow is a context. The context is the
state that the compressor and the decompressor maintain in order to
correctly compress or decompress the headers of the packet in the
flow. Each context is identified using a Context Identifier (CID).
Jonsson, et. al [Page 10]
INTERNET-DRAFT The ROHC Framework November 11, 2005
Context information is conceptually kept in a table. The context
table is indexed using the CID, which is sent along with compressed
headers and feedback information.
The CID space can be either small, which means that CIDs can take the
values 0 through 15, or large, which means that CIDs take values
between 0 and 2^14 - 1 = 16383. Whether the CID space is large or
small MUST be established, possibly by negotiation, before any
compressed packet may be sent over the ROHC channel.
The CID space is distinct for each channel, i.e., CID 3 over channel
A and CID 3 over channel B do not refer to the same context, even if
the endpoints of A and B are the same nodes. In particular, CIDs for
any pair of ROHC channels are not related (two associated ROHC
channels serving as feedback channels for one another need not even
have CID spaces of the same size).
5.1.2. Per-Channel Parameters
The ROHC channel is based on a number of parameters that form part of
the established channel state and the per-context state. The state of
the ROHC channel MUST be established before the first ROHC packet may
be sent. This may be achieved using negotiation protocols provided by
the link layer (see also [4], which describes an option for
negotiation of ROHC parameters for PPP. This section describes some
of this state information in an abstract way:
MAX_CID: Nonnegative integer; highest context ID number to be used by
the compressor (note that this parameter is not coupled to, but in
effect further constrained by, LARGE_CIDS). This value represents
an agreement by the decompressor that it can provide sufficient
memory resources to host at least MAX_CID+1 contexts; the
decompressor MUST maintain established contexts within this space
until either the CID gets re-used or the channel is taken down.
LARGE_CIDS: Boolean; if false, the short CID representation (0 bytes
or 1 prefix byte, covering CID 0 to 15) is used; if true, the
embedded CID representation (1 or 2 embedded CID bytes covering
CID 0 to 16383) is used. See also 5.1.1.
PROFILES: Set of nonnegative integers, each integer indicating a
profile supported by the decompressor. A profile is identified by
a 16-bit value, where the 8 LSB bits indicate the actual profile,
and the 8 MSB bits indicate the variant of that profile. The ROHC
compressed header format identifies the profile used with only the
8 LSB bits; this means that if multiple variants of the same
profile are available for a ROHC channel, the PROFILES set MUST
NOT include more than one variant of the same profile after
negotiation. The compressor MUST NOT compress using a profile not
in PROFILES.
Jonsson, et. al [Page 11]
INTERNET-DRAFT The ROHC Framework November 11, 2005
FEEDBACK_FOR: Optional reference to a channel in the reverse
direction. If provided, this parameter indicates which channel
any feedback sent on this channel refers to (see [5]).
MRRU: Nonnegative integer. Maximum reconstructed reception unit. This
is the size of the largest reconstructed unit in octets that the
decompressor is expected to reassemble from segments (see 5.2.4).
Note that this size includes the CRC. If MRRU is negotiated to be
0, no segment headers are allowed on the channel.
5.2. ROHC Packets and Packet Types
This section uses the following convention in the diagrams when
representing various ROHC packet types, fields and formats:
- colons ":" indicate that the part is optional
- slashes "/" indicate variable length
The ROHC packet type indication scheme has been designed to provide
optional padding, a feedback packet type, an optional Add-CID octet
(which include 4 bits of CID), and a simple segmentation and
reassembly mechanism.
The following packet types are reserved at the ROHC framework level:
1110 : Padding or Add-CID octet
11110 : Feedback
11111000 : IR-DYN packet
1111110 : IR packet
1111111 : Segment
Other packet types can be defined and used by individual profiles.
5.2.1. General Format of ROHC Packets
A ROHC packet has the following general format:
--- --- --- --- --- --- --- ---
: Padding : variable length
--- --- --- --- --- --- --- ---
: Feedback : 0 or more feedback elements
--- --- --- --- --- --- --- ---
: Header : variable, with CID information
--- --- --- --- --- --- --- ---
: Payload : variable length
--- --- --- --- --- --- --- ---
Padding is any number (zero or more) of padding octets.
Feedback may consist of multiple concatenated feedback elements, as
defined in 5.2.3.1.
Jonsson, et. al [Page 12]
INTERNET-DRAFT The ROHC Framework November 11, 2005
Header is either a profile-specific header or an IR or IR-DYN header
(see section 5.2.2).
At least one of Feedback or Header MUST be present.
Padding Octet:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+
Note: The Padding Octet MUST NOT be interpreted as an Add-CID
octet for CID 0.
Add-CID Octet:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+
CID: 0x1 through 0xF indicates CIDs 1 through 15.
Note: The Padding Octet looks like an Add-CID octet for CID 0.
All Header packet types have the following general format:
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
+---+---+---+---+---+---+---+---+
Jonsson, et. al [Page 13]
INTERNET-DRAFT The ROHC Framework November 11, 2005
Header either starts with a packet type indication or has a packet
type indication immediately following an Add-CID Octet:
When the ROHC channel is configured with a small CID space:
o If an Add-CID immediately precedes the packet type, it has the
CID of the Add-CID; otherwise it has CID 0.
o A small CID with the value 0 is represented using zero bits;
therefore a flow associated with CID 0 has no CID overhead in
the compressed header. In such case, Header starts with a
packet type indication.
o A small CID with a value from 1 to 15 is represented by a four-
bit field in place of a packet type field (Add-CID) plus four
more bits, i.e. using the Add-CID octet as described above. In
this case, Header starts with the Add-CID octet, followed by a
packet type indication.
o There is no large CID in the compressed header.
When the ROHC channel is configured with a large CID space:
o The large CID is always present and is represented using the
encoding scheme of section 5.3.2, limited to two octets. In
this case, Header starts with a packet type indication.
5.2.2. Initialization and Refresh (IR) Packet Types
Initially, all contexts are in no context state, i.e., all packets
referencing this context except packets that have enough information
on the static fields are discarded. Section 5.2.2.3 describes the
decompressor logic for the IR and IR-DYN packet types.
IR packet types contain a profile identifier, which determines how
the rest of the header is to be interpreted. They also associate a
profile with a context. The stored profile parameter further
determines the syntax and semantics of the packet type identifiers
and packet types used in conjunction with a specific context.
The IR and IR-DYN packets always update the context for all context-
updating fields carried in the header. It never clears the context,
unless otherwise specified by the profile in the Profile field.
5.2.2.1. ROHC IR Packet Type
The IR header associates a CID with a profile, and typically also
initializes the context. It can typically also refresh all (or parts
of) the context. It has the following general format.
Jonsson, et. al [Page 14]
INTERNET-DRAFT The ROHC Framework November 11, 2005
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
x: Profile specific information. Interpreted according to the
profile indicated in the Profile field of the IR header.
Profile: The profile to be associated with the CID. In the IR
header, the profile identifier is abbreviated to the 8 least
significant bits (see section 5.1.2).
CRC: 8-bit CRC computed using the polynomial of section 5.3.1.1.
Profile specific information: The contents of this part of the IR
header are defined by the individual profiles. Interpreted
according to the profile indicated in the Profile field of the IR
header.
5.2.2.2. ROHC IR-DYN Packet Type
In contrast to the IR header, the IR-DYN header can never initialize
an uninitialized context. However, it can redefine what profile is
associated with a context, if the target profile allows this. Thus
this packet type also needs to be reserved at the framework level.
The IR-DYN header typically also initializes or refreshes parts of a
context. It has the following general format:
Jonsson, et. al [Page 15]
INTERNET-DRAFT The ROHC Framework November 11, 2005
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
Profile: The profile to be associated with the CID. This is
abbreviated in the same way as with IR packets.
CRC: 8-bit CRC computed using the polynomial of section 5.3.1.1.
Profile specific information: This part of the IR packet is
defined by individual profiles. It is interpreted according
to the profile indicated in the Profile field.
5.2.2.3. ROHC Initial Decompressor Processing
When the decompressor receives a packet of type IR, the profile
indicated in the IR packet determines how it is to be processed.
If the 8-bit CRC fails to verify the integrity of the header, the
packet MUST be discarded. If a profile is indicated in the context,
the logic of that profile determines what, if any, feedback is to be
sent. If no profile is noted in the context, the logic used to
determine what, if any, feedback is to be sent is up to the
implementation; however, it may be suitable to take no further
actions as any part of the IR packet may have caused the failure.
When the decompressor receives a packet of type IR-DYN, the profile
indicated in the IR-DYN packet determines how it is to be processed.
o If the 8-bit CRC fails to verify the integrity of the header,
the packet MUST be discarded. If a profile is indicated in the
context, the logic of that profile determines what, if any,
feedback is to be sent. If no profile is noted in the context,
the logic used to determine what, if any, feedback is to be sent
Jonsson, et. al [Page 16]
INTERNET-DRAFT The ROHC Framework November 11, 2005
is up to the implementation; however, it may be suitable to take
no further actions as any part of the IR packet may have caused
the failure.
o If the context has not been initialized by an IR packet, the
packet MUST be discarded. The logic of the profile indicated
in the IR-DYN header (if verified by the 8-bit CRC), determines
what, if any, feedback is to be sent.
If a parsing error occurs for any packet type, the decompressor MUST
discard the packet without further processing. For example, a CID
field is present in the compressed header when the large CID space is
used for the ROHC channel, and the field is coded using the self-
describing variable-length encoding of section 5.3.2; if the field
starts with 110 or 111, this would generate a parsing error for the
decompressor because this field must not be encoded with a size
larger than 2 octets.
5.2.3. ROHC Feedback
Feedback carries information from decompressor to compressor.
Feedback can be sent over a ROHC channel that operates in the same
direction as the feedback.
The ROHC packet type scheme has been designed to allow the transport
of feedback using interspersion or piggybacking, or a combination of
both, over a ROHC channel with the help of the following properties:
Reserved packet type:
A feedback packet type is reserved at the framework level. The
packet type can carry variable-length feedback information.
CID information:
The feedback information sent on a particular channel is passed
to, and interpreted by, the compressor associated with feedback on
that channel. Thus, the feedback information contains CID
information. The ROHC feedback scheme thus requires that a channel
carries feedback to at most one compressor. How a compressor is
associated with the feedback for a particular channel is outside
the scope of this specification. See also [5].
Length information:
The length of the feedback information can be determined by
examining the first few octets of the feedback. This makes
possible the piggybacking of feedback, and also the concatenation
of more than one feedback element in a packet. The length
information thus decouples the decompressor from the associated
same-side compressor, as the decompressor can extract the feedback
Jonsson, et. al [Page 17]
INTERNET-DRAFT The ROHC Framework November 11, 2005
information from the compressed header without parsing its
content, and hand over the extracted information.
The association between compressor-decompressor pairs operating in
opposite directions, for the purpose of exchanging piggyback and/or
interspersed feedback, SHOULD be maintained for the lifetime of the
ROHC channel. Otherwise, it is RECOMMENDED that the compressor be
notified if the feedback channel is no longer available: the
compressor SHOULD then restart compression by creating a new context
for each flow, and SHOULD use a CID value that was not previously
associated with the profile used to compress the flow.
5.2.3.1. ROHC Feedback Format
ROHC defines three different categories of feedback messages:
acknowledgement (ACK), negative ACK (NACK) and NACK for the entire
context (STATIC-NACK). Other type of information may be defined in
profile-specific feedback information.
ACK : Acknowledges successful decompression of a packet,
which means that the context is considered valid up to
this packet.
NACK : Indicates that some or all of the dynamic part of the
decompressor has been invalidated.
STATIC-NACK : Indicates that the entire static context of the
decompressor is not valid or has not been established.
Feedback sent on a ROHC channel consists of one or more concatenated
feedback elements, where each feedback element has the following
format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | Code | feedback type octet
+---+---+---+---+---+---+---+---+
: Size : if Code = 0
+---+---+---+---+---+---+---+---+
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
: :
/ large CID (5.3.2 encoding) / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
/ FEEDBACK type / variable length
+---+---+---+---+---+---+---+---+
Code: 0 indicates that a Size octet is present.
1-7 indicates the size of the feedback data field, in
octets.
Jonsson, et. al [Page 18]
INTERNET-DRAFT The ROHC Framework November 11, 2005
Size: Optional field indicating the size of the feedback data
field, in octets.
FEEDBACK type: FEEDBACK-1 or FEEDBACK-2.
CID information in feedback data indicates the CID of the packet flow
for which feedback is sent. Note that the LARGE_CIDS parameter that
controls whether a large CID is present is taken from the channel
state of the receiving compressor's channel, NOT from that of the
channel carrying the feedback.
The large CID, if present, is encoded according to section 5.3.2.
The CID field MUST NOT be encoded using more than 2 octets.
The FEEDBACK type field can have either of the following two formats:
FEEDBACK-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| profile specific information | 1 octet
+---+---+---+---+---+---+---+---+
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| |
+---+---+ profile specific / at least 2 octets
/ information |
+---+---+---+---+---+---+---+---+
Acktype: 0 = ACK
1 = NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used. Otherwise unparseable.)
Note: It is RECOMMENDED that profile-specific compressor feedback
logic include the assumption that the decompressor has invalidated
its entire dynamic context, and thus that an IR or an IR-DYN packet
should be sent, when defining the compressor response to a NACK.
Note: It is RECOMMENDED that profiles disallow the decompressor to
make a decompression attempt for packets carrying only a 3-bit CRC
after it has invalidated some or the entire dynamic context, until a
packet that contains sufficient information on the dynamic fields is
received, decompressed and successfully verified by a 7- or an 8-bit
CRC. Deviations from this recommendation should only make it
stricter, by only allowing decompression of packet types carrying 8-
bit CRC (e.g. IR and IR-DYN).
Jonsson, et. al [Page 19]
INTERNET-DRAFT The ROHC Framework November 11, 2005
5.2.4. ROHC segmentation
ROHC defines a simple segmentation protocol. The compressor may
perform segmentation e.g. to accommodate packets that are larger than
a specific size configured for the channel.
5.2.4.1. Segmentation Usage Considerations
The segmentation protocol defined in ROHC is not particularly
efficient. It is not intended to replace link layer segmentation
functions; these SHOULD be used whenever available and efficient for
the task at hand.
The ROHC segmentation protocol has been designed with an assumption
of in-order delivery of packets between the compressor and the
decompressor, using only a CRC for error detection, and no sequence
numbers. If in-order delivery cannot be guaranteed, ROHC segmentation
MUST NOT be used.
5.2.4.2. Segmentation Protocol
Segment Packet
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 1 | F |
+---+---+---+---+---+---+---+---+
/ Segment / variable length
+---+---+---+---+---+---+---+---+
F: Final bit. If set, it indicates that this is the last segment of
a reconstructed unit.
Padding octets and/or feedback may precede the segment header. It
never carries a CID. The reconstructed packet MUST NOT contain
padding, segments or feedback.
All segment header packets for one reconstructed unit have to be
received consecutively and in the correct order by the decompressor,
i.e., any non-segment-header packet following a non-final segment
header aborts the reassembly of the current reconstructed unit and
causes the decompressor to discard the non-final segments received on
this channel so far. When a final segment header is received, the
decompressor reassembles the segment carried in this packet and any
non-final segments that immediately preceded it into a single
reconstructed unit, in the order they were received. The
reconstructed unit has the format:
Jonsson, et. al [Page 20]
INTERNET-DRAFT The ROHC Framework November 11, 2005
Reconstructed Unit
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| |
/ Reconstructed ROHC packet / variable length
| |
+---+---+---+---+---+---+---+---+
/ CRC / 4 octets
+---+---+---+---+---+---+---+---+
The CRC is used by the decompressor to validate the reconstructed
unit. It uses the FCS-32 algorithm with the following generator
polynomial: x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + x^11 +
x^12 + x^16 + x^22 + x^23 + x^26 + x^32 [2]. If the reconstructed
unit is 4 octets or less, or if the CRC fails, or if it is larger
than the channel parameter MRRU (see 5.1.2), the reconstructed unit
MUST be discarded by the decompressor. If the CRC succeeds, the
reconstructed ROHC packet is interpreted as a ROHC Header, optionally
followed by a payload.
5.3. General encoding methods
5.3.1. Header compression CRCs, coverage and polynomials
This chapter describes how to calculate the CRCs used in ROHC packet
headers. For all CRCs, the algorithm in [2] is used, with the
polynomials specified in subsequent sections. A PERL implementation
of the algorithm can be found in Appendix A of [6].
Note that another type of CRC is defined in section 5.2.4.2, to be
used for reconstructed units.
5.3.1.1. IR and IR-DYN packet CRCs
The CRC in the IR and IR-DYN packet is calculated over the entire IR
or IR-DYN packet, excluding Payload and including CID or any Add-CID
octet. Padding isn't meant to be a meaningful part of a packet and is
not included in CRC calculation. As a result, the CRC doesn't cover
the "Add-CID octet for CID 0".
The CRC polynomial to be used for the 8-bit CRC is:
C(x) = 1 + x + x^2 + x^8
For purposes of computing the CRC, the CRC field in the header is set
to zero, and the initial content of the CRC register is to be preset
to all 1's.
Jonsson, et. al [Page 21]
INTERNET-DRAFT The ROHC Framework November 11, 2005
5.3.1.2. CRCs in compressed headers
The CRC in compressed headers is calculated over all octets of the
entire original header, before compression, in the following manner.
The initial content of the CRC register is preset to all 1's.
The polynomial to be used for the 3-bit CRC is:
C(x) = 1 + x + x^3
The polynomial to be used for the 7-bit CRC is:
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
The CRC in compressed headers is calculated over the entire original
header, before compression.
5.3.2. Self-describing variable-length values
The values of many fields and compression parameters can vary widely.
To optimize the transfer of such values, a variable number of octets
are used to encode them. The first few bits of the first octet
determine the number of octets used:
First bit is 0: 1 octet.
7 bits transferred.
Up to 127 decimal.
Encoded octets in hexadecimal: 00 to 7F
First bits are 10: 2 octets.
14 bits transferred.
Up to 16 383 decimal.
Encoded octets in hexadecimal: 80 00 to BF FF
First bits are 110: 3 octets.
21 bits transferred.
Up to 2 097 151 decimal.
Encoded octets in hexadecimal: C0 00 00 to DF FF FF
First bits are 111: 4 octets.
29 bits transferred.
Up to 536 870 911 decimal.
Encoded octets in hexadecimal: E0 00 00 00 to FF FF FF FF
6. Overview of a ROHC Profile (Informative)
The ROHC protocol is made up of a framework part and a profile part.
The framework defines the mechanisms common to all profiles, while
the profile defines the compression algorithm.
Jonsson, et. al [Page 22]
INTERNET-DRAFT The ROHC Framework November 11, 2005
Section 5 specified the details of the ROHC framework. This section
provides an informative overview of the elements that make a profile
specification. The normative specification of individual profiles is
outside the scope of this document.
A ROHC profile defines the elements that build up the compression
algorithm. A ROHC profile consists of:
Packet formats:
o Bits-on-the-wire
The profile defines the layout of the bits for profile-specific
packet types that it defines, and for the profile-specific parts
of packet types common to all profiles (e.g. IR and IR-DYN).
o Field encodings
Bits and groups of bits from the packet format layout, referred
to as compressed fields, represents the result of an encoding
method specific for that compressed field within a specific
packet format. The profile defines these encoding methods.
o Updating properties
The profile-specific packet formats may update the state of the
decompressor, and may do so in different ways. The profile
defines how individual profile-specific fields, or entire
profile-specific packet types, updates the decompressor context.
o Verification
Packets that update the state of the decompressor are verified,
to prevent incorrect updates to the decompressor context. The
profile defines the mechanism used to verify the decompression of
a packet.
Context management:
o Robustness logic
Packets may be lost or reordered between the compressor and the
decompressor. The profile defines mechanism to minimize the
impacts of such events, and prevent damage propagation.
o Repair mechanism
Despite the robustness logic, impairment events may still lead to
decompression failure(s), and even to context damage at the
decompressor. The profile defines repair mechanisms, including
feedback logic if used.
Jonsson, et. al [Page 23]
INTERNET-DRAFT The ROHC Framework November 11, 2005
7. Security Considerations
Because encryption eliminates the redundancy that header compression
schemes try to exploit, there is some inducement to forego encryption
of headers in order to enable operation over low-bandwidth links.
A malfunctioning or malicious header compressor could cause the
header decompressor to reconstitute packets that do not match the
original packets but still have valid headers and possibly also valid
transport checksums. Such corruption may be detected with end-to-end
authentication and integrity mechanisms, which will not be affected
by the compression. Moreover, the ROHC header compression scheme uses
an internal checksum for verification of reconstructed headers, which
reduces the probability of producing decompressed headers not
matching the original ones without this being noticed.
Denial-of-service attacks are possible if an intruder can introduce
(for example) bogus IR, IR-DYN or FEEDBACK packets onto the link and
thereby cause compression efficiency to be reduced. However, an
intruder having the ability to inject arbitrary packets at the link
layer in this manner raises additional security issues that dwarf
those related to the use of header compression.
8. IANA Considerations
An IANA registry for "RObust Header Compression (ROHC) Profile
Identifiers" [20] was created by RFC 3095 [3]. The assignment policy,
as outlined by RFC 3095, is the following:
The ROHC profile identifier is a non-negative integer. In many
negotiation protocols, it will be represented as a 16-bit value. Due
to the way the profile identifier is abbreviated in ROHC packets, the
8 least significant bits of the profile identifier have a special
significance: Two profile identifiers with identical 8 LSBs should be
assigned only if the higher-numbered one is intended to supersede the
lower-numbered one. To highlight this relationship, profile
identifiers should be given in hexadecimal (as in 0x1234, which would
for example supersede 0x0A34).
Following the policies outlined in [21], the IANA policy for
assigning new values for the profile identifier shall be
Specification Required: values and their meanings must be documented
in an RFC or in some other permanent and readily available reference,
in sufficient detail that interoperability between independent
implementations is possible. In the 8 LSBs, the range 0 to 127 is
reserved for IETF standard-track specifications; the range 128 to 254
is available for other specifications that meet this requirement
(such as Informational RFCs). The LSB value 255 is reserved for
future extensibility of the present specification.
Jonsson, et. al [Page 24]
INTERNET-DRAFT The ROHC Framework November 11, 2005
The following profile identifiers have so far been allocated:
Profile Identifier Usage Reference
------------------ ---------------------- ---------
0x0000 ROHC uncompressed RFC 3095
0x0001 ROHC RTP RFC 3095
0x0002 ROHC UDP RFC 3095
0x0003 ROHC ESP RFC 3095
0x0004 ROHC IP RFC 3843
0x0005 ROHC LLA RFC 3242
0x0105 ROHC LLA with R-mode RFC 3408
0x0007 ROHC RTP/UDP-Lite RFC 4019
0x0008 ROHC UDP-Lite RFC 4019
New profiles will need new identifiers to be assigned by the IANA,
but this document does not require any additional IANA action.
9. Acknowledgment
The authors would like to acknowledge all who have contributed to
previous ROHC work, and especially to the authors of RFC 3095 [3],
which is the technical basis for this document. Thanks also to the
various individuals who contributed to the ROHC RTP implementer's
guide, from which technical corrections and clarifications, when
applicable, have been incorporated into this document.
10. References
10.1. Normative References
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] W. Simpson, "PPP in HDLC-like framing", STD 51, RFC 1662, July
1994.
10.2. Informative References
[3] C. Bormann, et al., "RObust Header Compression (ROHC): Framework
and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,
July 2001.
[4] C. Bormann, "RObust Header Compression (ROHC) over PPP", RFC
3241, April 2002.
[5] L-E. Jonsson, "RObust Header Compression (ROHC): Terminology and
Channel Mapping Examples", RFC 3759, April 2004.
[6] L-E. Jonsson, et al., "The RFC 3095 Implementer's Guide",
internet-draft (work in progress), August 2005.
<draft-ietf-rohc-rtp-impl-guide-15.txt>
Jonsson, et. al [Page 25]
INTERNET-DRAFT The ROHC Framework November 11, 2005
[7] G. Pelletier, et al., "RObust Header Compression (ROHC): ROHC
over Channels that can Reorder Packets", internet-draft (work in
progress), May 2005.
<draft-ietf-rohc-over-reordering-03.txt>.
[8] G. Pelletier, et al., "RObust Header Compression (ROHC):
Profiles for RTP, UDP, UDP-Lite, ESP, IP, and uncompressed",
internet-draft (work in progress), November 2005.
<draft-pelletier-rohc-rfc3095bis-profiles-00.txt>
[9] J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[11] J. Postel, "User Datagram Protocol", STD 6, RFC 768, August
1980.
[12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[13] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[14] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC 1144, February 1990.
[15] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[16] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999.
[17] M. Degermark, "Requirements for robust IP/UDP/RTP header
compression", RFC 3096, July 2001.
[18] T. Koren, et al., "Enhanced Compressed RTP (CRTP) for Links with
High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
[19] Degermark, M., Hannu, H., Jonsson, L.E., and K. Svanbro,
"Evaluation of CRTP Performance over Cellular Radio Networks",
IEEE Personal Communication Magazine, Volume 7, number 4, pp.
20-25, August 2000.
[20] IANA registry, "RObust Header Compression (ROHC) Profile
Identifiers", http://www.iana.org/assignments/rohc-pro-ids
[21] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Jonsson, et. al [Page 26]
INTERNET-DRAFT The ROHC Framework November 11, 2005
11. Authors' Addresses
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Kristofer Sandlund
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 41 58
Fax: +46 920 996 21
EMail: kristofer.sandlund@ericsson.com
Jonsson, et. al [Page 27]
INTERNET-DRAFT The ROHC Framework November 11, 2005
Intellectual Property Statement
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Disclaimer of Validity
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 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.
This Internet-Draft expires May 11, 2006.
Jonsson, et. al [Page 28]
