Subject: [NSIS] session ID

From: [email-masked]
Date: Thu, 13 Feb 2003 15:45:58 +0100

Hi all,

Upon reflection after the NSIS interim meeting, I have a few concerns
regarding the session ID (intended to be able to differentiate existing
session state from new state state, e.g. after a reroute or mobility
event):

1. We must realize that the session ID does not come for free. With only
the flowspec present in the message, one would still have the option of
keeping only (forward/backward) routing state in the NEs and this can be
done per peer. With the session ID (which is necessarily per session), we
are obliged to keep state on a much finer granularity. We may have been
assuming that per-flow state was going to be kept anyway, but other
solutions have already been described.

2. A question that comes to mind is whether the session ID would belong in
the NTLP or in the NSLP. From discussion one might have inferred that it
would be the NTLP. I am not sure about this. I would say that the session
ID refers to state linked to the NSLP (reservation state, ...) and it is
not obvious that it should be in the NTLP. A reason to put it in the NTLP
would be to allow state refresh without going up to the NSLP. If this is
the case we should make that explicit. personally, I don't think it is such
a great idea. How for instance, would one differentiate between a refresh
that requires new AAA (to check credit e.g.) and one that doesn't?

just my 2cc,
Sven

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

---

From: Melinda Shore <[email-masked]>
Date: Thu, 13 Feb 2003 10:00:44 -0500

> the NTLP or in the NSLP.

It seems clear to me that it's not an either/or question.
There's a question about whether or not the NTLP needs a
session identifier for its own purposes, and that question
is independent of the question of what an NSLP would need.

Aside from that, in general I'm not overly fond of
overloaded functionality in protocols.  I believe there's a
good case to be made for a session/flow/what-have-you
identifier in the NTLP to simplify state management (imagine
a case where you've got two different NSIS applications, say
QoS and firewall, manipulating state for one data flow).

It may also simplify message processing in cases where an
NSIS-capable device doesn't support a particular NSIS
application.

Additionally, there may be differences in semantics.  I
would not like to see an NSLP session identifier constrained
in its semantics by the NTLP layer.  There may be issues
around grouping, etc.

Melinda

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Feb 2003 16:22:30 -0500

> session state from new state state, e.g. after a reroute or mobility

The main purpose, in my view, is to identify the state, so that one can 
easily distinguish one session from another session (that may well have 
the same NI/NR pair). If we want to allow multiple sessions between such 
NI/NR pairs, such an identifier is needed, even if we ignore the 
mobility issues.

> 1. We must realize that the session ID does not come for free. With only

How much does it cost, in Euros? :-)

> done per peer. With the session ID (which is necessarily per session), we

No, this doesn't work as soon as you have multiple sessions between two 
NI/NR pairs.

> solutions have already been described.

You cannot just keep state per peer. For details, I suggest reading our 
BGRP work or the discussion on aggregation in the RNAP papers. If you 
have no other information and only the next hop (either forward or 
backward), how do you know where the hop-before-that or hop-after-that 
is? Example:

A ---> B --- > C
        |-----> D

If A sends a message to B that contains no information other than that, 
how does B know whether this should go to C or D?

The state information is exactly the same in A for both C and D, so you 
have no chance to distinguish the state. Aggregation requires a funnel 
or sink-tree model, as far as we've been able to determine.

I suspect that merging requests requires identification at a higher 
layer since it is probably application-specific.

> would be the NTLP. I am not sure about this. I would say that the session

It needs to be in NTLP, since it is required, as discussed above, to 
simply get the message from NI to NR along the chain of NEs. This has 
nothing to do with reservation state. NFs need it to maintain (and 
delete, after timeout) state. How would they know what state to delete 
without this?

> that requires new AAA (to check credit e.g.) and one that doesn't?

The decision on re-authorization properly belongs to the NSLP. In my 
view of things, the NTLP hands up the NSLP object to the appropriate 
handler. The handler does its job and tells the NTLP one of two things: 
forward or error-stop here-return eror message, with a new blob of NSLP 
information.

> just my 2cc,

My two cents (which are worth less than 2cc, unfortunately...).