From uplesske@hotmail.com Tue Oct 23 07:58:32 2012 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960D111E8099 for ; Tue, 23 Oct 2012 07:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVSoPL4+ULID for ; Tue, 23 Oct 2012 07:58:28 -0700 (PDT) Received: from col0-omc2-s1.col0.hotmail.com (col0-omc2-s1.col0.hotmail.com [65.55.34.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0094111E808D for ; Tue, 23 Oct 2012 07:58:27 -0700 (PDT) Received: from COL121-W2 ([65.55.34.71]) by col0-omc2-s1.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Oct 2012 07:58:27 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_881dd182-a2d1-4e89-9013-afd3bad8c8c3_" X-Originating-IP: [62.159.77.164] From: urte plesske To: Date: Tue, 23 Oct 2012 16:58:27 +0200 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 23 Oct 2012 14:58:27.0596 (UTC) FILETIME=[DBAFDCC0:01CDB12E] Subject: [Sigtran] M3UA: SCON: congestion condition never abates X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 14:58:32 -0000 --_881dd182-a2d1-4e89-9013-afd3bad8c8c3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=2C I'm faced with a problem based on the following architecture: AS connected to two SGs AS / \ / \ SG1---SG2 SCCP: SGs are making GTTs to route to the ss7 network. MTP configurations on AS: There are two routesets defined on AS=2C one to SG1 (containing direct rout= e and route over SG2) and to SG2 (containing direct route and route over SG= 1) =20 SCON message was received by AS from SG2 with affected PC SG1. On AS the route set (PC SG1) was inhibited. No traffic was sent to SG1 by A= S any more.=20 =20 Usually the AS would start sending periodic DAUDs messages as a result of t= he congestion=2C but because SG1 was got to know as adjacent node=2C no DAU= Ds with affected Point Code =3D Point Code SG1 were sent by any ASP. No SCON messages were sent by SG2 to AS because no DATA and DAUD messages w= ere received to react. The congestion condition never abates. =20 Could you please help me with the following questions: How to solve this situation (timer on AS?)?=20 Is it correct not to audit adjacent nodes? Can (should) SG2 send a SCON message even there are no DATA and DAUD messag= es to react? =20 Where can I find (rfc) the information=2C that SCON is like TFC and not TFR= ? =20 Thanks a lot! =20 regards=2C urte = --_881dd182-a2d1-4e89-9013-afd3bad8c8c3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=2C I'm faced with a problem based on the f= ollowing architecture:

AS connected to two SGs
 =3B =3B AS
 =3B =3B/ =3B=  =3B\
 =3B/ =3B =3B =3B =3B\
SG1---SG2
=
SCCP: SGs are making GTTs to route to the ss7 ne= twork.
MTP configurations on AS:
There are two route= sets defined on AS=2C one to SG1 (containing direct route and route over SG= 2) and to SG2 (containing direct route and route over SG1)

 =3B
SCON message was received by AS from SG2 with af= fected PC SG1.
On AS the route set (PC SG1) was inhibited. No traffic wa= s sent to SG1 by AS any more.

 =3B
Usually the AS would start sending periodic DAUD= s =3Bmessages as a result of the congestion=2C but because SG1 was got = to know as adjacent node=2C no DAUDs with affected Point Code =3D Point Cod= e SG1 were sent by any ASP.
No SCON messages were sent by SG2 to AS beca= use no DATA and DAUD messages were received to react.

The congestion condition never abates.  =3B
Could you please help me with the following ques= tions:
How to solve this situation (timer on AS?)?
Is it correct not= to audit adjacent nodes?
Can (should) SG2 send a SCON =3Bmessage&nb= sp=3Beven there are no DATA and DAUD messages to react? =3B

Where can I find (rfc) the information=2C that S= CON is like TFC and not TFR?
 =3B
Thanks a lot!
 =3B
regards=2C urte

= = --_881dd182-a2d1-4e89-9013-afd3bad8c8c3_-- From snemana@sonusnet.com Tue Oct 23 08:13:34 2012 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3D021F8644 for ; Tue, 23 Oct 2012 08:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9i2ZUvgZByj for ; Tue, 23 Oct 2012 08:13:32 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id 233FD21F863F for ; Tue, 23 Oct 2012 08:13:32 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKUIa0FgNTRMjpWsdJ1DdAiO8ffgGFpCaK@postini.com; Tue, 23 Oct 2012 08:13:32 PDT Received: from USMA-EX-MB2.sonusnet.com ([fe80::c51d:eb9c:bce7:e4b0]) by USMA-EX-HUB2.sonusnet.com ([2002:42cb:5a11::42cb:5a11]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 11:13:25 -0400 From: "Nemana, Satya" To: urte plesske , "sigtran@ietf.org" Thread-Topic: [Sigtran] M3UA: SCON: congestion condition never abates Thread-Index: AQHNsS7h5HDD4IUXL067ip10iHIUvpfG/c4g Date: Tue, 23 Oct 2012 15:13:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.99.165] Content-Type: multipart/alternative; boundary="_000_A4C75474DC72BC44A5517224ED0604C50BD70FUSMAEXMB2sonusnet_" MIME-Version: 1.0 Subject: Re: [Sigtran] M3UA: SCON: congestion condition never abates X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:13:34 -0000 --_000_A4C75474DC72BC44A5517224ED0604C50BD70FUSMAEXMB2sonusnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Urte Even if AS does not send DAUD(for SG1 PC) to SG2, SG2 should send an SCON(L= evel-0) when the congestion clears. In your case, you don't explain if the AS clears(for SG1) when SG2 sends SC= ON(Level-0) for SG1 PC. The DAUD from AS is not as important as the SCON(Level-0) that should be se= nt by SG2 for clearing congestion towards SG1. The congestion in your case is not abating because SG2 is never clearing co= ngestion for PC:SG1. This sounds normal scenario as per protocol. Regards, Satya From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf = Of urte plesske Sent: 23 October 2012 15:58 To: sigtran@ietf.org Subject: [Sigtran] M3UA: SCON: congestion condition never abates Hello, I'm faced with a problem based on the following architecture: AS connected to two SGs AS / \ / \ SG1---SG2 SCCP: SGs are making GTTs to route to the ss7 network. MTP configurations on AS: There are two routesets defined on AS, one to SG1 (containing direct route = and route over SG2) and to SG2 (containing direct route and route over SG1) SCON message was received by AS from SG2 with affected PC SG1. On AS the route set (PC SG1) was inhibited. No traffic was sent to SG1 by A= S any more. Usually the AS would start sending periodic DAUDs messages as a result of t= he congestion, but because SG1 was got to know as adjacent node, no DAUDs w= ith affected Point Code =3D Point Code SG1 were sent by any ASP. No SCON messages were sent by SG2 to AS because no DATA and DAUD messages w= ere received to react. The congestion condition never abates. Could you please help me with the following questions: How to solve this situation (timer on AS?)? Is it correct not to audit adjacent nodes? Can (should) SG2 send a SCON message even there are no DATA and DAUD messag= es to react? Where can I find (rfc) the information, that SCON is like TFC and not TFR? Thanks a lot! regards, urte --_000_A4C75474DC72BC44A5517224ED0604C50BD70FUSMAEXMB2sonusnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Urte=

 <= /p>

Even if AS does not send = DAUD(for SG1 PC) to SG2, SG2 should send an SCON(Level-0) when the congesti= on clears.

In your case, you donR= 17;t explain if the AS clears(for SG1) when SG2 sends SCON(Level-0) for SG1= PC.

The DAUD from AS is not a= s important as the SCON(Level-0) that should be sent by SG2 for clearing co= ngestion towards SG1.

The congestion in your ca= se is not abating because SG2 is never clearing congestion for PC:SG1.=

This sounds normal scenar= io as per protocol.

 <= /p>

Regards,

Satya

 <= /p>

 <= /p>

 <= /p>

From: sigtran-= bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of urte plesske
Sent: 23 October 2012 15:58
To: sigtran@ietf.org
Subject: [Sigtran] M3UA: SCON: congestion condition never abates

 

Hello, I'm faced with a pro= blem based on the following architecture:

AS connected to two SGs
   AS
  /  \
 /    \
SG1---SG2

SCCP: SGs are making GTTs to route to the ss7 network.
MTP configurations on AS:
There are two routesets defined on AS, one to SG1 (containing direct route = and route over SG2) and to SG2 (containing direct route and route over SG1)=

 
SCON message was received by AS from SG2 with affected PC SG1.
On AS the route set (PC SG1) was inhibited. No traffic was sent to SG1 by A= S any more.

 
Usually the AS would start sending periodic DAUDs messages as a resul= t of the congestion, but because SG1 was got to know as adjacent node, no D= AUDs with affected Point Code =3D Point Code SG1 were sent by any ASP.
No SCON messages were sent by SG2 to AS because no DATA and DAUD messages w= ere received to react.

The congestion condition never abates.
 
Could you please help me with the following questions:
How to solve this situation (timer on AS?)?
Is it correct not to audit adjacent nodes?
Can (should) SG2 send a SCON message even there are no DATA and D= AUD messages to react? 

Where can I find (rfc) the information, that SCON is like TFC and not TFR?=
 
Thanks a lot!
 
regards, urte

--_000_A4C75474DC72BC44A5517224ED0604C50BD70FUSMAEXMB2sonusnet_-- From David.Laight@ACULAB.COM Tue Oct 23 08:25:18 2012 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1AA1F0C86 for ; Tue, 23 Oct 2012 08:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_BAD_LINEBREAK=0.5, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbQj712Gu0eS for ; Tue, 23 Oct 2012 08:25:18 -0700 (PDT) Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by ietfa.amsl.com (Postfix) with SMTP id 3C3E51F0C51 for ; Tue, 23 Oct 2012 08:25:17 -0700 (PDT) Received: (qmail 860 invoked from network); 23 Oct 2012 15:25:06 -0000 Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 23 Oct 2012 15:25:06 -0000 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 28737-09 for ; Tue, 23 Oct 2012 16:25:04 +0100 (BST) Received: (qmail 812 invoked by uid 599); 23 Oct 2012 15:25:04 -0000 Received: from unknown (HELO saturn3.Aculab.com) (10.202.163.5) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Tue, 23 Oct 2012 16:25:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDB132.18BFDFE2" Date: Tue, 23 Oct 2012 16:21:38 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Sigtran] M3UA: SCON: congestion condition never abates thread-index: Ac2xLtr9wrBDEkIEQcOx2LRhbcHO6gAAeR+Q References: From: "David Laight" To: "urte plesske" , X-Virus-Scanned: by iCritical at mx0.aculab.com Subject: Re: [Sigtran] M3UA: SCON: congestion condition never abates X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:25:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDB132.18BFDFE2 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I presume this is (supposed to be) M3UA? M3UA is an abstraction of the interface between MTP3 and its userparts = (typically SCCP and ISUP). This means that the =91AS=92 box isn=92t running MTP3, so your = descriptions about routing are incorrect. =20 The M3UA SCON indication is telling the userpart that MTP3 received a = TFC for the route. This could be used by the userpart to reduce its traffic. There is no network message that indicates that congestion has ceased. IIRC M3UA also doesn=92t contain any such message. The =91congestion level=92 will be 1, 2 or 3 in ansi networks, and = always 0 in ITU networks. =20 David =20 From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On = Behalf Of urte plesske Sent: 23 October 2012 15:58 To: sigtran@ietf.org Subject: [Sigtran] M3UA: SCON: congestion condition never abates =20 Hello, I'm faced with a problem based on the following architecture: AS connected to two SGs AS / \ / \ SG1---SG2 SCCP: SGs are making GTTs to route to the ss7 network. MTP configurations on AS: There are two routesets defined on AS, one to SG1 (containing direct = route and route over SG2) and to SG2 (containing direct route and route = over SG1) =20 SCON message was received by AS from SG2 with affected PC SG1. On AS the route set (PC SG1) was inhibited. No traffic was sent to SG1 = by AS any more.=20 =20 Usually the AS would start sending periodic DAUDs messages as a result = of the congestion, but because SG1 was got to know as adjacent node, no = DAUDs with affected Point Code =3D Point Code SG1 were sent by any ASP. No SCON messages were sent by SG2 to AS because no DATA and DAUD = messages were received to react. The congestion condition never abates. =20 Could you please help me with the following questions: How to solve this situation (timer on AS?)?=20 Is it correct not to audit adjacent nodes? Can (should) SG2 send a SCON message even there are no DATA and DAUD = messages to react? =20 Where can I find (rfc) the information, that SCON is like TFC and not = TFR? =20 Thanks a lot! =20 regards, urte =0D=0A =0D= ------_=_NextPart_001_01CDB132.18BFDFE2 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I presume this is (supposed to be) M3UA?

M3UA is an abstraction of the interface between MTP3 and its = userparts (typically SCCP and ISUP).

This means that the =91AS=92 box isn=92t running MTP3, so your = descriptions about routing are incorrect.

 

The M3UA SCON indication is telling the userpart that MTP3 received a = TFC for the route.

This could be used by the userpart to reduce its = traffic.

There is no network message that indicates that congestion has = ceased.

IIRC M3UA also doesn=92t contain any such = message.

The =91congestion level=92 will be 1, 2 or 3 in ansi networks, and = always 0 in ITU networks.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = David

 

From:= = sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf = Of urte plesske
Sent: 23 October 2012 15:58
To: = sigtran@ietf.org
Subject: [Sigtran] M3UA: SCON: congestion = condition never abates

 

Hello, I'm faced = with a problem based on the following architecture:

AS = connected to two SGs
<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>   = AS
  /  \
 /    \
S= G1---SG2

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>SCCP: SGs are = making GTTs to route to the ss7 network.
<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>MTP = configurations on AS:
There are two routesets defined on AS, one to = SG1 (containing direct route and route over SG2) and to SG2 (containing = direct route and route over SG1)
 
SCON = message was received by AS from SG2 with affected PC SG1.
On AS the = route set (PC SG1) was inhibited. No traffic was sent to SG1 by AS any = more.

 
Usually the AS would start sending periodic DAUDs messages as = a result of the congestion, but because SG1 was got to know as adjacent = node, no DAUDs with affected Point Code =3D Point Code SG1 were sent by = any ASP.
No SCON messages were sent by SG2 to AS because no DATA and = DAUD messages were received to react.

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>The congestion = condition never abates.
 
Could you please help me with the following questions:
How to = solve this situation (timer on AS?)?
Is it correct not to audit = adjacent nodes?
Can (should) SG2 send a SCON message even = there are no DATA and DAUD messages to react? 

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>Where can I = find (rfc) the information, that SCON is like TFC and not = TFR?
 
Thanks a lot!
 
regards, urte<= /span>


= =0D=0A
Registered Address Lakeside, Br= amley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 13973= 86 (Wales)
=0D=0A
=0D=0A

P Please consider the environment and d= on't print this e-mail unless you really need to

<= /FONT>

= ------_=_NextPart_001_01CDB132.18BFDFE2-- From bidulock@openss7.org Tue Oct 23 14:23:20 2012 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9474721F85EA for ; Tue, 23 Oct 2012 14:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8g50rw33q7N for ; Tue, 23 Oct 2012 14:23:19 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) by ietfa.amsl.com (Postfix) with ESMTP id ACEA01F0424 for ; Tue, 23 Oct 2012 14:23:15 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9NLNCeu025159; Tue, 23 Oct 2012 15:23:12 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9NLNC63023903; Tue, 23 Oct 2012 15:23:12 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id q9NLNCrO023902; Tue, 23 Oct 2012 15:23:12 -0600 Date: Tue, 23 Oct 2012 15:23:12 -0600 From: "Brian F. G. Bidulock" To: urte plesske Message-ID: <20121023212312.GA21751@openss7.org> Mail-Followup-To: urte plesske , sigtran@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: SCON: congestion condition never abates X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 21:23:20 -0000 urte, Please see comments inline... urte plesske wrote: (Tue, 23 Oct 2012 16:58:27) > Hello, I'm faced with a problem based on the following architecture: > AS connected to two SGs > AS > / \ > / \ > SG1---SG2 > SCCP: SGs are making GTTs to route to the ss7 network. > MTP configurations on AS: > There are two routesets defined on AS, one to SG1 (containing direct > route and route over SG2) and to SG2 (containing direct route and route > over SG1) > > SCON message was received by AS from SG2 with affected PC SG1. > On AS the route set (PC SG1) was inhibited. No traffic was sent to SG1 > by AS any more. This, to begin with, is somewhat peculiar. The circumstances under which SG2 would send SCON to the AS concerning SG1's point code would be: - traffic on the association from AS to SG2 is overloading; - SG2's SMH function is overloading (in which case it should have first attempted a DRST in ANSI-based networks); - the C-links between SG2 and SG1 are congested. Which begs the question, why is the AS sending messages with DPC of SG1 to SG2? Is not the direct route between AS and SG1 available and unrestricted? Perhaps you have already received a DRST from SG1 concerning its own point-code? (which would not be correct). So, that's number 1 problem: Why are you sending M3UA-User messages from the AS to SG1 via the indirect route through SG2 when there exists a direct route to SG1? > Usually the AS would start sending periodic DAUDs messages as a result > of the congestion, but because SG1 was got to know as adjacent node, no > DAUDs with affected Point Code = Point Code SG1 were sent by any ASP. > No SCON messages were sent by SG2 to AS because no DATA and DAUD > messages were received to react. > The congestion condition never abates. No, that is incorrect. You should audit even though the destination is adjacent. Following on on my first issue, you should be auditing SG1 already because there is something the matter with the direct route for you to have been sending messages on the indirect route. The direct route must be restricted or unavailable, or the AS is doing the wrong thing. > > Could you please help me with the following questions: > How to solve this situation (timer on AS?)? Send periodic DAUD while point codes are marked congested. The period should be 1.4 to 2.0 seconds. > Is it correct not to audit adjacent nodes? No it is not. Adjacent nodes need not be audited for availability, but they do need to be audited for restriction and congestion. > Can (should) SG2 send a SCON message even there are no DATA and DAUD > messages to react? No, is does not have to. SG2 only need send SCON to the AS under the same conditions as an STP would send TFC to an adjacent signalling point. > Where can I find (rfc) the information, that SCON is like TFC and not > TFR? In the sections describing SCON and DRST. SCON is equivalent to TFC, DRST is equivalent to TFR. --brian From bidulock@openss7.org Tue Oct 23 14:28:36 2012 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DF911E80F3 for ; Tue, 23 Oct 2012 14:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.122 X-Spam-Level: X-Spam-Status: No, score=-5.122 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22KlXw94vXEf for ; Tue, 23 Oct 2012 14:28:35 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1F00711E80F2 for ; Tue, 23 Oct 2012 14:28:34 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9NLSWvQ025176; Tue, 23 Oct 2012 15:28:32 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9NLSWtd024138; Tue, 23 Oct 2012 15:28:32 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id q9NLSVhO024137; Tue, 23 Oct 2012 15:28:31 -0600 Date: Tue, 23 Oct 2012 15:28:31 -0600 From: "Brian F. G. Bidulock" To: "Nemana, Satya" Message-ID: <20121023212831.GB21751@openss7.org> Mail-Followup-To: "Nemana, Satya" , urte plesske , "sigtran@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] M3UA: SCON: congestion condition never abates X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 21:28:36 -0000 Satya, No, in the multiple STP as SG configuration there is no basis under which the SG can send SCON(0) unless the SG sends signalling route set congestion test messages on behalf of all its subtending nodes. Therefore, the AS in this configuration should periodically audit. --brian Nemana, Satya wrote: (Tue, 23 Oct 2012 15:13:24) > Hi Urte > > > Even if AS does not send DAUD(for SG1 PC) to SG2, SG2 should send an > SCON(Level-0) when the congestion clears. > > In your case, you don't explain if the AS clears(for SG1) when SG2 > sends SCON(Level-0) for SG1 PC. > > The DAUD from AS is not as important as the SCON(Level-0) that should > be sent by SG2 for clearing congestion towards SG1. > > The congestion in your case is not abating because SG2 is never > clearing congestion for PC:SG1. > > This sounds normal scenario as per protocol. > > > Regards, > > Satya > > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of urte plesske > Sent: 23 October 2012 15:58 > To: sigtran@ietf.org > Subject: [Sigtran] M3UA: SCON: congestion condition never abates > > > Hello, I'm faced with a problem based on the following architecture: > AS connected to two SGs > AS > / \ > / \ > SG1---SG2 > SCCP: SGs are making GTTs to route to the ss7 network. > MTP configurations on AS: > There are two routesets defined on AS, one to SG1 (containing direct > route and route over SG2) and to SG2 (containing direct route and route > over SG1) > > SCON message was received by AS from SG2 with affected PC SG1. > On AS the route set (PC SG1) was inhibited. No traffic was sent to SG1 > by AS any more. > > Usually the AS would start sending periodic DAUDs messages as a result > of the congestion, but because SG1 was got to know as adjacent node, no > DAUDs with affected Point Code = Point Code SG1 were sent by any ASP. > No SCON messages were sent by SG2 to AS because no DATA and DAUD > messages were received to react. > The congestion condition never abates. > > Could you please help me with the following questions: > How to solve this situation (timer on AS?)? > Is it correct not to audit adjacent nodes? > Can (should) SG2 send a SCON message even there are no DATA and DAUD > messages to react? > Where can I find (rfc) the information, that SCON is like TFC and not > TFR? > > Thanks a lot! > > regards, urte > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Tue Oct 23 14:31:30 2012 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3854C1F0C91 for ; Tue, 23 Oct 2012 14:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.422 X-Spam-Level: X-Spam-Status: No, score=-5.422 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpE4VKp4enzC for ; Tue, 23 Oct 2012 14:31:28 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) by ietfa.amsl.com (Postfix) with ESMTP id 167AA1F0C95 for ; Tue, 23 Oct 2012 14:31:22 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9NLVJVq025188; Tue, 23 Oct 2012 15:31:19 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9NLVJYP024292; Tue, 23 Oct 2012 15:31:19 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id q9NLVJeV024291; Tue, 23 Oct 2012 15:31:19 -0600 Date: Tue, 23 Oct 2012 15:31:19 -0600 From: "Brian F. G. Bidulock" To: urte plesske , sigtran@ietf.org Message-ID: <20121023213119.GC21751@openss7.org> Mail-Followup-To: urte plesske , sigtran@ietf.org References: <20121023212312.GA21751@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121023212312.GA21751@openss7.org> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Sigtran] M3UA: SCON: congestion condition never abates X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 21:31:30 -0000 urte, I should point out that there is an alternative to auditting congestion. That is to simply resume sending traffic after a short period (1.4-2.0 seconds). If the network is still congested, you should get a SCON message rather immediately. Otherise, traffic can just continue. --brian Brian F. G. Bidulock wrote: (Tue, 23 Oct 2012 15:23:12) > urte, > > Please see comments inline... > > urte plesske wrote: (Tue, 23 Oct 2012 16:58:27) > > Hello, I'm faced with a problem based on the following architecture: > > AS connected to two SGs > > AS > > / \ > > / \ > > SG1---SG2 > > SCCP: SGs are making GTTs to route to the ss7 network. > > MTP configurations on AS: > > There are two routesets defined on AS, one to SG1 (containing direct > > route and route over SG2) and to SG2 (containing direct route and route > > over SG1) > > > > SCON message was received by AS from SG2 with affected PC SG1. > > On AS the route set (PC SG1) was inhibited. No traffic was sent to SG1 > > by AS any more. > > This, to begin with, is somewhat peculiar. The circumstances > under which SG2 would send SCON to the AS concerning SG1's point > code would be: > > - traffic on the association from AS to SG2 is overloading; > > - SG2's SMH function is overloading (in which case it should > have first attempted a DRST in ANSI-based networks); > > - the C-links between SG2 and SG1 are congested. > > Which begs the question, why is the AS sending messages with DPC > of SG1 to SG2? Is not the direct route between AS and SG1 > available and unrestricted? Perhaps you have already received a > DRST from SG1 concerning its own point-code? (which would not be > correct). > > So, that's number 1 problem: Why are you sending M3UA-User > messages from the AS to SG1 via the indirect route through SG2 > when there exists a direct route to SG1? > > > Usually the AS would start sending periodic DAUDs messages as a result > > of the congestion, but because SG1 was got to know as adjacent node, no > > DAUDs with affected Point Code = Point Code SG1 were sent by any ASP. > > No SCON messages were sent by SG2 to AS because no DATA and DAUD > > messages were received to react. > > The congestion condition never abates. > > No, that is incorrect. You should audit even though the > destination is adjacent. Following on on my first issue, > you should be auditing SG1 already because there is something > the matter with the direct route for you to have been sending > messages on the indirect route. The direct route must be > restricted or unavailable, or the AS is doing the wrong thing. > > > > > Could you please help me with the following questions: > > How to solve this situation (timer on AS?)? > > Send periodic DAUD while point codes are marked congested. > The period should be 1.4 to 2.0 seconds. > > > Is it correct not to audit adjacent nodes? > > No it is not. Adjacent nodes need not be audited for > availability, but they do need to be audited for restriction and > congestion. > > > Can (should) SG2 send a SCON message even there are no DATA and DAUD > > messages to react? > > No, is does not have to. SG2 only need send SCON to the AS > under the same conditions as an STP would send TFC to an > adjacent signalling point. > > > Where can I find (rfc) the information, that SCON is like TFC and not > > TFR? > > In the sections describing SCON and DRST. SCON is equivalent > to TFC, DRST is equivalent to TFR. > > --brian > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Tue Oct 23 15:20:12 2012 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EB71F0C95 for ; Tue, 23 Oct 2012 15:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.222 X-Spam-Level: X-Spam-Status: No, score=-5.222 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NXo3eJHB+r0 for ; Tue, 23 Oct 2012 15:20:09 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9D411E80A3 for ; Tue, 23 Oct 2012 15:20:06 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9NMJvkC025389; Tue, 23 Oct 2012 16:19:58 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9NMJvQd025238; Tue, 23 Oct 2012 16:19:57 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id q9NMJveF025237; Tue, 23 Oct 2012 16:19:57 -0600 Date: Tue, 23 Oct 2012 16:19:57 -0600 From: "Brian F. G. Bidulock" To: David Laight Message-ID: <20121023221957.GA25013@openss7.org> Mail-Followup-To: David Laight , urte plesske , sigtran@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: SCON: congestion condition never abates X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 22:20:12 -0000 David, SCON(0) is a valid message indicating "No congestion" for networks the implement multiple congestion levels. SCON messages for international method do not include a congestion level parameter. In international networks, congestion abatement is signalled in response to DAUD with a DAVA not preceded by a SCON. There is an implementation note undef RFC4666/3.4.4 that indicates that an M3UA may maintain a timer to control congestion notification vality that will be useful in cases where the peer node fails to indicate congestion abatement. There is also a note undef RFC4666/4.5.3 ASP Auditing that states that periodic DAUD should not be initiated in response to SCON(0) (i.e. multiple congestion level network signalling congestion abatement). --brian David Laight wrote: (Tue, 23 Oct 2012 16:21:38) > I presume this is (supposed to be) M3UA? > > M3UA is an abstraction of the interface between MTP3 and its userparts > (typically SCCP and ISUP). > > This means that the `AS' box isn't running MTP3, so your descriptions > about routing are incorrect. > > > The M3UA SCON indication is telling the userpart that MTP3 received a > TFC for the route. > > This could be used by the userpart to reduce its traffic. > > There is no network message that indicates that congestion has ceased. > > IIRC M3UA also doesn't contain any such message. > > The `congestion level' will be 1, 2 or 3 in ansi networks, and always 0 > in ITU networks. > > > David > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Tue Oct 23 15:23:41 2012 Return-Path: X-Original-To: sigtran@ietfa.amsl.com Delivered-To: sigtran@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59F91F0C9C for ; Tue, 23 Oct 2012 15:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+yHT86TrY92 for ; Tue, 23 Oct 2012 15:23:41 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) by ietfa.amsl.com (Postfix) with ESMTP id C29641F0C95 for ; Tue, 23 Oct 2012 15:23:40 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9NMNcjw025421; Tue, 23 Oct 2012 16:23:38 -0600 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9NMNcWP025460; Tue, 23 Oct 2012 16:23:38 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id q9NMNc1F025459; Tue, 23 Oct 2012 16:23:38 -0600 Date: Tue, 23 Oct 2012 16:23:37 -0600 From: "Brian F. G. Bidulock" To: "Nemana, Satya" Message-ID: <20121023222337.GB25013@openss7.org> Mail-Followup-To: "Nemana, Satya" , urte plesske , "sigtran@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] M3UA: SCON: congestion condition never abates X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 22:23:41 -0000 Satya, An SG is not always able to notify congestion abatement in the multiple SG as STP configuration. In this configuration the AS is responsible for maintaining the state of routes, route lists and routesets toward the SS7 network via each SG/STP. What you way really only applys to the normal case where the SG "owns" the AS point code (i.e. the SG is an SEP and not an STP in an STP pair). --brian Nemana, Satya wrote: (Tue, 23 Oct 2012 15:13:24) > Hi Urte > > > Even if AS does not send DAUD(for SG1 PC) to SG2, SG2 should send an > SCON(Level-0) when the congestion clears. > > In your case, you don't explain if the AS clears(for SG1) when SG2 > sends SCON(Level-0) for SG1 PC. > > The DAUD from AS is not as important as the SCON(Level-0) that should > be sent by SG2 for clearing congestion towards SG1. > > The congestion in your case is not abating because SG2 is never > clearing congestion for PC:SG1. > > This sounds normal scenario as per protocol. > > > Regards, > > Satya -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/