Subject: RE: [Sigtran] M3UA: Broadcast traffic Mode

From: "Goel, Soni" <[email-masked]>
Date: Fri, 22 Feb 2002 13:07:40 -0800

Hi Brian,

This means Broadcast mode is required only for loose synchronization of
ASPs.
It seems from this mail that a master ASP (Suppose ASP1) will receive DATA
messages and send MTP-TRANSFER indication to M3UA user.
While the slave ASP (Suppose ASP2) will receive DATA messages and discard
them.
This means that the M3UA User of ASP2 is not synchronized with the present
state of M3UA User of ASP1 (i.e. they are not tightly synchronized)
Now SGP sends a DATA message to both ASP1 and ASP2.
M3UA User at ASP1 processed this DATA message and reached a state X.
Since the M3UA User at ASP2 has not been processing any messages, therefore
it is in its initial state.
Suppose now the association of ASP1 with SGP went down.
Now how do you expect that the M3UA user at ASP2 can straightaway start
processing further messages sent by SGP when it is still in its initial
state ?

- Soni

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, February 21, 2002 8:17 PM
To: Goel, Soni
Cc: [email-masked]'
Subject: Re: [Sigtran] M3UA: Broadcast traffic Mode

Goel,

Goel, Soni wrote:                                (Thu, 21 Feb 2002 18:53:44)
> Hi Brian,
> 
> This is in reference to the threads you listed.
> I am attaching a mail from archive which talks about the usage of
Broadcast
> mode. 
> 
> As per this mail Broadcast mode supports a Hot standby approach at ASPs.
> Isn't the Hot standby approach required for complete synchronisation of
two
> entities ? 

No.  The note you attached below describe situations where only loose
synchornization is required.

> If yes, then does it mean that M3UA Users at 2 ASPs acting in Broadcast
mode
> should be completely synchronised ? 
> If yes, then the slave ASP should also send MTP-TRANSFER indications to
keep
> the M3UA user completely synchronised. 
> But this means it will need to respond back to this DATA message and thus
> all the ASPs will be responding back to the same DATA message. Am I
> missing/adding something ?

I think you are missing that broadcast does not mean that any tighter
sychronization is required that is required in loadshare.  Losdshare
merely requires the SGP to do complicated switchovers for which both
SCTP and M3UA are poorly suited; broadcast mode does not.

--brian

> 
> - Soni
> 
> Date: Tue, 24 Jul 2001 05:29:26 -0500
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "sigtran" <[email-masked]>
> Subject: Re: M3UA-07: Broadcast mode changes
> Reply-To: [email-masked]
> User-Agent: Mutt/1.2i
> Organization: http://www.openss7.org/
> Dsn-Notification-To: <[email-masked]>
> X-SMTP-HELO: bfgbhome.inetint.com
> X-SMTP-MAIL-FROM: [email-masked]
> X-SMTP-RCPT-TO: [email-masked]
> X-SMTP-PEER-INFO: [209.44.42.202]
> X-Orig: <[email-masked]>
> X-Orig: <[email-masked]>
> X-Orig: <[email-masked]>
> List-Unsubscribe: <mailto:[email-masked]>
> 
> Maria,
> 
> It was discussed briefly in two threads (grep for "broadcast" and "Traffic
> Modes").
> 
> The purpose of broadcast mode is to permit the a pool of ASPs to run fully
> synchronized and Hot Standby.
> 
> The leader-follower synchronization afforded by override and load-share
are
> what I would call "Warm" Standby.
> 
> It also permits a loosely coupled synchronization for applications where
> precise state syncrhonization between ASPs is neither necessary nor
> economical.
> 
> The purpose of adding it was to support these modes, and because the UAs
do
> not permit any implementation-defined traffic modes.
> 
> Broadcasting could be accomplished between the ASPs instead; however,
> broadcasting at the SG handles the situation (it is more efficient) where
> ASPs are geographically diverse, particularly where loose synchronization
is
> permitted by the application.
> 
> Most SS7 applications (ISUP, TCAP) are robust against duplication and
> ommission errors, permitting loose synchronization.
> 
> Consider that one ASP is in Madrid and the other is in Dallas.
> It is efficient if the SGP sends messages to both and the ASPs coordinate
on
> who is actively processing which messages (although both process each,
only
> one reacts).  Say, one ASP is master for one traffic flow and the other is
> slave.  Visa versa for other traffic flows.  When an ASP is informed of
the
> failure of the other, it starts active processing of slave messages.
> This is just one possible arrangement with broadcast mode.
> 
> Certainly the SGP performs this simple little broadcast function and a
wide
> spectrum of redundancy arrangements become possible at the ASP.
> 
> Certainly the SCTP assocations permit the SGP to perform a time-bounded
> reliable broadcast: the basis for all distributed atomic locking
protocols.
> Even hard and tight synchronization is possible.  ASPs can use a
symmetrical
> voting algorithm and better address babbling idiot and psychotic sister
> syndromes.
> 
> For example the common 3 out of 4 voting performed between fault tolerant
> processor quads is possible in a more distributed architecture.
> 
> These symmetrical voting algorithms depend upon the fact that there is no
> one member of the vote who is responsible for calling for the vote ('cuase
> if that guy failed, so would the whole voting process).  Implementing them
> is easier when the incoming messages are broadcast over a bus (or
network).
> 
> Is that enough detail?  (Or, should I draw diagrams...  ;)
> 
> --Brian
> 

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 22 Feb 2002 23:02:22 -0600

Goel,,

Both ASPs process each message to loosely sychronize state.  Only
the response from one ASP is acrually returned, the response from
the other is discarded before it is sent.

Because both ASPs have the same inputs events, they are in the same
state but loosely synchronized.

The only communication necessary between the ASPs is a periodic
heartbeat to determine if the other ASP is alive.  If an ASP fails,
the output events for all messages are sent from the remaining ASPs.

A few output events might be lost, but far less than the input events
that would be lost in an active/standby or loadshare failover.

This is a cost-effective way to acheive high reliability at a distance
using loose coupling but resulting anyway close syncrhonization.

--brian

Goel, Soni wrote:                                    (Fri, 22 Feb 2002 13:07:40)

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