Re: Interpretation of RFC4666 regarding M3UA SCON message

Zoltán,

Please see comments below...

Zoltán Juhász wrote:                         (Tue, 25 Jan 2011 11:10:37)
> 
>    The signalling config:
> 
>    SG1 and SG2 are M3UA relay between ASP1 and ASP2. There is a direct
>    association between ASP1 and ASP2 also (no traffic on that).
> 
>                 ASP2
>               /  |  \
>              /   |   \
>             /    |    \
>            SG1   |    SG2
>             \    |    /
>              \   |   /
>               \  |  /
>                 ASP1
> 
>    IP backbone packet drop occurred between ASP1 and SG1/SG2.

I am assuming that ASP1 and ASP2 have point codes distinct from point
codes of SG1 and SG1.  If this is not the case, none of the following
applies.

> 
>    This led to ASP1 to send M3UA SCONs to all of its M3UA peers (SG1,
>    SG2, ASP2).
> 
>    These SCONs contained SG1 and SG2 as "affected point code".

This is not reasonable.  An ASP should not ever send SCON and if it
chooses to, it must be for its own point code(s), and even then only in
response to a received message that triggers local congestion, or
"danger" of local congestion.  SCON, like TFC, is reactive (in response
to a received message) and never premptive (sent simply based on local
conditions).

SCON sent to SG1 or SG2 should only be because a message received from
(not via) SG1 or SG2 triggered local congestion.  I don't think that
packet loss between ASP1 and SG1/SG2 could trigger local congestion in
ASP1.  In fact, the packet loss should alleviate any congestion that
previously existed.

The only reasonable scenario that I can see is that if packet loss
occured between ASP1 and SG1/SG2, that ASP2 might redirect traffic
directly to ASP1.  In this case, local congestion could occur at ASP1.
But even then, the SCON should be send directly to ASP2 and have ASP1 as
the affected point code.

>    When ASP2 received SCONs it started congestion timer and stopped
>    signalling towards SG1 and SG2. This caused disturbance in the
>    network.
> 
>    When timer expired in SG2 the traffic resumed until the next SCON
>    from ASP1.

It should not have.  ASP2 is not behaving properly either.  When ASP2
receives a SCON with SG1/SG2 as the affected point codes, it should
limit traffic to (not via) SG1/SG2.  Traffic to ASP1 via SG1/SG2 should
not be affected.  Only traffic between ASP2 and any MTP-user at SG1/SG2
should be affected.

Nevertheless, ASP2 should never react to a SCON received from ASP1 with
some other affected point code.  ASP1 is not an SG.

>    The vendor of ASP1 says that they sent the SCON according to
>    RFC4666 3.4.4:
> 
>    RFC4666  3.4.4.  Signalling Congestion (SCON)
> 
>       The SCON message can be sent from an SGP to all concerned ASPs to
>       indicate that an SG has determined that there is congestion in the
>       SS7 network to one or more destinations, or to an ASP in response to
>       a DATA or DAUD message, as appropriate.  For some MTP protocol
>       variants (e.g., ANSI MTP) the SCON message may be sent when the SS7
>       congestion level changes.  The SCON message MAY also be sent from the
>       M3UA layer of an ASP to an M3UA peer, indicating that the congestion
>       level of the M3UA layer or the ASP has changed.
> 
>    In our opinion SGSN (ASP) should not send SCON in this situation
>    indicating an other node's point code as "affected point code".

I don't believe that it should send SCON at all in the situation you
described, far less using an invalid affected point code.

>    RFC4666 1.4.6 Congestion Management
> 
>    The M3UA layer at an ASP or IPSP MAY indicate local congestion to
>    an M3UA peer with an SCON message.
> 
>    Could you explain what exactly "local congestion" means?

"Local congestion" is the same as defined in the SS7 standards.  An SS7
SP is permitted to send TFC when the local message distribution (SMD)
function becomes overloaded or is in danger of overload.  Note, however,
that the functional block involved is the receive side only.  This does
not explain why an ASP would send SCON when transmit-side congestion is
discovered.  I was rather against ASPs sending SCON at all.

>    What is your opinion, is it allowed for an ASP to initiate an SCON
>    indicating other's point code as "affected point code"?

When RFC 4666 says that a node MAY do something, it is not giving an
implementation permission to violate SS7 network principles: it simply
leaves the door open for the implementation to meet the requirements
as they are addressed by the SS7 standards.

--brian

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