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

From: [email-masked]
Date: Thu, 08 Mar 2007 15:50:03 -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)	: J. Manner, et al.
	Filename	: draft-ietf-nsis-qos-nslp-13.txt
	Pages		: 85
	Date		: 2007-3-8
	
This specification describes the 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
   GIST, 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 specification explains the overall protocol approach, design
   decisions made and provides examples. It specifies object, message
   formats and processing rules.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-13.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-13.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.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 9 Mar 2007 11:36:12 +0100

Please take a look and review the new version of the QoS NSLP draft.

There have been some changes in the main part, plus a new appendix  
with the NSLP-RMF API.

Thanks,

   Martin

Anfang der weitergeleiteten E-Mail:

> Von: <[email-masked]>
> Datum: 8. März 2007 21:50:03 MEZ
> An: <[email-masked]>
> Kopie: <[email-masked]>
> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt
>

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 9 Mar 2007 12:50:52 +0200 (EET)

A diff of the changes since -12 is at:
http://tools.ietf.org/wg/nsis/draft-ietf-nsis-qos-nslp/draft-ietf-nsis-qos-nslp-13-from-12.diff.html

Main changes:
- Reduced refreshes are the default mechanism for refreshing sessions
- RSN needs to be taken into account when a node receives a tear
- Summary refresh and summary tear introduced (incl. objects and message 
  processing)
- QSPEC staking removed
- ACK-REQ flag introduced for diagnostics purposes
- Some changes to the INFO_SPEC codes (see the diff)
- (very) Initial version of NSLP-RMF API

Jukka

On Fri, 9 Mar 2007, Martin Stiemerling wrote:

> There have been some changes in the main part, plus a new appendix with the
> NSLP-RMF API.
> 
> Thanks,
> 
>  Martin
>

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 13 Mar 2007 14:35:35 +0100

Hi all,

I would like to encourage people to check the initial version of the  
NSLP-RMF API.

Note that the API is informational only and should just give hints to  
the implementers.

Thanks,

   Martin

Am 09.03.2007 um 11:50 schrieb Jukka MJ Manner:

>> with the
>>> This draft is a work item of the Next Steps in Signaling Working  
>>> Group of
>>> the IETF.
>>>

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Tue, 13 Mar 2007 15:42:40 -0500

Hi Andrew, All,

Regarding informative Appendix A "Abstract NSLP-RMF API" in the updated QoS NSLP draft http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt, I see that in Section A.2 (Triggers from RMF/QOSM towards QOS-NSLP) it says:

"   * features_out: it represents among others the flags that can
        be used by the QOS-NSLP
        for new generated QoS-NSLP messages:

      ** BREAK
      ** REQUEST REDUCED REFRESHES
      ** RESERVE-INIT
      ** TEAR
      ** REPLACE
      ** ACK-REQ
      ** PROXY
      ** SCOPING
      ** BYPASSING:  when the outgoing message should be bypassed
         then it includes the required bypassing level. Otherwise it
         is empty. It can be set only by QNI_Ingress, QNR_Ingress,
         QNI_Egress, QNR_Egress. It can be unset only by QNI_Ingress,
         QNR_Ingress, QNI_Egress, QNR_Egress
      ..."

If the RMF/QOSM API triggers various QoS-NSLP messages by setting 'flags', as above, how would this be interoperable?  E.g., QNE-1 has RMF/QOSM-1 and uses flag-1 to trigger some QoS-NSLP message-1, but another QNE-2 has RMF/QOSM-2 and uses flag-2 to trigger some other QoS-NSLP message-2.  Could QNE-1 and QNE-2 understand each other and interoperate correctly?  How does sending these flags over the API affect the QoS NSLP state machine?

Thanks a lot for your insights here.

Regards,
Jerry

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 9:36 AM
To: nsis
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt

Hi all,

Thanks,

   Martin

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 14 Mar 2007 11:54:39 +0100

Hi Jerry

These flags have to be set in for example, the situation that a QNE is an
Initial QNI (in case of an end-toend (initial) QOSM) or 
an Ingress/Egress QNI in case of an edge-to-edge (local QOSM). 

This all is needed in order to provide the support for the 
Bound and combined:
 * end-to-end and end-to-end scenarios
 * end-to-end and edge-to-edge scenarios
 * end-to-end and end-to-edge scenario

Best Regards,
Georgios

> From: ASH, GERALD R, ATTLABS [mailto:[email-masked]] 
> Sent: dinsdag 13 maart 2007 21:43
> To: Andrew McDonald; nsis
> Cc: ASH, GERALD R, ATTLABS
> Subject: Abstract NSLP-RMF API -- RE: [NSIS] 
> I-DACTION:draft-ietf-nsis-qos-nslp-13.txt
> 
> Hi Andrew, All,
> 
> Regarding informative Appendix A "Abstract NSLP-RMF API" in 
> the updated QoS NSLP draft 
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-1
> 3.txt, I see that in Section A.2 (Triggers from RMF/QOSM 
> towards QOS-NSLP) it says:
> 
> If the RMF/QOSM API triggers various QoS-NSLP messages by 
> setting 'flags', as above, how would this be interoperable?  
> E.g., QNE-1 has RMF/QOSM-1 and uses flag-1 to trigger some 
> QoS-NSLP message-1, but another QNE-2 has RMF/QOSM-2 and uses 
> flag-2 to trigger some other QoS-NSLP message-2.  Could QNE-1 
> and QNE-2 understand each other and interoperate correctly?  
> How does sending these flags over the API affect the QoS NSLP 
> state machine?
> 
> I would like to encourage people to check the initial version 
> of the NSLP-RMF API.
> 
> Note that the API is informational only and should just give 
> hints to the implementers.
> 
> Thanks,
> 
>    Martin
> 
> >>> Group of the IETF.
> >>>   GIST, it provides functionality similar to RSVP and 
> extends it.  
> >>> The
> >>> [email-masked] with the word unsubscribe 
> in the body 
> >>> of the message.
> >>> logging in, type "cd internet-drafts" and then "get 
> >>> draft-ietf-nsis-qos-nslp-13.txt".
> >>>
> >>> http://www.ietf.org/shadow.html or 
> >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>
> >>> command.  To decode the response(s), you will need "munpack" or a 
> >>> MIME-compliant mail reader.  Different MIME-compliant 
> mail readers 
> "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.
> >>>
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL 
> | Registered in England 2832014
> 
> 
> 
>

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 14 Mar 2007 10:59:01 +0000

Jerry, all,

I think that some of these aspects do give too much information/control 
to the RMF.

One problem we started to encounter when trying to come up with the 
initial cut of an API was that there are areas where the 'application' 
may want to interact with the NSLP. However, the figure 2 diagram in the 
QoS NSLP document currently shows all these interactions as being 
mediated by the RMF. It may also be that the API is the wrong 'shape' at 
the moment, and too RMF-driven. A better model might be to be more 
NSLP-driven with call-backs into the RMF (e.g. QoS NSLP to RMF: "tell me 
what to put in this RESERVE I'm going to send", rather than the current 
RMF to NSLP: "send a RESERVE with this QSpec in it").

Any thoughts on improvements would be useful.

regards,

Andrew

-- 
Andrew McDonald
Consultant Engineer
Tel: +44 (0)1794 833833
Fax: +44 (0)1794 833616

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Wed, 14 Mar 2007 07:30:35 -0500

Hi Andrew, All,

I agree with you that the Abstract NSLP-RMF API should be significantly toned down so as to, as you say, *not* make it 'too RMF driven' nor 'give too much information/control to the RMF'.  

The way it is now would make the result non-interoperable IMO, as illustrated in the example I provided below.  Furthermore, I think it should be clarified how the QoS NSLP state machine might be affected by 'triggers' from the RMF?  As in our long discussions earlier, the RMF must not change the normative QoS NSLP state machine based only on the informative API interactions and 'RMF/API triggers' alone, right?

Thanks,
Regards,
Jerry 

-----Original Message-----
From: Andrew McDonald [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 6:59 AM
To: ASH, GERALD R, ATTLABS
Cc: nsis
Subject: Re: Abstract NSLP-RMF API -- RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.txt

Jerry, all,

regards,

Andrew

-- 
Andrew McDonald
Consultant Engineer
Tel: +44 (0)1794 833833
Fax: +44 (0)1794 833616

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 14 Mar 2007 13:41:11 +0100

Hi Jerry

Regarding the following paragraph:
> As in our long discussions earlier, the RMF must not change 
> the normative QoS NSLP state machine based only on the 
> informative API interactions and 'RMF/API triggers' alone, right?

All the triggers that go into the QOS-NSLP will somehow change the 
QoS NSLP state machine. The API describes what are the possible in/out
triggers 
that should be taken into account by the QOS-NSLP state machine!

Best regards,
Georgios

> Sent: woensdag 14 maart 2007 13:31
> To: Andrew McDonald
> Cc: ASH, GERALD R, ATTLABS; nsis
> Subject: RE: Abstract NSLP-RMF API -- RE: [NSIS] 
> I agree with you that the Abstract NSLP-RMF API should be 
> significantly toned down so as to, as you say, *not* make it 
> 'too RMF driven' nor 'give too much information/control to the RMF'.  
> 
> The way it is now would make the result non-interoperable 
> IMO, as illustrated in the example I provided below.  
> Furthermore, I think it should be clarified how the QoS NSLP 
> state machine might be affected by 'triggers' from the RMF?  
> As in our long discussions earlier, the RMF must not change 
> the normative QoS NSLP state machine based only on the 
> informative API interactions and 'RMF/API triggers' alone, right?
> 
> Thanks,
> Regards,
> Jerry 
> 
> I think that some of these aspects do give too much 
> information/control to the RMF.
> 
> One problem we started to encounter when trying to come up 
> with the initial cut of an API was that there are areas where 
> the 'application' 
> may want to interact with the NSLP. However, the figure 2 
> diagram in the QoS NSLP document currently shows all these 
> interactions as being mediated by the RMF. It may also be 
> that the API is the wrong 'shape' at the moment, and too 
> RMF-driven. A better model might be to be more NSLP-driven 
> with call-backs into the RMF (e.g. QoS NSLP to RMF: "tell me 
> what to put in this RESERVE I'm going to send", rather than 
> the current RMF to NSLP: "send a RESERVE with this QSpec in it").
> 
> >>>>   with the framework and requirements developed in NSIS. 
> Together 
> >>>> with
> >>>> To remove yourself from the I-D Announcement list, send 
> a message 
> >>>> to [email-masked] with the word 
> unsubscribe in the 
> >>>> body of the message.
> >>>> "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.
> >>>>

---

From: <[email-masked]>
Date: Wed, 14 Mar 2007 23:55:10 -0500

Hi Jerry,

>'too RMF driven' nor 'give too much information/control to the RMF'.  

I agree.

>The way it is now would make the result non-interoperable IMO, 
>as illustrated in the example I provided below.  Furthermore, 
>I think it should be clarified how the QoS NSLP state machine 
>might be affected by 'triggers' from the RMF?  As in our long 
>discussions earlier, the RMF must not change the normative QoS 
>NSLP state machine based only on the informative API 
>interactions and 'RMF/API triggers' alone, right?

I agree with this as well.  APIs are generally illustrative in the IETF.

John

---

From: <[email-masked]>
Date: Wed, 14 Mar 2007 23:55:11 -0500

Georgios,

>> As in our long discussions earlier, the RMF must not change the 
>> normative QoS NSLP state machine based only on the informative API 
>All the triggers that go into the QOS-NSLP will somehow change 
>the QoS NSLP state machine. The API describes what are the 
>possible in/out triggers that should be taken into account by 
>the QOS-NSLP state machine!

I think we really need to be more precise than "...will somehow change 
the QoS NSLP state machine."  If we don't have it fully explained,
I doubt it can very well be specified.

We should be very explicit about what drives the state changes, to
ensure that we have an interporable specification.

John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 15 Mar 2007 11:09:10 +0100

Hi John

But all API triggers that are going in and out the QOS-NSLP will 
change the QOS-NSLP state machine.

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 15 maart 2007 5:55
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Abstract NSLP-RMF API -- 
> RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt
> 
> Georgios,
> 
> 
> >All the triggers that go into the QOS-NSLP will somehow 
> change the QoS 
> >NSLP state machine. The API describes what are the possible in/out 
> >triggers that should be taken into account by the QOS-NSLP state 
> >machine!
> 
> I think we really need to be more precise than "...will 
> somehow change the QoS NSLP state machine."  If we don't have 
> it fully explained, I doubt it can very well be specified.
> 
> We should be very explicit about what drives the state 
> changes, to ensure that we have an interporable specification.
> 
> John  
>

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 15 Mar 2007 10:41:14 -0000

hi all, 
> Hi John
> 
> But all API triggers that are going in and out the QOS-NSLP 
> will change the QOS-NSLP state machine.
> 

IMHO there should be a system of fines for use of the phrase
"change the QoS-NSLP state machine". do we really mean 'change
the state machine' or 'cause transitions within the state
machine'? - they're quite different things. 

any protocol state machine will have some transitions which 
are triggered by events defined as part of the protocol 
specification, and other transitions which can be caused
by arbitrary local events. provided the qos NSLP identifies
which come into the second class, and the RMF API allows only
these to be triggered, there shouldn't be a problem.

r.

PS since many of us will soon be in prague, which is the home
of some excellent beer, that could be an appropriate mechanism
for the penalty system.

> somehow change 
> > the QoS NSLP state machine."  If we don't have it fully 
> explained, I 
> > doubt it can very well be specified.
> >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 15 Mar 2007 12:24:58 +0100

Hi Robert

Thank you for the clarification the below is exactly what I meant:
'cause transitions within the state machine'

Best Regards,
Georgios

> From: Robert Hancock [mailto:[email-masked]] 
> Sent: donderdag 15 maart 2007 11:41
> To: 'Georgios Karagiannis'; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Abstract NSLP-RMF API 
> --RE:[NSIS]I-DACTION:draft-ietf-nsis-qos-nslp-13.txt
> 
> hi all, 
> > Hi John
> > 
> "change the QoS-NSLP state machine". do we really mean 
> 'change the state machine' or 'cause transitions within the 
> state machine'? - they're quite different things. 
> 
> specification, and other transitions which can be caused by 
> arbitrary local events. provided the qos NSLP identifies 
> of some excellent beer, that could be an appropriate 
> mechanism for the penalty system.
> 
> > Best regards,
> > Georgios
> > 
> > 
> >  
> > 
> changes, to

---

From: <[email-masked]>
Date: Thu, 15 Mar 2007 07:39:51 -0500

I think Robert's clarification is a good one as well. 

>From: ext Georgios Karagiannis [mailto:[email-masked]] 
>Sent: 15 March, 2007 04:25
>To: 'Robert Hancock'; Loughney John (Nokia-NRC/PaloAlto); 
>> To: 'Georgios Karagiannis'; [email-masked]; [email-masked]; 
>> [email-masked]
>> Cc: [email-masked]
>> IMHO there should be a system of fines for use of the phrase "change 
>> the QoS-NSLP state machine". do we really mean 'change the state 
>> machine' or 'cause transitions within the state machine'? - they're 
>> quite different things.
>> 
>> any protocol state machine will have some transitions which are 
>> triggered by events defined as part of the protocol 
>specification, and 
>> other transitions which can be caused by arbitrary local events. 
>> provided the qos NSLP identifies which come into the second 
>class, and 
>> the RMF API allows only these to be triggered, there shouldn't be a 
>> problem.
>> 
>> r.
>> 
>> PS since many of us will soon be in prague, which is the 
>home of some 
>> excellent beer, that could be an appropriate mechanism for 
>the penalty 
>> system.
>> 
>> > Best regards,
>> > Georgios
>> > 
>> > 
>> >  
>> >

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 15 Mar 2007 13:57:55 +0100

Hi Robert, all,

> machine'? - they're quite different things.

This is a long lasting confusion and all discussion simply talk about  
'cause transitions within the state machine'.

[...]

> of some excellent beer, that could be an appropriate mechanism

I highly endorse this! :-)

   Martin

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Thu, 15 Mar 2007 15:50:34 -0500

Hi Robert, All,

> Sent: Thursday, March 15, 2007 6:41 AM
> To: 'Georgios Karagiannis'; [email-masked]; ASH, 
> GERALD R, ATTLABS; [email-masked]
> Cc: [email-masked]

Right, FSMs  = states, events/triggers, actions, and transitions...
Perhaps we're guilty of fast and loose terminology but I suspect some
might know what it is and may have even designed FSMs for real protocols
(e.g., moi).  However I'd be delighted to discuss this at length over
several beers, and it will surely become clearer and clearer as more and
more beers are consumed :-)
 
> these to be triggered, there shouldn't be a problem.

It's the 'arbitrary local events' over the RMF API that I think the
discussion is about, and which ones are actually allowed events/triggers
within the NSLP FSM, and which events/triggers make sense coming from an
RMF over an API.  

For example, we have in Appendix A:

"A.2 Triggers from RMF/QOSM towards QOS-NSLP
...
    * features_out: it represents among others the flags that can
        be used by the QOS-NSLP
        for new generated QoS-NSLP messages:

      ** BREAK
      ** REQUEST REDUCED REFRESHES
      ** RESERVE-INIT
      ** TEAR
      ** REPLACE
      ** ACK-REQ
      ** PROXY
      ** SCOPING
      ** BYPASSING:  when the outgoing message should be bypassed
         then it includes the required bypassing level. Otherwise it
         is empty. It can be set only by QNI_Ingress, QNR_Ingress,
         QNI_Egress, QNR_Egress. It can be unset only by QNI_Ingress,
         QNR_Ingress, QNI_Egress, QNR_Egress
      ** BINDING ()
         when BINDING is required then it includes a
         BOUND_SESSION_ID list. Otherwise it is empty. It can
         only be requested by the following QNE types:
         QNI, QNR, QNI_Ingress, QNR_Ingress, QNI_Egress,
         QNR_Egress

It seems that many of these triggers are defined within the 'QoS NSLP
FSM' but some may not be (BYPASSING, BINDING, etc.).  Also, do all these
events/triggers make sense in the FSM coming from the RMF API (e.g.,
REQUEST REDUCED REFRESHES?).  And for BYPASSING and BINDING it says "It
can be set only by QNI_Ingress, QNR_Ingress, QNI_Egress, QNR_Egress", so
is the RMF API included in being able to set? 

In particular, are we going to see the QoS NSLP FSM with all its states,
events/triggers, actions, and transitions so that this discussion about
NSLP FSM will become more precise?

Thanks,
Jerry