GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3759

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:
  1. Are channels bi- or unidirectional?
  2. 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:
  1. A network element may have one or several IP interfaces.
  1. Each IP interface is connected to one or several logical layer two

channels.

  1. Each IP interface may have one or several ROHC instances, either

compressors, decompressors, or an arbitrary mix of both.

  1. For each ROHC instance, there is exactly one ROHC channel, and

optionally exactly one ROHC feedback channel.

  1. 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.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3759.txt · Last modified: 2004/04/12 21:56 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki