Subject: [NSIS] Proposal for implementing QoS NSLP Proxy Mode

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 17 Jul 2006 00:43:57 +0300 (EEST)

We had a good discussion with Robert about the QoS NSLP Proxy mode, and at
the end we agreed that the QoS NSLP does not really need much. Actually,
we only need a new scope (besides single link and e2e) called e.g. 
"proxy", and the domain admin must define manually, which QNE operates as 
proxy (Proxy-QNE, P-QNE). Here is how the fing works:

[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender]

For outgoing flows, the end host is the QNI, and sends a RESERVE with the
new proxy-scope bit set. The P-QNE will receive the RESERVE and reply with
a RESPONSE (if requested), and NOT forward the RESERVE further to the next
peer. The receiver-oriented reservation works the same way (QUERY towards
P-QNE, RESERVE back, then RESPONSE to P-QNE, all carrying the proxy-scope
bit).

For incoming flows, the end host is also the QNI, and it sends a RESERVE
towards the data sender with the proxy-scope bit set. Here the end host
sets the MRI so that it indicates the end host as the receiver of the
data, and the D-flag is set. If there is only one P-QNE in the domain,
GIST gets the RESERVE to the P-QNE. If there are more than one P-QNEs,
GIST will do its best, but may reply with an error indicating destination
unreachable.

Jukka

ps. I'll be out of emails for a couple of weeks now. I intend to finalize 
the QoS NSLP draft in August and we can then send it for AD review.

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Jul 2006 12:22:39 +0200 (MEST)

Hi Jukka

Great!
I think that the use of the QoS-NSLP proxy mode is useful and the
additional complexity introduced in the QoS-NSLP by this mode is not big.
Therefore, I agree to include it in the QoS-NSLP draft.

Best regards,
Georgios

---

From: <[email-masked]>
Date: Thu, 27 Jul 2006 02:32:58 +0300

This seems like a reasonable way forward, IMO.

John 

>-----Original Message-----
>From: ext Jukka MJ Manner [mailto:[email-masked]] 
>Sent: 16 July, 2006 17:44
>To: [email-masked]
>Subject: [NSIS] Proposal for implementing QoS NSLP Proxy Mode
>
>
>We had a good discussion with Robert about the QoS NSLP Proxy 
>mode, and at the end we agreed that the QoS NSLP does not 
>really need much. Actually, we only need a new scope (besides 
>single link and e2e) called e.g. 
>"proxy", and the domain admin must define manually, which QNE 
>operates as proxy (Proxy-QNE, P-QNE). Here is how the fing works:
>
>For outgoing flows, the end host is the QNI, and sends a 
>RESERVE with the new proxy-scope bit set. The P-QNE will 
>receive the RESERVE and reply with a RESPONSE (if requested), 
>and NOT forward the RESERVE further to the next peer. The 
>receiver-oriented reservation works the same way (QUERY 
>towards P-QNE, RESERVE back, then RESPONSE to P-QNE, all 
>carrying the proxy-scope bit).
>
>For incoming flows, the end host is also the QNI, and it sends 
>a RESERVE towards the data sender with the proxy-scope bit 
>set. Here the end host sets the MRI so that it indicates the 
>end host as the receiver of the data, and the D-flag is set. 
>If there is only one P-QNE in the domain, GIST gets the 
>RESERVE to the P-QNE. If there are more than one P-QNEs, GIST 
>will do its best, but may reply with an error indicating 
>destination unreachable.
>
>Jukka
>
>ps. I'll be out of emails for a couple of weeks now. I intend 
>to finalize the QoS NSLP draft in August and we can then send 
>it for AD review.
>

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 31 Jul 2006 11:59:06 +0200

Hi Jukka, all,

Sounds as a reasonable way forward!

   Martin

Am 16.07.2006 um 23:43 schrieb Jukka MJ Manner:

> operates as