Re: SCON received a­t ASP from one of SGs

Mikhail,

Mikhail Plotkin wrote:                                             (Fri, 02 Sep 2011 14:10:41)
>    Sorry for the previous mail, there was something with the format.
>    > Hi All,
>    > Hope to get a piece of advise regarding interpretation of
>    > sections 1.3.2 and 4.5.2.2 of RFC4666.
>    >
>    > ASP has routes to SS7 destination point through several SGs.
>    >
>    > 1 . If ASP gets SCON from one of SGs should it immediately send
>    > congestion indication to the user or should we send report to the
>    > user if and only if SCON received from both SGs? RFC says that
>    > ASP "determines whether or not the overall availability or
>    > congestion status of the affected destination(s) has changed".
>    > Does it mean ASP should set for the destination the minimum
>    > congestion status among all SGs or the maximum congestion status
>    > among all SGs ?

In the multiple SG as STP configuration, the SCON received at an ASP is
roughly equivalent to a TFC.  TFC is used to signal congestion of a
routeset somewhere along the path to the destination.  The direction
from which it arrives is of no consequence.  So, yes, if the SCON is
received at the ASP, the M3UA layer should issue the corresponding
MTP-STATUS message indicating PC congestion and the congestion level to
the MTP-User for the AS.

There is no need to go messing with the congestion level, if the load
is so imbalanced, the higher level messages will still throttle the
MTP-User behaviour.

>    > 2. In the same configuration. If we get SCON from one SG should
>    > we try to redistribute the part of traffic from the congested
>    > route, that leads to congestion, to the other routes  through
>    > which this destination is accessible?

No, definitely not.  SS7 does not redistribute directly on the basis of
congestion.  In ANSI/2000 procedures there is a mechianism for issuing
a TFR (DRST) from an STP (SG) when there is a 'danger of congestion',
but these procedure provide proper hysteresis to avoid thrashing.  It
is sufficent that the ASP process received DRST correctly, and it should
never reroute on SCON.

The SCON could have been triggered by congestion (and TFC) quite remote
from the SGs in the SS7 network.  Which SG it came through is of no
consequence.  An SG which discovers local congestion (or danger of
congestion caused by changeovers to under-provisioned C-links) can
request the AS to reroute traffic using the TFR (DRST) procedures.

--brian

>    >
>    > If yes, what measures can be taken to diminish possible negative
>    > side effects of such redistribution? By the way, RFC recommends
>    > to handle it "much like an MTP3 layer maintains route-set
>    > status", but ITU-T Q.704 does not say anything about rerouting
>    > caused by congestion in one of the routes.
>    >
>    > (Similar questions have been discussed here before, but those
>    > were for several ASPs and a single SG)
>    >
>    Regards, Mikhail.

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