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

From: "McDonald, Andrew" <[email-masked]>
Date: Wed, 8 Oct 2003 17:56:42 +0100

Hi 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.

Does that help to give a clearer picture?

Regards,

Andrew

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