Subject: [NSIS] QoS NSLP receiver-initiated reservation

From: Kappler Cornelia <[email-masked]>
Date: Fri, 14 May 2004 18:57:40 +0200

Hi Sven, Andrew and Georgios, 

I have some questions relating to the receiver-ini scenario (Sec 3.5.3 of the new -03 draft).

- Regarding the QUERY message alerting the receiver to issue a RESERVE it says "This QUERY message is instructing the QoS-NSLP process running on each QNE located on the path followed by this QUERY message to install a QoS-NSLP reverse path state" I assume you are referring to NTLP state (referring to a specific NSLP) here, because QUERY is defined to NOT install any QoS-NSLP state. May be the wording should be clarified.

- You mention the information whether OPWA (One-Path-with-Advertising) is used would be carried in the QSpec. However, I think this is Control Information is similar to the RESPONSE-REQUEST Object: It will be processed in the common QoS-NSLP processing to determine what type of message should be sent as a reaction to the incoming message. OPWA is not related to QoS-Model specific processing. It does not need resource information nor are they QSM specific. Therefore OPWA to me is Common Control Information (CCI) not carried in the QSpec.

- Regarding refreshing state, you mention refreshing reverse-path state (and hence GIMPS message associations) sending a QUERY, in addition to refreshing reservation state by sending the RESERVE. Actually I dont understand GIMPS refreshing mechanisms sufficiently. But shouldnt GIMPS notice a message association is still active when in one direction or the other messages come by in QoS NSLP? So it would suffice that RESERVEs are sent (which need to be sent anyways for refreshing the reservation state).

Thanks for your clarifications, Cornelia

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

---

From: "McDonald, Andrew" <[email-masked]>
Date: Mon, 17 May 2004 08:54:31 +0100

Cornelia,

On Fri, May 14, 2004 at 06:57:40PM +0200, Kappler Cornelia wrote:
> - Regarding the QUERY message alerting the receiver to issue a RESERVE it
> says "This QUERY message is instructing the QoS-NSLP process running on
each
> QNE located on the path followed by this QUERY message to install a
QoS-NSLP
> reverse path state" I assume you are referring to NTLP state (referring to
a
> specific NSLP) here, because QUERY is defined to NOT install any QoS-NSLP
> state. May be the wording should be clarified.

Yes, it should be "NTLP reverse path state". I thought I'd caught that one,
but it must have slipped through.

> - You mention the information whether OPWA (One-Path-with-Advertising) is
> used would be carried in the QSpec. However, I think this is Control
> Information is similar to the RESPONSE-REQUEST Object: It will be
processed
> in the common QoS-NSLP processing to determine what type of message should
> be sent as a reaction to the incoming message. OPWA is not related to
> QoS-Model specific processing. It does not need resource information nor
are
> they QSM specific. Therefore OPWA to me is Common Control Information
(CCI)
> not carried in the QSpec.

As I understand it, OPWA is about gathering information along the path to
allow the receiver to determine what reservation can be supported (supported
in RSVP using the Adspec). I think that although there may be
QoS-Model-independent parts of this, there are also QoS-Model-specific parts
(e.g. to me, the fact that Guaranteed Service and Controlled Load have
different requirements for contents of the ADSPEC in RFC2210 would hint at
this). It's probably an area where some more thinking about details would be
useful.

> - Regarding refreshing state, you mention refreshing reverse-path state
(and
> hence GIMPS message associations) sending a QUERY, in addition to
refreshing
> reservation state by sending the RESERVE. Actually I dont understand GIMPS
> refreshing mechanisms sufficiently. But shouldnt GIMPS notice a message
> association is still active when in one direction or the other messages
come
> by in QoS NSLP? So it would suffice that RESERVEs are sent (which need to
be
> sent anyways for refreshing the reservation state).

Yes, this is a good question. GIMPS does not say anything about this at the
moment, and so it is currently identified as an open issue in section 9.6 of
the QoS NSLP draft.

regards,
Andrew