From santhana@huawei.com Wed Mar 3 06:06:14 2010 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 0D0E128C37A for ; Wed, 3 Mar 2010 06:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_74=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 U1vNC1EtreNw for ; Wed, 3 Mar 2010 06:06:13 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 760FB3A863F for ; Wed, 3 Mar 2010 06:06:12 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYP00M91LU2WU@szxga03-in.huawei.com> for sigtran@ietf.org; Wed, 03 Mar 2010 22:06:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYP004R3LU28D@szxga03-in.huawei.com> for sigtran@ietf.org; Wed, 03 Mar 2010 22:06:02 +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 <0KYP003TSLU12S@szxml04-in.huawei.com> for sigtran@ietf.org; Wed, 03 Mar 2010 22:06:02 +0800 (CST) Date: Wed, 03 Mar 2010 19:26:09 +0530 From: Santhana To: sigtran@ietf.org Message-id: <000f01cabad9$478c5850$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_9ikO94pgaQu8XB4GKasmow)" Thread-index: Acq62Ub2QirpTDMkQ0CIQwUGDnijGw== Subject: [Sigtran] [M2UA, IUA] Stream to be used for ASPTM 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: Wed, 03 Mar 2010 14:06:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_9ikO94pgaQu8XB4GKasmow) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Brian Which stream has to be used for ASPTM messages in M2UA and IUA ? M2UA RFC(3331) states: In section 4.2.1 All MGMT messages, except BEAT and BEAT Ack, SHOULD be sent with sequenced delivery to ensure ordering. All MGMT messages, with the exception of ASPTM, BEAT and BEAT Ack messages, SHOULD be sent on SCTP stream '0'. All ASPTM messages SHOULD be sent on the stream which normally carries the data traffic to which the message applies. BEAT and BEAT Ack messages MAY be sent using out-of-order delivery, and MAY be sent on any stream. ===>As per this ASPTM should be sent on stream (other than 0) On section 1.5.4.1 SCTP Stream Management SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) messages (see Section 3) since stream '0' SHOULD only be used for ASP Management (ASPM) messages (see Section 4.3.3). And RFC explains all the ASPSM/ASPTM messages as ASPM messages. So there seems to be a contradiction here in RFC. ===>As per this ASPTM should be sent on stream 0 And for IUA is SCTP stream management aligned(same as) with M2UA ? Pls clarify. Regards Santhanakrishnan --Boundary_(ID_9ikO94pgaQu8XB4GKasmow) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Brian

            Which stream has to be used for ASPTM messages in M2UA and IUA ?

 

M2UA RFC(3331) states:

In section 4.2.1

   All MGMT messages, except BEAT and BEAT Ack, SHOULD be sent with
   sequenced delivery to ensure ordering.  All MGMT messages, with the
   exception of ASPTM, BEAT and BEAT Ack messages, SHOULD be sent on
   SCTP stream '0'.  All ASPTM messages SHOULD be sent on the stream
   which normally carries the data traffic to which the message applies.
   BEAT and BEAT Ack messages MAY be sent using out-of-order delivery,

      and MAY be sent on any stream.

===>As per this ASPTM should be sent on stream (other than 0)

 

On section 1.5.4.1  SCTP Stream Management
   SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP)
   messages (see Section 3) since stream '0' SHOULD only be used for ASP
   Management (ASPM) messages (see Section 4.3.3).
And RFC explains all the ASPSM/ASPTM messages as ASPM messages. So there seems to be a contradiction here in RFC.

===>As per this ASPTM should be sent on stream 0

 
 
And for IUA is SCTP stream management aligned(same as) with M2UA ?
 
Pls clarify.
 
Regards
Santhanakrishnan

 

--Boundary_(ID_9ikO94pgaQu8XB4GKasmow)-- From bidulock@openss7.org Wed Mar 3 15:43:12 2010 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 576133A7870 for ; Wed, 3 Mar 2010 15:43:12 -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_74=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 H6QQLiGO0ROx for ; Wed, 3 Mar 2010 15:43:11 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 2F19F3A7038 for ; Wed, 3 Mar 2010 15:43:07 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:cEq8aZTyeEnO366+LwN1kz8Yd3TD3zTC@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o23Ngnu3018202; Wed, 3 Mar 2010 16:42:49 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:DB1bmqCXx/niG+/UZMPQRYbJlXdXdmqt@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o23NgnrA009885; Wed, 3 Mar 2010 16:42:49 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o23Ngmhc009884; Wed, 3 Mar 2010 16:42:48 -0700 Date: Wed, 3 Mar 2010 16:42:48 -0700 From: "Brian F. G. Bidulock" To: Santhana Message-ID: <20100303234248.GA1068@openss7.org> Mail-Followup-To: Santhana , sigtran@ietf.org References: <000f01cabad9$478c5850$2001120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000f01cabad9$478c5850$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] [M2UA, IUA] Stream to be used for ASPTM messages 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, 03 Mar 2010 23:43:12 -0000 Santhana, Please see comments below: Santhana wrote: (Wed, 03 Mar 2010 19:26:09) ---X--snip--X--- > On section 1.5.4.1 SCTP Stream Management > SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) > messages (see Section 3) since stream '0' SHOULD only be used for ASP > Management (ASPM) messages (see Section 4.3.3). > And RFC explains all the ASPSM/ASPTM messages as ASPM messages. So there seems > to be a contradiction here in RFC. > > ===>As per this ASPTM should be sent on stream 0 Yes, ASPM should read ASPSM in section 1.5.4.1 above. > And for IUA is SCTP stream management aligned(same as) with M2UA ? No. The reasons for sending ASPTM and BEAT/ACK on a traffic stream are primarily to avoid message loss due to deactivation of the AS (at SGP or ASP) before the last data message has arrived for the deactivated traffic. Sending the messages last and sequenced on the data stream ensures that, once the acknowledge is received, no messages are in transit to the peer UA. This is important to meet SS7's stringently low message loss requirements. See http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 for other procedures that can reduce message loss that are in fitting with this use of ASPTM and BEAT/ACK. ISDN has far less stringent requirments and, thus, the procedures are not necessary for IUA and IUA sends all ASPM messages on stream 0. Historically, IUA was written first and M2UA came second borrowing a lot from IUA. Section 4.2.1 was updated correctly, but Section 1.5.4.1 still uses the IUA statements, which do not apply to M2UA. Please submit an Errata against RFC 3331 for this. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Wed Mar 3 15:45:15 2010 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 3006528C26D for ; Wed, 3 Mar 2010 15:45:15 -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] 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 ny10swOeT7YB for ; Wed, 3 Mar 2010 15:45:04 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 2B1DC28C285 for ; Wed, 3 Mar 2010 15:45:04 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:vwaf+Yq5sNsczjldmvi5DVbjAEfAY752@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o23Nj1I3018237; Wed, 3 Mar 2010 16:45:01 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:36rYSK5EmWY1g2AbHzzgHh7Y4jTbZghV@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o23Nj1ad009950; Wed, 3 Mar 2010 16:45:01 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o23Nj1AH009949; Wed, 3 Mar 2010 16:45:01 -0700 Date: Wed, 3 Mar 2010 16:45:01 -0700 From: "Brian F. G. Bidulock" To: Santhana Message-ID: <20100303234501.GB1068@openss7.org> Mail-Followup-To: Santhana , sigtran@ietf.org References: <000101caa55a$fbad51c0$2001120a@china.huawei.com> <20100204092018.GA31582@openss7.org> <002c01caa59e$1d215520$2001120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002c01caa59e$1d215520$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] [IUA] SCTP RI missing in IUA FSM 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, 03 Mar 2010 23:45:15 -0000 Santhana, Santhana wrote: (Thu, 04 Feb 2010 18:59:43) > > In simple words can an SCTP restart triggered from the SGP side of IUA ? > Not normally, as the SGP is the server and the ASP the client, only the client would to attempt to reconnect, triggering an SCTP restart. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Xiangsong.Cui@huawei.com Wed Mar 3 19:13:23 2010 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 AD0A03A8BD2 for ; Wed, 3 Mar 2010 19:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 sYfVW+RtslEC for ; Wed, 3 Mar 2010 19:13:21 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 657B528C501 for ; Wed, 3 Mar 2010 19:13:20 -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 <0KYQ00FZQM9X0P@szxga01-in.huawei.com> for sigtran@ietf.org; Thu, 04 Mar 2010 11:13:09 +0800 (CST) Received: from c00111037 ([10.111.16.59]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYQ008W2M9XAI@szxga01-in.huawei.com> for sigtran@ietf.org; Thu, 04 Mar 2010 11:13:09 +0800 (CST) Date: Thu, 04 Mar 2010 11:13:08 +0800 From: Xiangsong Cui To: sigtran@ietf.org Message-id: <083301cabb48$9da4c0a0$3b106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000f01cabad9$478c5850$2001120a@china.huawei.com> Subject: [Sigtran] Sigtran extension for network management and association changeover. 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, 04 Mar 2010 03:13:23 -0000 Dear folks, We submitted two drafts about the sigtran extension, Although the Sigtran WG has been concluded, I still would like to talk about these topics in sigtran list before the discussion in tsvwg list. The drafts may be found by http://tools.ietf.org/id/draft-cui-tsvwg-snm-ps-00.txt Abstract: Sigtran is widely applied in the telecommunication network but there are still some issues. This document briefly describes some concerned scenarios and presents the association changeover and Sigtran routing management problems. The goal of this document is to analyse the existing shortage of Sigtran and discuss the desirable improvements. http://tools.ietf.org/id/draft-cui-tsvwg-assoc-changeover-00.txt Abstract: Sigtran specifies association-level reliable transport for signaling using SCTP, but in some scenarios a single association failure's reliability mechanism is not sufficient to achieve telco reliability. This document specifies procedures for an SCTP association changeover solution which will enable applications to meet a higher degree of availability. Two generic changeover solutions are presented in this document. One is implemented inside the SCTP protocol stack and the other requires SCTP and ULP to work in collaboration. These extensions are expected to improve the performance of sigtran network, especially for telecommunication network, what do you think about them? Any comments are appreciated! Thanks and best regards Xiangsong From Xiangsong.Cui@huawei.com Wed Mar 3 19:48:28 2010 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 21AC93A8A0B for ; Wed, 3 Mar 2010 19:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 jQXDojKiwBcw for ; Wed, 3 Mar 2010 19:48:27 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3C9FF3A859E for ; Wed, 3 Mar 2010 19:48:27 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYQ00MIUNWG8L@szxga04-in.huawei.com> for sigtran@ietf.org; Thu, 04 Mar 2010 11:48:16 +0800 (CST) Received: from c00111037 ([10.111.16.59]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYQ00DQFNWFEG@szxga04-in.huawei.com> for sigtran@ietf.org; Thu, 04 Mar 2010 11:48:16 +0800 (CST) Date: Thu, 04 Mar 2010 11:48:15 +0800 From: Xiangsong Cui To: sigtran@ietf.org Message-id: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [Sigtran] Sigtran extension for network management and association changeover. 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, 04 Mar 2010 03:48:28 -0000 Re-posted mail, sorry for the duplication. ========================================= Dear folks, We submitted two drafts about the sigtran extension, Although the Sigtran WG has been concluded, I still would like to talk about these topics in sigtran list before the discussion in tsvwg list. The drafts may be found by http://tools.ietf.org/id/draft-cui-tsvwg-snm-ps-00.txt Abstract: Sigtran is widely applied in the telecommunication network but there are still some issues. This document briefly describes some concerned scenarios and presents the association changeover and Sigtran routing management problems. The goal of this document is to analyse the existing shortage of Sigtran and discuss the desirable improvements. http://tools.ietf.org/id/draft-cui-tsvwg-assoc-changeover-00.txt Abstract: Sigtran specifies association-level reliable transport for signaling using SCTP, but in some scenarios a single association failure's reliability mechanism is not sufficient to achieve telco reliability. This document specifies procedures for an SCTP association changeover solution which will enable applications to meet a higher degree of availability. Two generic changeover solutions are presented in this document. One is implemented inside the SCTP protocol stack and the other requires SCTP and ULP to work in collaboration. These extensions are expected to improve the performance of sigtran network, especially for telecommunication network, what do you think about them? Any comments are appreciated! Thanks and best regards Xiangsong From bidulock@openss7.org Thu Mar 4 00:09:01 2010 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 6A6C73A88C6 for ; Thu, 4 Mar 2010 00:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 xJXoO23fVcar for ; Thu, 4 Mar 2010 00:09:00 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 5CFFE3A885B for ; Thu, 4 Mar 2010 00:09:00 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:UedZTniJn3Wus+UYy7oMU9QoncHYVczS@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2488wN7026706; Thu, 4 Mar 2010 01:08:58 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:BJ00iE4ZEUUA0taLtuZb3p9simRtivZO@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2488wKl025215; Thu, 4 Mar 2010 01:08:58 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2488wiO025214; Thu, 4 Mar 2010 01:08:58 -0700 Date: Thu, 4 Mar 2010 01:08:58 -0700 From: "Brian F. G. Bidulock" To: Xiangsong Cui Message-ID: <20100304080858.GA23705@openss7.org> Mail-Followup-To: Xiangsong Cui , sigtran@ietf.org References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09dd01cabb4d$8582acd0$3b106f0a@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] Sigtran extension for network management and association changeover. 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, 04 Mar 2010 08:09:01 -0000 Xiangsong, Xiangsong Cui wrote: (Thu, 04 Mar 2010 11:48:15) > > http://tools.ietf.org/id/draft-cui-tsvwg-snm-ps-00.txt > Abstract: > Sigtran is widely applied in the telecommunication network but there > are still some issues. This document briefly describes some concerned > scenarios and presents the association changeover and Sigtran routing > management problems. The goal of this document is to analyse the > existing shortage of Sigtran and discuss the desirable improvements. I believe these issues were already addressed in the 3GPP Liaison statement of April 2008. Note that 3GPP (which you cite in the document) does not permit M3UA RK's at granularity of less than a signalling point code. > > http://tools.ietf.org/id/draft-cui-tsvwg-assoc-changeover-00.txt > Abstract: > Sigtran specifies association-level reliable transport for signaling > using SCTP, but in some scenarios a single association failure's > reliability mechanism is not sufficient to achieve telco reliability. > This document specifies procedures for an SCTP association changeover > solution which will enable applications to meet a higher degree of > availability. Two generic changeover solutions are presented in this > document. One is implemented inside the SCTP protocol stack and the > other requires SCTP and ULP to work in collaboration. http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides several mechanisms that are completely local and accomplish this without protocol changes: neither in SCTP nor the UA. UAs, such as M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams that already accommodate these procedures. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Xiangsong.Cui@huawei.com Thu Mar 4 01:18:19 2010 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 D60963A81D8 for ; Thu, 4 Mar 2010 01:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 nd4aO7uol1VA for ; Thu, 4 Mar 2010 01:18:12 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6E9903A7D53 for ; Thu, 4 Mar 2010 01:17:57 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYR006KB34NVD@szxga04-in.huawei.com> for sigtran@ietf.org; Thu, 04 Mar 2010 17:17:12 +0800 (CST) Received: from c00111037 ([10.111.16.59]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYR00NI934M1A@szxga04-in.huawei.com> for sigtran@ietf.org; Thu, 04 Mar 2010 17:17:11 +0800 (CST) Date: Thu, 04 Mar 2010 17:17:10 +0800 From: Xiangsong Cui To: bidulock@openss7.org Message-id: <0ce601cabb7b$78323bd0$3b106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> Cc: sigtran@ietf.org Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. 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, 04 Mar 2010 09:18:20 -0000 Dear Brian, Thanks for your attention, please see inline. Regards Xiangsong ----- Original Message ----- From: "Brian F. G. Bidulock" To: "Xiangsong Cui" Cc: Sent: Thursday, March 04, 2010 4:08 PM Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. > Xiangsong, > > Xiangsong Cui wrote: (Thu, 04 Mar 2010 11:48:15) >> >> http://tools.ietf.org/id/draft-cui-tsvwg-snm-ps-00.txt >> Abstract: >> Sigtran is widely applied in the telecommunication network but there >> are still some issues. This document briefly describes some concerned >> scenarios and presents the association changeover and Sigtran routing >> management problems. The goal of this document is to analyse the >> existing shortage of Sigtran and discuss the desirable improvements. > > I believe these issues were already addressed in the 3GPP Liaison > statement of April 2008. Note that 3GPP (which you cite in the > document) does not permit M3UA RK's at granularity of less than > a signalling point code. If you mean https://datatracker.ietf.org/documents/LIAISON/file552.txt, I think the issues are not all resolved. Changeover issue (I guess you agree this is a problem after I see your draft) is not mentioned in this liaison and the routing management issue is not resolved as you said. The liaison says "However, this approach has some drawbacks, expecially if multiple SGs are used." and "There was some discussion within the Working Group about potential extensions to overcome these drawbacks, but no consensus was reached." Do I miss any important information? In addition, in some practical scenario, even one SG, we also met some troubles. For example, in the basic case of GSM + softswitch, some BSC devices can not support multiple adjacent SP, unfortunately the BSCs can't be updated too. So the MGW has to share the SP code with the MSC Server, but we need install SCCP in both MGW (for SGW/STP purpose) and MSC Server (for MAP purpose). The duplicated combinations of "SP Code + SCCP User Part" bring problems for the network. If we use M2UA for GSM access, the complexity increases explicitly. Is this also a drawback? > >> >> http://tools.ietf.org/id/draft-cui-tsvwg-assoc-changeover-00.txt >> Abstract: >> Sigtran specifies association-level reliable transport for signaling >> using SCTP, but in some scenarios a single association failure's >> reliability mechanism is not sufficient to achieve telco reliability. >> This document specifies procedures for an SCTP association changeover >> solution which will enable applications to meet a higher degree of >> availability. Two generic changeover solutions are presented in this >> document. One is implemented inside the SCTP protocol stack and the >> other requires SCTP and ULP to work in collaboration. > > http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides > several mechanisms that are completely local and accomplish this > without protocol changes: neither in SCTP nor the UA. UAs, such as > M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams > that already accommodate these procedures. > I am glad to see this draft, but I need some time to read through it. We can discuss this item later. Thanks, Xiangsong > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ From Amir.Khan@emerson.com Thu Mar 4 05:42:24 2010 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 2C3643A8C29 for ; Thu, 4 Mar 2010 05:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 wgaDX52Nbbfu for ; Thu, 4 Mar 2010 05:42:23 -0800 (PST) Received: from USSTLZ-PSECAP05.EMERSON.COM (usstlz-psecap04.emerson.com [144.191.128.16]) by core3.amsl.com (Postfix) with ESMTP id 4FC793A8C05 for ; Thu, 4 Mar 2010 05:42:23 -0800 (PST) X-AuditID: 0a10081c-b7b89ae000001445-2d-4b8fb8c01ec2 Received: from usstlz-pinfeh01.emrsn.org ( [10.16.72.57]) by USSTLZ-PSECAP05.EMERSON.COM (Symantec Mail Security) with SMTP id 89.66.05189.0C8BF8B4; Thu, 4 Mar 2010 07:42:24 -0600 (CST) Received: from ETSMSG-HKEXR06.etsmsg.org (10.172.40.32) by usstlz-pinfeh01.emrsn.org (10.16.72.57) with Microsoft SMTP Server id 8.2.176.0; Thu, 4 Mar 2010 13:42:24 +0000 Received: from etsmsg-hkexm05.etsmsg.org ([142.130.2.85]) by ETSMSG-HKEXR06.etsmsg.org with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 21:42:21 +0800 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_01CABBA0.84229BDA" Date: Thu, 4 Mar 2010 21:42:20 +0800 Message-ID: <89D32649C0790143AB985A5BF77A104F02F4E063@etsmsg-hkexm05.etsmsg.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M3UA Notification and Routing Context Thread-Index: Acq7oINi/3gI2y4yS4+niI9b7AbDHw== From: To: X-OriginalArrivalTime: 04 Mar 2010 13:42:21.0912 (UTC) FILETIME=[841CC580:01CABBA0] X-Brightmail-Tracker: AAAAARMoVrw= Subject: [Sigtran] M3UA Notification and Routing Context 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, 04 Mar 2010 13:42:24 -0000 ------_=_NextPart_001_01CABBA0.84229BDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Does it become mandatory for SG to send Notify message ("Alternate ASP Active") with Routing Context, when the concerned ASP is a part of multiple AS. So that the concerned ASP can use this RC to become INACTIVE for the related AS. =20 E.g. If ASP1 is Actively processing traffic for both AS1(Override) and AS2(Loadshare) and another ASP2 of AS1 becomes ACTIVE, Do SG then needs to send Notify message ("Alternate ASP Active") with AS1 Routing Context, which ASP1 will use to become INACTIVE for AS1. =20 =20 Please comment. =20 Thanks aamir =20 =20 ------_=_NextPart_001_01CABBA0.84229BDA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
Does = it become=20 mandatory for SG to send Notify message ("Alternate ASP Active") with = Routing=20 Context, when the concerned ASP is a part of multiple AS. So that the = concerned=20 ASP can use this RC to become INACTIVE for the related=20 AS.
 
E.g. = If  ASP1=20 is Actively processing traffic for both AS1(Override) and = AS2(Loadshare) and another ASP2 of AS1 becomes ACTIVE, Do SG then needs = to send=20 Notify message ("Alternate ASP Active") with AS1 Routing Context, which = ASP1=20 will use to become INACTIVE for AS1.
 
 
Please = comment.
 
Thanks
aamir
 
 
------_=_NextPart_001_01CABBA0.84229BDA-- From bidulock@openss7.org Thu Mar 4 12:08:01 2010 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 A29C93A8E50 for ; Thu, 4 Mar 2010 12:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 h1j2bOFQOIAl for ; Thu, 4 Mar 2010 12:08:00 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 8D62D3A8E4B for ; Thu, 4 Mar 2010 12:08:00 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:8mJgdOWvau2s8G+HsQ0DUYKJYPz/XcdQ@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o24K7x7O006533; Thu, 4 Mar 2010 13:07:59 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:AEOJhVug0cNvylD5PCs4M6vt2ZWJBe7P@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o24K7xs5015947; Thu, 4 Mar 2010 13:07:59 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o24K7xYT015946; Thu, 4 Mar 2010 13:07:59 -0700 Date: Thu, 4 Mar 2010 13:07:59 -0700 From: "Brian F. G. Bidulock" To: Amir.Khan@Emerson.com Message-ID: <20100304200759.GA3165@openss7.org> Mail-Followup-To: Amir.Khan@Emerson.com, sigtran@ietf.org References: <89D32649C0790143AB985A5BF77A104F02F4E063@etsmsg-hkexm05.etsmsg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89D32649C0790143AB985A5BF77A104F02F4E063@etsmsg-hkexm05.etsmsg.org> 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 Notification and Routing Context 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, 04 Mar 2010 20:08:01 -0000 Amir, RC should likely be marked "conditional" instead of "optional". --brian Amir.Khan@Emerson.com wrote: (Thu, 04 Mar 2010 21:42:20) > > Hi All, > > > > Does it become mandatory for SG to send Notify message ("Alternate ASP > Active") with Routing Context, when the concerned ASP is a part of > multiple AS. So that the concerned ASP can use this RC to become > INACTIVE for the related AS. > > > > E.g. If ASP1 is Actively processing traffic for both AS1(Override) > and AS2(Loadshare) and another ASP2 of AS1 becomes ACTIVE, Do SG then > needs to send Notify message ("Alternate ASP Active") with AS1 Routing > Context, which ASP1 will use to become INACTIVE for AS1. > > > > > > Please comment. > > > > Thanks > > aamir > _______________________________________________ > 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 Xiangsong.Cui@huawei.com Thu Mar 4 18:44:57 2010 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 34BD328C0DB for ; Thu, 4 Mar 2010 18:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[AWL=0.827, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, STOX_REPLY_TYPE=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 9bNEyOLHRK4f for ; Thu, 4 Mar 2010 18:44:56 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 8567628C0D0 for ; Thu, 4 Mar 2010 18:44:51 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYS00DGZFMRZS@szxga02-in.huawei.com> for sigtran@ietf.org; Fri, 05 Mar 2010 10:44:51 +0800 (CST) Received: from c00111037 ([10.111.16.59]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYS0080QFMR5Q@szxga02-in.huawei.com> for sigtran@ietf.org; Fri, 05 Mar 2010 10:44:51 +0800 (CST) Date: Fri, 05 Mar 2010 10:44:50 +0800 From: Xiangsong Cui To: bidulock@openss7.org Message-id: <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> Cc: sigtran@ietf.org Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. 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, 05 Mar 2010 02:44:57 -0000 Dear Brian, I have read the corid draft and have some thought. > http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides > several mechanisms that are completely local and accomplish this > without protocol changes: neither in SCTP nor the UA. UAs, such as > M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams > that already accommodate these procedures. > > --brian In my understanding, the corid draft and my association-changeover draft are for the same goal, the main difference is corid draft works in UA (or SPP) layer while my association-changeover draft focuses on SCTP layer. The detailed differences include: 1, Corid draft modifies UA protocols (section 3 Protocol Elements), such as M2UA, M3UA, SUA, ISUA..... Association-changeover draft only changes SCTP protocol. 2, Corid draft brings many transport functionalities into UA layer, such as corid (section 4.1.2.1), flow id (section 4.1.2.2), tagging (section 4.1.3) and buffering (section 4.1.4). These features bring complex and repeated job into UA layer and would make UA hard to work. Association-changeover draft incorporates SS7 changeover functionality in Sigtran, the peers exchange sequence information, and the sender resends the unacknowledged messages. 3, Determining which messages have already been acknowledged? Corid draft accomplishes it in UA layer (<5> IMPLEMENTATION NOTE of corid draft), it is out of the scope of corid draft but that is really difficult. Association-changeover draft accomplishes it in SCTP layer by TSN, it is very easy. 4. Corid draft requires all traffic packets to include id information (section 4.1.3), which would waste bandwidth of the network. Association-changeover draft takes normal traffic transport procedure. 5. Corid resends all undetermined messages (including the acknowledged messages) to the peer, and the messages are determined by the peer node. Association-changeover resends only the unacknowledged messages to the peer. Are those right? Thanks and regards Xiangsong From Amir.Khan@emerson.com Thu Mar 4 21:27:32 2010 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 2C8FB3A8EB2 for ; Thu, 4 Mar 2010 21:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] 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 RP62bXH9xIzB for ; Thu, 4 Mar 2010 21:27:30 -0800 (PST) Received: from USSTLZ-PSECAP05.EMERSON.COM (usstlz-psecap04.emerson.com [144.191.128.16]) by core3.amsl.com (Postfix) with ESMTP id A63D43A8EB0 for ; Thu, 4 Mar 2010 21:27:30 -0800 (PST) X-AuditID: 0a10081c-b7b89ae000001445-6a-4b9096444ebb Received: from usstlz-pinfeh06.emrsn.org ( [10.16.72.62]) by USSTLZ-PSECAP05.EMERSON.COM (Symantec Mail Security) with SMTP id F9.85.05189.446909B4; Thu, 4 Mar 2010 23:27:32 -0600 (CST) Received: from ETSMSG-HKEXR05.etsmsg.org (10.172.40.31) by usstlz-pinfeh06.emrsn.org (10.16.72.62) with Microsoft SMTP Server id 8.2.176.0; Fri, 5 Mar 2010 05:27:32 +0000 Received: from etsmsg-hkexm05.etsmsg.org ([142.130.2.85]) by ETSMSG-HKEXR05.etsmsg.org with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 13:27:30 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Mar 2010 13:27:28 +0800 Message-ID: <89D32649C0790143AB985A5BF77A104F02F4E421@etsmsg-hkexm05.etsmsg.org> In-Reply-To: <20100304200759.GA3165@openss7.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] M3UA Notification and Routing Context Thread-Index: Acq71mggady8upowQC+jLfU8IGeulAATYa1Q References: <89D32649C0790143AB985A5BF77A104F02F4E063@etsmsg-hkexm05.etsmsg.org> <20100304200759.GA3165@openss7.org> From: To: X-OriginalArrivalTime: 05 Mar 2010 05:27:30.0744 (UTC) FILETIME=[8D35D380:01CABC24] X-Brightmail-Tracker: AAAAARMqGHk= Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA Notification and Routing Context 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, 05 Mar 2010 05:27:32 -0000 Brian, Than I guess RFC should clearly state this, rather than saying it just "optional". Can we treat this as a update in M3UA RFC. Thanks aamir -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]=20 Sent: Friday, March 05, 2010 1:38 AM To: Khan, Amir [NETPWR/INDIA/HYDE] Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA Notification and Routing Context Amir, RC should likely be marked "conditional" instead of "optional". --brian Amir.Khan@Emerson.com wrote: (Thu, 04 Mar 2010 21:42:20) >=20 > Hi All, >=20 >=20 >=20 > Does it become mandatory for SG to send Notify message ("Alternate ASP > Active") with Routing Context, when the concerned ASP is a part of > multiple AS. So that the concerned ASP can use this RC to become > INACTIVE for the related AS. >=20 >=20 >=20 > E.g. If ASP1 is Actively processing traffic for both AS1(Override) > and AS2(Loadshare) and another ASP2 of AS1 becomes ACTIVE, Do SG then > needs to send Notify message ("Alternate ASP Active") with AS1 Routing > Context, which ASP1 will use to become INACTIVE for AS1. >=20 >=20 >=20 >=20 >=20 > Please comment. >=20 >=20 >=20 > Thanks >=20 > aamir > _______________________________________________ > 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 Mar 4 21:54:01 2010 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 AC01A3A8EBF for ; Thu, 4 Mar 2010 21:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 TkVTVG+p635g for ; Thu, 4 Mar 2010 21:54:00 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id AC95D3A8EC6 for ; Thu, 4 Mar 2010 21:53:59 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:juXrpN84gf5TGNydNlV/9X1CgAnX2cnu@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o255rtNn016048; Thu, 4 Mar 2010 22:53:55 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:VNQ7c26sFQ7CqA2rl0+r8G/WyFElLkcS@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o255rt70032718; Thu, 4 Mar 2010 22:53:55 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o255rs3u032717; Thu, 4 Mar 2010 22:53:54 -0700 Date: Thu, 4 Mar 2010 22:53:54 -0700 From: "Brian F. G. Bidulock" To: Xiangsong Cui Message-ID: <20100305055354.GA31145@openss7.org> Mail-Followup-To: Xiangsong Cui , sigtran@ietf.org References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008801cabc0d$d4282d40$3b106f0a@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] Sigtran extension for network management and association changeover. 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: Fri, 05 Mar 2010 05:54:01 -0000 Xiangsong, No, that is not right. You are coming at this rather late in the game. M2PA first attempted to use SCTP's transport layer ack in its functionality but it became impossible. Modifications to SCTP were not seen to be appropriate when an application level ack would suffice. Not even all SIGTRAN layers require this capability, and modifications to SCTP would force the capability on all applications. I quite frankly agree with the consensus that was taken by tsvwg in these M2PA discussions and am resistant to a draft that would go against that consensus now. The corid draft does not require any changes to protocol elements. See the section entitled "Interworking". The approaches used in this section do no require any changes to the protocol or even for the peer to support the procedures. This approach (similar to the time-controlled changeover and changeback procedures of SS7) is used by a number of commercial implementations of M3UA. Standardization has not been necessary because the procedures are local, only rely on existing protocol elements and procedures, do not rely on implementation of the procedures at the peer, are largely implementation related, and are performance based implementation options. I resubmitted the corid and about 8 or so other extension drafts for 5 to 7 years while the working group was active and none were taken up as WG items. For example: http://tools.ietf.org/html/draft-bidulock-sigtran-aspcong-01 http://tools.ietf.org/html/draft-bidulock-sigtran-aspext-05 http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 http://tools.ietf.org/html/draft-bidulock-sigtran-isua-04 http://tools.ietf.org/html/draft-bidulock-sigtran-loadgrp-05 http://tools.ietf.org/html/draft-bidulock-sigtran-loadsel-05 http://tools.ietf.org/html/draft-bidulock-sigtran-m2pa-test-08 http://tools.ietf.org/html/draft-bidulock-sigtran-m2ua-ss7test-03 http://tools.ietf.org/html/draft-bidulock-sigtran-regext-04 http://tools.ietf.org/html/draft-bidulock-sigtran-tua-05 The necessary (but not all) protocol elements for corid-05 and regext-04 made their way into the UAs. loadgrp-05 and loadsel-05 are not supported in any way, leaving SLS as the only rational basis for loadsharing. The connection id components of regext-04 are not supportted, making connection-oriented SCCP in SUA useless. After 8 years of banging my head on that, I think it unlikely that there will be a rally around these concepts now that the WG is shut down. There is no charter, and these types of drafts do not seem sufficient to create one. For example, far more important items (the lack of an M3UA MIB, and MIBs for any other SIGTRAN UAs) cannot keep open or resurrect the WG. You can likely get more traction in forums that use SIGTRAN such as ITU-T and 3GPP. My advise (whether you want it or not) is to find procedures such as those in the corid Interworking section that fits your implementation. Do not use any proprietary protocol elements. Do not require any optional procedure of the peer. Corid shows that it is possible (if not preferred) in the Interworking section. If the corid procedures seem too complex for you, make your implementation simpler. If after that you want to share all your work with the IETF, put forth a draft that describes your implementation as an INFORMATIONAL RFC. I won't even consider reviewing a draft that attempts to provide protocol elements or requires changes in procedures at the peer, either at SCTP or UA levels; because my first criticism will be that it requires protocol elements and requires changes in procedures at the peer: neither of which are possible nor necessary at this point. --brian Xiangsong Cui wrote: (Fri, 05 Mar 2010 10:44:50) > Dear Brian, > > I have read the corid draft and have some thought. > > >http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides > >several mechanisms that are completely local and accomplish this > >without protocol changes: neither in SCTP nor the UA. UAs, such as > >M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams > >that already accommodate these procedures. > > > >--brian > > In my understanding, the corid draft and my association-changeover draft > are for > the same goal, the main difference is corid draft works in UA (or SPP) > layer while my association-changeover draft focuses on SCTP layer. > > The detailed differences include: > 1, Corid draft modifies UA protocols (section 3 Protocol Elements), such as > M2UA, M3UA, SUA, ISUA..... > Association-changeover draft only changes SCTP protocol. > 2, Corid draft brings many transport functionalities into UA layer, such as > corid (section 4.1.2.1), flow id (section 4.1.2.2), tagging (section > 4.1.3) and buffering > (section 4.1.4). These features bring complex and repeated job into UA > layer and would make UA hard to work. > Association-changeover draft incorporates SS7 changeover functionality > in Sigtran, > the peers exchange sequence information, and the sender resends the > unacknowledged messages. > 3, Determining which messages have already been acknowledged? > Corid draft accomplishes it in UA layer (<5> IMPLEMENTATION NOTE of > corid draft), it is out of the scope of corid draft but that is really > difficult. > Association-changeover draft accomplishes it in SCTP layer by TSN, it is > very easy. > 4. Corid draft requires all traffic packets to include id information > (section 4.1.3), which would waste bandwidth of the network. > Association-changeover draft takes normal traffic transport procedure. > 5. Corid resends all undetermined messages (including the acknowledged > messages) to the peer, and the messages are determined by the peer node. > Association-changeover resends only the unacknowledged messages to the > peer. > > Are those right? > > Thanks and regards > Xiangsong -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Thu Mar 4 21:54:49 2010 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 8F5903A8EBF for ; Thu, 4 Mar 2010 21:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 21MWagcY+G3V for ; Thu, 4 Mar 2010 21:54:48 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id AFF523A8B10 for ; Thu, 4 Mar 2010 21:54:48 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:tVEhfsLRnACB1iJ832X6xMPYiEt/n+iT@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o255slha016070; Thu, 4 Mar 2010 22:54:47 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:WKA5LCbLgIeqkSf6mOEcQnypg3vaITeW@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o255sl76000327; Thu, 4 Mar 2010 22:54:47 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o255sllH000326; Thu, 4 Mar 2010 22:54:47 -0700 Date: Thu, 4 Mar 2010 22:54:47 -0700 From: "Brian F. G. Bidulock" To: Amir.Khan@Emerson.com Message-ID: <20100305055447.GB31145@openss7.org> Mail-Followup-To: Amir.Khan@Emerson.com, sigtran@ietf.org References: <89D32649C0790143AB985A5BF77A104F02F4E063@etsmsg-hkexm05.etsmsg.org> <20100304200759.GA3165@openss7.org> <89D32649C0790143AB985A5BF77A104F02F4E421@etsmsg-hkexm05.etsmsg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89D32649C0790143AB985A5BF77A104F02F4E421@etsmsg-hkexm05.etsmsg.org> 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 Notification and Routing Context 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: Fri, 05 Mar 2010 05:54:49 -0000 Amir, Sure, I suggest you submit an ERRATA. --brian Amir.Khan@Emerson.com wrote: (Fri, 05 Mar 2010 13:27:28) > > Brian, > > > Than I guess RFC should clearly state this, rather than saying it just > "optional". Can we treat this as a update in M3UA RFC. > > > Thanks > aamir > > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Friday, March 05, 2010 1:38 AM > To: Khan, Amir [NETPWR/INDIA/HYDE] > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA Notification and Routing Context > > Amir, > > RC should likely be marked "conditional" instead of "optional". > > --brian > > Amir.Khan@Emerson.com wrote: (Thu, 04 Mar 2010 21:42:20) > > > > Hi All, > > > > > > > > Does it become mandatory for SG to send Notify message ("Alternate > ASP > > Active") with Routing Context, when the concerned ASP is a part of > > multiple AS. So that the concerned ASP can use this RC to become > > INACTIVE for the related AS. > > > > > > > > E.g. If ASP1 is Actively processing traffic for both AS1(Override) > > and AS2(Loadshare) and another ASP2 of AS1 becomes ACTIVE, Do SG > then > > needs to send Notify message ("Alternate ASP Active") with AS1 > Routing > > Context, which ASP1 will use to become INACTIVE for AS1. > > > > > > > > > > > > Please comment. > > > > > > > > Thanks > > > > aamir > > > _______________________________________________ > > 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 -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From wwwrun@rfc-editor.org Thu Mar 4 22:28:07 2010 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 356963A8C6B for ; Thu, 4 Mar 2010 22:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-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 a6c2fiZk1JW5 for ; Thu, 4 Mar 2010 22:28:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 0CB4D3A8EE1 for ; Thu, 4 Mar 2010 22:27:57 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id ADFDDE06F2; Thu, 4 Mar 2010 22:27:59 -0800 (PST) To: kmorneau@cisco.com, j.javier.pastor@ericsson.com, rjsparks@nostrum.com, fluffy@cisco.com, lyong@ciena.com From: RFC Errata System Message-Id: <20100305062759.ADFDDE06F2@rfc-editor.org> Date: Thu, 4 Mar 2010 22:27:59 -0800 (PST) Cc: sigtran@ietf.org, rfc-editor@rfc-editor.org Subject: [Sigtran] [Technical Errata Reported] RFC4666 (2065) 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, 05 Mar 2010 06:28:07 -0000 The following errata report has been submitted for RFC4666, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4666&eid=2065 -------------------------------------- Type: Technical Reported by: AMIR KHAN Section: 3.8.2 Original Text ------------- The Notify message contains the following parameters: Status Mandatory ASP Identifier Conditional Routing Context Optional INFO String Optional Corrected Text -------------- The Notify message contains the following parameters: Status Mandatory ASP Identifier Conditional Routing Context Conditional INFO String Optional Notes ----- Considering the scenario below I think the Routing Context in Notify must be conditional. If ASP1 is Actively processing traffic for both AS1(Override) and AS2(Loadshare) and another ASP2 of AS1 becomes ACTIVE. Then I think it becomes mandatory for SG to send Notify message ("Alternate ASP Active") with AS1 Routing Context. ASP1 will use this Notify (containing AS1 Routing Context) to become INACTIVE for AS1, without this AS1 Routing Context ASP1 will become INACTIVE for both AS1 and AS2, which is not desired here. Also please go through mailing list with subject line "M3UA Notification and Routing Context" for more on this. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4666 (draft-ietf-sigtran-rfc3332bis-06) -------------------------------------- Title : Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) Publication Date : September 2006 Author(s) : K. Morneault, Ed., J. Pastor-Balbas, Ed. Category : PROPOSED STANDARD Source : Signaling Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From Xiangsong.Cui@huawei.com Thu Mar 4 22:58:07 2010 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 072BA3A8ED9 for ; Thu, 4 Mar 2010 22:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 5H22ZLFVTxZr for ; Thu, 4 Mar 2010 22:58:05 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 053DE3A8A38 for ; Thu, 4 Mar 2010 22:58:05 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYS002LWRCK4A@szxga04-in.huawei.com> for sigtran@ietf.org; Fri, 05 Mar 2010 14:57:56 +0800 (CST) Received: from c00111037 ([10.111.16.59]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYS0074NRCKAK@szxga04-in.huawei.com> for sigtran@ietf.org; Fri, 05 Mar 2010 14:57:56 +0800 (CST) Date: Fri, 05 Mar 2010 14:57:56 +0800 From: Xiangsong Cui To: bidulock@openss7.org Message-id: <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> Cc: sigtran@ietf.org Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. 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, 05 Mar 2010 06:58:07 -0000 Dear Brian, Thanks for the discussion, comments inline. Regards Xiangsong ----- Original Message ----- From: "Brian F. G. Bidulock" To: "Xiangsong Cui" Cc: Sent: Friday, March 05, 2010 1:53 PM Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. > Xiangsong, > > No, that is not right. You are coming at this rather late in > the game. M2PA first attempted to use SCTP's transport layer > ack in its functionality but it became impossible. I don't think so, it seems the M2PA is reusing the functionality of MTP2, just using BSN to acknowledge the peer's FSN. > Modifications to SCTP were not seen to be appropriate when an > application level ack would suffice. Not even all SIGTRAN > layers require this capability, and modifications to SCTP would > force the capability on all applications. They are for different purpose (vs application level ack) and compatible, association changeover is harmless to any application. > > I quite frankly agree with the consensus that was taken by tsvwg > in these M2PA discussions and am resistant to a draft that would > go against that consensus now. I'm very interseted in the *consensus*, will find out the discussion and read it. > > The corid draft does not require any changes to protocol > elements. See the section entitled "Interworking". The > approaches used in this section do no require any changes to the > protocol or even for the peer to support the procedures. This I guess you are refering to section 4.3 Interworking Procedures, but not section 5.6 Interworking. Section 4.3 says "Because the CORID procedures provided here rely upon close synchronization of Correlation Number between SPP, if one of the SPP does not support these CORID procedures, neither SPP is able to take advantage of the full benefits of the procedures." In fact, if the peer doesn't support CORID, the only benefit relies on the buffer of local SPP. However, most UA SPPs don't provide buffering function, so what can these UA SPPs get in this situation? > approach (similar to the time-controlled changeover and > changeback procedures of SS7) is used by a number of commercial > implementations of M3UA. Standardization has not been necessary > because the procedures are local, only rely on existing protocol > elements and procedures, do not rely on implementation of the > procedures at the peer, are largely implementation related, and > are performance based implementation options. I can't agree changeover is a local feature. If you only want time-controlled changeover, you may use SCTP Receive Unsent Message primitive defined in RFC4960, ignoring the sent but not acknowledged messages, why buffer the unsent messages in UA layer? > > I resubmitted the corid and about 8 or so other extension drafts > for 5 to 7 years while the working group was active and none > were taken up as WG items. For example: > > http://tools.ietf.org/html/draft-bidulock-sigtran-aspcong-01 > http://tools.ietf.org/html/draft-bidulock-sigtran-aspext-05 > http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 > http://tools.ietf.org/html/draft-bidulock-sigtran-isua-04 > http://tools.ietf.org/html/draft-bidulock-sigtran-loadgrp-05 > http://tools.ietf.org/html/draft-bidulock-sigtran-loadsel-05 > http://tools.ietf.org/html/draft-bidulock-sigtran-m2pa-test-08 > http://tools.ietf.org/html/draft-bidulock-sigtran-m2ua-ss7test-03 > http://tools.ietf.org/html/draft-bidulock-sigtran-regext-04 > http://tools.ietf.org/html/draft-bidulock-sigtran-tua-05 > Thanks a lot for the contribution, I will read them carefully. > The necessary (but not all) protocol elements for corid-05 and > regext-04 made their way into the UAs. loadgrp-05 and > loadsel-05 are not supported in any way, leaving SLS as the only > rational basis for loadsharing. The connection id components of > regext-04 are not supportted, making connection-oriented SCCP in > SUA useless. > > After 8 years of banging my head on that, I think it unlikely > that there will be a rally around these concepts now that the WG > is shut down. There is no charter, and these types of drafts do > not seem sufficient to create one. For example, far more > important items (the lack of an M3UA MIB, and MIBs for any other > SIGTRAN UAs) cannot keep open or resurrect the WG. You can > likely get more traction in forums that use SIGTRAN such as > ITU-T and 3GPP. > > My advise (whether you want it or not) is to find procedures > such as those in the corid Interworking section that fits your > implementation. Do not use any proprietary protocol elements. > Do not require any optional procedure of the peer. Corid shows > that it is possible (if not preferred) in the Interworking > section. If the corid procedures seem too complex for you, make > your implementation simpler. If after that you want to share > all your work with the IETF, put forth a draft that describes > your implementation as an INFORMATIONAL RFC. Thank you very much for your comments and advise! > > I won't even consider reviewing a draft that attempts to provide > protocol elements or requires changes in procedures at the peer, > either at SCTP or UA levels; because my first criticism will be > that it requires protocol elements and requires changes in > procedures at the peer: neither of which are possible nor > necessary at this point. As you said in your draft, local implementation is not engough for the expected benefit, and we do wish a feasible solution for the high-performance Sigtran network. Thanks again, Xiangsong > > --brian > > > Xiangsong Cui wrote: (Fri, 05 Mar 2010 10:44:50) >> Dear Brian, >> >> I have read the corid draft and have some thought. >> >> >http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides >> >several mechanisms that are completely local and accomplish this >> >without protocol changes: neither in SCTP nor the UA. UAs, such as >> >M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams >> >that already accommodate these procedures. >> > >> >--brian >> >> In my understanding, the corid draft and my association-changeover draft >> are for >> the same goal, the main difference is corid draft works in UA (or SPP) >> layer while my association-changeover draft focuses on SCTP layer. >> >> The detailed differences include: >> 1, Corid draft modifies UA protocols (section 3 Protocol Elements), such as >> M2UA, M3UA, SUA, ISUA..... >> Association-changeover draft only changes SCTP protocol. >> 2, Corid draft brings many transport functionalities into UA layer, such as >> corid (section 4.1.2.1), flow id (section 4.1.2.2), tagging (section >> 4.1.3) and buffering >> (section 4.1.4). These features bring complex and repeated job into UA >> layer and would make UA hard to work. >> Association-changeover draft incorporates SS7 changeover functionality >> in Sigtran, >> the peers exchange sequence information, and the sender resends the >> unacknowledged messages. >> 3, Determining which messages have already been acknowledged? >> Corid draft accomplishes it in UA layer (<5> IMPLEMENTATION NOTE of >> corid draft), it is out of the scope of corid draft but that is really >> difficult. >> Association-changeover draft accomplishes it in SCTP layer by TSN, it is >> very easy. >> 4. Corid draft requires all traffic packets to include id information >> (section 4.1.3), which would waste bandwidth of the network. >> Association-changeover draft takes normal traffic transport procedure. >> 5. Corid resends all undetermined messages (including the acknowledged >> messages) to the peer, and the messages are determined by the peer node. >> Association-changeover resends only the unacknowledged messages to the >> peer. >> >> Are those right? >> >> Thanks and regards >> Xiangsong > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ From bidulock@openss7.org Fri Mar 5 00:54:55 2010 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 06DB23A738A for ; Fri, 5 Mar 2010 00:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 oyPrCk5-uFg7 for ; Fri, 5 Mar 2010 00:54:53 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 61EAA3A6920 for ; Fri, 5 Mar 2010 00:54:50 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:1+ssX8rwTKVHdxF5y3uOs020yL4t44u6@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o258sljc019225; Fri, 5 Mar 2010 01:54:47 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:XCYzfhdPk4UKEwM2IfFLEnHl4YmiIDMg@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o258slPQ005881; Fri, 5 Mar 2010 01:54:47 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o258skhk005880; Fri, 5 Mar 2010 01:54:46 -0700 Date: Fri, 5 Mar 2010 01:54:46 -0700 From: "Brian F. G. Bidulock" To: Xiangsong Cui Message-ID: <20100305085446.GA5507@openss7.org> Mail-Followup-To: Xiangsong Cui , sigtran@ietf.org References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <017101cabc31$2f2f7860$3b106f0a@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] Sigtran extension for network management and association changeover. 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: Fri, 05 Mar 2010 08:54:55 -0000 Xiangsong, Please see comments below: Xiangsong Cui wrote: (Fri, 05 Mar 2010 14:57:56) > > I don't think so, it seems the M2PA is reusing the functionality > of MTP2, just using BSN to acknowledge the peer's FSN. Check M2PA before draft 4. > > They are for different purpose (vs application level ack) and > compatible, association changeover is harmless to any application. Additional complexity and performance impact is not harmless. > In fact, if the peer doesn't support CORID, the only benefit relies on > the buffer of local SPP. However, most UA SPPs don't provide buffering > function, so what can these UA SPPs get in this situation? Standards compliant UAs must buffer to support AS-PENDING state. > > I can't agree changeover is a local feature. If you only want > time-controlled changeover, you may use SCTP Receive Unsent > Message primitive defined in RFC4960, ignoring the sent but not > acknowledged messages, why buffer the unsent messages in UA > layer? No you cannot because you risk message duplication which is 3 orders of magnitude worse than message loss for SS7. > > As you said in your draft, local implementation is not engough > for the expected benefit, and we do wish a feasible solution for > the high-performance Sigtran network. No, that's not what I said. Local implementation is not enough for the _full_ benefit. Nevertheless there is still _benefit_ to be had by one or both ends performing the Interworking Procedures. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Xiangsong.Cui@huawei.com Fri Mar 5 01:41:22 2010 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 875123A8F3A for ; Fri, 5 Mar 2010 01:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, STOX_REPLY_TYPE=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 y5d9LxikFry8 for ; Fri, 5 Mar 2010 01:41:21 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 297603A8448 for ; Fri, 5 Mar 2010 01:41:21 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYS0068AYWX9Q@szxga02-in.huawei.com> for sigtran@ietf.org; Fri, 05 Mar 2010 17:41:21 +0800 (CST) Received: from c00111037 ([10.111.16.59]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYS0076TYWW6B@szxga02-in.huawei.com> for sigtran@ietf.org; Fri, 05 Mar 2010 17:41:21 +0800 (CST) Date: Fri, 05 Mar 2010 17:41:20 +0800 From: Xiangsong Cui To: bidulock@openss7.org Message-id: <02bb01cabc48$0335b8c0$3b106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> <20100305085446.GA5507@openss7.org> Cc: sigtran@ietf.org Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. 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, 05 Mar 2010 09:41:22 -0000 Dear Brian, Please see in line. Thanks, Xiangsong ----- Original Message ----- From: "Brian F. G. Bidulock" To: "Xiangsong Cui" Cc: Sent: Friday, March 05, 2010 4:54 PM Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. > Xiangsong, > > Please see comments below: > > Xiangsong Cui wrote: (Fri, 05 Mar 2010 14:57:56) >> >> I don't think so, it seems the M2PA is reusing the functionality >> of MTP2, just using BSN to acknowledge the peer's FSN. > > Check M2PA before draft 4. I will check that, but I don't understand its relation with our dicussion, in you previous mail, " M2PA first attempted to use SCTP's transport layer ack in its functionality but it became impossible." How does the impossibility impact association changeover? > >> >> They are for different purpose (vs application level ack) and >> compatible, association changeover is harmless to any application. > > Additional complexity and performance impact is not harmless. Firstly, the changeover does happen in very special situation, maybe less than 0.01% probability, even there is some impact, it is very little. Comparing with corid approach (each message tagging and buffering, etc.), is it a heavy load? Secondly, exchanging a chunk pair and updating the buffer queue with the selceted acknowledged information, will those bring burden to SCTP? these are basic operations in SCTP. I think this is much less the quasi-transport function in SPP layer. > >> In fact, if the peer doesn't support CORID, the only benefit relies on >> the buffer of local SPP. However, most UA SPPs don't provide buffering >> function, so what can these UA SPPs get in this situation? > > Standards compliant UAs must buffer to support AS-PENDING state. We are talking changeover, which does only happen in initiating-active state. I don't think it is appropriate to expand the AS-pending operations (e.g. buffer) to active state. > >> >> I can't agree changeover is a local feature. If you only want >> time-controlled changeover, you may use SCTP Receive Unsent >> Message primitive defined in RFC4960, ignoring the sent but not >> acknowledged messages, why buffer the unsent messages in UA >> layer? > > No you cannot because you risk message duplication which is 3 > orders of magnitude worse than message loss for SS7. I don't understand your comment here, if you retrieve unsent messages and resend them, how does the peer get duplicated message? > >> >> As you said in your draft, local implementation is not engough >> for the expected benefit, and we do wish a feasible solution for >> the high-performance Sigtran network. > > No, that's not what I said. Local implementation is not enough > for the _full_ benefit. Nevertheless there is still _benefit_ > to be had by one or both ends performing the Interworking Procedures. *We* expect the higher benefit. Before the huge Time-Bandwidth Product, time-controlled changeover is near to non-changeover, because there are too much sent but unacknowledged messages, undetermined in the floating way. Regards, Xiangsong > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ From David.Laight@ACULAB.COM Fri Mar 5 01:52:27 2010 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 DD4B928C212 for ; Fri, 5 Mar 2010 01:52:27 -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 CQI9VLNazmj9 for ; Fri, 5 Mar 2010 01:52:27 -0800 (PST) Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by core3.amsl.com (Postfix) with SMTP id B5F9D3A8F44 for ; Fri, 5 Mar 2010 01:52:26 -0800 (PST) Received: (qmail 25081 invoked from network); 5 Mar 2010 09:52:28 -0000 Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 5 Mar 2010 09:52:28 -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 21949-08 for ; Fri, 5 Mar 2010 09:52:27 +0000 (GMT) Received: (qmail 25067 invoked by uid 599); 5 Mar 2010 09:52:27 -0000 Received: from unknown (HELO saturn3.Aculab.com) (10.202.163.5) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Fri, 05 Mar 2010 09:52:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Mar 2010 09:52:24 -0000 Message-ID: In-Reply-To: <02bb01cabc48$0335b8c0$3b106f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Sigtran extension for network management and association changeover. thread-index: Acq8SAmz6+4hZgU+Sf2SAsB6/vmaKgAADhUw From: "David Laight" To: "Xiangsong Cui" X-Virus-Scanned: by iCritical at mx0.aculab.com Cc: sigtran@ietf.org Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. 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, 05 Mar 2010 09:52:28 -0000 =20 > > No you cannot because you risk message duplication which is 3 > > orders of magnitude worse than message loss for SS7. >=20 > I don't understand your comment here, if you retrieve unsent messages > and resend them, how does the peer get duplicated message? Because you need to retrieve messages which the far end hasn't received, not those you have not received an ack for. In general all messages will have been sent (limited by the TX window), so there will almost never be unsent messages. The MTP3 retrieval procedures collect the sequence number of the last received message through an alternate channel (another signalling link) so that duplicates are avoided. Clearly and implementation which tied SCTP and M2PA together could obtain the relevant messages from one set of saved buffers - but that would be hidious layer-breaking. The main problem I see with using SCTP as a replacement for MTP2 (even as M3UA - never mind M2PA) is that, at least with the default timers, the detection of broken network links is exceptionally lethargic. SCTP also seems to have a habit of sending data down unverified (by heartbeat or other response) network links. David From Xiangsong.Cui@huawei.com Fri Mar 5 02:01:43 2010 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 DB4A728C226 for ; Fri, 5 Mar 2010 02:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, STOX_REPLY_TYPE=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 olwBVVEFmULl for ; Fri, 5 Mar 2010 02:01:43 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id D39E028C222 for ; Fri, 5 Mar 2010 02:01:42 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYS006H9ZUV9Q@szxga02-in.huawei.com> for sigtran@ietf.org; Fri, 05 Mar 2010 18:01:43 +0800 (CST) Received: from c00111037 ([10.111.16.59]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYS00K21ZUU92@szxga02-in.huawei.com> for sigtran@ietf.org; Fri, 05 Mar 2010 18:01:43 +0800 (CST) Date: Fri, 05 Mar 2010 18:01:41 +0800 From: Xiangsong Cui To: David Laight Message-id: <02e601cabc4a$db204f50$3b106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: sigtran@ietf.org Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. 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, 05 Mar 2010 10:01:44 -0000 Dear David, Thank you for your response. I want to say there is another primitive, Receive Unacknowledged Message. If we just retrieve unsent messages, but not unacknowledged messages, duplication will never happen. If there is no unsent messages, then the sender will resend nothing. The duration of association failure detection is another issue, I agree it does impact the changeover performance. Regards Xiangsong ----- Original Message ----- From: "David Laight" To: "Xiangsong Cui" Cc: Sent: Friday, March 05, 2010 5:52 PM Subject: RE: [Sigtran] Sigtran extension for network management and association changeover. > > No you cannot because you risk message duplication which is 3 > > orders of magnitude worse than message loss for SS7. > > I don't understand your comment here, if you retrieve unsent messages > and resend them, how does the peer get duplicated message? Because you need to retrieve messages which the far end hasn't received, not those you have not received an ack for. In general all messages will have been sent (limited by the TX window), so there will almost never be unsent messages. The MTP3 retrieval procedures collect the sequence number of the last received message through an alternate channel (another signalling link) so that duplicates are avoided. Clearly and implementation which tied SCTP and M2PA together could obtain the relevant messages from one set of saved buffers - but that would be hidious layer-breaking. The main problem I see with using SCTP as a replacement for MTP2 (even as M3UA - never mind M2PA) is that, at least with the default timers, the detection of broken network links is exceptionally lethargic. SCTP also seems to have a habit of sending data down unverified (by heartbeat or other response) network links. David From bidulock@openss7.org Fri Mar 5 05:05:57 2010 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 E3A083A8B0A for ; Fri, 5 Mar 2010 05:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 yGr+ppshDkVd for ; Fri, 5 Mar 2010 05:05:56 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id C3DFA3A87B0 for ; Fri, 5 Mar 2010 05:05:55 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:cBj3DP3+a5e5C2gnenqn8SUaHgMbh0OJ@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o25D5qn9023311; Fri, 5 Mar 2010 06:05:52 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:H++MlVDDdmBC1aIMuJfjWy2vew5b0jJc@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o25D5q14012568; Fri, 5 Mar 2010 06:05:52 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o25D5phk012567; Fri, 5 Mar 2010 06:05:51 -0700 Date: Fri, 5 Mar 2010 06:05:51 -0700 From: "Brian F. G. Bidulock" To: Xiangsong Cui Message-ID: <20100305130551.GA4024@openss7.org> Mail-Followup-To: Xiangsong Cui , sigtran@ietf.org References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> <20100305085446.GA5507@openss7.org> <02bb01cabc48$0335b8c0$3b106f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02bb01cabc48$0335b8c0$3b106f0a@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] Sigtran extension for network management and association changeover. 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: Fri, 05 Mar 2010 13:05:58 -0000 Xiangsong, Diversion of traffic does not always occur as a result of association failure. It can also result from: deactivation of an AS at an ASP (ASPIA, ASPDN) deactivation of an AS at an SGP (unsolicited ASPIA Ack or ASPDN Ack) activation of an AS at an ASP or SGP (ASPAC, ASPAC Ack) In these cases where the association has not failed, and because retrieving unsent messages is only defined for SCTP after association failure, these approaches will risk loss and duplication. SCTP acknowledgements only acknowledge that the SCTP peer received a portion of a message. They do not acknowledge that the UA peer received the message at all. For example, the UA peer could close a failed association, losing all messages in the receive buffer. Withholding SCTP acknowledgement until the message is actually read from the receive buffer by the ULP is not something that tsvwg wanted to do. Putting another layer of end-to-end acknowledgement in SCTP to acknowledge on a per-stream basis is not necessary for most other applications. Instead of performing this layering, an application layer acknowledgement from ULP-to-ULP is more appropriate. This is the concensus that was reached. When SCTP detects a restart condition, it is permitted by the SCTP specification to discard all queued (send and receive) messages. Once an SCTP restart has occurred, the SCTP can no longer acknowledge messages from the previous association; however, the UA can. SCTP does not stop messages from being placed into the receive buffer that cannot be acknowledged to the far end (e.g. because the association has already failed). A UA level acknowlegement (Correlation Id/Ack) and flushing (BEAT/ACK) handles all these cases, and in particular the ones where the association has not failed. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Fri Mar 5 05:25:45 2010 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 08DB53A8A5E for ; Fri, 5 Mar 2010 05:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 fjfHj077BJhT for ; Fri, 5 Mar 2010 05:25:44 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id CFE093A8339 for ; Fri, 5 Mar 2010 05:25:43 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:TyrL9+FXJbzO/gSxaNMx4KcpV78mp2W1@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o25DPhD3023645; Fri, 5 Mar 2010 06:25:43 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:uuvAb8fU3mwkCuaN0vvLZnZM+3utm8tB@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o25DPhsr013098; Fri, 5 Mar 2010 06:25:43 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o25DPhF6013097; Fri, 5 Mar 2010 06:25:43 -0700 Date: Fri, 5 Mar 2010 06:25:43 -0700 From: "Brian F. G. Bidulock" To: Xiangsong Cui Message-ID: <20100305132543.GB4024@openss7.org> Mail-Followup-To: Xiangsong Cui , sigtran@ietf.org References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> <20100305085446.GA5507@openss7.org> <02bb01cabc48$0335b8c0$3b106f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02bb01cabc48$0335b8c0$3b106f0a@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] Sigtran extension for network management and association changeover. 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: Fri, 05 Mar 2010 13:25:45 -0000 Xiangsong, Xiangsong Cui wrote: (Fri, 05 Mar 2010 17:41:20) > >>As you said in your draft, local implementation is not engough > >>for the expected benefit, and we do wish a feasible solution for > >>the high-performance Sigtran network. > > > >No, that's not what I said. Local implementation is not enough > >for the _full_ benefit. Nevertheless there is still _benefit_ > >to be had by one or both ends performing the Interworking Procedures. > > *We* expect the higher benefit. Before the huge Time-Bandwidth Product, > time-controlled changeover is near to non-changeover, because there are > too much sent but unacknowledged messages, undetermined in the floating way. Then you do not want SS7 either. International SS7 and many national variants (e.g. ETSI) permit an MTP implementation to _always_ use time-controlled changeover instead of sequenced changeover. (This includes satellite links by the way.) This is because there are cases where message missequencing can occur when changing over. It was never the intention of SIGTRAN to improve upon SS7 in this way. If you try to use SIGTRAN in an environment where even traditional SS7 will not work, it is likely to fail. There are implementors in this WG that swear by the time-controlled method, and that is one of the reasons why the corid draft never moved forward. An example where sequenced changeover will not work is where the failed association has a long delay and the alternate association has a short delay. See other examples in section 1.4.5 in the corid draft. Because SCTP does not know anything about the traffic flows driving its streams, messages received last on the failed or deactivated association might be processed after the first messages received on the new association, resulting in significant message mis-sequencing. Again, message discard or message delay is better than mis-sequencing for SS7, so time-controlled or flushing (BEAT/ACK) approaches are better in this regard. I don't think that you have thought this out. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From cbenson@adax.com Fri Mar 5 11:46:41 2010 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 08DBD28C327 for ; Fri, 5 Mar 2010 11:46:41 -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 j7uC1urR6hSd for ; Fri, 5 Mar 2010 11:46:40 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id BD5A23A8C13 for ; Fri, 5 Mar 2010 11:46:39 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 126FF120A81; Fri, 5 Mar 2010 11:46:42 -0800 (PST) Received: by adax (Postfix, from userid 243) id BCB088E52B; Fri, 5 Mar 2010 11:50:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id B6E228E52A; Fri, 5 Mar 2010 11:50:43 -0800 (PST) Date: Fri, 5 Mar 2010 11:50:43 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: "Brian F. G. Bidulock" In-Reply-To: <20100305055447.GB31145@openss7.org> Message-ID: References: <89D32649C0790143AB985A5BF77A104F02F4E063@etsmsg-hkexm05.etsmsg.org> <20100304200759.GA3165@openss7.org> <89D32649C0790143AB985A5BF77A104F02F4E421@etsmsg-hkexm05.etsmsg.org> <20100305055447.GB31145@openss7.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: sigtran@ietf.org, Amir.Khan@Emerson.com Subject: Re: [Sigtran] M3UA Notification and Routing Context 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, 05 Mar 2010 19:46:41 -0000 Amir and Brian, In similar vein to CONDITIONAL Routing Context in NOTIFY, isn't the presence of Network Appearance also CONDITIONAL rather than OPTIONAL in many of the M3UA message formats? With thanks from Chris Benson. On Thu, 4 Mar 2010, Brian F. G. Bidulock wrote: >> Date: Thu, 4 Mar 2010 22:54:47 -0700 >> From: Brian F. G. Bidulock >> To: >> Cc: >> Subject: Re: [Sigtran] M3UA Notification and Routing Context >> >> Amir, >> >> Sure, I suggest you submit an ERRATA. >> >> --brian >> >> Amir.Khan@Emerson.com wrote: (Fri, 05 Mar 2010 13:27:28) >> > >> > Brian, >> > >> > >> > Than I guess RFC should clearly state this, rather than saying it just >> > "optional". Can we treat this as a update in M3UA RFC. >> > >> > >> > Thanks >> > aamir >> > >> > >> > >> > -----Original Message----- >> > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] >> > Sent: Friday, March 05, 2010 1:38 AM >> > To: Khan, Amir [NETPWR/INDIA/HYDE] >> > Cc: sigtran@ietf.org >> > Subject: Re: [Sigtran] M3UA Notification and Routing Context >> > >> > Amir, >> > >> > RC should likely be marked "conditional" instead of "optional". >> > >> > --brian >> > >> > Amir.Khan@Emerson.com wrote: (Thu, 04 Mar 2010 21:42:20) >> > > >> > > Hi All, >> > > >> > > >> > > >> > > Does it become mandatory for SG to send Notify message ("Alternate >> > ASP >> > > Active") with Routing Context, when the concerned ASP is a part of >> > > multiple AS. So that the concerned ASP can use this RC to become >> > > INACTIVE for the related AS. >> > > >> > > >> > > >> > > E.g. If ASP1 is Actively processing traffic for both AS1(Override) >> > > and AS2(Loadshare) and another ASP2 of AS1 becomes ACTIVE, Do SG >> > then >> > > needs to send Notify message ("Alternate ASP Active") with AS1 >> > Routing >> > > Context, which ASP1 will use to become INACTIVE for AS1. >> > > >> > > >> > > >> > > >> > > >> > > Please comment. >> > > >> > > >> > > >> > > Thanks >> > > >> > > aamir >> > >> > > _______________________________________________ >> > > 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 >> >> -- >> Brian F. G. Bidulock >> bidulock@openss7.org >> http://www.openss7.org/ >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran >> From bidulock@openss7.org Fri Mar 5 11:54:15 2010 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 336E128C33E for ; Fri, 5 Mar 2010 11:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.049, 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 q20AAeM5uxrw for ; Fri, 5 Mar 2010 11:54:14 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 2B2EF28C338 for ; Fri, 5 Mar 2010 11:54:14 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:5VbHl0fdMdiojEP0gvywfCIjpaugqUh7@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o25Js0L7030335; Fri, 5 Mar 2010 12:54:00 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:8zc98dIrRV+p5PoZzDI20KyToDeSn/hu@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o25Js060026116; Fri, 5 Mar 2010 12:54:00 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o25Js0oL026115; Fri, 5 Mar 2010 12:54:00 -0700 Date: Fri, 5 Mar 2010 12:54:00 -0700 From: "Brian F. G. Bidulock" To: Chris Benson Message-ID: <20100305195400.GA26055@openss7.org> Mail-Followup-To: Chris Benson , sigtran@ietf.org, Amir.Khan@Emerson.com References: <89D32649C0790143AB985A5BF77A104F02F4E063@etsmsg-hkexm05.etsmsg.org> <20100304200759.GA3165@openss7.org> <89D32649C0790143AB985A5BF77A104F02F4E421@etsmsg-hkexm05.etsmsg.org> <20100305055447.GB31145@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, Amir.Khan@Emerson.com Subject: Re: [Sigtran] M3UA Notification and Routing Context 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: Fri, 05 Mar 2010 19:54:15 -0000 Chris, How so? I think that NA really is "optional". --brian Chris Benson wrote: (Fri, 05 Mar 2010 11:50:43) > Amir and Brian, > > In similar vein to CONDITIONAL Routing Context in NOTIFY, isn't > the presence of Network Appearance also CONDITIONAL rather than > OPTIONAL in many of the M3UA message formats? > > With thanks from Chris Benson. > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From cbenson@adax.com Fri Mar 5 12:05:39 2010 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 833383A8C9A for ; Fri, 5 Mar 2010 12:05:39 -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 F-cWjhdvyxhL for ; Fri, 5 Mar 2010 12:05:38 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id 818043A8C01 for ; Fri, 5 Mar 2010 12:05:38 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 019481209E7; Fri, 5 Mar 2010 12:05:41 -0800 (PST) Received: by adax (Postfix, from userid 243) id A97138E52B; Fri, 5 Mar 2010 12:09:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id A25508E52A; Fri, 5 Mar 2010 12:09:42 -0800 (PST) Date: Fri, 5 Mar 2010 12:09:42 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: "Brian F. G. Bidulock" In-Reply-To: <20100305195400.GA26055@openss7.org> Message-ID: References: <89D32649C0790143AB985A5BF77A104F02F4E063@etsmsg-hkexm05.etsmsg.org> <20100304200759.GA3165@openss7.org> <89D32649C0790143AB985A5BF77A104F02F4E421@etsmsg-hkexm05.etsmsg.org> <20100305055447.GB31145@openss7.org> <20100305195400.GA26055@openss7.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: sigtran@ietf.org, Amir.Khan@Emerson.com Subject: Re: [Sigtran] M3UA Notification and Routing Context 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, 05 Mar 2010 20:05:39 -0000 Brian, I thought Network Appearance "conditionally" mandated in circumstances such as described early in RFC 4666 ... An example scenario is where an SG appears as an element in multiple separate nationl SS7 networks and the same Signalling Point Code may be reused in different networks. Also there's the issue of Network Appearance being used to distinguish between different semantics of Message Priority, Point Code range etc. Can all of this be done satisfactorily (in the presence of multiple separately administered networks) without Network Appearance? This is not an idle question, as I am currently working as an M3UA implementation provider, to assist a customer combining NA and different RC value to distinguish between different SGs and SGPs, all from the same 1 ASP in 1 AS. With thanks for your speedy resposne, from Chris Benson. On Fri, 5 Mar 2010, Brian F. G. Bidulock wrote: >> Date: Fri, 5 Mar 2010 12:54:00 -0700 >> From: Brian F. G. Bidulock >> To: Chris Benson >> Cc: , >> Subject: Re: [Sigtran] M3UA Notification and Routing Context >> >> Chris, >> >> How so? I think that NA really is "optional". >> >> --brian >> >> Chris Benson wrote: (Fri, 05 Mar 2010 11:50:43) >> > Amir and Brian, >> > >> > In similar vein to CONDITIONAL Routing Context in NOTIFY, isn't >> > the presence of Network Appearance also CONDITIONAL rather than >> > OPTIONAL in many of the M3UA message formats? >> > >> > With thanks from Chris Benson. >> > >> >> -- >> Brian F. G. Bidulock >> bidulock@openss7.org >> http://www.openss7.org/ >> From bidulock@openss7.org Fri Mar 5 21:11:17 2010 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 D95D23A906E for ; Fri, 5 Mar 2010 21:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.045, 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 rgMwtV41QhQP for ; Fri, 5 Mar 2010 21:11:16 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id CB1063A906D for ; Fri, 5 Mar 2010 21:11:15 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:iheuh/U91fyNZbXGu8uZ3uZZzGmQZpDb@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o265BD0L007077; Fri, 5 Mar 2010 22:11:13 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:edDSDg+/UC014KkPboYdOSJoXUZYGfkt@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o265BD6B008422; Fri, 5 Mar 2010 22:11:13 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o265BDhW008421; Fri, 5 Mar 2010 22:11:13 -0700 Date: Fri, 5 Mar 2010 22:11:13 -0700 From: "Brian F. G. Bidulock" To: Chris Benson Message-ID: <20100306051113.GA7581@openss7.org> Mail-Followup-To: Chris Benson , sigtran@ietf.org, Amir.Khan@Emerson.com References: <89D32649C0790143AB985A5BF77A104F02F4E063@etsmsg-hkexm05.etsmsg.org> <20100304200759.GA3165@openss7.org> <89D32649C0790143AB985A5BF77A104F02F4E421@etsmsg-hkexm05.etsmsg.org> <20100305055447.GB31145@openss7.org> <20100305195400.GA26055@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, Amir.Khan@Emerson.com Subject: Re: [Sigtran] M3UA Notification and Routing Context 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, 06 Mar 2010 05:11:18 -0000 Chris, Chris Benson wrote: (Fri, 05 Mar 2010 12:09:42) > Brian, > > I thought Network Appearance "conditionally" mandated in > circumstances such as described early in RFC 4666 ... > An example scenario is where an SG appears as an > element in multiple separate nationl SS7 networks > and the same Signalling Point Code may be reused > in different networks. > Also there's the issue of Network Appearance being used to > distinguish between different semantics of Message Priority, > Point Code range etc. > > Can all of this be done satisfactorily (in the presence of > multiple separately administered networks) without Network > Appearance? Yes, by routing context. Routing context is conditional. NA is optional in most messages. > This is not an idle question, as I am currently working > as an M3UA implementation provider, to assist a customer > combining NA and different RC value to distinguish between > different SGs and SGPs, all from the same 1 ASP in 1 AS. There used to be a weird case where there could be more than one NA in an implied AS, and you can still see some text in the RFC (e.g. under registration request) that alludes to that, but nobody could describe the management of such a beast and those that advocated it in the first place had long left the WG. If that is the case you are thinking of, then it is really not "conditional" as that whole weird multiple-NA-implied-AS thing is completely "optional". Normally one AS represents one SPMC in one NA. In the weird-multiple-NA-implied-AS case, there are all kinds of things that might be considered conditional, but as they are not identified by the spec, it is best to leave them labelled simply "optional", which is true for all described cases. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Xiangsong.Cui@huawei.com Fri Mar 5 21:36:18 2010 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 D15B828C150 for ; Fri, 5 Mar 2010 21:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.294 X-Spam-Level: ** X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, 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 dBImibhcVvOd for ; Fri, 5 Mar 2010 21:36:17 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8506F28C0F9 for ; Fri, 5 Mar 2010 21:36:16 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYU00BX0I881V@szxga04-in.huawei.com> for sigtran@ietf.org; Sat, 06 Mar 2010 13:36:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYU00A8RI88D1@szxga04-in.huawei.com> for sigtran@ietf.org; Sat, 06 Mar 2010 13:36:08 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [222.131.243.26]) by szxmc03-in.huawei.com (mshttpd); Sat, 06 Mar 2010 13:36:08 +0800 Date: Sat, 06 Mar 2010 13:36:08 +0800 From: Xiangsong Cui In-reply-to: <20100305130551.GA4024@openss7.org> To: bidulock@openss7.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_0Xek3ke7nj2FmJmu5T7W8A)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> <20100305085446.GA5507@openss7.org> <02bb01cabc48$0335b8c0$3b106f0a@china.huawei.com> <20100305130551.GA4024@openss7.org> Cc: sigtran@ietf.org Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. 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: Sat, 06 Mar 2010 05:36:19 -0000 This is a multi-part message in MIME format. --Boundary_(ID_0Xek3ke7nj2FmJmu5T7W8A) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Dear Brian=2C ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Brian F=2E G=2E Bidulock=22 =3Cbidulock=40openss= 7=2Eorg=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =C8=FD=D4=C2 5=C8=D5=2C 2010 =CF=C2= =CE=E79=3A06 =D6=F7=CC=E2=3A Re=3A =5BSigtran=5D Sigtran extension for network managem= ent and association changeover=2E =CA=D5=BC=FE=C8=CB=3A Xiangsong Cui =3CXiangsong=2ECui=40huawei=2Ecom=3E =B3=AD=CB=CD=3A sigtran=40ietf=2Eorg =3E Xiangsong=2C =3E = =3E Diversion of traffic does not always occur as a result of =3E association failure=2E It can also result from=3A =3E = =3E deactivation of an AS at an ASP (ASPIA=2C ASPDN) =3E deactivation of an AS at an SGP (unsolicited ASPIA Ack or ASPDN Ack) =3E activation of an AS at an ASP or SGP (ASPAC=2C ASPAC Ack) Deactivation is the courtyard of AS-pending buffer=2C changeover is unnecessary at this time=2E UA layer can deal with that=2E And=2C does activation need changeover=3F =3E = =3E In these cases where the association has not failed=2C and because =3E retrieving unsent messages is only defined for SCTP after =3E association failure=2C these approaches will risk loss and =3E duplication=2E =3E = =3E SCTP acknowledgements only acknowledge that the SCTP peer =3E received a portion of a message=2E They do not acknowledge that =3E the UA peer received the message at all=2E For example=2C the UA =3E peer could close a failed association=2C losing all messages in =3E the receive buffer=2E I agree this point=2C but this doesn=27t impact association changeover=2E= Association failure may be terminal/endpoint error/failure or = connection error/failure=2E If it is connection error=2C the ULP of course can restore the messages cached in the receive buffer queue (in the terminal) of the failure association=2C no message = lossing=2E If it is the termainal/endpoint error=2C some messages = would be lost=2E This situation is very similar to MTP2=2E If it is a link error=2C sequenced chaneover is OK=2C but if it is the MTP2 = terminal error=2C MTP3 can not retrieve the sequence number=2C and = only time-controlled changeover can be appllied=2E messages lossing can not be avoided=2E =3E = =3E Withholding SCTP acknowledgement until the message is actually =3E read from the receive buffer by the ULP is not something that =3E tsvwg wanted to do=2E = I agree this=2E Putting another layer of end-to-end =3E acknowledgement in SCTP to acknowledge on a per-stream basis is =3E not necessary for most other applications=2E Instead of =3E performing this layering=2C an application layer acknowledgement =3E from ULP-to-ULP is more appropriate=2E This is the concensus that =3E was reached=2E I am wonderring at this point=2E Do you mean user adaptation is unappropriate and we need = peer-to-peer adaptation=3F If that is yes=2C I agree your corid draft is appropriate for that (note local implementation is = almost helpless because of the huge TBP)=2C while association = changeoveris is only for user adaptation=2E =3E = =3E When SCTP detects a restart condition=2C it is permitted by the =3E SCTP specification to discard all queued (send and receive) =3E messages=2E Once an SCTP restart has occurred=2C the SCTP can no =3E longer acknowledge messages from the previous association=3B =3E however=2C the UA can=2E Restart is another issue=2C not in the scope of association = changeover=2E =3E = =3E SCTP does not stop messages from being placed into the receive =3E buffer that cannot be acknowledged to the far end (e=2Eg=2E because =3E the association has already failed)=2E =3E = =3E A UA level acknowlegement (Correlation Id/Ack) and flushing =3E (BEAT/ACK) handles all these cases=2C and in particular the ones =3E where the association has not failed=2E Yes=2C but maybe =22A PA level=22 (peer-to-peer) is more exact=2E Regards=2C Xiangsong =3E = =3E --brian =3E = =3E -- = =3E Brian F=2E G=2E Bidulock =3E bidulock=40openss7=2Eorg =3E http=3A//www=2Eopenss7=2Eorg/ =3E --Boundary_(ID_0Xek3ke7nj2FmJmu5T7W8A) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for Xiangsong Cui begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_0Xek3ke7nj2FmJmu5T7W8A)-- From Xiangsong.Cui@huawei.com Fri Mar 5 21:39:13 2010 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 15CA728C126 for ; Fri, 5 Mar 2010 21:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.294 X-Spam-Level: ** X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, 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 XiTUC4GrnVjh for ; Fri, 5 Mar 2010 21:39:11 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 19A303A8BC7 for ; Fri, 5 Mar 2010 21:39:11 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYU004N9ID3JW@szxga04-in.huawei.com> for sigtran@ietf.org; Sat, 06 Mar 2010 13:39:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYU00DYAID33C@szxga04-in.huawei.com> for sigtran@ietf.org; Sat, 06 Mar 2010 13:39:03 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [222.131.243.26]) by szxmc03-in.huawei.com (mshttpd); Sat, 06 Mar 2010 13:39:03 +0800 Date: Sat, 06 Mar 2010 13:39:03 +0800 From: Xiangsong Cui In-reply-to: <20100305132543.GB4024@openss7.org> To: bidulock@openss7.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_ZnZCAK87B6+epwTYgDThCQ)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> <20100305085446.GA5507@openss7.org> <02bb01cabc48$0335b8c0$3b106f0a@china.huawei.com> <20100305132543.GB4024@openss7.org> Cc: sigtran@ietf.org Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. 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: Sat, 06 Mar 2010 05:39:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ZnZCAK87B6+epwTYgDThCQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Dear Brian=2C ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Brian F=2E G=2E Bidulock=22 =3Cbidulock=40openss= 7=2Eorg=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =C8=FD=D4=C2 5=C8=D5=2C 2010 =CF=C2= =CE=E79=3A26 =D6=F7=CC=E2=3A Re=3A =5BSigtran=5D Sigtran extension for network managem= ent and association changeover=2E =CA=D5=BC=FE=C8=CB=3A Xiangsong Cui =3CXiangsong=2ECui=40huawei=2Ecom=3E =B3=AD=CB=CD=3A sigtran=40ietf=2Eorg =3E Xiangsong=2C =3E = =3E Xiangsong Cui wrote=3A (Fri=2C 05 Mar 2010 17=3A= 41=3A20) =3E =3E =3E=3EAs you said in your draft=2C local implementation is not en= gough =3E =3E =3E=3Efor the expected benefit=2C and we do wish a feasible solut= ion = =3E for = =3E =3E =3E=3Ethe high-performance Sigtran network=2E =3E =3E =3E =3E =3E =3ENo=2C that=27s not what I said=2E Local implementation is not= enough =3E =3E =3Efor the =5Ffull=5F benefit=2E Nevertheless there is still =5F= benefit=5F =3E =3E =3Eto be had by one or both ends performing the Interworking = =3E Procedures=2E=3E = =3E =3E *We* expect the higher benefit=2E Before the huge Time-Bandwidth = =3E Product=2C=3E time-controlled changeover is near to non-changeover=2C= = =3E because there are =3E =3E too much sent but unacknowledged messages=2C undetermined in the = =3E floating way=2E =3E = =3E Then you do not want SS7 either=2E International SS7 and many nation= al =3E variants (e=2Eg=2E ETSI) permit an MTP implementation to =5Falways=5F= use =3E time-controlled changeover instead of sequenced changeover=2E (This =3E includes satellite links by the way=2E) This is because there are =3E cases where message missequencing can occur when changing over=2E It= =3E was never the intention of SIGTRAN to improve upon SS7 in this way=2E= =3E If you try to use SIGTRAN in an environment where even traditional SS= 7 =3E will not work=2C it is likely to fail=2E I can=27t agree this logic=2C we prefer sequenced changeover not means we are against time-controlled changeover=2C we just expect better result=2C on the basis of time-controlled changeover=2E =3E = =3E There are implementors in this WG that swear by the time-controlled =3E method=2C and that is one of the reasons why the corid draft never =3E moved forward=2E I think it is because you are designing a peer-to-peer adaption=2C = however=2C user adaption has been widely applied in the network=2C and it is very difficult to update the complex implementation=2E There is not any relation to time-controlled changeover=2E =3E = =3E An example where sequenced changeover will not work is where the = =3E failedassociation has a long delay and the alternate association = =3E has a short =3E delay=2E See other examples in section 1=2E4=2E5 in the corid draft=2E= =3E = =3E Because SCTP does not know anything about the traffic flows = =3E driving its =3E streams=2C messages received last on the failed or deactivated = =3E associationmight be processed after the first messages received on = =3E the new association=2C = =3E resulting in significant message mis-sequencing=2E Again=2C message = =3E discardor message delay is better than mis-sequencing for SS7=2C so = =3E time-controlled =3E or flushing (BEAT/ACK) approaches are better in this regard=2E =3E = =3E I don=27t think that you have thought this out=2E It is not as you thought=2C if you read the draft you would find that sequence delivery has been considerred in the draft=2E Regards=2C Xiangsong =3E = =3E --brian =3E = =3E -- = =3E Brian F=2E G=2E Bidulock =3E bidulock=40openss7=2Eorg =3E http=3A//www=2Eopenss7=2Eorg/ =3E --Boundary_(ID_ZnZCAK87B6+epwTYgDThCQ) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for Xiangsong Cui begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_ZnZCAK87B6+epwTYgDThCQ)-- From bidulock@openss7.org Sat Mar 6 04:11:08 2010 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 83B7528C1E6 for ; Sat, 6 Mar 2010 04:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.041, 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 o67f3Q6GchUt for ; Sat, 6 Mar 2010 04:11:07 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 16E6328C11D for ; Sat, 6 Mar 2010 04:11:06 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:WdE3jvDzu/Yl20wvhI68Usrpqaw8myOw@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o26CB1np014121; Sat, 6 Mar 2010 05:11:01 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:8XpIAPD8fueQrmZfabM5yrk4IxKw2bm+@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o26CB1Ff019517; Sat, 6 Mar 2010 05:11:01 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o26CB1Sg019516; Sat, 6 Mar 2010 05:11:01 -0700 Date: Sat, 6 Mar 2010 05:11:01 -0700 From: "Brian F. G. Bidulock" To: Xiangsong Cui Message-ID: <20100306121101.GA18634@openss7.org> Mail-Followup-To: Xiangsong Cui , sigtran@ietf.org References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> <20100305085446.GA5507@openss7.org> <02bb01cabc48$0335b8c0$3b106f0a@china.huawei.com> <20100305132543.GB4024@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] Sigtran extension for network management and association changeover. 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, 06 Mar 2010 12:11:09 -0000 Xiangsong, I read draft-cui-tsvwg-assoc-changeover-00 and I can really see no use for it in SIGTRAN UAs. Take the following example for M3UA (fairly typical arrangement): ______________ | _______ | __|_| SGP | | / _|_| 1 | | / / | |_______| | / / | _______ NIF | / / __|_| SGP | | / / / _|_| 2 | | _______ _______/ / / / | |_______| | | ASP |________/_/ / |______________| | 1 |____ / / SG1 |_______|___ \ / / _______ ___\_X___/ | ASP |____X \ | 2 |____ \ \ ______________ |_______|___ \ \ \ | _______ | \ \ \ \_____|_|X SGP X| | \ \_\______|_|X 1 X| fails \ \ | |X_____X| | \ \ | _______ NIF | \ \___|_| SGP | | \______|_| 2 | | | |_______| | |______________| SG2 Each ASP and each SGP is a separate SCTP endpoint. Only one association exists between any given ASP and any given SGP. (The above shows 8 associations where 4 are really adequate.) Suppose that SGP1 in SG2 fails causing associations ASP1-SG2/SGP1 and ASP2-SG2/SGP1 to be lost. SG2 must now changeover traffic from these failed associations to ASP1-SG2/SGP2 and ASP2-SG2/SGP2 in a load-sharing fashion. ASP1 must also changeover traffic from failed ASP1-SG2/SGP1 to ASP1-SG2/SGP2 and ASP2 must changeover traffic from failed ASP2-SG2/SGP1 to ASP2-SG2-SGP2. How does your draft keep messages from being lost, duplicated or mis-sequenced at the NIF at SG2 and at each of ASP1 and ASP2? Suppose that SGP1 in SG2 recovers. Traffic must now change back to SGP1 in SG2 when associations ASP1-SG2/SGP1 and ASP2-SG2/SGP1 are reformed and activated. How does your draft keep messages from being lost, duplicated, or mis-sequenced during the changeback? Suppose that instead of SG2/SGP1 failing, that SG2/SGP1 becomes isolated from the NIF at SG2 for the AS (causing unsolicited ASPIA Ack). Associations ASP1-SG2/SGP1 and ASP2-SG2/SGP1 do not fail and are carrying other traffic. Nevertheless, the same changeover for the AS must be performed as though SGP1 failed. How does your draft keep messages from being lost, duplicated or mis-sequenced at the NIF at SG2 and at each of ASP1 and ASP2? If your draft cannot handle these simple scenarios, it is not of much use. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Xiangsong.Cui@huawei.com Sun Mar 7 03:16:42 2010 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 D89173A840C for ; Sun, 7 Mar 2010 03:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.894 X-Spam-Level: ** X-Spam-Status: No, score=2.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, 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 95DqNWYXRToL for ; Sun, 7 Mar 2010 03:16:41 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id B38B228C11C for ; Sun, 7 Mar 2010 03:16:40 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYW00GE2SNKM9@szxga02-in.huawei.com> for sigtran@ietf.org; Sun, 07 Mar 2010 19:16:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYW008SSSNK77@szxga02-in.huawei.com> for sigtran@ietf.org; Sun, 07 Mar 2010 19:16:32 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [123.113.113.109]) by szxmc03-in.huawei.com (mshttpd); Sun, 07 Mar 2010 19:16:32 +0800 Date: Sun, 07 Mar 2010 19:16:32 +0800 From: Xiangsong Cui In-reply-to: <20100306121101.GA18634@openss7.org> To: bidulock@openss7.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_zif7AL8yjxdxxSX0n9c6PQ)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <09dd01cabb4d$8582acd0$3b106f0a@china.huawei.com> <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> <20100305085446.GA5507@openss7.org> <02bb01cabc48$0335b8c0$3b106f0a@china.huawei.com> <20100305132543.GB4024@openss7.org> <20100306121101.GA18634@openss7.org> Cc: sigtran@ietf.org Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. 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: Sun, 07 Mar 2010 11:16:43 -0000 This is a multi-part message in MIME format. --Boundary_(ID_zif7AL8yjxdxxSX0n9c6PQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Dear Brian=2C =3E Suppose that SGP1 in SG2 fails causing associations =3E ASP1-SG2/SGP1 and ASP2-SG2/SGP1 to be lost=2E SG2 must I=27m not very sure about your case=2E If the broken-down SGP in your assumption means the SGP = hardware=2C including SCTP and M3UA protocol stack=2C = sequenced changeover can not be achieved anyway=2E If the broken-down SGP means the SGP process of M3UA = protocol=2C SCTP process should be still active=2C and=2C association should still be in established state=2C and association changeover is unnecessary=2E This is very like the Processor Outage of MTP=2E SCTP buffers the messages and maybe some messages would be lost (queue overflow=2C etc=2E)=2C this depends = on the error in M3UA SGP=2E maybe corid approach = would not be available either=2C because there is = error in the SPP process=2E If the SGP failure means SCTP process crashes down = fully while SGP process of M3UA protocol is active=2C this is infrequent and I cann=27t see the exact scenario=2E On the other hand=2C it is similiar to MTP2 terminal = error=2C MTP3 cann=27t get sequence information of MSU=2C = sequenced changeover is impossible=2E Notice this is seldom case=2C and MTP3 will not append message buffer in MTP3 layer for the extreme changeover=2E So association changeover approach loses nothing = than MTP changeover=2E OK=2C we come to the last case=2C some protocol error happen=2E The association is terminated and it is also a failure in the SGP=2E At this time the SCTP process and M3UA = process are both active=2C and the SCTP process (in the SGP) can also cache the final status and buffered messages = of the broken-down association when it detects the = failure=2E The SCTP process in SGP can select the = alternative association (i=2Ee=2E=2C the association between ASP1 and SGP2 of SG2=2C the two associations are both = between the same node pair and both provide service to M3UA)=2E The ASP1 would also detecet the assciation failure=2C cache the status and the buffered messages of the = broken-down association and select the alternative = association (in this case ASP1 and SG2 would select the same alternative association=2C in the draft different = alternative associations are allowed in different = direction)=2E By now=2C both endpoint cache the enough = infoamtion and they can exchange the acknowledged = sequence number in the alternative association=2E = So the SCTP process of the both endpoint can know = well which messages are received by the peer and = which messages are sent but not received by the peer=2C and they locally know clearly which messages are not sent to the peer=2E In addition=2C they both know well = which messages are received by local SCTP process = but not moved to the ULP=2E The M3UA process can utilize the retrieve primitive defined in RFC4960 to retrieve the messages and resend them to SCTP layer=2E = At this time=2C M3UA has knowen the association failure = and would update the load sharing set=2E And the M3UA = process resend the retrieved messages as it send normal = message to SCTP layer=2E Of course=2C the later messages = that containing same CIC with the retrieved messages = should also be use the same association (i=2Ee=2E=2C the = alternative association)=2E So lossing=2C duplication and mis-sequence would never happen in the sender=2E In the = receiver side=2C the cumulative acknowledged message in = the receive queue (if there is=2C the ULP has not accepted them) would be moved to the receive queue of the = alternative association (still for the same ULP=2C this = point need clarification in the draft)=2C selected = acknowledged messages are reneged and would be resent by the peer=2C unacknowledged would also be resent by the = peer=2E So lossing=2C duplication and mis-sequenc would not happen in the receiver either=2E Well=2C changeover is finished and later is changeback=2E Changeback is not in the scope of the draft because the operations has been implemented in current protocol implementations=2E For example=2C in the load sharing mode=2C e=2Eg=2E n+k=2C if the number of active ASP changes from = m (m=3Cn) to n=2C some traffic would be moved to the new = activated ASP/association=2E and the signalling transport has already been lossless=2C non-dplication and sequenced=2E As a conclusion=2C assocaiton changeover approach is = designed to provide changeover functionality like MTP = (eliminating the gap between sigtran and MTP) and = improve the performance of sigtran network=2E Do I explain the procedure clearly=3F Regards Xiangsong ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Brian F=2E G=2E Bidulock=22 =3Cbidulock=40openss= 7=2Eorg=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C1=F9=2C =C8=FD=D4=C2 6=C8=D5=2C 2010 =CF=C2= =CE=E78=3A11 =D6=F7=CC=E2=3A Re=3A =5BSigtran=5D Sigtran extension for network managem= ent and association changeover=2E =CA=D5=BC=FE=C8=CB=3A Xiangsong Cui =3CXiangsong=2ECui=40huawei=2Ecom=3E =B3=AD=CB=CD=3A sigtran=40ietf=2Eorg =3E Xiangsong=2C =3E = =3E I read draft-cui-tsvwg-assoc-changeover-00 and I can =3E really see no use for it in SIGTRAN UAs=2E =3E = =3E Take the following example for M3UA (fairly typical =3E arrangement)=3A =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =7C =5F=5F=5F=5F=5F=5F=5F =7C =3E =5F=5F=7C=5F=7C SGP =7C =7C =3E / =5F=7C=5F=7C 1 =7C =7C =3E / / =7C =7C=5F=5F=5F=5F=5F=5F=5F=7C =7C =3E / / =7C =5F=5F=5F=5F=5F=5F=5F NIF =7C =3E / / =5F=5F=7C=5F=7C SGP =7C =7C =3E / / / =5F=7C=5F=7C 2 =7C =7C =3E =5F=5F=5F=5F=5F=5F=5F =5F=5F=5F=5F=5F=5F=5F/ / / / =7C =7C=5F=5F=5F= =5F=5F=5F=5F=7C =7C =3E =7C ASP =7C=5F=5F=5F=5F=5F=5F=5F=5F/=5F/ / =7C=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=7C =3E =7C 1 =7C=5F=5F=5F=5F / / SG1 =3E =7C=5F=5F=5F=5F=5F=5F=5F=7C=5F=5F=5F =5C / / =3E =5F=5F=5F=5F=5F=5F=5F =5F=5F=5F=5C=5FX=5F=5F=5F/ =3E =7C ASP =7C=5F=5F=5F=5FX =5C =3E =7C 2 =7C=5F=5F=5F=5F =5C =5C =5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F =3E =7C=5F=5F=5F=5F=5F=5F=5F=7C=5F=5F=5F =5C =5C =5C =7C =5F=5F=5F= =5F=5F=5F=5F =7C =3E =5C =5C =5C =5C=5F=5F=5F=5F=5F=7C=5F=7CX SGP X=7C =7C= =3E =5C =5C=5F=5C=5F=5F=5F=5F=5F=5F=7C=5F=7CX 1 X=7C fail= s =3E =5C =5C =7C =7CX=5F=5F=5F=5F=5FX=7C =7C =3E =5C =5C =7C =5F=5F=5F=5F=5F=5F=5F NIF =7C =3E =5C =5C=5F=5F=5F=7C=5F=7C SGP =7C =7C =3E =5C=5F=5F=5F=5F=5F=5F=7C=5F=7C 2 =7C =7C =3E =7C =7C=5F=5F=5F=5F=5F=5F=5F=7C =7C =3E =7C=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =7C =3E SG2 =3E = =3E Each ASP and each SGP is a separate SCTP endpoint=2E Only =3E one association exists between any given ASP and any =3E given SGP=2E (The above shows 8 associations where 4 are =3E really adequate=2E) =3E = =3E Suppose that SGP1 in SG2 fails causing associations =3E ASP1-SG2/SGP1 and ASP2-SG2/SGP1 to be lost=2E SG2 must =3E now changeover traffic from these failed associations to =3E ASP1-SG2/SGP2 and ASP2-SG2/SGP2 in a load-sharing =3E fashion=2E ASP1 must also changeover traffic from failed =3E ASP1-SG2/SGP1 to ASP1-SG2/SGP2 and ASP2 must changeover =3E traffic from failed ASP2-SG2/SGP1 to ASP2-SG2-SGP2=2E =3E = =3E How does your draft keep messages from being lost=2C =3E duplicated or mis-sequenced at the NIF at SG2 and at =3E each of ASP1 and ASP2=3F =3E = =3E Suppose that SGP1 in SG2 recovers=2E Traffic must now =3E change back to SGP1 in SG2 when associations =3E ASP1-SG2/SGP1 and ASP2-SG2/SGP1 are reformed and =3E activated=2E =3E = =3E How does your draft keep messages from being lost=2C =3E duplicated=2C or mis-sequenced during the changeback=3F =3E = =3E Suppose that instead of SG2/SGP1 failing=2C that SG2/SGP1 =3E becomes isolated from the NIF at SG2 for the AS (causing =3E unsolicited ASPIA Ack)=2E Associations ASP1-SG2/SGP1 and =3E ASP2-SG2/SGP1 do not fail and are carrying other =3E traffic=2E Nevertheless=2C the same changeover for the AS =3E must be performed as though SGP1 failed=2E =3E = =3E How does your draft keep messages from being lost=2C =3E duplicated or mis-sequenced at the NIF at SG2 and at =3E each of ASP1 and ASP2=3F =3E = =3E If your draft cannot handle these simple scenarios=2C it =3E is not of much use=2E =3E = =3E --brian =3E = =3E -- =3E Brian F=2E G=2E Bidulock =3E bidulock=40openss7=2Eorg =3E http=3A//www=2Eopenss7=2Eorg/ =3E --Boundary_(ID_zif7AL8yjxdxxSX0n9c6PQ) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for Xiangsong Cui begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_zif7AL8yjxdxxSX0n9c6PQ)-- From bidulock@openss7.org Mon Mar 8 03:13:35 2010 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 2B4793A6959 for ; Mon, 8 Mar 2010 03:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.038, 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 IOwSluFz-8RQ for ; Mon, 8 Mar 2010 03:13:33 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 682DE3A696D for ; Mon, 8 Mar 2010 03:13:33 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:kmz2O+64eUBO/s5On1kWgFF98vL2fSu+@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o28BDUuW028967; Mon, 8 Mar 2010 04:13:30 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:YcY8WIFaUvzEGrdb82t2FBadi44GBY36@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o28BDURU029745; Mon, 8 Mar 2010 04:13:30 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o28BDLBO029735; Mon, 8 Mar 2010 04:13:21 -0700 Date: Mon, 8 Mar 2010 04:13:21 -0700 From: "Brian F. G. Bidulock" To: Xiangsong Cui Message-ID: <20100308111321.GA605@openss7.org> Mail-Followup-To: Xiangsong Cui , sigtran@ietf.org References: <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> <20100305085446.GA5507@openss7.org> <02bb01cabc48$0335b8c0$3b106f0a@china.huawei.com> <20100305132543.GB4024@openss7.org> <20100306121101.GA18634@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] Sigtran extension for network management and association changeover. 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, 08 Mar 2010 11:13:35 -0000 Xiangsong, Please see comments below: Xiangsong Cui wrote: (Sun, 07 Mar 2010 19:16:32) > Dear Brian, > > > Suppose that SGP1 in SG2 fails causing associations > > ASP1-SG2/SGP1 and ASP2-SG2/SGP1 to be lost. SG2 must > > I'm not very sure about your case. > > If the broken-down SGP in your assumption means the SGP hardware, > including SCTP and M3UA protocol stack, sequenced changeover can not > be achieved anyway. Yes it can, see below. > If the broken-down SGP means the SGP process of M3UA protocol, SCTP > process should be still active, and, association should still be in > established state, and association changeover is unnecessary. This is > very like the Processor Outage of MTP. SCTP buffers the messages and > maybe some messages would be lost (queue overflow, etc.), this depends > on the error in M3UA SGP. maybe corid approach would not be available > either, because there is error in the SPP process. > > If the SGP failure means SCTP process crashes down fully while SGP > process of M3UA protocol is active, this is infrequent and I cann't > see the exact scenario. On the other hand, it is similiar to MTP2 > terminal error, MTP3 cann't get sequence information of MSU, sequenced > changeover is impossible. Notice this is seldom case, and MTP3 will > not append message buffer in MTP3 layer for the extreme changeover. > So association changeover approach loses nothing than MTP changeover. We are talking about SIGTRAN here; nevertheless, these assertions about SS7 are untrue. There is no requirement in SS7 to implement the retransmission buffer in the signaling terminal. Also the sequence number transmitted in a COO or COA is the sequence of the last MSU accepted by MTP-3. This information also is not required to be maintained in the signaling terminal, but may be maintained in MTP-3. Therefore, a signaling terminal can fail and MTP-3 may still be able to both update the retranmission buffer as well as provide the last BSNT in the COO or COA. So, an SS7 implementation may capable of performing a sequenced changeover even under a signaling terminal failure. Now back to SIGTRAN. The case I was presenting was where the SGP fails. This includes SCTP, M3UA and everything else at the SGP. However, the NIF has not failed (because it does not reside in the SGP). CORID permits the NIF to maintain both the "retransmission buffer" and the "sequence number" for the failed SGP. Because the messages sent via the alternate SGP contain tags identifying the "sequence numbering", CORID is capable of lossless changover in this case. So, it appears that association-changover is the only approach that is incapable of lossless changeover in this circumstance. > OK, we come to the last case, some protocol error happen. > The association is terminated and it is also a failure > in the SGP. At this time the SCTP process and M3UA > process are both active, and the SCTP process (in the SGP) > can also cache the final status and buffered messages > of the broken-down association when it detects the > failure. No. It is not the case that the association has broken down. The association is fully functional and is processing traffic for other AS. An isolation has occurred causing one AS via the one SGP to be deactivated only. The remainder of the description of this case (below) is invalid because the association is still active and messages cannot be retrieved from SCTP for an active association. > The SCTP process in SGP can select the alternative association (i.e., > the association between ASP1 and SGP2 of SG2, the two associations are > both between the same node pair and both provide service to M3UA). The > ASP1 would also detecet the assciation failure, cache the status and > the buffered messages of the broken-down association and select the > alternative association (in this case ASP1 and SG2 would select the > same alternative association, in the draft different alternative > associations are allowed in different direction). By now, both > endpoint cache the enough infoamtion and they can exchange the > acknowledged sequence number in the alternative association. So the > SCTP process of the both endpoint can know well which messages are > received by the peer and which messages are sent but not received by > the peer, and they locally know clearly which messages are not sent to > the peer. In addition, they both know well which messages are received > by local SCTP process but not moved to the ULP. The M3UA process can > utilize the retrieve primitive defined in RFC4960 to retrieve the > messages and resend them to SCTP layer. At this time, M3UA has knowen > the association failure and would update the load sharing set. And the > M3UA process resend the retrieved messages as it send normal message > to SCTP layer. Of course, the later messages that containing same CIC > with the retrieved messages should also be use the same association > (i.e., the alternative association). So lossing, duplication and > mis-sequence would never happen in the sender. In the receiver side, > the cumulative acknowledged message in the receive queue (if there is, > the ULP has not accepted them) would be moved to the receive queue of > the alternative association (still for the same ULP, this point need > clarification in the draft), selected acknowledged messages are > reneged and would be resent by the peer, unacknowledged would also be > resent by the peer. So lossing, duplication and mis-sequenc would not > happen in the receiver either. > > Well, changeover is finished and later is changeback. Changeback is > not in the scope of the draft because the operations has been > implemented in current protocol implementations. For example, in the > load sharing mode, e.g. n+k, if the number of active ASP changes from > m (m ASP/association. and the signalling transport has already been > lossless, non-dplication and sequenced. M3UA provides no mechanism to avoid missequencing. Messages transmitted on the new association can arrive in advance of messages still outstanding on the old association. CORID provides explicit procedures (even interworking procedures) to avoid missequencing, as does SS7. > As a conclusion, assocaiton changeover approach is designed to provide > changeover functionality like MTP (eliminating the gap between sigtran > and MTP) and improve the performance of sigtran network. And yet, association-changover does not handle these scenarios. The only situation that it might handle is association failure where the SCTP remains available at both ends, which field experience in SIGTRAN has shown to be the least likely case of failure. Even in that case, CORID approaches are better suited to deal with association failures and do not require any changes whatsoever to SCTP. I am sorry, but I, for one, am unable to support the association-changeover draft. It fails to address scenarios already handled by other approaches, provides no solution not also already handled by other approaches, and requires unnecessary changes to SCTP. Can you point out a likely scenario that the association-changeover draft can handle that CORID cannot? If not, why would you believe that fundamental changes to the requirements of SCTP are necessary? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Xiangsong.Cui@huawei.com Mon Mar 8 04:52:04 2010 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 33E9C3A684E for ; Mon, 8 Mar 2010 04:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, STOX_REPLY_TYPE=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 gVuAF4df0RFU for ; Mon, 8 Mar 2010 04:52:02 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 04BA43A68FF for ; Mon, 8 Mar 2010 04:52:02 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYY001SDRQNEE@szxga02-in.huawei.com> for sigtran@ietf.org; Mon, 08 Mar 2010 20:52:00 +0800 (CST) Received: from c00111037 ([10.111.16.59]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYY002LKRQNQ2@szxga02-in.huawei.com> for sigtran@ietf.org; Mon, 08 Mar 2010 20:51:59 +0800 (CST) Date: Mon, 08 Mar 2010 20:51:59 +0800 From: Xiangsong Cui To: bidulock@openss7.org Message-id: <035001cabebe$24712920$3b106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20100304080858.GA23705@openss7.org> <008801cabc0d$d4282d40$3b106f0a@china.huawei.com> <20100305055354.GA31145@openss7.org> <017101cabc31$2f2f7860$3b106f0a@china.huawei.com> <20100305085446.GA5507@openss7.org> <02bb01cabc48$0335b8c0$3b106f0a@china.huawei.com> <20100305132543.GB4024@openss7.org> <20100306121101.GA18634@openss7.org> <20100308111321.GA605@openss7.org> Cc: sigtran@ietf.org Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. 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, 08 Mar 2010 12:52:04 -0000 Dear Brian, Thanks a lot for the detailed discussion, please see my comments inline. Regards Xiangsong ----- Original Message ----- From: "Brian F. G. Bidulock" To: "Xiangsong Cui" Cc: Sent: Monday, March 08, 2010 7:13 PM Subject: Re: [Sigtran] Sigtran extension for network management and association changeover. > Xiangsong, > > Please see comments below: > > Xiangsong Cui wrote: (Sun, 07 Mar 2010 19:16:32) >> Dear Brian, >> >> > Suppose that SGP1 in SG2 fails causing associations >> > ASP1-SG2/SGP1 and ASP2-SG2/SGP1 to be lost. SG2 must >> >> I'm not very sure about your case. >> >> If the broken-down SGP in your assumption means the SGP hardware, >> including SCTP and M3UA protocol stack, sequenced changeover can not >> be achieved anyway. > > Yes it can, see below. > >> If the broken-down SGP means the SGP process of M3UA protocol, SCTP >> process should be still active, and, association should still be in >> established state, and association changeover is unnecessary. This is >> very like the Processor Outage of MTP. SCTP buffers the messages and >> maybe some messages would be lost (queue overflow, etc.), this depends >> on the error in M3UA SGP. maybe corid approach would not be available >> either, because there is error in the SPP process. >> >> If the SGP failure means SCTP process crashes down fully while SGP >> process of M3UA protocol is active, this is infrequent and I cann't >> see the exact scenario. On the other hand, it is similiar to MTP2 >> terminal error, MTP3 cann't get sequence information of MSU, sequenced >> changeover is impossible. Notice this is seldom case, and MTP3 will >> not append message buffer in MTP3 layer for the extreme changeover. >> So association changeover approach loses nothing than MTP changeover. > > We are talking about SIGTRAN here; nevertheless, these assertions about > SS7 are untrue. There is no requirement in SS7 to implement the > retransmission buffer in the signaling terminal. Also the sequence > number transmitted in a COO or COA is the sequence of the last MSU > accepted by MTP-3. This information also is not required to be > maintained in the signaling terminal, but may be maintained in MTP-3. > Therefore, a signaling terminal can fail and MTP-3 may still be able to > both update the retranmission buffer as well as provide the last BSNT in > the COO or COA. So, an SS7 implementation may capable of performing a > sequenced changeover even under a signaling terminal failure. I am wondering whether we are reading the same SS7 specifications. In ITU-T Q.704 (section 5.1) it says: "For this purpose, in the normal case the changeover procedure includes buffer updating and retrieval, which are performed before reopening the alternative signalling link(s) to the diverted traffic. Buffer updating consists of identifying all those messages in the retransmission buffer of the unavailable signalling link which have not been received by the far end." And, section 5.4.3 of Q.704 says: "Upon reception of a changeover order or changeover acknowledgement, the retransmission buffer of the unavailable signalling link is updated (except as noted in 5.6), according to the information contained in the message." And more, section 5.5 of Q.704 says: "the signal traffic already stored in the transmission buffers and retransmission buffer of the unavailable signalling link is sent directly towards the new signalling link(s), according to the modified routing." Do those mean message retrieval is between MTP3 and MTP2 signalling link? If the MTP2 terminal is down, how can message retrieval happen? > > Now back to SIGTRAN. The case I was presenting was where the SGP fails. > This includes SCTP, M3UA and everything else at the SGP. However, the > NIF has not failed (because it does not reside in the SGP). CORID > permits the NIF to maintain both the "retransmission buffer" and the > "sequence number" for the failed SGP. Because the messages sent via the > alternate SGP contain tags identifying the "sequence numbering", CORID > is capable of lossless changover in this case. Let me repeat, this is seldom case, and MTP3 will not append message buffer in MTP3 layer for the extreme changeover. Association changeover approach loses nothing than MTP changeover. > > So, it appears that association-changover is the only approach that is > incapable of lossless changeover in this circumstance. > >> OK, we come to the last case, some protocol error happen. >> The association is terminated and it is also a failure >> in the SGP. At this time the SCTP process and M3UA >> process are both active, and the SCTP process (in the SGP) >> can also cache the final status and buffered messages >> of the broken-down association when it detects the >> failure. > > No. It is not the case that the association has broken down. The > association is fully functional and is processing traffic for other AS. > An isolation has occurred causing one AS via the one SGP to be > deactivated only. The remainder of the description of this case (below) > is invalid because the association is still active and messages cannot > be retrieved from SCTP for an active association. > >> The SCTP process in SGP can select the alternative association (i.e., >> the association between ASP1 and SGP2 of SG2, the two associations are >> both between the same node pair and both provide service to M3UA). The >> ASP1 would also detecet the assciation failure, cache the status and >> the buffered messages of the broken-down association and select the >> alternative association (in this case ASP1 and SG2 would select the >> same alternative association, in the draft different alternative >> associations are allowed in different direction). By now, both >> endpoint cache the enough infoamtion and they can exchange the >> acknowledged sequence number in the alternative association. So the >> SCTP process of the both endpoint can know well which messages are >> received by the peer and which messages are sent but not received by >> the peer, and they locally know clearly which messages are not sent to >> the peer. In addition, they both know well which messages are received >> by local SCTP process but not moved to the ULP. The M3UA process can >> utilize the retrieve primitive defined in RFC4960 to retrieve the >> messages and resend them to SCTP layer. At this time, M3UA has knowen >> the association failure and would update the load sharing set. And the >> M3UA process resend the retrieved messages as it send normal message >> to SCTP layer. Of course, the later messages that containing same CIC >> with the retrieved messages should also be use the same association >> (i.e., the alternative association). So lossing, duplication and >> mis-sequence would never happen in the sender. In the receiver side, >> the cumulative acknowledged message in the receive queue (if there is, >> the ULP has not accepted them) would be moved to the receive queue of >> the alternative association (still for the same ULP, this point need >> clarification in the draft), selected acknowledged messages are >> reneged and would be resent by the peer, unacknowledged would also be >> resent by the peer. So lossing, duplication and mis-sequenc would not >> happen in the receiver either. >> >> Well, changeover is finished and later is changeback. Changeback is >> not in the scope of the draft because the operations has been >> implemented in current protocol implementations. For example, in the >> load sharing mode, e.g. n+k, if the number of active ASP changes from >> m (m> ASP/association. and the signalling transport has already been >> lossless, non-dplication and sequenced. > > M3UA provides no mechanism to avoid missequencing. Messages transmitted > on the new association can arrive in advance of messages still > outstanding on the old association. CORID provides explicit procedures > (even interworking procedures) to avoid missequencing, as does SS7. I didn't say M3UA protocol provide this function, I said current implementations have already considered this case. when the device changes from 1 active ASPs to 2 active ASPs, some traffic would be re-balanced in dynamic manner. Even there is no changeover, it also works well. > >> As a conclusion, assocaiton changeover approach is designed to provide >> changeover functionality like MTP (eliminating the gap between sigtran >> and MTP) and improve the performance of sigtran network. > > And yet, association-changover does not handle these scenarios. The > only situation that it might handle is association failure where the > SCTP remains available at both ends, which field experience in SIGTRAN > has shown to be the least likely case of failure. Even in that case, > CORID approaches are better suited to deal with association failures and > do not require any changes whatsoever to SCTP. > > I am sorry, but I, for one, am unable to support the > association-changeover draft. It fails to address scenarios already > handled by other approaches, provides no solution not also already > handled by other approaches, and requires unnecessary changes to SCTP. > > Can you point out a likely scenario that the association-changeover > draft can handle that CORID cannot? I agree corid can deal with these cases, the problem is not that corid is not powerful, but is that it too complex and expensive, and maybe guyes don't want such a PA level solution? > > If not, why would you believe that fundamental changes to the > requirements of SCTP are necessary? The reason is we can get MTP-similar changeover mechanism, with a much easy extension in SCTP level, without any modification in adaptation layer. Xiangsong > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ From bina.contact@gmail.com Wed Mar 10 01:04:32 2010 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 03D5F3A6405 for ; Wed, 10 Mar 2010 01:04:32 -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 9RsXOqDj6j+v for ; Wed, 10 Mar 2010 01:04:31 -0800 (PST) Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by core3.amsl.com (Postfix) with ESMTP id 340A43A6765 for ; Wed, 10 Mar 2010 01:04:31 -0800 (PST) Received: by pxi30 with SMTP id 30so80763pxi.5 for ; Wed, 10 Mar 2010 01:04:32 -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=SwCBiQ1pY8aVTlLYDYId5aq4Yl3FSFZzJMhGrROi/ps=; b=bVTX5jlQwKnnKA9f3k+ZGYO5SziVnQnPAgkTXciFlSn5KVcBeqP1GIKiftWfefunEE kXPioqaGcVawsHcWeuquskytSy1HXd7PrXOmkgWcsj2wDu31hMpHdxaFspZ01cnI0F2G PvFjz28N4qKDCRekFycFnlKqrgtte5AYDLBgk= 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=K9Lx0lIJyzphFMZYJEkescfEfJCHAQJLDQlQVgLdF0v2Y31QdqHDIIC7EpHUcuY+U/ GHtKdCliG8DTxv5Fy6EM9sx5e7Aodr0Vttw2AbVQJs7lIckqwzuFoBtwfRvHP66/T22w Y1gYiQiXfTr5Q37KrN3mFnngc2PcyruN+w6E4= MIME-Version: 1.0 Received: by 10.114.20.7 with SMTP id 7mr717551wat.49.1268211872698; Wed, 10 Mar 2010 01:04:32 -0800 (PST) In-Reply-To: References: Date: Wed, 10 Mar 2010 14:34:32 +0530 Message-ID: From: ACHARYA B To: sigtran@ietf.org Content-Type: multipart/alternative; boundary=00504502eaf12c134504816e9601 X-Mailman-Approved-At: Mon, 15 Mar 2010 09:00:47 -0700 Subject: [Sigtran] Fwd: difference between Sinalling types 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, 10 Mar 2010 09:06:41 -0000 --00504502eaf12c134504816e9601 Content-Type: text/plain; charset=ISO-8859-1 Kindly clear my doubts on signalling types as mentioned below. ---------- Forwarded message ---------- From: ACHARYA B Date: Wed, Mar 10, 2010 at 2:29 PM Subject: difference between Sinalling types To: hannsjuergen.schwarzbauer@domain.hidden Hi, This is Bina an IN Engg working in SS7 but need some info from u regarding M2UA,M3UA, and E1s signalling working concept and why they are came into picture i.e. their relevance and significance. If u have any documents pls send also. Thanks. Bina -- Best Wishes, Brundaban -- Best Wishes, Brundaban --00504502eaf12c134504816e9601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kindly clear my doubts on signalling types as mentioned below.

---------- Forwarded message ----------
From:= ACHARYA B <bina.contact@gmail.com>Date: Wed, Mar 10, 2010 at 2:29 PM
Subject: difference between Sinalling types
To: hannsjuergen.schwarzbaue= r@domain.hidden


Hi,
=A0=A0=A0=A0=A0 This is Bina an IN Engg working in SS7 but need some i= nfo from u regarding M2UA,M3UA, and E1s signalling working concept and why = they are came into picture i.e. their relevance and significance.
=A0
If u have any documents pls send also.
=A0
Thanks.
Bina

--
Best Wishes,
Brundaban



--
Best Wishes,
Brundaban
--00504502eaf12c134504816e9601-- From bidulock@openss7.org Tue Mar 16 00:21:20 2010 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 B53483A6805 for ; Tue, 16 Mar 2010 00:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, 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 05BE4Paj3Sma for ; Tue, 16 Mar 2010 00:21:19 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 41DD73A6774 for ; Tue, 16 Mar 2010 00:21:19 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:k/JlkEQwGRFwaiUUYo3XZAsV0hPrt0Lv@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2G7LNfX023757; Tue, 16 Mar 2010 01:21:23 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:GO1jNZt4+kd2zOLa2riu2XwvJS3zEdm0@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2G7LNkJ023870; Tue, 16 Mar 2010 01:21:23 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2G7LNJj023869; Tue, 16 Mar 2010 01:21:23 -0600 Date: Tue, 16 Mar 2010 01:21:23 -0600 From: "Brian F. G. Bidulock" To: ACHARYA B Message-ID: <20100316072123.GA23587@openss7.org> Mail-Followup-To: ACHARYA B , 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] Fwd: difference between Sinalling types 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: Tue, 16 Mar 2010 07:21:20 -0000 ACHARYA, Rest assured, your doubts are cleared: these signalling types are concepts that are working everywhere! --brian ACHARYA B wrote: (Wed, 10 Mar 2010 14:34:32) > > Kindly clear my doubts on signalling types as mentioned below. > > ---------- Forwarded message ---------- > From: ACHARYA B <[1]bina.contact@gmail.com> > Date: Wed, Mar 10, 2010 at 2:29 PM > Subject: difference between Sinalling types > To: hannsjuergen.schwarzbauer@domain.hidden > Hi, > This is Bina an IN Engg working in SS7 but need some info from u > regarding M2UA,M3UA, and E1s signalling working concept and why they > are came into picture i.e. their relevance and significance. > > If u have any documents pls send also. > > Thanks. > Bina > -- > Best Wishes, > Brundaban > > -- > Best Wishes, > Brundaban > > References > > 1. mailto:bina.contact@gmail.com > _______________________________________________ > 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 Srinivas.Murthy@ccpu.com Thu Mar 18 23:44:44 2010 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 D47353A680D for ; Thu, 18 Mar 2010 23:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 DvIkptkqr7Nw for ; Thu, 18 Mar 2010 23:44:42 -0700 (PDT) Received: from sd-smtp.ccpu.com (sd-smtp.ccpu.com [65.44.201.8]) by core3.amsl.com (Postfix) with ESMTP id E8AD83A67AB for ; Thu, 18 Mar 2010 23:44:41 -0700 (PDT) Received: from sd-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id DD37724C00D for ; Thu, 18 Mar 2010 23:44:52 -0700 (PDT) Received: from alladin.ccpu.com (alladin.ccpu.com [172.16.0.216]) by sd-smtp.ccpu.com (Postfix) with ESMTP id C68C524C001 for ; Thu, 18 Mar 2010 23:44:52 -0700 (PDT) Received: from IN-EXCHANGE.ccpu.com ([172.25.0.16]) by alladin.ccpu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 23:44:52 -0700 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_01CAC72F.ACD3B58C" Date: Fri, 19 Mar 2010 12:14:49 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F004055DFD@in-exchange.ccpu.com> In-Reply-To: <0901D1988E815341A0103206A834DA07BC8C67@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP Heartbeat Thread-Index: AcZHEUmePfIgYdAFTbadKbGE9CRv2IkAOlZA References: <0901D1988E815341A0103206A834DA07BC8C67@mdmxm02.ciena.com> From: "Srinivas Murthy" To: X-OriginalArrivalTime: 19 Mar 2010 06:44:52.0250 (UTC) FILETIME=[AD8BEFA0:01CAC72F] X-TM-AS-Product-Ver: IMSS-7.0.0.3216-6.0.0.1038-17260.003 X-TM-AS-Result: No--11.034-5.0-31-1 X-imss-scan-details: No--11.034-5.0-31-1 Subject: [Sigtran] SCTP Heartbeat 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, 19 Mar 2010 06:44:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC72F.ACD3B58C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a confusion in Section 8.3 of RFC 4960. As per the RFC it says, "Only one heartbeat should be sent each time the heartbeat timer=20 expires (if multiple destinations are idle). It is an implementation decision on how to choose which of the candidate idle destinations=20 to heartbeat to (if more than one destination is idle)." =20 Does that mean if we have an association with say 2 destination addresses and both are idle, we have to send heartbeat to only one of them per heartbeat interval? and as the selection is implementation decision we can choose any one of them to send heartbeat to. In this case if my implementation always chooses the same destination address then how will we know about the health of the other destination address? =20 Regards, Srinivas Murthy =20 ------_=_NextPart_001_01CAC72F.ACD3B58C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a confusion in Section 8.3 of RFC = 4960.

As per the RFC it says,

   “Only one heartbeat should be sent = each time the heartbeat timer

   expires (if multiple destinations are = idle).  It is an implementation

   decision on how to choose which of the = candidate idle destinations

   to heartbeat to (if more than one = destination is idle).”

 

Does that mean if we have an association with say 2 = destination addresses and both are idle, we have to send heartbeat to only one of = them per heartbeat interval? and as the selection is implementation decision we = can choose any one of them to send heartbeat to.

In this case if my implementation always chooses the same = destination address then how will we know about the health of the other destination address?

 

Regards,

Srinivas Murthy

 

------_=_NextPart_001_01CAC72F.ACD3B58C-- From Michael.Tuexen@lurchi.franken.de Fri Mar 19 00:05:29 2010 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 C01533A685E for ; Fri, 19 Mar 2010 00:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.678 X-Spam-Level: ** X-Spam-Status: No, score=2.678 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 cbM3ux7H9gIU for ; Fri, 19 Mar 2010 00:05:28 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 5728D3A6851 for ; Fri, 19 Mar 2010 00:05:27 -0700 (PDT) Received: from [192.168.1.190] (p508FEFD7.dip.t-dialin.net [80.143.239.215]) by mail-n.franken.de (Postfix) with ESMTP id 558021C0C0BD8; Fri, 19 Mar 2010 08:05:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F004055DFD@in-exchange.ccpu.com> Date: Fri, 19 Mar 2010 08:05:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1411F8AF-8E10-4FB8-AF9A-2CFE95B0C0E8@lurchi.franken.de> References: <0901D1988E815341A0103206A834DA07BC8C67@mdmxm02.ciena.com> <22F058C3ED9D784E90CE473F2A9847F004055DFD@in-exchange.ccpu.com> To: Srinivas Murthy X-Mailer: Apple Mail (2.1077) Cc: sigtran@ietf.org Subject: Re: [Sigtran] SCTP Heartbeat 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, 19 Mar 2010 07:05:29 -0000 On Mar 19, 2010, at 7:44 AM, Srinivas Murthy wrote: > Hi, > =20 > I have a confusion in Section 8.3 of RFC 4960. > As per the RFC it says, > =93Only one heartbeat should be sent each time the heartbeat timer > expires (if multiple destinations are idle). It is an = implementation > decision on how to choose which of the candidate idle destinations > to heartbeat to (if more than one destination is idle).=94 > =20 > Does that mean if we have an association with say 2 destination = addresses and both are idle, we have to send heartbeat to only one of = them per heartbeat interval? and as the selection is implementation = decision we can choose any one of them to send heartbeat to. > In this case if my implementation always chooses the same destination = address then how will we know about the health of the other destination = address? Hi Srinivas, first of all: SCTP issues should be discussed on tsvwg@ietf.org. The intention of RFC 4960 is that all idle paths are checked. So always choosing the same idle path is a bad implementation decision. I'm also wondering if it really is a good choice to send a HB every HB.timeout+RTO+jitter. It make much more sense to do this for every idle path every HB.timeout+RTO+jitter. Best regards Michael > =20 > Regards, > Srinivas Murthy > =20 > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran From shivi.verma@aricent.com Fri Mar 19 00:07:39 2010 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 2D1F53A6834 for ; Fri, 19 Mar 2010 00:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.442 X-Spam-Level: X-Spam-Status: No, score=0.442 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 ZV1TRI4memA4 for ; Fri, 19 Mar 2010 00:07:38 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id D389A3A67FC for ; Fri, 19 Mar 2010 00:07:37 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id B6D1936B9E for ; Fri, 19 Mar 2010 12:34:10 +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 A13FE36B9D for ; Fri, 19 Mar 2010 12:34:10 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Fri, 19 Mar 2010 12:37:48 +0530 From: Shivi Singh Verma To: "sigtran@ietf.org" Date: Fri, 19 Mar 2010 12:37:46 +0530 Thread-Topic: [Sigtran]Rc utilization while processing SSSNM messages Thread-Index: AcrHMT87wYHdQsXuQMOZ44B9UhH+DwAAXISwAAAJAkA= Message-ID: <40102CD77F8ADA41B01CB6B9446DCC46044EC3F9@GUREXMB01.ASIAN.AD.ARICENT.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_40102CD77F8ADA41B01CB6B9446DCC46044EC3F9GUREXMB01ASIANA_" MIME-Version: 1.0 Subject: [Sigtran] Rc utilization while processing SSSNM 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: Fri, 19 Mar 2010 07:07:39 -0000 --_000_40102CD77F8ADA41B01CB6B9446DCC46044EC3F9GUREXMB01ASIANA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What the role of RC while receiving SSNM message Thanks & Regards Shivi Singh Verma ________________________________ "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_40102CD77F8ADA41B01CB6B9446DCC46044EC3F9GUREXMB01ASIANA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

 

 

What the role of RC while receiving SSNM message

 

Thanks & Regards

Shivi Singh Verma

 



"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_40102CD77F8ADA41B01CB6B9446DCC46044EC3F9GUREXMB01ASIANA_-- From bidulock@openss7.org Fri Mar 19 00:30:46 2010 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 3E5EA3A6892 for ; Fri, 19 Mar 2010 00:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 RoQJqWo0r0Ej for ; Fri, 19 Mar 2010 00:30:44 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 23F663A6778 for ; Fri, 19 Mar 2010 00:30:43 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:ucLvO2YoDINzKWH/dMueqBfLmRps4oGx@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2J7Ui5D031727; Fri, 19 Mar 2010 01:30:44 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:WBZ1bzRzJD8Dkut3nnXPSKTq6acvIaGm@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2J7UiKi021193; Fri, 19 Mar 2010 01:30:44 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2J7UhMo021192; Fri, 19 Mar 2010 01:30:43 -0600 Date: Fri, 19 Mar 2010 01:30:43 -0600 From: "Brian F. G. Bidulock" To: Shivi Singh Verma Message-ID: <20100319073043.GA20985@openss7.org> Mail-Followup-To: Shivi Singh Verma , "sigtran@ietf.org" References: <40102CD77F8ADA41B01CB6B9446DCC46044EC3F9@GUREXMB01.ASIAN.AD.ARICENT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40102CD77F8ADA41B01CB6B9446DCC46044EC3F9@GUREXMB01.ASIAN.AD.ARICENT.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] Rc utilization while processing SSSNM messages 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: Fri, 19 Mar 2010 07:30:46 -0000 Shivi, Shivi Singh Verma wrote: (Fri, 19 Mar 2010 12:37:46) > > What the role of RC while receiving SSNM message To identify the AS to which the message applies. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From shivi.verma@aricent.com Fri Mar 19 01:05:08 2010 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 3C6C83A685D for ; Fri, 19 Mar 2010 01:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 lw2PNTt8yvSO for ; Fri, 19 Mar 2010 01:05:03 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 092143A6778 for ; Fri, 19 Mar 2010 01:05:03 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id C773A36B8D; Fri, 19 Mar 2010 13:31:33 +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 B1DF136B8A; Fri, 19 Mar 2010 13:31:33 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Fri, 19 Mar 2010 13:35:11 +0530 From: Shivi Singh Verma To: "bidulock@openss7.org" Date: Fri, 19 Mar 2010 13:35:10 +0530 Thread-Topic: [Sigtran] Rc utilization while processing SSNM messages Thread-Index: AcrHNhydUIuC1XqkSM6EaOl6/Xsn5AABAhkQ Message-ID: <40102CD77F8ADA41B01CB6B9446DCC46044EC476@GUREXMB01.ASIAN.AD.ARICENT.COM> References: <40102CD77F8ADA41B01CB6B9446DCC46044EC3F9@GUREXMB01.ASIAN.AD.ARICENT.COM> <20100319073043.GA20985@openss7.org> In-Reply-To: <20100319073043.GA20985@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] Rc utilization while processing SSNM 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: Fri, 19 Mar 2010 08:05:08 -0000 Then in that case, we have to maintain SSNM Point Code status per AS per SG= .That is, a point code reachable through SG can have different status thro= ugh different ASs. In M3UA stack, RC value is also utilized while processing incoming DAVA. Ba= sed on RC value, AS will be identified and update the status of point code = reachable through SG for that AS. Can you clarify whether my understanding is correct? Thanks & Regards Shivi Singh Verma -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Friday, March 19, 2010 1:01 PM To: Shivi Singh Verma Cc: sigtran@ietf.org Subject: Re: [Sigtran] Rc utilization while processing SSSNM messages Shivi, Shivi Singh Verma wrote: (Fri, 19 Mar 2010 12:37:46) > > What the role of RC while receiving SSNM message To identify the AS to which the message applies. --brian -- 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 rajesh.makhija@aricent.com Fri Mar 19 03:59:00 2010 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 677F83A69B5 for ; Fri, 19 Mar 2010 03:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.732 X-Spam-Level: * X-Spam-Status: No, score=1.732 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 b4OJnsss1nF8 for ; Fri, 19 Mar 2010 03:58:59 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by core3.amsl.com (Postfix) with ESMTP id 4B74C3A67FA for ; Fri, 19 Mar 2010 03:58:58 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 16A6B36B81 for ; Fri, 19 Mar 2010 16:25: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 0170836B69 for ; Fri, 19 Mar 2010 16:25:30 +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; Fri, 19 Mar 2010 16:29:07 +0530 From: Rajesh Makhija To: "sigtran@ietf.org" Date: Fri, 19 Mar 2010 16:29:08 +0530 Thread-Topic: Query regarding reachability STATUS of Signaling Point Code Thread-Index: AcrHUzLTuQh+47FpTcGL2HJ/jAn9uA== 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_ED87E3B738CE6240A27EC10A62BE60AE1263C751GUREXMB01ASIANA_" MIME-Version: 1.0 Cc: Rajat2 Gupta , Amit Jain Subject: [Sigtran] Query regarding reachability STATUS of Signaling Point Code 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, 19 Mar 2010 10:59:00 -0000 --_000_ED87E3B738CE6240A27EC10A62BE60AE1263C751GUREXMB01ASIANA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, We would like to understand how the STATUS of Signaling Point Code (that un= iquely identifies an SS7 node) shall be interpreted by M3UA at ASP/AS side. Entities Configured: Let us consider an ASP is serving two Application servers, say AS-1 and AS-= 2. This ASP is connected (through SCTP association) to an SGP. This SGP is= serving an SG. The routing context of AS1 is X and routing context of AS2 is Y. A route is configured for an SS7 destination (say with point code 101) thro= ugh this SG. This SS7 node with point code 101 is initially unavailable. Now, a DAVA message (for SS7 point code 101) is sent by SGP to ASP with rou= ting context X (which is the routing context corresponding to AS1) There seem to be two possible interpretations: 1. SS7 node with point code (101) is marked as reachable for both the= Application servers, AS1 and AS2. 2. SS7 point code (101) is marked as reachable for AS-1 only (as dete= rmined by the RC in the DUNA message) and remains unreachable for AS-2. Which one of the above-mentioned interpretations is correct? Regards Rajesh ________________________________ "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_ED87E3B738CE6240A27EC10A62BE60AE1263C751GUREXMB01ASIANA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
We would like to understand how the =
STATUS of Signaling Point Code (that uniquely identifies an SS7 node) shall=
 be interpreted by M3UA at ASP/AS side.

 

Entities Config= ured:

 

Let us consider an ASP is serving two = Application servers, say AS-1 and AS-2.  This ASP is connected (throug= h SCTP association) to an SGP. This SGP is serving an SG.

 

The routing context of AS1 is X and ro= uting context of AS2 is Y.

 
A route is configured for an SS7 destination (say with point co=
de 101) through this SG.

 

This SS7 node with point code 101 is i= nitially unavailable.

 

Now, a DAVA mes= sage (for SS7 point code 101) is sent by SGP to ASP with routing context X (which is the rout= ing context corresponding to AS1)

 

There seem to be two possible interpre= tations:

 

1. &= nbsp;     SS7 node with point code (101) is marked as reachable for both the Application servers, AS1 and AS2.

2. &= nbsp;     SS7 point code (101) is marked as reachable for AS-1 only (as determined by the RC in the DUNA message= ) and remains unreachable for AS-2.

 

Which one of the above-mentioned inter= pretations is correct?

 

Regards

 

Rajesh

 

 

 



"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_ED87E3B738CE6240A27EC10A62BE60AE1263C751GUREXMB01ASIANA_-- From bidulock@openss7.org Fri Mar 19 06:55:15 2010 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 14FAC3A6A27 for ; Fri, 19 Mar 2010 06:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 VIz4mJUFo3tm for ; Fri, 19 Mar 2010 06:55:14 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id CCD203A6A1E for ; Fri, 19 Mar 2010 06:55:13 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:iO++OOvpEHWw6CXmMblKwC8Cr59M8If2@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2JDtHlG006066; Fri, 19 Mar 2010 07:55:17 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:kxpZ7P7Riiq2pvZcwE5Zsm9aRl8/O+3f@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2JDtHDi028604; Fri, 19 Mar 2010 07:55:17 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2JDtHdU028603; Fri, 19 Mar 2010 07:55:17 -0600 Date: Fri, 19 Mar 2010 07:55:17 -0600 From: "Brian F. G. Bidulock" To: Shivi Singh Verma Message-ID: <20100319135516.GB20985@openss7.org> Mail-Followup-To: Shivi Singh Verma , "sigtran@ietf.org" References: <40102CD77F8ADA41B01CB6B9446DCC46044EC3F9@GUREXMB01.ASIAN.AD.ARICENT.COM> <20100319073043.GA20985@openss7.org> <40102CD77F8ADA41B01CB6B9446DCC46044EC476@GUREXMB01.ASIAN.AD.ARICENT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40102CD77F8ADA41B01CB6B9446DCC46044EC476@GUREXMB01.ASIAN.AD.ARICENT.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] Rc utilization while processing SSNM messages 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: Fri, 19 Mar 2010 13:55:15 -0000 Shivi, No, that is not correct: except at an ASP in the multiple-SG-as-STP case, M3UA does not have to keep track of point code status at all. --brian Shivi Singh Verma wrote: (Fri, 19 Mar 2010 13:35:10) > > Then in that case, we have to maintain SSNM Point Code status > per AS per SG .That is, a point code reachable through SG can > have different status through different ASs. > > In M3UA stack, RC value is also utilized while processing > incoming DAVA. Based on RC value, AS will be identified and > update the status of point code reachable through SG for that > AS. > > Can you clarify whether my understanding is correct? > > Thanks & Regards > > Shivi Singh Verma > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Friday, March 19, 2010 1:01 PM > To: Shivi Singh Verma > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Rc utilization while processing SSSNM messages > > Shivi, > > Shivi Singh Verma wrote: (Fri, 19 Mar 2010 12:37:46) > > > > What the role of RC while receiving SSNM message > > > To identify the AS to which the message applies. > > --brian > > -- > 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." -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Xiangsong.Cui@huawei.com Fri Mar 19 07:02:19 2010 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 5AFB53A6A1E for ; Fri, 19 Mar 2010 07:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.877 X-Spam-Level: *** X-Spam-Status: No, score=3.877 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_50=0.001, CN_BODY_35=0.339, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45] 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 k-oD7WA71TSd for ; Fri, 19 Mar 2010 07:02:18 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7F0AB3A682F for ; Fri, 19 Mar 2010 07:02:14 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZJ00D1T8C12H@szxga03-in.huawei.com> for sigtran@ietf.org; Fri, 19 Mar 2010 22:02:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZJ005FK8C1JQ@szxga03-in.huawei.com> for sigtran@ietf.org; Fri, 19 Mar 2010 22:02:25 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [221.223.248.106]) by szxmc03-in.huawei.com (mshttpd); Fri, 19 Mar 2010 22:02:25 +0800 Date: Fri, 19 Mar 2010 22:02:25 +0800 From: Xiangsong Cui In-reply-to: To: Rajesh Makhija Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_S4N7l7CNYQrcg8m2yQ6Ztg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: Cc: Rajat2 Gupta , "sigtran@ietf.org" , Amit Jain Subject: [Sigtran] Re : Query regarding reachability STATUS of Signaling Point Code 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, 19 Mar 2010 14:02:19 -0000 This is a multi-part message in MIME format. --Boundary_(ID_S4N7l7CNYQrcg8m2yQ6Ztg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline =3E Now=2C a DAVA message (for SS7 point code 101) is sent by SGP to ASP = =3E with routing context X (which is the routing context corresponding = =3E to AS1) But why does the SGW send NAVA only for routing context X=3F Xiangsong ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Rajesh Makhija =3Crajesh=2Emakhija=40aricent=2Ecom=3E= =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =C8=FD=D4=C2 19=C8=D5=2C 2010 =CF=C2= =CE=E76=3A59 =D6=F7=CC=E2=3A =5BSigtran=5D Query regarding reachability STATUS of Sign= aling Point Code =CA=D5=BC=FE=C8=CB=3A =22sigtran=40ietf=2Eorg=22 =3Csigtran=40ietf=2Eorg=3E= =B3=AD=CB=CD=3A Rajat2 Gupta =3Crajat2=2Egupta=40aricent=2Ecom=3E=2C Amit= Jain =3Camit=2Ejain=40aricent=2Ecom=3E =3E Hello=2C =3E = =3E = =3E = =3E We would like to understand how the STATUS of Signaling Point Code = =3E (that uniquely identifies an SS7 node) shall be interpreted by = =3E M3UA at ASP/AS side=2E =3E = =3E Entities Configured=3A =3E = =3E Let us consider an ASP is serving two Application servers=2C say AS- =3E 1 and AS-2=2E This ASP is connected (through SCTP association) to = =3E an SGP=2E This SGP is serving an SG=2E =3E = =3E The routing context of AS1 is X and routing context of AS2 is Y=2E =3E = =3E = =3E = =3E A route is configured for an SS7 destination (say with point code = =3E 101) through this SG=2E =3E = =3E This SS7 node with point code 101 is initially unavailable=2E =3E = =3E Now=2C a DAVA message (for SS7 point code 101) is sent by SGP to ASP = =3E with routing context X (which is the routing context corresponding = =3E to AS1) =3E = =3E There seem to be two possible interpretations=3A =3E = =3E 1=2E SS7 node with point code (101) is marked as reachable for = =3E both the Application servers=2C AS1 and AS2=2E =3E 2=2E SS7 point code (101) is marked as reachable for AS-1 only = =3E (as determined by the RC in the DUNA message) and remains = =3E unreachable for AS-2=2E =3E = =3E Which one of the above-mentioned interpretations is correct=3F =3E = =3E Regards =3E = =3E Rajesh =3E = =3E = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =22DISCLAIMER=3A This message is proprietary to Aricent and is = =3E intended solely for the use of the individual to whom it is = =3E addressed=2E It may contain privileged or confidential information = =3E and should not be circulated or used for any purpose other than = =3E for what it is intended=2E If you have received this message in = =3E error=2C please notify the originator immediately=2E If you are not = =3E the intended recipient=2C you are notified that you are strictly = =3E prohibited from using=2C copying=2C altering=2C or disclosing the = =3E contents of this message=2E Aricent accepts no responsibility for = =3E loss or damage arising from the use of the information transmitted = =3E by this email including damage from virus=2E=22 =3E --Boundary_(ID_S4N7l7CNYQrcg8m2yQ6Ztg) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for Xiangsong Cui begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_S4N7l7CNYQrcg8m2yQ6Ztg)-- From bidulock@openss7.org Fri Mar 19 07:15:29 2010 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 B5F2A3A6A17 for ; Fri, 19 Mar 2010 07:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 su+KpvIq+FgY for ; Fri, 19 Mar 2010 07:15:28 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 8A6803A682F for ; Fri, 19 Mar 2010 07:15:28 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:2GEuxQZJZakedE0fRWVe/NnZESrDNErk@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2JEFXT6006400; Fri, 19 Mar 2010 08:15:33 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:GLTA5nD31fP1R/wGJnHlpKut7WL3qSAG@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2JEFXCN028990; Fri, 19 Mar 2010 08:15:33 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2JEFXc2028989; Fri, 19 Mar 2010 08:15:33 -0600 Date: Fri, 19 Mar 2010 08:15:33 -0600 From: "Brian F. G. Bidulock" To: Rajesh Makhija Message-ID: <20100319141533.GC20985@openss7.org> Mail-Followup-To: Rajesh Makhija , "sigtran@ietf.org" , Rajat2 Gupta , Amit Jain 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: Rajat2 Gupta , "sigtran@ietf.org" , Amit Jain Subject: Re: [Sigtran] Query regarding reachability STATUS of Signaling Point Code 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: Fri, 19 Mar 2010 14:15:29 -0000 Rajesh, Please see comments below: Rajesh Makhija wrote: (Fri, 19 Mar 2010 16:29:08) > > Hello, > > We would like to understand how the STATUS of Signaling Point > Code (that unique ly identifies an SS7 node) shall be > interpreted by M3UA at ASP/AS side. > > > Entities Configured: > > > Let us consider an ASP is serving two Application servers, > say AS-1 and AS-2. This ASP is connected (through SCTP > association) to an SGP. This SGP is serving an SG. > > > The routing context of AS1 is X and routing context of AS2 > is Y. > > A route is configured for an SS7 destination (say with point > code 101) through this SG. > > > This SS7 node with point code 101 is initially unavailable. > > > Now, a DAVA message (for SS7 point code 101) is sent by SGP > to ASP with routing context X (which is the routing context > corresponding to AS1) > > > There seem to be two possible interpretations: > > > 1. SS7 node with point code (101) is marked as > reachable for both the Application servers, AS1 and AS2. > > 2. SS7 point code (101) is marked as reachable for > AS-1 only (as determined by the RC in the DUNA message) and > remains unreachable for AS-2. > > > Which one of the above-mentioned interpretations is > correct? Neither. M3UA at the ASP simply identifies the MTP/MTP-User interface (AS) associated with the RC and passes an MTP-RESUME primitive to the MTP-User. It is the MTP-User's responsibility to track the state of remote signalling points. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From rajesh.makhija@aricent.com Sat Mar 20 03:05:20 2010 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 077223A681D for ; Sat, 20 Mar 2010 03:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.703 X-Spam-Level: ** X-Spam-Status: No, score=2.703 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_00=-2.599, CN_BODY_35=0.339, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_12=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 iCE15821IrFH for ; Sat, 20 Mar 2010 03:05:15 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by core3.amsl.com (Postfix) with ESMTP id 843A83A686C for ; Sat, 20 Mar 2010 03:05:14 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 6B1B936B4C; Sat, 20 Mar 2010 15:31: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 5553036B44; Sat, 20 Mar 2010 15:31:47 +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; Sat, 20 Mar 2010 15:35:25 +0530 From: Rajesh Makhija To: "sigtran@ietf.org" , Xiangsong Cui Date: Sat, 20 Mar 2010 15:35:16 +0530 Thread-Topic: Re :[Sigtran] Query regarding reachability STATUS of Signaling Point Code Thread-Index: AcrHbNdza+C0QW7JQPST1MGxUMlPlgApKn6Q 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: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Rajat2 Gupta , Amit Jain Subject: Re: [Sigtran] Re : Query regarding reachability STATUS of Signaling Point Code 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: Sat, 20 Mar 2010 10:05:20 -0000 WGlhbmdzb25nLA0KDQpUaGFuayB5b3UgZm9yIHBvaW50aW5nIHRoaXMgb3V0Lg0KDQpJIHdhcyBv cmlnaW5hbGx5IHdvbmRlcmluZyBpZiBTR1cgZG9lcyBzZW5kIERBVkEgZm9yIHJvdXRpbmcgY29u dGV4dCBYIG9ubHkgdGhlbiBob3cgc2hvdWxkIEFTL0FTUCBpbnRlcnByZXQgdGhlIHNhbWUuDQoN CkF0IHRoaXMgbW9tZW50IEkgYW0gbm90IHN1cmUgaWYgdGhpcyAoU0dXIHNlbmRpbmcgREFWQSB3 aXRoIHJvdXRpbmcgY29udGV4dCBYIG9ubHkpIGNhbiBoYXBwZW4gaW4gYSByZWFsIGxpZmUgbmV0 d29yay4NCg0KQW5kIHdoZXRoZXIgaXQgaXMgcG9zc2libGUgdGhhdCBhIHJvdXRlIGZvciBhbiBT UzcgZGVzdGluYXRpb24gaXMgYXZhaWxhYmxlIGZvciBvbmUgQVMgYW5kIG5vdCBhdmFpbGFibGUg Zm9yIHNlY29uZCBBUyB0aHJvdWdoIHRoZSBzYW1lIFNHVyAoZ2l2ZW4gdGhhdCBib3RoIEFTKHMp IGFyZSBpbiBBY3RpdmUgc3RhdGUpLg0KDQpJIHdvdWxkIHJlcXVlc3Qgb3RoZXJzIHRvIGNvbW1l bnQgb24gdGhlIGZvbGxvd2luZyB0d28gcG9pbnRzOg0KDQoxLiBXaGV0aGVyIGl0IGlzIHBvc3Np YmxlIHRoYXQgYSByb3V0ZSBmb3IgYW4gU1M3IGRlc3RpbmF0aW9uIGlzIGF2YWlsYWJsZSBmb3Ig b25lIEFTIChBUy0xKSBhbmQgbm90IGF2YWlsYWJsZSBmb3Igc2Vjb25kIEFTIChBUy0yKSB0aHJv dWdoIHRoZSBzYW1lIFNHVyAoZ2l2ZW4gdGhhdCBib3RoIEFTKHMpIGFyZSBpbiBBY3RpdmUgc3Rh dGUpLA0KV2hlbiBhICJjb21tb24gQVNQIiBpcyBzZXJ2aW5nIGJvdGggQVMtMSBhbmQgQVMtMiAo Z2l2ZW4gdGhlIGNvbW1vbiBBU1AgaXMgYWN0aXZlIGZvciBib3RoIEFTLTEgYW5kIEFTLTIpDQoN CjIuIFdoZXRoZXIgaXQgaXMgcG9zc2libGUgdGhhdCBhIHJvdXRlIGZvciBhbiBTUzcgZGVzdGlu YXRpb24gaXMgYXZhaWxhYmxlIGZvciBvbmUgQVMgKEFTLTEpIGFuZCBub3QgYXZhaWxhYmxlIGZv ciBzZWNvbmQgQVMgKEFTLTIpIHRocm91Z2ggdGhlIHNhbWUgU0dXIChnaXZlbiB0aGF0IGJvdGgg QVMocykgYXJlIGluIEFjdGl2ZSBzdGF0ZSksDQpXaGVuICJ0d28gbXV0dWFsbHkgZXhjbHVzaXZl IiBBU1AocyksIHNheSBBU1AtMSBhbmQgQVNQLTIgYXJlIHNlcnZpbmcgQVMtMSBhbmQgQVMtMiBy ZXNwZWN0aXZlbHkgKGdpdmVuIHRoZSBBU1AtMSBpcyBhY3RpdmUgZm9yIEFTLTEgYW5kIEFTUC0y IGlzIGFjdGl2ZSBmb3IgYW5kIEFTLTIpDQoNClJlZ2FyZHMNCg0KUmFqZXNoDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBYaWFuZ3NvbmcgQ3VpIFttYWlsdG86WGlhbmdzb25n LkN1aUBodWF3ZWkuY29tXQ0KU2VudDogRnJpZGF5LCBNYXJjaCAxOSwgMjAxMCA3OjMyIFBNDQpU bzogUmFqZXNoIE1ha2hpamENCkNjOiBzaWd0cmFuQGlldGYub3JnOyBSYWphdDIgR3VwdGE7IEFt aXQgSmFpbg0KU3ViamVjdDogUmUgOltTaWd0cmFuXSBRdWVyeSByZWdhcmRpbmcgcmVhY2hhYmls aXR5IFNUQVRVUyBvZiBTaWduYWxpbmcgUG9pbnQgQ29kZQ0KDQo+IE5vdywgYSBEQVZBIG1lc3Nh Z2UgKGZvciBTUzcgcG9pbnQgY29kZSAxMDEpIGlzIHNlbnQgYnkgU0dQIHRvIEFTUA0KPiB3aXRo IHJvdXRpbmcgY29udGV4dCBYICh3aGljaCBpcyB0aGUgcm91dGluZyBjb250ZXh0IGNvcnJlc3Bv bmRpbmcNCj4gdG8gQVMxKQ0KDQpCdXQgd2h5IGRvZXMgdGhlIFNHVyBzZW5kIE5BVkEgb25seSBm b3Igcm91dGluZyBjb250ZXh0IFg/DQoNClhpYW5nc29uZw0KDQotLS0tLSDUrdPKvP4gLS0tLS0N CreivP7IyzogUmFqZXNoIE1ha2hpamEgPHJhamVzaC5tYWtoaWphQGFyaWNlbnQuY29tPg0KyNXG 2jog0MfG2s7lLCDI/dTCIDE5yNUsIDIwMTAgz8LO5zY6NTkNCtb3zOI6IFtTaWd0cmFuXSBRdWVy eSByZWdhcmRpbmcgcmVhY2hhYmlsaXR5IFNUQVRVUyBvZiBTaWduYWxpbmcgUG9pbnQgICAgQ29k ZQ0KytW8/sjLOiAic2lndHJhbkBpZXRmLm9yZyIgPHNpZ3RyYW5AaWV0Zi5vcmc+DQqzrcvNOiBS YWphdDIgR3VwdGEgPHJhamF0Mi5ndXB0YUBhcmljZW50LmNvbT4sIEFtaXQgSmFpbiA8YW1pdC5q YWluQGFyaWNlbnQuY29tPg0KDQo+IEhlbGxvLA0KPg0KPg0KPg0KPiBXZSB3b3VsZCBsaWtlIHRv IHVuZGVyc3RhbmQgaG93IHRoZSBTVEFUVVMgb2YgU2lnbmFsaW5nIFBvaW50IENvZGUNCj4gKHRo YXQgdW5pcXVlbHkgaWRlbnRpZmllcyBhbiBTUzcgbm9kZSkgc2hhbGwgYmUgaW50ZXJwcmV0ZWQg YnkNCj4gTTNVQSBhdCBBU1AvQVMgc2lkZS4NCj4NCj4gRW50aXRpZXMgQ29uZmlndXJlZDoNCj4N Cj4gTGV0IHVzIGNvbnNpZGVyIGFuIEFTUCBpcyBzZXJ2aW5nIHR3byBBcHBsaWNhdGlvbiBzZXJ2 ZXJzLCBzYXkgQVMtDQo+IDEgYW5kIEFTLTIuICBUaGlzIEFTUCBpcyBjb25uZWN0ZWQgKHRocm91 Z2ggU0NUUCBhc3NvY2lhdGlvbikgdG8NCj4gYW4gU0dQLiBUaGlzIFNHUCBpcyBzZXJ2aW5nIGFu IFNHLg0KPg0KPiBUaGUgcm91dGluZyBjb250ZXh0IG9mIEFTMSBpcyBYIGFuZCByb3V0aW5nIGNv bnRleHQgb2YgQVMyIGlzIFkuDQo+DQo+DQo+DQo+IEEgcm91dGUgaXMgY29uZmlndXJlZCBmb3Ig YW4gU1M3IGRlc3RpbmF0aW9uIChzYXkgd2l0aCBwb2ludCBjb2RlDQo+IDEwMSkgdGhyb3VnaCB0 aGlzIFNHLg0KPg0KPiBUaGlzIFNTNyBub2RlIHdpdGggcG9pbnQgY29kZSAxMDEgaXMgaW5pdGlh bGx5IHVuYXZhaWxhYmxlLg0KPg0KPiBOb3csIGEgREFWQSBtZXNzYWdlIChmb3IgU1M3IHBvaW50 IGNvZGUgMTAxKSBpcyBzZW50IGJ5IFNHUCB0byBBU1ANCj4gd2l0aCByb3V0aW5nIGNvbnRleHQg WCAod2hpY2ggaXMgdGhlIHJvdXRpbmcgY29udGV4dCBjb3JyZXNwb25kaW5nDQo+IHRvIEFTMSkN Cj4NCj4gVGhlcmUgc2VlbSB0byBiZSB0d28gcG9zc2libGUgaW50ZXJwcmV0YXRpb25zOg0KPg0K PiAxLiAgICAgICBTUzcgbm9kZSB3aXRoIHBvaW50IGNvZGUgKDEwMSkgaXMgbWFya2VkIGFzIHJl YWNoYWJsZSBmb3INCj4gYm90aCB0aGUgQXBwbGljYXRpb24gc2VydmVycywgQVMxIGFuZCBBUzIu DQo+IDIuICAgICAgIFNTNyBwb2ludCBjb2RlICgxMDEpIGlzIG1hcmtlZCBhcyByZWFjaGFibGUg Zm9yIEFTLTEgb25seQ0KPiAoYXMgZGV0ZXJtaW5lZCBieSB0aGUgUkMgaW4gdGhlIERVTkEgbWVz c2FnZSkgYW5kIHJlbWFpbnMNCj4gdW5yZWFjaGFibGUgZm9yIEFTLTIuDQo+DQo+IFdoaWNoIG9u ZSBvZiB0aGUgYWJvdmUtbWVudGlvbmVkIGludGVycHJldGF0aW9ucyBpcyBjb3JyZWN0Pw0KPg0K PiBSZWdhcmRzDQo+DQo+IFJhamVzaA0KPg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiAiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5 IHRvIEFyaWNlbnQgYW5kIGlzDQo+IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzDQo+IGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJp dmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24NCj4gYW5kIHNob3VsZCBub3QgYmUg Y2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuDQo+IGZvciB3aGF0 IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4NCj4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBh cmUgbm90DQo+IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5 b3UgYXJlIHN0cmljdGx5DQo+IHByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJp bmcsIG9yIGRpc2Nsb3NpbmcgdGhlDQo+IGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2Vu dCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvcg0KPiBsb3NzIG9yIGRhbWFnZSBhcmlzaW5n IGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQNCj4gYnkgdGhpcyBl bWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIg0KPg0KDQoiRElTQ0xBSU1FUjogVGhp cyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgYW5kIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4g SXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5k IHNob3VsZCBub3QgYmUgY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0 aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHku IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQg dGhhdCB5b3UgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0 ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2Vu dCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciBsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZy b20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBp bmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIg0K From bidulock@openss7.org Sat Mar 20 13:58:11 2010 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 B061C3A6869 for ; Sat, 20 Mar 2010 13:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 1+jlSbMCBVZP for ; Sat, 20 Mar 2010 13:58:10 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 0DDCD3A677D for ; Sat, 20 Mar 2010 13:58:09 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:0sFsINeWZDBauozOHAU/TpEjqt8oiGNq@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2KKvu8I004617; Sat, 20 Mar 2010 14:57:56 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:iltAvmq8KfsynQ/LdPeW6eg0mlbi73/e@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2KKvuLu024694; Sat, 20 Mar 2010 14:57:56 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2KKvugt024693; Sat, 20 Mar 2010 14:57:56 -0600 Date: Sat, 20 Mar 2010 14:57:55 -0600 From: "Brian F. G. Bidulock" To: Rajesh Makhija Message-ID: <20100320205755.GA23083@openss7.org> Mail-Followup-To: Rajesh Makhija , "sigtran@ietf.org" , Xiangsong Cui , Rajat2 Gupta , Amit Jain 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: Rajat2 Gupta , Amit Jain , "sigtran@ietf.org" Subject: Re: [Sigtran] Re : Query regarding reachability STATUS of Signaling Point Code 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, 20 Mar 2010 20:58:11 -0000 Rajesh, Rajesh Makhija wrote: (Sat, 20 Mar 2010 15:35:16) > Xiangsong, > > Thank you for pointing this out. > > I was originally wondering if SGW does send DAVA for routing context X > only then how should AS/ASP interpret the same. > > At this moment I am not sure if this (SGW sending DAVA with routing > context X only) can happen in a real life network. > > And whether it is possible that a route for an SS7 destination is > available for one AS and not available for second AS through the same > SGW (given that both AS(s) are in Active state). Yes, it is possible. > > I would request others to comment on the following two points: > > 1. Whether it is possible that a route for an SS7 destination is > available for one AS (AS-1) and not available for second AS (AS-2) > through the same SGW (given that both AS(s) are in Active state), When > a "common ASP" is serving both AS-1 and AS-2 (given the common ASP is > active for both AS-1 and AS-2) Yes, it is possible. > 2. Whether it is possible that a route for an SS7 destination is > available for one AS (AS-1) and not available for second AS (AS-2) > through the same SGW (given that both AS(s) are in Active > state), When "two mutually exclusive" ASP(s), say ASP-1 and ASP-2 are > serving AS-1 and AS-2 respectively (given the ASP-1 is active for AS-1 > and ASP-2 is active for and AS-2) Yes, it is possible. Just because it is one SG does not mean that all AS that it serves have the same connectivity or routing to the SS7 network. For example, AS-1 may use one set of signalling links, and AS-2 may use another. Conditions in the SS7 network may cause one route set to become unavailable to one AS, yet it is available to another. The ASP, however, does not need to know this. All it needs to do is identify which AS correspond to an SNMM message (from the RC or NA in the message) and deliver the corresponding MTP primitive. This is in contrast with SGP within an SG: when an SS7 destination is inaccessible to an AS via one SGP it is inaccessilble to that AS via all SGP forming an SG. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From shivi.verma@aricent.com Sun Mar 21 20:54:06 2010 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 72A4B3A6936 for ; Sun, 21 Mar 2010 20:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.338 X-Spam-Level: * X-Spam-Status: No, score=1.338 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, 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 UdcIsdRDKJHU for ; Sun, 21 Mar 2010 20:54:05 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by core3.amsl.com (Postfix) with ESMTP id 102433A68D2 for ; Sun, 21 Mar 2010 20:54:05 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 9A98D36B50; Mon, 22 Mar 2010 09:20:40 +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 84E8436B24; Mon, 22 Mar 2010 09:20:40 +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; Mon, 22 Mar 2010 09:24:20 +0530 From: Shivi Singh Verma To: "bidulock@openss7.org" Date: Mon, 22 Mar 2010 09:24:19 +0530 Thread-Topic: [Sigtran] Rc utilization while processing SSNM messages Thread-Index: AcrHa9PFqQF4j1ajRo2txq+U8o8YVgCBtuJA Message-ID: <40102CD77F8ADA41B01CB6B9446DCC46045653AE@GUREXMB01.ASIAN.AD.ARICENT.COM> References: <40102CD77F8ADA41B01CB6B9446DCC46044EC3F9@GUREXMB01.ASIAN.AD.ARICENT.COM> <20100319073043.GA20985@openss7.org> <40102CD77F8ADA41B01CB6B9446DCC46044EC476@GUREXMB01.ASIAN.AD.ARICENT.COM> <20100319135516.GB20985@openss7.org> In-Reply-To: <20100319135516.GB20985@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] Rc utilization while processing SSNM 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, 22 Mar 2010 03:54:06 -0000 Hi brian, Does this mean a point code reachable through SG cannot different status th= rough different AS. Also what in the case of DAUD msg, what does the RC indentify? If it indica= tes AS, then do we have send DAUD msg to SG from each AS. Thanks & Regards Shivi Singh Verma -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Friday, March 19, 2010 7:25 PM To: Shivi Singh Verma Cc: sigtran@ietf.org Subject: Re: [Sigtran] Rc utilization while processing SSNM messages Shivi, No, that is not correct: except at an ASP in the multiple-SG-as-STP case, M3UA does not have to keep track of point code status at all. --brian Shivi Singh Verma wrote: (Fri, 19 Mar 2010 13:35:10) > > Then in that case, we have to maintain SSNM Point Code status > per AS per SG .That is, a point code reachable through SG can > have different status through different ASs. > > In M3UA stack, RC value is also utilized while processing > incoming DAVA. Based on RC value, AS will be identified and > update the status of point code reachable through SG for that > AS. > > Can you clarify whether my understanding is correct? > > Thanks & Regards > > Shivi Singh Verma > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Friday, March 19, 2010 1:01 PM > To: Shivi Singh Verma > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Rc utilization while processing SSSNM messages > > Shivi, > > Shivi Singh Verma wrote: (Fri, 19 Mar 2010 12:37:46) > > > > What the role of RC while receiving SSNM message > > > To identify the AS to which the message applies. > > --brian > > -- > 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." -- 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 Mon Mar 22 00:52:43 2010 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 11A4E3A6B0B for ; Mon, 22 Mar 2010 00:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 c5gV0sJ3G91M for ; Mon, 22 Mar 2010 00:52:42 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 3CA1D3A6881 for ; Mon, 22 Mar 2010 00:52:41 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:HriJLEftqjLrFrTkZ1SnvNgOpO4KQdZJ@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2M7qoPJ007266; Mon, 22 Mar 2010 01:52:50 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:YDKPJFJUuFGSlt9flDleNBGgyI/P3gci@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2M7qok0021518; Mon, 22 Mar 2010 01:52:50 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2M7qnUa021517; Mon, 22 Mar 2010 01:52:49 -0600 Date: Mon, 22 Mar 2010 01:52:49 -0600 From: "Brian F. G. Bidulock" To: Shivi Singh Verma Message-ID: <20100322075249.GA21356@openss7.org> Mail-Followup-To: Shivi Singh Verma , "sigtran@ietf.org" References: <40102CD77F8ADA41B01CB6B9446DCC46044EC3F9@GUREXMB01.ASIAN.AD.ARICENT.COM> <20100319073043.GA20985@openss7.org> <40102CD77F8ADA41B01CB6B9446DCC46044EC476@GUREXMB01.ASIAN.AD.ARICENT.COM> <20100319135516.GB20985@openss7.org> <40102CD77F8ADA41B01CB6B9446DCC46045653AE@GUREXMB01.ASIAN.AD.ARICENT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40102CD77F8ADA41B01CB6B9446DCC46045653AE@GUREXMB01.ASIAN.AD.ARICENT.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] Rc utilization while processing SSNM messages 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, 22 Mar 2010 07:52:43 -0000 Shivi, Shivi Singh Verma wrote: (Mon, 22 Mar 2010 09:24:19) > Hi brian, > Does this mean a point code reachable through SG cannot different > status through different AS. No. See my response on the other thread. > Also what in the case of DAUD msg, what does the RC indentify? If > it indicates AS, then do we have send DAUD msg to SG from each AS. RC always identifies AS. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bina.contact@gmail.com Tue Mar 16 01:53:15 2010 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 352593A6A0A for ; Tue, 16 Mar 2010 01:53:15 -0700 (PDT) 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 ixUncitN1oxe for ; Tue, 16 Mar 2010 01:53:14 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id C33CC3A68D1 for ; Tue, 16 Mar 2010 01:53:07 -0700 (PDT) Received: by pwj6 with SMTP id 6so2527170pwj.31 for ; Tue, 16 Mar 2010 01:53:13 -0700 (PDT) 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=JdhrqO+Gjsv53a4o5QMJqumtE66T+oHM9flaqedS3QE=; b=rfr+UvP0/UIqWwXHOpQTsy0LFgzaXzZ7i7aNzk7B0lsAMh+C28/nzzYqApHr+24m9u b9LJ20xcDiQQM6L3sQBBQZXaihfkPovuty/cS1TX+l765qIRXk0hYL9/YPaU53Fzi47N z3/IvWY8uwSW0PlSWd+EMmUwoK/YH13L1GB0g= 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=MHiOhjqcUqzWYb4hj321TrYgG5bdCA5oHyinr63nfPmSewA20NjpGfQe4gEjFl00Px YSTcISF6CCTxD401iQSL/2+mNalxnYsBxsv/Loz3q6dr+uzXe1jFLr53jFZax2CVPK5L Rnxu/Gk1awAwUBbEdS2NpZgXyexKESQmzFjqI= MIME-Version: 1.0 Received: by 10.115.98.13 with SMTP id a13mr1599586wam.88.1268729593608; Tue, 16 Mar 2010 01:53:13 -0700 (PDT) In-Reply-To: <20100316072123.GA23587@openss7.org> References: <20100316072123.GA23587@openss7.org> Date: Tue, 16 Mar 2010 14:23:13 +0530 Message-ID: From: ACHARYA B To: bidulock@openss7.org, ACHARYA B , sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016e649d552be3b660481e720cf X-Mailman-Approved-At: Tue, 23 Mar 2010 18:43:35 -0700 Subject: Re: [Sigtran] Fwd: difference between Sinalling types 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, 16 Mar 2010 08:53:15 -0000 --0016e649d552be3b660481e720cf Content-Type: text/plain; charset=ISO-8859-1 Can u explain by some illustrations or concepts that how sigtran works. On Tue, Mar 16, 2010 at 12:51 PM, Brian F. G. Bidulock wrote: > ACHARYA, > > Rest assured, your doubts are cleared: these signalling types > are concepts that are working everywhere! > > --brian > > ACHARYA B wrote: (Wed, 10 Mar 2010 14:34:32) > > > > Kindly clear my doubts on signalling types as mentioned below. > > > > ---------- Forwarded message ---------- > > From: ACHARYA B <[1]bina.contact@gmail.com> > > Date: Wed, Mar 10, 2010 at 2:29 PM > > Subject: difference between Sinalling types > > To: hannsjuergen.schwarzbauer@domain.hidden > > Hi, > > This is Bina an IN Engg working in SS7 but need some info from u > > regarding M2UA,M3UA, and E1s signalling working concept and why they > > are came into picture i.e. their relevance and significance. > > > > If u have any documents pls send also. > > > > Thanks. > > Bina > > -- > > Best Wishes, > > Brundaban > > > > -- > > Best Wishes, > > Brundaban > > > > References > > > > 1. mailto:bina.contact@gmail.com > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > -- Best Wishes, Brundaban --0016e649d552be3b660481e720cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can u explain by some illustrations or concepts that how sigtran works.
=
On Tue, Mar 16, 2010 at 12:51 PM, Brian F. G. Bi= dulock <bidulo= ck@openss7.org> wrote:
ACHARYA,

Rest assured, yo= ur doubts are cleared: these signalling types
are concepts that are work= ing everywhere!

--brian

ACHARYA B wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0(Wed, 10 Mar 2010 14:34:32)
>
> =A0 =A0Kindly clear my doubts on signalling = types as mentioned below.
>
> =A0 =A0---------- Forwarded messa= ge ----------
> =A0 =A0From: ACHARYA B <[1]bina.contact@gmail.com>
> =A0 =A0Date: Wed= , Mar 10, 2010 at 2:29 PM
> =A0 =A0Subject: difference between Sinall= ing types
> =A0 =A0To: hannsjuergen.schwarzbauer@domain.hidden
> =A0 =A0Hi,<= br>> =A0 =A0 =A0 =A0 =A0This is Bina an IN Engg working in SS7 but need = some info from u
> =A0 =A0regarding M2UA,M3UA, and E1s signalling wor= king concept and why they
> =A0 =A0are came into picture i.e. their relevance and significance.>
> =A0 =A0If u have any documents pls send also.
>
>= =A0 =A0Thanks.
> =A0 =A0Bina
> =A0 =A0--
> =A0 =A0Best W= ishes,
> =A0 =A0Brundaban
>
> =A0 =A0--
> =A0 =A0Best Wishes,
> =A0 =A0Brundaban=
>
> References
>
> =A0 =A01. mailto:bina.contact@gmail.com

> _= ______________________________________________
> Sigtran mailing list
> Sigtr= an@ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran<= br>

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



--
Best Wishes,
Brundaban
--0016e649d552be3b660481e720cf-- From shivi.verma@aricent.com Thu Mar 18 23:56:02 2010 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 2C6E73A68BB for ; Thu, 18 Mar 2010 23:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 0j9aUvGbY+KE for ; Thu, 18 Mar 2010 23:56:01 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by core3.amsl.com (Postfix) with ESMTP id 003D23A68BA for ; Thu, 18 Mar 2010 23:55:55 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id A933936B93 for ; Fri, 19 Mar 2010 12:22: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 92D3536B76 for ; Fri, 19 Mar 2010 12:22:29 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Fri, 19 Mar 2010 12:26:07 +0530 From: Shivi Singh Verma To: "sigtran@ietf.org" Date: Fri, 19 Mar 2010 12:26:06 +0530 Thread-Topic: [Sigtran]Rc utilization while processing SSSNM messages Thread-Index: AcrHMT87wYHdQsXuQMOZ44B9UhH+Dw== Message-ID: <40102CD77F8ADA41B01CB6B9446DCC46044EC3D2@GUREXMB01.ASIAN.AD.ARICENT.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_40102CD77F8ADA41B01CB6B9446DCC46044EC3D2GUREXMB01ASIANA_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 23 Mar 2010 18:44:02 -0700 Subject: [Sigtran] Rc utilization while processing SSSNM 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: Fri, 19 Mar 2010 06:57:21 -0000 --_000_40102CD77F8ADA41B01CB6B9446DCC46044EC3D2GUREXMB01ASIANA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What the role of RC while receiving SSNM message Thanks & Regards Shivi Singh Verma ________________________________ "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_40102CD77F8ADA41B01CB6B9446DCC46044EC3D2GUREXMB01ASIANA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What the role of RC while receiving SSNM message

 

Thanks & Regards

Shivi Singh Verma

 



"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_40102CD77F8ADA41B01CB6B9446DCC46044EC3D2GUREXMB01ASIANA_-- From bidulock@openss7.org Tue Mar 23 21:03:36 2010 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 CAB1A3A6BAC for ; Tue, 23 Mar 2010 21:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 TEA-5Jom2CEj for ; Tue, 23 Mar 2010 21:03:36 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 62E353A69C2 for ; Tue, 23 Mar 2010 21:03:30 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:3X97D/z8+XrkvTDFdP7l8N8iC0sFfloX@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2O43ct8019055; Tue, 23 Mar 2010 22:03:38 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:LBip/rmgVsHxQGRcX/9O8VRraPMQ2BVB@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2O43cHp004698; Tue, 23 Mar 2010 22:03:38 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2O43Rt7004693; Tue, 23 Mar 2010 22:03:27 -0600 Date: Tue, 23 Mar 2010 22:03:27 -0600 From: "Brian F. G. Bidulock" To: Shivi Singh Verma Message-ID: <20100324040327.GA4600@openss7.org> Mail-Followup-To: Shivi Singh Verma , "sigtran@ietf.org" References: <40102CD77F8ADA41B01CB6B9446DCC46044EC3D2@GUREXMB01.ASIAN.AD.ARICENT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40102CD77F8ADA41B01CB6B9446DCC46044EC3D2@GUREXMB01.ASIAN.AD.ARICENT.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] Rc utilization while processing SSSNM messages 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, 24 Mar 2010 04:03:36 -0000 Shivi, Shivi Singh Verma wrote: (Fri, 19 Mar 2010 12:26:06) > > What the role of RC while receiving SSNM message As with any message: to identify the AS to which the message applies. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From anandnilkal@gmail.com Tue Mar 23 19:47:44 2010 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 660CD3A677E for ; Tue, 23 Mar 2010 19:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 C8Hna5w21WPn for ; Tue, 23 Mar 2010 19:47:43 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BC3883A68B4 for ; Tue, 23 Mar 2010 19:47:40 -0700 (PDT) Received: by wwg30 with SMTP id 30so3609379wwg.31 for ; Tue, 23 Mar 2010 19:47:57 -0700 (PDT) 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=NsBdS94HlBYtDGkm6X7Kp8c5Z1MKWi7decIybx4DfGs=; b=QempGD3wrfSLGb4VbPIlQ0BLHo6FESjopW3+SjBD0VrXVd3JiHeewPzSnr3pYajwpd OLMHjzblpFj8KeRPAmNoqMV8CplPQh1PfYKLuemeql/lXDkWNvBcryUL+03PmUqogz3X ObkCe8diW01HyxpAyAHQqj5bAstJm4wy9KGUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UPIvS8Tv6xTC9F1jIR0PM4atQNHPwvh0fAAShQNLmnORB7248G+4cvgJDuL1aoCRGx NCiynMYZlwItj8CQZv5POoDs3ZJKjLsOY1xb9YOpqbCPslVb/7xYnAoMW6bN/anJwpKj p8w6Az9/7OuqgaCd80q06ppwhAFn7tdB78feE= MIME-Version: 1.0 Received: by 10.216.87.131 with SMTP id y3mr1806777wee.9.1269398877152; Tue, 23 Mar 2010 19:47:57 -0700 (PDT) Date: Wed, 24 Mar 2010 08:17:57 +0530 Message-ID: <6a1a80601003231947y51e24e6bsc178d1bee5c25827@mail.gmail.com> From: Anand N Ilkal To: sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016e6d77e5e26a4bd048282f55b X-Mailman-Approved-At: Wed, 24 Mar 2010 08:16:51 -0700 Subject: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not have any RC. 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, 24 Mar 2010 04:20:44 -0000 --0016e6d77e5e26a4bd048282f55b Content-Type: text/plain; charset=ISO-8859-1 Hello, In Double Exchange mode under IPSP-IPSP model. what should be the behaviour in case Remote Peer sends ASPAC without any Routing Context? Section 4.3.1 in RFC 4666 indicates the Single Exchange behaviour can be followed - extracts from RFC 4666 - "ASPTM messages. When sending ASPTM messages to activate/deactivate all the traffic independently of routing keys by not specifying any RC, a single exchange could be sufficient." Does it mean the local peer does not have to send ASPAC to the peer? Or is it just talking about multiple AS's in the remote peer? By sending only one ASPAC with no RC, it is updating the status for all the AS's in the remote peer which are served by the same ASP? -- with regards, Anand kumar Ilkal --0016e6d77e5e26a4bd048282f55b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

In Double Exchange mode under IPSP-IPSP model. what should be= the behaviour in case Remote Peer sends ASPAC without any Routing Context?=

Section 4.3.1 in RFC 4666 indicates the Single Exchange behaviour c= an be followed -

extracts from RFC 4666 -

"ASPTM messages. When sending ASPT= M messages to activate/deactivate
all the traffic independently of routi= ng keys by not specifying any
RC, a single exchange could be sufficient.= "

Does it mean the local peer does not have to send ASPAC to the peer?Or is it just talking about multiple AS's in the remote peer? By sendi= ng only one ASPAC with no RC, it is updating the status for all the AS'= s in the remote peer which are served by the same ASP?

--
with regards,
Anand kumar Ilkal
--0016e6d77e5e26a4bd048282f55b-- From bidulock@openss7.org Wed Mar 24 08:49:41 2010 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 BB3AF3A6C09 for ; Wed, 24 Mar 2010 08:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 d9K+YRZOILnS for ; Wed, 24 Mar 2010 08:49:40 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id C1D253A6B8F for ; Wed, 24 Mar 2010 08:41:00 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:0m//5BlO/aiP6wEuSQ8bBEZzB2d0gHu5@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2OFfI33031252; Wed, 24 Mar 2010 09:41:18 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:0XKCGnGD5BPa6490JjkXdWM0nZdluiYg@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2OFfIB5017567; Wed, 24 Mar 2010 09:41:18 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2OFfIU7017566; Wed, 24 Mar 2010 09:41:18 -0600 Date: Wed, 24 Mar 2010 09:41:18 -0600 From: "Brian F. G. Bidulock" To: Anand N Ilkal Message-ID: <20100324154118.GB14963@openss7.org> Mail-Followup-To: Anand N Ilkal , sigtran@ietf.org References: <6a1a80601003231947y51e24e6bsc178d1bee5c25827@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a1a80601003231947y51e24e6bsc178d1bee5c25827@mail.gmail.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] Behaviour in DE-IPSP model when ASPAC does not have any RC. 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, 24 Mar 2010 15:49:41 -0000 Anand, For each full duplex flow, DE requires one RC at one peer and another at the other peer. This requires a double-ended exchange to activate using RC. Where the IPSP has a conifgured AS (see 4.3.4.3 second paragraph), no RC is required in ASPAC, in which case, the AS at each end is known by both sides and a single-ended exchage _could_ be possible. That is all that it is saying. --brian Anand N Ilkal wrote: (Wed, 24 Mar 2010 08:17:57) > > Hello, > In Double Exchange mode under IPSP-IPSP model. what should be the > behaviour in case Remote Peer sends ASPAC without any Routing Context? > Section 4.3.1 in RFC 4666 indicates the Single Exchange behaviour can > be followed - > extracts from RFC 4666 - > "ASPTM messages. When sending ASPTM messages to activate/deactivate > all the traffic independently of routing keys by not specifying any > RC, a single exchange could be sufficient." > Does it mean the local peer does not have to send ASPAC to the peer? > Or is it just talking about multiple AS's in the remote peer? By > sending only one ASPAC with no RC, it is updating the status for all > the AS's in the remote peer which are served by the same ASP? > -- > with regards, > Anand kumar Ilkal > _______________________________________________ > 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 anandnilkal@gmail.com Wed Mar 24 18:41:18 2010 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 1C2BB3A688C for ; Wed, 24 Mar 2010 18:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.576 X-Spam-Level: X-Spam-Status: No, score=0.576 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 e6cY7vmytBeF for ; Wed, 24 Mar 2010 18:41:16 -0700 (PDT) Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by core3.amsl.com (Postfix) with ESMTP id 106B13A6B91 for ; Wed, 24 Mar 2010 18:41:15 -0700 (PDT) Received: by ewy27 with SMTP id 27so2136420ewy.13 for ; Wed, 24 Mar 2010 18:41:33 -0700 (PDT) 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:received:message-id:subject:from:to:content-type; bh=ZGHoPkJdpU5v2IAo0WF36pvv6PdTvGCB/IsbYWyIas8=; b=QZ2OgIry2T5dvo3i6JFw0zQSCfK6VaIHNVDmoHTmzMCCdAVlizm7ZeWa5CHWUJX2tX zdrA07X50u4krVvc73A3wtRPcKovsqnB7vryGpQ/eqsS13sRYYOqTC8AsYioWsefKriG MMnJj348boS2uVHmPGHKCdyXyVjgxGZcaTMRY= 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=bCS7LxdfrkEUA1x5OtlfqMNQixtPOxeEsDoeaEY3ONTlaMq4pUJwwwEdN+9GTKpLxE tYFIMzOmRq7ezaTuiM7hl4J97r4oFRc5b8X6co8XHlS6BV8f92ST4y4UV9+goI5EXBvB Xmd0GJz2OfRhuLMLmPYfq6b27kwftWktXaWOY= MIME-Version: 1.0 Received: by 10.213.9.204 with HTTP; Wed, 24 Mar 2010 18:41:33 -0700 (PDT) In-Reply-To: <20100324154118.GB14963@openss7.org> References: <6a1a80601003231947y51e24e6bsc178d1bee5c25827@mail.gmail.com> <20100324154118.GB14963@openss7.org> Date: Thu, 25 Mar 2010 07:11:33 +0530 Received: by 10.213.68.203 with SMTP id w11mr2479732ebi.43.1269481293026; Wed, 24 Mar 2010 18:41:33 -0700 (PDT) Message-ID: <6a1a80601003241841i7a02e70dy632a6ad085a22549@mail.gmail.com> From: Anand N Ilkal To: bidulock@openss7.org, Anand N Ilkal , sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016361375978518e2048296252c Subject: Re: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not have any RC. 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, 25 Mar 2010 01:41:18 -0000 --0016361375978518e2048296252c Content-Type: text/plain; charset=ISO-8859-1 Hello Brian, Thanks for the reply - i have a scenario - in the static configurations one node has two AS's served by same ASP. on the peer node i have one AS with an ASP. if peer node sends ASPAC without RC. this will make remote AS state ACTIVE and local AS's state also as ACTIVE in local stack. Though ASPAC_ACK would have all the RC's of remote AS's which ASP is serving, in this case only one. and remote stack would then mark its AS as ACTIVE and two AS's as ACTIVE in its stack. My question is what if out of two AS's only one AS at local stack is ready to serve traffic? Remote stack in this case by default assumes, both AS's as active. According to 4.3.1 in RFC 4666, if single exchange behaviour is followed and state machines are updated, we are not in a position to inform peer end about our true capability to serve traffic. IPSP A IPSP B AS1 RC=100 AS1 RC=300 ---------- ASP1 ------------- ASP1 AS2 RC=200 ---------- ASP1 INIT --------------------------------------------------------------------------------> <------------------------------------------------------------------------------- INIT_ACK COOKIE_ECHO --------------------------------------------------------------------------------> <------------------------------------------------------------------------------- COOKIE_ACK <------------------------------------------------------------------------------- ASPUP ASPUP_ACK --------------------------------------------------------------------------------> <------------------------------------------------------------------------------- ASPAC (without RC) ASPAC_ACK ---------------------------------------------------------------------------------> (IPSP B will mark all the AS's as active in its stack, which are served remote ASP, IPSP A also marks all remote AS's as active in local stack which are served by remote ASP) On 24 March 2010 21:11, Brian F. G. Bidulock wrote: > Anand, > > For each full duplex flow, DE requires one RC at one peer and another at > the > other peer. This requires a double-ended exchange to activate using RC. > Where the IPSP has a conifgured AS (see 4.3.4.3 second paragraph), no RC is > required in ASPAC, in which case, the AS at each end is known by both sides > and a single-ended exchage _could_ be possible. That is all that it is > saying. > > --brian > > Anand N Ilkal wrote: > (Wed, 24 Mar 2010 08:17:57) > > > > Hello, > > In Double Exchange mode under IPSP-IPSP model. what should be the > > behaviour in case Remote Peer sends ASPAC without any Routing Context? > > Section 4.3.1 in RFC 4666 indicates the Single Exchange behaviour can > > be followed - > > extracts from RFC 4666 - > > "ASPTM messages. When sending ASPTM messages to activate/deactivate > > all the traffic independently of routing keys by not specifying any > > RC, a single exchange could be sufficient." > > Does it mean the local peer does not have to send ASPAC to the peer? > > Or is it just talking about multiple AS's in the remote peer? By > > sending only one ASPAC with no RC, it is updating the status for all > > the AS's in the remote peer which are served by the same ASP? > > -- > > with regards, > > Anand kumar Ilkal > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > -- with regards, Anand kumar Ilkal --0016361375978518e2048296252c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Brian,

Thanks for the reply -

i have a scenario - in th= e static configurations

one node has two AS's served by same ASP= . on the peer node i have one AS with an ASP.

if peer node sends ASP= AC without RC. this will make remote AS state ACTIVE and local AS's sta= te also as ACTIVE in local stack. Though ASPAC_ACK would have all the RC= 9;s of remote AS's which ASP is serving, in this case only one. and rem= ote stack would then mark its AS as ACTIVE and two AS's as ACTIVE in it= s stack.

My question is what if out of two AS's only one AS at local stack i= s ready to serve traffic? Remote stack in this case by default assumes, bot= h AS's as active.

According to 4.3.1 in RFC 4666, if single exch= ange behaviour is followed and state machines are updated, we are not in a = position to inform peer end about our true capability to serve traffic.

IPSP A=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=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=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=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPSP B
A= S1 RC=3D100=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=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=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=A0=A0=A0=A0=A0=A0=A0 AS1 RC=3D300
=A0=A0=A0=A0=A0=A0 ---------- ASP1=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=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=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=A0=A0=A0=A0 ------------- ASP1AS2=A0 RC=3D200
=A0=A0=A0=A0=A0=A0 ---------- ASP1

=A0=A0 INIT= =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=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=A0=A0=A0 <-------------------------------------------= ------------------------------------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 INIT_ACK
=A0=A0 COOKIE_ECHO=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=A0=A0=A0=A0=A0=A0=A0=A0 <-------------------------------------------= ------------------------------------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 COOKIE_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=A0=A0 <-------------------------= ------------------------------------------------------=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 ASPUP
=A0=A0=A0 ASPUP_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=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 ASPAC= (without RC)
=A0=A0=A0 ASPAC_ACK=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------------------------= -------------------------------------------------------->=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 (IPSP B will mark all the AS's as active in its s= tack, which are served remote ASP, IPSP A also marks all remote AS's as= active in local stack which are served by remote ASP)




On 24 March 2010 21:11, Brian F.= G. Bidulock <= bidulock@openss7.org> wrote:
Anand,

For each full duplex flow, DE requires one RC at one peer and another at th= e
other peer. =A0This requires a double-ended exchange to activate using RC.<= br> Where the IPSP has a conifgured AS (see 4.3.4.3 second paragraph), no RC is=
required in ASPAC, in which case, the AS at each end is known by both sides=
and a single-ended exchage _could_ be possible. =A0That is all that it is s= aying.

--brian

Anand N Ilkal 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= (Wed, 24 Mar 2010 08:17:57)
>
> =A0 =A0Hello,
> =A0 =A0In Double Exchange mode under IPSP-IPSP model. what should be t= he
> =A0 =A0behaviour in case Remote Peer sends ASPAC without any Routing C= ontext?
> =A0 =A0Section 4.3.1 in RFC 4666 indicates the Single Exchange behavio= ur can
> =A0 =A0be followed -
> =A0 =A0extracts from RFC 4666 -
> =A0 =A0"ASPTM messages. When sending ASPTM messages to activate/d= eactivate
> =A0 =A0all the traffic independently of routing keys by not specifying= any
> =A0 =A0RC, a single exchange could be sufficient."
> =A0 =A0Does it mean the local peer does not have to send ASPAC to the = peer?
> =A0 =A0Or is it just talking about multiple AS's in the remote pee= r? By
> =A0 =A0sending only one ASPAC with no RC, it is updating the status fo= r all
> =A0 =A0the AS's in the remote peer which are served by the same AS= P?
> =A0 =A0--
> =A0 =A0with regards,
> =A0 =A0Anand kumar Ilkal

> _______________________________________________
> 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/



--
with regards,Anand kumar Ilkal
--0016361375978518e2048296252c-- From suresh.jaddu@nsn.com Wed Mar 24 21:16:13 2010 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 2BEEB3A6A2D for ; Wed, 24 Mar 2010 21:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.685 X-Spam-Level: X-Spam-Status: No, score=0.685 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FRT_BELOW2=2.154] 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 F9UKfB9od6jd for ; Wed, 24 Mar 2010 21:16:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id BB2763A6A5D for ; Wed, 24 Mar 2010 21:16:11 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2P4GSng007066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Mar 2010 05:16:28 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2P4GQqL016531; Thu, 25 Mar 2010 05:16:26 +0100 Received: from SGSIEXC017.nsn-intra.net ([10.159.224.99]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 05:16:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2010 12:15:39 +0800 Message-ID: <53078B21B5DDA14BA1E89B400224A335012F33B3@SGSIEXC017.nsn-intra.net> In-Reply-To: <20100324154118.GB14963@openss7.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not haveany RC. Thread-Index: AcrLaa4x3ZgFXczrTziwF7PUxWoB/wAZeTzQ References: <6a1a80601003231947y51e24e6bsc178d1bee5c25827@mail.gmail.com> <20100324154118.GB14963@openss7.org> From: "Jaddu, Suresh (NSN - IN/Bangalore)" To: , "Anand N Ilkal" X-OriginalArrivalTime: 25 Mar 2010 04:16:26.0398 (UTC) FILETIME=[EFB943E0:01CACBD1] Cc: sigtran@ietf.org Subject: Re: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not haveany RC. 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, 25 Mar 2010 04:16:13 -0000 Brain, Can we also interpret your bellow statement like this --> In IPSP double = exchange mode ASPACT from both sides MUST include the Routing context of = its local AS.=20 If that is correct then why in the RFC section 5.6.2 its mentioned that = Routing Context is optional in ASPAC message. Thanks Suresh. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On = Behalf Of ext Brian F. G. Bidulock Sent: Wednesday, March 24, 2010 9:11 PM To: Anand N Ilkal Cc: sigtran@ietf.org Subject: Re: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not = haveany RC. Anand, For each full duplex flow, DE requires one RC at one peer and another at = the other peer. This requires a double-ended exchange to activate using RC. Where the IPSP has a conifgured AS (see 4.3.4.3 second paragraph), no RC = is required in ASPAC, in which case, the AS at each end is known by both = sides and a single-ended exchage _could_ be possible. That is all that it is = saying. --brian Anand N Ilkal wrote: = (Wed, 24 Mar 2010 08:17:57) >=20 > Hello, > In Double Exchange mode under IPSP-IPSP model. what should be the > behaviour in case Remote Peer sends ASPAC without any Routing = Context? > Section 4.3.1 in RFC 4666 indicates the Single Exchange behaviour = can > be followed - > extracts from RFC 4666 - > "ASPTM messages. When sending ASPTM messages to activate/deactivate > all the traffic independently of routing keys by not specifying any > RC, a single exchange could be sufficient." > Does it mean the local peer does not have to send ASPAC to the = peer? > Or is it just talking about multiple AS's in the remote peer? By > sending only one ASPAC with no RC, it is updating the status for = all > the AS's in the remote peer which are served by the same ASP? > -- > with regards, > Anand kumar Ilkal > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran From shivi.verma@aricent.com Thu Mar 25 02:02:01 2010 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 D8DC03A69B5 for ; Thu, 25 Mar 2010 02:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 pdRWeveBbfRU for ; Thu, 25 Mar 2010 02:02:00 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 48D0D3A6C72 for ; Thu, 25 Mar 2010 02:01:59 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 169C136B8A for ; Thu, 25 Mar 2010 14:28:37 +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 F3E0E36B5F for ; Thu, 25 Mar 2010 14:28:36 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Thu, 25 Mar 2010 14:32:18 +0530 From: Shivi Singh Verma To: "sigtran@ietf.org" Date: Thu, 25 Mar 2010 14:32:16 +0530 Thread-Topic: Query related to ASPTM message exchange in IPSP-DE mode Thread-Index: AcrL+d3aQQIASbtUTey/xdLk2VX2uw== Message-ID: <40102CD77F8ADA41B01CB6B9446DCC46045EAE4E@GUREXMB01.ASIAN.AD.ARICENT.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_40102CD77F8ADA41B01CB6B9446DCC46045EAE4EGUREXMB01ASIANA_" MIME-Version: 1.0 Cc: Debasri Sarkar Subject: [Sigtran] Query related to ASPTM message exchange in IPSP-DE mode 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, 25 Mar 2010 09:02:01 -0000 --_000_40102CD77F8ADA41B01CB6B9446DCC46045EAE4EGUREXMB01ASIANA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, RFC 4666 mentions about special cases in IPSP DE mode. Following are the excerpts from RFC 4666 section 4.3.1: --------------------------------------- Then the transitions in brackets can be used for the IPSP DE model communication (DE-IPSPs) and are related to the special cases when just one ASP*M messages exchange is needed, as follows: - ASPSM messages. When exchanging ASPSM messages using only a single exchange (only one request and one acknowledgment). . Example: (see section 5.6.2) whenever a DE-IPSP is taking the leading role to start communication to a peer DE-IPSP, it sends ASP Up message to the peer DE-IPSP. The peer MAY consider the initiating DE-IPSPs as being in ASP-INACTIVE state, as it already sent a message, and answer back with ASP Up Ack. Upon the reception of this answer by the initiating DE-IPSP it also MAY consider the peer as being in ASP-INACTIVE state since it did respond. Therefore a second ASP Up message exchange to be started by the peer DE-IPSP could be avoided. In this case the reception of ASP Up Ack will turn into a state change. - ASPTM messages. When sending ASPTM messages to activate/deactivate all the traffic independently of routing keys by not specifying any RC, a single exchange could be sufficient. --------------------------------------- The question is 1. Whether the sender of ASPAC message without RC should wait for corresp= onding ASPAC message from peer IPSP. 2. Whether the receiver of ASPAC/ASPAC ACK message should activate all re= mote AS as well as all local AS. Thanks & Regards Shivi Singh Verma ________________________________ "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_40102CD77F8ADA41B01CB6B9446DCC46045EAE4EGUREXMB01ASIANA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

<= span style=3D"font-size:10.0pt;font-family:Tahoma;color:#333399">RFC 4666 m= entions about special cases in IPSP DE mode.

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

<= span style=3D"font-size:10.0pt;font-family:Tahoma;color:#333399">Following = are the excerpts from RFC 4666 section 4.3.1:

---------------------------------------

  Then the transitions in brackets can be used for the IPS= P DE model

   communication (DE-IPSPs) and are related to the sp= ecial cases when

   just one ASP*M messages exchange is needed, as fol= lows:

 

   - ASPSM messages. When exchanging ASPSM messages u= sing only a single

     exchange (only one request and one ack= nowledgment). .

     Example: (see section 5.6.2) whenever = a DE-IPSP is taking the

     leading role to start communication to= a peer DE-IPSP, it sends ASP

     Up message to the peer DE-IPSP. The pe= er MAY consider the initiating

     DE-IPSPs as being in ASP-INACTIVE stat= e, as it already sent a

     message, and answer back with ASP Up A= ck. Upon the reception of this

     answer by the initiating DE-IPSP it al= so MAY consider the peer as

     being in ASP-INACTIVE state since it d= id respond. Therefore a second

     ASP Up message exchange to be started = by the peer DE-IPSP could be

     avoided. In this case the reception of= ASP Up Ack will turn into a

     state change.=

 

   - ASPTM messages. When sending ASPTM messages to activate/deactivate

=      all the traffic independently of routing keys = by not specifying any

=      RC, a single exchange could be sufficient.

---------------------------------------

The question is

  1. = Whether the sender of ASPAC messa= ge without RC should wait for corresponding ASPAC message from peer IPSP.
  2. Whether the receiver of ASPAC/ASP= AC ACK message should activate all remote AS as well as all local AS.

 

 

Thanks & Regards

Shivi Singh Verma

 



"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_40102CD77F8ADA41B01CB6B9446DCC46045EAE4EGUREXMB01ASIANA_-- From bidulock@openss7.org Thu Mar 25 03:31:17 2010 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 5FE3B3A686E for ; Thu, 25 Mar 2010 03:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FRT_BELOW2=2.154] 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 vqZoUh8AzQpl for ; Thu, 25 Mar 2010 03:31:16 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 42CF63A6909 for ; Thu, 25 Mar 2010 03:31:15 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:wP6NdNF2zpoWqIkzhL2S/XdmdKT2BbGd@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2PAVW8f017500; Thu, 25 Mar 2010 04:31:32 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:w7wYc/pDsJ9srcggoxY/gm7RL/ZGq8XX@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2PAVWxo004484; Thu, 25 Mar 2010 04:31:32 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2PAVV7K004483; Thu, 25 Mar 2010 04:31:31 -0600 Date: Thu, 25 Mar 2010 04:31:31 -0600 From: "Brian F. G. Bidulock" To: "Jaddu, Suresh (NSN - IN/Bangalore)" Message-ID: <20100325103131.GB3577@openss7.org> Mail-Followup-To: "Jaddu, Suresh (NSN - IN/Bangalore)" , Anand N Ilkal , sigtran@ietf.org References: <6a1a80601003231947y51e24e6bsc178d1bee5c25827@mail.gmail.com> <20100324154118.GB14963@openss7.org> <53078B21B5DDA14BA1E89B400224A335012F33B3@SGSIEXC017.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53078B21B5DDA14BA1E89B400224A335012F33B3@SGSIEXC017.nsn-intra.net> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Anand N Ilkal , sigtran@ietf.org Subject: Re: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not haveany RC. 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, 25 Mar 2010 10:31:17 -0000 Jaddu,, Jaddu, Suresh (NSN - IN/Bangalore) wrote: (Thu, 25 Mar 2010 12:15:39) > > Can we also interpret your bellow statement like this --> In IPSP > double exchange mode ASPACT from both sides MUST include the Routing > context of its local AS. No. There is no such statement in the RFC. > If that is correct then why in the RFC section 5.6.2 its mentioned > that Routing Context is optional in ASPAC message. It is not really optional. That is, there are degrees of optional. 4.3.4.3 says... ... In the case where an ASP wishes to process the traffic for more than one Application Server across a common SCTP association, the ASP Active message(s) SHOULD contain a list of one or more Routing Contexts to indicate for which Application Servers the ASP Active message applies. ... Thus, including RC in ASPAC is not completely optional. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From anandnilkal@gmail.com Thu Mar 25 07:53:35 2010 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 853913A6A71 for ; Thu, 25 Mar 2010 07:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.826 X-Spam-Level: * X-Spam-Status: No, score=1.826 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, FRT_BELOW2=2.154, 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 9nhrOgoO6tzP for ; Thu, 25 Mar 2010 07:53:30 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E1BAD3A6A39 for ; Thu, 25 Mar 2010 07:53:28 -0700 (PDT) Received: by wwb31 with SMTP id 31so174417wwb.31 for ; Thu, 25 Mar 2010 07:53:48 -0700 (PDT) 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=oB+EZAm2mzn6BhpaQs1v0nybKHG5wFBgICbPjbwkGXk=; b=OSEAzA31E+IiRK89WQte6z5Kh5LuPRxTKsoUaF4jDSzMOSRSMvUQBdcOQ6/mKkCqT3 pS4TCtHhB/zMtvpBfFXWC/G9u2K7uriIMbuXoz26FeYMO0n3IU9x8QN+Z2GY0f+Ngvfy zSi5K5I8HRNfeM5cs2p2or3ud2qT+64MSv+mY= 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=tVVBlp2l1UYW7NgFFa/1D6asLVogphL3PE/SEWCcvTxAKhl1z7YgQs18i7lF6rjPiR bSzxFPsh+Gh/ZmjN2OS84/Kon4KOr5mo453utJ1cpuShs5R8DPTO6K9jVwVxFcxXIeq5 bcR0wkSN4BKsw1hgWyaWSdUd4GS2eOGQQpzJE= MIME-Version: 1.0 Received: by 10.216.179.133 with SMTP id h5mr1605987wem.62.1269528827753; Thu, 25 Mar 2010 07:53:47 -0700 (PDT) In-Reply-To: <20100325103131.GB3577@openss7.org> References: <6a1a80601003231947y51e24e6bsc178d1bee5c25827@mail.gmail.com> <20100324154118.GB14963@openss7.org> <53078B21B5DDA14BA1E89B400224A335012F33B3@SGSIEXC017.nsn-intra.net> <20100325103131.GB3577@openss7.org> Date: Thu, 25 Mar 2010 20:23:47 +0530 Message-ID: <6a1a80601003250753r584474e0k47ee24eb61971a10@mail.gmail.com> From: Anand N Ilkal To: bidulock@openss7.org, "Jaddu, Suresh (NSN - IN/Bangalore)" , Anand N Ilkal , sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016e64c0b8ccf835b0482a136ea Subject: Re: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not haveany RC. 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, 25 Mar 2010 14:53:35 -0000 --0016e64c0b8ccf835b0482a136ea Content-Type: text/plain; charset=ISO-8859-1 Hello Brian, could you please provide your thoughts on the scenario earlier explained? re-produced just for clarification... My doubt is if the following scenario is correct in Double Exchange mode- IPSP A IPSP B LAS1 RC=100 RAS1 RC=300 ---------- LASP1 ------------ RASP1 LAS2 RC=200 ---------- LASP1 INIT ---------------------------------------------------------------> <---------------------------------------------------------------- INIT_ACK COOKIE_ECHO --------------------------------------------------------------> <---------------------------------------------------------------- COOKIE_ACK <---------------------------------------------------------------- ASPUP ASPUP_ACK ---------------------------------------------------------------> <---------------------------------------------------------------- ASPAC (without RC) ASPAC_ACK ----------------------------------------------------------------> *IPSP A marks LAS1, LAS2, RAS1, LASP1 and RASP1 as ACTIVE in its stack after receiving ASPAC without any RC, similarly after receiving ASPAC_ACK IPSP B will mark LAS1, LAS2, RAS1, LASP1 and RASP1 as ACTIVE in its stack*. *And Hence there is no need for sending ASPAC from IPSP A*. On 25 March 2010 16:01, Brian F. G. Bidulock wrote: > Jaddu,, > > Jaddu, Suresh (NSN - IN/Bangalore) wrote: (Thu, 25 Mar 2010 12:15:39) > > > > Can we also interpret your bellow statement like this --> In IPSP > > double exchange mode ASPACT from both sides MUST include the Routing > > context of its local AS. > > No. There is no such statement in the RFC. > > > If that is correct then why in the RFC section 5.6.2 its mentioned > > that Routing Context is optional in ASPAC message. > > It is not really optional. That is, there are degrees of optional. > > 4.3.4.3 says... > > ... In the case where an ASP wishes to > process the traffic for more than one Application Server across a > common SCTP association, the ASP Active message(s) SHOULD contain a > list of one or more Routing Contexts to indicate for which > Application Servers the ASP Active message applies. ... > > Thus, including RC in ASPAC is not completely optional. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > -- with regards, Anand kumar Ilkal --0016e64c0b8ccf835b0482a136ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Brian,

could you please provide your thoughts on the scenario = earlier explained?
re-produced just for clarification...

My doub= t is if the following scenario is correct in Double Exchange mode-

IPSP A=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=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=A0=A0=A0=A0=A0=A0= =A0 IPSP B
LAS1 RC=3D100=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=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 RAS1 RC=3D300
=A0=A0=A0=A0=A0=A0 ---------- LASP1=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=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 ------------ RASP1
LAS2=A0 RC=3D200=A0=A0=A0=A0=A0=A0 ---------- LASP1

=A0=A0 INIT=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=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=A0=A0=A0 <----------------------------------------------------------------=20 INIT_ACK
=A0=A0 COOKIE_ECHO=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= =A0=A0=A0=A0=A0=A0=A0=A0 <----------------------------------------------------------------=20 COOKIE_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=A0=A0 <----------------------------------------------------------------=A0=A0 ASPUP
=A0=A0=A0 ASPUP_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=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 <----------------------------------------------------------------=A0=A0 ASPAC (without RC)
=A0=A0=A0 ASPAC_ACK=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ---------------------------------------------------------------->

And Hence there is no need for sending ASPAC from IPSP A.=




On 25 March 2010 16:01, Brian F.= G. Bidulock <= bidulock@openss7.org> wrote:
Jaddu,,

Jaddu, Suresh (NSN - IN/Bangalore) wrote: =A0 =A0(Thu, 25 Mar 2010 12:15:39= )
>
> Can we also interpret your bellow statement like this --> In IPSP > double exchange mode ASPACT from both sides MUST include the Routing > context of its local AS.

No. =A0There is no such statement in the RFC.

> If that is correct then why in the RFC section 5.6.2 its mentioned
> that Routing Context is optional in ASPAC message.

It is not really optional. =A0That is, there are degrees of optional.=

4.3.4.3 says...

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... =A0In the case = where an ASP wishes to
=A0 process the traffic for more than one Application Server across a
=A0 common SCTP association, the ASP Active message(s) SHOULD contain a =A0 list of one or more Routing Contexts to indicate for which
=A0 Application Servers the ASP Active message applies. =A0...

Thus, including RC in ASPAC is not completely optional.

--brian



--
with regard= s,
Anand kumar Ilkal
--0016e64c0b8ccf835b0482a136ea-- From bidulock@openss7.org Thu Mar 25 12:33:23 2010 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 92B963A6A94 for ; Thu, 25 Mar 2010 12:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 zHeejNw+lok2 for ; Thu, 25 Mar 2010 12:33:22 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 965C23A6991 for ; Thu, 25 Mar 2010 12:33:17 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:xQcXiCI8eIF3cjEYpfpf+KO7YylyIiL5@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2PJXbAA026707; Thu, 25 Mar 2010 13:33:37 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:FPWdjl2AUpz72XfG3AZuGPN0ECh1gqJU@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2PJXbff014620; Thu, 25 Mar 2010 13:33:37 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2PJXahN014619; Thu, 25 Mar 2010 13:33:36 -0600 Date: Thu, 25 Mar 2010 13:33:36 -0600 From: "Brian F. G. Bidulock" To: Anand N Ilkal Message-ID: <20100325193336.GA14424@openss7.org> Mail-Followup-To: Anand N Ilkal , "Jaddu, Suresh (NSN - IN/Bangalore)" , sigtran@ietf.org References: <6a1a80601003231947y51e24e6bsc178d1bee5c25827@mail.gmail.com> <20100324154118.GB14963@openss7.org> <53078B21B5DDA14BA1E89B400224A335012F33B3@SGSIEXC017.nsn-intra.net> <20100325103131.GB3577@openss7.org> <6a1a80601003250753r584474e0k47ee24eb61971a10@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a1a80601003250753r584474e0k47ee24eb61971a10@mail.gmail.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] Behaviour in DE-IPSP model when ASPAC does not haveany RC. 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, 25 Mar 2010 19:33:23 -0000 Anand, Your example does not make any sense to me: you did know that for DE mode to work, each AS must be defined at either end of the association and that a separate RK, RS and AS must be defined for each direction of traffic? Please provide the real-world RK's for the AS in your example. --brian Anand N Ilkal wrote: (Thu, 25 Mar 2010 20:23:47) > > Hello Brian, > could you please provide your thoughts on the scenario earlier > explained? > re-produced just for clarification... > My doubt is if the following scenario is correct in Double Exchange > mode- > > IPSP A IPSP B > LAS1 RC=100 RAS1 RC=300 > ---------- LASP1 ------------ RASP1 > LAS2 RC=200 > ---------- LASP1 > INIT ---------------------------------------------------------------> > <---------------------------------------------------------------- > INIT_ACK > COOKIE_ECHO > --------------------------------------------------------------> > <---------------------------------------------------------------- > COOKIE_ACK > <---------------------------------------------------------------- > ASPUP > ASPUP_ACK > ---------------------------------------------------------------> > <---------------------------------------------------------------- > ASPAC (without RC) > ASPAC_ACK > ----------------------------------------------------------------> > > IPSP A marks LAS1, LAS2, RAS1, LASP1 and RASP1 as ACTIVE in its stack > after receiving ASPAC without any RC, similarly after receiving > ASPAC_ACK IPSP B will mark LAS1, LAS2, RAS1, LASP1 and RASP1 as ACTIVE > in its stack. And Hence there is no need for sending ASPAC from IPSP > A. -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From anandnilkal@gmail.com Thu Mar 25 16:55:41 2010 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 29D993A6838 for ; Thu, 25 Mar 2010 16:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.059 X-Spam-Level: X-Spam-Status: No, score=0.059 tagged_above=-999 required=5 tests=[AWL=1.527, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 L8uKq0ixmNvp for ; Thu, 25 Mar 2010 16:55:38 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 3EFD13A683E for ; Thu, 25 Mar 2010 16:55:37 -0700 (PDT) Received: by wwb31 with SMTP id 31so527571wwb.31 for ; Thu, 25 Mar 2010 16:55:57 -0700 (PDT) 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:received:message-id:subject:from:to:content-type; bh=q4K7fAltSfI81n7pkbRMQcLslX2FH1Irih73KIoQlw4=; b=fE5iGhzmCPgmp7TpTcBcSjIsiNC2jXQe7bT649iGe/odAMZP1Un5Fckg9FA199RTJZ gCueaRQEfMuqsHREi1pbhfpD1VSD4QElsWB11tqT6kg+dUZabOcK+QILD0LUHd+zO5dI tQZ7+GrhPR349+XjMNDdHIvceAy5zzNojmXCk= 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=SP0IKg+Qke4R6axZEl60v6m6w4jtNvO+S/D7jZ/liL4Dwv0llWgih22iHyonVx7GGx 4uzsuf3HTs6aFmZ/yELyDhK8R1PNRhDR4DwkroClWFfcOpR8gi1XDBPqJ3ZIfFMSb1+c TcAIhEeK1yS5MqhR0WTxgcOhQWX5tKbKavXEo= MIME-Version: 1.0 Received: by 10.216.159.78 with HTTP; Thu, 25 Mar 2010 16:55:57 -0700 (PDT) In-Reply-To: <20100325193336.GA14424@openss7.org> References: <6a1a80601003231947y51e24e6bsc178d1bee5c25827@mail.gmail.com> <20100324154118.GB14963@openss7.org> <53078B21B5DDA14BA1E89B400224A335012F33B3@SGSIEXC017.nsn-intra.net> <20100325103131.GB3577@openss7.org> <6a1a80601003250753r584474e0k47ee24eb61971a10@mail.gmail.com> <20100325193336.GA14424@openss7.org> Date: Fri, 26 Mar 2010 05:25:57 +0530 Received: by 10.216.85.194 with SMTP id u44mr10040wee.65.1269561357343; Thu, 25 Mar 2010 16:55:57 -0700 (PDT) Message-ID: <6a1a80601003251655n7d03191cr51304ac92d65e690@mail.gmail.com> From: Anand N Ilkal To: bidulock@openss7.org, Anand N Ilkal , "Jaddu, Suresh (NSN - IN/Bangalore)" , sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016e6d7e744b99e800482a8c972 Subject: Re: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not haveany RC. 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, 25 Mar 2010 23:55:41 -0000 --0016e6d7e744b99e800482a8c972 Content-Type: text/plain; charset=ISO-8859-1 hello Brian, Yes, even i doubt the scenario. In other do you see any scenario under which only one ASPAC/ASPAC_ACK are enough to start traffic both ends in Double Exchange mode? Here RK's are made up of just DPC. And the references are from IPSP A node. LAS1 is Local AS1 with Routing Context 100 (values are fixed from static configuration) LAS2 is Local AS2 with Routing Context 200 (values are fixed from static configuration) RAS1 is Remote AS1 with Routing Context 300 (values are fixed from static configuration) LASP1 is ASP at IPSP A serving LAS1 and LAS2 RASP1 is ASP at IPSP B serving RAS1. my question is regarding the following statement in RFC. Does it says, one ASPAC (without RC) from Peer. and ASPAC_ACK from local is enough to start traffic from both ends? Or It says sender of ASPTM message to activate/deactivate all traffic, can send one ASPAC without any RC, And it expecte peer end to send its own ASPAC. - ASPTM messages. When sending ASPTM messages to activate/deactivate all the traffic independently of routing keys by not specifying any RC, a single exchange could be sufficient. On 26 March 2010 01:03, Brian F. G. Bidulock wrote: > Anand, > > Your example does not make any sense to me: you did know that for > DE mode to work, each AS must be defined at either end of the > association and that a separate RK, RS and AS must be defined > for each direction of traffic? > > Please provide the real-world RK's for the AS in your example. > > --brian > > Anand N Ilkal wrote: (Thu, 25 Mar 2010 20:23:47) > > > > Hello Brian, > > could you please provide your thoughts on the scenario earlier > > explained? > > re-produced just for clarification... > > My doubt is if the following scenario is correct in Double Exchange > > mode- > > > > IPSP A IPSP B > > LAS1 RC=100 RAS1 RC=300 > > ---------- LASP1 ------------ RASP1 > > LAS2 RC=200 > > ---------- LASP1 > > INIT ---------------------------------------------------------------> > > <---------------------------------------------------------------- > > INIT_ACK > > COOKIE_ECHO > > --------------------------------------------------------------> > > <---------------------------------------------------------------- > > COOKIE_ACK > > <---------------------------------------------------------------- > > ASPUP > > ASPUP_ACK > > ---------------------------------------------------------------> > > <---------------------------------------------------------------- > > ASPAC (without RC) > > ASPAC_ACK > > ----------------------------------------------------------------> > > > > IPSP A marks LAS1, LAS2, RAS1, LASP1 and RASP1 as ACTIVE in its stack > > after receiving ASPAC without any RC, similarly after receiving > > ASPAC_ACK IPSP B will mark LAS1, LAS2, RAS1, LASP1 and RASP1 as ACTIVE > > in its stack. And Hence there is no need for sending ASPAC from IPSP > > A. > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > -- with regards, Anand kumar Ilkal --0016e6d7e744b99e800482a8c972 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hello Brian,

Yes, even i doubt the scenario. In other do you see any= scenario under which only one ASPAC/ASPAC_ACK are enough to start traffic = both ends in Double Exchange mode?

Here RK's are made up of just= DPC. And the references are from IPSP A node.

LAS1=A0=A0=A0=A0=A0=A0=A0 is Local AS1 with Routing Context 100 (values= are fixed from static configuration)
LAS2=A0=A0=A0=A0=A0=A0=A0 is Local= AS2 with Routing Context 200 (values are fixed from static configuration)<= br>RAS1=A0=A0=A0=A0=A0=A0=A0 is Remote AS1 with Routing Context 300 (values= are fixed from static configuration)
LASP1=A0=A0=A0=A0=A0 is ASP at IPSP A serving LAS1 and LAS2
RASP1=A0=A0= =A0=A0=A0 is ASP at IPSP B serving RAS1.

my question is regarding th= e following statement in RFC.

Does it says, one ASPAC (without RC) = from Peer. and ASPAC_ACK from local is enough to start traffic from both en= ds?

Or

It says sender of ASPTM message to activate/deactivate all tr= affic, can send one ASPAC without any RC, And it expecte peer end to send i= ts own ASPAC.
- A= SPTM messages. W= hen sending ASPTM messages to activate/deactivate

= =A0=A0=A0=A0 all the traffic independently of routing keys by not s= pecifying any

= =A0=A0=A0=A0 RC, a single exchange could be sufficient.



On 26 March 2010 01:03, Brian F. G. Bidu= lock <bidulock= @openss7.org> wrote:
Anand,

Your example does not make any sense to me: you did know that for
DE mode to work, each AS must be defined at either end of the
association and that a separate RK, RS and AS must be defined
for each direction of traffic?

Please provide the real-world RK's for the AS in your example.

--brian

Anand N Ilkal wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Thu, 25 Mar 2010 20:2= 3:47)
>
> =A0 =A0Hello Brian,
> =A0 =A0could you please provide your thoughts on the scenario earlier<= br> > =A0 =A0explained?
> =A0 =A0re-produced just for clarification...
> =A0 =A0My doubt is if the following scenario is correct in Double Exch= ange
> =A0 =A0mode-
>
> =A0 =A0IPSP A IPSP B
> =A0 =A0LAS1 RC=3D100 RAS1 RC=3D300
> =A0 =A0---------- LASP1 ------------ RASP1
> =A0 =A0LAS2 RC=3D200
> =A0 =A0---------- LASP1
> =A0 =A0INIT ----------------------------------------------------------= ----->
> =A0 =A0<-----------------------------------------------------------= -----
> =A0 =A0INIT_ACK
> =A0 =A0COOKIE_ECHO
> =A0 =A0--------------------------------------------------------------&= gt;
> =A0 =A0<-----------------------------------------------------------= -----
> =A0 =A0COOKIE_ACK
> =A0 =A0<-----------------------------------------------------------= -----
> =A0 =A0ASPUP
> =A0 =A0ASPUP_ACK
> =A0 =A0---------------------------------------------------------------= >
> =A0 =A0<-----------------------------------------------------------= -----
> =A0 =A0ASPAC (without RC)
> =A0 =A0ASPAC_ACK
> =A0 =A0---------------------------------------------------------------= ->
>
> =A0 =A0IPSP A marks LAS1, LAS2, RAS1, LASP1 and RASP1 as ACTIVE in its= stack
> =A0 =A0after receiving ASPAC without any RC, similarly after receiving=
> =A0 =A0ASPAC_ACK IPSP B will mark LAS1, LAS2, RAS1, LASP1 and RASP1 as= ACTIVE
> =A0 =A0in its stack. And Hence there is no need for sending ASPAC from= IPSP
> =A0 =A0A.

--



--
with regard= s,
Anand kumar Ilkal
--0016e6d7e744b99e800482a8c972-- From bidulock@openss7.org Thu Mar 25 17:24:24 2010 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 DE1023A69BF for ; Thu, 25 Mar 2010 17:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 WapDwzOkBV5h for ; Thu, 25 Mar 2010 17:24:23 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 062B13A6A3A for ; Thu, 25 Mar 2010 17:24:21 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:G7lU7u4ekx4EcAFQfhm1h4PDomVoDudK@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2Q0OfH1031463; Thu, 25 Mar 2010 18:24:41 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:qfh/2ulWPbd3IH2NH3sRxORtqdPIavof@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2Q0Ofc0020076; Thu, 25 Mar 2010 18:24:41 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2Q0OfFb020075; Thu, 25 Mar 2010 18:24:41 -0600 Date: Thu, 25 Mar 2010 18:24:41 -0600 From: "Brian F. G. Bidulock" To: Anand N Ilkal Message-ID: <20100326002441.GA19977@openss7.org> Mail-Followup-To: Anand N Ilkal , "Jaddu, Suresh (NSN - IN/Bangalore)" , sigtran@ietf.org References: <6a1a80601003231947y51e24e6bsc178d1bee5c25827@mail.gmail.com> <20100324154118.GB14963@openss7.org> <53078B21B5DDA14BA1E89B400224A335012F33B3@SGSIEXC017.nsn-intra.net> <20100325103131.GB3577@openss7.org> <6a1a80601003250753r584474e0k47ee24eb61971a10@mail.gmail.com> <20100325193336.GA14424@openss7.org> <6a1a80601003251655n7d03191cr51304ac92d65e690@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a1a80601003251655n7d03191cr51304ac92d65e690@mail.gmail.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] Behaviour in DE-IPSP model when ASPAC does not haveany RC. 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: Fri, 26 Mar 2010 00:24:25 -0000 Anand, And what would those DPC values be for each AS? --brian Anand N Ilkal wrote: (Fri, 26 Mar 2010 05:25:57) > > hello Brian, > Yes, even i doubt the scenario. In other do you see any scenario under > which only one ASPAC/ASPAC_ACK are enough to start traffic both ends > in Double Exchange mode? > Here RK's are made up of just DPC. And the references are from IPSP A > node. > LAS1 is Local AS1 with Routing Context 100 (values are fixed > from static configuration) > LAS2 is Local AS2 with Routing Context 200 (values are fixed > from static configuration) > RAS1 is Remote AS1 with Routing Context 300 (values are fixed > from static configuration) > LASP1 is ASP at IPSP A serving LAS1 and LAS2 > RASP1 is ASP at IPSP B serving RAS1. > my question is regarding the following statement in RFC. > Does it says, one ASPAC (without RC) from Peer. and ASPAC_ACK from > local is enough to start traffic from both ends? > Or > It says sender of ASPTM message to activate/deactivate all traffic, > can send one ASPAC without any RC, And it expecte peer end to send its > own ASPAC. > - ASPTM messages. When sending ASPTM messages to activate/deactivate > > all the traffic independently of routing keys by not specifying > any > > RC, a single exchange could be sufficient. > > On 26 March 2010 01:03, Brian F. G. Bidulock <[1]bidulock@openss7.org> > wrote: > > Anand, > Your example does not make any sense to me: you did know that for > DE mode to work, each AS must be defined at either end of the > association and that a separate RK, RS and AS must be defined > for each direction of traffic? > Please provide the real-world RK's for the AS in your example. > --brian > Anand N Ilkal wrote: (Thu, 25 Mar 2010 20:23:47) > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From anandnilkal@gmail.com Thu Mar 25 17:32:03 2010 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 48C773A6970 for ; Thu, 25 Mar 2010 17:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 yXb7Em1-3HcM for ; Thu, 25 Mar 2010 17:32:02 -0700 (PDT) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by core3.amsl.com (Postfix) with ESMTP id C6BBD3A6924 for ; Thu, 25 Mar 2010 17:32:01 -0700 (PDT) Received: by fxm1 with SMTP id 1so259414fxm.13 for ; Thu, 25 Mar 2010 17:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:subject :to:cc:reply-to:mime-version:x-priority:content-type :content-transfer-encoding; bh=MwlDGG0AR9tZpO7AxDvccjF8LNIlmuZZExyftt4Ap38=; b=EJ2ajc9NFs1qO/On9de8T3ekP1MCX+R3u9Ihb93aW9pyw55lySOJURf6Ex5kxKs5d9 4KrjBqBO1R2Wslq6E7C/0wVxF8ADg6QJt6c2Tx4sqXd1pBuRySPxnf2FcgdUS952WszG NfdEfnln5gQsLILdqcV+fyGoTsy8XqAvgNDDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:subject:to:cc:reply-to:mime-version:x-priority :content-type:content-transfer-encoding; b=ud9LQIfghaV/FJkMQzuUStHyeK7dzQfn7SnlDpR7xKrguLfn3InaWy5hNsXmIJLX/b o5z82g7h0/jPR06lHayfnFmeq1oEJHrBjdR1CtTqJYOtUlmg/0R6e1mhwtrxkQAqSzeU 7QXjkaTD6SbzrmFXM3Dgc5w0I4uk0Ac7MexNc= Received: by 10.223.64.205 with SMTP id f13mr81318fai.98.1269563541077; Thu, 25 Mar 2010 17:32:21 -0700 (PDT) Received: from vienec12mg05 ([213.185.186.253]) by mx.google.com with ESMTPS id 35sm643974fkt.7.2010.03.25.17.32.20 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Mar 2010 17:32:20 -0700 (PDT) Message-ID: <4bac0094.23145e0a.5b97.ffffcb4f@mx.google.com> Date: Fri, 26 Mar 2010 00:32:05 +0000 From: "anandnilkal@gmail.com" To: "bidulock@openss7.org" MIME-Version: 1.0 X-Priority: 3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not haveany RC. X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: anandnilkal@gmail.com List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 00:32:03 -0000 LAS1 serves traffic with RK DPC=3D111,similarly LAS2 serves traffic for= DPC=3D222 and RAS1 serves RK with DPC=3D333. -----Original Message----- From: Brian F. G. Bidulock Sent: 2010-03-26 05:54:41 To: Anand N Ilkal Cc: Jaddu, Suresh (NSN - IN/Bangalore); sigtran@ietf.org Subject: Re: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not = haveany RC. Anand, And what would those DPC values be for each AS? --brian Anand N Ilkal wrote: (Fri, 26 Mar 2010 05:25:5= 7) >=20 > hello Brian, > Yes, even i doubt the scenario. In other do you see any scenario u= nder > which only one ASPAC/ASPAC_ACK are enough to start traffic both en= ds > in Double Exchange mode? > Here RK's are made up of just DPC. And the references are from IPS= P A > node. > LAS1 is Local AS1 with Routing Context 100 (values are fixe= d > from static configuration) > LAS2 is Local AS2 with Routing Context 200 (values are fixe= d > from static configuration) > RAS1 is Remote AS1 with Routing Context 300 (values are fix= ed > from static configuration) > LASP1 is ASP at IPSP A serving LAS1 and LAS2 > RASP1 is ASP at IPSP B serving RAS1. > my question is regarding the following statement in RFC. > Does it says, one ASPAC (without RC) from Peer. and ASPAC_ACK from > local is enough to start traffic from both ends? > Or > It says sender of ASPTM message to activate/deactivate all traffic= , > can send one ASPAC without any RC, And it expecte peer end to send= its > own ASPAC. > - ASPTM messages. When sending ASPTM messages to activate/deactiva= te >=20 > all the traffic independently of routing keys by not specifyi= ng > any >=20 > RC, a single exchange could be sufficient. >=20 > On 26 March 2010 01:03, Brian F. G. Bidulock <[1]bidulock@openss7.= org> > wrote: >=20 > Anand, > Your example does not make any sense to me: you did know that fo= r > DE mode to work, each AS must be defined at either end of the > association and that a separate RK, RS and AS must be defined > for each direction of traffic? > Please provide the real-world RK's for the AS in your example. > --brian > Anand N Ilkal wrote: (Thu, 25 Mar 2010 20:23:47) >=20 --=20 Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Thu Mar 25 23:37:44 2010 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 A3C4F3A6A10 for ; Thu, 25 Mar 2010 23:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 eR4CwApXKYqD for ; Thu, 25 Mar 2010 23:37:43 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 4FC6D3A69FE for ; Thu, 25 Mar 2010 23:37:41 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:8pSX6AWotSdTs62umS4sm5eCQqhdhAgM@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2Q6c0JL005423; Fri, 26 Mar 2010 00:38:01 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:foOd1KWX4H4O6Vt0TrGOBaH9ywlwHhaQ@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2Q6c0SM025442; Fri, 26 Mar 2010 00:38:00 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2Q6c05F025441; Fri, 26 Mar 2010 00:38:00 -0600 Date: Fri, 26 Mar 2010 00:38:00 -0600 From: "Brian F. G. Bidulock" To: "anandnilkal@gmail.com" Message-ID: <20100326063800.GA25014@openss7.org> Mail-Followup-To: "anandnilkal@gmail.com" , "sigtran@ietf.org" References: <4bac0094.23145e0a.5b97.ffffcb4f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4bac0094.23145e0a.5b97.ffffcb4f@mx.google.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] Behaviour in DE-IPSP model when ASPAC does not haveany RC. 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: Fri, 26 Mar 2010 06:37:44 -0000 anandnilkal, You can't do DE this way. RKs must be symmetric. Also, you should not send ASPAC without RC when multiple AS are supported over the same association according to the RFC regardless of operating mode. --brian anandnilkal@gmail.com wrote: (Fri, 26 Mar 2010 00:32:05) > > LAS1 serves traffic with RK DPC=111,similarly LAS2 serves traffic for DPC=222 and RAS1 serves RK with DPC=333. > > -----Original Message----- > From: Brian F. G. Bidulock > Sent: 2010-03-26 05:54:41 > To: Anand N Ilkal > Cc: Jaddu, Suresh (NSN - IN/Bangalore); sigtran@ietf.org > Subject: Re: [Sigtran] Behaviour in DE-IPSP model when ASPAC does not haveany RC. > > Anand, > > And what would those DPC values be for each AS? > > --brian > > Anand N Ilkal wrote: (Fri, 26 Mar 2010 05:25:57) > > > > hello Brian, > > Yes, even i doubt the scenario. In other do you see any scenario under > > which only one ASPAC/ASPAC_ACK are enough to start traffic both ends > > in Double Exchange mode? > > Here RK's are made up of just DPC. And the references are from IPSP A > > node. > > LAS1 is Local AS1 with Routing Context 100 (values are fixed > > from static configuration) > > LAS2 is Local AS2 with Routing Context 200 (values are fixed > > from static configuration) > > RAS1 is Remote AS1 with Routing Context 300 (values are fixed > > from static configuration) > > LASP1 is ASP at IPSP A serving LAS1 and LAS2 > > RASP1 is ASP at IPSP B serving RAS1. > > my question is regarding the following statement in RFC. > > Does it says, one ASPAC (without RC) from Peer. and ASPAC_ACK from > > local is enough to start traffic from both ends? > > Or > > It says sender of ASPTM message to activate/deactivate all traffic, > > can send one ASPAC without any RC, And it expecte peer end to send its > > own ASPAC. > > - ASPTM messages. When sending ASPTM messages to activate/deactivate > > > > all the traffic independently of routing keys by not specifying > > any > > > > RC, a single exchange could be sufficient. > > > > On 26 March 2010 01:03, Brian F. G. Bidulock <[1]bidulock@openss7.org> > > wrote: > > > > Anand, > > Your example does not make any sense to me: you did know that for > > DE mode to work, each AS must be defined at either end of the > > association and that a separate RK, RS and AS must be defined > > for each direction of traffic? > > Please provide the real-world RK's for the AS in your example. > > --brian > > Anand N Ilkal wrote: (Thu, 25 Mar 2010 20:23:47) > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > 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 bendavissigtran@gmail.com Mon Mar 29 05:17:45 2010 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 82FCD3A67DA for ; Mon, 29 Mar 2010 05:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 MM2arrXAO83n for ; Mon, 29 Mar 2010 05:17:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 62D323A6A4A for ; Mon, 29 Mar 2010 05:17:36 -0700 (PDT) Received: by wyb29 with SMTP id 29so4999478wyb.31 for ; Mon, 29 Mar 2010 05:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=E0oiF2DTQVF28mLIw/XygB+gaFH/TqrlHk+g0FrIlUk=; b=jLjbUQTWHA1oGyvHFUnTmgnzM8MZW69x2Dg8N20DigATdpasLexmXHXOclAqhbKILK q5efFuMlUQhRjwHoCyEUCrHf0anGIR56oX0Knq5ahPS/6Sa75qxLQmA+9BtvTDODeMDM cQ2LgOgEyNrZ2XSjqBPMjSDPoZtSL7zcP/7sU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QOsdwA7zXw/a7Caczjx1xWX86N+CGUac83yyrpUp4oFLsuvUj1Qz4cDmA02tecXxeR nnRyVv0UFUOlo+CTyC1n3roekplvUJWld8tj8va/rDapuJWTNq9P7brp0n37bWZ00JWI 56lGFljrwVMxLwkNgeQdDGSX3jk+fw9IBCfz8= MIME-Version: 1.0 Received: by 10.216.13.143 with HTTP; Mon, 29 Mar 2010 05:18:00 -0700 (PDT) Date: Mon, 29 Mar 2010 14:18:00 +0200 Received: by 10.216.172.70 with SMTP id s48mr831708wel.114.1269865080397; Mon, 29 Mar 2010 05:18:00 -0700 (PDT) Message-ID: From: Ben Davis To: sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016e6498360079fc40482ef812c Subject: [Sigtran] M2PA version 7 ? 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, 29 Mar 2010 12:17:45 -0000 --0016e6498360079fc40482ef812c Content-Type: text/plain; charset=ISO-8859-1 Hi experts, One document I recently read mentionned M2PA version 7. RFC 4165 just mentions version 1 as the only version for M2PA. Should I understand that version 7 was a draft number before this RFC became a standard ? Ben --0016e6498360079fc40482ef812c Content-Type: text/html; charset=ISO-8859-1 Hi experts,

One document I recently read mentionned M2PA version 7.
RFC 4165 just mentions version 1 as the only version for M2PA.

Should I understand that version 7 was a draft number before this RFC became a standard ?

Ben
--0016e6498360079fc40482ef812c-- From bidulock@openss7.org Mon Mar 29 05:54:17 2010 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 20E703A68DB for ; Mon, 29 Mar 2010 05:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 ZtZmE193APoA for ; Mon, 29 Mar 2010 05:54:15 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 93B1B3A68AA for ; Mon, 29 Mar 2010 05:54:15 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:9QloHD+Rb49xvAzX+puc6kDZKJ2nmNoB@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o2TCse7r019133; Mon, 29 Mar 2010 06:54:40 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:mO6JtDVd9ALEySuGIFKTElqmL9xr4wwC@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o2TCseOt026156; Mon, 29 Mar 2010 06:54:40 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o2TCseds026155; Mon, 29 Mar 2010 06:54:40 -0600 Date: Mon, 29 Mar 2010 06:54:40 -0600 From: "Brian F. G. Bidulock" To: Ben Davis Message-ID: <20100329125440.GA26023@openss7.org> Mail-Followup-To: Ben Davis , 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] M2PA version 7 ? 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, 29 Mar 2010 12:54:17 -0000 Ben, Yes. Draft 07 was referenced by some standards groups before the RFC was issued. --brian Ben Davis wrote: (Mon, 29 Mar 2010 14:18:00) > > Hi experts, > One document I recently read mentionned M2PA version 7. > RFC 4165 just mentions version 1 as the only version for M2PA. > Should I understand that version 7 was a draft number before this RFC > became a standard ? > Ben > _______________________________________________ > 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 debasri.sarkar@aricent.com Wed Mar 24 23:34:02 2010 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 D44993A6867 for ; Wed, 24 Mar 2010 23:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.848 X-Spam-Level: X-Spam-Status: No, score=0.848 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SARE_SUB_OBFU_Q1=0.227] 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 35+7RNvKel1X for ; Wed, 24 Mar 2010 23:34:01 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id DDF483A67A1 for ; Wed, 24 Mar 2010 23:34:00 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id DF49636B67 for ; Thu, 25 Mar 2010 12:00:36 +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 D335C36B65 for ; Thu, 25 Mar 2010 12:00:36 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Thu, 25 Mar 2010 12:04:18 +0530 From: Debasri Sarkar To: "'sigtran@ietf.org'" Date: Thu, 25 Mar 2010 12:04:17 +0530 Thread-Topic: Qyery related to ASPTM message exchange in IPSP-DE mode Thread-Index: AcrL5TFq0DhUY7pNTBeRYgJ2QmH3bw== 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_DF735188ED91BD458FA0E0C17929339F03E82DF9GUREXMB01ASIANA_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 29 Mar 2010 11:12:14 -0700 Cc: Debasri Sarkar Subject: [Sigtran] Qyery related to ASPTM message exchange in IPSP-DE mode 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, 25 Mar 2010 06:37:39 -0000 --_000_DF735188ED91BD458FA0E0C17929339F03E82DF9GUREXMB01ASIANA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, RFC 4666 mentions about special cases in IPSP DE mode. Following are the excerpts from RFC 4666 section 4.3.1: --------------------------------------- Then the transitions in brackets can be used for the IPSP DE model communication (DE-IPSPs) and are related to the special cases when just one ASP*M messages exchange is needed, as follows: - ASPSM messages. When exchanging ASPSM messages using only a single exchange (only one request and one acknowledgment). . Example: (see section 5.6.2) whenever a DE-IPSP is taking the leading role to start communication to a peer DE-IPSP, it sends ASP Up message to the peer DE-IPSP. The peer MAY consider the initiating DE-IPSPs as being in ASP-INACTIVE state, as it already sent a message, and answer back with ASP Up Ack. Upon the reception of this answer by the initiating DE-IPSP it alsoMAY consider the peer as being in ASP-INACTIVE state since it did respond. Therefore a second ASP Up message exchange to be started by the peer DE-IPSP could be avoided. In this case the reception of ASP Up Ack will turn into a state change. - ASPTM messages. When sending ASPTM messages to activate/deactivate all the traffic independently of routing keys by not specifying any RC, a single exchange could be sufficient. --------------------------------------- The question is 1. Whether the sender of ASPAC message without RC should wait for corresp= onding ASPAC message from peer IPSP. 2. Whether the receiver of ASPAC/ASPAC ACK message should activate all re= mote AS as well as all local AS. Regards, Debasri ________________________________ "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_DF735188ED91BD458FA0E0C17929339F03E82DF9GUREXMB01ASIANA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

<= span style=3D"font-size:10.0pt;font-family:Tahoma;color:#333399">RFC 4666 m= entions about special cases in IPSP DE mode.

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

<= span style=3D"font-size:10.0pt;font-family:Tahoma;color:#333399">Following = are the excerpts from RFC 4666 section 4.3.1:

---------------------------------------

  Then the transitions in brackets can be used for the IPS= P DE model

   communication (DE-IPSPs) and are related to the sp= ecial cases when

   just one ASP*M messages exchange is needed, as fol= lows:

 

   - ASPSM messages. When exchanging ASPSM messages u= sing only a single

     exchange (only one request and one ack= nowledgment). .

     Example: (see section 5.6.2) whenever = a DE-IPSP is taking the

     leading role to start communication to= a peer DE-IPSP, it sends ASP

     Up message to the peer DE-IPSP. The pe= er MAY consider the initiating

     DE-IPSPs as being in ASP-INACTIVE stat= e, as it already sent a

     message, and answer back with ASP Up A= ck. Upon the reception of this

     answer by the initiating DE-IPSP it al= soMAY consider the peer as

     being in ASP-INACTIVE state since it d= id respond. Therefore a second

     ASP Up message exchange to be started = by the peer DE-IPSP could be

     avoided. In this case the reception of= ASP Up Ack will turn into a

     state change.=

 

   - ASPTM messages. When sending ASPTM messages to activate/deactivate

=      all the traffic independently of routing keys = by not specifying any

=      RC, a single exchange could be sufficient.

---------------------------------------

The question is

  1. = Whether the sender of ASPAC messa= ge without RC should wait for corresponding ASPAC message from peer IPSP.
  2. Whether the receiver of ASPAC/ASP= AC ACK message should activate all remote AS as well as all local AS.

 

Regards,

Debasri

 



"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_DF735188ED91BD458FA0E0C17929339F03E82DF9GUREXMB01ASIANA_--