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

From: [email-masked]
Date: Tue, 28 Oct 2003 15:43:06 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Steps in Signaling Working Group of the IETF.

	Title		: NSLP for Quality-of-Service signaling
	Author(s)	: S. Van den Bosch
	Filename	: draft-ietf-nsis-qos-nslp-01.txt
	Pages		: 30
	Date		: 2003-10-28
	
This draft describes an NSIS Signaling Layer Protocol (NSLP) for 
signaling QoS reservations in the Internet. It is in accordance with 
the framework and requirements developed in NSIS. 
Together with the NTLP, it provides functionality similar to RSVP and 
extends it. The QoS-NSLP is independent of the underlying QoS 
specification or architecture and provides support for different 
reservation models. It is simplified by the elimination of support 
for multicast flows. 
This version of the draft focuses on the basic protocol structure. It 
identifies the different message types and describes the basic 
operation of the protocol to create, refresh, modify and teardown a 
reservation or to obtain information on the characteristics of the 
associated data path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nsis-qos-nslp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-nsis-qos-nslp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Wed, 29 Oct 2003 18:37:27 +0100

Dear all ,

It seems that the life-cycle of a draft version becomes shorter.    :o)

I still have some question on QoS NSLP. Generally, that is a "too" generic
QoS-NSLP to me. As the remarks in the others' mails, I find that there are
many more 'should' (23 words) than 'must' (13 words).   :o)

-You write message name in uppercase (e.g. RESERVE), it can make confusion
with class and object name. Can you use lowercase (e.g. Reserve) ? I don't
think it as a convention, however, it was used in COPS, RSVP...

-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. 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.

- For "QUERY" message, if no NSLP (reservation state) is established, does
this message go back to the previous hop (as the Resv of RSVP) or it will be
directly sent to the hop which initiated the "QUERY" message (in some cases,
this hop is not an edge node) ? If it does, hop by hop security is suitable
?

- It seems obscure to me the ResponseRequest object, how is the flag 'local'
used ? RII is unique to a NSLP node or global in a local 'region' ? Can we
simpify the problem by putting in RII the address of the node which wants to
receive a REPONSE ? (it's only my propose)

- I totally agree the 6.2. The fonction routing change detection is done by
NTLP.

- It seems to be a new requirement for NTLP to detect that there is no more
NSLPs (e.g. QoS-NSLP) on the path (6.3). I think it is good but it needs
some explications.

Regards.

Nary Tra
ENST, Paris

----- Original Message -----
From: <[email-masked]>
To: <IETF-Announce:>
Cc: <[email-masked]>
Sent: Tuesday, October 28, 2003 9:43 PM
Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt

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

---

From: "Cheng Hong" <[email-masked]>
Date: Fri, 31 Oct 2003 17:05:53 +0800

Hi Nary Tra, Sven, and all,

I have the similar question as Nary about the RII. Is that the same as SII?
Can it be just replace by the SII or using the same value?

Besides that, I have a few more comments on the -01 draft.

a) Section 1.2 says "Only messages related to QoS are passed to the
QoS-NSLP. The NTLP may also generate triggers to the QoS-NSLP
(e.g.indications that a route change has occurred)."

I don't think QoS-NSLP would be the only QoS related Signaling Application.
It is somehow confusing. Therefore, I think it maybe better to clarify that
as:

"Only messages related to the particular QoS NSLP, e.g. indicated by the
Signaling Application Identifier defined in 4.6.3 of [3], are passed to the
QoS-NSLP.The NTLP may also generate triggers to the QoS-NSLP
(e.g.indications that a route change has occurred)."

b) In Section 2.1, it says "Messages are normally passed from the NSLP to
the NTLP via an API,which also specifies the signaling application (as
QoS-NSLP), the flow/session identifier, and an indication of the intended
direction - towards data sender or receiver."

It sounds that the session identifier is provided through the NTLP. And
other than here, there is no mentioning about the session identifier. My
feeling is that it is better for the NSLP to actual maintain the session ID,
since there my be several session come from the same NSLP instance, and only
NSLP knows how to correlate the session and flows. Therefore, it would be
better to provide some description about the operation on session ID in the
NSLP draft.

c) In section 3.1 RESERVE, it is mentioned that "Note that the potential
initiation of (reverse path) state removal at the NTLP is a separate issue.
This will be signaled over the API between NTLP and QoS-NSLP."

Shouldn't the state removal a business of the NSLP only? NTLP could provide
hint/trigger for that, but the decision should still be made by the NSLP.
Also, whether to use API for this purpose is purely implementation issue,
e.g. we could use loopback message instead.

cheers

Cheng Hong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Thanh
> Tra LUU
> Sent: Thursday, October 30, 2003 1:37 AM
> To: [email-masked]
> Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt
>
>
>
> Dear all ,
>