Subject: [NSIS] QoS NSLP: summary object

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 9 Nov 2006 22:39:11 +0200 (EET)

Based on John's request, here is recap of the summary object mentioned 
today. After Roland's comment on the mic, there are actually two use 
cases:

1. Allow a QNE to refresh several sessions in one NSLP refreshing RESERVE 
message. 

2. Allow a ANE to tear down several sessions in one NSLP tearing 
RESERVE message.

Both of these save bytes and processing compared to doing it independently 
for each session. They can be implemented outside GIST by keeping track of 
the SII_HANDLE provided by GIST (however, you can only know the handle 
after you have received a message from the per, e.g., a RESPONSE). If a 
QNE has sessions whose next peer has the same SII_HANDLE, it can use a new 
SESSION_LIST where it indicates SID+RSN pairs of sessions it wants to 
refresh or tear down. The receiving QNE, in case of unknown SID, will 
reply with a RESPONSE carrying the same object to indicate which session 
references where not understood. If a confirmation was requested from the 
QNR for a tear, and it must send an individual RESPONSE for each 
terminated session, as usual - the summary refresh could hit a QNR with 
multiple sessions being terminated.

We would like to add this to the NSLP spec. Any comments, arguments, 
feedback? I'll wait for a week, then add this unless I hear arguments 
against.

Jukka

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

---

From: Roland Bless <[email-masked]>
Date: Thu, 09 Nov 2006 22:28:46 +0100

Hi Jukka and all,

> after you have received a message from the per, e.g., a RESPONSE). If a 

Not quite. After you received a GIST response. GIST will report it
upwards to the NSLP. However, you care about refresh or tear only
after the initial setup worked. So I don't see any problems here.
Furthermore, it is an optimization, so basically no problem if it
is not applicable in some rare cases.

> refresh or tear down. The receiving QNE, in case of unknown SID, will 

Yes, and as we just discussed in private, it would be good to have
an SID-List only object (SIDs w/o RSN), too.

> multiple sessions being terminated.

In this case we would get a summary error back.

> feedback? I'll wait for a week, then add this unless I hear arguments 

Obviously I'm in favor of having that. However, we must be careful
about covering the new error cases and handle them properly.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 9 Nov 2006 23:47:54 +0200 (EET)

Hi,
two comments back. :)

Jukka

> is not applicable in some rare cases.

[1] This note comes from looking at the GIST API. In order to send a 
summary refresh, you need to have compared the GIST SII_HANDLE before. And 
you will only get to know the SII_HANDLE for a session if you receive the 
RESPONSE. It is not a problem in the general case, just a note.

> an SID-List only object (SIDs w/o RSN), too.

[2] Actualy... may be not. You need the SID AND the RSN for both tear and 
refresh. Thus, you need to send both anyway. RSN is a mandatory object for 
all RESERVE messages. You need to have the RSN in synch if you are tearing 
otherwise you will tear a different state than the previous QNE.

---

From: Roland Bless <[email-masked]>
Date: Thu, 09 Nov 2006 23:24:58 +0100

Hi Jukka,

> RESPONSE. It is not a problem in the general case, just a note.

That is not correct. You get the SII-Handle from GIST
as soon you got the _GIST_ Response back (NOT the QoS NSLP
RESPONSE) from the other peer (you should get a NetworkNotification
that passes the SII-handle). However,
you'll do summary refreshes/tears only for established sessions
anyway, so you'll have the SII-handle in all cases.

> otherwise you will tear a different state than the previous QNE.

My thinking was that if you are tearing the session you maybe don't
care about it's current state anymore?

Cheers (you got the beer),
 Roland

---

From: Takako Sanda <[email-masked]>
Date: Fri, 10 Nov 2006 10:52:44 +0900

Hi Jukka,

On Thu, 09 Nov 2006 22:39:11 +0200 (EET)

> 2. Allow a ANE to tear down several sessions in one NSLP tearing 

I agree to having these use cases.

But I am wondering how QNE decides to send summary refresh/teardown.

For example, in aggregation scenario, there may be the case that summary
refresh/teardown should not be done, i.e. some of the aggregated
sessions need to be refreshed/torn individually.
So, QNE may need to have some mechanisms to know if summary refresh is
required or not.

cheers,
Takako

---

From: [email-masked]
Date: Fri, 10 Nov 2006 04:03:35 +0200 (EET)

Hi,
A simple example: session refresh between domains, your QNE knows it is
the edge. For the tear, a mobility scenario, where several flows change
paths and you want to tear old states.

Jukka