Subject: [rohc] ROHC MIB issues to be discussed at session today

From: Juergen Quittek <[email-masked]>
Date: Tue, 19 Mar 2002 19:17:01 +0100

Hi Rohcers,

The main issues concerning the ROHC RTP MIB to be discussed 
at the session today are:

- Extensibility

  How to be extensible concerning ROHC for TCP, SCTP, … ?
  In general there are three alternative ways
  1. Define independent MIB modules for each transport protocol.
     This is obviously possible but does not appear to be very
     desirable.
  2. Try to define a basic module and individual extension modules.
     This way is probably possible, but needs some effort for
     defining interface points for the extensions to come.
  3. Try to be open and generic in order to be able to integrate
     foreseeable future extensions.
     I think this is almost impossible, because - at least I - cannot
     forsee the requirements of ROHC extensions coming up.

- Statistics

  Is there any feedback on the statistics collected by the MIB.
  Are some of them superfluous, are more desired?

- Conformance

  MIB modules contain conformance statements defining individual
  managed objects or object groups to be madatory or optional. 
  Which object groups of the ROHC MIB module should be manadatory, 
  which should be optional?

- Architectural assumptions

  For structuring the MIB module some architectural assumptions
  were required. Please provide input on whether you think they
  are reasonable and appropriate or not:

  1. Concurrent Instances of ROHC

     At a network node serving as (de)compressor point serveral instances
     of ROHC implementations may run concurrently. These may all be
     instances of the same implementation, or they may be instances of
     different versions of the same implementation, or they may origin
     from different manufacturers.

     As an example take a ROHC implementation running completely on a
     network interface card. At a node equipped with several cards, each
     card runs its own independent instance. Typically all cards use the
     same ROHC implementation when the node is installed for the first
     time. But after some time some cards my be replaced or added without
     replacing or updating all installed cards. Then the newer card my run
     some recent versions of the ROHC implementations or even use other
     independent implementations.

  2. Single Instance per Interface

     No more than one instance of ROHC may act as (de)compression point
     for a specific (logical) IP interface.

     This assumption may be too restrictive. In general, systems can be
     built that violate this assumption. It needs to be discussed further,
     wether such systems are probable to be implemented or just irrelevant
     alternatives.

  3. Multiple Interfaces per Instance

     A single instance of ROHC may serve more than one IP interface. An
     example is a central implementation serving all interfaces of a
     network node.

  4. Channels may be Bi-directional

     Channels may carry data in both directions. This is typically not the
     case, but it does not require much additional effort to support bi-
     directional channels by the MIB structure, and we did not see any
     good reason to exclude future implementations on bi-directional
     channels. However, we still see this assumption as subject of further
     discussions.

 5.  Channel Used by Single Instance

     A channel is exclusively used by a single implementation of ROHC.

  6. Feedback Channel at Same Interface

     A feedback channel must be accessible at the same IP interface at
     which also the original channel is accessible.

     This is again a questionable assumption. One could think of using
     different logical interfaces for forward and backward channels. Input
     on how realistic such implementations are is very welcome.

    Juergen
--
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
-- 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc