Network Working Group Lars-Erik Jonsson
INTERNET-DRAFT Krister Svanbro
Expires: February 2001 Hans Hannu
Ericsson, Sweden
August 23, 2000
Profiles and Parameters in ROHC
<draft-jonsson-rohc-profiles-00.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
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
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
The RObust Header Compression WG (ROHC) is developing compression
schemes initially for IP/UDP/RTP header compression [ROHC]. The group
is also chartered to develop compression for IP/TCP and after re-
chartering it is possible (probable) that also compression of other
protocols will follow. Compression and decompression must always
follow well defined rules but there exist a number of variables that
will affect details in the way compression should be carried out and
how these rules are set. The purpose of this document is to identify
such variables and outline a way to make ROHC both adaptable to
various conditions and possible to extend for future needs.
Jonsson, Svanbro, Hannu [Page 1]
INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000
Table of contents
1. Introduction..................................................3
2. A profile concept.............................................3
3. Variables for scheme adaptation...............................4
3.1. Size of context identifier (CID).......................4
3.2. IP version, 4 or 6.....................................5
3.3. Transport protocol.....................................5
3.4. Checksum presence in UDP (IPv4 only)...................5
3.5. Use of timer-based timestamp compression...............6
3.6. Compression of application protocols...................6
3.7. Future needs...........................................6
4. Parameters to negotiate by link layer.........................7
5. Proposed FH structure.........................................7
6. List of possible profiles and additional parameters...........8
7. Other considerations..........................................8
8. Conclusions...................................................9
9. References...................................................10
10. Authors addresses............................................10
Jonsson, Svanbro, Hannu [Page 2]
INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000
1. Introduction
The RObust Header Compression WG (ROHC) is developing compression
schemes initially for IP/UDP/RTP header compression [ROHC]. These
first outcomes from the WG are expected during 2000 and is already
chosen by cellular communities to be part of year 2000 standards.
ROHC is further chartered to develop compression also for IP/TCP and
after re-chartering it is probable that other protocols, mainly
application protocols, will follow.
Compression and decompression must always follow well defined and
standardized rules. However, even if probably the general ROHC
principles of today for how to do header compression will be
applicable also in the future, there exist a number of variables
that will affect details in the way compression should be carried
out.
The purpose of this document is to identify such variables, analyze
them and propose how ROHC adaptation should be carried out for each
of them. A profile concept is proposed to handle some of the
variations, profile specific parameters are proposed to handle others
and finally link layer negotiations are proposed for a few channel
specific issues.
In chapter 2, the profile concept is defined. Chapter 3 lists and
analyses the various variables for scheme adaptation and concludes
about how to treat each of them. In chapter 4, a full header base
structure is proposed and in chapter 6 some possible profiles are
listed to exemplify the concept. Finally, chapter 6 summarizes what
is left for negotiation on the link layer and chapter 7 mentions some
additional considerations. Conclusions may be found in chapter 8.
2. A profile concept
This chapter proposes a definition of ROHC profiles to be used in the
ROHC scheme. The profile concept proposed here is derived from the
ROCCO [ROCCO] profiles with modifications due to experiences from
that work and comments from various people involved in ROHC.
A profile is a context specific parameter which explicitly defines
the kind of packet stream compressed within the context, the packet
formats used and the exact details of compression and decompression
logic. For each context present on a channel, one profile is used to
compress the packet stream corresponding to that context. The same
profile may be used for all context but there may also be as many
different profiles as the number of active contexts.
Profiles are identified with a profile identifier which is proposed
to be an 8-bit value where the first bit is set to 0. If the first
bit is set to one, the profile number is extended to 2 octets. This
Jonsson, Svanbro, Hannu [Page 3]
INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000
would give 128 possible profiles identified with 1 octet and 32768
with 2 octets. 128 is expected to be sufficient but by allowing an
extended range the solution is not limiting the possibilities for
future needs.
One of the most important property of a profile is the protocols that
are compressed with that profile. There may be many different
combinations, more or less specialized, and a few examples of
possible profiles can be seen in chapter 5. Note that there may exist
several profiles that compress the same set of headers in different
ways.
In addition to what is unambiguous defined for a profile, the profile
itself may have additional parameters that are set as part of the
compression logic using the packet formats defined for that profile.
3. Variables for scheme adaptation
There are several variables that will affect both packet formats and
compression/decompression logic. This chapter lists and analyses the
parameters that have been identified during the ROCCO work and in the
discussions following that work. The variables identified are:
- Size of context identifier
- IP version, 4 or 6
- Transport protocols
- Checksum presence in UDP
- Use of timer-based timestamp compression
- Compression of application protocols
- Future needs
The analysis carried out below aims at deciding whether it makes
sense to have a parameter included in what is defined by the profile
identifier or if a parameter should be handled by other means.
3.1. Size of context identifier (CID)
Header compression removes the per packet information used to
identify and separate the packet streams, addresses, port numbers
and, for RTP, the SSRC identifier. It is therefore necessary to add
some other mechanism to get this functionality, which is normally a
field in the beginning of all packets sent over the channel called
the context identifier or CID. The CID and its size are thus channel
parameters that must be well defined and CID must be present in all
packets sent over the channel. Since the CID size should be variable
from channel to channel it is easiest to have a CID size of whole
octets, zero, one or several. Also, since the CID must be well
defined for all packets, it is natural to put the CID in the
beginning of each packet. The CID size must thus be known a priori
Jonsson, Svanbro, Hannu [Page 4]
INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000
and should therefore be either pre-configured for the link or
negotiated (compressor->decompressor) when the channel is
established.
3.2. IP version, 4 or 6
Since IP version 4 differs from IP version 6 in a number of ways,
also header compression will differ. Even if IPv4 and IPv6 packets
will probably not appear at the same place, it could happen and IP
version would then be a context specific property. There exist thus
at least two possible ways to handle this variation in header
compression characteristic. Either the IP version field is included
in the compressed full header as it appears in the original header or
implicitly defined by different profiles. Both ways would work, but
if it is explicitly indicated all profiles must have support for both
IPv4 and IPv6 which would be a significant disadvantage especially in
the future. The best flexibility would thus be provided if different
profiles are defined for IPv4 and IPv6, i.e. IP version becomes part
of what is defined by a profile.
3.3. Transport protocol
The same ideas as for the IP version applies also to the transport
protocol issue. However, the disadvantages of having it explicitly
indicated in the compressed full headers are even more significant.
First of all, the requirement to have all profiles support all
existing transport protocols is even more undesirable since there are
major differences between the transport protocols and standardization
of the compression schemes is naturally separate issues (as in ROHC
right now). New transport protocols will probably also appear in the
future which makes it impossible for all profiles to support all
transport protocols. This means that also the transport protocol
support variable becomes a part of what is defined by a profile.
3.4. Checksum presence in UDP (IPv4 only)
In IPv4, it is possible to disable the UDP checksum. If the checksum
is disabled, it will probably be so for all packets belonging to the
same packet stream. If it is disabled, header compression would
benefit from that since the checksum does not have to be transmitted
over the link. The compressed header formats will therefore differ
based on whether the checksum is enabled or disabled. Presence of the
UDP checksum will thus be a context specific parameter. However,
since this parameter is specific to UDP for IPv4, it does not suite
the purpose of the profile concept but should instead be a profile
specific parameter for all profiles compressing UDP over IPv4.
Jonsson, Svanbro, Hannu [Page 5]
INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000
3.5. Use of timer-based timestamp compression
For certain real-time specific header compression schemes, usage of
timers or wall clocks could improve the compression performance
significantly. However, a compression scheme should never be designed
to require such functionality and the usage must therefore be an
option for compression enhancements. That would thus be a profile
specific parameter for profiles that make use of such mechanisms,
e.g. profiles for compression of RTP headers.
3.6. Compression of application protocols
Compression of application protocol headers is a difficult task since
the presence of application protocols are not explicitly indicated in
the original packet headers. The only things that are told explicitly
are IP version and which transport protocol that is used. This makes
it hard to decide whether a packet stream is IP/UDP/RTP or IP/UDP and
choose the appropriate compression scheme. In RFC2508 [CRTP], RTP is
always assumed for all UDP streams and if the compression ratio gets
low the scheme falls back to compression of IP/UDP only. This method
works if RTP is the only possible application protocol. However, the
number of application protocols in use is increasing and the method
used in RFC2508 can therefore not be applied for all possible
application protocol combinations.
As mentioned above, the task of deciding what protocols to compress
if application protocols are present is difficult. It should
therefore be treated as an issue separate from ROHC and ROHC should
not make any assumptions about this. Instead, ROHC should define
compression profiles for various protocol combinations and methods
for how to switch profile for a context.
3.7. Future needs
In the short term, ROHC will standardize IP/UDP/RTP header
compression. The charter of ROHC also includes compression for IP/TCP
and more schemes are expected to follow. It is therefore important
that ROHC becomes flexible and general so that new variations of the
scheme can be added, utilizing the common header compression parts.
Especially since it should not only be possible to handle the
protocols known today, but also those that will appear in the future.
Future link layers may also look different and put new or different
requirements on header compression, meaning that new profiles must be
added to compress the same protocols in a different way to get a
certain desired behavior. By having the profile identifier, ROHC will
get flexibility to add new variations both for existing protocols,
future new protocols and future new requirements on compression of
today's protocols.
Jonsson, Svanbro, Hannu [Page 6]
INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000
4. Parameters to negotiate by link layer
For the link layer, only two parameters must be negotiated between
compressor and decompressor:
- Size of context identifier (CID)
The CID is 0, 8 or 16 bits and the desired size must either
be pre-configured or communicated when channel is established
between compressor and decompressor. CID size should normally
be communicated from compressor to decompressor.
- Profile capabilities
The profile identifier is an 8-bit number (may be extended to
16 bits) that unambiguously defines how header compression is
carried out. However, both compressor and decompressor must
support a certain profile to be able to use it. Since the
compressor will decide what profile to use, it must know which
profiles are supported by the decompressor. As for the CID,
profile support might be pre-configured but normally it should
be communicated from decompressor to compressor when the
channel is established.
5. Proposed full header (FH) structure
Since the profile to use for a certain context is specified in the
initial full headers of a new compressed packet stream, the beginning
of the full header format must be common for all profiles. If
multiple contexts are supported, the CID must be unambiguously
defined for all packet formats in all profile. All profiles must also
have a common packet type identifier and profile number field for the
full header format. The figure below shows a schematic figure of the
proposed full header format.
+...+...+...+...+...+...+...+...+
: CID : 0-2 octets
+---+---+---+---+---+---+---+---+
| Full Header Packet Type | 1 octet
+---+---+---+---+---+---+---+---+
| Profile Number | 1 octet
+---+---+---+---+---+---+---+---+
| Profile specific full header | Example: Profiles for UDP in
: structure including profile : IPv4 will have a
: specific parameters. The : checksum presence
: structure may be affected : flag and if set the
: by the values of the profile : checksum will also
| specific parameters. | be in the structure.
+---+---+---+---+---+---+---+---+
Jonsson, Svanbro, Hannu [Page 7]
INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000
6. List of possible profiles and additional parameters
This section exemplifies the profile concept by listing some possible
profiles that will be defined with proposed profile numbers. Profile
specific parameters, as described in previous sections of this
document, are also listed.
+---------+----------------------+----------------------------------+
| Profile | Compressed protocols | Additional parameters |
+---------+----------------------+----------------------------------+
| 0* | All, uncompressed | - |
| 1 | IPv4 only | - |
| 2 | IPv6 only | ? |
| 3* | IPv4/UDP | Checksum on/off |
| 4* | IPv6/UDP | - |
| 5** | IPv4/TCP | ? |
| 6** | IPv6/TCP | ? |
| 7* | IPv4/UDP/RTP | Checksum on/off, Timer-based TS |
| 8* | IPv6/UDP/RTP | Timer-based TS |
| .. | | |
+---------+----------------------+----------------------------------+
* Will be defined by ROHC during 2000
** Will be defined by ROHC during 2001
7. Other considerations
The profile number space becomes very important for ROHC and must be
controlled on good authority. Assignment of profile numbers should
therefore be made by the IANA.
Jonsson, Svanbro, Hannu [Page 8]
INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000
8. Conclusions
This document has discussed how to make ROHC adaptable to various
variation needs regarding what to compress and how to compress. A
solution based on a combination of link layer negotiations, ROHC
profiles and profile specific parameters has been proposed. The main
arguments in favor of the proposed solution are the ones listed
below.
# By defining context specific profiles in ROHC:
- Standardization can be done step-wise but the original
framework of ROHC can be reused.
- ROHC will become expandable to future needs both for new
solutions to handle today's protocols and also for new
protocols.
- It would be easy to switch from one profile to another for
the same context, since profile type is established by
in-band signaling in full headers.
# There will be only two parameters to negotiate by link layer:
- Size of context identifier (compressor -> decompressor)
- Profile capabilities (decompressor -> compressor)
# The number of profiles is reduced by having profile specific
parameters for some profiles (e.g. presence of checksum in UDP)
Jonsson, Svanbro, Hannu [Page 9]
INTERNET-DRAFT Profiles and Parameters in ROHC August 23, 2000
9. References
[CRTP] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, February 1999.
[ROHC] Carsten Bormann, et.al., "Robust Header Compression (ROHC)",
Internet Draft (work in progress), July 2000.
<draft-ietf-rohc-rtp-01.txt>
[ROCCO] Lars-Erik Jonsson, Mikael Degermark, Hans Hannu, Krister
Svanbro, "RObust Checksum-based header COmpression (ROCCO)",
Internet Draft (work in progress), June 2000.
<draft-ietf-rohc-rtp-rocco-01.txt>
10. Authors addresses
Lars-Erik Jonsson Tel: +46 920 20 21 07
Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 EMail: lars-erik.jonsson@ericsson.com
SE-971 28 Lulea, Sweden
Krister Svanbro Tel: +46 920 20 20 77
Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 EMail: krister.svanbro@ericsson.com
SE-971 28 Lulea, Sweden
Hans Hannu Tel: +46 920 20 21 84
Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920 EMail: hans.hannu@ericsson.com
SE-971 28 Lulea, Sweden
This Internet-Draft expires February 23, 2001.
Jonsson, Svanbro, Hannu [Page 10]