Subject: [rohc] PROFILES negotiation and profile "versions"

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 16 Sep 2002 16:10:43 +0200

Folks (Carsten??),

I got some questions regarding ROHC negotiation that led me 
into an issue where I think RFC 3095 is not totally clear,
and I would like to hear your opinions in this regard.

RFC 3095 defines the PROFILES channel property as the list of
profiles supported by the decompressor, each identified with a
16-bit profile number. This is thus information signaled from
the decompressor to the compressor when the channel is
established, as e.g. defined for PPP by RFC 3241. The compressor
then decides which profile to use and indicates this in IR or
IR-DYN headers. The IR/IR-DYN profile field is only 8 bits
long and includes the LSB's of the profile ID, which should
work fine since the profile ID MSB's just indicate "version"
of the profile, and the compressor must choose the newest
"version" supported by both compressor (known by itself) and
decompressor (indicated in PROFILES).

However, the decompressor do not know which version(s) of
a profile are supported by the compressor, and can therefore
not know which version the compressor chooses. Lets assume that
the decompressor supports 0x0001 and 0x0101, while the
compressor only supports 0x0001. The compressor will then choose
0x0001, but the decompressor can not know that. Which version
should the decompressor assume?

I think we have a potential problem here, or have I missed 
something? Is the assumption that "upgraded" decompressors
will still be backwards compatible with old versions? RFC 3095
only says that "the higher-numbered one is intended to supersede
the lower-numbered one", but it is unclear what is meant with
"supersede". Is there a simple answer that I have missed, or
do we need to define clearer how to supersede a profile by
defining upgrades, i.e. set rules for what is allowed? What was
really the intension?

Below, all relevant sections from RFC 3095 and RFC 3241 are 
included for your convenience.

Please let me know your view of this!
/L-E

RFC 3095:  4.2.  Dynamicity

   Streams need not share all characteristics important for
   compression. ROHC has a notion of compression profiles:
   a compression profile denotes a predefined set of such
   characteristics.  To provide extensibility, the negotiated
   channel state includes the set of profiles acceptable to
   the decompressor.  The context state includes the profile
   currently in use for the context.

RFC 3095:  8.  IANA Considerations

   The ROHC profile identifier is a non-negative integer. In
   many negotiation protocols, it will be represented as a
   16-bit value.  Due to the way the profile identifier is
   abbreviated in ROHC packets, the 8 least significant bits
   of the profile identifier have a special significance: Two
   profile identifiers with identical 8 LSBs should be
   assigned only if the higher-numbered one is intended to
   supersede the lower-numbered one.  To highlight this
   relationship, profile identifiers should be given in 
   hexadecimal (as in 0x1234, which would for example
   supersede 0x0A34).

RFC 3095:  5.1.1.  Per-channel parameters

   PROFILES: Set of nonnegative integers, each integer
   indicating a profile supported by the decompressor.  The
   compressor MUST NOT compress using a profile not in
   PROFILES.

RFC 3095:  5.2.3.  ROHC IR packet type  

   Profile: The profile to be associated with the CID.  In the
   IR packet, the profile identifier is abbreviated to the 8
   least significant bits.  It selects the highest-number
   profile in the channel state parameter PROFILES that matches
   the 8 LSBs given.

RFC 3241:  2.  Configuration Option

   It may be worth repeating [RFC1332], section 4: "The IP-
   Compression-Protocol Configuration Option is used to
   indicate the ability to receive compressed packets.  Each
   end of the link must separately request this option if bi-
   directional compression is desired."  I.e., the option
   describes the capabilities of the decompressor (receiving
   side) of the peer that sends the Configure-Request.

RFC 3241:  2.2.  PROFILES Suboption

   The set of profiles to be enabled is subject to negotiation.
   Most initial implementations of ROHC implement profiles
   0x0000 to 0x0003. This option MUST be supplied.

   Description

      Define the set of profiles supported by the decompressor.

                       Figure 3: PROFILES suboption

             0                   1                   2
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |     Type      |    Length     |  Profiles...
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-----------------------------------
Lars-Erik Jonsson, M.Sc
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research and Experiments
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Sep 2002 16:34:46 +0200

Speaking about 3241, it seems a compressor should not allow the negotiation of 
(i.e., Configure-Ack) two profile versions of the same profile in the PROFILES 
suboption that have incompatible wire protocols.  This is a bit backwards 
(normally, you would expect the decompressor to control this, but it can't 
really do that very efficiently, as it has to offer its whole portfolio of 
protocol versions in the Configure-Request), but workable. Of course, a paranoid 
decompressor can always offer the newest versions only and hope that the 
compressor will Configure-Nak it down, but this isn't as efficient, and presumes 
some intelligence on the side of the compressor PPP implementation.  In any 
case, this means you can't Configure-Ack a version you don't know of a profile 
you do want to use, as that version might be incompatible.

For other negotiation protocols, the ROHC-over-X documents have to make sure 
that the same can be done.  I don't think that has ever been pointed out.

Gruesse, Carsten

---

From: "Mikael Degermark" <[email-masked]>
Date: Mon, 16 Sep 2002 04:00:48 -0700

Hmm. Isn't it the sequence of events the following (for ROHC over PPP):

1) Decompressor side sends to compressor side a list of supported
profiles (16 bit numbers). This can include several profile numbers that
only
differ in the upper 8 bits, i.e., are really variants of the same profile.

2) Compressor side sees which of these it can do, and Configure-Acks
those. It may not Configure-Ack two profile numbers that differ only in
the upper 8 bits.

3) Both sides now know what 8-bit profile numbers used in IRs and IR-DYNs
mean: The corresponding 16-bit number, of which there may be at most one.

Where is the problem here? Are you saying that

a) there is a problem with the current set of specs, or
b) we should improve 3095bis so that the rule in 2) above is made explicit.

Cheers,

Micke