Subject: [rohc] Question about Channel Parameters and U-Mode

From: "Holmes, Matthew, CND Tech Dev, VF UK" <[email-masked]>
Date: Thu, 23 Jan 2003 12:01:54 -0000

Hi All

I'm a bit confused about how channel parameters are negotiated in U-Mode. If no feedback path is available then U-Mode would be used.
Can some one explain what happens with the channel parameters in this case? 
How would something like the PROFILES parameter be sent to the compressor? 
Although feedback is not required for U-Mode is a two-way link mandatory for the link establishment?

Any help would be appreciated,

Thank you

Matthew Holmes

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

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 23 Jan 2003 14:29:20 +0100

Alan,

> This does raise the question as to whether, for the sake of
> better standardisation, there should be a specified preferred
> a-priori set of parameters for each link type.

Yes, this could be appropriate for simplex links. However, we
do not handle such link specific issues in the IETF. We do
define the operation for PPP, but other bodies have to handle
this for other links. That is what we have done in ROHC, in
the same way as for previous compression schemes.

> For example, for PPP links, rfc3241, these parameters could 
> be assumed:
> 
> MAX_CID		15
> MRRU		0
> MAX_HEADER	168
> PROFILES	0x0000, 0x0001, 0x0002 

Well, I am not sure one can specify a default for PROFILES. If
there is a way no negotiate, one should absolutely use that.

> Then if you had two different brands of ROHC/PPP software from
> different vendors, you should be able to get them interworking
> on a simplex link without sending round the carrier pigeon.

Hmmm...PPP is not for simplex links...so the above suggestion does
not really compile. But I agree that this approach would be a
candidate for simplex links. That is what is meant with a priori,
as suggested by 3095.

> Therefore I conclude that, more or less, parameter negotiation is
> superfluous on a simplex link, and maybe for duplex also,
> if you assume that all implementations wake up as above or with
> larger numbers or sets.
> All you really need to know is that the other side has an 
> ROHC implementation.

You would still have to negotiate (at least) profiles, and it is
useful to have negotiation also for the other parameters. In any
case, this is a link-specific issue that must be addressed for
each link type. For PPP, all parameters are negotiated, as defined
by RFC 3241.

> Maybe a set of standard out-of-the-box null-negotiation parameters
> could be specified in RFC 3241 to take care of simplex links!?

RFC 3241 defines ROHC-over-PPP, which is for duplex links. 

To summarize, this is an issue for bodies responsible of simplex
links where one wants to use ROHC, it is not within our scope.

Cheers,
/L-E