doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc3759.txt b/doc/rfc/rfc3759.txt
new file mode 100644
index 0000000..c2b7447
--- /dev/null
+++ b/doc/rfc/rfc3759.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                       L-E. Jonsson
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jonsson                      Informational                      [Page 1]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+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.
+
+
+
+
+
+Jonsson                      Informational                      [Page 2]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+   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.
+
+
+
+
+
+
+Jonsson                      Informational                      [Page 3]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+   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.
+
+
+
+
+
+
+Jonsson                      Informational                      [Page 4]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+   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.
+
+
+
+
+
+
+Jonsson                      Informational                      [Page 5]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+   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.
+
+
+
+
+
+
+
+Jonsson                      Informational                      [Page 6]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+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.
+
+
+
+Jonsson                      Informational                      [Page 7]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+   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  <->    |
+                +----------------------------------------+
+
+
+
+
+Jonsson                      Informational                      [Page 8]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+   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.
+
+
+
+Jonsson                      Informational                      [Page 9]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+      +-----------------+                      +-----------------+
+      | 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.
+
+4.  ROHC Instances
+
+   For various purposes, such as 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; where both are present,
+   they will be referred to as two ROHC instances.
+
+   The following two subsections describe the two kinds of ROHC
+   instances and their external interfaces, while sections 5 and 6
+   address how communication over these interfaces is realized through
+   "ROHC channels" and "ROHC feedback channels".  Section 7 builds on
+   top of the instance, channel and feedback channel concepts, and
+   clarifies how ROHC contexts map to this.
+
+
+
+
+Jonsson                      Informational                     [Page 10]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+   It should be noted that all figures in sections 4-6 have been rotated
+   90 degrees to simplify drawing, i.e., they do not show a "stack
+   view".
+
+4.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 5).
+
+      Feedback Input (FI):     Feedback from the corresponding
+           [optional]          decompressor 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 6).  When there are no
+                               means to transmit feedback from
+                               decompressor to compressor, FI is not
+                               used, and bi-directional compression
+                               will not be possible.
+
+      Piggyback Input (PI):    If the compressor is associated with a
+           [optional]          co-located decompressor, for which the
+                               compressor delivers feedback to the
+                               other end of the link, 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
+                               4.2).
+
+
+
+
+Jonsson                      Informational                     [Page 11]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+4.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:
+
+                               +--------------+
+                      -> 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 5).
+
+      Decompressed Output (DO): Decompressed packets are delivered from
+                                the decompressor to higher layers
+                                through the DO.
+
+      Feedback Output (FO):     Feedback to the corresponding compressor
+           [optional]           is sent from the compressor through the
+                                FO, which (if present) is connected to
+                                the input end of a ROHC feedback channel
+                                of some kind (see section 6).  When
+                                there are no means to transmit feedback
+                                from decompressor to compressor, FO is
+                                not used, and bi-directional compression
+                                will not be possible.
+
+      Piggyback Output (PO):    If the decompressor is associated with
+           [optional]           a co-located compressor to which the
+                                decompressor delivers feedback it
+                                receives piggybacked from the other end
+                                of the link, 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 4.1).
+
+
+
+
+
+
+
+
+Jonsson                      Informational                     [Page 12]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+5.  ROHC Channels
+
+   In section 3, a general concept of channels was introduced.
+   According to that definition, a channel is basically a logical
+   point-to-point connection between the IP interfaces of 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 how ROHC logically works.  Therefore, for the case of
+   ROHC, the channel concept is enhanced and a more restricted concept
+   of "ROHC channels" is defined.
+
+   A ROHC channel has the same properties as a channel, with the
+   difference that a ROHC channel is always 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 and one ROHC decompressor, hereafter
+   referred to as ROHC peers, creating a one-to-one mapping between a
+   ROHC channel and two ROHC compressor/decompressor peers.
+
+   +--------------+          --->-->-->-->---          +--------------+
+   |              | -> CO ->   ROHC Channel   -> CI -> |              |
+   |     ROHC     |          --->-->-->-->---          |     ROHC     |
+   |  Compressor  |                                    | Decompressor |
+   |              |                                    |              |
+   +--------------+                                    +--------------+
+
+   In many cases the lower layer channel is by nature bi-directional,
+   but for ROHC communication over that channel, a ROHC channel would
+   only represent one communication direction of that 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 both 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 6.
+
+
+
+
+
+
+
+
+Jonsson                      Informational                     [Page 13]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+6.  ROHC Feedback Channels
+
+   Since ROHC can be implemented over various kinds 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 the transport
+   of actual ROHC packets through the definition of ROHC channels as
+   always being unidirectional from compressor to decompressor.  This
+   means that an additional channel concept must be defined for
+   feedback, which is what will hereafter 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 corresponding
+   ROHC peer decompressor, a ROHC feedback channel is a logically
+   dedicated unidirectional channel from a ROHC decompressor to its
+   corresponding 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.
+
+   +--------------+                                     +--------------+
+   |              |                                     |              |
+   |     ROHC     |                                     |     ROHC     |
+   |  Compressor  |          --<--<--<--<--<--          | Decompressor |
+   |              | <- FI <-  ROHC FB Channel  <- FO <- |              |
+   +--------------+          --<--<--<--<--<--          +--------------+
+
+   The reason for making this simplification and logically separating
+   ROHC channels from ROHC feedback channels is generality for handling
+   of feedback.  ROHC has been designed with the assumption of logical
+   separation, which creates flexibility in realizing feedback
+   transport, as discussed in [RFC-3095, section 5.2.1].  There are no
+   restrictions on how to implement a ROHC feedback channel, other than
+   that it must be made available and be logically dedicated to the ROHC
+   peers if bi-directional compression operation is to be allowed.
+
+   The following subsections provide some, not at all exhaustive,
+   examples of how a ROHC feedback channel might possibly be realized.
+
+6.1.  Single-Channel Dedicated ROHC Feedback Channel Example
+
+   This section 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.
+
+
+
+
+
+Jonsson                      Informational                     [Page 14]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+                          Bi-directional channel
+                            ..................
+       +--------------+     : -->-->-->-->-- :     +--------------+
+   --> |UI          CO| --> :  ROHC Channel  : --> |CI          DO| -->
+       |     ROHC     |     : -->-->-->-->-- :     |     ROHC     |
+       |  Compressor  |     :                :     | Decompressor |
+       |              |     : --<--<--<--<-- :     |              |
+     o |PI          FI| <-- :   FB Channel   : <-- |FO          PO| o
+       +--------------+     : --<--<--<--<-- :     +--------------+
+                            :................:
+
+   In this example, feedback is sent on its own dedicated channel, as
+   discussed in e.g., feedback realization example 1-3 of ROHC [RFC-
+   3095, page 44].  This means that the piggybacking/interspersing
+   mechanism of ROHC is not used, and the PI/PO connections are thus
+   left open (marked with a "o").  To facilitate communication with ROHC
+   compression in a two-way manner using this approach, an identical
+   configuration must be provided for the other direction, i.e., making
+   use of four logical unidirectional channels.
+
+6.2.  Piggybacked/Interspersed ROHC Feedback Channel Example
+
+   This section illustrates how a bi-directional channel has been
+   configured to represent one ROHC channel in each direction, while
+   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| <--
+       +--------------+     : --<--<--<--<-- :     +--------------+
+                            :................:
+
+
+
+
+
+Jonsson                      Informational                     [Page 15]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+   In this example, feedback is transmitted piggybacked or interspersed
+   among compressed header 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 compressor B
+   to the PO output at decompressor B.  It should be noted that in this
+   picture, PO and FO at the decompressors have been swapped to simplify
+   drawing.
+
+6.3.  Dual-Channel Dedicated ROHC Feedback Channel Example
+
+   This section illustrates how two bi-directional channels have been
+   configured to represent two ROHC channels and two dedicated ROHC
+   feedback channels, respectively.
+
+                          Bi-directional channel
+                            ..................
+       +--------------+     : -->-->-->-->-- :     +--------------+
+     ->|UI          CO| --> : ROHC Channel A : --> |CI          DO|->
+       |     ROHC     |     : -->-->-->-->-- :     |     ROHC     |
+       |  Compressor  |     :                :     | Decompressor |
+       |      A       |     :                :     |      A       |
+       |              |     :                :     |              |
+   +-> |FI          PI| o   :                :   o |PO          FO| --+
+   |   +--------------+     : --<--<--<--<-- :     +--------------+   |
+   |                     +- : ROHC Channel B :<-+                     |
+   |                     |  : --<--<--<--<-- :  |                     |
+   |   +--------------+  |  :................:  |  +--------------+   |
+   | <-|DO          CI|<-+                      +- |CO          UI|<- |
+   |   |     ROHC     |                            |     ROHC     |   |
+   |   | Decompressor |   Bi-directional channel   |  Compressor  |   |
+   |   |      B       |     ..................     |      B       |   |
+   |   |              |     : -->-->-->-->-- :     |              |   |
+   |  o|PO          FO| --> :  FB Channel B  : --> |FI          PI|o  |
+   |   +--------------+     : -->-->-->-->-- :     +--------------+   |
+   |                        :                :                        |
+   |                        : --<--<--<--<-- :                        |
+   +----------------------- :  FB Channel A  : <----------------------+
+                            : --<--<--<--<-- :
+                            :................:
+
+   In this example, feedback is, in both directions, sent on its own
+   dedicated channel, as discussed in e.g., feedback realization example
+   1-3 of ROHC [RFC-3095, page 44].  With this configuration, the
+   piggybacking/interspersing mechanism of ROHC is not used, and the
+   PI/PO connections are thus left open (marked with a "o").  It should
+
+
+
+Jonsson                      Informational                     [Page 16]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+   be noted that in this picture FI/PI and PO/FO at the A-instances have
+   been swapped to simplify drawing, while the B-instances have been
+   horizontally mirrored.
+
+7.  ROHC Contexts
+
+   In previous sections, it has been clarified that one network element
+   may have multiple IP interfaces, one IP interface may have multiple
+   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.
+
+
+
+
+
+Jonsson                      Informational                     [Page 17]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+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.
+
+
+
+Jonsson                      Informational                     [Page 18]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+   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
+
+
+
+
+
+
+
+
+Jonsson                      Informational                     [Page 19]
+
+RFC 3759     ROHC Terminology and Channel Mapping Examples    April 2004
+
+
+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.
+
+
+
+
+
+
+
+
+
+Jonsson                      Informational                     [Page 20]
+