Subject: Integration of QoS? AW: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2)

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Sep 2006 03:06:37 -0400

Hi Julien,
Hi Yoshi,

as part of the current charter we are working on two broad topics: 
mobility ad QoS

How would I combine MIP6 bootstrapping with QoS when, for example, 
additional AVPs have to be returned to the NAS/HA in the 
Diameter-EAP-Answer together with mobility specific parameters?

If I understood Yoshi right then he would define another 
Authorization/Accounting application for QoS and hence we would need 
three separate exchanges instead of one. Correct? How would we combine 
the QoS with DCC when real-time accounting?

Ciao
Hannes

PS: Ideally we would like to avoid too many dependencies between the 
different Diameter document. For example, we don't want to modify a 
bootstrapping document when RFC 4072 is updated. We don't want to write 
a new document when we realize that it would be useful to have QoS, 
Mobility & Credit Control combined.

 > -----Ursprüngliche Nachricht-----
 > Von: Julien Bournelle [mailto:[email-masked]]
 > Gesendet: Freitag, 15. September 2006 06:21
 > An: [email-masked]
 > Betreff: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID)
 > (polling part 2)
 >
 > Hi all,
 >
 >  this is a new polling concerning the ha-aaah interface for the Mobile
 >  IPv6 Boostrapping. To date, at the previous one, there was a
 >  consensus on moving forward with a new App-ID. But, yoshi has
 >  proposed an interesting idea that should be considered by the WG.
 >
 >  As you may recall, in the ha-aaah case, the MN is authenticated by
 >  EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH
 >  interface must, at least, be able to carry EAP packets. It
 > appears that
 >  we now have 2 options:
 >
 >  (1) We define a new Diameter application for Mobile IPv6 with a new
 >      App-ID that carry EAP packets as it is done in RFC 4072 (Diameter
 >      EAP) but Authorization and Accouting is specific to Mobile IPv6
 >      (thus the need for a new App-ID). The risk, as noted by yoshi, is
 >      that an update of the RFC4072 may result in an update of this
 >      application.
 >
 >
 >  (2) We define a new Diameter Application for Mobile IPv6 but which is
 >      used for Authorization and Accounting. We continue to use
 >      Diameter EAP fFrom [email-masked] Thu Sep 21 03:06:38 2006
Date: Thu, 21 Sep 2006 03:06:37 -0400
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Subject: Integration of QoS? AW: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID)
	(polling part 2)
Cc: [email-masked]

Hi Julien,
Hi Yoshi,

as part of the current charter we are working on two broad topics: 
mobility ad QoS

How would I combine MIP6 bootstrapping with QoS when, for example, 
additional AVPs have to be returned to the NAS/HA in the 
Diameter-EAP-Answer together with mobility specific parameters?

If I understood Yoshi right then he would define another 
Authorization/Accounting application for QoS and hence we would need 
three separate exchanges instead of one. Correct? How would we combine 
the QoS with DCC when real-time accounting?

Ciao
Hannes

PS: Ideally we would like to avoid too many dependencies between the 
different Diameter document. For example, we don't want to modify a 
bootstrapping document when RFC 4072 is updated. We don't want to write 
a new document when we realize that it would be useful to have QoS, 
Mobility & Credit Control combined.

 > -----Ursprüngliche Nachricht-----
 > Von: Julien Bournelle [mailto:[email-masked]]
 > Gesendet: Freitag, 15. September 2006 06:21
 > An: [email-masked]
 > Betreff: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID)
 > (polling part 2)
 >
 > Hi all,
 >
 >  this is a new polling concerning the ha-aaah interface for the Mobile
 >  IPv6 Boostrapping. To date, at the previous one, there was a
 >  consensus on moving forward with a new App-ID. But, yoshi has
 >  proposed an interesting idea that should be considered by the WG.
 >
 >  As you may recall, in the ha-aaah case, the MN is authenticated by
 >  EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH
 >  interface must, at least, be able to carry EAP packets. It
 > appears that
 >  we now have 2 options:
 >
 >  (1) We define a new Diameter application for Mobile IPv6 with a new
 >      App-ID that carry EAP packets as it is done in RFC 4072 (Diameter
 >      EAP) but Authorization and Accouting is specific to Mobile IPv6
 >      (thus the need for a new App-ID). The risk, as noted by yoshi, is
 >      that an update of the RFC4072 may result in an update of this
 >      application.
 >
 >
 >  (2) We define a new Diameter Application for Mobile IPv6 but which is
 >      used for Authorization and Accounting. We continue to use
 >      Diameter EAP for the Authentication. Thus the HA will use
 >      Diameter EAP with the AVP Auth-Request-Type set to
 >      AUTHENTICATE_ONLY and then the HA will use this MIP6 Application
 >      for Authorization/Accounting of the Mobile IPv6 service. This new
 >      application will have its own App-ID.
 >
 >      This would avoid to update the application if 4072 is updated and
 >      this could be a way to proceed if other applications need EAP for
 >      Authentication but have different needs for the Authorization and
 >      Accounting part.
 >
 >  Please indicate wether you prefer (1) or (2).
 >
 >  As in the previous polling:
 >  - it might be useful to state a reason for your decision.
 >  - indicate wether some aspects are still unclear to you.
 >
 >  Regards,
 >
 >  Julien
 >
 > _______________________________________________
 > DiME mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/dime
 >

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Sep 2006 04:55:10 -0400

Hi Hannes,

On Thu, Sep 21, 2006 at 03:06:37AM -0400, Hannes Tschofenig wrote:
> three separate exchanges instead of one. Correct? 

Yes, that is correct.  I would like to also note that those
applications as well as EAP application can be executed in parallel.
So it does not necessarily has a performance issue unlike you
mentioned in another email that summarizes the discussion.

> How would we combine 

I don't know what issue would arise when we run QoS and DCC as
different applications with real-time accounting.  Can you elaborate
on possible issue?

Yoshihiro Ohba