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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 30 Oct 2003 15:07:17 -0000

hi,
> Hi,
> 
> I am not sure if it is a good idea to filter messages out in the NTLP
> because you assume the NSLP will not need them (because it believes the
> message is not new). It is probably cleaner if the NTLP does not need to
> know about the RSN in the first place.
> 
> Best regards,
> Sven

this would also absolutely be my view. lower layers should not do
thinking on behalf of upper layers. if it is possible for an entity
to know not to send a message, why not do this in the layer that
the message is generated, rather than asking a lower layer to guess
that the message wasn't really needed?

r.

> 
> 
> 
> 
> 
> "Thanh Tra LUU" <[email-masked]>@ietf.org on 30/10/2003 15:46:27
> 
> Sent by:    [email-masked]
> 
> 
> To:    "Hancock, Robert" <[email-masked]>
> cc:    <[email-masked]>
> Subject:    Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt
> 
> 
> 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
> 
> 
> > 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.
> >
> > --
> > 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.
> >
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
>  https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> 

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