Subject: RE: AW: [NSIS] Re: authorizing query messages

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Mon, 10 Oct 2005 17:17:04 -0400

Hi, Hanes and all:

I think that this is one of the important points that we need to
consider here for authorization using DIAMETER (as Dave pointed out).

The DIAMETER server needs to authorize QoS resources (which is also
coupled with authentication). If the "amount" of QoS resources of each
kind (e.g., audio, video, data) are considered, QSPEC needs to be used
(by the way, NOT the QoS models because QoS models are coupled with
"domains" and NSIS is not dealing with domains per se).

So, the point is this: DIAMETR QoS application support also needs to be
augmented with the "generalized" QSPEC.

As I explained before, the support of specific QoS models do not
automatically mean the support of the "generalized" QSPEC, DIAMETER QoS
application also needs to be extended for each QoS model. 

Going further, DIAMETER SIP application standard also needs to be
coupled with this from the application QoS signaling point of view. 

Anyway, this is NOT rocket science as people are dealing with these
kinds things on end-to-end basis using SIP, RADIUS/DIAMETR, RSVP,  and
DiffServ for implementations as standards have NOT progressed to support
those completely yet.

Any comments?

Best regards,
Radhika

PS: By the way, do people understand now how QoS models that deal with
certain domains based on certain specific values of each QoS parameter
make the "generalized" QSPEC templates messy if the same QSPEC draft
deals with both?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David R Oran
Sent: Monday, October 10, 2005 10:52 AM
To: Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner;
[email-masked]
Subject: Re: AW: [NSIS] Re: authorizing query messages

Do you think it makes sense to have the authorization response to the  
query return a QSPEC with the user's authorized resources so that can  
be returned along with the available resources (or alternatively used  
by the NSLP to reduce the reported available resources to only the  
amount authorized?

On Oct 6, 2005, at 11:37 AM, Tschofenig, Hannes wrote:

> hi jukka,
>
> thanks for your feedback. here is a proposal how to handle  
> authorization
> for the query message:
>
> the query message triggers a QAR with the authentication info but
> without any QoS-Resources.
> it might be necessary to indicate (somewhere) that this is only a  
> query
> without the need to enable accounting and charging.
>
> as such, the response in the QAA is also limited to the result rather
> than returning information like avps like CC-Time,Cost,
> QoS-Resources,Authz-time).
>
> here is the figure:
>
>    End-Host         Network Element             Entity
>   requesting QoS      ( Diameter              ( Diameter
>                        QoS Client)             QoS Server)
>       |                   |                         |
>       +---QoS-Query------>|                         |
>       |                   +- - - - - QAR - - - - - >|
>       |                   |(QoS-Resources=NULL,     |
>       |                   |   QoS-Auth-Data,User-ID)|
>       |                   |                +--------+--------------+
>       |                   |                |  Authorize request    |
>       |                   |                |  Keep no session data |
>       |                   |                |                       |
>       |                   |                +--------+--------------+
>       |                   |< - - - - QAA - - - - - -+
>       |                   |(Result-Code)            |
>       |                   |                         |
>       |           +-------+---------+
>       |           |Proceeed with    |
>       |           |QoS signaling    |
>       |           |exchange         |
>       |           +-------+---------+
>       |                   |
>       |                   +----------QoS-Reserve--------------->
>       |                   |
>       |                   |<---------QoS-Response---------------
>       |<--QoS-Response----+
>
>
> ciao
> hannes
>
>
>
>> Hi,
>>
>> I would expect that in certain networks, not everybody may query the
>> network of available resources. Thus, there could be need to
>> include an
>> auhtorization token, or ask from a Diameter server whether the node
>> sending the query is allowed to do that.
>>
>> Cheers,
>> Jukka
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Nguyen, An" <[email-masked]>
Date: Wed, 12 Oct 2005 13:09:18 -0400

David,

Just a question: Do we need to enhance
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-09.txt
to include QSPEC if you we decide to use DIAMETER to perform the
authorization for users' resources?

Thanks,

An
-----Original Message-----
From: David R Oran [mailto:[email-masked]]
Sent: Monday, October 10, 2005 10:52 AM
To: Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner;
[email-masked]

On Oct 6, 2005, at 11:37 AM, Tschofenig, Hannes wrote:

>> On Thu, 6 Oct 2005, Hannes Tschofenig wrote:
>>
>>
>>
>>> hi all,
>>>
>>> as part of our work on the diameter-qos application and the
>>>
>>>
>> radius-qos draft
>>
>>
>>> we came across the aspect of authorizing individual types
>>>
>>>
>> of actions taken by
>>
>>
>>> the qos signaling protocol. from discussions in the past i
>>>
>>>
>> remember that
>>
>>
>>> people wanted to authorize query messages as well. when we
>>>
>>>
>> come to the
>>
>>
>>> concrete details we are not quite sure what it actually
>>>
>>>
>> means. what would be
>>
>>
>>> the authorization decision regarding the query message
>>>
>>>
>> people have in mind?
>>
>>
>>>
>>> ciao
>>> hannes
>>>
>>>
>>>
>>>
>>>
>>

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 13 Oct 2005 10:42:54 +0200

hi an, 

let me tell you my view on this issue. 

carrying only the qspec parameter is not sufficient for the
authorization decision. you need todo more as you see in the document
(and more stuff will certainly follow -- based on the reviewers feedback
we recently received). you might not want to dump almost all
diameter-qos parameters into the diameter-sip document. instead, it
might be better to see how they interwork just like the diameter-sip
application needs to interwork with other diameter applications as well.
this is a bit more complex compared to radius where you can just dump
the desired parameter into a message since the concept of an application
is not defined. for the diameter-qos application we investigated the
interworking with other applications, such as nasreq and credit control.
this might be another application to take a look at. 

in the past we had a few discussions discussions how to map the qos
specific parameters in the sdp to the qspec. within the sdp payloads
only bandwidth parameters are carried. the 3gpp additionally uses
further parameters in addition to the bandwidth parameters but they are
determined based on codec information and bearer information. 
as such, it was difficult to show a good mapping by investigating only
the ietf work. 

ciao
hannes

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 13 Oct 2005 10:42:01 +0200

hi david, 

> by the NSLP to reduce the reported available resources to only the  
if the query message triggers a diameter interaction then it might be
useful to provide this type of information. 
does not sound like a bad idea. it might, however, raise some additional
questions: 
- should the diameter client cache this information to shorten the
authorization protocol interaction for a subsequently received reserve
message? 
- how long should the diameter client cache a response (if at all)?  
- is the response related to a particular flow only or also valid for
other flows? 

ciao
hannes

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Thu, 13 Oct 2005 09:38:43 -0400

An:
 
I do NOT think that Diameter SIP application is the right place to do so. There are several steps to do so as follows:

1.	
	QSPEC is not an application per se. It is mere couple of QoS parameters (please note that it is NOT QoS model - it is extremely technically confusing as well as technically inconsistent to mix QSPEC and QoS Model in the same breath/place).
2.	
	A QSPEC cannot independently sent in the middle of something unless it is coupled with to meet any application's needs.
3.	
	SIP is only ONE real-time application, and however, QSPEC is good for all applications including both real-time and non-real-time applications.
4.	
	Diameter QoS Application is the right place for extending this using QSPEC (again NOT QoS models).
5.	
	If item 3 can use item 4, it will then prove all standards Diameter-based standards are consistent.
6.	
	With respect to NSIS signaling protocol, item 5 will also test whether or not NSIS protocol is good or not.

Hope this clarifies your question.

If you have any more questions, please let me know.

Best regards,
Radhika

________________________________

From: [email-masked] on behalf of Nguyen, An
Sent: Wed 10/12/2005 1:09 PM
To: 'David R Oran'; Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; [email-masked]
Subject: RE: AW: [NSIS] Re: authorizing query messages

David,

Thanks,

An
-----Original Message-----
From: David R Oran [mailto:[email-masked]]
Sent: Monday, October 10, 2005 10:52 AM
To: Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner;
[email-masked]

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Thu, 13 Oct 2005 15:37:07 -0400

An and Hannes:
 
Kindly see my earlier email related to this.
 
In addition, I like to add couple of points related to Hannes comments as follows:

1.	
	It is desirable to have all the QoS parameters of QSPEC to be authorized. If something is missing in Diameter QoS application or vice versa, we need to augment those.
2.	
	Diameter QoS application does not need to use QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters within the Diameter QoS application protocol. If any QoS parameters or exact semantics are missing in Dia QoS, Dia QoS needs to be extended for only those.
3.	
	Once items 1 and 2 are taken care of, authorization/authentication will be taken care of by basic Diameter protocol (depending on which application [e.g., SIP, FTP, etc.] will invoke QoS.
4.	
	With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS, we do not need to worry about this. All we need to see whether all the QoS parameters expressed in SDP have the place holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth is there. If it is so, we are on the safe side because Dia QoS/QSPEC can support this. In the future, we hope that SDP QoS parameters can be extended to delay, jitter, packet loss, etc. based on the QoS needs of each codec type. Until that happens, let us wait.
5.	
	By the way, I would like to later how SIP, NSIS signaling protocol, and Diameter SIP application and Diameter QoS application are integrated on end-to-end basis. (Note: We have done our home work for probable implementation after studying the modeling and simulations results [sorry - not to be publicly released] and test-bed [NSIS protocol NOT yet] in controlled environments, but I am waiting how the standard works progress. Later on, we hope to implement for the worldwide network that will include MANET as the access network.)

The point that I like to make is this: QSPEC Authorization/Authentication is NOT a big deal. It is straight forward as describe above.

If An has any problems, let me know.
 
Best regards,
Radhika

From: [email-masked] on behalf of Tschofenig, Hannes
Sent: Thu 10/13/2005 4:42 AM
To: Nguyen, An; David R Oran
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; [email-masked]
Subject: AW: AW: [NSIS] Re: authorizing query messages

hi an,

in the past we had a few discussions how to map the qos

ciao
hannes

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Thu, 13 Oct 2005 16:19:46 -0400

Hi, An:
 
I also see that there is no direct work on Diameter QoS application unless something new is started in this area. Or, am I missing something?
 
The other thing is that we can assume that QSPEC is authorized using AAA (e.g., Diameter) protocol. In this cae, the standards development for authorization of QSPEC using AAA protocl falls under the charter of AAA WG, not a part of NSIS.
 
Best regards,
Radhika

From: [email-masked] on behalf of Roy, Radhika (AEAD)
Sent: Thu 10/13/2005 3:37 PM
To: Tschofenig, Hannes; Nguyen, An
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; [email-masked]
Subject: RE: AW: [NSIS] Re: authorizing query messages

An and Hannes:

1.	

 
Best regards,
Radhika

hi an,

ciao
hannes

---

From: "Nguyen, An" <[email-masked]>
Date: Thu, 13 Oct 2005 16:30:26 -0400

Roy,
 
No, I don't have any problems. By the way, I would like to see how SIP, NSIS
signaling protocol , Diameter SIP application and Diameter QoS application
whill be integrated to provide end-to-end QoS also.
 
Regards,
 
An

-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:[email-masked]]
Sent: Thursday, October 13, 2005 3:37 PM
To: Tschofenig, Hannes; Nguyen, An
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; [email-masked]
Subject: RE: AW: [NSIS] Re: authorizing query messages

An and Hannes:

In addition, I like to add couple of points related to Hannes comments as
follows:

1.	

	It is desirable to have all the QoS parameters of QSPEC to be
authorized. If something is missing in Diameter QoS application or vice
versa, we need to augment those.
2.	

	Diameter QoS application does not need to use QSPEC per se. It needs
to carry the abstract of QSPEC QoS parameters within the Diameter QoS
application protocol. If any QoS parameters or exact semantics are missing
in Dia QoS, Dia QoS needs to be extended for only those.
3.	

	Once items 1 and 2 are taken care of, authorization/authentication
will be taken care of by basic Diameter protocol (depending on which
application [e.g., SIP, FTP, etc.] will invoke QoS.
4.	

	With respect to mapping of SIP/SDP QoS parameters mapping into Dia
QoS, we do not need to worry about this. All we need to see whether all the
QoS parameters expressed in SDP have the place holder in Dia QoS (indirectly
QSPEC QoS). At present, as Hannes mentioned, only bandwidth is there. If it
is so, we are on the safe side because Dia QoS/QSPEC can support this. In
the future, we hope that SDP QoS parameters can be extended to delay,
jitter, packet loss, etc. based on the QoS needs of each codec type. Until
that happens, let us wait.
5.	

	By the way, I would like to later how SIP, NSIS signaling protocol,
and Diameter SIP application and Diameter QoS application are integrated on
end-to-end basis. (Note: We have done our home work for probable
implementation after studying the modeling and simulations results [sorry -
not to be publicly released] and test-bed [NSIS protocol NOT yet] in
controlled environments, but I am waiting how the standard works progress.
Later on, we hope to implement for the worldwide network that will include
MANET as the access network.)

The point that I like to make is this: QSPEC Authorization/Authentication is
NOT a big deal. It is straight forward as describe above.

Best regards,
Radhika
  _____  

hi an,

ciao
hannes

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Thu, 13 Oct 2005 18:17:22 -0400

Hi, An:
 
OK, let us start working on this item - how NSIS signaling protocol, Diameter SIP application and Diameter QoS application work in an integrated way.
 
By the way, do you have any clue about the Diameter QoS application as I indicate in my earlier email?
 
Best regards,
Radhika

From: Nguyen, An [mailto:[email-masked]]
Sent: Thu 10/13/2005 4:30 PM
To: Roy, Radhika (AEAD); Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; [email-masked]; Nguyen, An
Subject: RE: AW: [NSIS] Re: authorizing query messages

Roy,
 
No, I don't have any problems. By the way, I would like to see how SIP, NSIS signaling protocol , Diameter SIP application and Diameter QoS application whill be integrated to provide end-to-end QoS also.
 
Regards,
 
An

	-----Original Message-----
	From: Roy, Radhika (AEAD) [mailto:[email-masked]]
	Sent: Thursday, October 13, 2005 3:37 PM
	To: Tschofenig, Hannes; Nguyen, An
	Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; [email-masked]
	Subject: RE: AW: [NSIS] Re: authorizing query messages

	An and Hannes:

	1.	

	 
	Best regards,
	Radhika

	hi an,

	
	
	ciao
	hannes

---

From: [email-masked]
Date: Fri, 14 Oct 2005 10:13:50 +0300

An,

>to include QSPEC if you we decide to use DIAMETER to perform 
>the authorization for users' resources?

Authorizing QoS reservations is something that is a work-in-progress.
There have
been some discussions of this topic in both the AAA and RADext working
group.  
At a highlevel, it would be good to have some common format for coding
QoS
reservations which can be reused for AAA-systems for Authorization &
Accounting
purposes, but this is very much a work-in-progress.

thanks,
John

---

From: "Nguyen, An" <[email-masked]>
Date: Mon, 17 Oct 2005 09:30:28 -0400

<http://www.tschofenig.priv.at/drafts/draft-alfano-aaa-qosprot-04.html> Roy,
 
Correct me if I am wrong!. I think you were talking abou this:
 
 <http://www.tschofenig.priv.at/drafts/draft-alfano-aaa-qosprot-04.html>
http://www.tschofenig.priv.at/drafts/draft-alfano-aaa-qosprot-04.html
 
An

-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:[email-masked]]
Sent: Thursday, October 13, 2005 6:17 PM
To: Nguyen, An; Tschofenig, Hannes
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; [email-masked]
Subject: RE: AW: [NSIS] Re: authorizing query messages

Hi, An:
 
OK, let us start working on this item - how NSIS signaling protocol,
Diameter SIP application and Diameter QoS application work in an integrated
way.
 
By the way, do you have any clue about the Diameter QoS application as I
indicate in my earlier email?
 
Best regards,
Radhika

  _____  

Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; [email-masked];
Nguyen, An

Roy,

Regards,
 
An

-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:[email-masked]]
Sent: Thursday, October 13, 2005 3:37 PM
To: Tschofenig, Hannes; Nguyen, An
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; [email-masked]
Subject: RE: AW: [NSIS] Re: authorizing query messages

An and Hannes:

1.	

 
Best regards,
Radhika
  _____  

hi an,

ciao
hannes

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Mon, 17 Oct 2005 10:15:04 -0400

An:

I got it, and let us work on this document for authorization where QSPEC
needs to be integrated per suggestions provided in other emails. In
addition, SIP, Diameter QoS applications, and NSIS QoS signaling
protocol need to be used on end-to-end basis. By the way, FW/NAT
crossing will also to be included with NSIS works along with STUN.

I appreciated for your pointer to the AAA QoS draft. I also got the url
of this draft in the IETF-Draft section:
http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-04.txt

Let me provide another IETF draft on QoS model:
http://user.informatik.uni-goettingen.de/~fu/nsis/cls_qosm/draft-kappler
-nsis-qosmodel-controlledload-03.txt

The beauty of this QoS model is that, unlike so-called ITU's Y.series
QoS models, it uses IETF IntServ's QoS model that does not depend on any
specific values of any performance parameters. That is, any values of
any QoS parameters can be used with the NSIS QoS signaling protocol.

Now, you can see how the co-authors/co-editors of the QSPEC draft are
technically inconsistent to include so called value-specific Y-series
QoS models in the draft, but do not include the non-QoS-value-specific
IETF's IntServ QoS models.

Then the question comes: Why does QSPEC draft not DELETE those so-called
QoS-value-specific QoS models that are creating so much technical
confusions? Why do they not create separate QoS model-specific drafts
for Y.xxxx and others like that of the Kappler draft to remove all
technical confusions of the QSPEC draft?

Best regards,

Radhika

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 17, 2005 9:30 AM
To: Roy, Radhika (AEAD); Nguyen, An
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner;
[email-masked]; Tschofenig, Hannes
Subject: RE: AW: [NSIS] Re: authorizing query messages

Roy, <http://www.tschofenig.priv.at/drafts/draft-alfano-aaa-qosprot-04.html>

An

	-----Original Message-----
	From: Roy, Radhika (AEAD) [mailto:[email-masked]]
	Sent: Thursday, October 13, 2005 6:17 PM
	To: Nguyen, An; Tschofenig, Hannes
	Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner;
[email-masked]

	Hi, An:

	OK, let us start working on this item - how NSIS signaling
protocol, Diameter SIP application and Diameter QoS application work in
an integrated way.

	By the way, do you have any clue about the Diameter QoS
application as I indicate in my earlier email?

	Best regards,

	Radhika

[email-masked]; Nguyen, An

	Roy,

	No, I don't have any problems. By the way, I would like to see
how SIP, NSIS signaling protocol , Diameter SIP application and Diameter
QoS application whill be integrated to provide end-to-end QoS also.

	Regards,

	An

		-----Original Message-----
		From: Roy, Radhika (AEAD)
[mailto:[email-masked]]
		Sent: Thursday, October 13, 2005 3:37 PM
		To: Tschofenig, Hannes; Nguyen, An
		Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ
Manner; [email-masked]
		Subject: RE: AW: [NSIS] Re: authorizing query messages

		An and Hannes:

		In addition, I like to add couple of points related to
Hannes comments as follows:

		1.	It is desirable to have all the QoS parameters
of QSPEC to be authorized. If something is missing in Diameter QoS
application or vice versa, we need to augment those.

		2.	Diameter QoS application does not need to use
QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters
within the Diameter QoS application protocol. If any QoS parameters or
exact semantics are missing in Dia QoS, Dia QoS needs to be extended for
only those.

		3.	Once items 1 and 2 are taken care of,
authorization/authentication will be taken care of by basic Diameter
protocol (depending on which application [e.g., SIP, FTP, etc.] will
invoke QoS.

		4.	With respect to mapping of SIP/SDP QoS
parameters mapping into Dia QoS, we do not need to worry about this. All
we need to see whether all the QoS parameters expressed in SDP have the
place holder in Dia QoS (indirectly QSPEC QoS). At present, as Hannes
mentioned, only bandwidth is there. If it is so, we are on the safe side
because Dia QoS/QSPEC can support this. In the future, we hope that SDP
QoS parameters can be extended to delay, jitter, packet loss, etc. based
on the QoS needs of each codec type. Until that happens, let us wait.

		5.	By the way, I would like to later how SIP, NSIS
signaling protocol, and Diameter SIP application and Diameter QoS
application are integrated on end-to-end basis. (Note: We have done our
home work for probable implementation after studying the modeling and
simulations results [sorry - not to be publicly released] and test-bed
[NSIS protocol NOT yet] in controlled environments, but I am waiting how
the standard works progress. Later on, we hope to implement for the
worldwide network that will include MANET as the access network.)

		The point that I like to make is this: QSPEC
Authorization/Authentication is NOT a big deal. It is straight forward
as describe above.

		Best regards,

		Radhika

		From: [email-masked] on behalf of Tschofenig,
Hannes
		Sent: Thu 10/13/2005 4:42 AM
		To: Nguyen, An; David R Oran
		Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ
Manner; [email-masked]
		Subject: AW: AW: [NSIS] Re: authorizing query messages

		hi an,

		carrying only the qspec parameter is not sufficient for
the
		authorization decision. you need todo more as you see in
the document
		(and more stuff will certainly follow -- based on the
reviewers feedback
		we recently received). you might not want to dump almost
all
		diameter-qos parameters into the diameter-sip document.
instead, it
		might be better to see how they interwork just like the
diameter-sip
		application needs to interwork with other diameter
applications as well.
		this is a bit more complex compared to radius where you
can just dump
		the desired parameter into a message since the concept
of an application
		is not defined. for the diameter-qos application we
investigated the
		interworking with other applications, such as nasreq and
credit control.
		this might be another application to take a look at.
		
		in the past we had a few discussions how to map the qos
		specific parameters in the sdp to the qspec. within the
sdp payloads
		only bandwidth parameters are carried. the 3gpp
additionally uses
		further parameters in addition to the bandwidth
parameters but they are
		determined based on codec information and bearer
information.
		as such, it was difficult to show a good mapping by
investigating only
		the ietf work.
		
		ciao
		hannes

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 17 Oct 2005 16:26:27 +0200

hi roy, 
 
thanks for the feedback. please see my comments inline:

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Donnerstag, 13. Oktober 2005 21:37
An: Tschofenig, Hannes; Nguyen, An
Cc: McDonald, Andrew; Georgios Karagiannis; Jukka MJ Manner; [email-masked]
Betreff: RE: AW: [NSIS] Re: authorizing query messages

An and Hannes:

1.	

	Diameter QoS application does not need to use QSPEC per se. It needs to carry the abstract of QSPEC QoS parameters within the Diameter QoS application protocol. If any QoS parameters or exact semantics are missing in Dia QoS, Dia QoS needs to be extended for only those 

it is a matter of taste whether you create your own object or to reuse the same object for carrying the qos specific parameters (if the semantic is the same). 
we have chosen one approach but someone else might use a different approach.  

3.	

we aim to make the aaa interaction independent of the qos signaling protocol. whether this is possible in all cases is subject for future work. 
for the design of the diameter application one might reuse different applications. you might want to review the current design. 
 
4.	

currently it seems that the mapping is straight forward. 
 
5.	

further work is required to document these issues. the only document i am aware of is a document written by martin that described the interworking between the natfw nslp and sip signaling but this was some time back. 

 
i am not sure what you mean by "big deal". it is a lot of work to put things together and to describe them in a consistent way. we tried todo this with the diameter-qos application (and with all our other documents).
 
ciao
hannes

Best regards,
Radhika
  _____  

hi an,

ciao
hannes

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 17 Oct 2005 16:27:40 +0200

# hi roy, 

Hi, An:

I also see that there is no direct work on Diameter QoS application
unless something new is started in this area. Or, am I missing
something?
# i am not quite sure what you mean. 
# have you read the diameter-qos application?

The other thing is that we can assume that QSPEC is authorized using AAA
(e.g., Diameter) protocol. In this cae, the standards development for
authorization of QSPEC using AAA protocl falls under the charter of AAA
WG, not a part of NSIS.

# that's subject for discussion between the chairs and the area
directors. 

# ciao
# hannes

Best regards,
Radhika

An and Hannes:

In addition, I like to add couple of points related to Hannes comments
as follows:
It is desirable to have all the QoS parameters of QSPEC to be
authorized. If something is missing in Diameter QoS application or vice
versa, we need to augment those.
Diameter QoS application does not need to use QSPEC per se. It needs to
carry the abstract of QSPEC QoS parameters within the Diameter QoS
application protocol. If any QoS parameters or exact semantics are
missing in Dia QoS, Dia QoS needs to be extended for only those.
Once items 1 and 2 are taken care of, authorization/authentication will
be taken care of by basic Diameter protocol (depending on which
application [e.g., SIP, FTP, etc.] will invoke QoS.
With respect to mapping of SIP/SDP QoS parameters mapping into Dia QoS,
we do not need to worry about this. All we need to see whether all the
QoS parameters expressed in SDP have the place holder in Dia QoS
(indirectly QSPEC QoS). At present, as Hannes mentioned, only bandwidth
is there. If it is so, we are on the safe side because Dia QoS/QSPEC can
support this. In the future, we hope that SDP QoS parameters can be
extended to delay, jitter, packet loss, etc. based on the QoS needs of
each codec type. Until that happens, let us wait.
By the way, I would like to later how SIP, NSIS signaling protocol, and
Diameter SIP application and Diameter QoS application are integrated on
end-to-end basis. (Note: We have done our home work for probable
implementation after studying the modeling and simulations results
[sorry - not to be publicly released] and test-bed [NSIS protocol NOT
yet] in controlled environments, but I am waiting how the standard works
progress. Later on, we hope to implement for the worldwide network that
will include MANET as the access network.)
The point that I like to make is this: QSPEC
Authorization/Authentication is NOT a big deal. It is straight forward
as describe above.

Best regards,
Radhika

hi an,

ciao
hannes

---

From: "Nguyen, An" <[email-masked]>
Date: Mon, 17 Oct 2005 11:10:09 -0400

Hannes,

Thanks for your clarification. See inlines.

An
>From: Tschofenig, Hannes [mailto:[email-masked]]
>Sent: Monday, October 17, 2005 10:28 AM

Understood. 

>authorization of QSPEC using AAA protocl falls under the charter of AAA

Agreed. I just want to see the QSPEC authorization/authentication work gets
done somewhere. 

# ciao
# hannes

Best regards,
Radhika

An and Hannes:

Best regards,
Radhika

hi an,

ciao
hannes