Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call

From: "ASH, GERALD R \(JERRY\), SBCLABS" <[email-masked]>
Date: Fri, 2 Feb 2007 18:37:36 -0600

Certainly this ID is very relevant to the discussion.  According to the
ID, the QoS NSLP state machine only receives 2 types of information from
the RMF:

RMF():Performs Resource Management Function and returns the following
      values{AVAIL, NO_AVAIL}. 

Therefore it is not possible to trigger different QoS NSLP message
responses when the QoS NSLP is in a particular state, based on input
from the RMF that is dependent on the particular QOSM being used by the
RMF.  

As illustrated in Cornelia's slide 2 (3rd bullet) example in the
attached, what RMD is doing would appear to be precluded by the current
QoS NSLP state machine, i.e.:

"This is a tearing RESERVE and the RMF tells me that the RMD control
info says to not generate a new message" -> needed by RMD for partial
resv. Release

Since this behavior deviates from the defined QoS NSLP State Machine, as
John says, "If the QOSM has a different state machine, then that QoSM
MUST be a Standards Track document that extends the QoS NSLP."

Thanks,
Jerry

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, February 02, 2007 11:26 AM
To: Kappler, Cornelia
Cc: Martin Stiemerling; Georgios Karagiannis; nsis
Subject: State Machines .... was [NSIS] Summary of QSPEC call

Hi all,

let me repeat again what I said during the phone conference call.

The QoS NSLP implicitly contains a state machine and an explicit 
description of the QoS NSLP state machine can be found in:
http://tools.ietf.org/wg/nsis/draft-fu-nsis-qos-nslp-statemachine-05.txt
http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-statemachine-
05.pdf

The QoS NSLP alone is not useful. In order todo something it needs to 
(a) carry some QoS parameters with the corresponding meaning and (b) the

state transitions need to be triggered. These triggers might come from 
various sources. Some of the triggers have been discussed in the context

of RMD when an edge node of an RMD domain receives an end-to-end 
signaling message. Some actions might have to be taken within the RMD 
domain based on this incoming message. The type of message, the content 
of the QoS parameters, security parameters, the reservation state within

the RMD domain, etc. influence the decision making process.

The QoSM has its own state machine and it interacts with the QoS NSLP 
whereby these actions have to fit to the QoS NSLP state machine but 
there is a lot of freedom since the QoS NSLP just defines basic message 
patterns.

Hence, when someone says that the QoSM MUST NOT modify the QoS NSLP 
state machine it would be good to be very explicit what that actually 
means.

This procdure of interworking between different state machines at 
different components is nothing new. Diameter (RFC 3588 and the 
applications) and EAP - EAP methods do the same.

Ciao
Hannes

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 03 Feb 2007 14:42:36 -0500

Hi Jerry,

draft-fu-nsis-qos-nslp-statemachine-05.txt is an informational proposal. 
Node internal interactions haven't received a lot of attention given that the QoS NSLP also just hints the API in the appendix as informational. The current state machine document does not go into lot of details with any local node dependent functions, including security and AAA interactions.  

I will, however, investigate Cornelia's thoughts to determine whether there is a problem. 

Ciao
Hannes

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 5 Feb 2007 11:08:08 +0100

Hi Jerry

Please note that any QOSM describes the functionality 
of RMF, thus it uses a different QOSM state machine that 
is different than the QoS-NSLP state machine. 

Furthermore, as Hannes emphasized in his e-mails the 
current QoS-NSLP state machine document is an Informational RFC 
and it does not go into lot of details with any local node 
dependent functions, including QOSM, security and AAA interactions.

Regarding the following paragraph, as I mentioned during the telephone
conference 
meeting, the following RMD feature can be questionable and therefore 
we will change it.

> As illustrated in Cornelia's slide 2 (3rd bullet) example in 
> the attached, what RMD is doing would appear to be precluded 
> by the current QoS NSLP state machine, i.e.:
> 
> "This is a tearing RESERVE and the RMF tells me that the RMD 
> control info says to not generate a new message" -> needed by 
> RMD for partial resv. Release 

However, all other features included in the RMD-QOSM  and in all other
existing 
QOSMs can be and should be supported by the current QoS-NSLP functionality.

Best Regards,
Georgios

> From: ASH, GERALD R (JERRY), SBCLABS [mailto:[email-masked]] 
> Sent: zaterdag 3 februari 2007 1:38
> To: Hannes Tschofenig; nsis
> Cc: ASH, GERALD R (JERRY), SBCLABS
> Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call
> 
> Certainly this ID is very relevant to the discussion.  
> According to the ID, the QoS NSLP state machine only receives 
> 2 types of information from the RMF:
> 
> Therefore it is not possible to trigger different QoS NSLP 
> message responses when the QoS NSLP is in a particular state, 
> based on input from the RMF that is dependent on the 
> particular QOSM being used by the RMF.  
> 
> As illustrated in Cornelia's slide 2 (3rd bullet) example in 
> the attached, what RMD is doing would appear to be precluded 
> by the current QoS NSLP state machine, i.e.:
> 
> "This is a tearing RESERVE and the RMF tells me that the RMD 
> control info says to not generate a new message" -> needed by 
> RMD for partial resv. Release
> 
> Since this behavior deviates from the defined QoS NSLP State 
> Machine, as John says, "If the QOSM has a different state 
> machine, then that QoSM MUST be a Standards Track document 
> that extends the QoS NSLP."
> 
> Thanks,
> Jerry
> 
> The QoS NSLP implicitly contains a state machine and an 
> explicit description of the QoS NSLP state machine can be found in:
> state transitions need to be triggered. These triggers might 
> come from various sources. Some of the triggers have been 
> discussed in the context
> 
> of RMD when an edge node of an RMD domain receives an 
> end-to-end signaling message. Some actions might have to be 
> taken within the RMD domain based on this incoming message. 
> The type of message, the content of the QoS parameters, 
> security parameters, the reservation state within
> 
> The QoSM has its own state machine and it interacts with the 
> QoS NSLP whereby these actions have to fit to the QoS NSLP 
> state machine but there is a lot of freedom since the QoS 
> NSLP just defines basic message patterns.
> 
> Hence, when someone says that the QoSM MUST NOT modify the 
> QoS NSLP state machine it would be good to be very explicit 
> what that actually means.
> 
> This procdure of interworking between different state 
> machines at different components is nothing new. Diameter 
> (RFC 3588 and the

---

From: <[email-masked]>
Date: Mon, 5 Feb 2007 11:16:34 -0600

Georgios,

>Please note that any QOSM describes the functionality of RMF, 
>thus it uses a different QOSM state machine that is different 
>than the QoS-NSLP state machine. 

I disagree.  All QoSM need to use the state machine as defined in
the QoS NSLP.  If a QoSM changes the state machine of the QoS NSLP,
then it must do so via a Standards Track RFC which extends the
QoS NLSP.

The RMF will have its own state machine, based upon which QoSM it
is using, but the RMF functionality should be defined upon in the
QoSM which is specifying it.

Overall, QoSM are not assumed to change the General Processing rules
as defined in section 5.2.  If it does, then the QoSM is extending
the QoS NSLP.  

John

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 6 Feb 2007 10:10:16 +0100

Hi John, 

I think Georgios is saying that the state machine of the QoS NSLP and the QoSM are different but they need to work together. 

Let me compare this with EAP and EAP methods:

EAP has a state machine and the same is true for EAP methods. RFC 4137 even describes the EAP state machine.
Both, the EAP and the EAP method state machine, need to work together and the EAP method state machine cannot trigger messages that are not allowed in the EAP state machine.

For example, an EAP method cannot force an EAP peer to send a EAP-Failure towards the EAP server since the EAP state machine only allows the message to be sent from the EAP server to the EAP client. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Gesendet: Montag, 5. Februar 2007 18:17
> An: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Betreff: RE: State Machines .... was [NSIS] Summary of QSPEC call
> 
> Georgios,
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 6 Feb 2007 10:18:24 +0100

Hi John

> [Georgios] Please note that any QOSM describes the functionality of 
> RMF, thus it 
> >uses a different QOSM state machine that is different than 
> the QoS-NSLP 
> >state machine.
> 
> [John] I disagree.  All QoSM need to use the state machine as 
> defined in the QoS NSLP.  If a QoSM changes the state machine 
> of the QoS NSLP, then it must do so via a Standards Track RFC 
> which extends the QoS NLSP.

Do you agree that the QOSM and the QOS-NSLP are 
supporting two different functionalities.
Thus the QOSM has its own state machine and the 
QOS-NSLP has its own state machine.

Have we followed a different telephone conference meeting?

During the telephone conference meeting we have agreed that the 
RMF triggers can change the reaction of the QOS-NSLP.
We have also agreed that QOSMs all utilize the
state machines of the underlying NSIS protocols and are 
not expected to re-define or extend these. Note that 
a QOSM can however, extend the RMF triggers to/from 
the QOS-NSLP functionality, which might affect the QoS-NSLP state machine.

Maybe the last sentence is not exactly the same as the words 
that I have proposed during the meeting, but the semantics are.

> [John] Overall, QoSM are not assumed to change the General 
> Processing rules as defined in section 5.2.  If it does, then 
> the QoSM is extending the QoS NSLP.  

Now regarding the above, I agree, but I think that this is something 
different than saying that the QOS-NSLP state machine should not be changed.

Please note that the unidirectional/bidirectional and sender/receiver 
reservation intiation, refresh, tear, modification of the following 
scenarios are not described in the QOS-NSLP:
bound and parallel end-to-end and end-to-end sessions
bound and parallel end-to-end and edge-to-edge sessions
bound and parallel end-to-end and end-to-edge sessions

* Examples of QOSMs that support end-to-end sessions can be:
Intserv like Controlled Load QOSM
Intserv like Guaranteed Service QOSM

* Examples of QOSMs that can support edge-to-edge sessions can be:
RSVP aggregation like QOSM
RMD-QOSM
interdomain and intra-domain ITU-T RACF QoS model
PCN like congestion notifictaion and preemption QoS model.
RSVP-TE like QOSM

* Examples of QOSMs that can support end-to-edge sessions:
IEEE 802.16

The reason of this is that the QOS-NSLP does not go into lot of details 
with any local node dependent functions, including QOSM functionality, 
security and AAA interactions. 

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: maandag 5 februari 2007 18:17
> To: [email-masked]; [email-masked]; 
> >Please note that any QOSM describes the functionality of 
> RMF, thus it 
> >uses a different QOSM state machine that is different than 
> the QoS-NSLP 
> >state machine.
> 
> I disagree.  All QoSM need to use the state machine as 
> defined in the QoS NSLP.  If a QoSM changes the state machine 
> of the QoS NSLP, then it must do so via a Standards Track RFC 
> which extends the QoS NLSP.
> 
> The RMF will have its own state machine, based upon which 
> QoSM it is using, but the RMF functionality should be defined 
> upon in the QoSM which is specifying it.
> 
> Overall, QoSM are not assumed to change the General 
> Processing rules as defined in section 5.2.  If it does, then 
> the QoSM is extending the QoS NSLP.  
> 
> John
>

---

From: <[email-masked]>
Date: Tue, 6 Feb 2007 08:33:32 -0600

I agree that the RMD & QoS NSLP are different. I agree they need
to work together, but the QoS NSLP should not be changed/modified
by the QoS model, otherwise it is extending/modifying the behavior of
the QoS NSLP:

John

>From: ext Tschofenig, Hannes [mailto:[email-masked]] 
>Sent: 06 February, 2007 01:10
>To: Loughney John (Nokia-NRC/PaloAlto); 
>[email-masked]; [email-masked]; 
>Subject: AW: State Machines .... was [NSIS] Summary of QSPEC call
>
>Hi John, 
>
>I think Georgios is saying that the state machine of the QoS 
>NSLP and the QoSM are different but they need to work together. 
>
>EAP has a state machine and the same is true for EAP methods. 
>RFC 4137 even describes the EAP state machine.
>Both, the EAP and the EAP method state machine, need to work 
>together and the EAP method state machine cannot trigger 
>messages that are not allowed in the EAP state machine.
>
>For example, an EAP method cannot force an EAP peer to send a 
>EAP-Failure towards the EAP server since the EAP state machine 
>only allows the message to be sent from the EAP server to the 
>EAP client. 
>
>Ciao
>Hannes
>
>> An: [email-masked]; [email-masked]; [email-masked]; 
>> [email-masked]
>> >uses a different QOSM state machine that is different than the 
>> >QoS-NSLP state machine.
>> 
>defined in the 
>> QoS NSLP.  If a QoSM changes the state machine of the QoS NSLP, then 
>> it must do so via a Standards Track RFC which extends the QoS NLSP.
>> 
>> The RMF will have its own state machine, based upon which QoSM it is 
>> using, but the RMF functionality should be defined upon in the QoSM 
>> which is specifying it.
>> 
>> as defined in section 5.2.  If it does, then the QoSM is 
>extending the 
>> QoS NSLP.
>> 
>> John
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 06 Feb 2007 15:39:13 +0100

Hi John,

> by the QoS model, otherwise it is extending/modifying the behavior of
That's also my thinking.

During the phone conference I recall that Cornelia mentioned that she 
found something in the RMD specification that extended or modified the 
behavior of the QoS NSLP state machine. Maybe she could elaborate a bit 
about this issue.

Ciao
Hannes

---

From: <[email-masked]>
Date: Tue, 6 Feb 2007 08:40:00 -0600

Georgios,

>> 
>> [John] I disagree.  All QoSM need to use the state machine as defined

>> in the QoS NSLP.  If a QoSM changes the state machine of the QoS
NSLP, 
>> then it must do so via a Standards Track RFC which extends the QoS 
>> NLSP.
>
>Do you agree that the QOSM and the QOS-NSLP are supporting two 
>different functionalities.
>Thus the QOSM has its own state machine and the QOS-NSLP has 
>its own state machine.

Exactly.  That is what we are talking about.  The RMF can have
its own state machine, and that can vary from QoSM to QoSM model.

The paragraph above is only refering to the QoS NSLP state machine,
it is not talking about the RMF state machine at all. The RMF
state machine can be defined in the QoSM, not the NSLP.

>> [John] Overall, QoSM are not assumed to change the General Processing

>> rules as defined in section 5.2.  If it does, then the QoSM is 
>> extending the QoS NSLP.
>
>Now regarding the above, I agree, but I think that this is 
>something different than saying that the QOS-NSLP state 
>machine should not be changed.

What exactly do you want? I am not understanding what point you
are trying to make. 

>RSVP aggregation like QOSM RMD-QOSM

>security and AAA interactions. 

At the end of the day, a standard QoS NSLP node should be able to
be re-used with any QoSM and work. If a QoSM makes special
optimizations,
then it needs to do 1 of 2 things:

1) Make the optimizations optional, and have a fallback to the standard
   message processing rules defined in the QoS NSLP.
2) The QoSM needs to make a QoS NSLP extension, which is a standards
track
   document.

I cannot see how we get any interoperability otherwise.

John

---

From: <[email-masked]>
Date: Tue, 6 Feb 2007 08:42:42 -0600

Hannes,

>> I agree that the RMD & QoS NSLP are different. I agree they need to 
>> work together, but the QoS NSLP should not be changed/modified by the

>> QoS model, otherwise it is extending/modifying the behavior of the
QoS 
>> NSLP:

Good. 

>During the phone conference I recall that Cornelia mentioned 
>that she found something in the RMD specification that 
>extended or modified the behavior of the QoS NSLP state 
>machine. Maybe she could elaborate a bit about this issue.

If it does, then it should also describe a fall back to 'standard
behavior' as defined in the message processing rules defined in
the QoS NLSP and everything would be OK.

John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 6 Feb 2007 16:12:57 +0100

Hi John

Regarding the interoperability support, I will resend you the 
proposal that Jukka has made with some additions of mine.

"In order to preserve the end-to-end interoperability the end-to-end
semantic and end-to-end QoS NSLP messaging by the QNI, or any peer QNE must
be preserved, and within those bounds a QOSM must operate. Furthermore, a
QOSM should not change the externally observable operation of the QOS-NSLP
protocol." 

Do you agree?

Best regards,
Georgios

> Sent: dinsdag 6 februari 2007 15:40
> >Thus the QOSM has its own state machine and the QOS-NSLP has its own 
> >state machine.
> 
> Exactly.  That is what we are talking about.  The RMF can 
> have its own state machine, and that can vary from QoSM to QoSM model.
> 
> The paragraph above is only refering to the QoS NSLP state 
> machine, it is not talking about the RMF state machine at 
> all. The RMF state machine can be defined in the QoSM, not the NSLP.
> 
> Processing
> What exactly do you want? I am not understanding what point 
> you are trying to make. 
> 
> >bound and parallel end-to-end and end-to-end sessions bound and 
> >parallel end-to-end and edge-to-edge sessions bound and parallel 
> >end-to-end and end-to-edge sessions
> >
> >interdomain and intra-domain ITU-T RACF QoS model PCN like 
> congestion 
> >notifictaion and preemption QoS model.
> >RSVP-TE like QOSM
> >
> At the end of the day, a standard QoS NSLP node should be 
> able to be re-used with any QoSM and work. If a QoSM makes 
> special optimizations, then it needs to do 1 of 2 things:
> 
> 2) The QoSM needs to make a QoS NSLP extension, which is a 
> standards track
>    document.
>

---

From: <[email-masked]>
Date: Tue, 6 Feb 2007 14:22:13 -0600

Honestly, I don't think that it is specific enough. See text that
Jerry has just proposed.

John 

>From: ext Georgios Karagiannis [mailto:[email-masked]] 
>Sent: 06 February, 2007 07:13
>To: Loughney John (Nokia-NRC/PaloAlto); [email-masked]; 
>"In order to preserve the end-to-end interoperability the 
>end-to-end semantic and end-to-end QoS NSLP messaging by the 
>QNI, or any peer QNE must be preserved, and within those 
>bounds a QOSM must operate. Furthermore, a QOSM should not 
>change the externally observable operation of the QOS-NSLP protocol." 
>
>Do you agree?
>
>Best regards,
>Georgios
>
>
>> To: [email-masked]; [email-masked]; [email-masked]; 
>> [email-masked]
>have its own 
>> state machine, and that can vary from QoSM to QoSM model.
>> 
>machine, it 
>> is not talking about the RMF state machine at all. The RMF state 
>> machine can be defined in the QoSM, not the NSLP.
>> 
>something 
>> What exactly do you want? I am not understanding what point you are 
>> trying to make.
>> 
>> At the end of the day, a standard QoS NSLP node should be able to be 
>> re-used with any QoSM and work. If a QoSM makes special 
>optimizations,

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Thu, 8 Feb 2007 15:19:02 +0100

Hi Hannes, 

[sorry, I was offline for a couple of days, so I respond only now]

I was referring to the following behaviour of RMD:

An ingress generates an intra-RMD RESERVE with an RMD QSPEC and sends it, via several stateless nodes, to the egress. The RMD QSPEC contains a counter C which is increased at each stateless node where the reservation is admitted. Now the i-th node on the path does not have enough resources. It sets a flag in the QSPEC (I dont remember which) to indicate the reservation is not admitted. Henceforth the counter C is no longer increased. Finally the RESERVE arrives at the egress. The egress notes the reservation failed, and sends a RESPONSE to the ingress, with a QSPEC containing the final value of C. The ingress now initiates a tearing RESERVE towards the egress. Each stateless nodes receiving the tearing RESERVE tears down the reservation, counts down the counter by one, and forwards the tearing RESERVE. Up to now this is perfectly normal QoS NSLP behaviour. But now the following happens: At the ith hop, the counter is zero, and the RESERVE is stopped. (The reason is that from node i+1 onwards, no reservation was performed, so it is not necessary to tear anything). 

This is why the last part is interesting behaviour: We have a QSPEC parameter (the counter C) which does not appear in any other QOSM (at least not so far). Still, it influences the QoS NSLP state machine in that it says the RESERVE should be discontinued. The normal QoS NSLP state machine would always forward the RESERVE up to the QNR, so this is a modification. 
(Georgios already said that this is an optimization that could be removed from RMD if I recall correctly, so this might not be an issue)

Another interesting aspect is that, generally, a RESPONSE will only ever be generated by a QNR if the QoS NSLP object "RII" is included in the message. We thus see that in the case of RMD, the RMF must be able to tell QoS NSLP that RII be included.
This is not a state-machine issue (is it?) but rather one of how flexible and powerful the RMF - QoS NSLP API is. For example, in the QoS NSLP state machine draft by Xiaoming, the only thing the RMF ever tells QoS NSLP is "resources available" or "resources unavailable", respectively. It would be interesting to hear Xiaomings view on this. 

What thus may happen is that a RMD could not run on any QoS NSLP implementation. OTOH this might not be an issue since we do aim at "QoS NSLP interoperability" rather than "RMF - QoS NSLP interoperability".

Cornelia

> Von: Hannes Tschofenig [mailto:[email-masked]] 
> Gesendet: Dienstag, 6. Februar 2007 15:39
> An: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> Tschofenig, Hannes
> Betreff: Re: State Machines .... was [NSIS] Summary of QSPEC call
> 
> Hi John,
> 
> QoSM it is 
> Processing rules

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 08 Feb 2007 21:27:54 +0100

Hi Cornelia,

thanks for describing the issue. Please find my response below:

> An ingress generates an intra-RMD RESERVE with an RMD QSPEC and sends it, via several stateless nodes, to the egress. The RMD QSPEC contains a counter C which is increased at each stateless node wh…
I agree that here is a problem.

> This is not a state-machine issue (is it?) but rather one of how flexible and powerful the RMF - QoS NSLP API is.
>  For example, in the QoS NSLP state machine draft by Xiaoming, the only thing the RMF ever tells QoS NSLP is "resources available" or "resources unavailable", respectively. It would be interesting to hear Xiaomings view on this. 
>   
I don't see this as a problem. Given the heated discussion we had I 
would, however, update the QoS NSLP state machine to address this issue.

Ciao
Hannes

>>> by the QoS model, otherwise it is extending/modifying the 
>>>       
>> behavior of
>>     
>>> the QoS NSLP:
>>>
>>>   
>>>       
>> That's also my thinking.
>>
>>>> From: ext Tschofenig, Hannes 
>>>>         
>> [mailto:[email-masked]] 
>>     
>> [email-masked]; 
>>     
>>>>> [email-masked]
>>>>> QoS NSLP.  If a QoSM changes the state machine of the QoS 
>>>>>           
>> NSLP, then 
>>     
>>>>> it must do so via a Standards Track RFC which extends the 
>>>>>           
>> QoS NLSP.
>>     
>>>>> using, but the RMF functionality should be defined upon 
>>>>>           
>> in the QoSM 
>>     
>>>>> which is specifying it.
>>>>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 9 Feb 2007 09:37:12 +0100

Hi Cornelia

Thanks for the clarification!
Please note that the RMD partial release is an optimization, and according 
to the updates that we will introduce in the QoS-NSLP regarding
interoperability 
this might become a problem. 
Therefore, we will change this feature in the RMD-QOSM draft.

However, the second point that you discussed is, as you already concluded,
And I agree with you, it is not an issue, since it complies to the new
updates 
on the QOS-NSLP.

If you could reintroduce the QSPEC control information semantics into the 
QSPEC draft, see my e-mail of yesterday then we can complete the ongoing
drafts and go for WG
last call!

Best Regards,
georgios

> From: Kappler, Cornelia [mailto:[email-masked]] 
> Sent: donderdag 8 februari 2007 15:19
> To: Hannes Tschofenig; [email-masked]
> An ingress generates an intra-RMD RESERVE with an RMD QSPEC 
> and sends it, via several stateless nodes, to the egress. The 
> RMD QSPEC contains a counter C which is increased at each 
> stateless node where the reservation is admitted. Now the 
> i-th node on the path does not have enough resources. It sets 
> a flag in the QSPEC (I dont remember which) to indicate the 
> reservation is not admitted. Henceforth the counter C is no 
> longer increased. Finally the RESERVE arrives at the egress. 
> The egress notes the reservation failed, and sends a RESPONSE 
> to the ingress, with a QSPEC containing the final value of C. 
> The ingress now initiates a tearing RESERVE towards the 
> egress. Each stateless nodes receiving the tearing RESERVE 
> tears down the reservation, counts down the counter by one, 
> and forwards the tearing RESERVE. Up to now this is perfectly 
> normal QoS NSLP behaviour. But now the following happens: At 
> the ith hop, the counter is zero, and the RESERVE is stopped. 
> (The reason is that from node i+1 onwards, no reservation was 
> performed, so it is not necessary to tear anything). 
> 
> This is why the last part is interesting behaviour: We have a 
> QSPEC parameter (the counter C) which does not appear in any 
> other QOSM (at least not so far). Still, it influences the 
> QoS NSLP state machine in that it says the RESERVE should be 
> discontinued. The normal QoS NSLP state machine would always 
> forward the RESERVE up to the QNR, so this is a modification. 
> (Georgios already said that this is an optimization that 
> could be removed from RMD if I recall correctly, so this 
> might not be an issue)
> 
> Another interesting aspect is that, generally, a RESPONSE 
> will only ever be generated by a QNR if the QoS NSLP object 
> "RII" is included in the message. We thus see that in the 
> case of RMD, the RMF must be able to tell QoS NSLP that RII 
> be included.
> This is not a state-machine issue (is it?) but rather one of 
> how flexible and powerful the RMF - QoS NSLP API is. For 
> example, in the QoS NSLP state machine draft by Xiaoming, the 
> only thing the RMF ever tells QoS NSLP is "resources 
> available" or "resources unavailable", respectively. It would 
> be interesting to hear Xiaomings view on this. 
> 
> What thus may happen is that a RMD could not run on any QoS 
> NSLP implementation. OTOH this might not be an issue since we 
> do aim at "QoS NSLP interoperability" rather than "RMF - QoS 
> NSLP interoperability".
> 
> Cornelia
> 
> 
> 
> Tschofenig, 
> > > work together, but the QoS NSLP should not be changed/modified by 
> > > the QoS model, otherwise it is extending/modifying the
> > behavior of
> > > the QoS NSLP:
> > >
> > >   
> > That's also my thinking.
> > 
> > behavior of the QoS NSLP state machine. Maybe she could elaborate a 
> > bit about this issue.
> > 
> > Ciao
> > Hannes
> > 
> > > John
> > >
> > >   
> > >> To: Loughney John (Nokia-NRC/PaloAlto); [email-masked]; 
> > >> [email-masked]; [email-masked]; [email-masked]
> > >> I think Georgios is saying that the state machine of the 
> QoS NSLP 
> > >> and the QoSM are different but they need to work together.
> > >>
> messages 
> > >> that are not allowed in the EAP state machine.
> > >>
> > >> EAP-Failure towards the EAP server since the EAP state 
> machine only 
> > >> allows the message to be sent from the EAP server to the EAP 
> > >> client.
> > >>
> > >> Ciao
> > >> Hannes
> > >>
> > >>