RE: Multiple SUA SGs, sending for SSP from SGs

"Tolga Asveren" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]>
Stanislav,


-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Stanislav Ivanovich
Sent: Tuesday, January 10, 2006 2:47 PM
To: SIGTRAN
Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs


Hi all,

I agree with Tolga!

I would even say -> why would one after all have several SGW'es for the same
application??? What is it for?

If one wants reliability of transmission resources (SGW'es) then one
installs several SGP'es in the same SGW and provides one logical access
point for each application to SS7 network.


What would be the benefit of multiple SGW per application after all??? Does
anyone know that?
[TOLGA]I think, this may makes sense to provide geographical redundancy for
SG services. It may be not very efficient to have a geographically
distributed SG consisting of multiple SGPs, e.g. where SGPs are in different
cities, if one considers that they have to provide a uniqie view of
SCCP/MTP3 layer they are hosting. OTOH, I believe using SG-SG kind of
approach is a better alternative rather than ASP/SGP multi-SG mechanism,
because with SG-SG, there is no remote hosting of SCCP/MTP3 layers, thus no
problem of multiple copies of the same SCCP/MTP3 instance, which are not
synchronized.

regards/ Stanislav



Tolga Asveren <[email protected]> wrote:
Ilie,

Multiple SG scenarios are overall a bit problematic -or better said require
some care and attention-. This is due to the fact that the SCCP layer for AS
is hosted on SG and if you have multiple SGs, you will have multiple copies
of the same SCCP instance which do not know about each others state -if they
knew, they would be part of the same SG-.

OTOH, for most practical cases, one prbably can survive. If we consider your
example, I would expect ASP to send ASPIA to both SGs, causing each ot them
to send SSP -probably only of them would receive SST though-.

Maybe slightly more interesting scenario is, what happens if ASP looses
connectivity to only one SG? This would cause the subsystem to be available
in one SG and unavailable on the other one, not something we want to have.
OTOH, we should remember multihoming feature of SCTP and what it practically
means to us: SCTP multihoming provides network/NIC redundancy, i.e. loss of
association is an indication for host failure. So, in the scenario I
described if it is ASP which is down, both SGs will detect loss of
association. ! If it is one SG which is down, it won't be able to send SSP.

In any case, one should be careful with multi-SG scenarios.

Thanks,
Tolga


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Ilie Glib
> Sent: Tuesday, January 10, 2006 1:30 PM
> To: SIGTRAN
> Subject: [Sigtran] Multiple SUA SGs, sending for SSP from SGs
>
>
> Hello Folks,
>
> Let's consider two SUA SGs which provide connectivity to an SSN
> in IP network.
> SUA RFC (section 5.1.2.3.) suggests sending an SSP from an SG when the
> AS serving the SSN goes inactive in the SG and I also assume in case
> the SG loses connectivity to the AS.
>
> 5.1.2.3. Unsuccessful ASP Fail-over scenario
>
> ASP-a1 ASP-a2 SG SEP
> (Primary) (Backup)
> +-------------ASP Inactive------------->
> <-----------ASP Inactive ACK-----------+
> <--------------------NTFY (AS Pending)-+
> <--NTFY (AS Pending)-+
> After some time elapses (i.e., timeout).
> +--------SSP-------->
> <--------SST--------+
> <-------------------NTFY (AS Inactive)-+
> <-NTFY (AS Inactive)-+
>
>
>
> What shall be done in multiple SGs scenario when the SSN is allowed
> via another SG?
>
> Is this a realistic example?
>
> Thank you in advance
>
> --
> Ilie
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>



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





Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays,
whatever.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.