From santhana@huawei.com Wed Aug 5 06:47:42 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18A828C57D for ; Wed, 5 Aug 2009 06:47:42 -0700 (PDT) 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_42=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 o55cThKQbIoD for ; Wed, 5 Aug 2009 06:47:41 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id AA2923A7003 for ; Wed, 5 Aug 2009 06:47:41 -0700 (PDT) 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 <0KNW00EW3OZ7TD@szxga04-in.huawei.com> for sigtran@ietf.org; Wed, 05 Aug 2009 21:47:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNW00FPEOZ7HO@szxga04-in.huawei.com> for sigtran@ietf.org; Wed, 05 Aug 2009 21:47:31 +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 <0KNW007VMOZ5T0@szxml04-in.huawei.com> for sigtran@ietf.org; Wed, 05 Aug 2009 21:47:31 +0800 (CST) Date: Wed, 05 Aug 2009 19:13:18 +0530 From: Santhana In-reply-to: <20090710205123.GA18962@openss7.org> To: bidulock@openss7.org Message-id: <000601ca15d2$b197c6f0$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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoBoDITCbcJh5gATyG4DR04lhYjPQUMdo8g References: <004b01ca0089$e9d6f9e0$2001120a@china.huawei.com> <20090709122954.GB14163@openss7.org> <006701ca0119$2a9ccdd0$2001120a@china.huawei.com> <20090710070013.GA3146@openss7.org> <007801ca0167$bc570800$2001120a@china.huawei.com> <20090710205123.GA18962@openss7.org> Cc: sigtran@ietf.org Subject: Re: [Sigtran] [M3UA] IPSP receiving ASP ACTIVE Ack 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, 05 Aug 2009 13:47:42 -0000 Hi Brian In the INACTIVE state when an IPSP/ASP receives ACTIVE Ack, your suggestion is to send INACTIVE message to the peer(as per the below discussion). In the similar fashion when an IPSP/ASP is in DOWN state, and it receives UP Ack, Which would be the better response. "DOWN message" or "ERROR(Unexpected)". As per the below discussion I understand sending DOWN in this case is better. Please share your opinion on this. Regards Santhanakrishnan -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Saturday, July 11, 2009 2:21 AM To: Santhana Cc: sigtran@ietf.org Subject: Re: [Sigtran] [M3UA] IPSP receiving ASP ACTIVE Ack Santhana, Yes, they are just ok. Sending ERROR "Unexpected message" is certainly not the best response. ASP Inactive is a better response. --brian Santhana wrote: (Fri, 10 Jul 2009 19:37:17) > > Hi Brian > Then for unsolicited "ASP ACTIVE Ack" message are the following > responses ok in SE mode. > > ===================================== > PRESENT STATE ACTION > ===================================== > ACTIVE No Action > INACTIVE Send ERROR "Unexpected" > ===================================== > > Regards > Santhanakrishnan -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Howard.May@dialogic.com Mon Aug 17 02:31:12 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4060728C267 for ; Mon, 17 Aug 2009 02:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVqzrwtedTZb for ; Mon, 17 Aug 2009 02:31:11 -0700 (PDT) Received: from outbound.dialogic.com (outbound.dialogic.com [65.220.90.252]) by core3.amsl.com (Postfix) with ESMTP id 5499F28C26D for ; Mon, 17 Aug 2009 02:31:11 -0700 (PDT) Received: from MBX.dialogic.com ([fe80::bd56:b76c:8d2c:437b]) by pysxht01.dialogic.com ([::1]) with mapi; Mon, 17 Aug 2009 05:31:12 -0400 From: Howard May To: "sigtran@ietf.org" Date: Mon, 17 Aug 2009 05:31:10 -0400 Thread-Topic: M3UA: IPSP SE with different traffic modes Thread-Index: AcofHXTnC7h/1FRfSi2pXxgLXnOhuA== Message-ID: <3256B665A5FD30499BA25BFF2EB77F3F0494807128@MBX.dialogic.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_3256B665A5FD30499BA25BFF2EB77F3F0494807128MBXdialogicco_" MIME-Version: 1.0 Subject: [Sigtran] M3UA: IPSP SE with different traffic modes 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, 17 Aug 2009 09:31:12 -0000 --_000_3256B665A5FD30499BA25BFF2EB77F3F0494807128MBXdialogicco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there provision in the standards for a SE IPSP system with peer systems = using different traffic modes (one side in loadshare and the other broadcas= t for instance). In SE IPSP there seems to be no way for the system receivi= ng an ACTIVE Request to tell the peer what traffic mode it wishes to use. T= he specification says that the ASPTM ACTIVE ACK should reflect the Traffic = Mode that was received in the ASPTM ACTIVE REQ. Must a system use DE to achieve this? Regards --_000_3256B665A5FD30499BA25BFF2EB77F3F0494807128MBXdialogicco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there provision in the standards for a SE IPSP system with peer systems using different traffic modes (one side in loadshare and = the other broadcast for instance). In SE IPSP there seems to be no way for the system receiving an ACTIVE Request to tell the peer what traffic mode it wi= shes to use. The specification says that the ASPTM ACTIVE ACK should reflect the Traffic Mode that was received in the ASPTM ACTIVE REQ. <= /font>

 

Must a system use DE to achieve this?<= /font>

 

Regards

--_000_3256B665A5FD30499BA25BFF2EB77F3F0494807128MBXdialogicco_-- From juan.harrison@bt.com Wed Aug 19 04:05:27 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729B33A6828 for ; Wed, 19 Aug 2009 04:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-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 nUT3t6-X-F9Y for ; Wed, 19 Aug 2009 04:05:26 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D65E93A69C6 for ; Wed, 19 Aug 2009 04:05:22 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:05: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 12:05:17 +0100 Message-ID: <212B88087E52DB4EB870E1580474DF6A0334BCAB@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D draft-hunt-sigtran-iua-rate-message-00: IUA message backward compatibility Thread-Index: AcogvO8bWrQMA/TJSaWMNxQwy4h6kA== From: To: X-OriginalArrivalTime: 19 Aug 2009 11:05:26.0629 (UTC) FILETIME=[F4C9D950:01CA20BC] Subject: [Sigtran] I-D draft-hunt-sigtran-iua-rate-message-00: IUA message backward compatibility 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, 19 Aug 2009 11:05:27 -0000 Hi all, 1. Background 1.1 I-D "IUA Extension for Rate Control Message" draft-hunt-sigtran-iua-rate-message-00 proposes an extension to IUA [RFC4233] to support the use of an Overload Control Agent in the Signalling Gateway. A new IUA message (ASPCAR) and its corresponding acknowledgement message (ASPCAR Ack) are defined along with a new parameter and related procedures. 1.2 This extension is intended to be optional on each side [MGC and SG] of the IUA interface. Therefore, one of the procedural features proposed in the I-D is that when a MGC supports the extension it should be able to discover the corresponding capability of the SG. This allows the MGC to suppress unnecessary subsequent attempts to invoke the I-D procedures and also allows the possibility of the MGC following alternative overload control strategies (which are outside the scope of I-D draft-hunt-sigtran-iua-rate-message-00). A straightforward method to achieve this aim might be based on the new (ASPCAR) message being recognised or not by the SG. 1.3 Unfortunately, the IUA unsupported message type handling procedure defined in RFC4233 (sub-clause 7.2.2) is rather weak. True, it is mandatory for an IUA entity to respond to receipt of an unsupported message type by returning an ERR message with Error Code value "unsupported message type". But, as the Diagnostic Information parameter in the ERR message remains optional, there is no mandatory unambiguous correlation between the ERR "unsupported message type" report and the offending unsupported message. Without such direct correlation the usefulness of the procedure remains limited. 1.4 Furthermore, the content of the Diagnostics Information field in the Diagnostics Information parameter is not unambiguously defined by RFC4233. 2. Questions In the light of the background summarised above, in order to review I-D draft-hunt-sigtran-iua-rate-message-00 (in particular sub-clause 5.1), I would very much appreciate your experience and views on the following questions: 2.1 Is it the case that, if an existing implementation of IUA has to invoke its unsupported message type procedure, it is likely (or not) to include in the ERR message the Diagnostics Information identifying the offending message? 2.2 If Diagnostics Information is included to identify the offending unsupported message, is an existing implementation of IUA likely to: a) provide just the common message header of the offending message? b) provide the full offending message? c) provide any other "information germane to the error condition" in addition to, or in place of, (a) or (b) above? Thank you for you consideration of this matter. Best regards, Juan BT Innovate & Design=20 Tel: +44 (0) 2087262737=20 Mob: +44 (0) 7801321140=20 Email: juan.harrison@bt.com=20 Web: www.bt.com=20 This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20