Subject: [rohc] new-ID: ROHC values for Framed-Compression attribute

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 11 Oct 2005 11:23:15 -0400

Hi all,

We submitted the following draft to define the RADIUS Framed-Attribute
values to support ROHC, LLA-ROHC and ROCH-TCP. Here is the abstract:

"
   The definition of RADIUS attribute "Framed-Compression" in RFC 2865
   does not include values for new Header Compression schemes like ROHC,
   ROHC-TCP.  This document defines the new values to the "Framed-
   Compression" attribute.
"

http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribut
es-00.txt

We appreciate your comment on this.

Regards,
Kuntal

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 11 Oct 2005 18:10:43 +0200

Hi Kuntal,

Good to hear from you! I especially liked the following passage in the draft:

"ROHC is being deployed worldwide and it is especially gaining
   immense popularity in 3G wireless networks."

Seriously, here are my comments on your draft (actually, I mainly have questions because I don't know enough about Radius):

1) Comparing Description in 5.13 of 2865 and your draft, I can't parse the 3rd sentence of the first paragraph:

>     an Access-Request packet as a hint to the server that the NAS
>     would prefer to use that compression, but the server is not
>     required to honor the hint.

<     Access-Request packet as a hint to the server that the NAS would
<     prefer to supports the use that a compression scheme, but the RADIUS
<     server is not required to honor the hint.

It seems that you redescribe the "use of" a compression scheme to "support for". Is it the intention?
Is this used as some sort of "parameter negotiation" within an authentication/authorization mechanism?

The only other diff until the Value element is the addition of "in the same Radius message", which I understand as a clarification not being a change from 2865.

Then comes additional values:

>  TBD-1    RObust Header Compression [RFC3095].
>
>  TBD-2    VJ TCP/IP header compression and RObust Header Compression
>           [ROHC-VJ].  When this value is negotiated, VJ compression 
>           is used for all TCP/IP traffic and ROHC compression is used 
>           for remaining traffic (UDP/IP, RTP/IP, ESP/IP).
>
>  TBD-3    Link Layer Assisted RObust Header Compression [RFC3242].

So, bearing in mind again that I know nothing about Radius, I have the following questions:

2) why values that relate to single (RoHC) profile (TBD-3) and single algorithm
   (VJ, ...), are mixed with values that relate to many (RoHC) profiles
   (TBD-1 -> profiles 0, 1, 2, 3).
   This seem to depart from the way values for this attribute are specified in 2865.
3) what is [RoHC-VJ]? I see the reference points to ROHC-TCP.
   Do you mean the ROHC-TCP profile? The text does say VJ (1144) for TCP
   traffic and "ROHC compression" for other traffic.
   I get completely confused. Honestly, I wouldn't know what the value
   would mean as part of this attribute even if I'd be allowed to guess!
4) Is it not possible to define one value for ROHC only instead, no matter what
   profile is being used? Or is it useful to know what profile aka type of
   traffic is being compressed?
5) How does this relate to the supported set of profiles being negotiated
   during the ROHC channel establishment? Does it have to be absolutely
   coherent with the profile set?
6) Assuming that the answer to 4) is no, and that each profile must have
   its own value, should values be also added for other ROHC profiles, e.g.
   IP-Only profile, UDP-Lite, ROHC-TCP?

However, because 2865 says:

  "Some Attributes MAY be included more than once.  The effect of this
   is Attribute specific, and is specified in each Attribute
   description"

I would assume that it is possible to define one value per compression algorithm (in the case of ROHC preferably one value for all ROHC traffic, alternatively one value for each ROHC profile), and then send multiple Framed-Compression attributes for each algorithm supported/used. Is this correct? If it is, why not do so?

How often do you have comments on a draft that are actually longer than the draft itself ; )

/Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Chowdhury, Kuntal
> Sent: den 11 oktober 2005 17:23
> To: [email-masked]
> Cc: Seshadri, Arun
> Subject: [rohc] new-ID: ROHC values for Framed-Compression attribute
> 
> 
> Hi all,
> 
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 13 Oct 2005 10:21:40 -0400

Lars-Erik,

Thanks for your suggestion. We will update the ID accordingly.

Regards,
Kuntal

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Lars-Erik Jonsson
> Sent: Thursday, October 13, 2005 1:36 AM
> To: Chowdhury, Kuntal; Ghyslain Pelletier (LU/EAB); [email-masked]
> Cc: Seshadri, Arun
> Subject: Re: [rohc] new-ID: ROHC values for Framed-Compression
attribute
> 
> > I guess we can add a section to describe the NAS behavior. The
actual
> > negotiation of the profile will be negotiation protocol dependent.
We
> > can say that this draft provides a mechanism to exchange ROHC
specific
> > profiles and variants between the NAS and the RADIUS server. The
> > negotiation of the profiles and variants is link protocol dependent.
> >
> > Or we can simply point to section 9 of ROHC implementer's guide for
> > MN-NAS profile negotiation considerations.
> 
> I think it would be better if you actually say this and not refer to
the
> impl. guide, who looks at references? =)
> 
> /L-E
> 
>

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Mon, 17 Oct 2005 16:38:53 +0200

Kuntal,

Here I will go again with some naive questions regarding Radius and what this draft is aiming to achieve.

See inline.

/Ghyslain

> BTW, what I intended to say was "by including this attribute in
> Access-Request the NAS indicates its header compression 
> capability e.g. ROHC to the RADIUS server."

> We can say that this draft provides a mechanism to exchange ROHC specific

What is the relationship between the PROFILES negotiation happening at the link protocol layer, and the exchange between the NAS and the RADIUS server? To what end does the RADIUS server use this information, wrt individual ROHC profile variants? I can understand that the Framed-Compression attribute would carry one identifier for a ROHC channel, but am I missing the point with individual variants here. My understanding right now is that what the NAS sends to the server in the Framed-Compression attribute is a hint, and the server may ignore it.

I guess I am not really clear with the purpose of this attribute with respect to ROHC, and specifically with respect to individual profiles and/or combinations thereof. And then I don't know RADIUS : (

> Here are some of my thoughts:
> 
> a. How does the NAS indicate its capability to support multiple
> compression schemes e.g. ROHC, VJ, IPX header compression etc.?
> According to RFC 2865, the Framed-Compression attribute can 
> be repeated
> in the same message. But it is not clear whether the NAS can include
> multiple instances of this attribute in the Access-Request to indicate
> its capability-set to the RADIUS sever or it is just the RADIUS server
> that can include multiple instances of this attribute in the
> Access-Accept for the NAS to apply on the session. May be this can be
> clarified in this ID.

A quick search on this question led me to believe that Framed-Compression attribute:
- may be used in Access-Accept packets, from server to NAS, multiple of them;
- may be used in Access-Request packets (as hints to the server only), multiple of them;
So it would seem that the NAS can include multiple of this attribute in the same message.
Someone can confirm this?
 
> b. May be the Framed-Compression attribute definition part should be
> left as is to align with RFC 2865. However a new attribute can be
> introduced to indicate NASs capability to the RADIUS server 
> w.r.t. ROHC.

Hummm, I still fail to see why one single value for ROHC isn't sufficient.
(simply because I don't understand, once explained I can surely change my mind)

> May be this attribute can have a bit-mask encoded value to indicate
> multiple ROHC scheme or ROHC profile support at the NAS.

Would you have to cover all the possible profiles/variants combinations? I probably don't understand the approach, since my understanding tells me that for each new profile specified, you'd have to define multiple new values... This does not make much sense to me...
  
> [KC>] I think it is useful to define separate values for 
> different ROHC profiles. In practice, a single value for
> ROHC may be too broad and NASs may not support all ROHC
> profiles. I would request you and others to chime in here.

Isn't it the job of the PROFILES negotiation? I would understand this as the only thing that the server needs to know is if ROHC PROFILES negotiation is supported somehow at the link protocol layer.
 
Could you elaborate on why this is useful/necessary?
Maybe also in the draft.

Yes, it would be good to have other's opinion on this.
I am not sure I am helping!

> [KC>] The supported set of ROHC profiles are negotiated between MN and
> the NAS. Hence, I would assume that the NAS would negotiate only those
> profiles with the MN that it supports and that are returned in the
> Access-Accept from the RADIUS server. Do you think we need this
> clarification in this ID?

Yes, it would be good to have.

/Ghyslain

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 18 Oct 2005 00:44:22 -0400

Hi Ghyslain,

Please see comments inline....

Thanks,
Kuntal

> From: Ghyslain Pelletier (LU/EAB)
[mailto:[email-masked]]
> Sent: Monday, October 17, 2005 9:39 AM
> To: Chowdhury, Kuntal; [email-masked]
> Cc: Seshadri, Arun
> Subject: RE: [rohc] new-ID: ROHC values for Framed-Compression
attribute
> 
> Kuntal,
> 
> Here I will go again with some naive questions regarding Radius and
what
> this draft is aiming to achieve.
> 
> See inline.
> 
> /Ghyslain
> 
> What is the relationship between the PROFILES negotiation happening at
the
> link protocol layer, and the exchange between the NAS and the RADIUS
> server? 
[KC>] The relationship is that the NAS is only supposed to negotiate the
ROHC profiles that are sent in the Access-Accept from the RADIUS server.
Depending on when the link layer negotiation takes place and whether the
link layer protocol allows for re-negotiation of parameters w/o
impacting the upper layers (e.g. PPP does not allow), the NAS and the
mobile node will agree on a set of profile that they will support for
the session.

On a second thought, may be we will be better off de-coupling the RADIUS
attribute from link layer specific Profile negotiation. We can say that
the NAS only activates/applies those ROHC profiles/variants that are
negotiated with the MN. The Framed-Compression attribute just conveys to
the NAS that the RADIUS server authorized the use of ROHC for the user.
What do you think?

> To what end does the RADIUS server use this information, wrt
> individual ROHC profile variants? I can understand that the Framed-
> Compression attribute would carry one identifier for a ROHC channel,
but
> am I missing the point with individual variants here. My understanding
> right now is that what the NAS sends to the server in the Framed-
> Compression attribute is a hint, and the server may ignore it.
> 
[KC>] Our original idea was to define a value for ROHC in the
Framed-Compression attribute. I think we should just define that and
keep the matter simple. Let the NAS and the MN negotiate any ROHC
profile that is supported at both ends.

> I guess I am not really clear with the purpose of this attribute with
> respect to ROHC, and specifically with respect to individual profiles
> and/or combinations thereof. And then I don't know RADIUS : (
> 
[KC>] The Framed-Compression attribute is used to apply specific header
compression on user's flows. The values for ROHC was missing form the
defined values, so we are trying to define it. I think the question is,
should we define ROHC values at a more granular level or we just define
a value for ROHC and leave it at that? I am OK with defining a single
value for ROHC and leave it at that.

> A quick search on this question led me to believe that
Framed-Compression
> attribute:
> - may be used in Access-Accept packets, from server to NAS, multiple
of
> them;
[KC>] The appearance of multiple Framed-Compression attribute in
Access-Request was not clear to me. The RFC is silent about it and I
guess we can assume it does allow inclusion of the same attribute more
than once (0+) in Access-Request.

> So it would seem that the NAS can include multiple of this attribute
in
> the same message.
[KC>] I will verify this on the radext mailing list.
 
> (simply because I don't understand, once explained I can surely change
my
> mind)
[KC>] As I noted above, I am OK to define one value for ROHC and let the
NAS and MN decide on the ROHC profile to use.

> Would you have to cover all the possible profiles/variants
combinations? I
> probably don't understand the approach, since my understanding tells
me
> that for each new profile specified, you'd have to define multiple new
> values... This does not make much sense to me...
> 
> Isn't it the job of the PROFILES negotiation? I would understand this
as
> the only thing that the server needs to know is if ROHC PROFILES
> negotiation is supported somehow at the link protocol layer.
> 
[KC>] Agree.

> Yes, it would be good to have.
[KC>] If we define one value for ROHC, this will not be an issue
anymore.

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 18 Oct 2005 12:41:18 +0200

Thanks for your clarifications!

> profile that is supported at both ends.

According to my current understanding, this seems to be the simplest and the most workable alternative.

/Ghyslain