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

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

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

This is something we must remember to discuss in RFC3095bis(FM),
and maybe clarify in RFC 3241bis (if/when that happens). There
is a significant difference between having simple "capability
announcements" and requiring real negotiations.

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

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 17 Sep 2002 08:51:50 +0200

Micke,

The problem is that 3095 gives the impression it is sufficient if the decompressor side announces to the compressor side which profiles it supports, while this shows that two-way negotiations are really needed to avoid ambiguities. For example, the PROFILES channel parameter is defined only as the set of profiles supported by the decompressor, while it should be the set of profiles agreed between compressor and decompressor.

> Where is the problem here? Are you saying that
> a) there is a problem with the current set of specs, or

Well, we seem to be on the safe side with PPP, but RFC 3241 still does not mention anything about how to carry out 2).

> b) we should improve 3095bis so that the rule in 2) above is 
> made explicit.

Yes, 3095bis should be much clearer on how profile support is negotiated between compressor and decompressor. 

BR
/L-E

> -----Original Message-----
> From: Mikael Degermark [mailto:[email-masked]]
> Sent: den 16 september 2002 13:01
> To: Lars-Erik Jonsson (EAB); [email-masked]; Carsten Bormann (E-mail)
> Subject: Re: [rohc] PROFILES negotiation and profile "versions"
> 
> 
> 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
> 
> ----- Original Message -----
> From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
> To: <[email-masked]>; "Carsten Bormann (E-mail)" <[email-masked]>
> Sent: Monday, September 16, 2002 7:10 AM
> Subject: [rohc] PROFILES negotiation and profile "versions"
> 
> 
> > 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...
> >             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >