Subject: [Sigtran] SUA - multiple SGs

From: "Valerie Gastaud" <[email-masked]>
Date: Mon, 25 Nov 2002 17:56:26 +0100

I spent some time going through the mailing list archives to find an answer
to my questions but even if I found a lot of useful information, the
following is not very clear to me:

Very often, I saw the SG/STP case can be solved by defining alias PC to the
SG.
SG/STP is meant to allow traffic for a given AS to be routed through more
than one SG, hence providing redundancy in case of failure.
I see well how message routing in the SG is solved with alias PC but what is
less clear is how the failure cases should be handled:
let's say one SG sees one AS as inactive (due to the failure of all SCTP
associations), what should be the SG behavior in this case if I want the
re-routing of SS7 traffic through another SG (where the same AS is seen
active)?
Let's consider also there are no C-links between the SGs.
I don't believe SSP or UDTS can be the answer since these are SCCP end-node
messages that do not permit re-routing but I don't see any other SCCP
message that could be used.
MTP Route management message (TFP) could be used, but:
- how to trigger MTP Route management from NIF which sits on top of SCCP?
- the drawback is that if one AS (=SSN) is inactive, the whole PC becomes
inacessible from this SG (TFP does not obviously contain SSN granularity)

Or is the answer is to always have SS7 C-links?
Thanks,

Valerie

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 25 Nov 2002 10:30:18 -0700

Valerie,

See the procedures with regard to routing for Alias point codes under
failure in ANSI T1.111.4/2000.  When the "local" SCCP fails, messages
are routed to the STP mate if the mate is accessible (via whatever means,
C-links, hopping back through B/D-links to another STP, etc.)

It shouldn't take too much effort to extrapolate this from SCCP as an
MTP-User to SCCP subsystems.

--brian

Valerie Gastaud wrote:                             (Mon, 25 Nov 2002 17:56:26)

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

---

From: "Valerie Gastaud" <[email-masked]>
Date: Tue, 26 Nov 2002 12:25:08 +0100

Brian,

Thanks for pointing me out to the correct spec.
If I understand well what is said in the ANSI spec, this means that the
local SCCP status change for the alias PC triggers the MTP network
management functions.
This leads to the drawback I mentioned in my original email, i.e. since MTP
procedures do not obviously have the SSN granularity, the inaccessibility of
one RK=DPC+SSN implies the re-routing of all the traffic destined to this
DPC including the one of these RKs which were still active.
This also means that the SG has to inform the other ASPs (those whose RK
contains the DPC) which are still active to stop sending traffic through
this SG. I believe the only way to do that is to send a DUNA message that
will contain all destinations.

                       ___SG-A_                _______
                      |        |              |       |
                      |        |              | ASP1  |
                 _____|  SG    |XXXXXXXXXXXXX | DPC=3 |
                /     |  PC=1  |   \         /| SSN=8 |
               /      |________|    \       / |_______|
              /                      \     /
    _____    / SS7 link               \   /   _______
   /     \  /                          \ /   |       |
  /       \/                            /____|  ASP2 |
  |  STP  |                            / ____|  DPC=3|
  \       /\                          / /    |  SSN=9|
   \_____/  \                        / /     |_______|
             \                      / /
              \        ________    / /
               \      |        |__/ /   SCTP
                \_____|        |___/ Associations
                      | SG     |
                      | PC=2   |
                      |________|

                         SG-B

In the above example, if the association between SG-A and ASP1 fails, SG-A
will send a TFP with affected PC=3, causing the STP to re-route traffic for
DPC=3 to SG-B.
Additionally SG-A must inform ASP2 to stop sending traffic through it.
This is a simple configuration but if may become more complicated when the
SG has to manage a bunch of RKs for different SSNs.
Valerie
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: lundi 25 novembre 2002 18:30
To: Valerie Gastaud
Cc: Sigtran
Subject: Re: [Sigtran] SUA - multiple SGs

Valerie,

--brian

Valerie Gastaud wrote:                             (Mon, 25 Nov 2002
17:56:26)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Nov 2002 04:41:20 -0700

Valerie,

ANSI T1.111.4/2000 Alias point codes don't work well without
C-links either.

If you place C-links between SG-A and SG-B then you do not have
a problem.  SG-A can send DPC=3 SSN=8 traffic to SG-B over
C-links.

Another alternative is to mate your SCP/HLRs.  Having only one
ASP responsible for SSN=8 does not take advantage of any of the
benefits of active/standby, loadshare or broadcast modes.

If you design your system with a single point of failure, you
should not be suprised that it does not work well when things
fail.  If you refuse to put in C-links, and refuse to (at least)
duplicate your ASPs, the system will not be very robust.

I would say that C-links are typical.  So are duplicated ASPs.

Why are you interested in such atypical, non-redunant arrangements?

--brian

Valerie Gastaud wrote:                               (Tue, 26 Nov 2002 12:25:08)

---

From: "Valerie Gastaud" <[email-masked]>
Date: Tue, 26 Nov 2002 13:40:27 +0100

Brian,

The figure is just an example. Even if I define duplicate ASPs, it is still
possible that a router failure for example causes the inacessibility of both
of them.
If you compare to SS7, there are procedures that cover link and link-set
failure where one could have argued that if you have 2 links in your
link-set, it's enough to cover SPOF.

If I have C-links between SG-A and SG-B, SG-A could send DPC=3 SSN=8 traffic
to SG-B over C-links, provided some implementation specifics.
If ever the Route towards SG-B becomes unavailable also, then there is no
way to avoid the sending of TFP but the probability to have this happen is
greatly reduced.

Valerie

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: mardi 26 novembre 2002 12:41
To: Valerie Gastaud
Cc: Sigtran
Subject: Re: [Sigtran] SUA - multiple SGs

Valerie,

--brian

Valerie Gastaud wrote:                               (Tue, 26 Nov 2002
12:25:08)
> > I see well how message routing in the SG is solved with alias PC but
what
> is

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Nov 2002 07:26:39 -0700

Valerie,

Valerie Gastaud wrote:                                                             (Tue, 26 Nov 2002 13:40:27)
> possible that a router failure for example causes the inacessibility of both

Again, you presume a single point of failure.  I suggest you don't route both
of your ASPs through the same router.

> link-set, it's enough to cover SPOF.

You must also consider nodes, battery plant, earthquakes and other significant
geographically contained events.  This is why mated STPs (and mated SCPs for
that matter) are placed at a distance from each other.  Within a linkset,
there will even be space, frequency, and route diversity.

You should consider the same for ASPs.  Your paired ASPs should share no
critical component (no SPOF) in the path between each ASP and each SG.

> way to avoid the sending of TFP but the probability to have this happen is

If an STP loses an entire A-Link set and simultaneously an entire C-Link set,
it is not going to be a very useful STP.  Normally this would only happen if
the entire SS7 network is on its way into darkness.

I would not use TFP.  The appropriate action per Q.714/2.8.3 (3) is:

	Release cause: subsystem failure.
	Refusal cause: subsystem failure.
	Return cause: subsystem failure.

See also Q.714/2.4.5 Step 4, and particularly the procedures with regards
to multiple SCCP entities in the entity set in subsections c) and d) (which
also says that Release/Refusal/Return cause "subsystem failure" is
appropriate.

--brian

---

From: "Valerie Gastaud" <[email-masked]>
Date: Wed, 27 Nov 2002 10:01:40 +0100

Brian,

> way to avoid the sending of TFP but the probability to have this happen is

If an STP loses an entire A-Link set and simultaneously an entire C-Link
set,
it is not going to be a very useful STP.  Normally this would only happen if
the entire SS7 network is on its way into darkness.
>>>>VG: IMO, this is precisely what made the success of SS7, not only SPOF
were covered. But this is another debate.

>>>>VG: to me, this is a different procedure.
In the example, TFP will inform the STP to re-route traffic destined to
DPC#3 through SG-b.
SG-a, as a Relay node, can still receive messages with DPC#1 and Route on GT
where the GTT results in DPC#3. DPC#3 SSN=8 being not accessible from SG-a,
the procedures you pointed out apply, so both procedures at MTP and SCCP
levels are needed.

Valerie

> > procedures do not obviously have the SSN granularity, the
inaccessibility
> of
> > > Very often, I saw the SG/STP case can be solved by defining alias PC
to
> > the

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 27 Nov 2002 02:21:56 -0700

Valerie,

ANSI SS7 STPs do not send TFP for local point codes.  They do
for alias point codes, but alias point codes are only for
addressing the STP's local GTT function.  In your example, you
are using DPC=3 as a SEP point code and not an alias point
code.  If, for example, you used DPC=4 as the STP alias point
code for GTT function and performed GTT at the STP to DPC=3
SSN=8 the situation would match the ANSI specifications.  In
this case the STP is acting as relay.  Then sending TFP per
ANSI T1.111.4/2000 procedures for DPC=4 would result in
selection of SG-B for GTT and SG-B could loadshare to DPC=3
over available routes.  But this is not normally necessary, as
the SCCP/GTT function should always be available (six or seven
9's) at the STP/SG-B.  Failure of SG-B to be able to route
DPC=3 SSN=8 to an ASP should merely result in alternate
routing for this subsystem (i.e., over C-links), otherwise,
the procedures of Q.714/2.8.3 apply.

I stress, the alias point code procedures of ANSI
T1.111.4/2000 are not intended to be used for local MTP-User
functions other than the availability of the SCCP/GTT function
at the STP.

--brian

Valerie Gastaud wrote:                                 (Wed, 27 Nov 2002 10:01:40)

---

From: "Valerie Gastaud" <[email-masked]>
Date: Wed, 27 Nov 2002 11:54:24 +0100

Brian,

I got why you said but how can the SG stay in the path of SS7 messages
routed on DPC=3, which will likely be the case of subsequent messages of a
TCAP transaction (generally only the first message of the transaction
contains a GT).
I have the feeling that my configuration can only be achieved with SGs
having STP functions, alias PC does not seem sufficient.
Valerie
-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: mercredi 27 novembre 2002 10:22
To: Valerie Gastaud
Cc: Sigtran
Subject: Re: [Sigtran] SUA - multiple SGs

Valerie,

--brian

Valerie Gastaud wrote:                                 (Wed, 27 Nov 2002
10:01:40)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 27 Nov 2002 05:29:17 -0700

Valerie,

Valerie Gastaud wrote:          (Wed, 27 Nov 2002 11:54:24)
> TCAP transaction (generally only the first message of the transaction

Subsequent messages (e.g, conversations) are routed on DPC only.

> having STP functions, alias PC does not seem sufficient.

I think you need to understand how SS7 handles this situation
before attempting to get your SUA NIF to handle it.  SCCP
subsystems are either available or unavailable (allowed or
prohibited) at a signalling point. SCCP subsystems on a single
point code cannot be made accessible to some routes and
inaccessible to other routes.  If you want to make a subsystem
accessible or inaccessible on a route basis, you need multiple
point codes (i.e., replicated subsystems).  In that case, the
ASP would have DPC=5 SSN=8 via SG-A and DPC=6 SSN=8 via SG-B and
the SEP sending transactions would also be aware of these
replicated subsystems.  Then when SG-A loses connection to DPC=5
SSN=8 it sends SSP with affected PC=5 and SSN=8 and SMI
indicating mated subsystems, and sends UDTS with cause
"Subsystem failure".  The SEP can fail the transaction, or
reattempt transactions with still available DPC=6 SSN=8.  Also,
if SG-A has C-links it can route via SG-B.  This looks like the
following to the SS7 network:

                                        __________________ 
                     PC=1 GTT-PC=4     |          PC=5    |
                         SG-A          |  ASP     _____   |
                         _____ RC=1    |         /     \  |
                        |\    |________|________|\_____/| |
                    ____| STP |________|_       |       | |
                   /    |____\|        | \     /|  SCP  | |
          _____   /        |   RC=2    |  \   /  \_____/  |
         /     \ /         |           |   \ /            |
        |  SSP  |          |           |    X     PC=6    |
         \_____/ \         |           |   / \    _____   |
                  \      __|__ RC=1    |  /   \  /     \  |
                   \____|\    |________|_/     \|\_____/| |
  RK1 = DPC=5/SSN=8     | STP |________|________|       | |
  RK2 = DPC=6/SSN=8     |____\|        |        |  SCP  | |
                               RC=2    |         \____ /  |
                         SG-B          |__________________|
                     PC=2 GTT-PC=4                         

With the above diagram , it the association between SG-A and the
ASP should fail, then SG-A/STP can route messages for RK1 and
RK2 to SG-B (if SG-A has not received a SSP for SSN=8, APC=5 or
6 from SG-B, and has not received TFP for APC=5 or 6).  The SSP
need  not be aware of the duplicated subsystems, because it
addresses GTT to DPC=4 (the purpose of alias point codes is so
that the SEP can address a single point code and not worry about
replicated subsystems for GTT.)  Or, the SSP can be made aware
that duplicated subsystems are involved (in which case it will
be a concerned point code and will also receive SSP.)

So, I suppose the point is: if you want to treat ASPs as
independently accessible on subsystem granularity, each access
(route to the ASP) will need its own point code and the ASP must
be viewed by the SS7 network as a replicated subsystem.  This
makes each acess an independent SCCP entity in the SCCP entity
set and SCCP management procedures will work correctly.

Otherwise, you must view the ASP as a non-replicated subsystems:
in which case, if the subsystem becomes inaccessible to one STP,
the entire subsystem must be treated as unavailable if other
subsystems on the ASP remain available.  If the point code has
only a single subsystem (as is often the case with SCPs and
HLRs), then (and only then) is it possible to treat the entire
point code as inaccessible.

In the case where the ASP is serving a large number of
subsystems assigned to a single point code (e.g, to avoid PC
exhaustion), then indicating SSP and "subsystem failure" is more
appropriate than TFP.  Sending TFP would have the unnacceptable
effect of 1) disrupting all transactions/connections for
subsystems other than the affected subsystem the affected SG
(half of the entire transaction/connection load), 2)
transferring the transaction/connection load and
requery/reattempt load for all susbsytems (more than half of the
entire transaction/connection load) to the other STP/SG.

So, only in the special case where all routing keys containing
the affected PC have failed does TFP make any sense (because
only if there is no remaining active AS/RC/RK with the affected
DPC can loss of the association be interpreted as
inaccessibility of the point code).  Whenever an active AS/RC/RK
with the affected DPC is available (per your original example)
SSP and "subsystem failure" is appropriate and TFP is not
because of the disruptive effect that TFP will have on the
network for the remaining subsystems.

--brian

---

From: "Valerie Gastaud" <[email-masked]>
Date: Thu, 28 Nov 2002 15:54:37 +0100

Brian,

comments inline.
Valerie
-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: mercredi 27 novembre 2002 13:29
To: Valerie Gastaud
Cc: Sigtran
Subject: Re: [Sigtran] SUA - multiple SGs

Valerie,

>>>>VG: so, I believe DPC5/6 are viewed as PC located behind the SGs, i.e.
the SSP has SS7 routes to DPC 5/6 going through the SGs and the SGs are able
to receive messages with DPC5/6 and to pass them on to NIF.  This is what I
meant by having STP functions.

inaccessible to other routes.
>>>>VG: I agree if the subsystem itself is unavailable, i.e. the
application, there is no added value to re-route the traffic.
What I wanted to address is a "route" failure between the end-node where the
application is running and one adjacent Point code (that can be an STP or a
SG).

If you want to make a subsystem

                                        __________________
                     PC=1 GTT-PC=4     |          PC=5    |
                         SG-A          |  ASP     _____   |
                         _____ RC=1    |         /     \  |

>>>>VG: Basically this means that:
- if the subsystem itself is unavailable, then SSP must be sent.
- if the "route" is down, the traffic must be rerouted to another SG over
C-links. If this is not possible, then either SSP or TFP can be sent.
SSP has the advantage to have SSN granularity (therefore impacting only the
subsystem) but has the drawback that the service may be completely
interrupted if there is no replicated susbsystem. The transactions in
progress will also be disrupted since they are routed on DPC.
TFP has the advantage that traffic will be re-routed at MTP level but the
drawback that all traffic associated to the affected DPC will be re-routed.

--brian

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