draft-ietf-rohc-rtp-lower-layer-guidelines-00.txt   draft-ietf-rohc-rtp-lower-layer-guidelines-01.txt 
Network Working Group Krister Svanbro, Ericsson Network Working Group Krister Svanbro, Ericsson
INTERNET-DRAFT Sweden INTERNET-DRAFT Sweden
Expires: April 2001 October 10, 2000 Expires: August 2001 February 7, 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-00.txt> <draft-ietf-rohc-rtp-lower-layer-guidelines-01.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 28 skipping to change at page 2, line 28
3.4 Negotiation of header compression parameters..........6 3.4 Negotiation of header compression parameters..........6
3.5 Demultiplexing of flows onto logically 3.5 Demultiplexing of flows onto logically
separated channels..................................6 separated channels..................................6
3.6 Packet type identification............................6 3.6 Packet type identification............................6
3.7 Packet duplication....................................6 3.7 Packet duplication....................................6
3.8 Feedback packets......................................7 3.8 Packet reordering.....................................7
3.9 Feedback packets......................................7
4. Cellular system specific guidelines...........................7 4. Cellular system specific guidelines...........................7
4.1 Handover procedures...................................7 4.1 Handover procedures...................................7
4.2 Unequal error detection...............................8 4.2 Unequal error detection...............................8
4.3 Unequal error protection..............................9 4.3 Unequal error protection..............................9
5. Author's addresses............................................9 5. IANA Considerations...........................................9
6. References...................................................10 6. Security considerations......................................10
7. Author's addresses...........................................10
8. References...................................................10
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
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 and packet type identification may be separated from the
header compression scheme and instead done at underlying link layer. header compression scheme and instead done at underlying link layer.
[RFC2509], for example, elaborates on how to incorporate IP header [RFC2509], for example, elaborates on how to incorporate IP header
skipping to change at page 3, line 36 skipping to change at page 3, line 36
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 system 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 [REQ]. layers, while the requirements on ROHC may be found in [REQ].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
3. General guidelines 3. General guidelines
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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. Un-predictable changes in the RTP, UDP or IP numerous factors. Un-predictable changes in the RTP, UDP or IP
headers may cause compressed headers to momentarily increase in size headers may cause compressed headers to momentarily increase in size
as well as header sizes may depend on packet loss rate at lower as well as header sizes may depend on packet loss rate at lower
layers. Header size distributions depend also on the mode ROHC layers. Header size distributions depend also on the mode ROHC
operate in. However, for e.g. a voice application, carried by operates in. However, for e.g. a voice application, carried by
RTP/UDP/IPv4, with a constant speech frame size and silence RTP/UDP/IPv4, with a constant speech frame size and silence
suppression, the following basic header size changes may be suppression, the following basic header size changes may be
considered as typical: 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 and with sizes depending on basically IP-version. For
IPv4 the size is approximately 40 bytes, and for IPv6 approximately IPv4 the size is approximately 40 bytes, and for IPv6 approximately
60 bytes. The IR/DYN headers are used typically during one round trip 60 bytes. The IR/DYN headers are used typically during one round trip
time, possible interleaved with compressed headers. After that, time, possible interleaved with compressed headers. After that,
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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
[ROHC] provide optional implementation parameters that make it [ROHC] provide 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.
3.4 Negotiation of header compression parameters 3.4 Negotiation of header compression parameters
ROHC have some parameters that needs to be set at an initial setup ROHC has some parameters that needs to be set at an initial setup
phase. Which header compression profile to use may have to be phase. Which header compression profile to use may have to be
determined and also what kind of context identification (CID) determined and also what kind of context identification (CID)
mechanism to use. mechanism to use.
The lower layers supporting ROHC MUST include mechanisms for The lower layers supporting ROHC MUST include mechanisms for
negotiating header compression parameters such as, CID usage and/or negotiating header compression parameters such as, CID usage and/or
header compression profiles. It is RECOMMENDED that the lower layer header compression profiles. It is RECOMMENDED that the lower layer
have mechanisms that support re-negotiations of these parameters. have mechanisms that support re-negotiations of these parameters.
For unidirectional links, this negotiation may be performed out-of-
band or even a priori.
3.5 Demultiplexing of flows onto logically separated channels 3.5 Demultiplexing of flows onto logically separated channels
In some cellular technologies there are a demultiplexing of flows In some cellular technologies there are a demultiplexing of flows
onto radio bearers suitable to the particular flows, i.e., onto onto radio bearers suitable to the particular flows, i.e., onto
logically separated channels. For instance, real-time flows such as logically separated channels. For instance, real-time flows such as
voice and video may be carried on logically separated bearers. It is voice and 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
skipping to change at page 7, line 7 skipping to change at page 7, line 10
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 it is ROHC can handle packet duplication before the compressor but it is
RECOMMENDED that such packet duplications are avoided. Lower layers RECOMMENDED that such packet duplications are avoided. Lower layers
MUST NOT duplicate packets on the path between ROHC compressor and MUST NOT duplicate packets on the path between ROHC compressor and
decompressor. decompressor.
3.8 Feedback packets 3.8 Packet reordering
Lower layers between compressor and decompressor is not assumed to
reorder packets, i.e., the decompressor receives packets in the same
order as the compressor sends them. ROHC handles, however, reordering
before the compression point. That is, there is no assumption that
the compressor will only receive packets in sequence.
3.9 Feedback packets
ROHC consist of three modes; Unidirectional mode (U-mode), ROHC consist of three modes; Unidirectional mode (U-mode),
bidirectional optimistic mode (O-mode) and bidirectional reliable bidirectional optimistic mode (O-mode) and bidirectional reliable
mode (R-mode). A brief description of the modes can be found in mode (R-mode). A brief description of the modes can be found in
chapter 4.4 in [ROHC]. chapter 4.4 in [ROHC].
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 message consist of small ROHC internal packets without
skipping to change at page 8, line 35 skipping to change at page 8, line 45
If the cellular system does not have any internal mechanism for If the cellular system does not have any internal mechanism for
transferring header compression context between nodes, the context transferring header compression context between nodes, the context
relocation may be done by the header compression scheme by means of a relocation may be done by the header compression scheme by means of a
context refresh. The header compression scheme may perform a new context refresh. The header compression scheme may perform a new
header compression initialization, e.g. by sending full headers. This header compression initialization, e.g. by sending full headers. This
will, however, introduce an increase in the average header size will, however, introduce an increase in the average header size
dependent on how often a transfer of context is needed. dependent on how often a transfer of context is needed.
In this latter case, the lower layers MUST indicate to the header In this latter case, the lower layers MUST indicate to the header
compressor that such a handover has occurred, so that it knows when compressor that such a handover has occurred, so that it knows when
to refresh the context. Chapter 6.3 Implementation parameters in to refresh the context. Chapter 6.3 Implementation parameters and
[ROHC] provide optional implementation parameters that make it signals in [ROHC] provide optional implementation parameters that
possible to trigger e.g. a complete context refresh. make it possible to trigger e.g. a complete context refresh.
4.2 Unequal error detection 4.2 Unequal error detection
Chapter 3.1 states that ROHC requires error detection from lower Chapter 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.
skipping to change at page 9, line 17 skipping to change at page 9, line 26
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.
4.3 Unequal error protection 4.3 Unequal error protection
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 packets.
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 depend of course on the cost of UEP for the radio interface and
related protocols. related protocols.
5. Author's Addresses 5. IANA Considerations
A protocol which follows these guidelines, e.g., [ROHC], will require
the IANA to assign various numbers. This document by itself, however,
does not require IANA involvment.
6. Security Considerations
A protocol which follows these guidelines, e.g., [ROHC], must be able
to compress packets containing IPSEC headers according to [REQ].
There may be other sequrity aspects to consider in such protocols.
This document by itself, however, does not add security risks.
7. Author's Addresses
Krister Svanbro Tel: +46 920 20 20 77 Krister Svanbro Tel: +46 920 20 20 77
Box 920 Fax: +46 920 20 20 99 Box 920 Fax: +46 920 20 20 99
Ericsson Erisoft AB Email: krister.svanbro@ericsson.com Ericsson Erisoft AB Email: krister.svanbro@ericsson.com
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
6. References 8. References
[ROHC] Carsten Borman et al, "Robust Header Compression (ROHC)", [ROHC] Carsten Borman et al, "Robust Header Compression (ROHC)",
Internet-Draft (work in progress), October 2000. Internet-Draft (work in progress), February 2001.
<draft-ietf-rohc-rtp-03.txt> <draft-ietf-rohc-rtp-08.txt>
[REQ] Mikael Degermark, "Requirements for robust IP/UDP/RTP [REQ] Mikael Degermark, "Requirements for robust IP/UDP/RTP
header compression", Internet Draft (work in progress), header compression", Internet Draft (work in progress),
June 2000. February 2001.
<draft-ietf-rohc-rtp-requirements-01.txt> <draft-ietf-rohc-rtp-requirements-05.txt>
[RFC1144] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed [RFC1144] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990. Serial Links", RFC 1144, February 1990.
[RFC2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP [RFC2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP
Header Compression", RFC 2507, February 1999. Header Compression", RFC 2507, February 1999.
[RFC2508] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP [RFC2508] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, February Headers for Low-Speed Serial Links", RFC 2508, February
1999. 1999.
 End of changes. 

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