draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt   rfc3409.txt 
Network Working Group Krister Svanbro Network Working Group K. Svanbro
INTERNET-DRAFT Ericsson Request for Comments: 3409 Ericsson
Expires: June 2002 December 19, 2001 Category: Informational December 2002
Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression
<draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at This memo provides information for the Internet community. It does
http://www.ietf.org/ietf/lid-abstracts.txt not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be Copyright (C) The Internet Society (2002). All Rights Reserved.
directed to its mailing list, rohc@cdt.luth.se.
Abstract Abstract
This document describes lower layer guidelines for robust header This document describes lower layer guidelines for robust header
compression (ROHC) and the requirements ROHC put on lower layers. The compression (ROHC) and the requirements ROHC puts on lower layers.
purpose of this document is to support the incorporation of robust The purpose of this document is to support the incorporation of
header compression algorithms, as specified in the ROHC working robust header compression algorithms, as specified in the ROHC
group, into different systems such as those specified by 3GPP, 3GPP2, working group, into different systems such as those specified by
ETSI, etc. The document covers only lower layer guidelines for Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2),
compression of RTP/UDP/IP and UDP/IP headers as specified in European Technical Standards Institute (ETSI), etc. This document
[RFC3095]. Both general guidelines and guidelines specific for covers only lower layer guidelines for compression of RTP/UDP/IP and
cellular systems are treated. UDP/IP headers as specified in [RFC3095]. Both general guidelines
and guidelines specific for cellular systems are discussed in this
document.
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction.................................................. 2
2. General guidelines............................................3 2. General guidelines............................................ 2
2.1. Error detection.......................................3 2.1. Error detection....................................... 2
2.2. Inferred header field information.....................3 2.2. Inferred header field information..................... 3
2.3. Handling of header size variation.....................4 2.3. Handling of header size variation..................... 3
2.4. Negotiation of header compression parameters..........5 2.4. Negotiation of header compression parameters.......... 5
2.5. Demultiplexing of flows onto logical channels.........5 2.5. Demultiplexing of flows onto logical channels......... 5
2.6. Packet type identification............................5 2.6. Packet type identification............................ 5
2.7. Packet duplication....................................6 2.7. Packet duplication.................................... 6
2.8. Packet reordering.....................................6 2.8. Packet reordering..................................... 6
2.9. Feedback packets......................................6 2.9. Feedback packets...................................... 6
3. Cellular system specific guidelines...........................6 3. Cellular system specific guidelines........................... 7
3.1. Handover procedures...................................7 3.1. Handover procedures................................... 7
3.2. Unequal error detection (UED).........................8 3.2. Unequal error detection (UED)......................... 8
3.3. Unequal error protection (UEP)........................8 3.3. Unequal error protection (UEP)........................ 9
4. IANA considerations...........................................9
5. Security considerations.......................................9 4. IANA Considerations........................................... 9
6. Author's addresses............................................9 5. Security Considerations....................................... 9
7. References....................................................9 6. References.................................................... 9
7. Author's Address..............................................10
8. Full Copyright Statement......................................11
1. Introduction 1. Introduction
Almost all header compression algorithms [RFC1144, RFC2507, RFC2508] Almost all header compression algorithms [RFC1144, RFC2507, RFC2508]
rely on some functionality from underlying link layer. Headers rely on some functionality from the underlying link layer. Headers
(compressed or not) are expected to be delivered without any residual (compressed or not) are expected to be delivered without any residual
bit errors, IP length fields are inferred from link layer length bit errors. IP length fields are inferred from link layer length
fields and packet type identification may be separated from the fields. Packet type identification may be separated from the header
header compression scheme and instead done at underlying link layer. compression scheme and performed at the underlying link layer.
[RFC2509], for example, elaborates on how to incorporate IP header [RFC2509], for example, elaborates on how to incorporate IP header
compression [RFC2507] in PPP [RFC1661]. compression [RFC2507] in PPP [RFC1661].
It is important to be aware of such assumptions on required It is important to be aware of such assumptions on required
functionality from underlying layers when incorporating a header functionality from underlying layers when incorporating a header
compression scheme into a system. The functionality required by a compression scheme into a system. The functionality required by a
specific header compression scheme from lower layers may also be specific header compression scheme from lower layers may also be
needed if incorporation of a header compression scheme is to be needed if incorporation of a header compression scheme is to be
prepared without knowing the exact details of the final scheme. prepared without knowing the exact details of the final scheme.
This document describes lower layer guidelines for robust RTP/UDP/IP This document describes lower layer guidelines for robust RTP/UDP/IP
header compression [RFC3095] as specified by the ROHC working group. header compression [RFC3095] as specified by the ROHC working group.
[RFC3095] will from this point be referenced to as ROHC. These [RFC3095] will from this point be referenced to as ROHC. These
guidelines should simplify incorporation of the robust header guidelines should simplify incorporation of the robust header
compression algorithms into cellular systems like those standardized compression algorithms into cellular systems like those standardized
by 3GPP, 3GPP2, ETSI, etc, and also into specific link layer by 3GPP, 3GPP2, ETSI, etc, and also into specific link layer
protocols such as PPP. The document should also enable preparation of protocols such as PPP. The document should also enable preparation
this incorporation without requiring detailed knowledge about the of this incorporation without requiring detailed knowledge about the
final header compression scheme. Relevant standardization groups final header compression scheme. Relevant standardization groups
standardizing link layers should, aided by this document, include standardizing link layers should, aided by this document, include
required functionality in "their" link layers to support robust required functionality in "their" link layers to support robust
header compression. header compression.
Hence, this document clarifies the requirements ROHC put on lower Hence, this document clarifies the requirements ROHC put on lower
layers, while the requirements on ROHC may be found in [RFC3096]. layers, while the requirements on ROHC may be found in [RFC3096].
2. General guidelines 2. General guidelines
2.1. Error detection 2.1. Error detection
All current header compression schemes [RFC1144, RFC2507, RFC2508] All current header compression schemes [RFC1144, RFC2507, RFC2508]
rely on lower layers to detect errors in (compressed) headers. This rely on lower layers to detect errors in (compressed) headers. This
is usually done with link layer checksums covering at least the is usually done with link layer checksums covering at least the
compressed header. However, any error detecting mechanism may fail to compressed header. However, any error detecting mechanism may fail
detect some bit errors, which are usually called residual bit errors. to detect some bit errors, which are usually called residual bit
errors.
As for non-compressed IP packets, lower layers must provide similar As for non-compressed IP packets, lower layers must provide similar
error detection, at least for ROHC headers. ROHC has been designed error detection, at least for ROHC headers. ROHC has been designed
not to increase the residual bit error rate (for reasonable residual not to increase the residual bit error rate (for reasonable residual
error rates) compared to the case when no header compression is used. error rates) compared to the case when no header compression is used.
Headers passed up to the header decompressor should, however, have a Headers passed up to the header decompressor should, however, have a
residual bit error probability close to zero. residual bit error probability close to zero.
A ROHC decompressor might make use of packets with erroneous headers, A ROHC decompressor might make use of packets with erroneous headers,
even if they must be discarded. It is therefore recommended that also even if they must be discarded. It is therefore recommended that
such invalid packets are passed up to the decompressor instead of such invalid packets are passed up to the decompressor instead of
being discarded by lower layers, but the packet must then be being discarded by lower layers, but the packet must then be
accompanied with an error indication. accompanied with an error indication.
2.2. Inferred header field information 2.2. Inferred header field information
Some fields of the RTP/UDP/IP headers may be classified as inferred, Some fields of the RTP/UDP/IP headers may be classified as inferred,
that is their values are to be inferred from other values or from an that is their values are to be inferred from other values or from an
underlying link layer. A ROHC decompressor requires that at least the underlying link layer. A ROHC decompressor requires that at least
following information can be inferred from any underlying link layer: the following information can be inferred from any underlying link
layer:
Packet Length (IPv4) / Payload Length (IPv6) Packet Length (IPv4) / Payload Length (IPv6)
The received packet (with compressed header) length. The received packet (with compressed header) length.
Length (UDP) Length (UDP)
This field is redundant with the Packet Length (IPv4) or the This field is redundant with the Packet Length (IPv4) or the
Payload Length (IPv6) field. Payload Length (IPv6) field.
In summary, all these fields relate to the length of the packet the In summary, all these fields relate to the length of the packet the
compressed header is included in. These fields may thus be inferred compressed header is included in. These fields may thus be inferred
by the decompressor if one packet length value is signaled from the by the decompressor if one packet length value is signaled from the
link layer to the decompressor on a per packet basis. This packet link layer to the decompressor on a per packet basis. This packet
length value should be the length of the received packet including length value should be the length of the received packet including
the (compressed) header. the (compressed) header.
2.3. Handling of header size variations 2.3. Handling of header size variations
It is desirable for many cellular link layer technologies that bit It is desirable for many cellular link layer technologies that bit
rate variations and thus packet size variations are minimized. rate variations and thus packet size variations are minimized.
However, there will always be some variation in compressed header However, there will always be some variation in compressed header
sizes since there is a trade-off between header size variations and sizes since there is a trade-off between header size variations and
compression efficiency, and also due to events in the header flow and compression efficiency, and also due to events in the header flow and
on the channel. Variations in header sizes cause variations in packet on the channel. Variations in header sizes cause variations in
sizes depending on variations of payload size. The following will packet sizes depending on variations of payload size. The following
only treat header size variations caused by ROHC and not packet size will only treat header size variations caused by ROHC and not packet
variations due to variations of payload size. size variations due to variations of payload size.
The link layer must in some manner support varying header sizes from The link layer must in some manner support varying header sizes from
40 bytes (full RTP/UDP/IPv4 header) or 60 bytes (full RTP/UDP/IPv6) 40 bytes (full RTP/UDP/IPv4 header) or 60 bytes (full RTP/UDP/IPv6)
down to 1 byte for the minimal compressed header. It is likely that down to 1 byte for the minimal compressed header. It is likely that
the small compressed headers dominate the flow of headers, and that the small compressed headers dominate the flow of headers, and that
the largest headers are sent rarely, e.g. only a few times in the the largest headers are sent rarely, e.g., only a few times in the
initialization phase of the header compression scheme. initialization phase of the header compression scheme.
Header size variations and thus packet size variations depend on Header size variations and thus packet size variations depend on
numerous factors. Unpredictable changes in the RTP, UDP or IP headers numerous factors. Unpredictable changes in the RTP, UDP or IP
may cause compressed headers to momentarily increase in size, and headers may cause compressed headers to momentarily increase in size,
header sizes may depend on packet loss rate at lower layers. Header and header sizes may depend on packet loss rate at lower layers.
size distributions depend also on the mode ROHC operates in. However, Header size distributions depend also on the mode ROHC operates in.
for e.g. a voice application, carried by RTP/UDP/IPv4, with a However, for e.g., a voice application, carried by RTP/UDP/IPv4, with
constant speech frame size and silence suppression, the following a constant speech frame size and silence suppression, the following
basic header size changes may be considered as typical: basic header size changes may be considered as typical:
In the very beginning of the speech session, the ROHC scheme is In the very beginning of the speech session, the ROHC scheme is
initialized by sending full headers called IR/DYN. These are the initialized by sending full headers called IR/DYN. These are the
largest headers, with sizes depending basically on the IP-version. largest headers, with sizes depending basically on the IP-version.
For IPv4 the size is approximately 40 bytes, and for IPv6 For IPv4 the size is approximately 40 bytes, and for IPv6
approximately 60 bytes. The IR/DYN headers are used typically during approximately 60 bytes. The IR/DYN headers are used typically during
one round trip time, possible interleaved with compressed headers. one round trip time, possible interleaved with compressed headers.
After that, usually only compressed headers are sent. Compressed After that, usually only compressed headers are sent. Compressed
headers may vary in size from 1 byte up to several bytes. The headers may vary in size from 1 byte up to several bytes. The
smallest compressed headers are used when there is no unpredictable smallest compressed headers are used when there is no unpredictable
changes in header fields, typically during a talk spurt. In the changes in header fields, typically during a talk spurt. In the
beginning of a talk spurt, compressed header sizes may increase by beginning of a talk spurt, compressed header sizes may increase by
one or a few bytes momentarily. Apart from increases due to new talk one or a few bytes momentarily. Apart from increases due to new talk
spurts, compressed headers may increase in size momentarily due to spurts, compressed headers may increase in size momentarily due to
unpredictable changes in header fields. unpredictable changes in header fields.
ROHC provides some means to limit the amount of produced header ROHC provides some means to limit the amount of produced header
sizes. In some cases a larger header than needed may be used to limit sizes. In some cases a larger header than needed may be used to
the number of header sizes used. Padding octets may also be used to limit the number of header sizes used. Padding octets may also be
fill up to a desired size. Chapter 6.3 (Implementation parameters) in used to fill up to a desired size. Chapter 6.3 (Implementation
[RFC3095] provides optional implementation parameters that make it parameters) in [RFC3095] provides optional implementation parameters
possible to mandate how a ROHC implementation should operate, for that make it possible to mandate how a ROHC implementation should
instance to mandate how many header sizes that may be used. operate, for instance to mandate how many header sizes that may be
used.
2.4. Negotiation of header compression parameters 2.4. Negotiation of header compression parameters
ROHC has some parameters that need to be configured in an initial ROHC has some parameters that need to be configured in an initial
setup phase. Which header compression profiles are allowed may have setup phase. Which header compression profiles are allowed may have
to be determined and also what kind of context identification (CID) to be determined and also what kind of context identification (CID)
mechanism to use. mechanism to use.
The lower layers supporting ROHC should thus include mechanisms for The lower layers supporting ROHC should thus include mechanisms for
negotiation of header compression parameters such as CID usage and negotiation of header compression parameters such as CID usage and
header compression profile support. In certain environments, it might header compression profile support. In certain environments, it
also be desirable to have mechanisms for re-negotiation of these might also be desirable to have mechanisms for re-negotiation of
parameters. these parameters.
The negotiation must also make sure that compressor and decompressor
use exactly the same profile, i.e. that the set of profiles available
after negotiation must not include two profile identifiers with the
same 8-bit LSB value.
For unidirectional links, this configuration might have to be For unidirectional links, this configuration might have to be
performed out-of-band or a priori, and similar methods could of performed out-of-band or a priori, and similar methods could of
course also be used for bi-directional links if direct negotiation is course also be used for bi-directional links if direct negotiation is
not possible. not possible.
2.5. Demultiplexing of flows onto logical channels 2.5. Demultiplexing of flows onto logical channels
In some cellular technologies flows are demultiplexed onto radio In some cellular technologies flows are demultiplexed onto radio
bearers suitable to the particular flows, i.e., onto logically bearers suitable to the particular flows, i.e., onto logically
separated channels. For instance, real-time flows such as voice and separated channels. For instance, real-time flows such as voice and
video may be carried on logically separated bearers. It is video may be carried on logically separated bearers. It is
recommended that this kind of demultiplexing is done in the lower recommended that this kind of demultiplexing is done in the lower
layers supporting robust header compression. By doing so, the need layers supporting robust header compression. By doing so, the need
for context identification in the header compression scheme is for context identification in the header compression scheme is
reduced. If there is a one to one mapping between flow and logical reduced. If there is a one to one mapping between flow and logical
channel, there is no need at all for context identification at the channel, there is no need at all for context identification at the
header compression level. header compression level.
2.6. Packet type identification 2.6. Packet type identification
Header compression schemes like [RFC2507, RFC2508] have relied on the Header compression schemes like [RFC2507, RFC2508] have relied on the
underlying link layer to identify different kinds of headers by means underlying link layer to identify different kinds of headers by means
of packet type identifiers on link layers. This kind of mechanism is of packet type identifiers on link layers. This kind of mechanism is
not necessarily needed for ROHC since a ROHC packet type identifier not necessarily needed for ROHC since a ROHC packet type identifier
is included in all compressed ROHC headers. Only if ROHC packets are is included in all compressed ROHC headers. Only if ROHC packets are
to be mixed with other packets, such as packets compressed by other to be mixed with other packets, such as packets compressed by other
header compression schemes, the link layer must provide a packet type header compression schemes, must the link layer provide a packet type
identifier. In such cases, or if ROHC is used on top of link layers identifier. In such cases, or if ROHC is used on top of link layers
already providing packet type identification, one (1) packet type already providing packet type identification, one (1) packet type
identifier must be reserved for identification of ROHC packets. Thus, identifier must be reserved for identification of ROHC packets. Thus,
only one ROHC packet type is needed to mix ROHC and e.g. RFC2507 only one ROHC packet type is needed to mix ROHC and e.g., RFC 2507
flows, or to support ROHC on links where packet type identifiers are flows, or to support ROHC on links where packet type identifiers are
already present. already present.
2.7. Packet duplication 2.7. Packet duplication
Exact duplications of one and the same packet may waste transmission Exact duplications of one and the same packet may waste transmission
resources and is in contradiction to compression. Even so, packet resources and is in contradiction to compression. Even so, packet
duplication may occur for various reasons. Packet duplication may duplication may occur for various reasons. Packet duplication may
also occur in different places along the path for a packet. also occur in different places along the path for a packet.
ROHC can handle packet duplication before the compressor but such ROHC can handle packet duplication before the compressor but such
packet duplications should be avoided for optimal compression packet duplications should be avoided for optimal compression
efficiency. For correct ROHC operation, lower layers are not allowed efficiency. For correct ROHC operation, lower layers are not allowed
to duplicate packets on the ROHC compressor-decompressor path. to duplicate packets on the ROHC compressor-decompressor path.
2.8. Packet reordering 2.8. Packet reordering
Lower layers between compressor and decompressor are assumed not to Lower layers between compressor and decompressor are assumed not to
reorder packets, i.e., the decompressor must receive packets in the reorder packets, i.e., the decompressor must receive packets in the
same order as the compressor sends them. ROHC handles, however, same order as the compressor sends them. ROHC handles, however,
reordering before the compression point. That is, there is no reordering before the compression point. That is, there is no
assumption that the compressor will only receive packets in sequence. assumption that the compressor will only receive packets in sequence.
2.9. Feedback packets 2.9. Feedback packets
ROHC may operate in three different modes; Unidirectional mode (U- ROHC may operate in three different modes; Unidirectional mode (U-
mode), bidirectional optimistic mode (O-mode) and bidirectional mode), bidirectional optimistic mode (O-mode) and bidirectional
reliable mode (R-mode). A brief description of the modes can be found reliable mode (R-mode). A brief description of the modes can be
in chapter 4.4 of [RFC3095]. found in chapter 4.4 of [RFC3095].
In U-mode it is not necessary to send any feedback from the In U-mode it is not necessary to send any feedback from the
decompressor to the compressor. O-mode and R-mode requires however decompressor to the compressor. O-mode and R-mode requires however
that feedback messages from the decompressor to the compressor may be that feedback messages from the decompressor to the compressor be
sent. Feedback messages consist of small ROHC internal packets sent. Feedback messages consist of small ROHC internal packets
without any application payload. It is possible in ROHC to piggy-back without any application payload. It is possible in ROHC to piggy-
feedback packets onto regular packets with ROHC compressed headers back feedback packets onto regular packets with ROHC compressed
and payload, if there is ROHC type of compression in both the forward headers and payload, if there is ROHC type of compression in both the
and reverse direction. However, this piggy-backing may not be desired forward and reverse direction. However, this piggy-backing may not
or possible in some cases. be desired or possible in some cases.
To support ROHC O-mode or R-mode operation, lower layers must provide To support ROHC O-mode or R-mode operation, lower layers must provide
transport of feedback packets from decompressor to compressor. If transport of feedback packets from decompressor to compressor. If
piggybacking of feedback packets is not used, lower layers must be piggybacking of feedback packets is not used, lower layers must be
able to handle feedback as small stand-alone packets. For optimal able to handle feedback as small stand-alone packets. For optimal
compression efficiency, feedback packets from the decompressor should compression efficiency, feedback packets from the decompressor should
be delivered as soon as possible to the compressor. be delivered as soon as possible to the compressor.
3. Cellular system specific guidelines 3. Cellular system specific guidelines
An important group of link layer technologies where robust header An important group of link layer technologies where robust header
compression will be needed are future cellular systems, which may compression will be needed are future cellular systems, which may
have a very large number of users in some years. The need for header have a very large number of users in some years. The need for header
compression is large in these kinds of systems to achieve spectrum compression is large in these kinds of systems to achieve spectrum
efficiency. Hence, it is important that future cellular systems can efficiency. Hence, it is important that future cellular systems can
efficiently incorporate the robust header compression scheme. efficiently incorporate the robust header compression scheme.
3.1. Handover procedures 3.1. Handover procedures
One cellular specific property that may affect header compression is One cellular specific property that may affect header compression is
mobility and thus, handover (i.e., change of serving base station or mobility and thus, handover (i.e., change of serving base station or
radio network controller). radio network controller).
The main characteristics of handovers relevant for robust header The main characteristics of handovers relevant for robust header
compression are: the length of the longest packet loss event due to compression are: the length of the longest packet loss event due to
handover (i.e. the number of consecutive packet losses), and handover (i.e., the number of consecutive packet losses), and
relocation of header compression context when necessary. relocation of header compression context when necessary.
Depending on the location of the header compressor/decompressor in Depending on the location of the header compressor/decompressor in
the radio access network and the type of handover, handover may or the radio access network and the type of handover, handover may or
may not cause disruptions or packet loss events in the (compressed) may not cause disruptions or packet loss events in the (compressed)
header flow relevant for the header compression scheme. For instance, header flow relevant for the header compression scheme. For
if soft handover is used and if the header compressor/decompressor instance, if soft handover is used and if the header
reside above the combining point for soft handover, there will be no compressor/decompressor reside above the combining point for soft
extra packet losses visible to the decompressor due to handover. In handover, there will be no extra packet losses visible to the
hard handovers, where packet loss events due to handover is decompressor due to handover. In hard handovers, where packet loss
introduced, the length of the longest consecutive packet loss is most events due to handover is introduced, the length of the longest
relevant and should thus be minimized. consecutive packet loss is most relevant and thus should be
minimized.
To maintain efficient ROHC operation, it should be ensured that To maintain efficient ROHC operation, it should be ensured that
handover events do not cause significant long events of consecutive handover events do not cause significant long events of consecutive
packet loss. The term "significant" in this context relates to the packet loss. The term "significant" in this context relates to the
kind of loss tolerable for the carried real-time application. kind of loss tolerable for the carried real-time application.
If hard handovers are performed, which may cause significant long If hard handovers are performed, which may cause significant long
events of consecutive packet loss, the radio access network should events of consecutive packet loss, the radio access network should
notify the compressor when such a handover has started and completed. notify the compressor when such a handover has started and completed.
The compressor could then be implemented to take proper actions and The compressor could then be implemented to take proper actions and
prevent consequences from such long loss events. prevent consequences from such long loss events.
Cellular systems supporting robust header compression may have Cellular systems supporting robust header compression may have
internal mechanisms for transferring the header compression context internal mechanisms for transferring the header compression context
between nodes where contexts may reside, at or before handover. If no between nodes where contexts may reside, at or before handover. If
such mechanism for transferring header compression context between no such mechanism for transferring header compression context between
nodes is available, the contexts may be resynchronized by the header nodes is available, the contexts may be resynchronized by the header
compression scheme itself by means of a context refresh. The header compression scheme itself by means of a context refresh. The header
compressor will then perform a new header compression initialization, compressor will then perform a new header compression initialization,
e.g. by sending full headers. This will, however, introduce an e.g., by sending full headers. This will, however, introduce an
increase in the average header size dependent on how often a transfer increase in the average header size dependent on how often a transfer
of context is needed. To reinitialize the context in such cases, the of context is needed. To reinitialize the context in such cases, the
lower layers must indicate to the header compressor when a handover lower layers must indicate to the header compressor when a handover
has occurred, so that it knows when to refresh the context. Chapter has occurred, so that it knows when to refresh the context. Chapter
6.3 (Implementation parameters) in [RFC3095] provides optional 6.3 (Implementation parameters) in [RFC3095] provides optional
implementation parameters that make it possible to trigger e.g. a implementation parameters that make it possible to trigger e.g., a
complete context refresh. complete context refresh.
3.2. Unequal error detection (UED) 3.2. Unequal error detection (UED)
Section 3.1 states that ROHC requires error detection from lower Section 3.1 states that ROHC requires error detection from lower
layers for at least the compressed header. However, some cellular layers for at least the compressed header. However, some cellular
technologies may differentiate the amount of error detection for technologies may differentiate the amount of error detection for
different parts of a packet. For instance, it could be possible to different parts of a packet. For instance, it could be possible to
have a stronger error detection for the header part of a packet, if have a stronger error detection for the header part of a packet, if
the application payload part of the packet is less sensitive to the application payload part of the packet is less sensitive to
errors, e.g. some cellular types of speech codecs. errors, e.g., some cellular types of speech codes.
ROHC does not require UED from lower layers, ROHC requires only an ROHC does not require UED from lower layers, ROHC requires only an
error detection mechanism that detects errors in at least the header error detection mechanism that detects errors in at least the header
part of the packet. There is thus no requirement on lower layers to part of the packet. Thus there is no requirement on lower layers to
provide separate error detection for the header and payload part of a provide separate error detection for the header and payload part of a
packet. However, overall performance may be increased if UED is used. packet. However, overall performance may be increased if UED is
used.
For example, if equal error detection is used in the form of one link For example, if equal error detection is used in the form of one link
layer checksum covering the entire packet including both header and layer checksum covering the entire packet including both header and
payload part, any bit error will cause the packet to be discarded at payload part, any bit error will cause the packet to be discarded at
the ROHC decompressor. It is not possible to distinguish between the ROHC decompressor. It is not possible to distinguish between
errors in the header and the payload part of the packet with this errors in the header and the payload part of the packet with this
error detection mechanism and the ROHC decompressor must assume that error detection mechanism and the ROHC decompressor must assume that
the header is damaged, even if the bit error hit the payload part of the header is damaged, even if the bit error hit the payload part of
the packet. If the header is assumed to be damaged, it is not the packet. If the header is assumed to be damaged, it is not
possible to ensure correct decompression and that packet will thus be possible to ensure correct decompression and that packet will thus be
discarded. If the application is such that it tolerates some errors discarded. If the application is such that it tolerates some errors
in the payload, it could have been better to deliver that packet to in the payload, it could have been better to deliver that packet to
the application and let the application judge whether the payload was the application and let the application judge whether the payload was
usable or not. Hence, with an unequal error detection scheme where it usable or not. Hence, with an unequal error detection scheme where
is possible to separate detection of errors in the header and payload it is possible to separate detection of errors in the header and
part of a packet, more packets may be delivered to applications in payload part of a packet, more packets may be delivered to
some cases for the same lower layer error rates. The final benefit applications in some cases for the same lower layer error rates. The
depends of course on the cost of UED for the radio interface and final benefit depends of course on the cost of UED for the radio
related protocols. interface and related protocols.
3.3. Unequal error protection (UEP) 3.3. Unequal error protection (UEP)
Some cellular technologies can provide different error probabilities Some cellular technologies can provide different error probabilities
for different parts of a packet, unequal error protection (UEP). For for different parts of a packet, unequal error protection (UEP). For
instance, the lower layers may provide a stronger error protection instance, the lower layers may provide a stronger error protection
for the header part of a packet compared to the payload part of the for the header part of a packet compared to the payload part of the
packet. packet.
ROHC does not require UEP. UEP may be beneficial in some cases to ROHC does not require UEP. UEP may be beneficial in some cases to
reduce the error rate in ROHC headers, but only if it is possible to reduce the error rate in ROHC headers, but only if it is possible to
distinguish between errors in header and payload parts of a packet, distinguish between errors in header and payload parts of a packet,
i.e. only if unequal error detection (UED) is used. The benefit of i.e., only if unequal error detection (UED) is used. The benefit of
UEP depends of course on the cost of UEP for the radio interface and UEP depends of course on the cost of UEP for the radio interface and
related protocols. related protocols.
4. IANA Considerations 4. IANA Considerations
A protocol which follows these guidelines, e.g., [RFC3095], will A protocol which follows these guidelines, e.g., [RFC3095], will
require the IANA to assign various numbers. This document by itself, require the IANA to assign various numbers. This document by itself,
however, does not require IANA involvement. however, does not require IANA involvement.
5. Security Considerations 5. Security Considerations
A protocol which follows these guidelines, e.g., [RFC3095], must be A protocol which follows these guidelines, e.g., [RFC3095], must be
able to compress packets containing IPSEC headers according to able to compress packets containing IPSEC headers according to
[RFC3096]. There may be other sequrity aspects to consider in such [RFC3096]. There may be other security aspects to consider in such
protocols. This document by itself, however, does not add security protocols. This document by itself, however, does not add security
risks. risks.
6. Author's Addresses 6. References
Krister Svanbro Tel: +46 920 20 20 77 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Box 920 Fax: +46 920 20 20 99 Serial Links", RFC 1144, February 1990.
Ericsson Erisoft AB Email: krister.svanbro@ericsson.com
SE-971 28 Lulea, Sweden
7. References [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC3095] Carsten Borman et al, "Robust Header Compression (ROHC)", [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
RFC 3095, July 2001. Compression", RFC 2507, February 1999.
[RFC3096] Mikael Degermark, "Requirements for robust IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
header compression", RFC 3096, July 2001. Headers for Low-Speed Serial Links", RFC 2508, February
1999.
[RFC1144] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed [RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header
Serial Links", RFC 1144, February 1990. Compression over PPP", RFC 2509, February 1999.
[RFC2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP [RFC3095] Borman, C., Burmeister, C., Degermark, M., Fukushima, H.,
Header Compression", RFC 2507, February 1999. 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)", RFC 3095, July 2001.
[RFC2508] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP [RFC3096] Degermark, M., "Requirements for robust IP/UDP/RTP header
Headers for Low-Speed Serial Links", RFC 2508, compression", RFC 3096, July 2001.
February 1999.
[RFC2509] Mattias Engan, Steven Casner, Carsten Bormann, "IP Header 7. Author's Address
Compression over PPP", RFC2509, February 1999
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", Krister Svanbro
STD 51, RFC 1661, July 1994. Box 920
Ericsson AB
SE-971 28 Lulea, Sweden
Full copyright statement Phone: +46 920 20 20 77
Fax: +46 920 20 20 99
EMail: krister.svanbro@ericsson.com
Copyright (C) The Internet Society (2001). All Rights Reserved. 8. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 10, line 33 skipping to change at page 11, line 33
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires June 19, 2002. Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 84 change blocks. 
183 lines changed or deleted 190 lines changed or added

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