Re: Interpretation of RFC4666 regarding M3UA SCON message

Hi Brian,

Thank you for the interpretation. Let me reflect some points:


> "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."
Yes, all the network elements (ASP1,ASP2,SG1,SG2) have different point codes.

>  "...ASP2 might redirect traffic directly to ASP1.  In this case, local congestion could occur at ASP1."
This was not the case. The direct association between ASP1 and ASP2 was not used (was not defined in M3UA routing).


>    When ASP2 received SCONs it started congestion timer and stopped signalling towards SG1 and SG2.
"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."
The traffic from ASP2 to ASP1 via SG1/SG2 was NOT affected. The disturbance caused by SG1/SG2's M3UA user unavailability.

>"Nevertheless, ASP2 should never react to a SCON received from ASP1 with some other affected point code.  ASP1 is not an SG."
I think ASP2 assumes that the originator of SCON is an SG, since the affected point code is not ASP1's point code. 
Should ASP2 be prepared for a wrongly sent SCON?


Regards
Zoltan



-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Friday, February 04, 2011 12:10 AM
To: Zoltán Juhász
Cc: [email protected]; Tibor Szakos
Subject: Re: [Sigtran] 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/