ROHC instances running (not necessarily both compressors and
decompressors), and for each ROHC instance, there is exactly one ROHC
channel and optionally one ROHC feedback channel. How ROHC channels
and ROHC feedback channels are realized will differ from case to
case, depending on the actual layer two technology used.
Each compressor/decompressor can further compress/decompress an
arbitrary (but limited) number of concurrent packet streams sent over
the ROHC channel connected to that compressor/decompressor. Each
packet stream relates to one particular context in the
compressor/decompressor. When sent over the ROHC channel, compressed
packets are labeled with a context identifier (CID), indicating to
which context the compressed packet corresponds. There is thus a
one-to-one mapping between the number 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 | | ROHC | | ROHC |
| Compressor | | Compressor | | Decompressor |
| 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, and it must be ensured
that the CID size of the corresponding decompressor at the other end
of the ROHC channel is not smaller than the CID space of the
compressor.
8. Summary
This document has introduced and defined a number of concepts and
terms for use in ROHC network integration, and explained how the
various pieces relate to each other. In the following bullet list,
the most important relationship conclusions are repeated:
- A network element may have one or several IP interfaces.
- Each IP interface is connected to one or several logical layer two
channels.
- Each IP interface may have one or several ROHC instances, either
compressors, decompressors, or an arbitrary mix of both.
- For each ROHC instance, there is exactly one ROHC channel, and
optionally exactly one ROHC feedback channel.
- How ROHC channels and ROHC feedback channels are realized through
the available logical layer two channels will vary, and there is
therefore no general relation between ROHC instances and logical
layer two channels. ROHC instances map only to ROHC channels and
ROHC feedback channels.
- Each compressor owns its own context identifier (CID) space, which
is the multiplexing mechanism it uses when sending compressed
header packets to its corresponding decompressor. That CID space
thus defines how many compressed packet streams can be
concurrently sent over the ROHC channel allocated to the
compressor/decompressor peers.
9. Implementation Implications
This section will address how the conceptual aspects discussed above
affect implementations of ROHC.
ROHC is defined as 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 separation from a standardization point of view, to
indicate what must be common to all profiles, what must be defined by
all profiles, and what are profile-specific details. To implement
the framework as a separate module is thus not an obvious choice,
especially if one wants to use profile implementations from different
vendors. However, optimized implementations will probably separate
the common parts and implement those in a ROHC framework module, and
add profile modules to that.
A ROHC instance might thus consist of various pieces of
implementation modules, profiles, and potentially also a common ROHC
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 potentially also for the instance as a whole.
10. Security Considerations
The clear understanding of ROHC channels and their relations to IP
interfaces and the physical medium, plays a critical role in ensuring
secure usage of ROHC. This document is therefore a valuable adjunct
to the Security Considerations found in RFC 3095 and other ROHC
specifications. However, as it just reviews information and
definitions, it does not add new security issues to the ROHC protocol
specifications.
11. Acknowledgements
Thanks to Juergen Quittek, Hans Hannu, Carsten Bormann, and Ghyslain
Pelletier for fruitful discussions, improvement suggestions, and
review. Thanks also to Peter Eriksson for doing a language review.
12. Informative 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): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
13. Author’s Address
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea
Sweden
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
EMail: lars-erik.jonsson@ericsson.com
14. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.