draft-ietf-rohc-rtp-lower-layer-guidelines-02.txt   draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt 
Network Working Group Krister Svanbro, Ericsson Network Working Group Krister Svanbro
INTERNET-DRAFT Sweden INTERNET-DRAFT Ericsson
Expires: May 2002 November 19, 2001 Expires: June 2002 December 19, 2001
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-02.txt> <draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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.....................4
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...........................6
3.1. Handover procedures...................................7 3.1. Handover procedures...................................7
3.2. Unequal error detection...............................8 3.2. Unequal error detection (UED).........................8
3.3. Unequal error protection..............................8 3.3. Unequal error protection (UEP)........................8
4. IANA considerations...........................................9 4. IANA considerations...........................................9
5. Security considerations.......................................9 5. Security considerations.......................................9
6. Author's addresses............................................9 6. Author's addresses............................................9
7. References....................................................9 7. References....................................................9
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 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
skipping to change at page 2, line 49 skipping to change at page 2, line 49
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 system 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 of
this incorporation without requiring detailed knowledge about the 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 clarify 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 to
skipping to change at page 3, line 37 skipping to change at page 3, line 37
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 also
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 require that at least the underlying link layer. A ROHC decompressor requires that at least the
following information from any underlying link layer: 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.
skipping to change at page 4, line 26 skipping to change at page 4, line 26
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 headers
may cause compressed headers to momentarily increase in size as well may cause compressed headers to momentarily increase in size, and
as header sizes may depend on packet loss rate at lower layers. header sizes may depend on packet loss rate at lower layers. Header
Header size distributions depend also on the mode ROHC operate in. size distributions depend also on the mode ROHC operates in. However,
However, for e.g. a voice application, carried by RTP/UDP/IPv4, with for e.g. a voice application, carried by RTP/UDP/IPv4, with a
a constant speech frame size and silence suppression, the following 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 and with sizes depending on basically IP-version. For largest headers, with sizes depending basically on the IP-version.
IPv4 the size is approximately 40 bytes, and for IPv6 approximately For IPv4 the size is approximately 40 bytes, and for IPv6
60 bytes. The IR/DYN headers are used typically during one round trip approximately 60 bytes. The IR/DYN headers are used typically during
time, possible interleaved with compressed headers. After that, one round trip time, possible interleaved with compressed headers.
usually only compressed headers are sent. Compressed headers may vary After that, usually only compressed headers are sent. Compressed
in size from 1 byte up to several bytes. The smallest compressed headers may vary in size from 1 byte up to several bytes. The
headers is used when there is no unpredictable changes in header smallest compressed headers are used when there is no unpredictable
fields, typically during a talk spurt. In the beginning of a talk changes in header fields, typically during a talk spurt. In the
spurt, compressed header sizes may increase with one or a few bytes beginning of a talk spurt, compressed header sizes may increase by
momentarily. Apart from increases due to new talk spurts, compressed one or a few bytes momentarily. Apart from increases due to new talk
headers may increase in size momentarily due to unpredictable changes spurts, compressed headers may increase in size momentarily due to
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 limit
the number of header sizes used. Padding octets may also be used to the number of header sizes used. Padding octets may also be used to
fill up to a desired size. Chapter 6.3 Implementation parameters in fill up to a desired size. Chapter 6.3 (Implementation parameters) in
[RFC3095] provide optional implementation parameters that make it [RFC3095] provides optional implementation parameters that make it
possible to mandate how a ROHC implementation should operate, for possible to mandate how a ROHC implementation should operate, for
instance to mandate how many header sizes that may be used. 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 have some parameters that needs to be configured in an initial ROHC has some parameters that need to be configured in an initial
setup phase. Which header compression profiles that are allowed may setup phase. Which header compression profiles are allowed may have
have to be determined and also what kind of context identification to be determined and also what kind of context identification (CID)
(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 might
also be desirable to have mechanisms for re-negotiation of these also be desirable to have mechanisms for re-negotiation of these
parameters. parameters.
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
skipping to change at page 6, line 19 skipping to change at page 6, line 19
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 is 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 found
in chapter 4.4 of [RFC3095]. 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 may be
sent. Feedback message consist of small ROHC internal packets without sent. Feedback messages consist of small ROHC internal packets
any application payload. It is possible in ROHC to piggy-back without any application payload. It is possible in ROHC to piggy-back
feedback packets onto regular packets with ROHC compressed headers feedback packets onto regular packets with ROHC compressed headers
and payload, if there is ROHC type of compression in both the forward and payload, if there is ROHC type of compression in both the forward
and reverse direction. However, this piggy-backing may not be desired and reverse direction. However, this piggy-backing may not be desired
or possible in some cases. 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
skipping to change at page 7, line 15 skipping to change at page 7, line 15
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); relocation handover (i.e. the number of consecutive packet losses), and
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 instance,
if soft handover is used and if the header compressor/decompressor if soft handover is used and if the header compressor/decompressor
reside above the combining point for soft handover, there will be no reside above the combining point for soft handover, there will be no
extra packet losses visible to the decompressor due to handover. In extra packet losses visible to the decompressor due to handover. In
hard handovers, where packet loss events due to handover is hard handovers, where packet loss events due to handover is
introduced, the length of the longest consecutive packet loss is most introduced, the length of the longest consecutive packet loss is most
relevant and should thus, be minimized. relevant and should thus 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. Significant in this context relates to the kind of loss packet loss. The term "significant" in this context relates to the
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 no
such mechanism for transferring header compression context between 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 than 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] provide 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 3.2. Unequal error detection (UED)
Chapter 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 codecs.
ROHC does not require UED from lower layers, ROHC requires only a 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. There is thus 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 a unequal error detection scheme where it usable or not. Hence, with an unequal error detection scheme where it
is possible to separate detection of errors in the header and payload is possible to separate detection of errors in the header and payload
part of a packet, more packets may be delivered to applications in part of a packet, more packets may be delivered to applications in
some cases for the same lower layer error rates. The final benefit some cases for the same lower layer error rates. The final benefit
depend of course on the cost of UED for the radio interface and depends of course on the cost of UED for the radio interface and
related protocols. related protocols.
3.3. Unequal error protection 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 packets. 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 depend 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
skipping to change at page 10, line 33 skipping to change at page 10, 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 May 19, 2002. This Internet-Draft expires June 19, 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/