Network Working Group Lars-Erik Jonsson
INTERNET-DRAFT Ericsson
Expires: December 2002 June 14, 2002
RObust Header Compression (ROHC): The ROHC Architecture
<draft-jonsson-rohc-architecture-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
RFC 3095 defines a Proposed Standard framework with profiles for
RObust Header Compression (ROHC). Various concepts are introduced
within the standard, which might be difficult to understand, and
especially how these relate to the surrounding environments where
header compression may be used. This document aims at clarifying the
architectural aspects of ROHC, discussing terms such as ROHC
instances, ROHC channels, ROHC feedback, ROHC contexts, and how these
terms relate to other terms like network elements and IP interfaces,
commonly used when for example addressing MIB issues.
Jonsson [Page 1]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
Table of Contents
1. Introduction..................................................2
2. ROHC External Terminology.....................................3
2.1. Network Elements and IP Interfaces.....................3
2.2. Channels...............................................3
2.3. A Unidirectional Point-to-Point Link Example...........4
2.4. A Bi-directional Point-to-Point Link Example...........5
2.5. A Bi-directional Multipoint Link Example...............5
2.6. A Multi-Channel Point-to-Point Link Example............6
3. ROHC Instances................................................7
3.1. ROHC Compressors.......................................8
3.2. ROHC Decompressors.....................................8
4. ROHC Channels.................................................9
5. ROHC Feedback Channels.......................................10
5.1. Single-Channel Dedicated ROHC FB Channel Example......11
5.2. Piggybacked/Interspersed ROHC FB Channel Example......11
5.3. Dual-Channel Dedicated ROHC FB Channel Example........12
6. ROHC Contexts................................................13
7. Implementation Implications..................................14
8. Security Considerations......................................15
9. Acknowledgements.............................................15
10. References..................................................15
11. Author's Address............................................15
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, which might not all be
very extensively defined and described, and that can easily be an
obstacle when trying to understand the standard. This can especially
be the case when one consider 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 the architectural aspects
of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC
feedback, 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 when for example addressing MIB
issues. One explicit goal with this document is to support and
simplify the MIB development work for ROHC.
The main part of this document, section 2 to 6, focuses on clarifying
the conceptual aspects, entity relationships, and terminology of ROHC
[RFC-3095]. After that, section 7 explains some implementation
implications that arise from these conceptual aspects.
Jonsson [Page 2]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
2. 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.
2.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, practices within the area
of network management recommends to use the term "network element",
which is therefore consistently used throughout the rest of this
document.
A network element is communicating 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".
To visualize the above terms, the top level hierarchy at a network
element will thus be the following, with 1 or several IP interfaces:
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
+---------------+ +---------------+ ...
The next section further builds on this top level hierarchy by
looking at what is below an IP interface.
2.2. Channels
As mentioned in 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 communication
Jonsson [Page 3]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
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 4.
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 well as the way channels are logically
created.
The following subsection 2.3-2.6 gives 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 the general channel definition is
slightly enhanced for header compression by the definition of ROHC
channels (see section 4) and ROHC feedback channels (see section 5).
2.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.
Jonsson [Page 4]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
+-----------------+ +-----------------+
| 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 here be applied.
2.4. A Bi-directional Point-to-Point Link Example
Starting from the example above, the natural next step example would
be one with one single bi-directional channel between two
communicating network elements. In this example, we still have just
two endpoints and one single channel, it is just 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 one bi-directional
channel like this is a PPP modem connection over a regular telephone
line. Header compression can easily be applied here as well, as
usually done over e.g. PPP, and the compression scheme can utilize
the return path to improve compression performance.
2.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 between more than two
communicating network elements. To simplify the example, the case
with three endpoints is used.
Jonsson [Page 5]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
+-----------------+ +-----------------+ +-----------------+
| Network Element | | Network Element | | Network Element |
+-----------------+ +-----------------+ +-----------------+
| IP | | IP | | IP |
| Interface | | Interface | | Interface |
+------+ +------+ +------+ +------+ +------+ +------+
| | | | | |
| | | | | |
| +-----------------+ +-----------------+ |
| <-> Bi-directional "shared channel" <-> |
+-----------------------------------------------+
A typical example of a multipoint link with a bi-directional "shared
channel" like this 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 a side point, it should be noted that a case of unidirectional
multipoint links is basically the same as a number of unidirectional
point-to-point links. For receivers, there is only one single sender,
and the sender is not at all affected by the receivers.
2.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 applied. The key point
with 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
characteristics. In this example, there are three channels present,
one bi-directional, and one unidirectional in each direction, but the
channel configuration could of course be arbitrary.
Jonsson [Page 6]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+-+ +---+ +---+ +-+ +-+ +---+ +---+ +-+
| | | | | | | | | | | |
| | | | | +--------------------------+ | | | | |
| | | | | <- Unidirectional channel <- | | | | |
| | | | +------------------------------+ | | | |
| | | | | | | |
| | | | | | | |
| | | +--------------------------------------+ | | |
| | | <-> Bi-directional channel <-> | | |
| | +------------------------------------------+ | |
| | | |
| | | |
| +--------------------------------------------------+ |
| -> Unidirectional channel -> |
+------------------------------------------------------+
As mentioned above, a typical example of a multi-channel link is a
cellular wireless link. In this example, header compression would be
applicable on a per-channel basis, for each channel operating either
in a bi-directional or unidirectional manner, depending on the
channel properties.
3. ROHC Instances
For e.g. the purpose of network management on an IP interface
implementing ROHC, it is necessary to identify the various ROHC
entities that might be present on an interface. Such a minimal ROHC
entity will from now on be referred to as a "ROHC instance". A ROHC
instance can be one of two different types, either a "ROHC
compressor" or a "ROHC decompressor" instance, and an IP interface
can have N ROHC compressors and M ROHC decompressors, where N and M
are arbitrary numbers. It should be noted that although a compressor
is often co-located with a decompressor, a ROHC instance can never
include both a compressor and a decompressor, but they will then be
referred to as two ROHC instances.
The following two subsections describe the two kinds of ROHC
instances and their external interfaces, while sections 4 and 5
address how communication over these interfaces is realized through
"ROHC channels" and "ROHC feedback channels". Section 6 builds on top
of the instance, channel and feedback channel concepts and clarifies
how ROHC contexts map to this.
Jonsson [Page 7]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
3.1. ROHC Compressors
A ROHC compressor instance supports header compression according to
one or several ROHC profiles. Apart from potential configuration or
control interfaces, a compressor instance receives and sends data
through 3 inputs and 1 output, as illustrated by the figure below:
+--------------+
-> UI -> | | -> CO ->
| ROHC |
| Compressor |
-> PI -> | | <- FI <-
+--------------+
Uncompressed Input (UI): Uncompressed packets are delivered from
higher layers to the compressor through
the UI.
Compressed Output (CO): Compressed packets are sent from the
compressor through the CO, which is always
connected to the input end of a ROHC
channel (see section 4).
Feedback Input (FI): Feedback from the decompressor at the
other end of the channel is received
by the compressor through the FI, which
(if present) is connected to the output
end of a ROHC feedback channel of some
kind (see section 5). When a ROHC feedback
channel is not available, bi-directional
compression will not be possible.
Piggyback Input (PI): If the compressor is associated with a
co-located decompressor, for which the
compressor delivers feedback to the
other end of the channel, feedback data
for piggybacking is delivered to the
compressor through the PI. If this input
is used, it is connected to the FO of the
co-located decompressor (see section 3.2).
3.2. ROHC Decompressors
A ROHC decompressor instance supports header decompression according
to one or several ROHC profiles. Apart from potential configuration
or control interfaces, a decompressor instance receives and sends
data through 1 input and 3 outputs, as illustrated by the figure
below:
Jonsson [Page 8]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
+--------------+
-> CI -> | | -> DO ->
| ROHC |
| Decompressor |
<- FO <- | | -> PO ->
+--------------+
Compressed Input (CI): Compressed packets are received by the
decompressor through the CI, which is
always connected to the output end of a
ROHC channel (see section 4).
Decompressed Output (DO): Decompressed packets are delivered from
the decompressor to higher layers through
the DO.
Feedback Output (FO): Feedback to the compressor at the other
end of the channel is sent through the
FO, which (if present) is connected to
the input end of a ROHC feedback channel
of some kind (see section 5). When a ROHC
feedback channel is not available, bi-
directional compression will not be
possible.
Piggyback Output (PO): If the decompressor is associated with
a co-located compressor, to which the
decompressor delivers feedback it
receives piggybacked from the other end
of the channel, the received feedback
data is delivered from the decompressor
through the PO. If this output is used,
it is connected to the FI of the co-
located compressor (see section 3.1).
4. ROHC Channels
In section 2, a general concept of channels was introduced. According
to that definition, a channel is basically a logical point-to-point
connection between IP interfaces at two communicating network
elements. By that definition, a channel represents the kind of
logical connection needed to make header compression generally
applicable, and then the channel properties control whether
compression can operate in a unidirectional or bi-directional manner.
The channel concept thus facilitates general header compression
discussions, but since it groups unidirectional and bi-directional
connections together it does not provide the means for describing
details of the logical ROHC design. Therefore, for the case of ROHC,
Jonsson [Page 9]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
the channel concept is enhanced and a more restricted concept of
"ROHC channels" is defined.
A ROHC channel has exactly the same properties as a channel, but with
the difference that a ROHC channel always is unidirectional. A ROHC
channel therefore has one single input endpoint, connected to the CO
of one single ROHC compressor instance, and one single output
endpoint, connected to the CI of one single ROHC decompressor
instance. A ROHC channel must thus in this way be logically dedicated
to one ROHC compressor/decompressor pair, hereafter referred to as
ROHC peers, creating a one-to-one mapping between a ROHC channel and
a pair of ROHC compressor/decompressor instances.
+--------------+ --->-->-->-->--- +--------------+
| | -> CO -> ROHC Channel -> CI -> | |
| ROHC | --->-->-->-->--- | ROHC |
| Compressor | | Decompressor |
| | | |
+--------------+ +--------------+
Of course, in many cases the channel is by nature bi-directional, but
for ROHC communication over that channel, a ROHC channel would only
represent one communication direction of the channel. For bi-
directional channels, a common case would be to logically allocate
one ROHC channel in each direction, allowing ROHC compression to be
performed in two directions. The reason for defining ROHC channels as
unidirectional is basically to separate and generalize the concept of
feedback, as described and exemplified in section 5.
5. ROHC Feedback Channels
Since ROHC can be implemented over various kind of links,
unidirectional or bi-directional one-channel links as well as multi-
channel links, the logical transmission of feedback from decompressor
to compressor has been separated out from other ROHC data transport
through the definition of ROHC channels as always unidirectional.
This means an additional channel concept must be defined for
feedback, which is what further will be referred to as "ROHC feedback
channels".
In the same way as a ROHC channel is a logically dedicated
unidirectional channel from a ROHC compressor to its ROHC peer
decompressor, a ROHC feedback channel is a logically dedicated
unidirectional channel from a ROHC decompressor to its ROHC peer
compressor. A ROHC feedback channel thus has one single input
endpoint, connected to the FO of one single ROHC decompressor
instance, and one single output endpoint, connected to the FI of one
single ROHC compressor instance.
Jonsson [Page 10]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
+--------------+ +--------------+
| | | |
| ROHC | | ROHC |
| Compressor | --<--<--<--<--<-- | Decompressor |
| | <- FI <- ROHC FB Channel <- FO <- | |
+--------------+ --<--<--<--<--<-- +--------------+
It might not be obvious why this extreme simplicity is needed, but
the reason is generality for handling of feedback. ROHC has been
designed with the assumption of logical separation, which creates
flexibility for how to realize feedback transport, as discussed in
[RFC-3095, section 5.2.1]. There are no restrictions on how to
implement a ROHC feedback channel, more than that it must be made
available and be logically dedicated to the ROHC peers.
The following subchapters provides some, not at all exclusive,
examples of how a ROHC feedback channel might possibly be
implemented.
5.1. Single-Channel Dedicated ROHC Feedback Channel Example
This chapter illustrates a one-way compression example where one bi-
directional channel has been configured to represent a ROHC channel
in one direction and a dedicated ROHC feedback channel in the other
direction.
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| | : --<--<--<--<-- : | |
ñ |PI FI| <-- : FB Channel : <-- |FO PO| ñ
+--------------+ : --<--<--<--<-- : +--------------+
:................:
In this example, feedback is sent on its own channel, as discussed in
e.g. feedback realization example 1-3 of ROHC [RFC-3095, page 44].
This means that the piggybacking mechanism of ROHC is not used, and
the PI/PO connections are thus not used (marked with a "ñ"). To
facilitate communication with ROHC compression in a two-way example
with this approach, an identical configuration must be provided for
the other direction.
5.2. Piggybacked/Interspersed ROHC Feedback Channel Example
This chapter illustrates how a bi-directional channel has been
configured to represent one ROHC channel in each direction, while
Jonsson [Page 11]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
still allowing feedback to be transmitted through ROHC piggybacking
and interspersing.
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel A : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| A | : : | A |
+-> |PI FI| <-+ : : +-- |PO FO| --+
| +--------------+ | : : | +--------------+ |
| | : : | |
| | : : | |
| +--------------+ | : : | +--------------+ |
+-- |FO PO| --+ : : +-> |FI PI| <-+
| ROHC | : : | ROHC |
| Decompressor | : : | Compressor |
| B | : --<--<--<--<-- : | B |
<-- |DO CI| <-- : ROHC Channel B : <-- |CO UI| <--
+--------------+ : --<--<--<--<-- : +--------------+
:................:
In this example, feedback is sent piggybacked on compressed packets
in the ROHC channels, as discussed in e.g. feedback realization
example 4-6 of ROHC [RFC-3095, page 44]. Feedback from decompressor A
to compressor A is here sent through FO(A)->PI(B), piggybacked on a
compressed packet over ROHC channel B, and delivered to compressor A
through PO(B)->FI(A). A logical ROHC feedback channel is thus
provided from the PI input at decompressor B to the PO output at
compressor B. It should be noted that in this picture, PO and FO at
the decompressors have been swapped to simplify drawing.
5.3. Dual-Channel Dedicated ROHC Feedback Channel Example
This chapter illustrates how two bi-directional channels have been
configured to represent two ROHC channels and two dedicated ROHC
feedback channels, respectively.
Jonsson [Page 12]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
->|UI CO| --> : ROHC Channel A : --> |CI DO|->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| A | : : | A |
| | : : | |
+-> |FI PI|ñ : : ñ|PO FO| --+
| +--------------+ : --<--<--<--<-- : +--------------+ |
| +- : ROHC Channel B :<-+ |
| | : --<--<--<--<-- : | |
| +--------------+ | :................: | +--------------+ |
| <-|FO CI|<-+ +- |CO UI|<- |
| | ROHC | | ROHC | |
| | Decompressor | Bi-directional channel | Compressor | |
| | B | .................. | B | |
| | | : -->-->-->-->-- : | | |
| ñ|PO FO| --> : FB Channel B : --> |FI PI|ñ |
| +--------------+ : -->-->-->-->-- : +--------------+ |
| : : |
| : --<--<--<--<-- : |
+----------------------- : FB Channel A : <----------------------+
: --<--<--<--<-- :
:................:
In this example, feedback is in both directions sent on its own
channel, as discussed in e.g. feedback realization example 1-3 of
ROHC [RFC-3095, page 44]. With this configuration, the piggybacking
mechanism of ROHC is not used, and the PI/PO connections are thus not
used (marked with a "ñ"). It should be noted that also in this
picture, PO and FO at the decompressors have been swapped to simplify
drawing, as well as the B-instances have been horizontally mirrored.
6. ROHC Contexts
In previous sections it has been clarified that one network element
may have multiple IP interfaces, one IP interfaces may have multiple
ROHC instances running, not necessary both compressors and
decompressors, and for each ROHC instance there is exactly one ROHC
channel and optionally one ROHC feedback channel.
Each compressor/decompressor can further compress/decompress an
arbitrary (but normally limited on a per-channel basis) number of
concurrent packet streams sent over the ROHC channel connected to
that compressor/decompressor. Each packet stream relates to one
particular context state in the compressor/decompressor. When sent
over the ROHC channel, compressed packets are labeled with a context
identifier (CID), indicating which context the compressed packet
corresponds to. There is thus a one-to-one mapping between the number
Jonsson [Page 13]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
of contexts that can be present in a compressor/decompressor and the
context identifier (CID) space used in compressed packets over that
ROHC channel. This is illustrated by the following figure:
+------------------------------------------------------------------+
| IP Interface |
+---------------+----+---------------+----+---------------+--------+
| ROHC HC | | ROHC HC | | ROHC HD |
| Context 0...N | | Context 0...M | | Context 0...K | ...
+--+---------+--+ +--+---------+--+ +--+---------+--+
^ | ^ | : ^
: CID | : CID | : CID |
: 0...N | : 0...M | : 0...K |
: v : v v |
ROHC ROHC ROHC ROHC ROHC ROHC
Feedback Channel Feedback Channel Feedback Channel
Channel Channel Channel
It should be noted that each ROHC instance at an IP interface
therefore has its own context and CID space, which size must be
agreed with the corresponding ROHC instance peer at the other end of
the ROHC channel.
7. Implementation Implications
This section will address some questions related to how the
conceptual aspects discussed above affect implementations of ROHC.
ROHC is defined with a general header compression framework on top of
which compression profiles can be defined for each specific set of
headers to compress. Although the framework holds a number of
important mechanisms, the separation between framework and profiles
is mainly a standardization wise separation, to indicate what must be
common for all profiles, what must be defined by all profiles, and
what is profile-specific details. To implement the framework as a
separate module is thus not an obvious thing to do, especially if one
wants to use profile implementations from different vendors. However,
optimized implementations will probably separate the common parts and
implement those separately, and add profile modules to that.
A ROHC instance might thus consist of various pieces of
implementation modules, profiles and potentially also a ROHC-common
module, possibly from different vendors. If vendor and implementation
version information is made available for network management
purposes, this should thus be done on a per-profile basis, and in
addition to that potentially also for the instance as a whole.
Jonsson [Page 14]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
8. Security Considerations
This document is of informative nature, and does not have any
security aspects to address.
9. Acknowledgements
Thanks to Juergen Quittek and Hans Hannu for fruitful discussions,
improvement suggestions, and review.
10. References
[RFC-3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., 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.
11. Author's Address
Lars-Erik Jonsson Tel: +46 920 20 21 07
Ericsson AB Fax: +46 920 20 20 99
Box 920
SE-971 28 Lulea
Sweden EMail: lars-erik.jonsson@ericsson.com
Jonsson [Page 15]
INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires December 14, 2002.
Jonsson [Page 16]