Subject: RE: [NSIS] qos-nslp-00

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 14 Oct 2003 09:46:05 +0200

Hi Andrew,

thanks, your example explains two things I couldn't find in the draft:
- that session IDs still need to be present and aren't replaced 
  by RSNs.
- how QoS-NSLP could react once it notes that it maintains stale
  state.

I'm having another question. The RSN is valid only between local 
NSLP peers. Would a single RSN be used per NSLP message or per 
session ID? Picking up your example, would it be 

a) one RSN per NSLP message
Srefresh [RSN #1, SID #55, SID #105, SID #751]

b) one RSN per SID
Srefresh [RSN #1, SID #55; RSN #78, SID #105; RSN #12, SID #751]

There's no difference if a single message carries data of a single
session. Otherwise, method a) reduces the amount of maintained 
state and signaling load.

Regards, Rüdiger

|Geib, Ruediger wrote:
|> it is not clear to me how the local node reacts once it learns
|> that it maintains stale state. If the only answer is "not at all"
|> I can't see a benefit of the RSN method against session ID based
|> refreshes. On the opposite, the state you have to maintain
|> locally will increase (besides session ID you will have to store
|> incoming and outgoing RSN).
|
|I think we may have got some confusion here on what a 'session ID'
|identifies and what an 'RSN' identifies. The RSN is interpreted in the
|context of a session identifier. i.e. 'Session-ID + RSN' can be used to
|identify some state in a node. 'RSN' on its own could belong 
|to any one of many sessions. Similarly, the QoS reservation may change 
|within a given session, so I don't believe that session ID could be 
|used on its own since it doesn't identify which version of the 
|reservation state it is referring to.
|
|Regarding what to do with a message containing an RSN that 
|isn't for the currently installed state, an example:
|(Remembering that RSN is a *sequence* number that increments when the
|reservation changes).
|
|a) ------------------------------->
|     Full Reserve SID #55, RSN #1
|
|b) <-------------------------------
|        ACK SID #55, RSN #1
|
|c) ------------------------------->
|     Full Reserve SID #55, RSN #2
|
|d) <-------------------------------
|        ACK SID #55, RSN #2
|
|e) ------------------------------->
|       Srefresh SID #55, RSN #1
|
|f) ------------------------------->
|       Srefresh SID #55, RSN #2
|
|g) ------------------------------->
|       Srefresh SID #55, RSN #3
|
|h) ------------------------------->
|       Srefresh SID #31, RSN #2
|
|Message (a) installs some state. Message (b) acknowledges that 
|state was successful installed (and can be referred to by 
|subsequent summary refreshes). Message (c) installs some new 
|state (e.g. asking for different resources) which replaces that 
|which was installed by message (a). Message (d) acknowledges 
|that state was successful installed.
|
|Message (e) refers to 'old' state (message RSN < current state 
|RSN). Possibly the messages got reordered between the nodes. We 
|might just be able to discard this refresh message silently.
|
|Message (f) refers to our currently installed state, so we 
|refresh it as requested.
|
|Message (g) refers to some future state that we haven't got 
|(message RSN > current state RSN). We need to signal an error 
|back (since our neighbour thinks we've got state we haven't, 
|and will probably carry on trying to just refresh it unless 
|told otherwise). I guess one possibility is that there has
|been some oscillation in the route (i.e. the Full Reserve for 
|SID #55, RSN #3 went to a different node but that wasn't the 
|route for long enough for us to time out our soft state).
|
|Message (h) refers to some state for a SID we don't know 
|about. Possibly the route has changed. Again, we need to signal 
|an error back to get a full refresh of our state.

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