Subject: [NSIS] QSPEC3: Information API in QoS NSLP

From: Martin Stiemerling <[email-masked]>
Date: Tue, 6 Feb 2007 14:55:33 +0100

I believe we have reached consensus for this item QSPEC3. If not,  
please object now.

- The QoS NSLP draft needs an informational section describing the  
API between QSPEC and QoS NSLP. This informational section should be  
in the spirit of the API description in GIST, i.e., giving guidance  
to implementers.

   Martin

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

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 6 Feb 2007 15:47:24 +0100

Hi Martin

I agree, but the RMF triggers are internal triggers betweeen QOSM and
QOS-NSLP thus 
they can be considered as API information. 
Thus your issue QSPEC1 is a part of this issue(QSPEC3).
Thus the RMF triggers should be given in the QOS-NSLP, but they should only 
be giving guidance to implementers and they should not restrict the
flexibility and extensibility of 
the QOSM.

Best Regards,
Georgios

> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: dinsdag 6 februari 2007 14:56
> To: nsis
> Subject: [NSIS] QSPEC3: Information API in QoS NSLP
> 
> I believe we have reached consensus for this item QSPEC3. If 
> not, please object now.
> 
> - The QoS NSLP draft needs an informational section 
> describing the API between QSPEC and QoS NSLP. This 
> informational section should be in the spirit of the API 
> description in GIST, i.e., giving guidance to implementers.
> 
>    Martin
> 
> 
> 
> 
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL 
> | Registered in England 2832014
> 
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 6 Feb 2007 09:12:56 -0600

Georgios,

Unfortunately, I must disagree. The QoS NSLP is a Standards Track
protocol,
the QoSM documents are only informational.  QoSM MUST use the standard
mechanisms defined in the QoS NSLP.  The signaling between the RMF and
QoS
NSLP must follow the message processing rules in the QoS NSLP.  If there
are changes to the message processing rules in the QoS NLSP, then the
QoSM MUST define a fall-back to the rules defined in the QoSM.

John

>From: ext Georgios Karagiannis [mailto:[email-masked]] 
>Sent: 06 February, 2007 06:47
>To: 'Martin Stiemerling'; 'nsis'
>Subject: RE: [NSIS] QSPEC3: Information API in QoS NSLP
>
>Hi Martin
>
>I agree, but the RMF triggers are internal triggers betweeen 
>QOSM and QOS-NSLP thus they can be considered as API information. 
>Thus the RMF triggers should be given in the QOS-NSLP, but 
>they should only be giving guidance to implementers and they 
>should not restrict the flexibility and extensibility of the QOSM.
>
>
>Best Regards,
>Georgios
>
>
> 
>
>describing the API 
>> between QSPEC and QoS NSLP. This informational section should be in 
>> the spirit of the API description in GIST, i.e., giving guidance to 
>> implementers.
>> 
>>    Martin
>> 
>> 
>> 
>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 6 Feb 2007 16:23:42 +0100

Hi John 

If you mean externally observable message processing rules, then it is okay!
Note that according to the NSIS goals, NSIS should be able to initiate and
maintain the
unidirectional/bidirectional and sender/receiver 
reservation intiation, refresh, tear, modification of:
 * bound and parallel end-to-end and end-to-end sessions 
 * bound and parallel end-to-end and edge-to-edge sessions 
 * bound and parallel end-to-end and end-to-edge sessions

* Examples of QOSMs that support end-to-end sessions can be:
  ** Intserv like Controlled Load QOSM
  ** Intserv like Guaranteed Service QOSM

* Examples of QOSMs that can support edge-to-edge sessions can be:
  ** RSVP aggregation like QOSM 
  ** RMD-QOSM
  ** interdomain and intra-domain ITU-T RACF QoS model 
  ** PCN like congestion notifictaion and preemption QoS model.
  ** RSVP-TE like QOSM

* Examples of QOSMs that can support end-to-edge sessions: 
 ** IEEE 802.16

The idea of using the QOSM and thus the specification of the 
RMF triggers was to support and 
provide the above scenarios.
Do you agree?

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: dinsdag 6 februari 2007 16:13
> To: [email-masked]; [email-masked]; [email-masked]
> Unfortunately, I must disagree. The QoS NSLP is a Standards 
> Track protocol, the QoSM documents are only informational.  
> QoSM MUST use the standard mechanisms defined in the QoS 
> NSLP.  The signaling between the RMF and QoS NSLP must follow 
> the message processing rules in the QoS NSLP.  If there are 
> changes to the message processing rules in the QoS NLSP, then 
> the QoSM MUST define a fall-back to the rules defined in the QoSM.
> 
> John
> 
> QOSM and 
> >QOS-NSLP thus they can be considered as API information.
> they should 
> >only be giving guidance to implementers and they should not restrict 
> >the flexibility and extensibility of the QOSM.
> >
> >
> >Best Regards,
> >Georgios
> >
> >
> > 
> >