From santhana@huawei.com Wed Dec 2 01:48:58 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A52128C182 for ; Wed, 2 Dec 2009 01:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.52 X-Spam-Level: ** X-Spam-Status: No, score=2.52 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb1lhKzko0Wm for ; Wed, 2 Dec 2009 01:48:55 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id C8B8C28C17F for ; Wed, 2 Dec 2009 01:48:54 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU000JFER8YH1@szxga01-in.huawei.com> for sigtran@ietf.org; Wed, 02 Dec 2009 17:48:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU000KQ2R8YT8@szxga01-in.huawei.com> for sigtran@ietf.org; Wed, 02 Dec 2009 17:48:34 +0800 (CST) Received: from BLRNSHTIPL2NC ([10.18.1.32]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU00091VR8TR7@szxml04-in.huawei.com> for sigtran@ietf.org; Wed, 02 Dec 2009 17:48:31 +0800 (CST) Date: Wed, 02 Dec 2009 15:10:49 +0530 From: Santhana To: sigtran@ietf.org Message-id: <000a01ca7333$89217cc0$2001120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_ojxEIKpytmxKAfHKJNIkag)" Thread-index: AcpzM4gB26EsP3ftTxSojoFSuPR4Jg== Subject: [Sigtran] [M3UA] Routing Context in DATA sent from ASP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 09:48:58 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ojxEIKpytmxKAfHKJNIkag) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Brian and other experts, When Routing Keys and Routing Contexts are provisioned between ASP and SGP, in the following scenario I have a doubt. ASP SGP ASP ACTIVE(RC1) --------------------------------------------------------------------------> ASP ACTIVE ACK(RC1) <-------------------------------------------------------------------------- DATA (RC1) <-------------------------------------------------------------------------- is this mandatory when ASP works for "one AS/multiple AS" ? DATA (RC1) --------------------------------------------------------------------------> is this necessary to include RC in DATA from ASP to SGP ? In the ASP ACTIVE and ACTIVE ACK message routing context RC1 is exchanged between ASP and SGP. Now DATA message is sent from both sides(SGP and ASP). When SGP sends a message to ASP, is it "mandatory" to include this RC parameter ? When ASP sends a message to SGP, is it "necessary" to include this RC parameter ? When ASP is working for only one AS, but still in ASP ACTIVE routing context RC1 is exchanged, then is it necessary for the DATA message sent from ASP to carry this RC ? Waiting for your valuable response. Regards Santhanakrishnan --Boundary_(ID_ojxEIKpytmxKAfHKJNIkag) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Brian and other experts,

            When Routing Keys and Routing Contexts are provisioned between ASP and SGP, in the following scenario I have a doubt.

 

ASP                                                                            SGP

                     ASP ACTIVE(RC1)

-------------------------------------------------------------------------->

 

                     ASP ACTIVE ACK(RC1)

<--------------------------------------------------------------------------

 

                     DATA (RC1)

<--------------------------------------------------------------------------        is this mandatory when ASP works for “one AS/multiple AS” ?

 

                     DATA (RC1)

-------------------------------------------------------------------------->        is this necessary to include RC in DATA from ASP to SGP ?

 

 

 

In the ASP ACTIVE and ACTIVE ACK message routing context RC1 is exchanged between ASP and SGP. Now DATA message is sent from both sides(SGP and ASP).

 

When SGP sends a message to ASP, is it “mandatory” to include this RC parameter ?

 

When ASP sends a message to SGP, is it “necessary” to include this RC parameter ?

 

When ASP is working for only one AS, but still in ASP ACTIVE routing context RC1 is exchanged, then is it necessary for the DATA message sent from ASP to carry this RC ?

 

Waiting for your valuable response.

 

Regards

Santhanakrishnan

--Boundary_(ID_ojxEIKpytmxKAfHKJNIkag)-- From sandy2787@gmail.com Thu Dec 3 01:27:43 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F423A6A03 for ; Thu, 3 Dec 2009 01:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrwar8HIJtp8 for ; Thu, 3 Dec 2009 01:27:43 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 038BE3A69E4 for ; Thu, 3 Dec 2009 01:27:42 -0800 (PST) Received: by pwi5 with SMTP id 5so193841pwi.29 for ; Thu, 03 Dec 2009 01:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=xspWvEKwPn7NSlTCYg4gWG4bQESc05NY6IuAP+NWbmE=; b=L/qhMm1oQs/XHXQ1Rw8VY94kPN8aQlmb1AXURmQkswOzIJ5AaUJ/K7TOvCNkF57QUY YuZ9QfxZulfT8eaYlrFe5N3E4Jyxhotb+17V0Gc8oZpbrKnoeWVFh5w9012Yno8fs5E6 9+C42F5DxP8EYLv5zMlCYqzarE4zH8IOnPdJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oN/G/rxWRo9nM4b0JYfnk9cSmQoLfa+vgSNkOPsHYR1kIs2U97VWSXAlgKoLSCkXGL 7ML9TFXNtPNN8y0REH+KOqlXV7Dr5iRr+RVOsLl4eJvZ2T9w2rbyJV7aGyNWYR1n17R2 /9spVuBmTCUI/o31c5WnS/298+goDDebDBr+I= MIME-Version: 1.0 Received: by 10.115.114.18 with SMTP id r18mr2230869wam.24.1259832452375; Thu, 03 Dec 2009 01:27:32 -0800 (PST) Date: Thu, 3 Dec 2009 14:57:31 +0530 Message-ID: From: Sandy To: sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016e64c16d4cce3e90479cf99bb Subject: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 09:27:43 -0000 --0016e64c16d4cce3e90479cf99bb Content-Type: text/plain; charset=ISO-8859-1 Hi All, We generally know that DUPU message is sent from SGP to ASP to indicate that the remote peer MTP3-user part is unavailable at SS7 node. What if ASP receives message with invalid SIO or if the message destined to the particular user is not available.In this case should ASP send a DUPU message to remote? If not what action should ASP take? Please explain. Thanks in advance. Regards, Sandeep B S. --0016e64c16d4cce3e90479cf99bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,

We generally know that DUPU message is sent from SGP to = ASP to indicate that the remote peer MTP3-user part is unavailable at SS7 n= ode.

What if ASP receives message with invalid SIO or if the message= destined to the particular user is not available.In this case should ASP s= end a DUPU message to remote? If not what action should ASP take? Please ex= plain.=A0 Thanks in advance.

Regards,
Sandeep B S.




--0016e64c16d4cce3e90479cf99bb-- From bidulock@openss7.org Thu Dec 3 05:30:35 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42FB33A684E for ; Thu, 3 Dec 2009 05:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+WpYA2HwjFm for ; Thu, 3 Dec 2009 05:30:34 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 0AF573A659B for ; Thu, 3 Dec 2009 05:30:33 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:yblq0hMaFz6Y2+jsQPtwpCTx9qrsFUFp@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id nB3DULua001433; Thu, 3 Dec 2009 06:30:21 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:yHjMpqoOB4OSl+OufDeSbm7W7/Sy8xhn@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id nB3DULJW023442; Thu, 3 Dec 2009 06:30:21 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id nB3DULb4023441; Thu, 3 Dec 2009 06:30:21 -0700 Date: Thu, 3 Dec 2009 06:30:21 -0700 From: "Brian F. G. Bidulock" To: Sandy Message-ID: <20091203133021.GB22736@openss7.org> Mail-Followup-To: Sandy , 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.13 (2006-08-11) Cc: sigtran@ietf.org Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 03 Dec 2009 13:30:35 -0000 Sandy, Invalid SIO should be screened by the SG. When an AS becomes unavailable at an ASP it should deactivate for the AS. DUPU is not permitted in the direction from ASP to SG. --brian Sandy wrote: (Thu, 03 Dec 2009 14:57:31) > > Hi All, > We generally know that DUPU message is sent from SGP to ASP to > indicate that the remote peer MTP3-user part is unavailable at SS7 > node. > What if ASP receives message with invalid SIO or if the message > destined to the particular user is not available.In this case should > ASP send a DUPU message to remote? If not what action should ASP take? > Please explain. Thanks in advance. > Regards, > Sandeep B S. > _______________________________________________ > 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 Thu Dec 3 05:32:17 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3E03A684E for ; Thu, 3 Dec 2009 05:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY3Dw5hY5Gtg for ; Thu, 3 Dec 2009 05:32:16 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 4B6613A659B for ; Thu, 3 Dec 2009 05:32:16 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:aAXDJr0k6gb75GTo3iZYyNILK4bm3f2v@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id nB3DVx4J001455; Thu, 3 Dec 2009 06:31:59 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:mytDrYb47g8A6JP1f6f2qk2100w6Xv+d@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id nB3DVw2W023527; Thu, 3 Dec 2009 06:31:58 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id nB3DVwbG023526; Thu, 3 Dec 2009 06:31:58 -0700 Date: Thu, 3 Dec 2009 06:31:58 -0700 From: "Brian F. G. Bidulock" To: Santhana Message-ID: <20091203133158.GC22736@openss7.org> Mail-Followup-To: Santhana , sigtran@ietf.org References: <000a01ca7333$89217cc0$2001120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000a01ca7333$89217cc0$2001120a@china.huawei.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sigtran@ietf.org Subject: Re: [Sigtran] [M3UA] Routing Context in DATA sent from ASP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 03 Dec 2009 13:32:17 -0000 Santhana, RC is not mandatory (in either direction) when the ASP is configured to serve a single AS. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From deepak.gunjal@aricent.com Thu Dec 3 06:28:05 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58DA28C164 for ; Thu, 3 Dec 2009 06:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSwjb1HZ+YPb for ; Thu, 3 Dec 2009 06:28:04 -0800 (PST) Received: from jaguar.aricent.com (unknown [125.21.164.247]) by core3.amsl.com (Postfix) with ESMTP id 0F77328C150 for ; Thu, 3 Dec 2009 06:28:04 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 5C42336B76; Thu, 3 Dec 2009 19:55:29 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 501F136B6E; Thu, 3 Dec 2009 19:55:29 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Thu, 3 Dec 2009 19:57:53 +0530 From: Deepak Gunjal To: "bidulock@openss7.org" , Sandy Date: Thu, 3 Dec 2009 19:57:53 +0530 Thread-Topic: [Sigtran] Should ASP send a DUPU? Thread-Index: Acp0HMtbB5MtyKRRTQGQryoN3MGqBwAB9K/w Message-ID: References: <20091203133021.GB22736@openss7.org> In-Reply-To: <20091203133021.GB22736@openss7.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 14:28:05 -0000 Hi, In case if my local SCCP user at ASP become unavailable, how does my local = ASP will notify to SG without DUPU? -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf = Of Brian F. G. Bidulock Sent: Thursday, December 03, 2009 7:00 PM To: Sandy Cc: sigtran@ietf.org Subject: Re: [Sigtran] Should ASP send a DUPU? Sandy, Invalid SIO should be screened by the SG. When an AS becomes unavailable at an ASP it should deactivate for the AS. DUPU is not permitted in the direction from ASP to SG. --brian Sandy wrote: (Thu, 03 Dec 2009 14:57:31) > > Hi All, > We generally know that DUPU message is sent from SGP to ASP to > indicate that the remote peer MTP3-user part is unavailable at SS7 > node. > What if ASP receives message with invalid SIO or if the message > destined to the particular user is not available.In this case should > ASP send a DUPU message to remote? If not what action should ASP take? > Please explain. Thanks in advance. > Regards, > Sandeep B S. > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From bidulock@openss7.org Thu Dec 3 11:55:25 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC7A3A6944 for ; Thu, 3 Dec 2009 11:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtjQEpfeLEZb for ; Thu, 3 Dec 2009 11:55:24 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id ABE7F3A6939 for ; Thu, 3 Dec 2009 11:55:24 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:kgvLmz13vqBKxhiD/gONwcx6s2M+ykfj@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id nB3Jt5Kh008242; Thu, 3 Dec 2009 12:55:05 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:WwCPnpeZR1ZCa/OlDRK4XcupaD4B0S7i@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id nB3Jt5AS004670; Thu, 3 Dec 2009 12:55:05 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id nB3Jt48F004669; Thu, 3 Dec 2009 12:55:04 -0700 Date: Thu, 3 Dec 2009 12:55:04 -0700 From: "Brian F. G. Bidulock" To: Deepak Gunjal Message-ID: <20091203195504.GA4446@openss7.org> Mail-Followup-To: Deepak Gunjal , Sandy , "sigtran@ietf.org" References: <20091203133021.GB22736@openss7.org> 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.13 (2006-08-11) Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 03 Dec 2009 19:55:25 -0000 Deepak, ASP Inactive. -- brian Deepak Gunjal wrote: (Thu, 03 Dec 2009 19:57:53) > Hi, > > In case if my local SCCP user at ASP become unavailable, how does my local ASP will notify to SG without DUPU? > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Brian F. G. Bidulock > Sent: Thursday, December 03, 2009 7:00 PM > To: Sandy > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Should ASP send a DUPU? > > Sandy, > > Invalid SIO should be screened by the SG. When an AS becomes > unavailable at an ASP it should deactivate for the AS. DUPU > is not permitted in the direction from ASP to SG. > > --brian > > Sandy wrote: (Thu, 03 Dec 2009 14:57:31) > > > > Hi All, > > We generally know that DUPU message is sent from SGP to ASP to > > indicate that the remote peer MTP3-user part is unavailable at SS7 > > node. > > What if ASP receives message with invalid SIO or if the message > > destined to the particular user is not available.In this case should > > ASP send a DUPU message to remote? If not what action should ASP take? > > Please explain. Thanks in advance. > > Regards, > > Sandeep B S. > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." > _______________________________________________ > 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 sandy2787@gmail.com Fri Dec 4 05:45:12 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E4F3A69E5 for ; Fri, 4 Dec 2009 05:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjb28-vpNlFs for ; Fri, 4 Dec 2009 05:45:11 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 728BA3A68D1 for ; Fri, 4 Dec 2009 05:45:11 -0800 (PST) Received: by pzk6 with SMTP id 6so2392209pzk.29 for ; Fri, 04 Dec 2009 05:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Cb0gZzXo5Q6OBq7jKAe6yg+MEUO6gc77tRyRd8kGBVE=; b=qzIqZcNPt9eYdLmAL1oQqGcvb/wQzBHa24QSvrhyULsle4Vqtx1SVmY0znuyIxS/Hn WAaykxyrv9b5qq8WHJO3aZdXOsrCvSDTZW3gwBGw7oZO4GRuzU/XZMkmFEj/5fZQ99gd yMbxINfs2pgVN5p1Y8m+gs4jMva8VOH49jb2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=MnyoBTf9iNzSg3wLMmcGItqUm+b2M43tnOWTz6+i0w8nuE8Q4avbnq+2WFDr2jN9zC 4fpSWxVeAeMTHFuJmfQaRG03Q9v/X9SpHuDUQYsXjeMxWibNrXkRUIksRaMOKMwIkgfi UvyLC4RJiwBCEFrLPllUOAwd4FTRYUaZCMFhc= MIME-Version: 1.0 Received: by 10.114.86.11 with SMTP id j11mr4135111wab.73.1259934297784; Fri, 04 Dec 2009 05:44:57 -0800 (PST) In-Reply-To: <20091203195504.GA4446@openss7.org> References: <20091203133021.GB22736@openss7.org> <20091203195504.GA4446@openss7.org> Date: Fri, 4 Dec 2009 19:14:57 +0530 Message-ID: From: Sandy To: bidulock@openss7.org, Deepak Gunjal , "sigtran@ietf.org" Content-Type: multipart/alternative; boundary=00504502ead54285a00479e75032 Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 13:45:12 -0000 --00504502ead54285a00479e75032 Content-Type: text/plain; charset=ISO-8859-1 Hi Brain, When the user part of ASP becomes unavailable then corresponding INACTIVE message for that AS is sent by ASP to SGP. At SGP side on receiving INACTIVE message from ASP, it searches for the corresponding routing key of the AS and sends DUNA/DUPU to SS7 point code based on the following conditions. DUNA is sent if the route is based on DPC only. DAVA is sent if the route is based on DPC and SIO Please confirm whether my understanding is on a right path. Regards, Sandeep B S On Fri, Dec 4, 2009 at 1:25 AM, Brian F. G. Bidulock wrote: > Deepak, > > ASP Inactive. > > -- brian > > Deepak Gunjal wrote: > (Thu, 03 Dec 2009 19:57:53) > > Hi, > > > > In case if my local SCCP user at ASP become unavailable, how does my > local ASP will notify to SG without DUPU? > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Brian F. G. Bidulock > > Sent: Thursday, December 03, 2009 7:00 PM > > To: Sandy > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] Should ASP send a DUPU? > > > > Sandy, > > > > Invalid SIO should be screened by the SG. When an AS becomes > > unavailable at an ASP it should deactivate for the AS. DUPU > > is not permitted in the direction from ASP to SG. > > > > --brian > > > > Sandy wrote: (Thu, 03 Dec 2009 14:57:31) > > > > > > Hi All, > > > We generally know that DUPU message is sent from SGP to ASP to > > > indicate that the remote peer MTP3-user part is unavailable at SS7 > > > node. > > > What if ASP receives message with invalid SIO or if the message > > > destined to the particular user is not available.In this case should > > > ASP send a DUPU message to remote? If not what action should ASP > take? > > > Please explain. Thanks in advance. > > > Regards, > > > Sandeep B S. > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www.ietf.org/mailman/listinfo/sigtran > > > > > > -- > > Brian F. G. Bidulock > > bidulock@openss7.org > > http://www.openss7.org/ > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran > > > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this > message. Aricent accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including damage from > virus." > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > --00504502ead54285a00479e75032 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Brain,

When the user part of ASP becomes unavailable then corresponding INACTIVE message fo= r that AS is sent by ASP to SGP. At SGP side on receiving INACTIVE message fr= om ASP, it searches for the corresponding routing key of the AS and sends DUNA/DUPU to SS7 point code based on the following conditions.

D= UNA is sent if the route is based on DPC only.

DAVA is sent if the route is based on DPC and SIO


Please confirm whether my understanding is on a right path.

Regards,
Sandeep B S

On Fri, Dec 4, 2009 at 1:25 A= M, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
Deepak,

ASP Inactive.

-- brian

Deepak Gunjal wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 (Thu, 03 Dec 2009 19:57:53)
> Hi,
>
> In case if my local SCCP user at ASP become unavailable, how does my l= ocal ASP will notify to SG without DUPU?
>
>
> -----Original Message-----
> From: sigtran-bounces@ietf= .org [mailto:sigtran-bounce= s@ietf.org] On Behalf Of Brian F. G. Bidulock
> Sent: Thursday, December 03, 2009 7:00 PM
> To: Sandy
> Cc: sigtran@ietf.org
> Subject: Re: [Sigtran] Should ASP send a DUPU?
>
> Sandy,
>
> Invalid SIO should be screened by the SG. =A0When an AS becomes
> unavailable at an ASP it should deactivate for the AS. =A0DUPU
> is not permitted in the direction from ASP to SG.
>
> --brian
>
> Sandy wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0(Thu, 03 Dec 2009 14:57:31)
> >
> > =A0 =A0Hi All,
> > =A0 =A0We generally know that DUPU message is sent from SGP to AS= P to
> > =A0 =A0indicate that the remote peer MTP3-user part is unavailabl= e at SS7
> > =A0 =A0node.
> > =A0 =A0What if ASP receives message with invalid SIO or if the me= ssage
> > =A0 =A0destined to the particular user is not available.In this c= ase should
> > =A0 =A0ASP send a DUPU message to remote? If not what action shou= ld ASP take?
> > =A0 =A0Please explain. =A0Thanks in advance.
> > =A0 =A0Regards,
> > =A0 =A0Sandeep B S.
>
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran@ietf.org
> > https://www.ietf.org/mailman/listinfo/sigtran
>
>
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.opens= s7.org/
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran
>
> "DISCLAIMER: This message is proprietary to Aricent and is intend= ed solely for the use of the individual to whom it is addressed. It may con= tain privileged or confidential information and should not be circulated or= used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this m= essage. Aricent accepts no responsibility for loss or damage arising from t= he use of the information transmitted by this email including damage from v= irus."
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran

--
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.or= g/

--00504502ead54285a00479e75032-- From sandy2787@gmail.com Fri Dec 4 05:52:36 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABECC3A6806 for ; Fri, 4 Dec 2009 05:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS+4yfFL+rjd for ; Fri, 4 Dec 2009 05:52:35 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 7FFED3A6A16 for ; Fri, 4 Dec 2009 05:52:35 -0800 (PST) Received: by pwi5 with SMTP id 5so1447595pwi.29 for ; Fri, 04 Dec 2009 05:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=iYmcF5TXZkRl8+Nwp670+6AbIStUtj5LogNfDXN+F14=; b=XTWZAtnL9iokC3GCv9B6Vig0YUzA11jWYWO87pCoMhJanFaNi/O3NxgKwXqR4e/Ylw /mQkon0eT/Ny8gdfmEvRKte/dpKTgtEaqUoCWeUBaAMsflUIGe79UD7YikJo8Q+unct3 Oikff/1OPQaPQdcZ6xOwAcYOFZvuIiGtGZ7Z4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=YzSxrSlmmhtBB5SuHM3FRIH/SrOdHp34CndBXoHnsc//0cuGTaI82dkDF38HBUd9tN AYhEh41ayYiLVb5HZKr8aCkiTmPu+jzap9Sp7SOL0vpkqNadmAACyKTkJ2DWjCcMJPjp gXolR64uPURS5zTJXkrk50O3YKkaKBdOqVG0I= MIME-Version: 1.0 Received: by 10.115.100.30 with SMTP id c30mr4015180wam.211.1259934743620; Fri, 04 Dec 2009 05:52:23 -0800 (PST) In-Reply-To: References: <20091203133021.GB22736@openss7.org> <20091203195504.GA4446@openss7.org> Date: Fri, 4 Dec 2009 19:22:23 +0530 Message-ID: From: Sandy To: bidulock@openss7.org, Deepak Gunjal , "sigtran@ietf.org" Content-Type: multipart/alternative; boundary=0016e64b9046d56be00479e76aca Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 13:52:36 -0000 --0016e64b9046d56be00479e76aca Content-Type: text/plain; charset=ISO-8859-1 Sorry, the second condition as to be : *DUPU* is sent if the route is based on DPC and SIO. Regards, Sandeep B S On Fri, Dec 4, 2009 at 7:14 PM, Sandy wrote: > Hi Brain, > > When the user part of ASP becomes unavailable then corresponding INACTIVE > message for that AS is sent by ASP to SGP. At SGP side on receiving INACTIVE > message from ASP, it searches for the corresponding routing key of the AS > and sends DUNA/DUPU to SS7 point code based on the following conditions. > > DUNA is sent if the route is based on DPC only. > > DAVA is sent if the route is based on DPC and SIO > > Please confirm whether my understanding is on a right path. > > Regards, > Sandeep B S > > > On Fri, Dec 4, 2009 at 1:25 AM, Brian F. G. Bidulock > wrote: > >> Deepak, >> >> ASP Inactive. >> >> -- brian >> >> Deepak Gunjal wrote: >> (Thu, 03 Dec 2009 19:57:53) >> > Hi, >> > >> > In case if my local SCCP user at ASP become unavailable, how does my >> local ASP will notify to SG without DUPU? >> > >> > >> > -----Original Message----- >> > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On >> Behalf Of Brian F. G. Bidulock >> > Sent: Thursday, December 03, 2009 7:00 PM >> > To: Sandy >> > Cc: sigtran@ietf.org >> > Subject: Re: [Sigtran] Should ASP send a DUPU? >> > >> > Sandy, >> > >> > Invalid SIO should be screened by the SG. When an AS becomes >> > unavailable at an ASP it should deactivate for the AS. DUPU >> > is not permitted in the direction from ASP to SG. >> > >> > --brian >> > >> > Sandy wrote: (Thu, 03 Dec 2009 >> 14:57:31) >> > > >> > > Hi All, >> > > We generally know that DUPU message is sent from SGP to ASP to >> > > indicate that the remote peer MTP3-user part is unavailable at SS7 >> > > node. >> > > What if ASP receives message with invalid SIO or if the message >> > > destined to the particular user is not available.In this case >> should >> > > ASP send a DUPU message to remote? If not what action should ASP >> take? >> > > Please explain. Thanks in advance. >> > > Regards, >> > > Sandeep B S. >> > >> > > _______________________________________________ >> > > Sigtran mailing list >> > > Sigtran@ietf.org >> > > https://www.ietf.org/mailman/listinfo/sigtran >> > >> > >> > -- >> > Brian F. G. Bidulock >> > bidulock@openss7.org >> > http://www.openss7.org/ >> > _______________________________________________ >> > Sigtran mailing list >> > Sigtran@ietf.org >> > https://www.ietf.org/mailman/listinfo/sigtran >> > >> > "DISCLAIMER: This message is proprietary to Aricent and is intended >> solely for the use of the individual to whom it is addressed. It may contain >> privileged or confidential information and should not be circulated or used >> for any purpose other than for what it is intended. If you have received >> this message in error, please notify the originator immediately. If you are >> not the intended recipient, you are notified that you are strictly >> prohibited from using, copying, altering, or disclosing the contents of this >> message. Aricent accepts no responsibility for loss or damage arising from >> the use of the information transmitted by this email including damage from >> virus." >> > _______________________________________________ >> > Sigtran mailing list >> > Sigtran@ietf.org >> > https://www.ietf.org/mailman/listinfo/sigtran >> >> -- >> Brian F. G. Bidulock >> bidulock@openss7.org >> http://www.openss7.org/ >> > > --0016e64b9046d56be00479e76aca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, the second condition as to be :

DUPU is sent if the r= oute is based on DPC and SIO.

Regards,
Sandeep B S

On Fri, Dec 4, 2009 at 7:14 PM, Sandy <sandy2787@gmail.com> wrote:

Hi Brain,=

When the user part of ASP becomes unavailable then corresponding INACTIVE message fo= r that AS is sent by ASP to SGP. At SGP side on receiving INACTIVE message fr= om ASP, it searches for the corresponding routing key of the AS and sends DUNA/DUPU to SS7 point code based on the following conditions.

D= UNA is sent if the route is based on DPC only.

DAVA is sent if the route is based on DPC and SIO


Please confirm whether my understanding is on a right path.

Regards,
Sandeep B S


On Fri, Dec 4, 2009 at 1:25 AM, Brian F. G. Bidulock <bidulock@ope= nss7.org> wrote:
Deepak,

ASP Inactive.

-- brian

Deepak Gunjal wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 (Thu, 03 Dec 2009 19:57:53)
> Hi,
>
> In case if my local SCCP user at ASP become unavailable, how does my l= ocal ASP will notify to SG without DUPU?
>
>
> -----Original Message-----
> From: si= gtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Brian F. G= . Bidulock
> Sent: Thursday, December 03, 2009 7:00 PM
> To: Sandy
> Cc: sigtran@ietf= .org
> Subject: Re: [Sigtran] Should ASP send a DUPU?
>
> Sandy,
>
> Invalid SIO should be screened by the SG. =A0When an AS becomes
> unavailable at an ASP it should deactivate for the AS. =A0DUPU
> is not permitted in the direction from ASP to SG.
>
> --brian
>
> Sandy wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0(Thu, 03 Dec 2009 14:57:31)
> >
> > =A0 =A0Hi All,
> > =A0 =A0We generally know that DUPU message is sent from SGP to AS= P to
> > =A0 =A0indicate that the remote peer MTP3-user part is unavailabl= e at SS7
> > =A0 =A0node.
> > =A0 =A0What if ASP receives message with invalid SIO or if the me= ssage
> > =A0 =A0destined to the particular user is not available.In this c= ase should
> > =A0 =A0ASP send a DUPU message to remote? If not what action shou= ld ASP take?
> > =A0 =A0Please explain. =A0Thanks in advance.
> > =A0 =A0Regards,
> > =A0 =A0Sandeep B S.
>
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran@iet= f.org
> > https://www.ietf.org/mailman/listinfo/sigtran
>
>
> --
> Brian F. G. Bidulock
> bidulock@ope= nss7.org
> http://www.opens= s7.org/
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org=
> https://www.ietf.org/mailman/listinfo/sigtran
>
> "DISCLAIMER: This message is proprietary to Aricent and is intend= ed solely for the use of the individual to whom it is addressed. It may con= tain privileged or confidential information and should not be circulated or= used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this m= essage. Aricent accepts no responsibility for loss or damage arising from t= he use of the information transmitted by this email including damage from v= irus."
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org=
> https://www.ietf.org/mailman/listinfo/sigtran

--
Brian F. G. Bidulock
bidulock@openss7.= org
http://www.openss7.or= g/


--0016e64b9046d56be00479e76aca-- From bidulock@openss7.org Fri Dec 4 16:08:19 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935F828C129 for ; Fri, 4 Dec 2009 16:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Afv+thvNVRwf for ; Fri, 4 Dec 2009 16:08:18 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 3591B28C128 for ; Fri, 4 Dec 2009 16:08:18 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:P49YbWCuJm+8klzcbvvRpmGXhsQ3mVn6@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id nB507qIj004008; Fri, 4 Dec 2009 17:07:52 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:eXq1dxUk5gH3paCIjCsqHMyLBgcNpypt@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id nB507qp6024753; Fri, 4 Dec 2009 17:07:52 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id nB507pl8024752; Fri, 4 Dec 2009 17:07:51 -0700 Date: Fri, 4 Dec 2009 17:07:51 -0700 From: "Brian F. G. Bidulock" To: Sandy Message-ID: <20091205000751.GA22698@openss7.org> Mail-Followup-To: Sandy , Deepak Gunjal , "sigtran@ietf.org" References: <20091203133021.GB22736@openss7.org> <20091203195504.GA4446@openss7.org> 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.13 (2006-08-11) Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 05 Dec 2009 00:08:19 -0000 Sandy, The SG does not send M3UA messages to SS7 Signalling Points. --brian Sandy wrote: (Fri, 04 Dec 2009 19:22:23) > > Sorry, the second condition as to be : > DUPU is sent if the route is based on DPC and SIO. > Regards, > Sandeep B S > > On Fri, Dec 4, 2009 at 7:14 PM, Sandy <[1]sandy2787@gmail.com> wrote: > > Hi Brain, > > When the user part of ASP becomes unavailable then corresponding > INACTIVE message for that AS is sent by ASP to SGP. At SGP side on > receiving INACTIVE message from ASP, it searches for the > corresponding routing key of the AS and sends DUNA/DUPU to SS7 > point code based on the following conditions. > > DUNA is sent if the route is based on DPC only. > > DAVA is sent if the route is based on DPC and SIO > Please confirm whether my understanding is on a right path. > Regards, > Sandeep B S > > On Fri, Dec 4, 2009 at 1:25 AM, Brian F. G. Bidulock > <[2]bidulock@openss7.org> wrote: > > Deepak, > ASP Inactive. > -- brian > Deepak Gunjal wrote: > (Thu, 03 Dec 2009 19:57:53) > > > Hi, > > > > In case if my local SCCP user at ASP become unavailable, how does my > local ASP will notify to SG without DUPU? > > > > > > -----Original Message----- > > From: [3]sigtran-bounces@ietf.org > [mailto:[4]sigtran-bounces@ietf.org] On Behalf Of Brian F. G. Bidulock > > Sent: Thursday, December 03, 2009 7:00 PM > > To: Sandy > > Cc: [5]sigtran@ietf.org > > Subject: Re: [Sigtran] Should ASP send a DUPU? > > > > Sandy, > > > > Invalid SIO should be screened by the SG. When an AS becomes > > unavailable at an ASP it should deactivate for the AS. DUPU > > is not permitted in the direction from ASP to SG. > > > > --brian > > > > Sandy wrote: (Thu, 03 Dec 2009 > 14:57:31) > > > > > > Hi All, > > > We generally know that DUPU message is sent from SGP to ASP to > > > indicate that the remote peer MTP3-user part is unavailable at > SS7 > > > node. > > > What if ASP receives message with invalid SIO or if the message > > > destined to the particular user is not available.In this case > should > > > ASP send a DUPU message to remote? If not what action should > ASP take? > > > Please explain. Thanks in advance. > > > Regards, > > > Sandeep B S. > > > > > _______________________________________________ > > > Sigtran mailing list > > > [6]Sigtran@ietf.org > > > [7]https://www.ietf.org/mailman/listinfo/sigtran > > > > > > -- > > Brian F. G. Bidulock > > [8]bidulock@openss7.org > > [9]http://www.openss7.org/ > > _______________________________________________ > > Sigtran mailing list > > [10]Sigtran@ietf.org > > [11]https://www.ietf.org/mailman/listinfo/sigtran > > > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, > altering, or disclosing the contents of this message. Aricent accepts > no responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > > _______________________________________________ > > Sigtran mailing list > > [12]Sigtran@ietf.org > > [13]https://www.ietf.org/mailman/listinfo/sigtran > -- > Brian F. G. Bidulock > [14]bidulock@openss7.org > [15]http://www.openss7.org/ > > References > > 1. mailto:sandy2787@gmail.com > 2. mailto:bidulock@openss7.org > 3. mailto:sigtran-bounces@ietf.org > 4. mailto:sigtran-bounces@ietf.org > 5. mailto:sigtran@ietf.org > 6. mailto:Sigtran@ietf.org > 7. https://www.ietf.org/mailman/listinfo/sigtran > 8. mailto:bidulock@openss7.org > 9. http://www.openss7.org/ > 10. mailto:Sigtran@ietf.org > 11. https://www.ietf.org/mailman/listinfo/sigtran > 12. mailto:Sigtran@ietf.org > 13. https://www.ietf.org/mailman/listinfo/sigtran > 14. mailto:bidulock@openss7.org > 15. http://www.openss7.org/ > _______________________________________________ > 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 sandy2787@gmail.com Sun Dec 6 21:50:04 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5F628C0CF for ; Sun, 6 Dec 2009 21:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58-jcAxi5POi for ; Sun, 6 Dec 2009 21:50:03 -0800 (PST) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id 3DD8B3A67F6 for ; Sun, 6 Dec 2009 21:50:03 -0800 (PST) Received: by pxi42 with SMTP id 42so1775584pxi.5 for ; Sun, 06 Dec 2009 21:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=VJmQZ9tUp2ZM+6x472WsheVxdr+1yQ9oGuD3V/GFGZQ=; b=v/PwebXv3HWgOXTnnS01D+m2WYLbyyLok33o6NrpVapazjlt8ApXPnMIkJOqYreTHs KzC+thnbPKT3S4YxhuQmk+jhUM8uQon+M1xbebWjwIKE004G0Hsygvu0k50NhWTGld0a Rp/w3wf9ME87h73Q7ZwbLktyHZzXsVTbFUHqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WHupzTZ6jOl+NeaNLX+9elsCFxeMGgZMMZzwGJ3K+w4abNWpRr3x/FbYvdMeMxw62G wZjM6rGBVM+wHKl0l4aVssEcm74jRuqT596UnE6iDs8FZY6QYxBAOhSXlOEB3NiqNi+q UF5HIqd4pJPXGwMcMw8k0D7wYDfzDdriBtt/c= MIME-Version: 1.0 Received: by 10.115.66.28 with SMTP id t28mr10679621wak.177.1260164987472; Sun, 06 Dec 2009 21:49:47 -0800 (PST) In-Reply-To: <20091205000751.GA22698@openss7.org> References: <20091203133021.GB22736@openss7.org> <20091203195504.GA4446@openss7.org> <20091205000751.GA22698@openss7.org> Date: Mon, 7 Dec 2009 11:19:47 +0530 Message-ID: From: Sandy To: bidulock@openss7.org, Sandy , Deepak Gunjal , "sigtran@ietf.org" Content-Type: multipart/alternative; boundary=0016e64756b46fce37047a1d061c Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 05:50:04 -0000 --0016e64756b46fce37047a1d061c Content-Type: text/plain; charset=ISO-8859-1 Hi, Thanks for your response. Does the corresponding SS7 primitives holds good for the scenario explained in previous mail. So on receiving INACTIVE from ASP, the SGP sends MTP- PAUSE primitive is sent if the route is based on dpc. MTP- UPU primitive is sent if the route is based on dpc and SIO. Regards, Sandeep B S On Sat, Dec 5, 2009 at 5:37 AM, Brian F. G. Bidulock wrote: > Sandy, > > The SG does not send M3UA messages to SS7 Signalling Points. > > --brian > > Sandy wrote: (Fri, 04 Dec 2009 19:22:23) > > > > Sorry, the second condition as to be : > > DUPU is sent if the route is based on DPC and SIO. > > Regards, > > Sandeep B S > > > > On Fri, Dec 4, 2009 at 7:14 PM, Sandy <[1]sandy2787@gmail.com> wrote: > > > > Hi Brain, > > > > When the user part of ASP becomes unavailable then corresponding > > INACTIVE message for that AS is sent by ASP to SGP. At SGP side on > > receiving INACTIVE message from ASP, it searches for the > > corresponding routing key of the AS and sends DUNA/DUPU to SS7 > > point code based on the following conditions. > > > > DUNA is sent if the route is based on DPC only. > > > > DAVA is sent if the route is based on DPC and SIO > > Please confirm whether my understanding is on a right path. > > Regards, > > Sandeep B S > > > > On Fri, Dec 4, 2009 at 1:25 AM, Brian F. G. Bidulock > > <[2]bidulock@openss7.org> wrote: > > > > Deepak, > > ASP Inactive. > > -- brian > > Deepak Gunjal wrote: > > (Thu, 03 Dec 2009 19:57:53) > > > > > Hi, > > > > > > In case if my local SCCP user at ASP become unavailable, how does my > > local ASP will notify to SG without DUPU? > > > > > > > > > -----Original Message----- > > > From: [3]sigtran-bounces@ietf.org > > [mailto:[4]sigtran-bounces@ietf.org] On Behalf Of Brian F. G. > Bidulock > > > Sent: Thursday, December 03, 2009 7:00 PM > > > To: Sandy > > > Cc: [5]sigtran@ietf.org > > > Subject: Re: [Sigtran] Should ASP send a DUPU? > > > > > > Sandy, > > > > > > Invalid SIO should be screened by the SG. When an AS becomes > > > unavailable at an ASP it should deactivate for the AS. DUPU > > > is not permitted in the direction from ASP to SG. > > > > > > --brian > > > > > > Sandy wrote: (Thu, 03 Dec 2009 > > 14:57:31) > > > > > > > > Hi All, > > > > We generally know that DUPU message is sent from SGP to ASP to > > > > indicate that the remote peer MTP3-user part is unavailable at > > SS7 > > > > node. > > > > What if ASP receives message with invalid SIO or if the message > > > > destined to the particular user is not available.In this case > > should > > > > ASP send a DUPU message to remote? If not what action should > > ASP take? > > > > Please explain. Thanks in advance. > > > > Regards, > > > > Sandeep B S. > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > [6]Sigtran@ietf.org > > > > [7]https://www.ietf.org/mailman/listinfo/sigtran > > > > > > > > > -- > > > Brian F. G. Bidulock > > > [8]bidulock@openss7.org > > > [9]http://www.openss7.org/ > > > _______________________________________________ > > > Sigtran mailing list > > > [10]Sigtran@ietf.org > > > [11]https://www.ietf.org/mailman/listinfo/sigtran > > > > > > "DISCLAIMER: This message is proprietary to Aricent and is intended > > solely for the use of the individual to whom it is addressed. It may > > contain privileged or confidential information and should not be > > circulated or used for any purpose other than for what it is intended. > > If you have received this message in error, please notify the > > originator immediately. If you are not the intended recipient, you are > > notified that you are strictly prohibited from using, copying, > > altering, or disclosing the contents of this message. Aricent accepts > > no responsibility for loss or damage arising from the use of the > > information transmitted by this email including damage from virus." > > > _______________________________________________ > > > Sigtran mailing list > > > [12]Sigtran@ietf.org > > > [13]https://www.ietf.org/mailman/listinfo/sigtran > > -- > > Brian F. G. Bidulock > > [14]bidulock@openss7.org > > [15]http://www.openss7.org/ > > > > References > > > > 1. mailto:sandy2787@gmail.com > > 2. mailto:bidulock@openss7.org > > 3. mailto:sigtran-bounces@ietf.org > > 4. mailto:sigtran-bounces@ietf.org > > 5. mailto:sigtran@ietf.org > > 6. mailto:Sigtran@ietf.org > > 7. https://www.ietf.org/mailman/listinfo/sigtran > > 8. mailto:bidulock@openss7.org > > 9. http://www.openss7.org/ > > 10. mailto:Sigtran@ietf.org > > 11. https://www.ietf.org/mailman/listinfo/sigtran > > 12. mailto:Sigtran@ietf.org > > 13. https://www.ietf.org/mailman/listinfo/sigtran > > 14. mailto:bidulock@openss7.org > > 15. http://www.openss7.org/ > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > --0016e64756b46fce37047a1d061c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Thanks for your response.

Does the corresponding SS7 prim= itives holds good for the scenario explained in previous mail.

So on= receiving INACTIVE from ASP, the SGP sends

=A0MTP- PAUSE primitive= is sent if the route is based on dpc.
=A0MTP- UPU primitive is sent if the route is based on dpc and SIO.

= Regards,
Sandeep B S

On Sat, Dec 5, 20= 09 at 5:37 AM, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
Sandy,

The SG does not send M3UA messages to SS7 Signalling Points.

--brian

Sandy wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0(Fri, 04 Dec 2009 19:22:23)
>
> =A0 =A0Sorry, the second condition as to be :
> =A0 =A0DUPU is sent if the route is based on DPC and SIO.
> =A0 =A0Regards,
> =A0 =A0Sandeep B S
>
> =A0 =A0On Fri, Dec 4, 2009 at 7:14 PM, Sandy &= lt;[1]sandy2787@gmail.com> wr= ote:
>
> =A0 =A0 =A0Hi Brain,
>
> =A0 =A0 =A0When the user part of ASP becomes unavailable then correspo= nding
> =A0 =A0 =A0INACTIVE message for that AS is sent by ASP to SGP. At SGP = side on
> =A0 =A0 =A0receiving INACTIVE message from ASP, it searches for the > =A0 =A0 =A0corresponding routing key of the AS and sends DUNA/DUPU to = SS7
> =A0 =A0 =A0point code based on the following conditions.
>
> =A0 =A0 =A0DUNA is sent if the route is based on DPC only.
>
> =A0 =A0 =A0DAVA is sent if the route is based on DPC and SIO
> =A0 =A0 =A0Please confirm whether my understanding is on a right path.=
> =A0 =A0 =A0Regards,
> =A0 =A0 =A0Sandeep B S
>
> =A0 =A0On Fri, Dec 4, 2009 at 1:25 AM, Brian F. G. Bidulock
> =A0 =A0<[2]bidulock@openss7.org> wrote:
>
> =A0 =A0 =A0Deepak,
> =A0 =A0 =A0ASP Inactive.
> =A0 =A0 =A0-- brian
> =A0 =A0 =A0Deepak Gunjal wrote:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Thu, 03 Dec 20= 09 19:57:53)
>
> =A0 =A0> Hi,
> =A0 =A0>
> =A0 =A0> In case if my local SCCP user at ASP become unavailable, h= ow does my
> =A0 =A0local ASP will notify to SG without DUPU?
> =A0 =A0>
> =A0 =A0>
> =A0 =A0> -----Original Message-----
> =A0 =A0> From: [3]sigtran-bounces@ietf.org
> =A0 =A0[mailto:[4]sigtran-= bounces@ietf.org] On Behalf Of Brian F. G. Bidulock
> =A0 =A0> Sent: Thursday, December 03, 2009 7:00 PM
> =A0 =A0> To: Sandy
> =A0 =A0> Cc: [5]sigtran@ietf.org
> =A0 =A0> Subject: Re: [Sigtran] Should ASP send a DUPU?
> =A0 =A0>
> =A0 =A0> Sandy,
> =A0 =A0>
> =A0 =A0> Invalid SIO should be screened by the SG. =A0When an AS be= comes
> =A0 =A0> unavailable at an ASP it should deactivate for the AS. =A0= DUPU
> =A0 =A0> is not permitted in the direction from ASP to SG.
> =A0 =A0>
> =A0 =A0> --brian
> =A0 =A0>
> =A0 =A0> Sandy wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0(Thu, 03 Dec 2009
> =A0 =A014:57:31)
> =A0 =A0> >
> =A0 =A0> > =A0 =A0Hi All,
> =A0 =A0> > =A0 =A0We generally know that DUPU message is sent fr= om SGP to ASP to
> =A0 =A0> > =A0 =A0indicate that the remote peer MTP3-user part i= s unavailable at
> =A0 =A0SS7
> =A0 =A0> > =A0 =A0node.
> =A0 =A0> > =A0 =A0What if ASP receives message with invalid SIO = or if the message
> =A0 =A0> > =A0 =A0destined to the particular user is not availab= le.In this case
> =A0 =A0should
> =A0 =A0> > =A0 =A0ASP send a DUPU message to remote? If not what= action should
> =A0 =A0ASP take?
> =A0 =A0> > =A0 =A0Please explain. =A0Thanks in advance.
> =A0 =A0> > =A0 =A0Regards,
> =A0 =A0> > =A0 =A0Sandeep B S.
> =A0 =A0>
> =A0 =A0> > _______________________________________________
> =A0 =A0> > Sigtran mailing list
> =A0 =A0> > [6]Si= gtran@ietf.org
> =A0 =A0> > [7]https://www.ietf.org/mailman/listinfo/sigtran=
> =A0 =A0>
> =A0 =A0>
> =A0 =A0> --
> =A0 =A0> Brian F. G. Bidulock
> =A0 =A0> [8]bidulock@openss= 7.org
> =A0 =A0> [9]h= ttp://www.openss7.org/
> =A0 =A0> _______________________________________________
> =A0 =A0> Sigtran mailing list
> =A0 =A0> [10]Sigtran@ietf.org
> =A0 =A0> [11]
https://www.ietf.org/mailman/listinfo/sigtran
> =A0 =A0>
> =A0 =A0> "DISCLAIMER: This message is proprietary to Aricent a= nd is intended
> =A0 =A0solely for the use of the individual to whom it is addressed. I= t may
> =A0 =A0contain privileged or confidential information and should not b= e
> =A0 =A0circulated or used for any purpose other than for what it is in= tended.
> =A0 =A0If you have received this message in error, please notify the > =A0 =A0originator immediately. If you are not the intended recipient, = you are
> =A0 =A0notified that you are strictly prohibited from using, copying,<= br> > =A0 =A0altering, or disclosing the contents of this message. Aricent a= ccepts
> =A0 =A0no responsibility for loss or damage arising from the use of th= e
> =A0 =A0information transmitted by this email including damage from vir= us."
> =A0 =A0> _______________________________________________
> =A0 =A0> Sigtran mailing list
> =A0 =A0> [12]Sigtran@ietf= .org
> =A0 =A0> [13]https://www.ietf.org/mailman/listinfo/sigtran
> =A0 =A0--
> =A0 =A0Brian F. G. Bidulock
> =A0 =A0[14]bidulock@openss7.or= g
> =A0 =A0[15]http:= //www.openss7.org/
>
> References
>
> =A0 =A01. mailto:sandy2787@gmai= l.com
> =A0 =A02. mailto:bidulock@open= ss7.org
> =A0 =A03. mailto:sigtran-b= ounces@ietf.org
> =A0 =A04. mailto:sigtran-b= ounces@ietf.org
> =A0 =A05. mailto:sigtran@ietf.org<= /a>
> =A0 =A06. mailto:
Sigtran@ietf.org<= /a>
> =A0 =A07.
https://www.ietf.org/mailman/listinfo/sigtran
> =A0 =A08. mailto:bidulock@open= ss7.org
> =A0 =A09. http:/= /www.openss7.org/
> =A0 10. mailto:Sigtran@ietf.org
> =A0 11.
https://www.ietf.org/mailman/listinfo/sigtran
> =A0 12. mailto:Sigtran@ietf.org
> =A0 13.
https://www.ietf.org/mailman/listinfo/sigtran
> =A0 14. mailto:bidulock@openss= 7.org
> =A0 15. http://w= ww.openss7.org/

> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran


--

--0016e64756b46fce37047a1d061c-- From bidulock@openss7.org Sun Dec 6 23:12:38 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690F63A6863 for ; Sun, 6 Dec 2009 23:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5794m77U5gI for ; Sun, 6 Dec 2009 23:12:37 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 43DE428C0DC for ; Sun, 6 Dec 2009 23:12:37 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:VkkadyJSuFbCzVIHxgiv5ffPOOhwjpUR@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id nB77C9nw028586; Mon, 7 Dec 2009 00:12:09 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:7B4gtAvgBAcWsevhB9zRA/5J+8P317tF@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id nB77C9mT002648; Mon, 7 Dec 2009 00:12:09 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id nB77C8Dx002647; Mon, 7 Dec 2009 00:12:08 -0700 Date: Mon, 7 Dec 2009 00:12:08 -0700 From: "Brian F. G. Bidulock" To: Sandy Message-ID: <20091207071208.GA1766@openss7.org> Mail-Followup-To: Sandy , Deepak Gunjal , "sigtran@ietf.org" References: <20091203133021.GB22736@openss7.org> <20091203195504.GA4446@openss7.org> <20091205000751.GA22698@openss7.org> 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.13 (2006-08-11) Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 07 Dec 2009 07:12:38 -0000 Sandy, The SG does not send MTP primitives to SS7 signalling points either. (Also, there is no such MTP primitive as MTP-UPU.) --brian Sandy wrote: (Mon, 07 Dec 2009 11:19:47) > > Hi, > Thanks for your response. > Does the corresponding SS7 primitives holds good for the scenario > explained in previous mail. > So on receiving INACTIVE from ASP, the SGP sends > MTP- PAUSE primitive is sent if the route is based on dpc. > MTP- UPU primitive is sent if the route is based on dpc and SIO. > Regards, > Sandeep B S > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From deepak.gunjal@aricent.com Sun Dec 6 23:17:32 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B024C3A6863 for ; Sun, 6 Dec 2009 23:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVjLsaqfHS6B for ; Sun, 6 Dec 2009 23:17:27 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by core3.amsl.com (Postfix) with ESMTP id A60F628C121 for ; Sun, 6 Dec 2009 23:17:25 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id B293F36B6E; Mon, 7 Dec 2009 12:44:47 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 9CC3036B67; Mon, 7 Dec 2009 12:44:47 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Mon, 7 Dec 2009 12:47:14 +0530 From: Deepak Gunjal To: "bidulock@openss7.org" , Sandy Date: Mon, 7 Dec 2009 12:47:13 +0530 Thread-Topic: [Sigtran] Should ASP send a DUPU? Thread-Index: Acp3DKJjwiP9+O5vSFapWYJZ7jsDcAAAC2gA Message-ID: References: <20091203133021.GB22736@openss7.org> <20091203195504.GA4446@openss7.org> <20091205000751.GA22698@openss7.org> <20091207071208.GA1766@openss7.org> In-Reply-To: <20091207071208.GA1766@openss7.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 07:17:32 -0000 Hi Brian, If it is not the SG then who converts the various state management messages= from ASP to corresponding MTP3 management messages? As per my understanding NIF at SG should map the State management messages = from ASP to MTP3 traffic management messages and finally the MTP3 layer at = SEP would convert to MTP3 upper layer service primitives like pause/resume = indications. -Deepak -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Monday, December 07, 2009 12:42 PM To: Sandy Cc: Deepak Gunjal; sigtran@ietf.org Subject: Re: [Sigtran] Should ASP send a DUPU? Sandy, The SG does not send MTP primitives to SS7 signalling points either. (Also, there is no such MTP primitive as MTP-UPU.) --brian Sandy wrote: (Mon, 07 Dec 2009 11:19:47) > > Hi, > Thanks for your response. > Does the corresponding SS7 primitives holds good for the scenario > explained in previous mail. > So on receiving INACTIVE from ASP, the SGP sends > MTP- PAUSE primitive is sent if the route is based on dpc. > MTP- UPU primitive is sent if the route is based on dpc and SIO. > Regards, > Sandeep B S > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From bidulock@openss7.org Sun Dec 6 23:44:12 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7A028C11A for ; Sun, 6 Dec 2009 23:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohub5IV1FnUL for ; Sun, 6 Dec 2009 23:44:11 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id ED4B128C118 for ; Sun, 6 Dec 2009 23:44:10 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:cloX4u4Kl0EIJtlVo/miIEGhe9OBEmDR@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id nB77hqmN029161; Mon, 7 Dec 2009 00:43:52 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:P6LUVToqNB5Ib0/IIdWEEMWb3Nt8UDgu@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id nB77hpr7003761; Mon, 7 Dec 2009 00:43:51 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id nB77hpMp003760; Mon, 7 Dec 2009 00:43:51 -0700 Date: Mon, 7 Dec 2009 00:43:51 -0700 From: "Brian F. G. Bidulock" To: Deepak Gunjal Message-ID: <20091207074351.GA2670@openss7.org> Mail-Followup-To: Deepak Gunjal , Sandy , "sigtran@ietf.org" References: <20091203133021.GB22736@openss7.org> <20091203195504.GA4446@openss7.org> <20091205000751.GA22698@openss7.org> <20091207071208.GA1766@openss7.org> 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.13 (2006-08-11) Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 07 Dec 2009 07:44:12 -0000 Deepak, Yes, and the SG would have to send SS7 MESSAGES to the remote SEP to accomplish this. The messages sent, and under what circumstances they are sent, are dictated by the SS7 protocol and variant: not by M3UA. So, why is DUPU only sent from SG to ASP?--because, the MTP-STATUS primitive to which it corresponds is only available as an indication primitive. How does an ASP (instance of an MTP-User) indicate to the SG (MTP) that it has gone away?--by loss of communication or explicit deactivation (ASP Inactive). What does the SG (MTP) do with that information?--what MTP always does when a user goes away. It matters not what registration key is used within the domain of M3UA. What the SG does is within the scope of the SS7 standards and is outside the scope of M3UA. See sections 1.6, 4.5 and 5.5.2.3 of the RFC. --brian Deepak Gunjal wrote: (Mon, 07 Dec 2009 12:47:13) > Hi Brian, > > If it is not the SG then who converts the various state management > messages from ASP to corresponding MTP3 management messages? > > As per my understanding NIF at SG should map the State management > messages from ASP to MTP3 traffic management messages and finally > the MTP3 layer at SEP would convert to MTP3 upper layer service > primitives like pause/resume indications. > > -Deepak > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, December 07, 2009 12:42 PM > To: Sandy > Cc: Deepak Gunjal; sigtran@ietf.org > Subject: Re: [Sigtran] Should ASP send a DUPU? > > Sandy, > > The SG does not send MTP primitives to SS7 signalling points either. > > (Also, there is no such MTP primitive as MTP-UPU.) > > --brian > > Sandy wrote: (Mon, 07 Dec 2009 11:19:47) > > > > Hi, > > Thanks for your response. > > Does the corresponding SS7 primitives holds good for the scenario > > explained in previous mail. > > So on receiving INACTIVE from ASP, the SGP sends > > MTP- PAUSE primitive is sent if the route is based on dpc. > > MTP- UPU primitive is sent if the route is based on dpc and SIO. > > Regards, > > Sandeep B S > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." > _______________________________________________ > 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 deepak.gunjal@aricent.com Sun Dec 6 23:57:10 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FA028C127 for ; Sun, 6 Dec 2009 23:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrVO806RGVub for ; Sun, 6 Dec 2009 23:57:09 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 3A96A28C118 for ; Sun, 6 Dec 2009 23:57:09 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 5624936B5F; Mon, 7 Dec 2009 13:24:30 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 4031736B50; Mon, 7 Dec 2009 13:24:29 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Mon, 7 Dec 2009 13:26:56 +0530 From: Deepak Gunjal To: "bidulock@openss7.org" Date: Mon, 7 Dec 2009 13:26:55 +0530 Thread-Topic: [Sigtran] Should ASP send a DUPU? Thread-Index: Acp3EQmrb1/ZZiKBSua5voq5j3b7PgAAcFRw Message-ID: References: <20091203133021.GB22736@openss7.org> <20091203195504.GA4446@openss7.org> <20091205000751.GA22698@openss7.org> <20091207071208.GA1766@openss7.org> <20091207074351.GA2670@openss7.org> In-Reply-To: <20091207074351.GA2670@openss7.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Should ASP send a DUPU? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 07:57:10 -0000 Thanks Brian. It explains the SG functions. -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Monday, December 07, 2009 1:14 PM To: Deepak Gunjal Cc: Sandy; sigtran@ietf.org Subject: Re: [Sigtran] Should ASP send a DUPU? Deepak, Yes, and the SG would have to send SS7 MESSAGES to the remote SEP to accomplish this. The messages sent, and under what circumstances they are sent, are dictated by the SS7 protocol and variant: not by M3UA. So, why is DUPU only sent from SG to ASP?--because, the MTP-STATUS primitive to which it corresponds is only available as an indication primitive. How does an ASP (instance of an MTP-User) indicate to the SG (MTP) that it has gone away?--by loss of communication or explicit deactivation (ASP Inactive). What does the SG (MTP) do with that information?--what MTP always does when a user goes away. It matters not what registration key is used within the domain of M3UA. What the SG does is within the scope of the SS7 standards and is outside the scope of M3UA. See sections 1.6, 4.5 and 5.5.2.3 of the RFC. --brian Deepak Gunjal wrote: (Mon, 07 Dec 2009 12:47:13) > Hi Brian, > > If it is not the SG then who converts the various state management > messages from ASP to corresponding MTP3 management messages? > > As per my understanding NIF at SG should map the State management > messages from ASP to MTP3 traffic management messages and finally > the MTP3 layer at SEP would convert to MTP3 upper layer service > primitives like pause/resume indications. > > -Deepak > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, December 07, 2009 12:42 PM > To: Sandy > Cc: Deepak Gunjal; sigtran@ietf.org > Subject: Re: [Sigtran] Should ASP send a DUPU? > > Sandy, > > The SG does not send MTP primitives to SS7 signalling points either. > > (Also, there is no such MTP primitive as MTP-UPU.) > > --brian > > Sandy wrote: (Mon, 07 Dec 2009 11:19:47) > > > > Hi, > > Thanks for your response. > > Does the corresponding SS7 primitives holds good for the scenario > > explained in previous mail. > > So on receiving INACTIVE from ASP, the SGP sends > > MTP- PAUSE primitive is sent if the route is based on dpc. > > MTP- UPU primitive is sent if the route is based on dpc and SIO. > > Regards, > > Sandeep B S > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > "DISCLAIMER: This message is proprietary to Aricent and is intended solel= y for the use of the individual to whom it is addressed. It may contain pri= vileged or confidential information and should not be circulated or used fo= r any purpose other than for what it is intended. If you have received this= message in error, please notify the originator immediately. If you are not= the intended recipient, you are notified that you are strictly prohibited = from using, copying, altering, or disclosing the contents of this message. = Aricent accepts no responsibility for loss or damage arising from the use o= f the information transmitted by this email including damage from virus." > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From evgenij.fokin@gmail.com Wed Dec 16 07:35:30 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739043A696B for ; Wed, 16 Dec 2009 07:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO1ZeQodNROm for ; Wed, 16 Dec 2009 07:35:29 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 200D33A6863 for ; Wed, 16 Dec 2009 07:35:28 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so805478fgg.13 for ; Wed, 16 Dec 2009 07:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=JTPYGfwSz1dnlJc6JheyRJetQ/nRRegnHG9ONsMTw3s=; b=md4ieHLhDeqLNjsBtYz8f4zIFW/v2bnOOtKiAa85K41Y3/XnMRXb2AmbsinAgyHHPm fgCBOeCciBoPBTSO4opLv1AzDkWbHIZC5/FaKmGZ3SOd2x6w9/VYzXznzzex5AiaDwx9 xbG3jeiBTSHFoka3QgBv42TrwbTwmXvNNcISM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gPJsvjgKRdWqeOTvDv3/NQfXu2rOLMnSwctuefFl4aHg8MhKlRxo96vGnzIO2u6Qno bAYyhTTCoeUl7SAwsV1pBfqJQAQNNZBYM9+14JtY5Zw4rYZMVIjEMp7mk6CXbYN1FMrK ti1KQgN/BGJbf/DgvCuZvx6FemNZqCEQBxWKQ= MIME-Version: 1.0 Received: by 10.86.233.20 with SMTP id f20mr1591524fgh.28.1260977712302; Wed, 16 Dec 2009 07:35:12 -0800 (PST) Date: Wed, 16 Dec 2009 18:35:12 +0300 Message-ID: From: Evgenij To: sigtran@ietf.org Content-Type: multipart/alternative; boundary=001485f33bec9c8cfd047ada4023 Subject: [Sigtran] [M3UA] IPSP DE ASP Up Procedures X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 15:35:30 -0000 --001485f33bec9c8cfd047ada4023 Content-Type: text/plain; charset=ISO-8859-1 Hi All, How many interchange ASP Up messages are needed for ASP Up procedure? In section 4.3.4.1.2 saying that four messages are needed but in section 5.6.2 saying that one single exchange of ASP UP message is enough. It is contradiction or not? 4.3.4.1.2. IPSP Considerations (ASP Up) Alternatively, when using the IPSP DE model, an interchange of ASP Up messages from each end *MUST* be performed. Four messages are needed for completion. 5.6.2. Double Exchange IPSP-A IPSP-B | | |<-------------ASP Up------------| |-----------ASP Up Ack---------->| | | |-------------ASP Up------------>| (optional) |<----------ASP Up Ack-----------| (optional) | | |<------- ASP Active(RCb)--------| RC: Routing Context |-----ASP Active Ack (RCb)------>| (optional) | | |------- ASP Active(RCa)-------->| RC: Routing Context |<-----ASP Active Ack (RCa)------| (optional) | | |<========= DATA (RCa) =========| |========== DATA (RCb) ========>| | | |<-----ASP Inactive (RCb)--------| RC: Routing Context |----ASP Inactive Ack (RCb)----->| | | |------ASP Inactive (RCa)------->| RC: Routing Context |<----ASP Inactive Ack (RCa)-----| | | |<-----------ASP Down------------| |---------ASP Down Ack---------->| | | |------------ASP Down----------->| (optional) |<--------ASP Down Ack-----------| (optional) | | In this approach, *only one single exchange of ASP Up message* can be considered sufficient since the response by the other peer can be considered a notice that it is in ASP_UP state. --- Regards Evgenij --001485f33bec9c8cfd047ada4023 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,
<= br>=A0=A0=A0 How many interchange ASP Up messages are needed for ASP Up pro= cedure?
In section
4.3.4.1.2 saying that four messages are nee= ded but in section 5.6.2 saying that one single exchange of ASP UP message is enough= . It is contradi= ction or not?

4.3.4.1.2. =A0IPSP Considerations (ASP Up)

=A0 Alternatively, when using the IPSP DE model, an interchange of ASP Up
=A0 messages from each e= nd MUST be performed. =A0Four messages are needed
=A0 for completion.

5= .6.2. =A0Double Exchange

=A0 =A0 =A0 =A0 =A0 =A0 =A0 IPSP-A =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPSP-B
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<-------------ASP Up----------= --|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |-----------ASP Up Ack---------->|
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |-------------= ASP Up------------>| =A0(optional)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= <----------ASP Up Ack-----------| =A0(optional)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<------- A= SP Active(RCb)--------| =A0RC: Routing Context
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |-----ASP Active Ack (RCb)------>| =A0 =A0 =A0(optional)
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |------- ASP Active(RCa)-------->| =A0R= C: Routing Context
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<-----ASP Active= Ack (RCa)------| =A0 =A0 =A0(optional)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<=3D=3D=3D=3D=3D=3D=3D=3D=3D =A0DATA (RCa)= =3D=3D=3D=3D=3D=3D=3D=3D=3D|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =A0DATA (R= Cb) =3D=3D=3D=3D=3D=3D=3D=3D>|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |<-----ASP Inactive (RCb)--------| =A0RC: Routin= g Context
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |----ASP Inactive Ack (RCb)--= --->|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |------ASP Ina= ctive (RCa)------->| =A0RC: Routing Context
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |<----ASP Inactive Ack (RCa)-----|
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<-----------ASP Down------------|
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |---------ASP Down Ack---------->|
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |------------A= SP Down----------->| =A0(optional)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<--------ASP Down Ack-----------| =A0(= optional)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|

=A0 In this approach, only one single exchange of ASP Up messa= ge can be
=A0 considered sufficient since the= response by the other peer can be
=A0 considered a notice that it = is in ASP_UP state.

= ---

Regards

=A0=A0=A0 Evgenij

--001485f33bec9c8cfd047ada4023-- From ifed@linkbit.com Wed Dec 16 08:20:23 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF94E3A69E0 for ; Wed, 16 Dec 2009 08:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0GgEGDhEIZC for ; Wed, 16 Dec 2009 08:20:22 -0800 (PST) Received: from mail.linkbit.com (mail.linkbit.com [192.217.199.58]) by core3.amsl.com (Postfix) with ESMTP id EF0193A69DE for ; Wed, 16 Dec 2009 08:20:18 -0800 (PST) Received: from [10.183.0.52] (k5752-e6339.cpms.ru [87.236.27.76]) (authenticated bits=0) by mail.linkbit.com (8.14.3/8.14.3) with ESMTP id nBGGHHsR023695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Dec 2009 08:17:19 -0800 (PST) (envelope-from ifed@linkbit.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=linkbit.com; s=mail; t=1260980239; bh=V4jAct8HgyWRwaFlAfBmw1OcSJyuDZ7U2DF8XaFojvY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=gt+em/hswAAzABWb1pKdJN/GxyJpFDvqjAYSws 6BvSyEzXSGLPfJncd52mVOBppIc4x7EuGx6HTFI4m4kBXFTpvhmaPSfjFoh07AJBZrv fEMMdnEWBhqt5lBpQJqRCtadFUNSI73kpwb5Mun58/Ad3cEyY7ONB73SWkrrOhVo9E= Message-ID: <4B2908AF.9090705@linkbit.com> Date: Wed, 16 Dec 2009 19:19:59 +0300 From: Igor Fedotov User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Sigtran@ietf.org References: <4B290460.6010303@linkbit.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060508000503040304030806" Subject: Re: [Sigtran] [M3UA] IPSP DE ASP Up Procedures X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:20:23 -0000 This is a multi-part message in MIME format. --------------060508000503040304030806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Evgenij IMHO M3UA spec isn't clear in the issue. This was mentioned for example at SIGTRAN PLUGTESTS in Moscow in 2007 ( http://www.etsi.eu/WebSite/document/PlugtestsHistory/2007SIGTRAN/SIGTRAN_2007_REPORT.pdf, day 5 report, issue 1). I'd say, the most preferable approach would be to use four messages in Double Exchange, as described here: http://www.archivum.info/sigtran@ietf.org/2005-07/00030/RE:_%5BSigtran%5D_M3UA_:_2_or_4_messages_for_ASP-UP_in_IPSP_DE > *From: *Evgenij > > *Date: *December 16, 2009 7:35:12 AM PST > *To: *sigtran@ietf.org > *Subject: **[Sigtran] [M3UA] IPSP DE ASP Up Procedures* > > Hi All, > > How many interchange ASP Up messages are needed for ASP Up procedure? > In section 4.3.4.1.2 saying that four messages are needed but in > section 5.6.2 saying that one single exchange of ASP UP message is > enough. It is contradiction or not? > > 4.3.4.1.2. IPSP Considerations (ASP Up) > > Alternatively, when using the IPSP DE model, an interchange of ASP Up > messages from each end *MUST* be performed. Four messages are needed > for completion. > > 5.6.2. Double Exchange > > IPSP-A IPSP-B > | | > |<-------------ASP Up------------| > |-----------ASP Up Ack---------->| > | | > |-------------ASP Up------------>| (optional) > |<----------ASP Up Ack-----------| (optional) > | | > |<------- ASP Active(RCb)--------| RC: Routing Context > |-----ASP Active Ack (RCb)------>| (optional) > | | > |------- ASP Active(RCa)-------->| RC: Routing Context > |<-----ASP Active Ack (RCa)------| (optional) > | | > |<========= DATA (RCa) =========| > |========== DATA (RCb) ========>| > | | > |<-----ASP Inactive (RCb)--------| RC: Routing Context > |----ASP Inactive Ack (RCb)----->| > | | > |------ASP Inactive (RCa)------->| RC: Routing Context > |<----ASP Inactive Ack (RCa)-----| > | | > |<-----------ASP Down------------| > |---------ASP Down Ack---------->| > | | > |------------ASP Down----------->| (optional) > |<--------ASP Down Ack-----------| (optional) > | | > > In this approach, *only one single exchange of ASP Up message* can be > considered sufficient since the response by the other peer can be > considered a notice that it is in ASP_UP state. > > --- > > Regards > > Evgenij > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran --------------060508000503040304030806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Evgenij

IMHO M3UA spec isn't clear in the issue. This was mentioned for example at SIGTRAN PLUGTESTS in Moscow in 2007 ( http://www.etsi.eu/WebSite/document/PlugtestsHistory/2007SIGTRAN/SIGTRAN_2007_REPORT.pdf, day 5 report, issue 1).

I'd say, the most preferable approach would be to use four messages in Double Exchange, as described here:


From: Evgenij <evgenij.fokin@gmail.com>
Date: December 16, 2009 7:35:12 AM PST
Subject: [Sigtran] [M3UA] IPSP DE ASP Up Procedures

Hi All,

    How many interchange ASP Up messages are needed for ASP Up procedure?
In section
4.3.4.1.2 saying that four messages are needed but in section 5.6.2 saying that one single exchange of ASP UP message is enough. It is contradiction or not?

4.3.4.1.2.  IPSP Considerations (ASP Up)

  Alternatively, when using the IPSP DE model, an interchange of ASP Up
  messages from each end MUST be performed.  Four messages are needed
  for completion.

5.6.2.  Double Exchange

              IPSP-A                           IPSP-B
                |                                |
                |<-------------ASP Up------------|
                |-----------ASP Up Ack---------->|
                |                                |
                |-------------ASP Up------------>|  (optional)
                |<----------ASP Up Ack-----------|  (optional)
                |                                |
                |<------- ASP Active(RCb)--------|  RC: Routing Context
                |-----ASP Active Ack (RCb)------>|      (optional)
                |                                |
                |------- ASP Active(RCa)-------->|  RC: Routing Context
                |<-----ASP Active Ack (RCa)------|      (optional)
                |                                |
                |<=========  DATA (RCa) =========|
                |==========  DATA (RCb) ========>|
                |                                |
                |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                |----ASP Inactive Ack (RCb)----->|
                |                                |
                |------ASP Inactive (RCa)------->|  RC: Routing Context
                |<----ASP Inactive Ack (RCa)-----|
                |                                |
                |<-----------ASP Down------------|
                |---------ASP Down Ack---------->|
                |                                |
                |------------ASP Down----------->|  (optional)
                |<--------ASP Down Ack-----------|  (optional)
                |                                |

  In this approach, only one single exchange of ASP Up message can be
  considered sufficient since the response by the other peer can be
  considered a notice that it is in ASP_UP state.

---

Regards

    Evgenij
    
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran


--------------060508000503040304030806-- From evgenij.fokin@gmail.com Thu Dec 17 01:04:05 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B963A67D9 for ; Thu, 17 Dec 2009 01:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J525wwyDbO+j for ; Thu, 17 Dec 2009 01:04:04 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 9404C3A6877 for ; Thu, 17 Dec 2009 01:04:04 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 19so676596fgg.13 for ; Thu, 17 Dec 2009 01:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=SjgFoiDdS5S29/jRgedVXPCOne3DodnOoSad3jn1ui8=; b=EHv1ro1CCXEI9l3+p4GlTsNzHOB9OFcUqc1Y2/pfcjVZH0u2PHlnIr+mARzfGV1hIA iVRLoaPrybliZF5XM7Ab3f9OUFOi/jAT4uAm1A/2iQvaqKGOqF6D0YlGtfCXY2/QvvC/ DKanFCsYEXSfliQOQOXipBU9pcN6oSaS2qneQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=SVN9uBBxkUbSKrtRXTT7owSHcRwHF5NwG7BcSa/Zj5FSul+9sS8B0mIBixzqlM8HpP 9XEU56OP8ov5ggfC3zCBLH73kWbgtRhU9k1qs/HweTZPK0x1nSXc+WRpxF+mgPA4Jlrz TZGEoz8EjnK3rwhgWMWzDmGE5OFkX2G9aIufY= MIME-Version: 1.0 Received: by 10.239.168.163 with SMTP id k35mr232036hbe.71.1261040626181; Thu, 17 Dec 2009 01:03:46 -0800 (PST) In-Reply-To: <4B2908AF.9090705@linkbit.com> References: <4B290460.6010303@linkbit.com> <4B2908AF.9090705@linkbit.com> Date: Thu, 17 Dec 2009 12:03:46 +0300 Message-ID: From: Evgenij To: Igor Fedotov , sigtran@ietf.org Content-Type: multipart/alternative; boundary=001636499e499225f4047ae8e64a Subject: Re: [Sigtran] [M3UA] IPSP DE ASP Up Procedures X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 09:04:05 -0000 --001636499e499225f4047ae8e64a Content-Type: text/plain; charset=ISO-8859-1 Thanks Igor! The links is very useful for me. 2009/12/16 Igor Fedotov > Hi, Evgenij > > IMHO M3UA spec isn't clear in the issue. This was mentioned for example at > SIGTRAN PLUGTESTS in Moscow in 2007 ( > http://www.etsi.eu/WebSite/document/PlugtestsHistory/2007SIGTRAN/SIGTRAN_2007_REPORT.pdf, > day 5 report, issue 1). > > I'd say, the most preferable approach would be to use four messages in > Double Exchange, as described here: > > http://www.archivum.info/sigtran@ietf.org/2005-07/00030/RE:_%5BSigtran%5D_M3UA_:_2_or_4_messages_for_ASP-UP_in_IPSP_DE > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > > --001636499e499225f4047ae8e64a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Igor!

The links is very useful for me.


2009= /12/16 Igor Fedotov
=20
Hi, Evgenij

IMHO M3UA spec isn't clear in the issue. This was mentioned for example at SIGTRAN PLUGTESTS in Moscow in 2007 (=A0http://www.etsi.eu/WebSite/document/PlugtestsHistory/2007SIGTRA= N/SIGTRAN_2007_REPORT.pdf, day 5 report, issue 1).

I'd say, the most preferable approach would be to use four messages in Double Exchange, as described here:

_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran


--001636499e499225f4047ae8e64a-- From bidulock@openss7.org Thu Dec 17 06:45:37 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A133A6933 for ; Thu, 17 Dec 2009 06:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv1u0efB2hBP for ; Thu, 17 Dec 2009 06:45:36 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 3FEC63A690E for ; Thu, 17 Dec 2009 06:45:36 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:SK/ZrGkYyoaEQ4GfLD6jLVt7jWG2LyDK@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id nBHEjI92018372; Thu, 17 Dec 2009 07:45:18 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:ZqiQ3o8U+gHwv7ayS2Y5enE7CA+rRNBB@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id nBHEjHeX003810; Thu, 17 Dec 2009 07:45:17 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id nBHEj1aB003791; Thu, 17 Dec 2009 07:45:01 -0700 Date: Thu, 17 Dec 2009 07:45:00 -0700 From: "Brian F. G. Bidulock" To: Evgenij Message-ID: <20091217144500.GA3526@openss7.org> Mail-Followup-To: Evgenij , Igor Fedotov , sigtran@ietf.org References: <4B290460.6010303@linkbit.com> <4B2908AF.9090705@linkbit.com> 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.13 (2006-08-11) Cc: sigtran@ietf.org, Igor Fedotov Subject: Re: [Sigtran] [M3UA] IPSP DE ASP Up Procedures X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 17 Dec 2009 14:45:38 -0000 Evgenij, It was agreed to make all four ASP UP/Ack message mandatory for both SUA and M3UA in the thread "RE: M3UA also affected : [SUA issue 17] IPSP cases." from August 28, 2001. It is the passages mentioning two as optional that are incorrect (a holdover from drafts previous to August 2001). --brian Evgenij wrote: (Thu, 17 Dec 2009 12:03:46) > > Thanks Igor! > The links is very useful for me. > > 2009/12/16 Igor Fedotov > > Hi, Evgenij > IMHO M3UA spec isn't clear in the issue. This was mentioned for > example at SIGTRAN PLUGTESTS in Moscow in 2007 > ( [1]http://www.etsi.eu/WebSite/document/PlugtestsHistory/2007SIGTRAN/ > SIGTRAN_2007_REPORT.pdf, day 5 report, issue 1). > I'd say, the most preferable approach would be to use four messages in > Double Exchange, as described here: > [2]http://www.archivum.info/sigtran@ietf.org/2005-07/00030/RE:_%5BSigt > ran%5D_M3UA_:_2_or_4_messages_for_ASP-UP_in_IPSP_DE > > _______________________________________________ > Sigtran mailing list > [3]Sigtran@ietf.org > [4]https://www.ietf.org/mailman/listinfo/sigtran > > References > > 1. http://www.etsi.eu/WebSite/document/PlugtestsHistory/2007SIGTRAN/SIGTRAN_2007_REPORT.pdf > 2. http://www.archivum.info/sigtran@ietf.org/2005-07/00030/RE:_%5BSigtran%5D_M3UA_:_2_or_4_messages_for_ASP-UP_in_IPSP_DE > 3. mailto:Sigtran@ietf.org > 4. https://www.ietf.org/mailman/listinfo/sigtran > _______________________________________________ > 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 venkat.bv@gmail.com Mon Dec 21 02:57:27 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89DA93A69CD for ; Mon, 21 Dec 2009 02:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K17cggCF-fyk for ; Mon, 21 Dec 2009 02:57:26 -0800 (PST) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id B0BC73A6828 for ; Mon, 21 Dec 2009 02:57:26 -0800 (PST) Received: by vws31 with SMTP id 31so1631545vws.29 for ; Mon, 21 Dec 2009 02:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=2UgUfxWC4Zrv28CvQOmzL9zAPon6z7zy9e9ikQGWQ7g=; b=DSJ/NNKfLG3cctHs0KF4ukNrMypQbo3M0JSOKd/9xHF9QK7bz8gbEav6svcw68cBem gU0z54rpWGxZgCGLePxqCDGOdx3yADt6HSJMxLQ2pFv4p8q6FFAylqtva1NdJg8sifka f1PA0ZJBQgw3yVali6NVMWFCBCavEb+3wgiI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VgerZQHvbLkcpHzqjz8i4u+n2ERklsIgzYv44aaUOQThESN9IhQRt0RaFWCVBM0MFC 3G8iLJSUrVWW2PAil5rcnX7GUOX1nghSpKZFcJyXo0Y466x2jP+LyqMOZfDNryy036Uk rdam4582Se7LPGglRAsZRne/LbFxdjpftOt3k= MIME-Version: 1.0 Received: by 10.220.126.165 with SMTP id c37mr6755135vcs.76.1261393027068; Mon, 21 Dec 2009 02:57:07 -0800 (PST) Date: Mon, 21 Dec 2009 16:27:07 +0530 Message-ID: From: Siva To: bidulock@openss7.org, Evgenij , Igor Fedotov , sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016e68f9b634cfc2f047b3af380 Subject: [Sigtran] ASN.1 syntax files for ANSI MAP messages X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 10:57:27 -0000 --0016e68f9b634cfc2f047b3af380 Content-Type: text/plain; charset=ISO-8859-1 Hello, If you have *ASN.1 syntax definition files* for *ANSI TCAP* and *ANSI MAP*messages, can you please send it to me? Thanks a lot for your help in Advance! Thanks & Regards, Venkat --0016e68f9b634cfc2f047b3af380 Content-Type: text/html; charset=ISO-8859-1 Hello,
If you have ASN.1 syntax definition files for ANSI TCAP and ANSI MAP messages, can you please send it to me?

Thanks a lot for your help in Advance!

Thanks & Regards,
Venkat
--0016e68f9b634cfc2f047b3af380-- From deepak.gunjal@aricent.com Tue Dec 22 10:50:49 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040FB3A6833 for ; Tue, 22 Dec 2009 10:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KGhdmEyVuTO for ; Tue, 22 Dec 2009 10:50:48 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by core3.amsl.com (Postfix) with ESMTP id 65E783A6825 for ; Tue, 22 Dec 2009 10:50:47 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id AA60336B50 for ; Wed, 23 Dec 2009 00:17:51 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 9524136B4C for ; Wed, 23 Dec 2009 00:17:51 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Wed, 23 Dec 2009 00:20:29 +0530 From: Deepak Gunjal To: "sigtran@ietf.org" Date: Wed, 23 Dec 2009 00:20:28 +0530 Thread-Topic: What are the chances that SG may not send Notify messages to AS (M3UA) Thread-Index: AQHKgzehXPAYB76amEezIp2KJqItdA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BDF44534797E3E46B55F3D12DE0C4BC40338960DCAGUREXMB01ASIA_" MIME-Version: 1.0 Subject: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 18:50:49 -0000 --_000_BDF44534797E3E46B55F3D12DE0C4BC40338960DCAGUREXMB01ASIA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I want to know that if SG implementations can opt to not send the Notify me= ssage for AS state change? As per the RFC 4666 sending Notify messages is a SHOULD clause which recomm= ends but not mandate the sending of Notify message unless there are very st= rong reason to not implement recommended behavior. In such cases the ASP implementations will be required to shield themselves= from such implementations. Although I haven't faced such issue till now bu= t I heard that one of the leading M3UA testing tool vendor has told that th= eir implementation does not send Notify or it can send Notify may be after = AS has gone through two or more state changes. Please suggest. Thanks and Regards Deepak ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_BDF44534797E3E46B55F3D12DE0C4BC40338960DCAGUREXMB01ASIA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I want to know that if SG implementations= can opt to not send the Notify message for AS state change?

As per the RFC 4666 sending Notify messag= es is a SHOULD clause which recommends but not mandate the sending of Notif= y message unless there are very strong reason to not implement recommended = behavior.

 

In such cases the ASP implementations wil= l be required to shield themselves from such implementations. Although I ha= ven't faced such issue till now but I heard that one of the leading M3UA te= sting tool vendor has told that their implementation does not send Notify or it can send Notify may be after AS = has gone through two or more state changes.

 

Please suggest.

 

Thanks and Regards

Deepak



"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
--_000_BDF44534797E3E46B55F3D12DE0C4BC40338960DCAGUREXMB01ASIA_-- From cbenson@adax.com Tue Dec 22 11:42:36 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43BB43A69AF for ; Tue, 22 Dec 2009 11:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbY6Ag7bDu2x for ; Tue, 22 Dec 2009 11:42:35 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id 50DFB3A6895 for ; Tue, 22 Dec 2009 11:42:35 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 79E9F120AFE; Tue, 22 Dec 2009 11:42:18 -0800 (PST) Received: by adax (Postfix, from userid 243) id 40AE08E52B; Tue, 22 Dec 2009 11:43:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 364FB8E52A; Tue, 22 Dec 2009 11:43:19 -0800 (PST) Date: Tue, 22 Dec 2009 11:43:19 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Deepak Gunjal In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 19:42:36 -0000 Deepak, I won't estimate "chances" numerically (!), but I'd like to point out that the Notify message concerning AS state change is NOT optional but IS compulsory. Section 4.3.4.5 "Notify Procedures" of RFC 4666 (same as RFC 3332 here) states (in part): A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. I don't see anything optional about this, even in IPSP mode described subsequently. Those first three words "A Notify message" unambiguously refer to the M3UA encoding "on the wire" from the SGP side. Indications that are internally generated (at the ASP) are distinguished by the name M-NOTIFY, in the second sentence above. Perhaps the implementation which you dispute is referring to other forms of the Notify message (such as Status Type "Other"), or perhaps there's a difference reagrding the time interval over which an AS is in the AS_PENDING state. I presume that this last (PENDING) mechanism is to stop unecessary oscillations between AS states as one ASP goes INACTIVE and another ACTIVE in raspid succession. But after a configurable time interval, the AS must leave the AS-PENDING state, and a NOTIFY must be generated by the SG side, if the longer term AS state has changed. Good luck with getting those "chances" down to zero. Chris Benson. On Wed, 23 Dec 2009, Deepak Gunjal wrote: >> Date: Wed, 23 Dec 2009 00:20:28 +0530 >> From: Deepak Gunjal >> To: "sigtran@ietf.org" >> Subject: [Sigtran] What are the chances that SG may not send Notify messages >> to AS (M3UA) >> >> Hi, >> >> >> >> I want to know that if SG implementations can opt to not send the Notify message for AS state change? >> >> As per the RFC 4666 sending Notify messages is a SHOULD clause which recommends but not mandate the sending of Notify message unless there are very strong reason to not implement recommended behavior. >> >> >> >> In such cases the ASP implementations will be required to shield themselves from such implementations. Although I haven't faced such issue till now but I heard that one of the leading M3UA testing tool vendor has told that their implementation does not send Notify or it can send Notify may be after AS has gone through two or more state changes. >> >> >> >> Please suggest. >> >> >> >> Thanks and Regards >> >> Deepak >> >> ________________________________ >> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." >> From deepak.gunjal@aricent.com Tue Dec 22 23:09:46 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4BA3A695D for ; Tue, 22 Dec 2009 23:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXSpaapvzQp1 for ; Tue, 22 Dec 2009 23:09:39 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 82A9D3A695C for ; Tue, 22 Dec 2009 23:09:36 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id B9ABB36B59; Wed, 23 Dec 2009 12:36:39 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id A398436B4E; Wed, 23 Dec 2009 12:36:39 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Wed, 23 Dec 2009 12:39:17 +0530 From: Deepak Gunjal To: Chris Benson Date: Wed, 23 Dec 2009 12:39:16 +0530 Thread-Topic: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) Thread-Index: AcqDPuKS5aiZROMcSmKWxlU2wRVqWgAXw5SQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BDF44534797E3E46B55F3D12DE0C4BC40338708AF1GUREXMB01ASIA_" MIME-Version: 1.0 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 07:09:47 -0000 --_000_BDF44534797E3E46B55F3D12DE0C4BC40338708AF1GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, Thanks for your detailed reply. From the same section, 2nd paragraph "When = an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular AS, a Notify= message SHOULD be sent, by the ASP-UP receptor, after sending the ASP-UP-= ACK, in order to inform the ASP of the current AS state." Now as per the above statement when an ASP moves from ASP-DOWN to ASP-INACT= IVE it seems that the Notify could be optional (SHOULD clause) and this is = the cause of my doubt which a bit is an contradictory statement what has be= en written in the beginning of this section 4.3.4.5. Can you please confirm if there is some misinterpretation from my side? Thanks Deepak -----Original Message----- From: Chris Benson [mailto:cbenson@adax.com] Sent: Wednesday, December 23, 2009 1:13 AM To: Deepak Gunjal Cc: sigtran@ietf.org Subject: Re: [Sigtran] What are the chances that SG may not send Notify mes= sages to AS (M3UA) Deepak, I won't estimate "chances" numerically (!), but I'd like to point out that the Notify message concerning AS state change is NOT optional but IS compulsory. Section 4.3.4.5 "Notify Procedures" of RFC 4666 (same as RFC 3332 here) states (in part): A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. I don't see anything optional about this, even in IPSP mode described subsequently. Those first three words "A Notify message" unambiguously refer to the M3UA encoding "on the wire" from the SGP side. Indications that are internally generated (at the ASP) are distinguished by the name M-NOTIFY, in the second sentence above. Perhaps the implementation which you dispute is referring to other forms of the Notify message (such as Status Type "Other"), or perhaps there's a difference reagrding the time interval over which an AS is in the AS_PENDING state. I presume that this last (PENDING) mechanism is to stop unecessary oscillations between AS states as one ASP goes INACTIVE and another ACTIVE in raspid succession. But after a configurable time interval, the AS must leave the AS-PENDING state, and a NOTIFY must be generated by the SG side, if the longer term AS state has changed. Good luck with getting those "chances" down to zero. Chris Benson. On Wed, 23 Dec 2009, Deepak Gunjal wrote: >> Date: Wed, 23 Dec 2009 00:20:28 +0530 >> From: Deepak Gunjal >> To: "sigtran@ietf.org" >> Subject: [Sigtran] What are the chances that SG may not send Notify mes= sages >> to AS (M3UA) >> >> Hi, >> >> >> >> I want to know that if SG implementations can opt to not send the Notif= y message for AS state change? >> >> As per the RFC 4666 sending Notify messages is a SHOULD clause which re= commends but not mandate the sending of Notify message unless there are ver= y strong reason to not implement recommended behavior. >> >> >> >> In such cases the ASP implementations will be required to shield themse= lves from such implementations. Although I haven't faced such issue till no= w but I heard that one of the leading M3UA testing tool vendor has told tha= t their implementation does not send Notify or it can send Notify may be af= ter AS has gone through two or more state changes. >> >> >> >> Please suggest. >> >> >> >> Thanks and Regards >> >> Deepak >> >> ________________________________ >> "DISCLAIMER: This message is proprietary to Aricent and is intended sol= ely for the use of the individual to whom it is addressed. It may contain p= rivileged or confidential information and should not be circulated or used = for any purpose other than for what it is intended. If you have received th= is message in error, please notify the originator immediately. If you are n= ot the intended recipient, you are notified that you are strictly prohibite= d from using, copying, altering, or disclosing the contents of this message= . Aricent accepts no responsibility for loss or damage arising from the use= of the information transmitted by this email including damage from virus." >> ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_BDF44534797E3E46B55F3D12DE0C4BC40338708AF1GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chris,

 

Thanks for your detailed reply. From the same section, 2nd para=
graph “When an ASP moves from ASP-DOWN to ASP-INACTIVE within a parti=
cular AS, a Notify message SHOULD be sent, by the ASP-UP receptor, after  sending the ASP-UP-ACK, =
in order to inform the ASP of the current AS state.”
 

Now as per the above statement when an ASP moves from ASP-DOWN to A= SP-INACTIVE it seems that the Notify could be optional (SHOULD clause) and = this is the cause of my doubt which a bit is an contradictory statement what has been written in t= he beginning of this section 4.3.4.5.

 

Can you please confirm if there is some misinterpretation from my s= ide?

 

Thanks

Deepak

 

-----Original Message-----
From: Chris Benson [mailto:cbenson@adax.com]
Sent: Wednesday, December 23, 2009 1:13 AM
To: Deepak Gunjal
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] What are the chances that SG may not send Notify mes= sages to AS (M3UA)

 

Deepak,

 

I won't estimate "chances" numerically (!), but I'd like<= o:p>

to point out that the Notify message concerning AS state=

change is NOT optional but IS compulsory.<= /p>

 

Section 4.3.4.5 "Notify Procedures" of RFC 4666 (same as = RFC

3332 here) states (in part):

 

   A Notify message reflecting a change in the AS state M= UST

   be sent to all ASPs in the AS, except those in the ASP= -DOWN

   state, with appropriate Status Information and any ASP

   Identifier of the failed ASP.  At the ASP, Layer = Management

   is informed with an M-NOTIFY indication primitive.

 

I don't see anything optional about this, even in IPSP mode

described subsequently.  Those first three words "A Notif= y

message" unambiguously refer to the M3UA encoding "on the= wire"

from the SGP side.  Indications that are internally generated

(at the ASP) are distinguished by the name M-NOTIFY, in the

second sentence above.

 

Perhaps the implementation which you dispute is referring

to other forms of the Notify message (such as Status Type

"Other"), or perhaps there's a difference reagrding the

time interval over which an AS is in the AS_PENDING state.

I presume that this last (PENDING) mechanism is to stop<= /span>

unecessary oscillations between AS states as one ASP goes

INACTIVE and another ACTIVE in raspid succession. But

after a configurable time interval, the AS must leave

the AS-PENDING state, and a NOTIFY must be generated

by the SG side, if the longer term AS state has changed.=

 

Good luck with getting those "chances" down to zero.=

 

Chris Benson.

 

On Wed, 23 Dec 2009, Deepak Gunjal wrote:<= /p>

 

>>  Date: Wed, 23 Dec 2009 00:20:28 +0530=

>>  From: Deepak Gunjal <deepak.gunjal@aricent.com>= ;

>>  To: "sigtran@ietf.org" <sigtran@ietf.or= g>

>>  Subject: [Sigtran] What are the chances that SG may = not send Notify messages

>>       to AS (M3UA)

>> 

>>  Hi,

>> 

>> 

>> 

>>  I want to know that if SG implementations can opt to= not send the Notify message for AS state change?<= /p>

>> 

>>  As per the RFC 4666 sending Notify messages is a SHO= ULD clause which recommends but not mandate the sending of Notify message u= nless there are very strong reason to not implement recommended behavior.

>> 

>> 

>> 

>>  In such cases the ASP implementations will be requir= ed to shield themselves from such implementations. Although I haven't faced= such issue till now but I heard that one of the leading M3UA testing tool vendor has told that their implementa= tion does not send Notify or it can send Notify may be after AS has gone th= rough two or more state changes.

>> 

>> 

>> 

>>  Please suggest.

>> 

>> 

>> 

>>  Thanks and Regards

>> 

>>  Deepak

>> 

>>  ________________________________

>>  "DISCLAIMER: This message is proprietary to Ari= cent and is intended solely for the use of the individual to whom it is add= ressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other tha= n for what it is intended. If you have received this message in error, plea= se notify the originator immediately. If you are not the intended recipient= , you are notified that you are strictly prohibited from using, copying, altering, or disclosing the conte= nts of this message. Aricent accepts no responsibility for loss or damage a= rising from the use of the information transmitted by this email including = damage from virus."

>> 



"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
--_000_BDF44534797E3E46B55F3D12DE0C4BC40338708AF1GUREXMB01ASIA_-- From bidulock@openss7.org Wed Dec 23 05:42:57 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A36B3A6808 for ; Wed, 23 Dec 2009 05:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIR9U6mMhRGq for ; Wed, 23 Dec 2009 05:42:56 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 84DD53A677D for ; Wed, 23 Dec 2009 05:42:56 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:XK5iohCQ6gFIn0x79bK585H2wI8gPCc/@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id nBNDgQhW031817; Wed, 23 Dec 2009 06:42:27 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:5t9aJ+X+mu/AHbJ7uL8nOf5KbyqNIvGf@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id nBNDgQBE029081; Wed, 23 Dec 2009 06:42:26 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id nBNDgQfT029079; Wed, 23 Dec 2009 06:42:26 -0700 Date: Wed, 23 Dec 2009 06:42:26 -0700 From: "Brian F. G. Bidulock" To: Deepak Gunjal Message-ID: <20091223134225.GA25127@openss7.org> Mail-Followup-To: Deepak Gunjal , Chris Benson , "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.13 (2006-08-11) Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 23 Dec 2009 13:42:57 -0000 Deepak, AS state is maintained on an SG-wide basis. That is, there is one coordinated AS state that is the same for all SGP that make up an SG. When this AS state changes, each ASP that is not in the ASP-Down state (for some SGP) must be sent a notify message informing the ASP of the change of AS state. When an ASP moves from the ASP-DOWN to ASP-INACTIVE state within an AS, the SG should inform the ASP of the coordinated AS state provided that it hasn't done so already. It is not optional. It is recommended and you need a very good reason not to do so in each circumstance. What are some reasons for not sending a Notify message when an ASP-DOWN to ASP-INACTIVE transition occurs: 1. ASP-DOWN to ASP-INACTIVE transitions are per-SGP. AS state is coordinated SG-wide. The SG need only inform the ASP of AS state once (not once for each SGP in the SG). 2. The ASP-DOWN to ASP-INACTIVE transition causes the AS state to move from AS Down to AS Inactive. In this case a Notify message must be send to signal the AS state transition and a separate message to inform the ASP of the current state is unnecessary. I can't think of any more of the top of my head. So what can you do if you are faced with a broken SG implementation that ignores this recommendation? First, tell them to fix it or present the very good reasons why they are not sending it. Then, if you are forced to deal with such a broken implementation, consider the following: If the ASP-DOWN to ASP-INACTIVE state transition causes the AS to change state from AS-DOWN to AS-INACTIVE then the Notify message MUST be sent per 4.3.4.5. Therefore, if the ASP does not receive a Notify message, the SG is either terribly broken or the AS was not in the AS-DOWN state previously: that is, the ASP is not the first ASP in the AS. This is actually a lot of information. If no Notify is received, there exists some other ASP in the AS that is aware of the SG's view of AS state. ASPs in an AS need to coordinate themselves. The ASP might obtain the AS state from this other ASP. I actually brought this passage up as a last call issue on M3UAv02 (where is was added). The issue was not resolved at last call. In fact there were many issues brought up at last call that were not resolved. The issue was that the ASP-DOWN to ASP-INACTIVE state transition is not necessarily due to the ASP Up procedure (it can also occur as a result of the Registration procedure). Therefore, mention of the "ASP-UP receptor" is misleading. When an ASP transitions from the ASP-DOWN to ASP-INACTIVE state for the first time in a particular AS (for whatever reason) the ASP should be informed by the SG of the current AS state with a Notify message, unless it has already or will otherwise be notified of the AS state. Can you think of any good reason not to do that in a given circumstance? The danger of an SG not sending this Notify message is that the ASP might sit around waiting for one. This could be a bad thing if the current AS state happens to be AS-ACTIVE (with insufficient ASPs active), AS-PENDING or AS-INACTIVE. --brian Deepak Gunjal wrote: (Wed, 23 Dec 2009 12:39:16) > > Hi Chris, > > > Thanks for your detailed reply. From the same section, 2^nd > paragraph "When an ASP moves from ASP-DOWN to ASP-INACTIVE within > a particular AS, a Notify message SHOULD be sent, by the ASP-UP > receptor, after sending the ASP-UP-ACK, in ord er to inform the > ASP of the current AS state." > > > Now as per the above statement when an ASP moves from ASP-DOWN > to ASP-INACTIVE it seems that the Notify could be optional > (SHOULD clause) and this is the cause of my doubt which a bit > is an contradictory statement what has been written in the > beginning of this section 4.3.4.5. > > > Can you please confirm if there is some misinterpretation from > my side? > > > Thanks > > Deepak > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From deepak.gunjal@aricent.com Wed Dec 23 06:03:18 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963D83A63D3 for ; Wed, 23 Dec 2009 06:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vye+lVEZNZDO for ; Wed, 23 Dec 2009 06:03:09 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 8EE153A6808 for ; Wed, 23 Dec 2009 06:03:07 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id D2C8536B76; Wed, 23 Dec 2009 19:30:08 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id BC3FE36B74; Wed, 23 Dec 2009 19:30:08 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Wed, 23 Dec 2009 19:32:47 +0530 From: Deepak Gunjal To: "bidulock@openss7.org" Date: Wed, 23 Dec 2009 19:32:45 +0530 Thread-Topic: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) Thread-Index: AcqD1crWjy0okM5iS6ybgMyG9abU6gAANkuQ Message-ID: References: <20091223134225.GA25127@openss7.org> In-Reply-To: <20091223134225.GA25127@openss7.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BDF44534797E3E46B55F3D12DE0C4BC40338708E90GUREXMB01ASIA_" MIME-Version: 1.0 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 14:03:18 -0000 --_000_BDF44534797E3E46B55F3D12DE0C4BC40338708E90GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, Thanks a lot for the detailed explanation. On the first instance reading RF= C 4666, I thought that the Notify is must and we implemented the ASP based = on it. It all worked fine until one day while using a tool from leading ven= dor we encountered this issue. We discussed this issue with the vendor and he told us that it's not a must= condition and they may send the Notify after two or more state changes. Al= so as per their comment they have seen "MANY" implementation which do not s= ends Notify which is itself very strange as we have also tested our system = with two SG implementation which do sends Notify messages as expected. But if such faulty implementation is present it will block our ASP from sen= ding ASP-ACTIVE as we always wait for Notify (AS-INACTIVE) and will lead us= to a deadlock situation. Also in our simulated environment no other ASP wa= s active and hence state at AS should have been AS-DOWN and no other state = should have been possible. While going through the RFC in section 4.3.4.5, I found bit contradictory o= r would say confusing statements and where I could interpret Notify in some= circumstances could be optional but as per your explanation I can clearly = see that it is a must condition. Right now I don't think very good reason why SG may take a deviation but wi= ll surely ask our vendor to provide some good reason for their implementati= on. Thanks a lot. Regards Deepak -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Wednesday, December 23, 2009 7:12 PM To: Deepak Gunjal Cc: Chris Benson; sigtran@ietf.org Subject: Re: [Sigtran] What are the chances that SG may not send Notify mes= sages to AS (M3UA) Deepak, AS state is maintained on an SG-wide basis. That is, there is one coordinated AS state that is the same for all SGP that make up an SG. When this AS state changes, each ASP that is not in the ASP-Down state (for some SGP) must be sent a notify message informing the ASP of the change of AS state. When an ASP moves from the ASP-DOWN to ASP-INACTIVE state within an AS, the SG should inform the ASP of the coordinated AS state provided that it hasn't done so already. It is not optional. It is recommended and you need a very good reason not to do so in each circumstance. What are some reasons for not sending a Notify message when an ASP-DOWN to ASP-INACTIVE transition occurs: 1. ASP-DOWN to ASP-INACTIVE transitions are per-SGP. AS state is coordinated SG-wide. The SG need only inform the ASP of AS state once (not once for each SGP in the SG). 2. The ASP-DOWN to ASP-INACTIVE transition causes the AS state to move from AS Down to AS Inactive. In this case a Notify message must be send to signal the AS state transition and a separate message to inform the ASP of the current state is unnecessary. I can't think of any more of the top of my head. So what can you do if you are faced with a broken SG implementation that ignores this recommendation? First, tell them to fix it or present the very good reasons why they are not sending it. Then, if you are forced to deal with such a broken implementation, consider the following: If the ASP-DOWN to ASP-INACTIVE state transition causes the AS to change state from AS-DOWN to AS-INACTIVE then the Notify message MUST be sent per 4.3.4.5. Therefore, if the ASP does not receive a Notify message, the SG is either terribly broken or the AS was not in the AS-DOWN state previously: that is, the ASP is not the first ASP in the AS. This is actually a lot of information. If no Notify is received, there exists some other ASP in the AS that is aware of the SG's view of AS state. ASPs in an AS need to coordinate themselves. The ASP might obtain the AS state from this other ASP. I actually brought this passage up as a last call issue on M3UAv02 (where is was added). The issue was not resolved at last call. In fact there were many issues brought up at last call that were not resolved. The issue was that the ASP-DOWN to ASP-INACTIVE state transition is not necessarily due to the ASP Up procedure (it can also occur as a result of the Registration procedure). Therefore, mention of the "ASP-UP receptor" is misleading. When an ASP transitions from the ASP-DOWN to ASP-INACTIVE state for the first time in a particular AS (for whatever reason) the ASP should be informed by the SG of the current AS state with a Notify message, unless it has already or will otherwise be notified of the AS state. Can you think of any good reason not to do that in a given circumstance? The danger of an SG not sending this Notify message is that the ASP might sit around waiting for one. This could be a bad thing if the current AS state happens to be AS-ACTIVE (with insufficient ASPs active), AS-PENDING or AS-INACTIVE. --brian Deepak Gunjal wrote: (Wed, 23 Dec 2009 12:39:16) > > Hi Chris, > > > Thanks for your detailed reply. From the same section, 2^nd > paragraph "When an ASP moves from ASP-DOWN to ASP-INACTIVE within > a particular AS, a Notify message SHOULD be sent, by the ASP-UP > receptor, after sending the ASP-UP-ACK, in ord er to inform the > ASP of the current AS state." > > > Now as per the above statement when an ASP moves from ASP-DOWN > to ASP-INACTIVE it seems that the Notify could be optional > (SHOULD clause) and this is the cause of my doubt which a bit > is an contradictory statement what has been written in the > beginning of this section 4.3.4.5. > > > Can you please confirm if there is some misinterpretation from > my side? > > > Thanks > > Deepak > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_BDF44534797E3E46B55F3D12DE0C4BC40338708E90GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian,

 

Thanks a lot for the detailed explanation. On the first instance re= ading RFC 4666, I thought that the Notify is must and we implemented the AS= P based on it. It all worked fine until one day while using a tool from leading vendor we encountered t= his issue.

 

We discussed this issue with the vendor and he told us that it̵= 7;s not a must condition and they may send the Notify after two or more sta= te changes. Also as per their comment they have seen “MANY” implementation which do not send= s Notify which is itself very strange as we have also tested our system wit= h two SG implementation which do sends Notify messages as expected.

 

But if such faulty implementation is present it will block our ASP = from sending ASP-ACTIVE as we always wait for Notify (AS-INACTIVE) and will= lead us to a deadlock situation. Also in our simulated environment no other ASP was active and hence state = at AS should have been AS-DOWN and no other state should have been possible= .

 

While going through the RFC in section 4.3.4.5, I found bit contrad= ictory or would say confusing statements and where I could interpret Notify= in some circumstances could be optional but as per your explanation I can clearly see that it is a mus= t condition.

 

Right now I don’t think very good reason why SG may take a de= viation but will surely ask our vendor to provide some good reason for thei= r implementation.

 

Thanks a lot.

 

Regards

Deepak

 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]
Sent: Wednesday, December 23, 2009 7:12 PM
To: Deepak Gunjal
Cc: Chris Benson; sigtran@ietf.org
Subject: Re: [Sigtran] What are the chances that SG may not send Notify mes= sages to AS (M3UA)

 

Deepak,

 

AS state is maintained on an SG-wide basis.  That is, there is= one

coordinated AS state that is the same for all SGP that make up an

SG.  When this AS state changes, each ASP that is not in the

ASP-Down state (for some SGP) must be sent a notify message

informing the ASP of the change of AS state.

 

When an ASP moves from the ASP-DOWN to ASP-INACTIVE state within an=

AS, the SG should inform the ASP of the coordinated AS state

provided that it hasn't done so already.  It is not optional.&= nbsp; It is

recommended and you need a very good reason not to do so in each

circumstance.

 

What are some reasons for not sending a Notify message when an=

ASP-DOWN to ASP-INACTIVE transition occurs:

 

1. ASP-DOWN to ASP-INACTIVE transitions are per-SGP.  AS state= is

   coordinated SG-wide.  The SG need only inform the= ASP of AS state

   once (not once for each SGP in the SG).

 

2. The ASP-DOWN to ASP-INACTIVE transition causes the AS state to

   move from AS Down to AS Inactive.  In this case a= Notify message

   must be send to signal the AS state transition and a s= eparate

   message to inform the ASP of the current state is unne= cessary.

 

I can't think of any more of the top of my head.<= /font>

 

So what can you do if you are faced with a broken SG implementation=

that ignores this recommendation?  First, tell them to fix it = or

present the very good reasons why they are not sending it.  Th= en, if

you are forced to deal with such a broken implementation, consider<= o:p>

the following:

 

If the ASP-DOWN to ASP-INACTIVE state transition causes the AS to

change state from AS-DOWN to AS-INACTIVE then the Notify message

MUST be sent per 4.3.4.5.  Therefore, if the ASP does not rece= ive a

Notify message, the SG is either terribly broken or the AS was not<= o:p>

in the AS-DOWN state previously: that is, the ASP is not the first<= o:p>

ASP in the AS.  This is actually a lot of information.  I= f no Notify

is received, there exists some other ASP in the AS that is aware of=

the SG's view of AS state.  ASPs in an AS need to coordinate

themselves.  The ASP might obtain the AS state from this other= ASP.

 

I actually brought this passage up as a last call issue on M3UAv02<= o:p>

(where is was added).  The issue was not resolved at last call= .  In

fact there were many issues brought up at last call that were not

resolved.  The issue was that the ASP-DOWN to ASP-INACTIVE sta= te

transition is not necessarily due to the ASP Up procedure  (it= can

also occur as a result of the Registration procedure).  Theref= ore,

mention of the "ASP-UP receptor" is misleading.

 

When an ASP transitions from the ASP-DOWN to ASP-INACTIVE state for=

the first time in a particular AS (for whatever reason) the ASP

should be informed by the SG of the current AS state with a Notify<= o:p>

message, unless it has already or will otherwise be notified of the=

AS state.

 

Can you think of any good reason not to do that in a given

circumstance?

 

The danger of an SG not sending this Notify message is that the

ASP might sit around waiting for one.  This could be a bad thi= ng

if the current AS state happens to be AS-ACTIVE (with insufficient<= o:p>

ASPs active), AS-PENDING or AS-INACTIVE.

 

--brian

 

 

 

 

Deepak Gunjal wrote:        = ;            &n= bsp;    (Wed, 23 Dec 2009 12:39:16)=

>

>    Hi Chris,

>

>

> Thanks for your detailed reply. From the same section, 2^nd

> paragraph "When an ASP moves from ASP-DOWN to ASP-INACTIV= E within

> a particular AS, a Notify message SHOULD be sent, by the ASP-U= P

> receptor, after  sending the ASP-UP-ACK, in ord er to inf= orm the

> ASP of the current AS state."

>

>    Now as per the above statement when an ASP m= oves from ASP-DOWN

>    to ASP-INACTIVE it seems that the Notify cou= ld be optional

>    (SHOULD clause) and this is the cause of my = doubt which a bit

>    is an contradictory statement what has been = written in the

>    beginning of this section 4.3.4.5.

>

>

>    Can you please confirm if there is some misi= nterpretation from

>    my side?

>

>

>    Thanks

>

>    Deepak

>

 

 

--

Brian F. G. Bidulock

bidulock@openss7.org

http://www.openss7.org/



"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
--_000_BDF44534797E3E46B55F3D12DE0C4BC40338708E90GUREXMB01ASIA_-- From David.Laight@ACULAB.COM Wed Dec 23 06:10:20 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1EEC3A68AC for ; Wed, 23 Dec 2009 06:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VivwyBAWbqsL for ; Wed, 23 Dec 2009 06:10:16 -0800 (PST) Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by core3.amsl.com (Postfix) with SMTP id 067A43A6892 for ; Wed, 23 Dec 2009 06:10:15 -0800 (PST) Received: (qmail 18033 invoked from network); 23 Dec 2009 14:09:57 -0000 Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 23 Dec 2009 14:09:57 -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 14164-09 for ; Wed, 23 Dec 2009 14:09:56 +0000 (GMT) Received: (qmail 18019 invoked by uid 599); 23 Dec 2009 14:09:56 -0000 Received: from unknown (HELO saturn2.Aculab.com) (10.202.163.6) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Wed, 23 Dec 2009 14:09:56 +0000 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_01CA83D9.99F67A3F" Date: Wed, 23 Dec 2009 14:09:54 -0000 Message-ID: <00D42150952F70458C66072322F7FE25026E807E@saturn2.aculab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) Thread-Index: AcqD1crWjy0okM5iS6ybgMyG9abU6gAANkuQAACgliA= From: "David Laight" To: "Deepak Gunjal" , X-ST-MF-Message-Resent: 12/23/2009 14:09 X-Virus-Scanned: by iCritical at mx0.aculab.com Cc: sigtran@ietf.org Subject: Re: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 14:10:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA83D9.99F67A3F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are many implementations that only conform to RFC3332, so don't send the initial NOTIFY of the current state - only sending NOTIFY when the ASP state actually changes. This tends to cause problems when there are multiple AS in an ASP (loadshare). If they are doing a test tools, they should be rejecting such systems as 'non conformant' ! David We discussed this issue with the vendor and he told us that it's not a must condition and they may send the Notify after two or more state changes. Also as per their comment they have seen "MANY" implementation which do not sends Notify which is itself very strange as we have also tested our system with two SG implementation which do sends Notify messages as expected. Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1= 1PT, UK Registration No: 1397386 (Wales) P Please consider the environment and don't print this e-mail unless you = really need to -- =0AScanned by iCritical.=0A ------_=_NextPart_001_01CA83D9.99F67A3F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= SPAN class=3D825400614-23122009>There are many implementations that only confo= rm to RFC3332, so don't send the initial NOTIFY
<= SPAN class=3D825400614-23122009>of the current state - only sending NOTIFY whe= n the ASP state actually changes.
<= SPAN class=3D825400614-23122009> 
<= SPAN class=3D825400614-23122009>This tends to cause problems when there are mu= ltiple AS in an ASP (loadshare).
<= SPAN class=3D825400614-23122009> 
<= SPAN class=3D825400614-23122009>If they are doing a test tools, they should be= rejecting such systems as 'non conformant' !
<= SPAN class=3D825400614-23122009> 
<= SPAN class=3D825400614-23122009>    David

We discussed this issue with the vendor and h= e told us that it’s not a must condition and they may send the Notify after= two or more state changes. Also as per their comment they have seen “MANYR= 21; implementation which do not sends Notify which is itself very strange as we have also = tested our system with two SG implementation which do sends Notify messages as= expected.

Registered Address Lake= side, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
 

P Please consider the environmen= t and don't print this e-mail unless you really need to


=

-- =0A
Scanned by iCritical.=0A


= ------_=_NextPart_001_01CA83D9.99F67A3F-- From deepak.gunjal@aricent.com Wed Dec 23 06:14:09 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6FE3A68DA for ; Wed, 23 Dec 2009 06:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSCMwQqvDQcS for ; Wed, 23 Dec 2009 06:14:04 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id A297E3A68C3 for ; Wed, 23 Dec 2009 06:14:03 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id D4BCE36B63; Wed, 23 Dec 2009 19:41:06 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id BE8E936B51; Wed, 23 Dec 2009 19:41:06 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Wed, 23 Dec 2009 19:43:45 +0530 From: Deepak Gunjal To: David Laight , "bidulock@openss7.org" Date: Wed, 23 Dec 2009 19:43:44 +0530 Thread-Topic: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) Thread-Index: AcqD1crWjy0okM5iS6ybgMyG9abU6gAANkuQAACgliAAACm7sA== Message-ID: References: <00D42150952F70458C66072322F7FE25026E807E@saturn2.aculab.com> In-Reply-To: <00D42150952F70458C66072322F7FE25026E807E@saturn2.aculab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BDF44534797E3E46B55F3D12DE0C4BC40338708E9FGUREXMB01ASIA_" MIME-Version: 1.0 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 14:14:09 -0000 --_000_BDF44534797E3E46B55F3D12DE0C4BC40338708E9FGUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That is correct. In this particular case even the AS was created with two A= SP in override mode and out of two ASP only one was coming active so I woul= d not expect that Notify will not come. ________________________________ From: David Laight [mailto:David.Laight@ACULAB.COM] Sent: Wednesday, December 23, 2009 7:40 PM To: Deepak Gunjal; bidulock@openss7.org Cc: sigtran@ietf.org Subject: RE: [Sigtran] What are the chances that SG may not send Notify mes= sages to AS (M3UA) There are many implementations that only conform to RFC3332, so don't send = the initial NOTIFY of the current state - only sending NOTIFY when the ASP state actually chan= ges. This tends to cause problems when there are multiple AS in an ASP (loadshar= e). If they are doing a test tools, they should be rejecting such systems as 'n= on conformant' ! David We discussed this issue with the vendor and he told us that it's not a must= condition and they may send the Notify after two or more state changes. Al= so as per their comment they have seen "MANY" implementation which do not s= ends Notify which is itself very strange as we have also tested our system = with two SG implementation which do sends Notify messages as expected. Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales) P Please consider the environment and don't print this e-mail unless you re= ally need to -- Scanned by iCritical. ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_BDF44534797E3E46B55F3D12DE0C4BC40338708E9FGUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That is correct. In this particular ca= se even the AS was created with two ASP in override mode and out of two ASP= only one was coming active so I would not expect that Notify will not come.<= /font>

 


From: Davi= d Laight [mailto:David.Laight@ACULAB.COM]
Sent: Wednesday, December 23= , 2009 7:40 PM
To: Deepak Gunjal; bidulock@= openss7.org
Cc: sigtran@ietf.org
Subject: RE: [Sigtran] What = are the chances that SG may not send Notify messages to AS (M3UA)

 

There are many implementations that on= ly conform to RFC3332, so don't send the initial NOTIFY<= /o:p>

of the current state - only sending NO= TIFY when the ASP state actually changes.

 

This tends to cause problems when ther= e are multiple AS in an ASP (loadshare).

 

If they are doing a test tools, they s= hould be rejecting such systems as 'non conformant' !

 

    David=

We discussed this issue with the vendor and he told us that it̵= 7;s not a must condition and they may send the Notify after two or more sta= te changes. Also as per their comment they have seen “MANY” implementation which do not send= s Notify which is itself very strange as we have also tested our system wit= h two SG implementation which do sends Notify messages as expected.

<= span style=3D"font-size:10.0pt;font-family:Tahoma;color:#484830">Registered= Address Lakeside, Bramley Road= , Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

<= span style=3D"font-size:10.0pt;font-family:Tahoma;color:#484830"> 

P Please consider the environment and don't print this e-mail un= less you really need to

 

--
Scanned by iCritical.

 



"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
--_000_BDF44534797E3E46B55F3D12DE0C4BC40338708E9FGUREXMB01ASIA_-- From cbenson@adax.com Mon Dec 28 15:53:04 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED223A68A4 for ; Mon, 28 Dec 2009 15:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-1.432, BAYES_40=-0.185, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIbHaEQYkwUu for ; Mon, 28 Dec 2009 15:53:03 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id AAAA83A67AB for ; Mon, 28 Dec 2009 15:53:03 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 6CC331209AD; Mon, 28 Dec 2009 15:52:43 -0800 (PST) Received: by adax (Postfix, from userid 243) id 954A38E52B; Mon, 28 Dec 2009 15:53:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 8BBC78E52A; Mon, 28 Dec 2009 15:53:59 -0800 (PST) Date: Mon, 28 Dec 2009 15:53:59 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Deepak Gunjal In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 23:53:05 -0000 Deepak, I think others have assisted you with compelling responses already. However, I don't believe that there is a contradiction in RFC 4666. If the AS state has changed there MUST be a Notify message. If an ASP is just joining the club of inactive ASPs, (and this fact alone doesn't change the AS state), then it SHOULD receive a Notify message, so it can get on-board with the current AS state. Brian and David have already commented before me why the SHOULD in my paragraph above "ought to have been" a MUST. The RFC might contradict useful practice, but I don't think it contradicts itself. The second paragraph would have been clearer with an "Otherwise" (i.e. not causing an AS state change). The scenario you describe (first of two ASPs moves from DOWN to INACTIVE) is such that the AS state changes, and so the first MUST above (first sentence of Section 4.3.4.5) applies, and that Notify is compulsory, even with this single AS state change. Note however, that the ASP can infer this from its receipt of an ASP-UP-Ack when in AS-DOWN state. With thanks, from Chris Benson. On Wed, 23 Dec 2009, Deepak Gunjal wrote: >> Date: Wed, 23 Dec 2009 12:39:16 +0530 >> From: Deepak Gunjal >> To: Chris Benson >> Cc: "sigtran@ietf.org" >> Subject: RE: [Sigtran] What are the chances that SG may not send Notify >> messages to AS (M3UA) >> >> Hi Chris, >> >> >> >> Thanks for your detailed reply. From the same section, 2nd paragraph "When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular AS, a Notify message SHOULD be sent, by the ASP-UP receptor, after sending the ASP-UP-ACK, in order to inform the ASP of the current AS state." >> >> >> >> Now as per the above statement when an ASP moves from ASP-DOWN to ASP-INACTIVE it seems that the Notify could be optional (SHOULD clause) and this is the cause of my doubt which a bit is an contradictory statement what has been written in the beginning of this section 4.3.4.5. >> >> >> >> Can you please confirm if there is some misinterpretation from my side? >> >> >> >> Thanks >> >> Deepak >> >> >> >> -----Original Message----- >> From: Chris Benson [mailto:cbenson@adax.com] >> Sent: Wednesday, December 23, 2009 1:13 AM >> To: Deepak Gunjal >> Cc: sigtran@ietf.org >> Subject: Re: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA) >> >> >> >> Deepak, >> >> >> >> I won't estimate "chances" numerically (!), but I'd like >> >> to point out that the Notify message concerning AS state >> >> change is NOT optional but IS compulsory. >> >> >> >> Section 4.3.4.5 "Notify Procedures" of RFC 4666 (same as RFC >> >> 3332 here) states (in part): >> >> >> >> A Notify message reflecting a change in the AS state MUST >> >> be sent to all ASPs in the AS, except those in the ASP-DOWN >> >> state, with appropriate Status Information and any ASP >> >> Identifier of the failed ASP. At the ASP, Layer Management >> >> is informed with an M-NOTIFY indication primitive. >> >> >> >> I don't see anything optional about this, even in IPSP mode >> >> described subsequently. Those first three words "A Notify >> >> message" unambiguously refer to the M3UA encoding "on the wire" >> >> from the SGP side. Indications that are internally generated >> >> (at the ASP) are distinguished by the name M-NOTIFY, in the >> >> second sentence above. >> >> >> >> Perhaps the implementation which you dispute is referring >> >> to other forms of the Notify message (such as Status Type >> >> "Other"), or perhaps there's a difference reagrding the >> >> time interval over which an AS is in the AS_PENDING state. >> >> I presume that this last (PENDING) mechanism is to stop >> >> unecessary oscillations between AS states as one ASP goes >> >> INACTIVE and another ACTIVE in raspid succession. But >> >> after a configurable time interval, the AS must leave >> >> the AS-PENDING state, and a NOTIFY must be generated >> >> by the SG side, if the longer term AS state has changed. >> >> >> >> Good luck with getting those "chances" down to zero. >> >> >> >> Chris Benson. >> >> >> >> On Wed, 23 Dec 2009, Deepak Gunjal wrote: >> >> >> >> >> Date: Wed, 23 Dec 2009 00:20:28 +0530 >> >> >> From: Deepak Gunjal >> >> >> To: "sigtran@ietf.org" >> >> >> Subject: [Sigtran] What are the chances that SG may not send Notify messages >> >> >> to AS (M3UA) >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> >> >> I want to know that if SG implementations can opt to not send the Notify message for AS state change? >> >> >> >> >> >> As per the RFC 4666 sending Notify messages is a SHOULD clause which recommends but not mandate the sending of Notify message unless there are very strong reason to not implement recommended behavior. >> >> >> >> >> >> >> >> >> >> >> >> In such cases the ASP implementations will be required to shield themselves from such implementations. Although I haven't faced such issue till now but I heard that one of the leading M3UA testing tool vendor has told that their implementation does not send Notify or it can send Notify may be after AS has gone through two or more state changes. >> >> >> >> >> >> >> >> >> >> >> >> Please suggest. >> >> >> >> >> >> >> >> >> >> >> >> Thanks and Regards >> >> >> >> >> >> Deepak >> >> >> >> >> >> ________________________________ >> >> >> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." >> >> >> >> >> ________________________________ >> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." >>