RE: RFC 4666 on Signaling System 7 (SS7)MessageTransferPart 3 (MTP3) - User Adaptation Layer (M3UA)

We support this scenario and have deployed it in some networks for
various reasons. 

-----Original Message-----
From: Ilie Glib [mailto:[email protected]] 
Sent: Friday, September 22, 2006 11:41 AM
To: [email protected]; [email protected]
Subject: Re: [Sigtran] RFC 4666 on Signaling System 7
(SS7)MessageTransferPart 3 (MTP3) - User Adaptation Layer (M3UA)

Hello Brian,

Do you really think that it is normal when there are multiple SCTP
associations between two processes, an SGP and an ASP?
How many signalling processes would see each process in that scenario?

By the way Figure 5 in RFC 3332 does not show that case.

Regards

-Ilie

On 9/21/06, Brian F. G. Bidulock <[email protected]> wrote:
> Tolga,
>
> It was always the intention of the SIGTRAN protocols that they support

> multiple associations between ASP and SGP.
> See, for example, Figure 5 in RFC 3332.  That figure shows a near full

> mesh of SCTP associations between SGP and ASP.
>
> The purpose of multiple hosts in an SG or MGC is reliability.
> If you place one association between them, you have a single point of 
> failure.  Carrier grade systems are designed for no single point of 
> failure.  To ensure no SPOF, you need multiple SGP in an SG, multiple 
> SG, and multiple ASPs in an MGC.
>
> M3UA cannot handle sequenced changeover or changeback between 
> associations without message loss (or worse,
> duplication) using local procedures.  A protocol mechanism such as 
> corid is necessary.
>
> SS7 does this (all day long).  CORID is precisely the SS7 procedures 
> applied to SIGTRAN.
>
> If there is some point(s) in the draft that you disagree with perhaps 
> you could quote them and make some suggestions for improvement.
>
> --brian
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>


--
Ilie

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