From santhana@huawei.com Wed Feb 3 21:37: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 D1CE93A683F for ; Wed, 3 Feb 2010 21:37:45 -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 5tqfSLxm8q-K for ; Wed, 3 Feb 2010 21:37:45 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0E0FC3A680A for ; Wed, 3 Feb 2010 21:37:45 -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 <0KXA002FFYC3YG@szxga03-in.huawei.com> for sigtran@ietf.org; Thu, 04 Feb 2010 13:38:27 +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 <0KXA00AM6YC3I3@szxga03-in.huawei.com> for sigtran@ietf.org; Thu, 04 Feb 2010 13:38:27 +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 <0KXA0066RYBZ3H@szxml04-in.huawei.com> for sigtran@ietf.org; Thu, 04 Feb 2010 13:38:27 +0800 (CST) Date: Thu, 04 Feb 2010 10:59:07 +0530 From: Santhana To: sigtran@ietf.org Message-id: <000101caa55a$fbad51c0$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_YcBvaXuZYfi+Zdpb0vdsSQ)" Thread-index: AcqlWvjdwjhB2Dg+Q5CAAZwWmz4BvQ== Subject: [Sigtran] [IUA] SCTP RI missing in IUA FSM 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 Feb 2010 05:37:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_YcBvaXuZYfi+Zdpb0vdsSQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Brian In IUA RFC 3057, it does not describe about processing of SCTP-RI in the IUA FSM. I could see SCTP-RI mentioned in other UAs. Is it some miss in the IUA RFC, or it has some special insight ? Regards Santhanakrishnan --Boundary_(ID_YcBvaXuZYfi+Zdpb0vdsSQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Brian

            In IUA RFC 3057, it does not describe about processing of SCTP-RI in the IUA FSM. I could see SCTP-RI mentioned in other UAs. Is it some miss in the IUA RFC, or it has some special insight ?

 

Regards

Santhanakrishnan

--Boundary_(ID_YcBvaXuZYfi+Zdpb0vdsSQ)-- From santhana@huawei.com Wed Feb 3 22:23: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 B8E673A6CB0 for ; Wed, 3 Feb 2010 22:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_83=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 7ukOPdG8v5G4 for ; Wed, 3 Feb 2010 22:23:05 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 290A63A6CEE for ; Wed, 3 Feb 2010 22:22:58 -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 <0KXB0010C0EQFD@szxga03-in.huawei.com> for sigtran@ietf.org; Thu, 04 Feb 2010 14:23:14 +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 <0KXB00GP60EQUF@szxga03-in.huawei.com> for sigtran@ietf.org; Thu, 04 Feb 2010 14:23:14 +0800 (CST) Received: from BLRNSHTIPL2NC ([10.18.1.32]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXB0088A0EN66@szxml06-in.huawei.com> for sigtran@ietf.org; Thu, 04 Feb 2010 14:23:14 +0800 (CST) Date: Thu, 04 Feb 2010 11:43:56 +0530 From: Santhana To: sigtran@ietf.org Message-id: <000c01caa561$3cf6f9f0$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_Q/oil4eaR6HMLbUBirAr+g)" Thread-index: AcqlYTtA016zqtQBTH68Eaevi9l2DQ== Subject: [Sigtran] [SCCP] Return on Error option in SCCP XUDT 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 Feb 2010 06:23:09 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Q/oil4eaR6HMLbUBirAr+g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Brian In SCCP, for XUDT message, Can "Return on Error" option be set in the Second or Subsequent segments of XUDT as per standard ? Some sections in SCCP standards are confusing. For ex: In section 4.1.1.1.3 Message return Procedure If message return is requested by the SCCP user, then it is an implementation decision that determines which XUDT or LUDT messages have return on error requested. If "Return on Error" set this way in the second or subsequent segments(not set in the First Segment), what should be the behavior ? Should XUDTS be returned in this case ? Regards Santhanakrishnan --Boundary_(ID_Q/oil4eaR6HMLbUBirAr+g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Brian

            In SCCP, for XUDT message,

 

Can “Return on Error” option be set in the Second or Subsequent segments of XUDT as per standard ? Some sections in SCCP standards are confusing.

 

For ex: In section

4.1.1.1.3 Message return Procedure

If message return is requested by the SCCP user, then it is an implementation decision that

determines which XUDT or LUDT messages have return on error requested.

 

If “Return on Error” set this way in the second or subsequent segments(not set in the First Segment), what should be the behavior ? Should XUDTS be returned in this case ?

 

Regards

Santhanakrishnan

 

--Boundary_(ID_Q/oil4eaR6HMLbUBirAr+g)-- From bidulock@openss7.org Thu Feb 4 01:19:54 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 9C8FB3A699F for ; Thu, 4 Feb 2010 01:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 jmsat8YsEgSD for ; Thu, 4 Feb 2010 01:19:53 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id DDFF83A6AB2 for ; Thu, 4 Feb 2010 01:19:52 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:X+niUu6AuVEZ4I0kkx09bjxLLCggcWba@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o149KIBo031075; Thu, 4 Feb 2010 02:20:18 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:ry9nX0QjlIDViHHrQgC1ysbohw4AQO/7@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o149KIRC003570; Thu, 4 Feb 2010 02:20:18 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o149KICm003569; Thu, 4 Feb 2010 02:20:18 -0700 Date: Thu, 4 Feb 2010 02:20:18 -0700 From: "Brian F. G. Bidulock" To: Santhana Message-ID: <20100204092018.GA31582@openss7.org> Mail-Followup-To: Santhana , sigtran@ietf.org References: <000101caa55a$fbad51c0$2001120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000101caa55a$fbad51c0$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: Thu, 04 Feb 2010 09:19:54 -0000 Santhana, RFC 3057 dates back a ways, and IUA was the first SIGTRAN WG product (other than SCTP and the framework docs) to go to RFC. I don't think that SCTP RI missing has any real significance. It is always at the SCTP receiver's discretion to treat SCTP RI as SCTP CI. --brian Santhana wrote: (Thu, 04 Feb 2010 10:59:07) > > Hi Brian > > In IUA RFC 3057, it does not describe about processing of > SCTP-RI in the IUA FSM. I could see SCTP-RI mentioned in other UAs. Is > it some miss in the IUA RFC, or it has some special insight ? > > > Regards > > Santhanakrishnan > _______________________________________________ > 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 Feb 4 02:02: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 6718A3A6D49 for ; Thu, 4 Feb 2010 02:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_83=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 dj5M0isr-31e for ; Thu, 4 Feb 2010 02:02:05 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 33CEA3A6BDE for ; Thu, 4 Feb 2010 02:02:05 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:zrq2X+LJH5tjJt1sy9qoyUiAlZ0UicL2@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o14A2mnK031750; Thu, 4 Feb 2010 03:02:48 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:pTm13eKdRPTQc9uU8WIcBIVKy4wGq5Bv@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o14A2mOX005924; Thu, 4 Feb 2010 03:02:48 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o14A2mUt005923; Thu, 4 Feb 2010 03:02:48 -0700 Date: Thu, 4 Feb 2010 03:02:48 -0700 From: "Brian F. G. Bidulock" To: Santhana Message-ID: <20100204100248.GB31582@openss7.org> Mail-Followup-To: Santhana , sigtran@ietf.org References: <000c01caa561$3cf6f9f0$2001120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01caa561$3cf6f9f0$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] [SCCP] Return on Error option in SCCP XUDT 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 Feb 2010 10:02:06 -0000 Santhana, This is not an SS7 forum; however, that section of Q.714 means what it says: when the user requests return on error and the message is to be segmented into XUDT messages, the implementation can decide which XUDT messages making up the segments can contain return on error. Also, when receiving XUDTS messages that represent returned segments, the implementation must decide how to place those into the user data field of an N-NOTICE indication primitive. The XUDTS or LUDTS messages are being returned to the user that set them in the first place in this case. Therefore, the implementation sending the segmented XUDT messages should expect to receive XUDTS messages only for those messages upon which it set return on error in the first place. Because inter-working between LUDT messages and XUDT messages may require segmentation, and because the next paragraph of 4.1.1.1.3 says that when segmenting an LUDT into an XUDT for inter-working, only the first segment (XUDT) will have the return on error set; the only part of a message that one can expect to receive in this case is the first. So, the LUDT to segmented XUDT inter-working is different and demands that only the first segmented XUDT have return on error set. The most sane way for the implementation to handle the first case, of course, is to set the return on error in each XUDT segment, starting with the first, that represents a sufficient portion of the message so that the SCCP-User can identify it if returned (maybe only the first segment). For TCAP, this off course means the first part of the message (transaction portion and dialogue portion), otherwise the failed transaction cannot be identified. The transaction and dialogue portions of a TCAP message can fit within the first segment depending on the segmentation thresholds set by the implementation as described in Q.714/4.1.1.1. You see, when these standards say "implementation decision" it really means that the specification cannot proscribe one way or the other, or even identify clearly the criteria of the decision. To consider the criteria requires knowledge of the implementation (such as my TCAP example above). "Implementation decision" does not mean "how ever your feel today", but a careful decision based on knowledge of the protocol, its application, and the specific implementation. Hope that helps. --brian Santhana wrote: (Thu, 04 Feb 2010 11:43:56) > > Hi Brian > > In SCCP, for XUDT message, > > > Can "Return on Error" option be set in the Second or Subsequent > segments of XUDT as per standard ? Some sections in SCCP standards are > confusing. > > > For ex: In section > > 4.1.1.1.3 Message return Procedure > > If message return is requested by the SCCP user, then it is an > implementation decision that > > determines which XUDT or LUDT messages have return on error requested. > > > If "Return on Error" set this way in the second or subsequent > segments(not set in the First Segment), what should be the behavior ? > Should XUDTS be returned in this case ? > > > Regards > > Santhanakrishnan > _______________________________________________ > 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 santhana@huawei.com Thu Feb 4 05:38: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 23EA728C1A2 for ; Thu, 4 Feb 2010 05:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.921 X-Spam-Level: * X-Spam-Status: No, score=1.921 tagged_above=-999 required=5 tests=[AWL=-3.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_ESTABLISH=2.492, FRT_ESTABLISH2=2.492, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=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 rJLer7lH7INu for ; Thu, 4 Feb 2010 05:38:30 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B51A63A6B09 for ; Thu, 4 Feb 2010 05:38:24 -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 <0KXB005RIKL0DU@szxga03-in.huawei.com> for sigtran@ietf.org; Thu, 04 Feb 2010 21:39:00 +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 <0KXB001GCKL0Y4@szxga03-in.huawei.com> for sigtran@ietf.org; Thu, 04 Feb 2010 21:39:00 +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 <0KXB00EYOKKZBG@szxml04-in.huawei.com> for sigtran@ietf.org; Thu, 04 Feb 2010 21:39:00 +0800 (CST) Date: Thu, 04 Feb 2010 18:59:43 +0530 From: Santhana In-reply-to: <20100204092018.GA31582@openss7.org> To: bidulock@openss7.org Message-id: <002c01caa59e$1d215520$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: Acqle3qaIhO1X2bnQC+j0wlD8RZsXgAIGhEg References: <000101caa55a$fbad51c0$2001120a@china.huawei.com> <20100204092018.GA31582@openss7.org> 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 List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 13:38:32 -0000 Hi Brian Thanks for ur clarification. In IUA ASP FSM, it is mentioned like this for SCTP-CDI. "SCTP CDI: The local SCTP layer's Communication Down Indication to the Upper Layer Protocol (IUA) on an SG. The local SCTP will send this indication when it detects the loss of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE notification and COMMUNICATION LOST notification from the SCTP." I guess the same applies even for SCTP-RI. Suppose in an IUA SGP-ASP relation, where SGP is working as SCTP Server and ASP as SCTP Client. By the above RFC statements, it implies that the restart can be initiated only by the ASP side by sending INIT(and hence the RI to the Upper Layer Protocol (IUA) on an SG). As per my SCTP understanding, once an association is established, any EndPoint can send INIT to restart the association. Does the above RFC statement prohibit a restart initiation from SGP side by sending INIT in the already establilshed SCTP association. In simple words can an SCTP restart triggered from the SGP side of IUA ? Regards Santhanakrishnan -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Thursday, February 04, 2010 2:50 PM To: Santhana Cc: sigtran@ietf.org Subject: Re: [Sigtran] [IUA] SCTP RI missing in IUA FSM Santhana, RFC 3057 dates back a ways, and IUA was the first SIGTRAN WG product (other than SCTP and the framework docs) to go to RFC. I don't think that SCTP RI missing has any real significance. It is always at the SCTP receiver's discretion to treat SCTP RI as SCTP CI. --brian Santhana wrote: (Thu, 04 Feb 2010 10:59:07) > > Hi Brian > > In IUA RFC 3057, it does not describe about processing of > SCTP-RI in the IUA FSM. I could see SCTP-RI mentioned in other UAs. Is > it some miss in the IUA RFC, or it has some special insight ? > > > Regards > > Santhanakrishnan > _______________________________________________ > 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 santhana@huawei.com Wed Feb 10 20:38:30 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 6EA053A74F9 for ; Wed, 10 Feb 2010 20:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=1.432, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=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 3j5-oI8KR0UX for ; Wed, 10 Feb 2010 20:38:29 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0306E3A7102 for ; Wed, 10 Feb 2010 20:38:29 -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 <0KXN00IJKU9TJ7@szxga03-in.huawei.com> for sigtran@ietf.org; Thu, 11 Feb 2010 12:39:29 +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 <0KXN007OPU9TAD@szxga03-in.huawei.com> for sigtran@ietf.org; Thu, 11 Feb 2010 12:39:29 +0800 (CST) Received: from BLRNSHTIPL2NC ([10.18.1.32]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXN00GHBU9SKR@szxml06-in.huawei.com> for sigtran@ietf.org; Thu, 11 Feb 2010 12:39:28 +0800 (CST) Date: Thu, 11 Feb 2010 10:00:01 +0530 From: Santhana To: sigtran@ietf.org Message-id: <000001caaad2$e0dd3d10$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_TjVHuvDi1/tyhcNFyAjj6g)" Thread-index: Acqq0uA4cQOl5phERzWkdLKREF3QIQ== Subject: [Sigtran] [M3UA] Mgmt Blocking 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, 11 Feb 2010 04:38:30 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TjVHuvDi1/tyhcNFyAjj6g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi When the SGP/IPSP is Blocked by the Management, the RFC 4666 says, the SGP/IPSP should return ERROR(Mgmt Block) on receiving ASP UP/ASP ACTIVE. But does this Mgmt Block, prohibits sending of ASP UP/ASP ACTIVE also. I could work out a scenario in IPSP DE mode, where an IPSP is blocked by the Management in INACTIVE state. Now when it is in INACTIVE state, for any ACTIVE message received, it returns ERROR (Mgmt Block). But locally can it send ASP ACTIVE and becomes ACTIVE in one direction. Is this allowed? How to define Mgmt Block in IPSP DE mode? Regards Santhanakrishnan --Boundary_(ID_TjVHuvDi1/tyhcNFyAjj6g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi

            When the SGP/IPSP is Blocked by the Management, the RFC 4666 says, the SGP/IPSP should return ERROR(Mgmt Block) on receiving ASP UP/ASP ACTIVE.

But does this Mgmt Block, prohibits sending of ASP UP/ASP ACTIVE also.

 

I could work out a scenario in IPSP DE mode, where an IPSP is blocked by the Management in INACTIVE state. Now when it is in INACTIVE state, for any ACTIVE message received, it returns ERROR (Mgmt Block). But locally can it send ASP ACTIVE and becomes ACTIVE in one direction. Is this allowed?

 

How to define Mgmt Block in IPSP DE mode?

 

Regards

Santhanakrishnan

--Boundary_(ID_TjVHuvDi1/tyhcNFyAjj6g)-- From bidulock@openss7.org Wed Feb 10 21:07:26 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 DFFEB28C177 for ; Wed, 10 Feb 2010 21:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_54=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 RyDLgnlI5SJ3 for ; Wed, 10 Feb 2010 21:07:26 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id D67B228C11D for ; Wed, 10 Feb 2010 21:07:25 -0800 (PST) Received: from wilbur.pigworks.openss7.net (IDENT:5wndDl0f1Nej/Yx7SsoEZ1f78WTuFWzn@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id o1B58Qh3001086; Wed, 10 Feb 2010 22:08:26 -0700 Received: from wilbur.pigworks.openss7.net (IDENT:VI4WBaUzzncDxLB3rsA5DoQPaeeb4vrl@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o1B58QSR014524; Wed, 10 Feb 2010 22:08:26 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o1B58Qra014523; Wed, 10 Feb 2010 22:08:26 -0700 Date: Wed, 10 Feb 2010 22:08:26 -0700 From: "Brian F. G. Bidulock" To: Santhana Message-ID: <20100211050826.GA14205@openss7.org> Mail-Followup-To: Santhana , sigtran@ietf.org References: <000001caaad2$e0dd3d10$2001120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001caaad2$e0dd3d10$2001120a@china.huawei.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sigtran@ietf.org Subject: Re: [Sigtran] [M3UA] Mgmt Blocking 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, 11 Feb 2010 05:07:27 -0000 Santhana, Santhana wrote: (Thu, 11 Feb 2010 10:00:01) > > Hi > > When the SGP/IPSP is Blocked by the Management, the RFC > 4666 says, the SGP/IPSP should return ERROR(Mgmt Block) on receiving > ASP UP/ASP ACTIVE. > > But does this Mgmt Block, prohibits sending of ASP UP/ASP ACTIVE also. > > > I could work out a scenario in IPSP DE mode, where an IPSP is blocked > by the Management in INACTIVE state. Now when it is in INACTIVE state, > for any ACTIVE message received, it returns ERROR (Mgmt Block). But > locally can it send ASP ACTIVE and becomes ACTIVE in one direction. Is > this allowed? Yes. And that is one of the deficiencies of DE mode (that unidirectional traffic can result) and one of the reasons why SE mode is recommended. > How to define Mgmt Block in IPSP DE mode? Yes, that is the way it works. If that doesn't make much sense to you, consider using SE mode instead. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/