Subject: [NSIS] Scenario Requiring Effectively Persistent State

From: "Schneider, Marco" <[email-masked]>
Date: Tue, 28 May 2002 15:03:26 -0500

Hi All,
In the current requirements draft there is discussion of the need for
automatic release of resources after failure (5.3.2). In the following I
discuss a scenario where "effectively persistent" state is required. In
other words it is desirable that resources are not released after failure.
First consider the case where an end-system (corresponding to an individual
customer) signals NSIS. Let us assume that it has signaled for a number of
QOS flows with itself as either the source or sink of data. Clearly in most
circumstances, if the end-system goes down, there is no reason to maintain
these existing flows since in any case they cannot be utilized during the
period that the end-system is down. As long as flows can easily be
re-established when the end-system comes back up this should satisfy most
requirements. Nevertheless in the case of a "lifeline connection" for voice
over IP, this may not be enough.

In contrast to the above scenario, consider an NSIS proxy controller under
the control of a network operator that signals on behalf of end-systems.
Clearly no existing devices support NSIS and if NSIS becomes successful
there will still be a large number of end-systems and mobile devices that do
not support this protocol. For instance many users may not want to upgrade
their desktop to the newest version of their operating system due to
prohibitive costs. There may also be devices with limited memory or
processing power that cannot signal using NSIS (perhaps less likely). For
all these reasons we may see NSIS proxy controllers that proxy signal NSIS
on behalf of large numbers of end-systems. One particularly important case
will be IP telephony. In such cases the NSIS proxy controller, which is the
initiator of the flow reservations, is independent of the data path and may
be responsible for thousands of simultaneous flows. Such reservations may
include lifeline services. In the case of NSIS proxy controller failure, it
is essential that the existing flow reservations do not get torn down. The
flow reservations generated by this privileged network controlled device
must be effectively persistent in the face of its failure. The requirement
is that NSIS support graceful implementations that enable effectively
persistent state in the face of proxy controller failure. This may or may
not mean that the flow reservations are truly persistent.

Best Regards,
Marco

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 29 May 2002 08:49:16 +0200

Hi Marco,

quite a reasonable argument. I've been going through this
discussion in another group and we concluded:

- As long as an adjacent signaling unit still up 
  discovers no lack of state (e.g. no response on
  a new reservation related message), keeping the
  service up is allright.
- The proxy coming into service again must be able
  to re-install its own state. A secure solution is
  to just allow a check of the remainders of the proxy
  service reservation database in communication with
  adjacent signaling systems.

The latter issue of the proxy being able to re-install
state is quite important. If you can't do that, 
"release" is the best option.

Regards, Rüdiger

> For all these reasons we may see NSIS proxy controllers
> that proxy signal NSIS on behalf of large numbers of
> end-systems. One particularly important case will be
> IP telephony. In such cases the NSIS proxy controller,
> which is the initiator of the flow reservations, is
> independent of the data path and may be responsible 
> for thousands of simultaneous flows. Such reservations
> may include lifeline services. In the case of NSIS proxy 
> controller failure, it is essential that the existing
> flow reservations do not get torn down. The flow
> reservations generated by this privileged network 
> controlled device must be effectively persistent in the
> face of its failure. The requirement is that NSIS 
> support graceful implementations that enable effectively
> persistent state in the face of proxy controller failure. 
> This may or may not mean that the flow reservations are
> truly persistent.