Request for Comments: 3759 Ericsson
Updates: 3095 April 2004
Category: Informational
RObust Header Compression (ROHC):
Terminology and Channel Mapping Examples
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document aims to clarify terms and concepts presented in RFC
3095. RFC 3095 defines a Proposed Standard framework with profiles
for RObust Header Compression (ROHC). The standard introduces
various concepts which might be difficult to understand and
especially to relate correctly to the surrounding environments where
header compression may be used. This document aims at clarifying
these aspects of ROHC, discussing terms such as ROHC instances, ROHC
channels, ROHC feedback, and ROHC contexts, and how these terms
relate to other terms, like network elements and IP interfaces,
commonly used, for example, when addressing MIB issues.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ROHC External Terminology. . . . . . . . . . . . . . . . . . . 6
3.1. Network Elements and IP Interfaces . . . . . . . . . . . 6
3.2. Channels . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. A Unidirectional Point-to-Point Link Example . . . . . . 8
3.4. A Bi-directional Point-to-Point Link Example . . . . . . 8
3.5. A Bi-directional Multipoint Link Example . . . . . . . . 9
3.6. A Multi-Channel Point-to-Point Link Example. . . . . . . 9
4. ROHC Instances . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. ROHC Compressors . . . . . . . . . . . . . . . . . . . . 11
4.2. ROHC Decompressors . . . . . . . . . . . . . . . . . . . 12
5. ROHC Channels. . . . . . . . . . . . . . . . . . . . . . . . . 13
6. ROHC Feedback Channels . . . . . . . . . . . . . . . . . . . . 14
6.1. Single-Channel Dedicated ROHC FB Channel Example . . . . 14
6.2. Piggybacked/Interspersed ROHC FB Channel Example . . . . 15
6.3. Dual-Channel Dedicated ROHC FB Channel Example . . . . . 16
7. ROHC Contexts. . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Implementation Implications. . . . . . . . . . . . . . . . . . 18
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . . 19
13. Author’s Address . . . . . . . . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
1. Introduction
In RFC 3095, the RObust Header Compression (ROHC) standard framework
is defined, along with 4 compression profiles [RFC-3095]. Various
concepts are introduced within the standard that are not all very
extensively defined and described, which can easily be an obstacle
when trying to understand the standard. This can especially be the
case when one considers how the various parts of ROHC relate to the
surrounding environments where header compression may be used.
The purpose of this document is to clarify these aspects of ROHC
through examples and additional terminology, discussing terms such as
ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts.
This especially means to clarify how these terms relate to other
terms, such as network elements and IP interfaces, which are commonly
used for example when addressing MIB issues. One explicit goal of
this document is to support and simplify the ROHC MIB development
work.
The main part of this document, sections 3 to 8, focuses on
clarifying the conceptual aspects, entity relationships, and
terminology of ROHC [RFC-3095]. Section 9 explains some
implementation implications that arise from these conceptual aspects.
2. Terminology
ROHC instance
A logical entity that performs header compression or decompression
according to one or several ROHC profiles can be referred to as a
ROHC instance. A ROHC instance is either a ROHC compressor
instance or a ROHC decompressor instance. See section 4.
ROHC compressor instance
A ROHC compressor instance is a logical entity that performs
header compression according to one or several ROHC profiles.
There is a one-to-one relation between a ROHC compressor instance
and a ROHC channel, where the ROHC compressor is located at the
input end of the ROHC channel. See section 4.1.
ROHC decompressor instance
A ROHC decompressor instance is a logical entity that performs
header decompression according to one or several ROHC profiles.
There is a one-to-one relation between a ROHC decompressor
instance and a ROHC channel, where the ROHC decompressor is
located at the output end of the ROHC channel. See section 4.2.
Corresponding decompressor
When talking about a compressor’s corresponding decompressor, this
refers to the peer decompressor located at the other end of the
ROHC channel to which the compressor sends compressed header
packets, i.e., the decompressor that decompresses the headers
compressed by the compressor.
Corresponding compressor
When talking about a decompressor’s corresponding compressor, this
refers to the peer compressor located at the other end of the ROHC
channel from which the decompressor receives compressed header
packets, i.e., the compressor that compresses the headers the
decompressor decompresses.
ROHC peers
A ROHC compressor and its corresponding ROHC decompressor are
referred to as ROHC peers.
Link
A communication path between two network entities is, in this
document, generally referred to as a link.
Bi-directional compression
If there are means to send feedback information from a
decompressor to its corresponding compressor, the compression
performance can be improved. This way of operating, utilizing the
feedback possibility for improved compression performance, is
referred to as bi-directional compression.
Unidirectional compression
If there are no means to send feedback information from a
decompressor to its corresponding compressor, the compression
performance might not be as good as if feedback could be utilized.
This way of operating, without making use of feedback for improved
compression performance, is referred to as unidirectional
compression.
ROHC channel
When a ROHC compressor has transformed original packets into ROHC
packets with compressed headers, these ROHC packets are sent to
the corresponding decompressor through a logical point-to-point
connection dedicated to that traffic. Such a logical channel,
which only has to carry data in this single direction from
compressor to decompressor, is referred to as a ROHC channel. See
section 5.
ROHC feedback channel
To allow bi-directional compression operation, a logical point-
to-point connection must be provided for feedback data from the
decompressor to its corresponding compressor. Such a logical
channel, which only has to carry data in the single direction from
decompressor to compressor, is referred to as a ROHC feedback
channel. See section 6.
Co-located compressor/decompressor
A minimal ROHC instance is only a compressor or a decompressor,
communicating with a corresponding decompressor or compressor peer
at the other end of a ROHC channel, thus handling packet streams
sent in one direction over the link. However, in many cases, the
link will carry packet streams in both directions, and it would
then be desirable to also perform header compression in both
directions. That would require both a ROHC compressor and a ROHC
decompressor at each end of the link, each referred to as a co-
located compressor/decompressor pair.
Associated compressor/decompressor
If there is a co-located ROHC compressor/decompressor pair at each
end of a link, feedback messages can be transmitted from a ROHC
decompressor to its corresponding compressor by creating a virtual
ROHC feedback channel among the compressed header packets sent
from the co-located ROHC compressor to the decompressor co-located
with the compressor at the other end. When a co-located ROHC
compressor/decompressor pair is connected for this purpose, they
are said to be associated with each other.
Interspersed feedback
Feedback from a ROHC decompressor to a ROHC compressor can either
be sent on a separate ROHC feedback channel dedicated to feedback
packets, or sent among compressed header packets going in the
opposite direction from a co-located (associated) compressor to a
similarly co-located decompressor at the other end of the link.
If feedback packets are transmitted in the latter way and sent as
stand-alone packets, this is referred to as interspersed feedback.
See section 6.2 for an example.
Piggybacked feedback
Feedback from a ROHC decompressor to a ROHC compressor can either
be sent on a separate ROHC feedback channel dedicated to feedback
packets, or sent among compressed header packets going in the
opposite direction from a co-located (associated) compressor to a
similarly co-located decompressor at the other end of the link.
If feedback packets are transmitted in the latter way and sent
encapsulated within compressed header packets going in the other
direction, this is referred to as piggybacked feedback. See
section 6.2 for an example.
Dedicated feedback channel
A dedicated feedback channel is a logical layer two channel from a
ROHC decompressor to a ROHC compressor, used only to transmit
feedback packets. See sections 6.1 and 6.3 for examples.
3. ROHC External Terminology
When considering aspects of ROHC that relate to the surrounding
networking environment where header compression may be applied,
unnecessary confusion is easily created because a common, well
understood, and well defined, terminology is missing. One major goal
with this document is to define the preferred terminology to use when
discussing header compression network integration issues.
3.1. Network Elements and IP Interfaces
Header compression is applied over certain links, between two
communicating entities in a network. Such entities may be referred
to as "nodes", "network devices", or "network elements", all terms
usually having the same meaning. However, practice within the area
of network management favors using the term "network element", which
is therefore consistently used throughout the rest of this document.
A network element communicates through one or several network
interfaces, which are often subject to network management, as defined
by MIB specifications. In all IP internetworking, each such
interface has its own IP identity, providing a common network
interface abstraction, independent of the link technology hidden
below the interface. Throughout the rest of this document, such
interfaces will be referred to as "IP interfaces".
Thus, to visualize the above terms, the top level hierarchy of a
network element is as follows, with one or several IP interfaces:
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
+---------------+ +---------------+ ...
The next section builds on this top level hierarchy by looking at
what is below an IP interface.
3.2. Channels
As mentioned in the previous section, an IP interface can be
implemented on top of almost any link technology, although different
link technologies have different characteristics, and provide
communication by different means. However, all link technologies
provide the common capability to send and/or receive data to/from the
IP interface. A generic way of visualizing the common ability to
communicate is to envision it as one or several logical communication
channels provided by the link, where each channel can be either bi-
directional or unidirectional. Such logical point-to-point
connections will, throughout the rest of this document, be referred
to as "channels", either bi-directional or unidirectional. Note that
this definition of "channels" is less restrictive than the definition
of "ROHC channels", as given in section 5.
Extending the above network element hierarchy with the concept of
channels would then lead to the following:
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
++ +-+ +-+ +----+ ++ +-+ +-+ +----+ ...
|C| |C| |C| |C| |C| |C|
|h| |h| |h| |h| |h| |h|
|a| |a| |a| |a| |a| |a|
|n| |n| |n| ... |n| |n| |n| ...
|n| |n| |n| |n| |n| |n|
|e| |e| |e| |e| |e| |e|
|l| |l| |l| |l| |l| |l|
: : : : : : : : : : : :
Whether there is more than one channel, and whether the channel(s)
is/are bi-directional or unidirectional (or a mix of both) is link
technology dependent, as is the way in which channels are logically
created.
The following subsections, 3.3-3.6, give a number of different link
examples, and relate these to the general descriptions above.
Further, each section discusses how header compression might be
applied in that particular case. The core questions for header
compression are:
- Are channels bi- or unidirectional?
- Is the link point-to-point? If not, a lower layer addressing
scheme is needed to create logical point-to-point channels.
Note that these subsections talk about header compression in general,
while later sections will address the case of ROHC in more detail.
Further, one should remember that in the later sections, the general
channel definition is slightly enhanced for header compression by the
definition of the ROHC channel (section 5) and the ROHC feedback
channel (section 6), while here the basic channel concept is used, as
defined above.
3.3. A Unidirectional Point-to-Point Link Example
The simplest possible link example one can derive from the general
overview above is the case with one single unidirectional channel
between two communicating network elements.
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| -> Unidirectional channel -> |
+----------------------------------------+
A typical example of a point-to-point link with one unidirectional
channel like this is a satellite link. Since there is no return path
present, only unidirectional header compression can be applied here.
3.4. A Bi-directional Point-to-Point Link Example
Taking the above example one step further, the natural extension
would be an example with one single bi-directional channel between
two communicating network elements. In this example, there are still
only two endpoints and one single channel, but the channel is simply
enhanced to allow bi-directional communication.
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| <-> Bi-directional channel <-> |
+----------------------------------------+
A typical example of a point-to-point link with such a bi-directional
channel is a PPP modem connection over a regular telephone line.
Header compression can easily be applied here as well, as is usually
done over e.g., PPP, and the compression scheme can make use of the
return path to improve compression performance.
3.5. A Bi-directional Multipoint Link Example
Leaving the simple point-to-point link examples, this section
addresses the case of a bi-directional link connecting more than two
communicating network elements. To simplify the example, the case
with three endpoints is considered.
+-----------------+ +-----------------+ +-----------------+
| Network Element | | Network Element | | Network Element |
+-----------------+ +-----------------+ +-----------------+
| IP | | IP | | IP |
| Interface | | Interface | | Interface |
+------+ +------+ +------+ +------+ +------+ +------+
| | | | | |
| | | | | |
| +-----------------+ +-----------------+ |
| <-> Bi-directional "shared channel" <-> |
+-----------------------------------------------+
A typical example of a multipoint link with such a bi-directional
"shared channel" is an Ethernet. Since the channel is shared,
applying header compression would require a lower layer addressing
scheme to provide logical point-to-point channels, according to the
definition of "channels".
As an aside, it should be noted that a case of unidirectional
multipoint links is basically the same as a number of unidirectional
point-to-point links. In such a case, each receiver only sees one
single sender, and the sender’s behavior is independent of the number
of receivers and is unaffected by their behavior.
3.6. A Multi-Channel Point-to-Point Link Example
This final example addresses a scenario which is expected to be
typical in many environments where ROHC will be applied. The key
point of the example is the multi-channel property, which is common
in, for example, cellular environments. Data through the same IP
interface might here be transmitted on different channels, depending
on its characteristics. In the following example, there are three
channels present, one bi-directional, and one unidirectional in each
direction, but the channel configuration could of course be
arbitrary.
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+-+ +---+ +---+ +-+ +-+ +---+ +---+ +-+
| | | | | | | | | | | |
| | | | | +--------------------------+ | | | | |
| | | | | <- Unidirectional channel <- | | | | |
| | | | +------------------------------+ | | | |
| | | | | | | |
| | | | | | | |
| | | +--------------------------------------+ | | |
| | | <-> Bi-directional channel <-> | | |