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