Subject: [NSIS] Rmd-qos-nslp statemachine issues

From: Ferenc Pintér (IJ/ETH)<[email-masked]>
Date: Mon, 12 Dec 2005 14:48:48 +0100

Hi all!

I am a hungarian student implementing the QoS-NSLP and its RMD extension with help of Attila Bader at Ericsson.
I've found some problematic parts while creating a new statemachine for the RMD-extended QoS-NSLP.
This was:

"As I read the original QoS-Statemachine draft /draft-fu-nsis-qos-nslp-statemachine-02.txt/
and the .pdf version, I've found that if a QNE in IDLE state receives a normal reservation
request without RII it cannot admit - (rx_RESERVE)&&(!RII)&&(RMF="NOT AVAIL") - , 
sends a response - tx_RESPONSE(RSN,E_SPEC="0x04?") - to its upstream peer.
If the upstream peer (or any QNE) in QoS_INSTALLED state receives that type of response,
indicating reservation failure, it sends a notify - tx_NOTIFY(RSN,E_SPEC="0x04?") - 
upstream.
The question is: why does the upstream node translate the response message to a notify,
however notify is only used in special error conditions?
Is this a typo in the statemachine draft?

I've re-read the newest qos-nslp draft as well, and found in section 5.4.3 Response Messages:

"On receipt of a RESPONSE message containing an RSN object, the QNE
MUST compare the RSN to that of the appropriate signalling session.
If the match succeeds then the INFO_SPEC MUST be processed. The
RESPONSE message MUST NOT be forwarded further along the path whether
or not the match succeeds."

Is this why the statemachine uses notify for this case?

This problem also does not help with the following:

	- What if Egress receives a downstream peer sent response/notify indicating
	  reservation failure downstream of the stateless domain and Egress?
	  What type of message shall be sent to Ingress to ignite an intra-domain teardown?
	  
		-	A marked response(PDR,E_SPEC="0x04?") with restoring a pre-saved
			hop-count in PDR_Reservation_Report to help Ingress create the 
			intra-domain teardown reserve?

		-	Do not save any values in Egress after successful intra-domain
			reservation, rather insert a BIG value into Response's Admitted_Hops count
			when this failure occurs?

		-	Use a Notify(PDR) with S or M or both bits set and let the edge
			nodes figure out this is not the severe congestion case, by for. ex.
			using PDR_Reservation_Report instead of default PDR_Congestion_Report?

		-	Or, as the last option, use a simple QoS-NSLP Notify, and program
			Ingress to issue an intra-domain teardown somehow (and only for specific notifies),
			and Egress to filter it out?

Attila suggested using simple QoS-NSLP Notify() when Egress receives a 
Notify(RSN,E_SPEC="0x04?") from its downstream peer - just sending it through Egress - ,
and using a Response(PDR)  with either storing the hop count of the domain after the 
reservation, or adding a BIG hop count to it before sending to Ingress, after Egress
received a Response(RSN,E_SPEC="0x04?").Either way, if Egress receives a Response()
indicating failure, with a CheckRII=NOT_LOCAL RII inside it, it will just send a 
Reponse(PDR) to Ingress."

As Georgios proposed, I've read the related paragraphs /5.4.3, 5.3.5.4/ in http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-08-09.html, they say RESPONSE must be, and NOTIFY may be sent by QNE receiving a response indicating downstream reservation failure. 
So after all, I am convinced that I shall not send a NOTIFY, although that is written in - draft-fu-nsis-qos-nslp-statemachine-02.txt /and in the pdf version as well/ - which seems to be the newest QoS-NSLP statemachine draft around. 
I will use at every QNE (in QoS installed state) : 
rx_RESPONSE(RSN, E_SPEC="0x04?") 	Delete QoS state IDLE 	tx_RESPONSE(RSN, E_SPEC="0x04?") 
and do not care about what if QNE receives notify. 
instead of what is written is the QoS-NSLP statemachine draft: 
rx_RESPONSE(RSN, 		|Delete QoS state 		|IDLE 	|
	E_SPEC="0x04?") 	|tx_NOTIFY(RSN, 	|	|
				| E_SPEC="0x04?") 	|	|
and 

rx_NOTIFY(RSN, 			|Delete QoS state 		|IDLE 	|
	E_SPEC="0x04?") 	|rx_NOTIFY(RSN, 	| 	|
				| E_SPEC="0x04?") 	| 	|

And QNI will receive RESPONSE(failure) with RSN, not NOTIFY(failure) with RSN. /I do not know why they used NOTIFY for this in the QoS-NSLP statemachine draft in the first place./ 
This might lead to the following in RMD-QoS-NSLP: 
When Egress receives this failure response, it simply sends a RESPONSE(PDR,E_SPEC="0x04?") to Ingress to signal the error. Egress will include an Admitted_Hops value in this RESPONSE /as Max_Admitted_Hops/, which was saved previously when it received the intra-domain RESERVE(PHR). /or, for simpler Egress operation, it could just use a BIG value as well instead of this Admitted_Hops count, because when Ingress will issue an intra-domain teardown, the interior nodes will forward the teardown RESERVE as well, it will just reach Egress where it will be filtered out by the way/ 
Using Admitted_Hops is more precise though. 
Since Egress will never receive a NOTIFY(RSN,E_SPEC="0x04?") instead of RESPONSE(RSN,E_SPEC="0x04?"), I will not include this in the RMD Statemachine draft. / how Egress and Ingress handles other NOTIFY messages received from downstream is policy dependent, so I will skip these as well/.

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

---

From: Tseno Tsenov <[email-masked]>
Date: Mon, 12 Dec 2005 23:56:51 +0100

Hi Ferenc,

Thanks a lot for reviewing the statemachine draft.
Pls. see inline:

Original Message:

>Hi all!
>
>I am a hungarian student implementing the QoS-NSLP and its RMD extension with help of Attila Bader >at Ericsson.

Yes, this statement is the reason why a NOTIFY message appears in such case.
Pls. note that the statemachine draft is based on v-07 of the qos-nslp draft and at that time we identified this as an open issue and used NOTIFY for signaling of unsuccessful reservation. AFAIR, in October before the IETF meeting, Roland Bless spotted this issue in the mailing list, too.

Unfortunately, recently I dont follow the nsis work in details and don't know whether this issue is solved in the latest qos-nslp work. If you say that this statement is still in the newest qos-nslp draft then maybe additional clarifying text has been added or just these scenario and issue are classified as infeasible?

Greetings,
Tseno_

>[SNIP]