Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 30 Oct 2003 13:40:25 -0000

hi all,

a brief comment on the refresh/NSLP/NTLP question.

> -To refresh a reservation, everything is done by QoS-NSLP. I don't see the
> any NTLP functions to support refreshment. However, in the draft of
> R.Hancock (draft-handcock-nsis-reliability-00), NTLP can be used to
support
> refreshing state between NSLP peers. 

i think this is a misunderstanding. the draft mentioned classifies various
different sorts of signalling messages (and some of them are refresh 
messages). the role of the NTLP is to deliver all messages, but it
doesn't care directly if they are refreshes or something else. in other
words, the NTLP doesn't include specific functionality for refreshing
signalling application state, it provides a message delivery capability
which signalling applications can use to refresh their own state.

this specific issue is further discussed in 3.2.5 of the framework.
it was discussed on the mailing list quite intensively (around April/May 
this year).

> It raises a question : "If NTLP
> supports refreshing state, should it know the RSN to do refreshing ? "
Note
> that, RSN can be applied in other signaling applications, eg: the first
> "trigger message" is marked as RSN=x, the second is x+1 and the third is
> x+2. If NTLP receives RSN=x+1 and then it receives this message one more
> time, it considers this message a refresh message. After that it receives
> message with RSN=x+2 (of the same session id), it knows this is a new
> trigger message and gives NSLP this message. Somebody has answered me NTLP
> should not know RSN because it belongs to NSLP. According to me, NTLP
should
> know to support refreshing state, reason : this is a generic function of
> NTLP to support most of NSLP applications. Please correct me if i am
wrong.

please see above. hope this helps.

r.

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

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Thu, 30 Oct 2003 15:46:27 +0100

hi,

I do not mean NTLP refreshes the signaling application state. It is enough
clear about this one. I did not clearly express my thought. We can consider
RSN (RSN is just a name) as a message sequential number of NSLP and NTLP
should know this number as a NTLP state number. It helps NTLP to filter only
new NSLP message to transfert to NSLP.

Regards,

Nary Tra
ENST, Paris

----- Original Message -----
From: "Hancock, Robert" <[email-masked]>
To: "'Thanh Tra LUU'" <[email-masked]>; <[email-masked]>
Sent: Thursday, October 30, 2003 2:40 PM
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt

> --
> Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury,
Bracknell,
> Berkshire. RG12 8FZ
>
> The information contained in this e-mail and any attachments is
confidential to
> Roke Manor Research Ltd and must not be passed to any third party without
> permission. This communication is for information only and shall not
create or
> change any contractual relationship.
>