Subject: [Sigtran] ASP Load sharing

From: "PSK Chakravarthi" <[email-masked]>
Date: Thu, 19 Dec 2002 18:49:09 +0530

Brian,

How an ASP finds out that another ASP is down?  Is it by polling? If so,

ASP1 and ASP2 are controlling AS1.  Traffic mode of ASP1 and ASP2 is
load-share.

ASP2 detected loss of communication with ASP1.
As per mail discussions ASP2 now sends ASP-Inactive message to SGP to
indicate ASP1 is down.
But the communication between SGP and ASP1 may be OK.  Loss of communication
between two ASPs can not decide that one ASP is in problem.  If so even ASP1
may send ASP_Inactive message to SGP to indicate that ASP2 is down.
I feel only SGP should decide the state of ASP, so that there will not be
any ambiguity in deciding the state of an ASP.  But if experts feels that an
ASP can detect the failure of another ASP and can inform SGP then that ASP
can use NOTIFY message.  Notify message got both ASP Id and Routing context.
So SGP can find out which ASP is down.  We need not keep any constraint on
ASP Id that ASP Id should be globally unique.  Also we need to change
ASP-Inactive and ASP-Down messages. Please note that (section 3.8.2) NOTIFY
can be sent from a M3UA peer to another M3UA.

Thanks
Chak

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Dec 2002 09:49:23 -0700

Chak,

You are making presumptions about how ASPs communicate or share state.  The
RFC cannot do this because these two things are outside the scope of the UA
protocol.  ASPs might be, for example, SBCs on a shared backplane, where one
ASP can in almost all circumstances know the health and state of another ASP
better than the SGP which is only connected from a distance via SCTP.

M2UA, M3UA and SUA provide the NTFY("ASP Failure") mechanism precisely to
resolve the situtation where ASPs in an AS are incapable of determining
(precisely) whether an ASP has failed in the AS.  They can then rely on this
notificiation from the SGP.  This is why NTFY("ASP Failure") was always
intended to be REQUIRED behavior of the SGP when it detects loss of
communications with an ASP.

However, as with other Notifications, NTFY("ASP Failure") does not require
behavior from the ASP.  The principle behind notifications are that they
provide the information necessary to permit the ASPs to control their own
state.

For dynamic port allocation and other situations where the SGP cannot
determine the identitiy of an ASP from the connecting IP address(es) and port
(one of the original purposes of "ASP Id"), and for cases allowing dynamic
registration of all ASPs in all AS, the ASP Id is required to uniquely
identify an ASP to an SGP.  This has always been the case.  For use of ASP Id
in ASP Down, the ASP Id would need to uniquely identify an ASP to an SGP,
which is no more than is required of it when it is used for dynamic port
allocation (in the ASP Up message) or where each ASP can dynamically register
for all ASs (for the Notify messages).

The ASP never sends Notify to an SGP.  It has no reason to do so: it has
ASPSM and ASPTM messages to control the SGP.  Having an ASP notify an SGP
woule be against the principle of placing the ASPs in control.  It is natural
to place ASP Id in ASPSM messages to identify the ASP to which the message
applies, in the same manner as RC is used in ASPTM messages to identify the
AS to which the message applies.  ASPSM messages (except BEAT and BEAT ACK)
affect overall ASP state (Up/Down); ASPTM messages affect ASP state for
a specific AS (Active/Inactive).  It is natural to the architecture that ASP
Id uniquely identify an ASP to an SGP, and that this identification is not
local to an AS.   The SGP naturally identifies an ASP as "the ASP which is
at the other end of this SCTP association", and the RFC requires that some
mechanism be in place to avoid multiple SCTP assocations from an SGP to the
same ASP (or the use of ASP Id in ASP Up) to ensure that this is the case.

Now, the only way for ASP Id to be initially communicated from ASP to SGP
is via the ASP Up message.  There is no way to "negotiate" this value.
ThereFore, ASP Id, where it is used, must be provisioned on SGP and ASP.
During provisioning, it is a trivial matter to make the ASP Id not only
uniquely identify an ASP to an SGP, but also to make it uniquely identify
the ASP to all SGP to which the ASP communicates.  Just number your ASPs
starting with a number (n) starting with '1' for the first ASP and through
to 'N' for the last ASP.  Assign ASP Id to have the value 'n' and you're
done.  In fact, if you try to restrict the scope of the ASP Id to less than
global, all you are accomplishing is creating administrative work for
yourself.  Although the RFC could be interpreted to allow someone to be
so foolish in their assignments of ASP Id, it certainly cannot be construed
to recommend it.

I think we should clearly state in the IG that the ASP Id MUST uniquely
identify an ASP to an SGP and SHOULD uniqely identify an ASP to all SGP
to which it is configured to communicate.  And the IG should add the
ASP Id parameter to the ASP Down message in fitting with John Schantz'
original proposal which I recently revisited.

--brian

PSK Chakravarthi wrote:                          (Thu, 19 Dec 2002 18:49:09)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/