Re: Interpretation of RFC4666 regarding M3UA SCON message

Mikhail Plotkin <[email protected]> Thu, 3 Feb 2011 20:56:11 +0300
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]>
Hi, Zoltán.

Since ASP1 is an endpoint, I believe, neither of ASP2, SG1 and SG2 can
send traffic to SG1 or SG2 via ASP1 even in theory.
So ASP1 must not report SG1 and SG2 as "affected point code".

ASP can only report local congestion which would mean that the
M3UA layer at the ASP is overloaded or there is a congestion on the
interface between M3UA layer and its user.

Correct me if I'm wrong.

BR/ Mikhail

ZJ> Hi,

ZJ>  

ZJ>  

ZJ> We would like to ask you to interpret of RFC4666 regarding M3UA SCON message.

ZJ>  

ZJ> Recently an M3UA congestion occurred in a telekom network under our support.

ZJ>  

ZJ> The signalling config:

ZJ>  

ZJ> SG1 and SG2 are M3UA relay between ASP1 and ASP2. There is a
ZJ> direct association between ASP1 and ASP2 also (no traffic on that).

ZJ>  

ZJ>  

ZJ>  

ZJ>                          ASP2

ZJ>            /  |  \

ZJ>           /   |   \ 

ZJ>          /    |    \

ZJ>         SG1   |    SG2

ZJ>          \    |    /

ZJ>           \   |   /

ZJ>            \  |  / 

ZJ>              ASP1

ZJ>  

ZJ> IP backbone packet drop occurred between ASP1 and SG1/SG2. 

ZJ>  

ZJ> This led to ASP1 to send M3UA SCONs to all of its M3UA peers (SG1, SG2, ASP2).

ZJ>  

ZJ> These SCONs contained SG1 and SG2 as "affected point code". 

ZJ>  

ZJ> When ASP2 received SCONs it started congestion timer and
ZJ> stopped signalling towards SG1 and SG2. This caused disturbance in
ZJ> the network.

ZJ>  

ZJ> When timer expired in SG2 the traffic resumed until the next SCON from ASP1.

ZJ>  

ZJ> The vendor of ASP1 says that they sent the SCON according to RFC4666 34.4:

ZJ>  

ZJ> RFC4666  3.4.4.  Signalling Congestion (SCON)

ZJ>  

ZJ>    The SCON message can be sent from an SGP to all concerned ASPs to

ZJ>    indicate that an SG has determined that there is congestion in the

ZJ>    SS7 network to one or more destinations, or to an ASP in response to

ZJ>    a DATA or DAUD message, as appropriate.  For some MTP protocol

ZJ>    variants (e.g., ANSI MTP) the SCON message may be sent when the SS7

ZJ>    congestion level changes.  The SCON message MAY also be sent from the

ZJ>    M3UA layer of an ASP to an M3UA peer, indicating that the congestion

ZJ>    level of the M3UA layer or the ASP has changed.

ZJ>  

ZJ>  

ZJ>  

ZJ>  

ZJ>  

ZJ> In our opinion SGSN (ASP) should not send SCON in this
ZJ> situation indicating an other node's point code as "affected point
ZJ> code". 

ZJ>  

ZJ>  

ZJ> RFC4666 1.4.6 Congestion Management 

ZJ>  

ZJ> The M3UA layer at an ASP or IPSP MAY indicate local
ZJ> congestion to an M3UA peer with an SCON message. 

ZJ>  

ZJ> Could you explain what exactly "local congestion" means?

ZJ>  

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

ZJ>  

ZJ>  

ZJ>  

ZJ>  

ZJ> Thank you for your help

ZJ>  

ZJ> Zoltan Juhasz

ZJ> Tibor Szakos

ZJ>  

ZJ>  

ZJ>  



ZJ> __________ Information from ESET NOD32 Antivirus, version of
ZJ> virus signature database 5821 (20110126) __________

ZJ> The message was checked by ESET NOD32 Antivirus.

ZJ> http://www.esetnod32.ru/.ml