Subject: RE: [Sigtran] SUA: application redundancy in the IP network

From: "Schantz, John" <[email-masked]>
Date: Thu, 2 May 2002 13:26:09 -0500

Whoa Nellie ---- an SG is not justified in sending an SSP (at least not an originating one, the passed on one could be removed from the standard as far as I am concerned).  The SSP is originated by the SCCP that is serving a subsystem is unavailable, hence, the "serving" SUA would have the same responsibility.  SSPs are sent to concerned point codes (an adjacent STP or SG would be in the list) when the SCCP/SUA determines that a subsystem has become unavailable.  SSPs will also be sent to any other point code that sends messages to the unavailable subsystem - but these are also generated by the "serving" SCCP/SUA.

When the SG (& STP) receives the SSP, its SUA (SCCP) must determine if it means anything to it.  If it is a reply point (that is, does GTT), then it would mean something and the GTT translate would adjust its translations to use mate/alternative subsystem to route the traffic to.  Hence, it doesn't matter if the SGs or STPs are mated or not, they will be making their own decisions.

John

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 12:03 PM
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Sigtran] SUA: application redundancy in the IP network

Tolga,

There can only be two cases here:  either the SG's have the SCCP
relay function or they do not.  If the SG's have the SCCP relay
function, they are acting as STP and should coordinate with each
other before declaring routes or subsystems unavailble.  If they
are not acting as STPs, then they are acting as a single SEP/STP
and must coordinate between them.

Don't you see?  One SG has no business sending SSP if it can
access the subsystem via it's mate.  If it cannot access the
subsystem via its mate, then it is isolated and is correct to
send SSP.  If the SGs are not acting as STPs, then they
represent disjoint routes to different partitions of the SS7
network and can correctly send SSP.

So, where the SG's have separate point code, what you have
either looks like this:

Case A)

          _____             _______ 
         /     \           |       |
        |  SEP  |__________|  SG1  |____
        |       |          |       |    \
         \_____/           |_______|     \      _______
                                          \____|       |
                                               |  ASP  |
                                           ____|       |
          _____             _______       /    |_______|
         /     \           |       |     /
        |  SEP  |__________|  SG2  |___ /
        |       |          |       |
         \_____/           |_______|

Or like this:

Case B)
          _____             _______ 
         /     \           |       |
        |  SEP  |__________|  SG1  |____
        |       |  \      /|  STP  |    \
         \_____/    \    / |_______|     \      _______
                     \  /      |          \____|       |
                      \/       |               |  ASP  |
                      /\       |           ____|       |
          _____      /  \   ___|___       /    |_______|
         /     \    /    \ |       |     /
        |  SEP  |__/______\|  SG2  |___ /
        |       |          |  STP  |
         \_____/           |_______|

In Case A), it is perfectly correct for SG2 to send SSP to the
SEP when it cannot communicate to the ASP.

In Case B), why would SG2 send SSP  to any SEP just because it
cannot communicate directly with the ASP?  It still has
connectivity via SG1 (its mate).

--brian

Tolga Asveren wrote:                                        (Thu, 02 May 2002 12:11:37)
> Brian,
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Brian F. G. Bidulock
> > Sent: Thursday, May 02, 2002 10:18 AM
> > To: Zannin, Francois
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] SUA: application redundancy in the IP network
> > 
> > 
> > Zannin,,
> > 
> > Zannin, Francois wrote:                                   (Thu, 
> > 02 May 2002 15:57:29)
> > > Hi,
> > > 
> > > Some remarks about the reliability of SUA services in a ss7 network!
> > > 
> > > When an AS is connected to several SG that belong to the same ss7 
> > > network, and this AS, declared with the same PC on all SG, becomes 
> > > inactive from one SG; this SG sends a SSP to the concerned SEP 
> > > indicating that the AS (PC/SSN) is prohibited.
> > 
> > Why would you do that?
> [TOLGA] What else should happen to make SG send SSP to the concerned SEP?
> > 
> > --brian
> > 
> > 
> > > Then when the SEP receive this SSP, it considers that the service 
> > > in not available while it is still available from another SG!
> > > A solution should be to send the SSM only if no PC is specified 
> > > for the AS. 
> > > 
> > > This is a behavior for SUA, if a service can be accessed via several 
> > > SG, the service MUST be seen with different PC and the traffic routing 
> > > MUST use a ss7 GT translation and THIS GT translation only on the 
> > > TCAP BEGIN messages to have the benefit of the redundancy. Unless the 
> > > ss7 SEP application chose itself the PC of the service to use! 
> > > 
> > > Isn't it restrictive in a ss7 point of view?
> > > 
> > > Francois Z.
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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

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