[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 3759

Network Working Group                                       L-E. Jonsson
INTERNET-DRAFT                                                  Ericsson
Expires: June 2003                                      December 3, 2002






                    RObust Header Compression (ROHC):
      Terminology and Examples for MIB Modules and Channel Mappings
            <draft-ietf-rohc-terminology-and-examples-01.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 a submission of the IETF ROHC WG. Comments should be
   directed to the ROHC WG mailing list, rohc@ietf.org.


Abstract

   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                                                         [Page 1]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002



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...............................................6
        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................................................12
   6.  ROHC Feedback Channels.......................................13
        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......................................................17
   9.  Implementation Implications..................................18
   10.  Security Considerations.....................................19
   11.  Acknowledgements............................................19
   12.  References..................................................19
   13.  Author's Address............................................19


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 be the case
   especially 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 with 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]. After that, section 9 explains some
   implementation implications that arise from these conceptual aspects.



Jonsson                                                         [Page 2]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002



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 further 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 further 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 further
      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.

   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.




Jonsson                                                         [Page 3]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002



   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 can 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 further 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 further section 6.

   Co-located compressor/decompressor

      A minimal ROHC instance is only a compressor or a decompressor,
      communicating with a corresponding decompressor or compressor 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, which is what is 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 ROHC decompressor
      co-located with the compressor at the other end. When a co-located
      ROHC compressors/decompressor pair is connected for this purpose,
      they are said to be associated with each other.



Jonsson                                                         [Page 4]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002



   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 channel.
      If feedback packets are transmitted in the latter way and sent as
      stand-alone packets, this is referred to as interspersed feedback.
      See further 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 channel.
      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 further 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 further section 6.1 and 6.3 for examples.

























Jonsson                                                         [Page 5]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


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".

   To visualize the above terms, the top level hierarchy of a network
   element is thus the following, with one 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.


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-



Jonsson                                                         [Page 6]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


   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 ROHC channels (section 5) and ROHC feedback channels
   (section 6), while here the basic channel concept just defined above.










Jonsson                                                         [Page 7]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


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.








Jonsson                                                         [Page 8]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


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 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                                                         [Page 9]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 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.


4.  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; 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.

   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".



Jonsson                                                        [Page 10]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002



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 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 4.2).












Jonsson                                                        [Page 11]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


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 by 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 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 4.1).


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



Jonsson                                                        [Page 12]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


   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/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 |
   |              |                                    |              |
   +--------------+                                    +--------------+

   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.


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



Jonsson                                                        [Page 13]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


   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 separate 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.
                           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.



Jonsson                                                        [Page 14]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002




6.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
   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 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.















Jonsson                                                        [Page 15]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


6.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.

                           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 :<-+                     |
    |                     |  : --<--<--<--<-- :  |                     |
    |   +--------------+  |  :................:  |  +--------------+   |
    | <-|FO          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
   be noted that in this picture also PO and FO at the decompressors
   have been swapped to simplify drawing, while the B-instances have
   been vertically mirrored.














Jonsson                                                        [Page 16]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


7.  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 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 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
   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, 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.



Jonsson                                                        [Page 17]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002



    - 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 logical layer two channels available 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 pair.


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 is 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 separately, and add profile
   modules to these.

   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 in
   addition to that potentially also for the instance as a whole.






Jonsson                                                        [Page 18]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


10.  Security Considerations

   This document is of an informative nature, and does not have any
   security aspects to address.


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 making a linguistic review.


12.  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.


13.  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 19]

INTERNET-DRAFT   ROHC Terminology and Channel Examples  December 3, 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002). 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 June 3, 2003.



















Jonsson                                                        [Page 20]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/