Subject: [NSIS] state management and the nsis framework

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 8 May 2003 13:17:01 +0100

dear colleagues,

after some discussion about layer split issues and 'state management', i have attempted to put together some text of a proposal. I think this addresses most of the concerns expressed either on the mailing list or directly (to me). 

please let me know if it seems to be wrong/meaningless/unclear/disagreeable for any other reason. for now, I would like to use it as a working assumption.

cheers,

robert h.

===================================================================
[probably to go somewhere in section 3.2]
State Management (and the Layer Split)

Internet signalling requires the existence and management of state within the network for several reasons, ranging from state specific to signalling applications (e.g. buffer space allocations on interfaces or firewall pinhole status) to state needed to support signalling message transport (e.g. who is the peer to forward upstream signalling messages to). This section describes how state management functionality is split across the NSIS layers.

0. How the NTLP internal state is managed is a matter for its design and indeed implementation.

1. Conceptually, the NTLP provides a uniform message delivery service to signalling applications. It is unaware of the difference in state semantics between different types of signalling application message (e.g. whether a message changes or just refreshes signalling application state, or even has nothing to with signalling application state at all).

2. An NTLP instance in a node processes and if necessary forwards all signalling application messages "immediately". (It might offer different service classes, but these would be distinguished e.g. by reliability or priority, not signalling application state aspects.) Observable consequences of this are that the NTLP does not contain explicit timer or message sequence information related to the signalling application; and that signalling application messages pass immediately through an NSLP-unaware node (they can't be jittered there, or re-sent onto alternative paths if re-routing takes place later).

3. Within any node, it's an implementation decision whether to generate/jitter/filter refreshes either separately within each signalling application that needs this functionality, or as part of generic/shared code (a "soft-state management toolbox") more closely associated with the NTLP. The choice doesn't affect the NTLP specification at all. Implementations might piggy-back NTLP soft-state refreshe information (if the NTLP works this way) on signalling application messages, or even combine soft-state management between layers.

4. It may be helpful for signalling applications to receive state-management related 'triggers' from the NTLP, that a peer has failed or become available ("down/up notifications"). These triggers would be about adjacent NTLP peers, rather than signalling application peers. We can consider this as another case of route change detection/notification (which the NTLP is also supposed to do anyway).

4a. It is an open issue (i.e. we need to think more about) how sophisticated to make the definition of what triggers the NSLP would like; for example, should 'down' mean 'any loss of contact' or 'loss of contact for more than X seconds' and so on. Probably, we should err on the side of simplicity, and also require that the meaning of the trigger should not depend on how the NTLP generates it (which could be some lower layer connection reset, or loss of some number of NTLP-internal refreshes, or some other external source).

5. The existence of these triggers doesn't replace NSLP refreshes as the mechanism for maintaining liveness at the signalling application level. In this sense, up/down notifications are advisories which allow faster reaction to events in the network, but shouldn't be built into NSLP semantics. (This is essentially the same distinction - with the same rationale - as SNMP makes between traps and normal messages.)

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

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Fri, 9 May 2003 10:10:45 +0200

Hello Robert,

Please watch my oppion in the text.

> Internet signalling requires the existence and management of state within
the network for several reasons, ranging from state specific to signalling
applications (e.g. buffer space allocations on interfaces or firewall
pinhole status) to state needed to support signalling message transport
(e.g. who is the peer to forward upstream signalling messages to). This
section describes how state management functionality is split across the
NSIS layers.
> 0. How the NTLP internal state is managed is a matter for its design and
indeed implementation.

ok, I hope that the internal states can support almost all potential
signaling applications.

> 1. Conceptually, the NTLP provides a uniform message delivery service to
signalling applications. It is unaware of the difference in state semantics
between different types of signalling application message (e.g. whether a
message changes or just refreshes signalling application state, or even has
nothing to with signalling application state at all).

ok. NSLP will use the message and control all of the state of signaling
application. It means that if
NSLP want to send a message refresh, it must asks NTLP to do it. But I think
that NTLP can support something automatic and repeated (as the soft-state
management toolbox)  (3) , eg : NSLP ask NTLP : during T1(ms) please send
the refresh message every K(ms), if there is an error, send a notification.

> 2. An NTLP instance in a node processes and if necessary forwards all
signalling application messages "immediately". (It might offer different
service classes, but these would be distinguished e.g. by reliability or
priority, not signalling application state aspects.) Observable consequences
of this are that the NTLP does not contain explicit timer or message
sequence information related to the signalling application; and that
signalling application messages pass immediately through an NSLP-unaware
node (they can't be jittered there, or re-sent onto alternative paths if
re-routing takes place later).

ok. it's great, especially for path-decoupled signaling and the
signaling is more flexible in a heterogenous environment . I think about a
field which can tell NTLP continue processing or forwarding the message when
NTLP examine the header of  the message.

> 3. Within any node, it's an implementation decision whether to
generate/jitter/filter refreshes either separately within each signalling
application that needs this functionality, or as part of generic/shared code
(a "soft-state management toolbox") more closely associated with the NTLP.
The choice doesn't affect the NTLP specification at all. Implementations
might piggy-back NTLP soft-state refreshe information (if the NTLP works
this way) on signalling application messages, or even combine soft-state
management between layers.

I'm very interested in soft-state management toolbox of NTLP et how NSLP
uses it to manage the states of signaling application. This party is clear.

> 4. It may be helpful for signalling applications to receive
state-management related 'triggers' from the NTLP, that a peer has failed or
become available ("down/up notifications"). These triggers would be about
adjacent NTLP peers, rather than signalling application peers. We can
consider this as another case of route change detection/notification (which
the NTLP is also supposed to do anyway).

ok, Can we call them common triggers for all NSLPs ?  eg : if NTLP see that
the routing table is changed, it will notify its NSLP and adjacent NTLP.

> 4a. It is an open issue (i.e. we need to think more about) how
sophisticated to make the definition of what triggers the NSLP would like;
for example, should 'down' mean 'any loss of contact' or 'loss of contact
for more than X seconds' and so on. Probably, we should err on the side of
simplicity, and also require that the meaning of the trigger should not
depend on how the NTLP generates it (which could be some lower layer
connection reset, or loss of some number of NTLP-internal refreshes, or some
other external source).

ok, I think it depends on each particular signaling application. For exemple
: 'down' should mean
    + any loss of contact
    + loss of contact for more than X seconds or after resending X times a
message.
    + receive a notification of error from NTLP or from some other
application, other entities...

> 5. The existence of these triggers doesn't replace NSLP refreshes as the
mechanism for maintaining liveness at the signalling application level. In
this sense, up/down notifications are advisories which allow faster reaction
to events in the network, but shouldn't be built into NSLP semantics. (This
is essentially the same distinction - with the same rationale - as SNMP
makes between traps and normal messages.)

I think something are not clear. You mean the error triggers and the normal
operation  of soft-state management. I don't understand the reason why you
talk about the replacement of error triggers and normal operation.

Nary Tra

PhD student
ENST, Paris
Tel: (0033) (0) 1 45 81 71 06.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 12 May 2003 11:57:04 +0200

Hi Robert

Please receive my comments in line!

>> 1. Conceptually, the NTLP provides a uniform message delivery service to
signalling
>> applications. It is unaware of the difference in state semantics between
different types
>> of signalling application message (e.g. whether a message changes or just
refreshes signalling
>> application state, or even has nothing to with signalling application
state at all).

I agree with the statement that the NTLP provides a uniform message delivery
service to signalling
applications. However, the NTLP protocol should be used to initiate, refresh
and teardown a NTLP state.
Therefore different types of NTLP messages are neaded, i.e., to initiate a
NTLP state,
to refresh a NTLP state and to tear down a NTLP state.

>> 2. An NTLP instance in a node processes and if necessary forwards all
signalling application
>> messages "immediately". (It might offer different service classes, but
these would be distinguished
>> e.g. by reliability or priority, not signalling application state
aspects.) Observable consequences of
>> this are that the NTLP does not contain explicit timer or message
sequence information related to
>> the signalling application; and that signalling application messages pass
immediately through an
>> NSLP-unaware node (they can't be jittered there, or re-sent onto
alternative paths if re-routing takes place later).

Here I also agree with you on the fact that the NTLP does not contain
explicit timer or message
sequence information related to the signalling application. However, if the
NTLP needs this information to manage the
NTLP states then this information should be allowed.

>> 3. Within any node, it's an implementation decision whether to
generate/jitter/filter refreshes either
>> separately within each signalling application that needs this
functionality, or as part of generic/shared
>> code (a "soft-state management toolbox") more closely associated with the
NTLP. The choice doesn't
>> affect the NTLP specification at all. Implementations might piggy-back
NTLP soft-state refreshe
>> information (if the NTLP works this way) on signalling application
messages, or even combine
>> soft-state management between layers.

Okay, but will then the following functionality will also be possible:
"The NSLP refresh procedure can be a pure NTLP refresh procedure,
meaning that a refresh NTLP message is periodically sent
through all the NTLP stateful nodes located between NI (sender) and
NR (receiver).  If a NTLP state in a NTLP stateful is not refreshed
on time then the NTLP functionality at this node informs the NSLP state that
the
refresh procedure is unsuccessful. "

>> 4. It may be helpful for signalling applications to receive
state-management related 'triggers'
>> from the NTLP, that a peer has failed or become available ("down/up
notifications"). These triggers
>> would be about adjacent NTLP peers, rather than signalling application
peers. We can consider this
>> as another case of route change detection/notification (which the NTLP is
also supposed to do anyway).

What do you mean by saying that:
"These triggers
would be about adjacent NTLP peers, rather than signalling application
peers."

I think that the NTLP instance should also be able to trigger a NSLP
instance also for other reasons.

>> 5. The existence of these triggers doesn't replace NSLP refreshes as the
mechanism for maintaining
>> liveness at the signalling application level. In this sense, up/down
notifications are advisories which allow
>> faster reaction to events in the network, but shouldn't be built into
NSLP semantics. (This is essentially the
>> same distinction - with the same rationale - as SNMP makes between traps
and normal messages.)

Do you mean that the functionality described in my remark on your remark
(bullet) 3, above,
will not be possible?

Best Regards,
Georgios