RE: M3UA notify message

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Friday, February 24, 2006 3:26 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] M3UA notify message
>
>
> Tolga,
>
> I prefer to read the RFC:
[TOLGA]Let me quote for you also the beginning of this passage:
Appendix A

"A.1 Signalling Network Architecture

   A Signalling Gateway is used to support the transport of MTP3-User
   signalling traffic received from the SS7 network to multiple
   distributed ASPs (e.g., MGCs and IP Databases).  Clearly, the M3UA
   protocol is not designed to meet the performance and reliability
   requirements for such transport by itself.  However, the conjunction
   of distributed architecture and redundant networks provides support
   for reliable transport of signalling traffic over IP."

Although not a normative part of RFC, this section gives a pretty good
overview of how redundancy can be achieved when utilizing M3UA, i.e. "the
conjunction of distributed architecture and redundant networks"

Basically
distributed architecture ==> host redundancy
redundant networks ==> NIC/network redundancy


And it continues as follows:
"To meet the stringent SS7 signalling reliability and performance
   requirements for carrier grade networks, Network Operators might
   require that no single point of failure is present in the end-to-end
   network architecture between an SS7 node and an IP-based application.
   This can typically be achieved through the use of redundant SGPs or
   SGs, redundant hosts, and the provision of redundant QOS-bounded IP
   network paths for SCTP Associations between SCTP End Points."

Again all of the ingredients for a successful carrier grade deployment are
mentioned:
redundant SGPs or SGs, redundant hosts and provision of redundant
QOs-bounded IP network paths for SCTP Associations between SCTP End Points.

Basically, what we did in
http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uacons-00.txt
regrding redundancy issues was not to invent something conceptually new,
just to explain why/how of the M3UA redundancy architecture in detail,
compare it to MTP3 and give some suggestions how to practically achieve it
based on deployment experiences.

People are free to rely on multiple SGPs for network redundancy, but I doubt
they will get the failover quality of SCTP, i.e. failover with no loss and
no missequencing of messages.
>
>    In the example above, each signalling process (SGP, ASP or IPSP) is
>    the end point to more than one SCTP association, leading to more than
>    one other signalling processes.  To support this, a signalling
>    process must be able to support distribution of M3UA messages to many
>    simultaneous active associations.  This message distribution function
>    is based on the status of provisioned Routing Keys, the status of the
>    signalling routes to signalling points in the SS7 network, and the
>    redundancy model (active-standby, load sharing, broadcast, n+k) of
>    the remote signalling processes.
>
>    For carrier grade networks, the failure or isolation of a particular
>    signalling process should not cause stable calls or transactions to
>    be lost.  This implies that signalling processes need, in some cases,
>    to share the call/transaction state or be able to pass the call state
>    information between each other.  In the case of ASPs performing call
>    processing, coordination may also be required with the related Media
>    Gateway to transfer the MGC control for a particular trunk
>    termination. However, this sharing or communication of
>    call/transaction state information is outside the scope of this
>    document.
>
>    This model serves as an example.  M3UA imposes no restrictions as to
>    the exact layout of the network elements, the message distribution
>    algorithms and the distribution of the signalling processes.
>    Instead, it provides a framework and a set of messages that allow for
>    a flexible and scalable signalling network architecture, aiming to
>    provide reliability and performance.
>
> --brian
>
> Tolga Asveren wrote:
>    (Fri, 24 Feb 2006 14:59:37)
> > Brian,
> >
> > Of course associations can fail. If they fail due to a host
> failure, there
> > is no issue. Now, I assume you speak of premature failures.
> >
> > Let's say, the probablity for an association to prematurely
> fail is p. If p
> > is not satisfying the requirements for a carrier grade
> environment, the SCTP
> > assocation is not fit to be used with M3UA -or one should be
> ready for bad
> > suprises-. There is nothing like something *never* fails, there
> is always a
> > probability for failure for anything, important is that it is under
> > tolerable limits.
> >
> > But, we discussed all this in this mailing list and put something to
> > summarize the result:
> >
> >
http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uacons-00.txt
>
> Specifically Sections 2 and 3 in that draft.
>
>    Thanks,
>    Tolga
>

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

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