Subject: [NSIS] state management question

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 18 Mar 2003 23:29:49 -0000

Dear all,

As discussed in today's session, there may or may not be an open issue about how much the NTLP should 'know' or 'do' about providing a state management service to signalling applications, or being aware that signalling applications are using the NTLP to do state management. (Note that this is entirely not about state that the NTLP uses internally, e.g. to route messages correctly.)

This is described as an open issue in section 3.4.2 of the current draft. Some of what is discussed there is certainly more than an implementation issue, since it relates to what message types the protocol supports, whether the protocol explicitly carries timing and related control information, and so on.

The pure question of whether the NTLP treats a refresh message differently from a 'new' message could be considered a node-internal implementation issue - provided you only expect this treatment to take place at nodes processing that signalling application and not intermediate ones. Consider a possible example:
1. The NTLP design is such that downstream (sender-->receiver) messages will be sent in end-to-end addressed router-alerting PATH-like packets.
2. An signalling application which generates a downstream message which is basically a refresh will have that message seen at every downstream node.
3. Any node which doesn't support that signalling application (i.e. not including the message sender) will have no choice but to forward that message immediately. Network desynchronisation actions can only be taken at the signalling application aware nodes.

Are we worried about this sort of thing? I'd be very happy with the 'NTLP is 100% ignorant of signalling application state management' approach. However, some people might see it as a departure from 'typical' RSVP behaviour. It's also clearly different from the original CSTP proposal (e.g. section 2.2 of Bob's 2 level draft).

I'd invite people who think that the NTLP should contain standardised (i.e. non-implementation specific) functionality to do something related to state management to say what that functionality should be.

Cheers,

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

---

From: Roland Bless <[email-masked]>
Date: Wed, 19 Mar 2003 20:27:20 +0100

Hi Robert,

>Are we worried about this sort of thing? I'd be very happy with the 'NTLP is 100% ignorant of signalling application state management' approach. However, some people might see it as a 
>
Yes, I share this view. Especially, in the mobility context, NTLP 
"connections" may change
more often during a handover. In these environments, you are usually 
interested in keeping/refreshing state in the NSLP independently of the 
underlying transport.

>departure from 'typical' RSVP behaviour. It's also clearly different from the original CSTP proposal (e.g. section 2.2 of Bob's 2 level draft).
>
Roland

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 20 Mar 2003 14:27:24 -0800

--On Dienstag, 18. März 2003 23:29 +0000 "Hancock, Robert" 
<[email-masked]> wrote:

> Dear all,
>
> As discussed in today's session, there may or may not be an open issue
> about how much the NTLP should 'know' or 'do' about providing a state
> management service to signalling applications, or being aware that
> signalling applications are using the NTLP to do state management. (Note
> that this is entirely not about state that the NTLP uses internally, e.g.
> to route messages correctly.)
>

The actual problem is that signaling is not only about state management as 
some people think. It involved also the triggering of functionality on the 
nodes using the state as argument.

If state management is not part of NTLP I do not see what NTLP is doing 
more than only forwarding signaling messages.

> The pure question of whether the NTLP treats a refresh message
> differently from a 'new' message could be considered a node-internal
> implementation issue - provided you only expect this treatment to take
> place at nodes processing that signalling application and not
> intermediate ones. Consider a possible example: 1. The NTLP design is
> such that downstream (sender-->receiver) messages will be sent in
> end-to-end addressed router-alerting PATH-like packets. 2. An signalling
> application which generates a downstream message which is basically a
> refresh will have that message seen at every downstream node. 3. Any node
> which doesn't support that signalling application (i.e. not including the
> message sender) will have no choice but to forward that message
> immediately. Network desynchronisation actions can only be taken at the
> signalling application aware nodes.
>
> Are we worried about this sort of thing? I'd be very happy with the 'NTLP
> is 100% ignorant of signalling application state management' approach.
> However, some people might see it as a departure from 'typical' RSVP
> behaviour. It's also clearly different from the original CSTP proposal
> (e.g. section 2.2 of Bob's 2 level draft).
>

In RSVP it is just fully integrated. IMHO state management should be in the 
core of NTLP. I also understand the problem with the more complex interface 
to signaling application. But I assume this heavily depends on how you 
implement it.

> I'd invite people who think that the NTLP should contain standardised
> (i.e. non-implementation specific) functionality to do something related
> to state management to say what that functionality should be.

The functionality should include refreshing, removing state in case of 
failure (timeout). In the perspective of "context transfer" having 
generalized state management makes a lot of sense to have generic state 
transfer.

What I currently cannot judge is what variety of state management is needed 
for the different signaling application.

Marcus
--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus