sending ASP UP in IPSP SE

From suresh.jaddu@nsn.com Mon Nov 15 07:32: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 E22EE3A6B8A for ; Mon, 15 Nov 2010 07:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_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 Vwq9c8zEd3nc for ; Mon, 15 Nov 2010 07:32:27 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E478A3A6CB9 for ; Mon, 15 Nov 2010 07:32:23 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oAFFW3jh013667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Nov 2010 16:33:04 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oAFFHVvx029295 for ; Mon, 15 Nov 2010 16:17:34 +0100 Received: from SGSIEXC017.nsn-intra.net ([10.159.224.99]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Nov 2010 16:17:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB84D7.2D963411" Date: Mon, 15 Nov 2010 23:10:01 +0800 Message-ID: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sending ASP UP in IPSP SE Thread-Index: AcuE1yyS+GSXKB9iRz23vUKs6CSPCg== From: "Jaddu, Suresh (NSN - IN/Bangalore)" To: X-OriginalArrivalTime: 15 Nov 2010 15:17:32.0963 (UTC) FILETIME=[39E9FF30:01CB84D8] Subject: [Sigtran] sending ASP UP in IPSP SE 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, 15 Nov 2010 15:32:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB84D7.2D963411 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, I think this is very old discussion, I have searched through achieves but could not find definitive answer. In IPSP single exchange mode how to dentine that which side sends the ASP UP message during initialization. From the archives and also the RFC it looks like either side can initiate the M3UA messaging but in the absence of any predefined roles or any prior agreement how to know that which side sends the ASP UP. In such situations it is certainly possible that both sides may send the ASP UP if that happens how to handle that, is it a valid case?? (if this is valid case then what is recommended handling). Thanks, SJ. ------_=_NextPart_001_01CB84D7.2D963411 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable sending ASP UP in IPSP SE

Hi All,

I think this is very old discussion, I = have searched through achieves but could not find definitive answer. In = IPSP single exchange mode how to dentine that which side sends the ASP = UP message during initialization. From the archives and also the RFC it = looks like either side can initiate the M3UA messaging but in the = absence of any predefined roles or any prior agreement how to know that = which side sends the ASP UP. In such situations it is certainly = possible that both sides may send the ASP UP if that happens how to = handle that, is it a valid case?? (if this is valid case then what is = recommended handling).

Thanks,
SJ.

------_=_NextPart_001_01CB84D7.2D963411-- From cbenson@adax.com Mon Nov 15 11:09: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 2DFC428C0E9 for ; Mon, 15 Nov 2010 11:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.450, 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 Rx8Kd42IOEqB for ; Mon, 15 Nov 2010 11:09:05 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id D825828C0D8 for ; Mon, 15 Nov 2010 11:09:04 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 9BCCC120A3F; Mon, 15 Nov 2010 11:09:45 -0800 (PST) Received: by adax (Postfix, from userid 243) id E0C988EDE6; Mon, 15 Nov 2010 11:13:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id D88488EDE5; Mon, 15 Nov 2010 11:13:42 -0800 (PST) Date: Mon, 15 Nov 2010 11:13:42 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: "Jaddu, Suresh (NSN - IN/Bangalore)" In-Reply-To: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> Message-ID: References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Sigtran@ietf.org Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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, 15 Nov 2010 19:09:11 -0000 SJ, The short answer is that it doesn't matter much, and all is well if both sides try to come UP around the same time, providing that each receiver of an ASP Up responds with an ASP Up Ack. The state of each IPSP is maintained by the remote (not local) peer M3UA layer. When one IPSP wishes to enter the UP/Inactive state, it issues a ASP Up message, indicating that it is ready for its state to be changed. If the receiver of the ASP Up "agrees", then it responds with ASP Up Ack. In the Single Exchange model, this SINGLE positive exchange carries the same meaning for the state of both sides. The initiator is saying "I want to move to the UP/Inactive state and you can too". The [positive] responder is saying "you are now in the UP/Inactive state, and I am too". So to answer your direct question, if both sides initiate ASP Up messages around the same time, all is well, because the two meanings coincide (both sides want to be UP/Inactive). To be successful, the ASP Up message requires an ASP Up Ack message, so both sides respond to an ASP UP message with an ASP UP Ack, and both sides move to the UP/Inactive state. The same argument applies to ASP Active messages etc. This Single Exchange Model requires that there be one Routing Key which fully specifies traffic in both directions. Chris Benson, Software Engineer, Adax Inc., Berkeley, California, USA. cbenson@adax.com +1 510 548-7047 ext. 189 www.adax.com On Mon, 15 Nov 2010, Jaddu, Suresh (NSN - IN/Bangalore) wrote: >> Date: Mon, 15 Nov 2010 23:10:01 +0800 >> From: "Jaddu, Suresh (NSN - IN/Bangalore)" >> To: >> Subject: [Sigtran] sending ASP UP in IPSP SE >> >> >> Hi All, >> >> I think this is very old discussion, I have searched through achieves >> but could not find definitive answer. In IPSP single exchange mode how >> to dentine that which side sends the ASP UP message during >> initialization. From the archives and also the RFC it looks like either >> side can initiate the M3UA messaging but in the absence of any >> predefined roles or any prior agreement how to know that which side >> sends the ASP UP. In such situations it is certainly possible that both >> sides may send the ASP UP if that happens how to handle that, is it a >> valid case?? (if this is valid case then what is recommended handling). >> >> Thanks, >> SJ. >> From vikramjeet.singh@alcatel-lucent.com Mon Nov 15 23:10: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 152F23A6DB2 for ; Mon, 15 Nov 2010 23:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=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 fvgDURUFo4eI for ; Mon, 15 Nov 2010 23:10:28 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 8A6AE3A6DDA for ; Mon, 15 Nov 2010 23:10:07 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id oAG7Ac8x026245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Nov 2010 01:10:41 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id oAG7AbnC001167 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 16 Nov 2010 12:40:38 +0530 Received: from INBANSXCHMBSB1.in.alcatel-lucent.com ([135.250.12.91]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 16 Nov 2010 12:40:37 +0530 From: "SINGH, VIKRAMJEET (VIKRAMJEET)" To: "Sigtran@ietf.org" Date: Tue, 16 Nov 2010 12:40:35 +0530 Thread-Topic: Does AS marks entire SG congested,when SCON is received on one of two PSPs configured with SG. Thread-Index: AcuE+L4OzVrXt+e7QPOkV/bzjrqpHgAY9uQg Message-ID: References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Subject: [Sigtran] Does AS marks entire SG congested, when SCON is received on one of two PSPs configured with SG. 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 Nov 2010 07:10:30 -0000 Hi All, AS ------------------PSP1-----------<--< 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 E8FDE3A6DBF for ; Tue, 16 Nov 2010 10:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.174 X-Spam-Level: X-Spam-Status: No, score=-1.174 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, 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 E130Hlp-7qjX for ; Tue, 16 Nov 2010 10:52:32 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id 958753A6C33 for ; Tue, 16 Nov 2010 10:52:32 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 84703120A68; Tue, 16 Nov 2010 10:53:16 -0800 (PST) Received: by adax (Postfix, from userid 243) id 319B48EDE6; Tue, 16 Nov 2010 10:57:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 283CA8EDE5; Tue, 16 Nov 2010 10:57:16 -0800 (PST) Date: Tue, 16 Nov 2010 10:57:16 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: "SINGH, VIKRAMJEET (VIKRAMJEET)" In-Reply-To: Message-ID: References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net>

MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Sigtran@ietf.org" Subject: Re: [Sigtran] Does AS marks entire SG congested, when SCON is received on one of two PSPs configured with SG. 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 Nov 2010 18:52:34 -0000 Vikramjeet, I am not familiar with the term "PSP" in this context, so I'll read PSP1 and PSP2 as ASP1 and ASP2. Alternatively they could be SGP1 and SGP2. I am sorry if my assumptions are incorrect. Specific reading of the M3UA RFCs suggests this: Because the [SGP at the] SG has not sent an SCON message to all of the "concerned" ?SPs", it doesn't apply to all of the ?SPs. If the ultimate SS7 destination PCx itself is congested, then the SG [SGPs] should sebd an SCON to all "concerned" ASPs (from all relevant SGPs). >From an SGP perspective, acting on SS7 status, RFC 4666 Section 4.5.1 states in part: In this way, all ASPs configured to send/receive traffic within a particular Network Appearance are informed. If the SGP operates within a single SS7 Network Appearance, then all ASPs are informed. But an SCON message can also be a response to a message in the other direction: perhaps only ASP1 sent such a message (see RFC 4666 Section 3.4.4). I would interpret your scenario to mean that PCx is congested when reached through ?SP1, and should be marked so, but no such congestion is to be inferred for PCx reached through ?SP2. Perhaps the reported "congestion" is at the ?SP1 interface or route to the SS7 network and does not apply to ?SP2. This is just my interpretation. With thanks, Chris Benson. On Tue, 16 Nov 2010, SINGH, VIKRAMJEET (VIKRAMJEET) wrote: >> Date: Tue, 16 Nov 2010 12:40:35 +0530 >> From: "SINGH, VIKRAMJEET (VIKRAMJEET)" >> To: "Sigtran@ietf.org" >> Subject: [Sigtran] Does AS marks entire SG congested, >> when SCON is received on one of two PSPs configured with SG. >> >> >> >> Hi All, >> >> AS ------------------PSP1-----------<--<> ------------------PSP2-------------------------- >> >> >> AS is configured with SG with 2 PSPs configured bwtween them. >> >> In AS M3UA Route configuration :2 PSPs configured with SG with Remote DPC=x. >> >> SCON is sent from SG to AS with affected PC.x on PSP1. >> >> Query: Would SG be marked as congested or PSP2 would be available for traffic? >> >> -Thanks, >> Vikramjeet Singh >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran >> From sunderjs@gmail.com Tue Nov 16 13:11:48 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 843953A677E for ; Tue, 16 Nov 2010 13:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRj1pOusrEvE for ; Tue, 16 Nov 2010 13:11:44 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 46DE23A67AE for ; Tue, 16 Nov 2010 13:11:41 -0800 (PST) Received: by qwf6 with SMTP id 6so160820qwf.31 for ; Tue, 16 Nov 2010 13:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=CC5fP6+coHb09EJl7O4jvCTZ1rQW+v6FWYsdw4rTbRo=; b=HMHc2lbkRJIe9SoxvdZnPXWZ0iy4xXYUod0OM+UHhYfD0Q1Eq3wO6C4IFCG+8eK6d4 NyKIOmQe8ddvufTX8YDNrrW3c7btY/Z3CYBh3tyYrytADrfmshOw12l7ic+BUgv4lGAK Zy1COH1Q2I48uq5teWXjqw9JlahAPDZk2Njnk= 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 :cc:content-type; b=vd6G1dni/oF9p288hgTyMlyX+hNvf2UxGEBMJ3awSEbS1181sLbdIfHuIdSfyEYQJs dbCXh98zJDPgnckr0XdczDy5GLWPZtWtmMIKJtROxdyekkmDQ30ZZUa2R/fzuLugETOx vHidgoO8bJb4aTEsD0brOoTd/QfOjIZd+zfBg= MIME-Version: 1.0 Received: by 10.224.45.130 with SMTP id e2mr6624576qaf.22.1289941945936; Tue, 16 Nov 2010 13:12:25 -0800 (PST) Received: by 10.220.176.74 with HTTP; Tue, 16 Nov 2010 13:12:25 -0800 (PST) In-Reply-To: References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> Date: Tue, 16 Nov 2010 17:12:25 -0400 Message-ID: From: Sunderjeet Singh To: Chris Benson Content-Type: multipart/alternative; boundary=0015175cb5aa77ea450495320357 Cc: Sigtran@ietf.org Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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 Nov 2010 21:11:49 -0000 --0015175cb5aa77ea450495320357 Content-Type: text/plain; charset=ISO-8859-1 As a simplification, can't the role of M3UA client be given to the end that initiated SCTP association ? Since SCTP client behaviour in IPSP communication should be configured anyways, giving the same end M3UA client fn would be pretty straight. So unless there are compelling reasons to keep the ASPUP intiator open for IPSP-SE case, this approach could generate a simpler implementation. Sunderjeet, Tech Mgr Aricent Technologies (Holdings) Ltd On Mon, Nov 15, 2010 at 3:13 PM, Chris Benson wrote: > SJ, > > The short answer is that it doesn't matter much, and all > is well if both sides try to come UP around the same time, > providing that each receiver of an ASP Up responds with > an ASP Up Ack. > > The state of each IPSP is maintained by the remote (not > local) peer M3UA layer. When one IPSP wishes to enter > the UP/Inactive state, it issues a ASP Up message, > indicating that it is ready for its state to be changed. > If the receiver of the ASP Up "agrees", then it responds > with ASP Up Ack. > > In the Single Exchange model, this SINGLE positive exchange > carries the same meaning for the state of both sides. The > initiator is saying "I want to move to the UP/Inactive state > and you can too". The [positive] responder is saying "you are > now in the UP/Inactive state, and I am too". > > So to answer your direct question, if both sides initiate > ASP Up messages around the same time, all is well, because > the two meanings coincide (both sides want to be UP/Inactive). > To be successful, the ASP Up message requires an ASP Up Ack > message, so both sides respond to an ASP UP message with > an ASP UP Ack, and both sides move to the UP/Inactive state. > > The same argument applies to ASP Active messages etc. > > This Single Exchange Model requires that there be one Routing > Key which fully specifies traffic in both directions. > > > > Chris Benson, Software Engineer, > Adax Inc., Berkeley, California, USA. > cbenson@adax.com > +1 510 548-7047 ext. 189 > www.adax.com > > On Mon, 15 Nov 2010, Jaddu, Suresh (NSN - IN/Bangalore) wrote: > > >> Date: Mon, 15 Nov 2010 23:10:01 +0800 > >> From: "Jaddu, Suresh (NSN - IN/Bangalore)" > >> To: > >> Subject: [Sigtran] sending ASP UP in IPSP SE > >> > >> > >> Hi All, > >> > >> I think this is very old discussion, I have searched through achieves > >> but could not find definitive answer. In IPSP single exchange mode how > >> to dentine that which side sends the ASP UP message during > >> initialization. From the archives and also the RFC it looks like either > >> side can initiate the M3UA messaging but in the absence of any > >> predefined roles or any prior agreement how to know that which side > >> sends the ASP UP. In such situations it is certainly possible that > both > >> sides may send the ASP UP if that happens how to handle that, is it a > >> valid case?? (if this is valid case then what is recommended handling). > >> > >> Thanks, > >> SJ. > >> > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > --0015175cb5aa77ea450495320357 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

As a simplification, can't the role of M3UA client be given to the= end that initiated SCTP association ?

Since SCTP client behaviour in IPSP communication should be configured= anyways, giving the same end

M3UA client fn would be pretty straight. So unless there are compellin= g reasons to keep the ASPUP intiator open

for IPSP-SE case, this approach could generate a simpler implementatio= n.

=A0

Sunderjeet, Tech Mgr

Aricent Technologies (Holdings) Ltd

=A0

On Mon, Nov 15, 2010 at 3:13 PM, Chris Benson <cbenson@adax.com> wrote:

SJ,

The short answer is t= hat it doesn't matter much, and all
is well if both sides try to com= e UP around the same time,
providing that each receiver of an ASP Up responds with
an ASP Up Ack.
The state of each IPSP is maintained by the remote (not
local) pee= r M3UA layer. =A0When one IPSP wishes to enter
the UP/Inactive state, it= issues a ASP Up message,
indicating that it is ready for its state to be changed.
If the receiver= of the ASP Up "agrees", then it responds
with ASP Up Ack.
=
In the Single Exchange model, this SINGLE positive exchange
carries = the same meaning for the state of both sides. =A0The
initiator is saying "I want to move to the UP/Inactive state
and yo= u can too". The [positive] responder is saying "you are
now in= the UP/Inactive state, and I am too".

So to answer your direct= question, if both sides initiate
ASP Up messages around the same time, all is well, because
the two meani= ngs coincide (both sides want to be UP/Inactive).
To be successful, the = ASP Up message requires an ASP Up Ack
message, so both sides respond to = an ASP UP message with
an ASP UP Ack, and both sides move to the UP/Inactive state.

The sam= e argument applies to ASP Active messages etc.

This Single Exchange = Model requires that there be one Routing
Key which fully specifies traff= ic in both directions.

Chris Benson, Software Engineer,
Adax Inc., Berkeley, Califo= rnia, USA.
=A0 =A0 cbenson@adax.com
=A0 =A0+1 510 548-7047 ext. 189
=A0 =A0 www.adax.com

On Mon, 15 Nov 2010, Jaddu, Suresh (NSN - IN/Bangalore) wrote:

&= gt;> =A0Date: Mon, 15 Nov 2010 23:10:01 +0800
>> =A0From: "= ;Jaddu, Suresh (NSN - IN/Bangalore)" <suresh.jaddu@nsn.com>
>> =A0To: =A0<Sigtran@ietf.org= >
>> =A0Subject: [Sigtran] sending ASP UP in IPSP SE

>>
>>
>> =A0Hi All,
>>>> =A0I think this is very old discussion, I have searched through = achieves
>> =A0but could not find definitive answer. In IPSP singl= e exchange mode how
>> =A0to dentine that which side sends the ASP UP message during
&= gt;> =A0initialization. From the archives and also the RFC it looks like= either
>> =A0side can initiate the M3UA messaging but in the abse= nce of any
>> =A0predefined roles or any prior agreement how to know that which = side
>> =A0sends the ASP UP. =A0In such situations it is certainly= possible that both
>> =A0sides may send the ASP UP if that happen= s how to handle that, is it a
>> =A0valid case?? (if this is valid case then what is recommended ha= ndling).
>>
>> =A0Thanks,
>> =A0SJ.
>><= br>
_______________________________________________
Sigtran m= ailing list
Sigtran@ietf.org
https://www.ie= tf.org/mailman/listinfo/sigtran

--0015175cb5aa77ea450495320357-- From cbenson@adax.com Tue Nov 16 13:33: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 E73E73A67E7 for ; Tue, 16 Nov 2010 13:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.350, 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 wAG8eS-HgtFT for ; Tue, 16 Nov 2010 13:33:42 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id A6D0B3A67E5 for ; Tue, 16 Nov 2010 13:33:42 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 19109120A2D; Tue, 16 Nov 2010 13:34:27 -0800 (PST) Received: by adax (Postfix, from userid 243) id 0528A8EDE6; Tue, 16 Nov 2010 13:38:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 00E038EDE5; Tue, 16 Nov 2010 13:38:26 -0800 (PST) Date: Tue, 16 Nov 2010 13:38:26 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Sunderjeet Singh In-Reply-To: Message-ID: References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net>

Date: Wed, 17 Nov 2010 11:20:54 -0400 Message-ID: From: Sunderjeet Singh To: Chris Benson Content-Type: multipart/alternative; boundary=20cf300faedd2448fd04954138a9 Cc: Sigtran@ietf.org Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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, 17 Nov 2010 15:20:16 -0000 --20cf300faedd2448fd04954138a9 Content-Type: text/plain; charset=ISO-8859-1 Chris, Management lockout of server and client retrying of server connectivity are typical of any client-server communication. It is always the client which is expected to initiate a connection by virtue of its role. Lockouts are special cases and there are ways to deal with it. I see little value in keeping the SE ASP*M message exchanges open which otherwise could be easily fixed. regards Sunderjeet On Tue, Nov 16, 2010 at 5:38 PM, Chris Benson wrote: > Sunderjeet, > > One might consider a case where one side is ready, but the > other side is not. There is the notion of Management Lockout > in M3UA (fourth paragraph of RFC 4666 Section 4.3.4.1). > > In this case it might be the "server" who was not initially > ready, and did not respond to the client's ASP Up with an > ASP Up Ack. Later, when this "server" becomes ready, it can > initiate and indicate state change by sending its own ASP Up > message. > > Either side can initiate this and similar state changes at > any time, e.g. in response to local management actions. > Your suggested simplification would lose such a capability. > > With best regards, from Chris Benson. > > On Tue, 16 Nov 2010, Sunderjeet Singh wrote: > > >> Date: Tue, 16 Nov 2010 17:12:25 -0400 > >> From: Sunderjeet Singh > >> To: Chris Benson > >> Cc: "Jaddu, Suresh (NSN - IN/Bangalore)" , > >> > >> Subject: Re: [Sigtran] sending ASP UP in IPSP SE > >> > >> As a simplification, can't the role of M3UA client be given to the end > that > >> initiated SCTP association ? > >> Since SCTP client behaviour in IPSP communication should be configured > >> anyways, giving the same end > >> M3UA client fn would be pretty straight. So unless there are compelling > >> reasons to keep the ASPUP intiator open > >> for IPSP-SE case, this approach could generate a simpler > implementation. > >> > >> > >> Sunderjeet, Tech Mgr > >> Aricent Technologies (Holdings) Ltd > >> > >> > >> On Mon, Nov 15, 2010 at 3:13 PM, Chris Benson > wrote: > >> > >> > SJ, > >> > > >> > The short answer is that it doesn't matter much, and all > >> > is well if both sides try to come UP around the same time, > >> > providing that each receiver of an ASP Up responds with > >> > an ASP Up Ack. > >> > > >> > The state of each IPSP is maintained by the remote (not > >> > local) peer M3UA layer. When one IPSP wishes to enter > >> > the UP/Inactive state, it issues a ASP Up message, > >> > indicating that it is ready for its state to be changed. > >> > If the receiver of the ASP Up "agrees", then it responds > >> > with ASP Up Ack. > >> > > >> > In the Single Exchange model, this SINGLE positive exchange > >> > carries the same meaning for the state of both sides. The > >> > initiator is saying "I want to move to the UP/Inactive state > >> > and you can too". The [positive] responder is saying "you are > >> > now in the UP/Inactive state, and I am too". > >> > > >> > So to answer your direct question, if both sides initiate > >> > ASP Up messages around the same time, all is well, because > >> > the two meanings coincide (both sides want to be UP/Inactive). > >> > To be successful, the ASP Up message requires an ASP Up Ack > >> > message, so both sides respond to an ASP UP message with > >> > an ASP UP Ack, and both sides move to the UP/Inactive state. > >> > > >> > The same argument applies to ASP Active messages etc. > >> > > >> > This Single Exchange Model requires that there be one Routing > >> > Key which fully specifies traffic in both directions. > >> > > >> > > >> > > >> > Chris Benson, Software Engineer, > >> > Adax Inc., Berkeley, California, USA. > >> > cbenson@adax.com > >> > +1 510 548-7047 ext. 189 > >> > www.adax.com > >> > > >> > On Mon, 15 Nov 2010, Jaddu, Suresh (NSN - IN/Bangalore) wrote: > >> > > >> > >> Date: Mon, 15 Nov 2010 23:10:01 +0800 > >> > >> From: "Jaddu, Suresh (NSN - IN/Bangalore)" > > >> > >> To: > >> > >> Subject: [Sigtran] sending ASP UP in IPSP SE > >> > >> > >> > >> > >> > >> Hi All, > >> > >> > >> > >> I think this is very old discussion, I have searched through > achieves > >> > >> but could not find definitive answer. In IPSP single exchange > mode how > >> > >> to dentine that which side sends the ASP UP message during > >> > >> initialization. From the archives and also the RFC it looks like > either > >> > >> side can initiate the M3UA messaging but in the absence of any > >> > >> predefined roles or any prior agreement how to know that which > side > >> > >> sends the ASP UP. In such situations it is certainly possible > that > >> > both > >> > >> sides may send the ASP UP if that happens how to handle that, is > it a > >> > >> valid case?? (if this is valid case then what is recommended > handling). > >> > >> > >> > >> Thanks, > >> > >> SJ. > >> > >> > >> > _______________________________________________ > >> > Sigtran mailing list > >> > Sigtran@ietf.org > >> > https://www.ietf.org/mailman/listinfo/sigtran > >> > > >> > --20cf300faedd2448fd04954138a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Chris,

=A0

Management lockout of server and client retrying of server connectivit= y are typical

of any client-server communication. It is always the client which is e= xpected to initiate

a connection by virtue of its role. Lockouts are special cases and the= re are ways to deal

with it.

=A0

I see little value in keeping the SE ASP*M message exchanges open whic= h otherwise could

be easily fixed.

=A0

regards

Sunderjeet

On Tue, Nov 16, 2010 at 5:38 PM, Chris Benson <cbenson@adax.com> wrote:

Sunderjeet,

One might con= sider a case where one side is ready, but the
other side is not. =A0Ther= e is the notion of Management Lockout
in M3UA (fourth paragraph of RFC 4666 Section 4.3.4.1).

In this case= it might be the "server" who was not initially
ready, and did= not respond to the client's ASP Up with an
ASP Up Ack. =A0Later, wh= en this "server" becomes ready, it can
initiate and indicate state change by sending its own ASP Up
message.
Either side can initiate this and similar state changes at
any time= , e.g. in response to local management actions.
Your suggested simplific= ation would lose such a capability.

With best regards, from Chris Benson.

On Tue, 16 Nov 2010, Sunde= rjeet Singh wrote:

>> =A0Date: Tue, 16 Nov 2010 17:12:25 -0400=
>> =A0From: Sunderjeet Singh <sunderjs@gmail.com>
>> =A0To: Chris Benson <cbenso= n@adax.com>
>> =A0Cc: "Jaddu, Suresh (NSN - IN/Bangalo= re)" <suresh.jaddu@nsn.com<= /a>>,
>> =A0 =A0 =A0<Sigtran@ietf.or= g>
>> =A0Subject: Re: [Sigtran] sending ASP UP in IPSP SE

>>
>> =A0As a simplification, can't th= e role of M3UA client be given to the end that
>> =A0initiated SCT= P association ?
>> =A0Since SCTP client behaviour in IPSP communic= ation should be configured
>> =A0anyways, giving the same end
>> =A0M3UA client fn woul= d be pretty straight. So unless there are compelling
>> =A0reasons= to keep the ASPUP intiator open
>> =A0for IPSP-SE case, this appr= oach could generate a simpler implementation.
>>
>>
>> =A0Sunderjeet, Tech Mgr
>> =A0Ari= cent Technologies (Holdings) Ltd
>>
>>
>> =A0On = Mon, Nov 15, 2010 at 3:13 PM, Chris Benson <cbenson@adax.com> wrote:
>>
>> =A0> SJ,
>> =A0>
>> =A0> Th= e short answer is that it doesn't matter much, and all
>> =A0&= gt; is well if both sides try to come UP around the same time,
>> = =A0> providing that each receiver of an ASP Up responds with
>> =A0> an ASP Up Ack.
>> =A0>
>> =A0> The= state of each IPSP is maintained by the remote (not
>> =A0> lo= cal) peer M3UA layer. =A0When one IPSP wishes to enter
>> =A0> = the UP/Inactive state, it issues a ASP Up message,
>> =A0> indicating that it is ready for its state to be changed.>> =A0> If the receiver of the ASP Up "agrees", then i= t responds
>> =A0> with ASP Up Ack.
>> =A0>
>= > =A0> In the Single Exchange model, this SINGLE positive exchange >> =A0> carries the same meaning for the state of both sides. =A0T= he
>> =A0> initiator is saying "I want to move to the UP/I= nactive state
>> =A0> and you can too". The [positive] res= ponder is saying "you are
>> =A0> now in the UP/Inactive state, and I am too".
>&= gt; =A0>
>> =A0> So to answer your direct question, if both = sides initiate
>> =A0> ASP Up messages around the same time, al= l is well, because
>> =A0> the two meanings coincide (both sides want to be UP/Inacti= ve).
>> =A0> To be successful, the ASP Up message requires an A= SP Up Ack
>> =A0> message, so both sides respond to an ASP UP m= essage with
>> =A0> an ASP UP Ack, and both sides move to the UP/Inactive stat= e.
>> =A0>
>> =A0> The same argument applies to ASP= Active messages etc.
>> =A0>
>> =A0> This Single E= xchange Model requires that there be one Routing
>> =A0> Key which fully specifies traffic in both directions.
&= gt;> =A0>
>> =A0>
>> =A0>
>> =A0>= Chris Benson, Software Engineer,
>> =A0> Adax Inc., Berkeley, = California, USA.
>> =A0> =A0 =A0cbenson@adax.co= m
>> =A0> =A0 =A0+1 510 548-7047 ext. 189
>> =A0&g= t; =A0 =A0www.adax.com
>> =A0>
>> =A0> On Mon, 15 Nov 2010, Jaddu, Suresh (NSN - IN/Bangalore) wr= ote:
>> =A0>
>> =A0> >> =A0Date: Mon, 15 Nov = 2010 23:10:01 +0800
>> =A0> >> =A0From: "Jaddu, Sure= sh (NSN - IN/Bangalore)" <s= uresh.jaddu@nsn.com>
>> =A0> >> =A0To: =A0<Sigtran@ietf.org>
>> =A0> >> =A0Subject: [Sigtran= ] sending ASP UP in IPSP SE
>> =A0> =A0>>
>> =A0= > >>
>> =A0> >> =A0Hi All,
>> =A0> >>
>&g= t; =A0> >> =A0I think this is very old discussion, I have searched= through achieves
>> =A0> >> =A0but could not find defini= tive answer. In IPSP single exchange mode how
>> =A0> >> =A0to dentine that which side sends the ASP UP me= ssage during
>> =A0> >> =A0initialization. From the archi= ves and also the RFC it looks like either
>> =A0> >> =A0s= ide can initiate the M3UA messaging but in the absence of any
>> =A0> >> =A0predefined roles or any prior agreement how to= know that which side
>> =A0> >> =A0sends the ASP UP. =A0= In such situations it is certainly possible that
>> =A0> both>> =A0> >> =A0sides may send the ASP UP if that happens ho= w to handle that, is it a
>> =A0> >> =A0valid case?? (if this is valid case then what = is recommended handling).
>> =A0> >>
>> =A0> = >> =A0Thanks,
>> =A0> >> =A0SJ.
>> =A0>= >>
>> =A0> _______________________________________________
>>= ; =A0> Sigtran mailing list
>> =A0> Sigtran@ietf.org
>> =A0> https://www.ietf.org/= mailman/listinfo/sigtran
>> =A0>
>>

--20cf300faedd2448fd04954138a9-- From cbenson@adax.com Fri Nov 19 10:58: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 AACA128C0FF for ; Fri, 19 Nov 2010 10:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, 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 8rzgzVClVvrA for ; Fri, 19 Nov 2010 10:58:29 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id 0D52D3A67FF for ; Fri, 19 Nov 2010 10:58:29 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id EBBDD120A1D; Fri, 19 Nov 2010 10:59:18 -0800 (PST) Received: by adax (Postfix, from userid 243) id E574F8EDF4; Fri, 19 Nov 2010 11:03:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id D79658EDF3; Fri, 19 Nov 2010 11:03:25 -0800 (PST) Date: Fri, 19 Nov 2010 11:03:25 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Sunderjeet Singh In-Reply-To: Message-ID: References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net>

MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Sigtran@ietf.org Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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 Nov 2010 18:58:30 -0000 Sunderjeet, Perhaps I should phrase my response differently: Regardless of possible merits of your suggestion, M3UA is a well established protocol (RFC since 2002), and my description is how it *is* implemented and MUST be implemented for interoperability. Even the client and server roles (which apply to initiating and responding connections, not the negotiation of UP/Active states) have been relegated to a lesser consideration in M3UA ASP/SGP mode, with either side permitted to establish connections. After that (as described in RFC 4666 Section 5.6.1), there is no client/server distinction between the IPSP peers. Without evaluating your suggestion, it should be noted that "hundreds" of M3UA implementations follow the RFCs, with either side initiating IPSP SE ASP*M state change procedures. I was trying to suggest a rationale for the decision that was already made in this regard long ago (in SIGTRAN years). Regardless of rationale, the protocol is already implemented whereby either side MAY initiate state change procedures. My personal view is that this doesn't cause any significant problem in the area you describe, and will not be changed. RFC 4666 Section 1.6.3 describes that the M3UA management layer may issue an M-ASP_UP request (etc.) to the local ASP [meaning ASP or IPSP]. This doesn't consider which side initiated the connection. Please consider my response a statement of how M3UA is implemented, rather than an evaluation of your suggestion. Best regards, from Chris Benson. On Wed, 17 Nov 2010, Sunderjeet Singh wrote: >> Date: Wed, 17 Nov 2010 11:20:54 -0400 >> From: Sunderjeet Singh >> To: Chris Benson >> Cc: >> Subject: Re: [Sigtran] sending ASP UP in IPSP SE >> >> Chris, >> >> Management lockout of server and client retrying of server connectivity are >> typical >> of any client-server communication. It is always the client which is >> expected to initiate >> a connection by virtue of its role. Lockouts are special cases and there are >> ways to deal >> with it. >> >> I see little value in keeping the SE ASP*M message exchanges open which >> otherwise could >> be easily fixed. >> >> regards >> Sunderjeet >> >> On Tue, Nov 16, 2010 at 5:38 PM, Chris Benson wrote: >> >> > Sunderjeet, >> > >> > One might consider a case where one side is ready, but the >> > other side is not. There is the notion of Management Lockout >> > in M3UA (fourth paragraph of RFC 4666 Section 4.3.4.1). >> > >> > In this case it might be the "server" who was not initially >> > ready, and did not respond to the client's ASP Up with an >> > ASP Up Ack. Later, when this "server" becomes ready, it can >> > initiate and indicate state change by sending its own ASP Up >> > message. >> > >> > Either side can initiate this and similar state changes at >> > any time, e.g. in response to local management actions. >> > Your suggested simplification would lose such a capability. >> > >> > With best regards, from Chris Benson. >> > >> > On Tue, 16 Nov 2010, Sunderjeet Singh wrote: >> > >> > >> Date: Tue, 16 Nov 2010 17:12:25 -0400 >> > >> From: Sunderjeet Singh >> > >> To: Chris Benson >> > >> Cc: "Jaddu, Suresh (NSN - IN/Bangalore)" , >> > >> >> > >> Subject: Re: [Sigtran] sending ASP UP in IPSP SE >> > >> >> > >> As a simplification, can't the role of M3UA client be given to the end >> > that >> > >> initiated SCTP association ? >> > >> Since SCTP client behaviour in IPSP communication should be configured >> > >> anyways, giving the same end >> > >> M3UA client fn would be pretty straight. So unless there are compelling >> > >> reasons to keep the ASPUP intiator open >> > >> for IPSP-SE case, this approach could generate a simpler >> > implementation. >> > >> >> > >> >> > >> Sunderjeet, Tech Mgr >> > >> Aricent Technologies (Holdings) Ltd >> > >> >> > >> >> > >> On Mon, Nov 15, 2010 at 3:13 PM, Chris Benson >> > wrote: >> > >> >> > >> > SJ, >> > >> > >> > >> > The short answer is that it doesn't matter much, and all >> > >> > is well if both sides try to come UP around the same time, >> > >> > providing that each receiver of an ASP Up responds with >> > >> > an ASP Up Ack. >> > >> > >> > >> > The state of each IPSP is maintained by the remote (not >> > >> > local) peer M3UA layer. When one IPSP wishes to enter >> > >> > the UP/Inactive state, it issues a ASP Up message, >> > >> > indicating that it is ready for its state to be changed. >> > >> > If the receiver of the ASP Up "agrees", then it responds >> > >> > with ASP Up Ack. >> > >> > >> > >> > In the Single Exchange model, this SINGLE positive exchange >> > >> > carries the same meaning for the state of both sides. The >> > >> > initiator is saying "I want to move to the UP/Inactive state >> > >> > and you can too". The [positive] responder is saying "you are >> > >> > now in the UP/Inactive state, and I am too". >> > >> > >> > >> > So to answer your direct question, if both sides initiate >> > >> > ASP Up messages around the same time, all is well, because >> > >> > the two meanings coincide (both sides want to be UP/Inactive). >> > >> > To be successful, the ASP Up message requires an ASP Up Ack >> > >> > message, so both sides respond to an ASP UP message with >> > >> > an ASP UP Ack, and both sides move to the UP/Inactive state. >> > >> > >> > >> > The same argument applies to ASP Active messages etc. >> > >> > >> > >> > This Single Exchange Model requires that there be one Routing >> > >> > Key which fully specifies traffic in both directions. >> > >> > >> > >> > >> > >> > >> > >> > Chris Benson, Software Engineer, >> > >> > Adax Inc., Berkeley, California, USA. >> > >> > cbenson@adax.com >> > >> > +1 510 548-7047 ext. 189 >> > >> > www.adax.com >> > >> > >> > >> > On Mon, 15 Nov 2010, Jaddu, Suresh (NSN - IN/Bangalore) wrote: >> > >> > >> > >> > >> Date: Mon, 15 Nov 2010 23:10:01 +0800 >> > >> > >> From: "Jaddu, Suresh (NSN - IN/Bangalore)" > > > >> > >> > >> To: >> > >> > >> Subject: [Sigtran] sending ASP UP in IPSP SE >> > >> > >> >> > >> > >> >> > >> > >> Hi All, >> > >> > >> >> > >> > >> I think this is very old discussion, I have searched through >> > achieves >> > >> > >> but could not find definitive answer. In IPSP single exchange >> > mode how >> > >> > >> to dentine that which side sends the ASP UP message during >> > >> > >> initialization. From the archives and also the RFC it looks like >> > either >> > >> > >> side can initiate the M3UA messaging but in the absence of any >> > >> > >> predefined roles or any prior agreement how to know that which >> > side >> > >> > >> sends the ASP UP. In such situations it is certainly possible >> > that >> > >> > both >> > >> > >> sides may send the ASP UP if that happens how to handle that, is >> > it a >> > >> > >> valid case?? (if this is valid case then what is recommended >> > handling). >> > >> > >> >> > >> > >> Thanks, >> > >> > >> SJ. >> > >> > >> >> > >> > _______________________________________________ >> > >> > Sigtran mailing list >> > >> > Sigtran@ietf.org >> > >> > https://www.ietf.org/mailman/listinfo/sigtran >> > >> > >> > >> >> > >> From evgenij.fokin@gmail.com Sat Nov 20 10:04: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 D93ED3A688A for ; Sat, 20 Nov 2010 10:04:14 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 3tnIBa+vldO2 for ; Sat, 20 Nov 2010 10:04:13 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 3479C3A69FE for ; Sat, 20 Nov 2010 10:04:13 -0800 (PST) Received: by eyd10 with SMTP id 10so3380706eyd.31 for ; Sat, 20 Nov 2010 10:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id :disposition-notification-to:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eNsBzJWIhUgH0neeaaRg7+K6r3gSTHKFaCdO8t44AxA=; b=Lx++fKaiJsU2q2lxGApD+b/khDc4EjpNuAuEoNSU/fzEjkcFzJOlVluK91Y2G21ae3 Y/E9xlzbL8p2CoPbhbNXLybECVLTbrhGTlM2yx+M2SA7MTAMrhZZHo7bPaFIjPZwl791 9fe8GyOIz3RPM6UPGVBE+CFB6GHzdJmfpSDN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; b=DFRXjYQEg6acnk/WSUBk8oU0ihaHISmYYPZ45Z3nLsS4AGtYa0QqPliKkXDGCrUYyn Y7J7q4q/agafpjck4tn1sxnYkZzR0pvbYgoYRyfRa7fD7MMplM7oFyBCPBxXG0eww+NT BAiUMzh/s+B6bmqFFW239lQU7mMNFwe4je26k= Received: by 10.14.119.129 with SMTP id n1mr1743151eeh.13.1290276302539; Sat, 20 Nov 2010 10:05:02 -0800 (PST) Received: from [95.79.8.229] ([95.79.8.229]) by mx.google.com with ESMTPS id v56sm2779443eeh.20.2010.11.20.10.05.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Nov 2010 10:05:01 -0800 (PST) Message-ID: <4CE80DC0.90803@gmail.com> Date: Sat, 20 Nov 2010 21:04:48 +0300 From: =?UTF-8?B?0JXQstCz0LXQvdC40Lkg0KTQvtC60LjQvQ==?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: sigtran@ietf.org References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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 Nov 2010 18:04:15 -0000 15.11.2010 22:13, Chris Benson wrote: > This Single Exchange Model requires that there be one Routing > Key which fully specifies traffic in both directions. > Chris, does it mean that in Single Exchange Model requires only one Routing Key? Is it correct if in Single Exchange Model are two or more Routing Keys which fully specifies traffic in both directions? -- Regards Evgenij From bidulock@openss7.org Sat Nov 20 14:01:25 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 CE78828C11B for ; Sat, 20 Nov 2010 14:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3jwM2AMX4tO for ; Sat, 20 Nov 2010 14:01:24 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id AD99628C120 for ; Sat, 20 Nov 2010 14:01:24 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oAKM2Fq4028154; Sat, 20 Nov 2010 15:02:15 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oAKM2FZB027110; Sat, 20 Nov 2010 15:02:15 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id oAKM2EQc027109; Sat, 20 Nov 2010 15:02:14 -0700 Date: Sat, 20 Nov 2010 15:02:14 -0700 From: "Brian F. G. Bidulock" To: ?????????????? ?????????? Message-ID: <20101120220214.GA26962@openss7.org> Mail-Followup-To: ?????????????? ?????????? , sigtran@ietf.org References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> <4CE80DC0.90803@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE80DC0.90803@gmail.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sigtran@ietf.org Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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 Nov 2010 22:01:25 -0000 ??????????????, ?????????????? ?????????? wrote: (Sat, 20 Nov 2010 21:04:48) > > 15.11.2010 22:13, Chris Benson wrote: >> This Single Exchange Model requires that there be one Routing >> Key which fully specifies traffic in both directions. >> > Chris, does it mean that in Single Exchange Model requires only one > Routing Key? > Is it correct if in Single Exchange Model are two or more Routing Keys > which fully specifies traffic in both directions? SE specifies both directions of traffic with one AS/RC/RK. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From ilie.glib@googlemail.com Mon Nov 22 04:56: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 14EDC28C0DD for ; Mon, 22 Nov 2010 04:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.438 X-Spam-Level: X-Spam-Status: No, score=0.438 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 oJoYlhrm+MvC for ; Mon, 22 Nov 2010 04:56:19 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id E3F373A6A4A for ; Mon, 22 Nov 2010 04:56:18 -0800 (PST) Received: by gxk27 with SMTP id 27so4387708gxk.31 for ; Mon, 22 Nov 2010 04:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=j+refi805yc3YJQki24l+RAKv5SG5Lm1I0Oy+tYvciM=; b=E2oRBcKaf4ZzfcEMRxaTXn54Be7j2hKxd89c7DfCRqEd1AY/TXGUSFbxC4KD2/4EPb E0ysOeGsxB42HJV1/lQdRILZbKpn7oa9tDB2n1IvmN1+F79XjZHzmf7WcGtyNqazv5Lb wdE0SxEkQymSp4xaIvzWtU5irlhRjeoc0nkTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Y9slXaKKKM8srvQqQXmqqMLQJJJp/kp4LvA/bYaPLz8D+IsBTeYADu6jz9YUYULM7M l7VOPk7MC0uqHqpQIOyhLDXpWE0mUFBYDSkmtRT9I2INFWRRhV3PkfWor4dYS8W8LjA+ 1d0zVJ5GBk3vPzgycNwKWziAlfBoNgz7pYSG4= MIME-Version: 1.0 Received: by 10.100.5.13 with SMTP id 13mr4036042ane.57.1290430632558; Mon, 22 Nov 2010 04:57:12 -0800 (PST) Received: by 10.100.153.15 with HTTP; Mon, 22 Nov 2010 04:57:12 -0800 (PST) In-Reply-To: <20101120220214.GA26962@openss7.org> References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> <4CE80DC0.90803@gmail.com> <20101120220214.GA26962@openss7.org> Date: Mon, 22 Nov 2010 13:57:12 +0100 Message-ID: From: Ilie Glib To: bidulock@openss7.org, "?????????????? ??????????" , sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016e644de7e75ffa10495a3cbd8 Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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 Nov 2010 12:56:20 -0000 --0016e644de7e75ffa10495a3cbd8 Content-Type: text/plain; charset=ISO-8859-1 Hello All, we had this discussion ages ago, and as far as I remember our conclusion was that in the SE IPSP to IPSP scenario one has two ASes - one on each side. They have symmetric RKs and a same value of the RC. BR //Ilie On Sat, Nov 20, 2010 at 11:02 PM, Brian F. G. Bidulock wrote: > ??????????????, > > ?????????????? ?????????? wrote: (Sat, 20 Nov > 2010 21:04:48) > > > > 15.11.2010 22:13, Chris Benson wrote: > >> This Single Exchange Model requires that there be one Routing > >> Key which fully specifies traffic in both directions. > >> > > Chris, does it mean that in Single Exchange Model requires only one > > Routing Key? > > Is it correct if in Single Exchange Model are two or more Routing Keys > > which fully specifies traffic in both directions? > > SE specifies both directions of traffic with one AS/RC/RK. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > -- Ilie --0016e644de7e75ffa10495a3cbd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello All,

=A0

we had this discussion ages ago, and as far as I remember our conclusi= on was that in the SE IPSP to IPSP scenario one has two ASes - one on each = side. They have symmetric RKs and a same value of the RC.

=A0

BR //Ilie

On Sat, Nov 20, 2010 at 11:02 PM, Brian F. G. Bi= dulock <bidulo= ck@openss7.org> wrote:

??????????????,

?????????= ????? ?????????? wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0(Sat, 20 Nov 2010 21:04:48)

>
> 15.11.2010 22:13, Chris Benson wrote:
>= ;> This Single Exchange Model requires that there be one Routing
>= > Key which fully specifies traffic in both directions.
>>
> Chris, does it mean that in Single Exchange Model requires only one> Routing Key?
> Is it correct if in Single Exchange Model are tw= o or more Routing Keys
> which fully specifies traffic in both direct= ions?

SE specifies both directions of traffic with one AS/RC/RK.
--brian

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

_______________________________________________
Sigtra= n mailing list
Sigtran@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sigtran

--
Ilie
--0016e644de7e75ffa10495a3cbd8-- From bidulock@openss7.org Mon Nov 22 07:02: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 3AC2428C0CE for ; Mon, 22 Nov 2010 07:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfK1+wNqdYzf for ; Mon, 22 Nov 2010 07:02:44 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 688E428C0E8 for ; Mon, 22 Nov 2010 07:02:44 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oAMF3aWG005791; Mon, 22 Nov 2010 08:03:37 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oAMF3a9m032018; Mon, 22 Nov 2010 08:03:36 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id oAMF3aQx032017; Mon, 22 Nov 2010 08:03:36 -0700 Date: Mon, 22 Nov 2010 08:03:36 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Message-ID: <20101122150336.GA31624@openss7.org> Mail-Followup-To: Ilie Glib , ?????????????? ?????????? , sigtran@ietf.org References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> <4CE80DC0.90803@gmail.com> <20101120220214.GA26962@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.18 (2008-05-17) Cc: sigtran@ietf.org Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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 Nov 2010 15:02:46 -0000 Ilie, Ilie Glib wrote: (Mon, 22 Nov 2010 13:57:12) > > we had this discussion ages ago, and as far as I remember our > conclusion was that in the SE IPSP to IPSP scenario one has two ASes - > one on each side. They have symmetric RKs and a same value of the RC. No. One AS, one RC, one RK, describing both directions of traffic. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From ilie.glib@googlemail.com Tue Nov 23 01:49: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 E0E823A6894 for ; Tue, 23 Nov 2010 01:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 CrJ7mBSdyU0Q for ; Tue, 23 Nov 2010 01:49:30 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 0E7E13A6893 for ; Tue, 23 Nov 2010 01:49:29 -0800 (PST) Received: by gwj17 with SMTP id 17so585378gwj.31 for ; Tue, 23 Nov 2010 01:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=VCtcCETiGDZ+PbhMfE+AcFESc4wPNCSEiBodjpS+Bk4=; b=NnQUa9LLCGSe3Xidx4HYkykT0IzXCyBVyHsDolfb2SxtWoPDinVIBDDQdux6P56a78 K+9k+Tf5EjUXbT6f5kr1uI/OSgYNKbMr8QFuPfq9MepDNeTpkbMXgJcW8+PbJLabIv5R HreG3YLVNIYwl+Z5DrbSmGaGIjcL44Ab+Qe5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=h7pJhxAXPL50sDX1GpjGOo1+dkk/mOhut8in4oWvRVHRrOQejhDLqprgTsK6Q53B79 vIflpX2NFMfbu8+PzkgW6Jcf/DrUhnEQeGZVL2yLCW5HHD2CDjS1k5fy23YRTqdzl2UH y99Rv7c7hWdJCZKr68nMfyNGNg9Dkoz3zpRDY= MIME-Version: 1.0 Received: by 10.100.132.18 with SMTP id f18mr4881977and.227.1290505826639; Tue, 23 Nov 2010 01:50:26 -0800 (PST) Received: by 10.100.153.15 with HTTP; Tue, 23 Nov 2010 01:50:26 -0800 (PST) In-Reply-To: <20101122150336.GA31624@openss7.org> References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> <4CE80DC0.90803@gmail.com> <20101120220214.GA26962@openss7.org> <20101122150336.GA31624@openss7.org> Date: Tue, 23 Nov 2010 10:50:26 +0100 Message-ID: From: Ilie Glib To: bidulock@openss7.org, Ilie Glib , "?????????????? ??????????" , sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016e645b88060a0330495b54db2 Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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, 23 Nov 2010 09:49:31 -0000 --0016e645b88060a0330495b54db2 Content-Type: text/plain; charset=ISO-8859-1 And how would they automatically register? Which SPC would would be DPC and which OPC in the RK? On Mon, Nov 22, 2010 at 4:03 PM, Brian F. G. Bidulock wrote: > Ilie, > > Ilie Glib wrote: > (Mon, 22 Nov 2010 13:57:12) > > > > we had this discussion ages ago, and as far as I remember our > > conclusion was that in the SE IPSP to IPSP scenario one has two ASes - > > one on each side. They have symmetric RKs and a same value of the RC. > > No. One AS, one RC, one RK, describing both directions of traffic. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > -- Ilie --0016e645b88060a0330495b54db2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

And how would they automatically register?

=A0

Which SPC would would be DPC and which OPC in the RK?

On Mon, Nov 22, 2010 at 4:03 PM, Brian F. G. Bid= ulock <biduloc= k@openss7.org> wrote:

Ilie,

Ilie Glib wrote: = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Mo= n, 22 Nov 2010 13:57:12)

>
> =A0 =A0we had this discussion ages ago, and = as far as I remember our
> =A0 =A0conclusion was that in the SE IPSP = to IPSP scenario one has two ASes -
> =A0 =A0one on each side. They h= ave symmetric RKs and a same value of the RC.

No. =A0One AS, one RC, one RK, describing both directions of traf= fic.

--brian

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

--
Ilie
--0016e645b88060a0330495b54db2-- From ilie.glib@googlemail.com Tue Nov 23 01:54: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 26FFE3A6889 for ; Tue, 23 Nov 2010 01:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 3PuxdBlDhrCp for ; Tue, 23 Nov 2010 01:54:42 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 1B5B63A689F for ; Tue, 23 Nov 2010 01:54:42 -0800 (PST) Received: by gyb13 with SMTP id 13so2150261gyb.31 for ; Tue, 23 Nov 2010 01:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=z61ccWvVfEHlMnUagA0aUd8koC3kWeiPfwfQdk+hTlg=; b=v1m8FilA5AAUWDwsHyDR3Q62XkdUe2u5PE2jAk2qRHcwjLLfAGthJ+Wj4prQpdTMtc rCbQO+D1quNSkCwGmVujBoQcQbEk4V6zyhKCLuon4S15yGJD+9zUIp1VyAeMq1yHM7sr z57oEoIj2QvOvRlTS2MVB9k5IZhTspnGToFNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=QMUdtMDAMtDbz4+B/X4OhUNE2X5lqwTd07k9UCrjk/AkL5RJf0zYWWZO51MDZpg2SI czNtKT/iwNJ4uXoo36kEM6Z2LQPKpWA/tiqfCKULHaQnDjk75Tdn08hZakafcQMxEyNP fO3wa0MV/5qyh4pKKkpEQjlMQ0Tb32XosUWLs= MIME-Version: 1.0 Received: by 10.100.107.20 with SMTP id f20mr4847358anc.91.1290506137456; Tue, 23 Nov 2010 01:55:37 -0800 (PST) Received: by 10.100.153.15 with HTTP; Tue, 23 Nov 2010 01:55:37 -0800 (PST) In-Reply-To: References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> <4CE80DC0.90803@gmail.com> <20101120220214.GA26962@openss7.org> <20101122150336.GA31624@openss7.org> Date: Tue, 23 Nov 2010 10:55:37 +0100 Message-ID: From: Ilie Glib To: bidulock@openss7.org, Ilie Glib , "?????????????? ??????????" , sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016e644cbbce751c90495b55fc6 Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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, 23 Nov 2010 09:54:44 -0000 --0016e644cbbce751c90495b55fc6 Content-Type: text/plain; charset=ISO-8859-1 Hello Brian, et al. here is a copy of an old mail. Enjoy it BR //Ilie ---------- Forwarded message ---------- From: Ilie Glib Date: Tue, Dec 6, 2005 at 5:11 PM Subject: Re: [Sigtran] AS, RK , RC concepts in SE model To: bidulock@openss7.org, Ilie Glib , Tolga Asveren , sigtran@ietf.org Brian, perfect, I was exactly after this statement. Now, we have consensus. Thank you very much indeed. Ilie On 12/6/05, Brian F. G. Bidulock wrote: > Ilie, > > An AS is a User (MTP-User, SCCP-User). In a peer-to-peer signalling > relation without relay or transfer, there are two Users, however, > there is only one signalling relation. Each end has an address. > the pair of addresses defines the signalling relation. A signalling > relation is an RK, and an RC. > > As Tolga puts it well, at one IPSP, there is a 1:1:1 relationship > between an AS (local concept) and RC and an RK. Same at the other. > The RCs are the same and the RK's are symmetric (both define the > signalling relation from the view at only one end). If you know > one RK you know the other. Each end defines an AS (without relay) > and both form one signalling relation. > > --brian > > > Ilie Glib wrote: (Tue, 06 Dec 2005 15:49:36) > > Hello Tolga, Brian, > > > > Thank you very much indeed for your clarifications. It is hard for me > > to understand how on earth a concept of a sink (AS) has evolved to a > > concept of two sinks. Anyway, > > - is this view largely accepted by the SIGTRAN community? > > - Will other adaptation layers (say SUA) follow this model? > > > > I would expect a separate draft/RFC that describes this model, one > > draft per xxUA. As far as I understood a new WI is planned for M3UA > > (for SG to SG), will it cover this model? How about other xxUAs? > > > > Thank you in advance > > > > Ilie > > > > On 12/6/05, Tolga Asveren wrote: > > > Ilie, > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Ilie Glib > > > > Sent: Tuesday, December 06, 2005 6:10 AM > > > > To: bidulock@openss7.org; Ilie Glib; sigtran@ietf.org > > > > Subject: Re: [Sigtran] AS, RK , RC concepts in SE model > > > > > > > > > > > > Hello Brian, > > > > > > > > in my view this is a considerable change of AS concept. In SIGTRAN an > > > > AS is an application server sitting behind its ASPs/IPSPs. Now you say > > > > an AS is a bidirectional signalling relation and not an Application > > > > Server. > > > [TOLGA]Two points related with this: > > > - From M3UA stack point of view, an AS is a signaling realtionship for > > > SGP/ASP/IPSP cases. It is true that AS is not only a M3UA stack but the > > > functional areas of M3UA specification deal only with M3UA stack behavior. > > > If you look from architectural perspective, I would say that an AS consists > > > of multiple ASPs -with M3UA stack, SS7 User Parts and Application logic-, > > > rather than AS sits behind ASPs/IPSPs. > > > > > > - From modeling point of view, 1:1 relationship between AS and RK still > > > holds for SE-IPSP. One can think that two ends of an SE-IPSP relationship > > > are different AS using the same RK. On each IPSP you still have the 1:1 > > > relationship between AS and RK, because you care only about your local AS > > > definiton -it defines traffic at both ends-. > > > > > > > > The same goes for RK, RK1 cannot be the same as RK2, because Routing > > > > Key defines where messages go, it defines routing. > > > [TOLGA]For SE-IPSP RK defines traffic at both ends. Still you have your > > > "local" RK to guide you for routing decisions. Obviously two sides need to > > > use the same RC so that messages are exchanged properly. > > > > > > > > In my view the concept of Application Server cannot be dependent on > > > > the exchange model used. How can we make the main SIGTRAN concept > > > > dependent on the communication model? > > > [TOLGA]It isn't. > > > > > > > > Any other opinions? > > > > > > > > Regards > > > > > > > > Ilie > > > > > > > > On 12/6/05, Brian F. G. Bidulock wrote: > > > > > Ilie, > > > > > > > > > > For SE AS1==AS2 (and RK1==RK2). > > > > > > > > > > For DE AS1!=AS2 (and RK1!=RK2). > > > > > > > > > > You need double the AS, RC and RKs in DE as you do in SE. > > > > > > > > > > Because they can't relay, IPSPs only need 1 AS betwixt them. > > > > > > > > > > --brian > > > > > > > > > > Ilie Glib wrote: (Tue, 06 Dec 2005 > > > > 11:40:47) > > > > > > Hello Folks, > > > > > > > > > > > > According to the current definition of AS and RK there is 1:1 > > > > > > relationship between them. The AS is an Application Server that > > > > > > process traffic routed according to the routing key, that is it > > > > > > process traffic that comes from unidirectional signalling relations, > > > > > > it does not process traffic that goes in the opposite direction, it > > > > > > generates traffic in the opposite direction. > > > > > > > > > > > > For example > > > > > > The RK1=(OPC=2-200, DPC=2-100) is different from RK2=(OPC=2-100, > > > > > > DPC=2-200). Each RK defines its own AS, in this case AS1, which > > > > > > corresponds to RK1, sits in 2-200 signalling point and AS2, which > > > > > > corresponds to RK2, is in 2-100, and each AS has its own RK. > > > > > > > > > > > > Could you please clarify > > > > > > > > > > > > Q1: What is correct 1) or 2) > > > > > > 1) In the described above configuration it is one AS = > > > > AS1=AS2, or otherwise > > > > > > 2) AS1 and AS2 are different ASes > > > > > > > > > > > > I assume 2) is correct. Then Routing Context RC1 corresponding to RK1 > > > > > > is assigned in AS2 and Routing Context RC2 corresponding to RK2 is > > > > > > assigned in AS1. RC1 and RC2 are different but may be the same by > > > > > > chance. > > > > > > > > > > > > Routing Context parameter is mandatory in SUA traffic messages. > > > > > > > > > > > > In case of SE model could you please clarify > > > > > > > > > > > > Q2: What Routing Context values will be used in traffic messages > > > > > > between AS1 and AS2? > > > > > > Q3: Does it depend on the direction of the message? > > > > > > > > > > > > Q4: When RC1 is used and when RC2? > > > > > > > > > > > > Q5: what RC shall be used by response messages? > > > > > > > > > > > > > > > > > > Thank you in advance > > > > > > > > > > > > Ilie > > > > > > > > > > > > _______________________________________________ > > > > > > Sigtran mailing list > > > > > > Sigtran@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > -- > > > > > Brian F. G. Bidulock > > > > > bidulock@openss7.org > > > > > http://www.openss7.org/ > > > > > > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > -- Ilie On Tue, Nov 23, 2010 at 10:50 AM, Ilie Glib wrote: > And how would they automatically register? > > Which SPC would would be DPC and which OPC in the RK? > > On Mon, Nov 22, 2010 at 4:03 PM, Brian F. G. Bidulock < > bidulock@openss7.org> wrote: > >> Ilie, >> >> Ilie Glib wrote: >> (Mon, 22 Nov 2010 13:57:12) >> > >> > we had this discussion ages ago, and as far as I remember our >> > conclusion was that in the SE IPSP to IPSP scenario one has two ASes >> - >> > one on each side. They have symmetric RKs and a same value of the RC. >> >> No. One AS, one RC, one RK, describing both directions of traffic. >> >> --brian >> >> -- >> Brian F. G. Bidulock >> bidulock@openss7.org >> http://www.openss7.org/ >> > > > > -- > Ilie > -- Ilie --0016e644cbbce751c90495b55fc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello Brian, et al.

=A0

here is a copy of an old mail. Enjoy it

=A0

BR //Ilie

=A0

---------- Forwarded message ----------
From:= Ilie Glib <ilie.glib@googlemail.com>
Date: Tue, Dec 6, 2005 at 5:11 PM
Subject: Re: [Sigtran] AS, RK , RC con= cepts in SE model
To: bidulock@o= penss7.org, Ilie Glib <i= lie.glib@googlemail.com>, Tolga Asveren <asveren@ulticom.com>, sigtran@ietf.org

Brian,

perfect, I was exactly after this statement.

N= ow, we have consensus.

Thank you very much indeed.

Ilie

On 12/6/05, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
= > Ilie,
>
> An AS is a User (MTP-User, SCCP-User). =A0In a p= eer-to-peer signalling
> relation without relay or transfer, there are two Users, however,
&= gt; there is only one signalling relation. =A0Each end has an address.
&= gt; the pair of addresses defines the signalling relation. =A0A signalling<= br> > relation is an RK, and an RC.
>
> As Tolga puts it well, a= t one IPSP, there is a 1:1:1 relationship
> between an AS (local conc= ept) and RC and an RK. =A0Same at the other.
> The RCs are the same a= nd the RK's are symmetric (both define the
> signalling relation from the view at only one end). =A0If you know
= > one RK you know the other. =A0Each end defines an AS (without relay)> and both form one signalling relation.
>
> --brian
&g= t;
>
> Ilie Glib 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(Tue, 06 Dec= 2005 15:49:36)
> > Hello Tolga, Brian,
> >
> > = Thank you very much indeed for your clarifications. It =A0is hard for me > > to understand how on earth a concept of a sink (AS) has evolved t= o a
> > concept of two sinks. Anyway,
> > - is this view = largely accepted by the SIGTRAN community?
> > - Will other adapta= tion layers (say SUA) follow this model?
> >
> > I would expect a separate draft/RFC that describes t= his model, one
> > draft per xxUA. As far as I understood a new WI= is planned for M3UA
> > (for SG to SG), will it cover this model?= How about other xxUAs?
> >
> > Thank you in advance
> >
> > Ilie<= br>> >
> > On 12/6/05, Tolga Asveren <asveren@ulticom.com> wrote:
> > > Il= ie,
> > >
> > > > -----Original Message-----
> &g= t; > > From: sigtran-boun= ces@ietf.org [mailto:sigtra= n-bounces@ietf.org]On
> > > > Behalf Of Ilie Glib
> > > > Sent: Tuesda= y, December 06, 2005 6:10 AM
> > > > To: bidulock@openss7.org; Ilie Glib; sigtran@ietf.org
> > > > Subject: Re: [Sigtran] AS, RK , RC concepts in SE model=
> > > >
> > > >
> > > > Hello= Brian,
> > > >
> > > > in my view this is a = considerable change of AS concept. In SIGTRAN an
> > > > AS is an application server sitting behind its ASPs/IPS= Ps. Now you say
> > > > an AS is a bidirectional signalling = relation and not an Application
> > > > Server.
> >= > [TOLGA]Two points related with this:
> > > - From M3UA stack point of view, an AS is a signaling realti= onship for
> > > SGP/ASP/IPSP cases. It is true that AS is not = only a M3UA stack but the
> > > functional areas of M3UA specif= ication deal only with M3UA stack behavior.
> > > If you look from architectural perspective, I would say that= an AS consists
> > > of multiple ASPs -with M3UA stack, SS7 Us= er Parts and Application logic-,
> > > rather than AS sits behi= nd ASPs/IPSPs.
> > >
> > > - From modeling point of view, 1:1 relatio= nship between AS and RK still
> > > holds for SE-IPSP. One can = think that two ends of an SE-IPSP relationship
> > > are differ= ent AS using the same RK. On each IPSP you still have the 1:1
> > > relationship between AS and RK, because you care only about = your local AS
> > > definiton -it defines traffic at both ends-= .
> > > >
> > > > The same goes for RK, =A0RK= 1 cannot be the same as RK2, because Routing
> > > > Key defines where messages go, it defines routing.
&= gt; > > [TOLGA]For SE-IPSP RK defines traffic at both ends. Still you= have your
> > > "local" RK to guide you for routing = decisions. Obviously two sides need to
> > > use the same RC so that messages are exchanged properly.
= > > > >
> > > > In my view the concept of Applic= ation Server cannot be dependent on
> > > > the exchange mod= el used. How can we make the main SIGTRAN concept
> > > > dependent on the communication model?
> > >= [TOLGA]It isn't.
> > > >
> > > > Any oth= er opinions?
> > > >
> > > > Regards
> = > > >
> > > > Ilie
> > > >
> > > > On 1= 2/6/05, Brian F. G. Bidulock <bi= dulock@openss7.org> wrote:
> > > > > Ilie,
>= > > > >
> > > > > For SE AS1=3D=3DAS2 (and RK1=3D=3DRK2).
> &g= t; > > >
> > > > > For DE AS1!=3DAS2 (and RK1!= =3DRK2).
> > > > >
> > > > > You need d= ouble the AS, RC and RKs in DE as you do in SE.
> > > > >
> > > > > Because they can't= relay, IPSPs only need 1 AS betwixt them.
> > > > >
&= gt; > > > > --brian
> > > > >
> > &g= t; > > Ilie Glib wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0(Tue, 06 Dec 2005
> > > > 11:40:47)
> > > > > > Hello Folks,=
> > > > > >
> > > > > > Accordin= g to the current definition of AS and RK there is 1:1
> > > >= ; > > relationship between them. The AS is an Application Server that=
> > > > > > process traffic routed according to the routi= ng key, that is it
> > > > > > process traffic that co= mes from unidirectional signalling relations,
> > > > > &= gt; it does not process traffic that goes in the opposite direction, it
> > > > > > generates traffic in the opposite direction.<= br>> > > > > >
> > > > > > For examp= le
> > > > > > The RK1=3D(OPC=3D2-200, DPC=3D2-100) is= different from RK2=3D(OPC=3D2-100,
> > > > > > DPC=3D2-200). Each RK defines its own AS, in = this case AS1, which
> > > > > > corresponds to RK1, s= its in 2-200 signalling point and AS2, which
> > > > > &g= t; corresponds to RK2, is in 2-100, and each AS has its own RK.
> > > > > >
> > > > > > Could you pl= ease clarify
> > > > > >
> > > > > &= gt; Q1: What is correct 1) or 2)
> > > > > > 1) In the= described above configuration it is one AS =3D
> > > > AS1=3DAS2, or otherwise
> > > > > >= ; 2) AS1 and AS2 are different ASes
> > > > > >
>= ; > > > > > I assume 2) is correct. Then Routing Context RC1= corresponding to RK1
> > > > > > is assigned in AS2 and Routing Context RC2 co= rresponding to RK2 is
> > > > > > assigned in AS1. RC1= and RC2 are different but may be the same by
> > > > > &= gt; chance.
> > > > > >
> > > > > > Routing Cont= ext parameter is mandatory in SUA traffic messages.
> > > > = > >
> > > > > > In case of SE model could you pl= ease clarify
> > > > > >
> > > > > > Q2: What Rou= ting Context values will be used in traffic messages
> > > >= > > between AS1 and AS2?
> > > > > > Q3: Does i= t depend on the direction of the message?
> > > > > >
> > > > > > Q4: When RC1= is used and when RC2?
> > > > > >
> > > &= gt; > > Q5: what RC shall be used by response messages?
> > = > > > >
> > > > > >
> > > > > > Thank you in= advance
> > > > > >
> > > > > > = Ilie
> > > > > >
> > > > > > ____= ___________________________________________
> > > > > > Sigtran mailing list
> > > > &= gt; > Sigtran@ietf.org
> &= gt; > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > --
> > > &= gt; > Brian F. G. Bidulock
> > > > > bidulock@openss7.org
> > > > >= http://www.openss7.o= rg/
> > > > >
> > > >
> > > > ____= ___________________________________________
> > > > Sigtran = mailing list
> > > > Sig= tran@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/sigtran> > > >
> > >
> > >
> > ><= br> > > > _______________________________________________
> >= > Sigtran mailing list
> > > Sigtran@ietf.org
> > > https://www1.ietf.org/mailma= n/listinfo/sigtran
> > >
> >
> > __________________________________= _____________
> > Sigtran mailing list
> > Sigtran@ietf.org
> > https://www1.ietf= .org/mailman/listinfo/sigtran
>
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/
>

--
Ilie

On Tue, Nov 23, 2010 at 10:50 AM, Ilie Glib <ilie.glib@goo= glemail.com> wrote:

And how would they automatically register?

=A0

Which SPC would would be DPC and which OPC in the RK?

On Mon, Nov 22, 2010 at 4:03 PM, Brian F. G. Bid= ulock <bidulock@openss7.org> wrote:

Ilie,

Ilie Glib wrote: = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Mo= n, 22 Nov 2010 13:57:12)

>
> =A0 =A0we had this discussion ages ago, and as far as I r= emember our
> =A0 =A0conclusion was that in the SE IPSP to IPSP scena= rio one has two ASes -
> =A0 =A0one on each side. They have symmetric= RKs and a same value of the RC.

No. =A0One AS, one RC, one RK, describing both directions of traf= fic.

--brian

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

--
Ilie

=
--
Ilie
--0016e644cbbce751c90495b55fc6-- From naveen.sarma@gmail.com Tue Nov 23 06:35:33 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 0497A3A6974 for ; Tue, 23 Nov 2010 06:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMoWNUshdYmw for ; Tue, 23 Nov 2010 06:35:32 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id DC6353A6969 for ; Tue, 23 Nov 2010 06:35:31 -0800 (PST) Received: by wyb29 with SMTP id 29so8380060wyb.31 for ; Tue, 23 Nov 2010 06:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=9RJWrONXwSs34WkMDLOQ8J5+T9+wfdk1MINJiUxTSZs=; b=W7apebdkBjNvrC2gieVUC3qrZOJppLDzjuofsp2F8P8HKlgzLPpJ7zI0LsyvR8dtxK yaPOeG64vmST8fQoN19adc2o6gOskvu76X234Vp3qwvAFYAZaEf+s8KCVh+zbwpDnynW pYGbQSwKJTqQ1AWgVIye846QsYwbS1cpu+cKg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=C4WgK/ySrClf9cXVecmjJZtLwGHmDmB8RmMTcnNFI0fZ/YqJfT8nXO48yx/9C11zB2 2nXXYagXDItSDbQCz6oIBSqjNM1kqZxng+/0c5PYYZInlrmmb5GizQbsv1MIl9/qc93G O9APCeqgTJ48/OhGdxQDAL1LbnUX8s8EUBW6U= Received: by 10.216.3.3 with SMTP id 3mr1065695weg.57.1290522988939; Tue, 23 Nov 2010 06:36:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.80.14 with HTTP; Tue, 23 Nov 2010 06:36:08 -0800 (PST) From: Naveen Kottapalli Date: Tue, 23 Nov 2010 14:36:08 +0000 Message-ID: To: sigtran@ietf.org Content-Type: multipart/alternative; boundary=0016364d265b548a720495b94cbd Subject: [Sigtran] Something improper with ASP state change procedures. X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 14:35:33 -0000 --0016364d265b548a720495b94cbd Content-Type: text/plain; charset=ISO-8859-1 Hi All, We are seeing some strange in the M3UA ASP state change procedures. Please find the description of the problem below. ASP SGP ======================================= ASPUP --------------> Processes ASPUP and sends ASPUP_ACK Move ASP to INACTIVE state <------------- ASPUP_ACK SCTP-SACK for ASPUP_ACK -------------> Missed or lost in the network ASPAC --------------> Processes ASPAC and sends ASPAC_ACK Move ASP to ACTIVE state <------------- ASPAC_ACK SCTP-SACK for ASPAC_ACK -------------> Missed or lost again in the network Move ASP to INACTIVE state <------------- SCTP layer at SGP retransmits the ASPUP_ACK, ASPAC_ACK because of lost SACKs. because of ASPUP_ACK in ACTIVE state SCTP-SACK -------------> Reached the SCTP layer of SGP In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE state whereas it is not the case. Since ASP is in INACTIVE state, all the data packets that were sent by SGP will be dropped (without sending any error message back to network). The above problem will lead to a potential message loss in the network. Considering the above behavior, I think the state machine should be tuned accordingly. Please pass on the comments on this. Thanks & Regards, Naveen. --0016364d265b548a720495b94cbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi All,

=A0

We are seeing some=A0strange in the M3UA ASP state change procedures.= =A0 Please find the description of the problem below.

=A0

ASP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SGP

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

ASPUP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------------->=A0 = Processes ASPUP and sends ASPUP_ACK

=A0

Move ASP to

INACTIVE state=A0=A0=A0<-------------=A0=A0=A0ASPUP_ACK

=A0

SCTP-SACK

for ASPUP_ACK=A0 ------------->=A0 Missed or lost in the network

=A0

ASPAC=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------------->=A0 = Processes ASPAC and sends ASPAC_ACK

=A0

Move ASP to

ACTIVE state=A0=A0=A0=A0=A0 <-------------=A0=A0=A0ASPAC_ACK

=A0

SCTP-SACK

for ASPAC_ACK=A0 ------------->=A0 Missed or lost again in the netw= ork

=A0

Move ASP to

INACTIVE state=A0=A0=A0<-------------=A0=A0=A0SCTP layer at SGP ret= ransmits the ASPUP_ACK, ASPAC_ACK=A0because of lost SACKs.

because of

ASPUP_ACK

in ACTIVE state

=A0

SCTP-SACK=A0=A0=A0=A0=A0=A0=A0 ------------->=A0 Reached the SCTP l= ayer of SGP

=A0

In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE= state whereas it is not the case.=A0 Since ASP is in INACTIVE state, all t= he data packets that were sent by SGP will be dropped (without sending any = error message back to network).=A0 The above problem will lead to a potenti= al message loss in the network.

=A0

Considering the above behavior, I think the state machine should be tu= ned accordingly.

=A0

Please pass on the comments on this.

=A0

Thanks & Regards,
Naveen.

--0016364d265b548a720495b94cbd-- From dario_filjar@yahoo.com Tue Nov 23 06:46:09 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 B820B28C135 for ; Tue, 23 Nov 2010 06:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLZ6FJQ0ACTk for ; Tue, 23 Nov 2010 06:46:03 -0800 (PST) Received: from web30002.mail.mud.yahoo.com (web30002.mail.mud.yahoo.com [209.191.69.19]) by core3.amsl.com (Postfix) with SMTP id 5B6B53A6978 for ; Tue, 23 Nov 2010 06:45:59 -0800 (PST) Received: (qmail 258 invoked by uid 60001); 23 Nov 2010 14:46:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1290523613; bh=TsjxYl4LFEO4krbDzshbKWbaqDl0wZJq8xmiaEnmt1g=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=OwWYJbJ60B/+UmVJE77rBzLkfKNegs9vTUub6boRgnWhplnjvVnDe+4T3KdeVEhhn3BQksxJyCY5NR9Qjzaz9f3J191i7Lc0pgBvUj0byErt5uHgemSJ1aSfV2YRSQyd+QR0kG3uqk26woqzyhgYn3+RA85bWd9fgw1wkK3LXe8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Qjt2nZW9MlLW8Omzl0mu+D03b+jZ5le0Kvqmb0AqTEsCyBMntLJlgKp/ZDg4cHr9yLaI7e9avYaHw9GgaUjNTxYn3mrGQIcI3jhrerrHaPi0lFcgrotfzv0QyzQNv23G/uX0C356MLpa7XfnrRjPDtBC4NXCkT1xN9qVl75gJCw=; Message-ID: <681618.98422.qm@web30002.mail.mud.yahoo.com> X-YMail-OSG: HqrB_20VM1mDgIElfqvZ04DhjuTbBQQkZPnSMzj9bLOR2Y3 .rM8jSJikULMDdqMYxwCvvQvTtdt6O.9zkTFnlePAzaGt23wXfin0FPU81uK kjhgHLWuVi2APji58jB3_Ka4gWrREUDg3ROGn7A.tSKe1gcSs.I2jt2S4KBq 3sLXjYZJ6QENT0Fmtb.gWlSyDD7NBXPBlMyyBwJBaSflvXt0zcHA7VEPblwp XFv0f.Zwd9uDsdQS0jryqp6BSfJ1PwTgxI0nG.RLZtTwrNN87YBSo_leEW_e 6ZjhES7Wq92Yyvl6zuWV6.kfGxNe_TtaOnKmSTjbUQEQtgnaQ0s.OeIDOyFX WqdY9bRXOZyF72Ob0c62pfCA4LohlLFyry5YKSS5gXug- Received: from [194.152.253.4] by web30002.mail.mud.yahoo.com via HTTP; Tue, 23 Nov 2010 06:46:53 PST X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.107.285259 Date: Tue, 23 Nov 2010 06:46:53 -0800 (PST) From: Dario Filjar To: sigtran@ietf.org, Naveen Kottapalli In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1176988401-1290523613=:98422" Subject: Re: [Sigtran] Something improper with ASP state change procedures. X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 14:46:09 -0000 --0-1176988401-1290523613=:98422 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Naveen, =A0 it seems that ASP does not behave correctly after reception of out-of-blue = ASP Up Ack message. According to RFC4666, section 4.3.4.1: =A0 "If the ASP receives an unexpected ASP Up Ack message, the ASP should consi= der itself in the ASP-INACTIVE state. If the ASP was not in the ASP-INACTIV= E state, it should send an Error message and then initate procedures to ret= urn to its previos state." =A0 So in your case, ASP shall initiate ASP Active procedure again after which = it will align the state with SGP. =A0 BR Dario --- On Tue, 11/23/10, Naveen Kottapalli wrote: From: Naveen Kottapalli Subject: [Sigtran] Something improper with ASP state change procedures. To: sigtran@ietf.org Date: Tuesday, November 23, 2010, 3:36 PM Hi All, =A0 We are seeing some=A0strange in the M3UA ASP state change procedures.=A0 Pl= ease find the description of the problem below. =A0 ASP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SGP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ASPUP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------------->=A0 Processe= s ASPUP and sends ASPUP_ACK =A0 Move ASP to INACTIVE state=A0=A0=A0<-------------=A0=A0=A0ASPUP_ACK =A0 SCTP-SACK for ASPUP_ACK=A0 ------------->=A0 Missed or lost in the network =A0 ASPAC=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------------->=A0 Processe= s ASPAC and sends ASPAC_ACK =A0 Move ASP to ACTIVE state=A0=A0=A0=A0=A0 <-------------=A0=A0=A0ASPAC_ACK =A0 SCTP-SACK for ASPAC_ACK=A0 ------------->=A0 Missed or lost again in the network =A0 Move ASP to INACTIVE state=A0=A0=A0<-------------=A0=A0=A0SCTP layer at SGP retransmits= the ASPUP_ACK, ASPAC_ACK=A0because of lost SACKs. because of ASPUP_ACK in ACTIVE state =A0 SCTP-SACK=A0=A0=A0=A0=A0=A0=A0 ------------->=A0 Reached the SCTP layer of = SGP =A0 In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE stat= e whereas it is not the case.=A0 Since ASP is in INACTIVE state, all the da= ta packets that were sent by SGP will be dropped (without sending any error= message back to network).=A0 The above problem will lead to a potential me= ssage loss in the network. =A0 Considering the above behavior, I think the state machine should be tuned a= ccordingly. =A0 Please pass on the comments on this. =A0 Thanks & Regards, Naveen. -----Inline Attachment Follows----- _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran =0A=0A=0A --0-1176988401-1290523613=:98422 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Naveen,

it seems that ASP does not behave correctly after reception of out-of-= blue ASP Up Ack message.

According to RFC4666, section 4.3.4.1:

"If the ASP receives an unexpected ASP Up Ack message, the ASP should = consider itself in the ASP-INACTIVE state. If the ASP was not in the ASP-IN= ACTIVE state, it should send an Error message and then initate procedures t= o return to its previos state."

So in your case, ASP shall initiate ASP Active procedure again after w= hich it will align the state with SGP.

BR Dario

--- On Tue, 11/23/10, Naveen Kottapalli <naveen.sarma= @gmail.com> wrote:

From: Naveen Kottapalli <naveen.sarma@gmail.co= m>
Subject: [Sigtran] Something improper with ASP state change proced= ures.
To: sigtran@ietf.org
Date: Tuesday, November 23, 2010, 3:36 PM<= BR>

Hi All,

We are seeing some strange in the M3UA ASP state change procedure= s. Please find the description of the problem below.

ASP           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             = SGP

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

ASPUP           = ;    --------------> Processes ASPUP and sends ASPU= P_ACK

Move ASP to

INACTIVE state   <-------------   ASP= UP_ACK

SCTP-SACK

for ASPUP_ACK -------------> Missed or lost in the netw= ork

ASPAC           = ;    --------------> Processes ASPAC and sends ASPA= C_ACK

Move ASP to

ACTIVE state      <------------- &nbs= p; ASPAC_ACK

SCTP-SACK

for ASPAC_ACK -------------> Missed or lost again in th= e network

Move ASP to

INACTIVE state   <-------------   SCT= P layer at SGP retransmits the ASPUP_ACK, ASPAC_ACK because of lost SA= CKs.

because of

ASPUP_ACK

in ACTIVE state

SCTP-SACK        ------------->&= nbsp; Reached the SCTP layer of SGP

In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE= state whereas it is not the case. Since ASP is in INACTIVE state, al= l the data packets that were sent by SGP will be dropped (without sending a= ny error message back to network). The above problem will lead to a p= otential message loss in the network.

Considering the above behavior, I think the state machine should be tu= ned accordingly.

Please pass on the comments on this.

Thanks & Regards,
Naveen.

-----Inline Attach= ment Follows-----

_______________________________________________
S= igtran mailing list
Sigtran@ietf.or= g
https://www.ietf.org/mailman/listinfo/sigtran

=0A=0A=0A=0A=0A=0A=0A=0A --0-1176988401-1290523613=:98422-- From abooth@pt.com Tue Nov 23 07:09: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 7C3FF3A6961 for ; Tue, 23 Nov 2010 07:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.056 X-Spam-Level: X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_12=0.6, MIME_BAD_LINEBREAK=0.5, MIME_HTML_ONLY=1.457] 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 BmrPduD0S4VP for ; Tue, 23 Nov 2010 07:09:11 -0800 (PST) Received: from ottgw.pt.com (ottgw.pt.com [209.217.107.194]) by core3.amsl.com (Postfix) with ESMTP id C4EDC3A68FB for ; Tue, 23 Nov 2010 07:09:08 -0800 (PST) Received: from notes4.pt.com (notes4.corp.pt.com [10.81.15.15]) by ottgw.pt.com (Postfix) with ESMTP id 25CB3D71A0; Tue, 23 Nov 2010 08:59:09 -0500 (EST) Sensitivity: MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Andrew Booth To: naveen.sarma@gmail.com Message-ID: Date: Tue, 23 Nov 2010 10:10:04 -0500 X-Mailer: Lotus Domino Web Server Release 8.5FP1 June 15, 2009 X-MIMETrack: Serialize by Notes Server on notes4/PTI(Release 8.5FP1|June 15, 2009) at 11/23/2010 10:10:04 AM, Serialize complete at 11/23/2010 10:10:04 AM, Itemize by Notes Server on notes4/PTI(Release 8.5FP1|June 15, 2009) at 11/23/2010 10:10:04 AM, Serialize by Router on notes4/PTI(Release 8.5FP1|June 15, 2009) at 11/23/2010 10:10:04 AM Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Cc: sigtran@ietf.org Subject: Re: [Sigtran] Something improper with ASP state change procedures. X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 15:09:12 -0000 Naveen,

The M3UA layer at the ASP should never see this secon= d ASP UP ACK. The ASP is still active.

From your description, = the second ASP UP ACK is an SCTP retransmission. This means it has th= e same TSN as the original ASP UP ACK. The SCTP layer at the ASP shou= ld recognize this as a duplicate chunk and should not pass it on to the M3U= A layer.

Andrew

-----sigtran-bounces@= ietf.org wrote: -----

To: sigtran@ietf.org
From: Naveen Kottapalli
Sent by: sigtran-bounces@ietf.org
Date: 11/23/2010 09:36AMSubject: [Sigtran] Something improper with ASP state change procedures.
Hi All,=0D
=0D
=0D
= =0D
We are seeing some strange in the M3UA ASP state change proced= ures. Please find the description of the problem below.=0D
=0D =0D

=0D

ASP &nbs= p; &= nbsp; &nbs= p; &= nbsp; &nbs= p; SGP=0D

=0D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=0D

=0D

ASPUP &n= bsp; --------------> Processes= ASPUP and sends ASPUP=5FACK=0D

=0D

Move AS= P to=0D

=0D

INACTIVE state <------------- = ; ASPUP=5FACK=0D

=0D

SCTP-SACK= =0D

=0D

for ASPUP=5FACK -------------> Missed or lo= st in the network=0D

=0D

ASPAC &= nbsp; ---= -----------> Processes ASPAC and sends ASPAC=5FACK=0D

=0D=0D

=0D

Move ASP to=0D

=0D

ACTIVE state&nb= sp; <------------- ASPAC=5FACK= =0D

=0D

SCTP-SACK=0D

=0D

f= or ASPAC=5FACK -------------> Missed or lost again in the ne= twork=0D

=0D

Move ASP to=0D

= =0D

INACTIVE state <------------- = SCTP layer at SGP retransmits the ASPUP=5FACK, ASPAC=5FACK because of = lost SACKs.=0D

=0D

because of=0D

=0D

ASPUP=5FACK=0D

= =0D

in ACTIVE state=0D

=0D

SCTP-SACK&nb= sp; -------------> Reached the= SCTP layer of SGP=0D

=0D

In the abov= e behavior the M3UA at SGP thinks that the ASP is in ACTIVE state whereas i= t is not the case. Since ASP is in INACTIVE state, all the data packe= ts that were sent by SGP will be dropped (without sending any error message= back to network). The above problem will lead to a potential message= loss in the network.=0D

=0D

Considering th= e above behavior, I think the state machine should be tuned accordingly.=0D=

=0D

Please pass on the comments on this.= =0D

=0D

Thanks & Regards,= =0D
Naveen.=0D

=0D

=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=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sigtran mailing list
Sigtran@ietf.org
=
https://www.ietf.=
org/mailman/listinfo/sigtran=0D

=0D

<= /font>= From naveen.sarma@gmail.com Tue Nov 23 07:41: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 253BB28C165 for ; Tue, 23 Nov 2010 07:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, NORMAL_HTTP_TO_IP=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 6yUq-q-Minni for ; Tue, 23 Nov 2010 07:41:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 69D9628C170 for ; Tue, 23 Nov 2010 07:29:34 -0800 (PST) Received: by gxk27 with SMTP id 27so5295144gxk.31 for ; Tue, 23 Nov 2010 07:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=ehqVQmR9Vsx+hsUkMNBpdFZZVCrIzrNdNMC87AFgtl0=; b=DBEoWFt5i+H/pI22L8WTEi2N8QEGrArOBsqNRGLMh0xNmPpHoemSR9gdifNbI/vLpJ JWHqdnUVpMPcyIP4BLG/tZB+7fVxVlBKpXC9UXsNR+ji04dCfsiNO3SjbzI5qIHFLp6q vwOqTXP71PQzYPokxNQZZX1/N7K9o42+LSKv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=kwz0PN/2LqleowB7kGtXJHauQK6X5y58rSt6ABXS9x2siFVg2XJoDoP53Hm9jMWy14 E5AaTjR0F8rvQRpnW2CVKN/qhLkWPaQKSKSScR/sWao+URpH63YbSIbkDIKDpW/SVu5S FjFb7eU7huoopqghdoQoNnjFFj3KPqmZcAwi4= Received: by 10.100.58.14 with SMTP id g14mr5153816ana.230.1290526231256; Tue, 23 Nov 2010 07:30:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.165.11 with HTTP; Tue, 23 Nov 2010 07:30:11 -0800 (PST) In-Reply-To: <681618.98422.qm@web30002.mail.mud.yahoo.com> References: <681618.98422.qm@web30002.mail.mud.yahoo.com> From: Naveen Kottapalli Date: Tue, 23 Nov 2010 15:30:11 +0000 Message-ID: To: Dario Filjar Content-Type: multipart/alternative; boundary=0016e647167c968a3e0495ba0d30 Cc: sigtran@ietf.org Subject: Re: [Sigtran] Something improper with ASP state change procedures. X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 15:41:39 -0000 --0016e647167c968a3e0495ba0d30 Content-Type: text/plain; charset=ISO-8859-1 The previous state was INACTIVE. So, the ASP will be moved back to INACTIVE instead of reactivating. Is my assumption right? Yours, Naveen. On 23 November 2010 14:46, Dario Filjar wrote: > Hi Naveen, > > it seems that ASP does not behave correctly after reception of out-of-blue > ASP Up Ack message. > According to RFC4666, section 4.3.4.1: > > "If the ASP receives an unexpected ASP Up Ack message, the ASP should > consider itself in the ASP-INACTIVE state. If the ASP was not in the > ASP-INACTIVE state, it should send an Error message and then initate > procedures to return to its previos state." > > So in your case, ASP shall initiate ASP Active procedure again after which > it will align the state with SGP. > > BR Dario > > > --- On *Tue, 11/23/10, Naveen Kottapalli * wrote: > > > From: Naveen Kottapalli > Subject: [Sigtran] Something improper with ASP state change procedures. > To: sigtran@ietf.org > Date: Tuesday, November 23, 2010, 3:36 PM > > > Hi All, > > We are seeing some strange in the M3UA ASP state change procedures. Please > find the description of the problem below. > > ASP SGP > ======================================= > ASPUP --------------> Processes ASPUP and sends ASPUP_ACK > > Move ASP to > INACTIVE state <------------- ASPUP_ACK > > SCTP-SACK > for ASPUP_ACK -------------> Missed or lost in the network > > ASPAC --------------> Processes ASPAC and sends ASPAC_ACK > > Move ASP to > ACTIVE state <------------- ASPAC_ACK > > SCTP-SACK > for ASPAC_ACK -------------> Missed or lost again in the network > > Move ASP to > INACTIVE state <------------- SCTP layer at SGP retransmits the > ASPUP_ACK, ASPAC_ACK because of lost SACKs. > because of > ASPUP_ACK > in ACTIVE state > > SCTP-SACK -------------> Reached the SCTP layer of SGP > > In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE > state whereas it is not the case. Since ASP is in INACTIVE state, all the > data packets that were sent by SGP will be dropped (without sending any > error message back to network). The above problem will lead to a potential > message loss in the network. > > Considering the above behavior, I think the state machine should be tuned > accordingly. > > Please pass on the comments on this. > > Thanks & Regards, > Naveen. > > -----Inline Attachment Follows----- > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > > > --0016e647167c968a3e0495ba0d30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The previous state was INACTIVE.=A0 So, the ASP will be moved back to = INACTIVE instead of reactivating.=A0 Is my assumption right?

Yours,
Naveen.

On 23 November 2010 14:46, Dario Filjar <dario_filjar@yahoo.= com> wrote:

Hi Naveen,

=A0

it seems that ASP does not behave correctly after reception of out-of-= blue ASP Up Ack message.

According to RFC4666, section 4.3.4.1:

=A0

"If the ASP receives an unexpected ASP Up Ack message, the ASP sh= ould consider itself in the ASP-INACTIVE state. If the ASP was not in the A= SP-INACTIVE state, it should send an Error message and then initate procedu= res to return to its previos state."

=A0

So in your case, ASP shall initiate ASP Active procedure again after w= hich it will align the state with SGP.

=A0

BR Dario

--- On Tue, 11/23/10, Naveen Kottapalli <naveen.sarma@gmail.com&= gt; wrote:

From: Naveen Kottapalli <naveen.sarma@gmail.com>
= Subject: [Sigtran] Something improper with ASP state change procedures.
= To: sigtran@ietf.org<= /a>
Date: Tuesday, November 23, 2010, 3:36 PM=20

Hi All,

=A0

We are seeing some=A0strange in the M3UA ASP state change procedures.= =A0 Please find the description of the problem below.

=A0

ASP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SGP

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

ASPUP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------------->=A0 = Processes ASPUP and sends ASPUP_ACK

=A0

Move ASP to

INACTIVE state=A0=A0=A0<-------------=A0=A0=A0ASPUP_ACK

=A0

SCTP-SACK

for ASPUP_ACK=A0 ------------->=A0 Missed or lost in the network
=A0

ASPAC=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------------->=A0 = Processes ASPAC and sends ASPAC_ACK

=A0

Move ASP to

ACTIVE state=A0=A0=A0=A0=A0 <-------------=A0=A0=A0ASPAC_ACK

=A0

SCTP-SACK

for ASPAC_ACK=A0 ------------->=A0 Missed or lost again in the netw= ork

=A0

Move ASP to

INACTIVE state=A0=A0=A0<-------------=A0=A0=A0SCTP layer at SGP ret= ransmits the ASPUP_ACK, ASPAC_ACK=A0because of lost SACKs.

because of

ASPUP_ACK

in ACTIVE state

=A0

SCTP-SACK=A0=A0=A0=A0=A0=A0=A0 ------------->=A0 Reached the SCTP l= ayer of SGP

=A0

In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE= state whereas it is not the case.=A0 Since ASP is in INACTIVE state, all t= he data packets that were sent by SGP will be dropped (without sending any = error message back to network).=A0 The above problem will lead to a potenti= al message loss in the network.

=A0

Considering the above behavior, I think the state machine should be tu= ned accordingly.

=A0

Please pass on the comments on this.

=A0

Thanks & Regards,
Naveen.

-----I= nline Attachment Follows-----

_______________________________________________
Sigtran mailing lis= t
Sigtran@ietf.org
https://www.ietf.org/mailm= an/listinfo/sigtran

--0016e647167c968a3e0495ba0d30-- From bidulock@openss7.org Tue Nov 23 07:54:10 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 A3DC73A694F for ; Tue, 23 Nov 2010 07:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpIHN69JJ3pW for ; Tue, 23 Nov 2010 07:54:09 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 89DA03A6949 for ; Tue, 23 Nov 2010 07:54:09 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oANFt3co031196; Tue, 23 Nov 2010 08:55:03 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oANFt3cG022449; Tue, 23 Nov 2010 08:55:03 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id oANFt3E2022448; Tue, 23 Nov 2010 08:55:03 -0700 Date: Tue, 23 Nov 2010 08:55:03 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Message-ID: <20101123155503.GA22245@openss7.org> Mail-Followup-To: Ilie Glib , ?????????????? ?????????? , sigtran@ietf.org References: <53078B21B5DDA14BA1E89B400224A335021A87DA@SGSIEXC017.nsn-intra.net> <4CE80DC0.90803@gmail.com> <20101120220214.GA26962@openss7.org> <20101122150336.GA31624@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.18 (2008-05-17) Cc: sigtran@ietf.org Subject: Re: [Sigtran] sending ASP UP in IPSP SE 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, 23 Nov 2010 15:54:10 -0000 Ilie, Ilie Glib wrote: (Tue, 23 Nov 2010 10:55:37) > > As Tolga puts it well, at one IPSP, there is a 1:1:1 relationship > > between an AS (local concept) and RC and an RK. Same at the other. > > The RCs are the same and the RK's are symmetric (both define the > > signalling relation from the view at only one end). If you know > > one RK you know the other. Each end defines an AS (without relay) > > and both form one signalling relation. > > > > --brian Yup. One AS, one RC, one RK (symmetric). --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From adi.aquarian@gmail.com Tue Nov 23 07:55: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 A55413A6979 for ; Tue, 23 Nov 2010 07:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, NORMAL_HTTP_TO_IP=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 ADtWLr6sQZkX for ; Tue, 23 Nov 2010 07:55:13 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E4CAA3A6949 for ; Tue, 23 Nov 2010 07:55:12 -0800 (PST) Received: by fxm9 with SMTP id 9so28619fxm.31 for ; Tue, 23 Nov 2010 07:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=XfwebWLrAF9uCCI5KAdhlgy1njrQjiYeIiC3fxtJi+g=; b=OzMQU/U+JU2oMwlKaNk97/UAbn+yzsOzNkxi3/1p1bORWhsXjIZH4Fp0yeWY9YB81i IXSmnbv1uIMnEmr4jylgB9tS7afpGFFfV/PVD3c3Hun739YPVLoVrIoUcqW1KjPEAtC8 lRMykKlY7/S8wTEa5T2QxqW9Z8VZwhh4dza0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=LrXsbeadm8O07tuGG7ylY9+u1RFzPYPRLzNDjays5n+O2tZZ3aDByhZsCJ0gZveFNv a3sl5OfQ6jm11xAw1dQ8lckesgLZAiuFXV56s2cP8brV42TpyRr7snT2QB/m6wFX3gQd +qidYzZbrCqBZNsBIbZ+N3xx0z2Swx5WYLZq4= Received: by 10.223.122.133 with SMTP id l5mr5519466far.52.1290527769956; Tue, 23 Nov 2010 07:56:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.115.147 with HTTP; Tue, 23 Nov 2010 07:55:49 -0800 (PST) In-Reply-To: References: <681618.98422.qm@web30002.mail.mud.yahoo.com> From: Aditya Sehgal Date: Tue, 23 Nov 2010 21:25:49 +0530 Message-ID: To: Naveen Kottapalli Content-Type: multipart/alternative; boundary=001636c5a5674d123f0495ba691a Cc: sigtran@ietf.org Subject: Re: [Sigtran] Something improper with ASP state change procedures. X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 15:55:14 -0000 --001636c5a5674d123f0495ba691a Content-Type: text/plain; charset=ISO-8859-1 Naveen, The M3UA layer at the ASP will NOT see those re-transmissions. The SCTP layer would know that these are re-transmissions (as the TSN would be the same) and therefore will not pass those messages to M3UA. So, in the scenario you describe, the state at the ASP would still be ACTIVE. Regards, Aditya On Tue, Nov 23, 2010 at 9:00 PM, Naveen Kottapalli wrote: > The previous state was INACTIVE. So, the ASP will be moved back to > INACTIVE instead of reactivating. Is my assumption right? > > Yours, > Naveen. > > > On 23 November 2010 14:46, Dario Filjar wrote: > >> Hi Naveen, >> >> it seems that ASP does not behave correctly after reception of out-of-blue >> ASP Up Ack message. >> According to RFC4666, section 4.3.4.1: >> >> "If the ASP receives an unexpected ASP Up Ack message, the ASP should >> consider itself in the ASP-INACTIVE state. If the ASP was not in the >> ASP-INACTIVE state, it should send an Error message and then initate >> procedures to return to its previos state." >> >> So in your case, ASP shall initiate ASP Active procedure again after which >> it will align the state with SGP. >> >> BR Dario >> >> >> --- On *Tue, 11/23/10, Naveen Kottapalli * wrote: >> >> >> From: Naveen Kottapalli >> Subject: [Sigtran] Something improper with ASP state change procedures. >> To: sigtran@ietf.org >> Date: Tuesday, November 23, 2010, 3:36 PM >> >> >> Hi All, >> >> We are seeing some strange in the M3UA ASP state change procedures. >> Please find the description of the problem below. >> >> ASP SGP >> ======================================= >> ASPUP --------------> Processes ASPUP and sends ASPUP_ACK >> >> Move ASP to >> INACTIVE state <------------- ASPUP_ACK >> >> SCTP-SACK >> for ASPUP_ACK -------------> Missed or lost in the network >> >> ASPAC --------------> Processes ASPAC and sends ASPAC_ACK >> >> Move ASP to >> ACTIVE state <------------- ASPAC_ACK >> >> SCTP-SACK >> for ASPAC_ACK -------------> Missed or lost again in the network >> >> Move ASP to >> INACTIVE state <------------- SCTP layer at SGP retransmits the >> ASPUP_ACK, ASPAC_ACK because of lost SACKs. >> because of >> ASPUP_ACK >> in ACTIVE state >> >> SCTP-SACK -------------> Reached the SCTP layer of SGP >> >> In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE >> state whereas it is not the case. Since ASP is in INACTIVE state, all the >> data packets that were sent by SGP will be dropped (without sending any >> error message back to network). The above problem will lead to a potential >> message loss in the network. >> >> Considering the above behavior, I think the state machine should be tuned >> accordingly. >> >> Please pass on the comments on this. >> >> Thanks & Regards, >> Naveen. >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran >> >> >> > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > > -- There are only 10 type of people in this World...Those who understand binary and those who dont --001636c5a5674d123f0495ba691a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Naveen,

The M3UA layer at the ASP will NOT see those re-transmissions. = The SCTP layer would know that these are re-transmissions (as the TSN would= be the same) and therefore will not pass those messages to M3UA. So, in th= e scenario you describe, the state at the ASP would still be ACTIVE.

Regards,

Aditya

On Tue, Nov 23, 2010 at 9:00 PM, Naveen Kottapalli &= lt;naveen.sarma@gmail.com>= wrote:

The previous state was INACTIVE.=A0 So= , the ASP will be moved back to INACTIVE instead of reactivating.=A0 Is my = assumption right?

Yours,
Naveen.

On 23 November 2010 14:46, Dario Filjar <d= ario_filjar@yahoo.com> wrote:

Hi Naveen,

=A0

it seems that ASP does not behave correctly after reception of out-of-= blue ASP Up Ack message.

According to RFC4666, section 4.3.4.1:

=A0

"If the ASP receives an unexpected ASP Up Ack message, the ASP sh= ould consider itself in the ASP-INACTIVE state. If the ASP was not in the A= SP-INACTIVE state, it should send an Error message and then initate procedu= res to return to its previos state."

=A0

So in your case, ASP shall initiate ASP Active procedure again after w= hich it will align the state with SGP.

=A0

BR Dario

--- On Tue, 11/23/10, Naveen Kottapalli <naveen.sarma@gmail.com&= gt; wrote:

From: Naveen Kottapalli <naveen.sarma@gmail.com>
Subject: [Sig= tran] Something improper with ASP state change procedures.
To: sigtran@ietf.org
Date: Tuesday, November 23, 2010, 3:36 PM=20

Hi All,

=A0

We are seeing some=A0strange in the M3UA ASP state change procedures.= =A0 Please find the description of the problem below.

=A0

ASP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SGP

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

ASPUP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------------->=A0 = Processes ASPUP and sends ASPUP_ACK

=A0

Move ASP to

INACTIVE state=A0=A0=A0<-------------=A0=A0=A0ASPUP_ACK

=A0

SCTP-SACK

for ASPUP_ACK=A0 ------------->=A0 Missed or lost in the network
=A0

ASPAC=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------------->=A0 = Processes ASPAC and sends ASPAC_ACK

=A0

Move ASP to

ACTIVE state=A0=A0=A0=A0=A0 <-------------=A0=A0=A0ASPAC_ACK

=A0

SCTP-SACK

for ASPAC_ACK=A0 ------------->=A0 Missed or lost again in the netw= ork

=A0

Move ASP to

INACTIVE state=A0=A0=A0<-------------=A0=A0=A0SCTP layer at SGP ret= ransmits the ASPUP_ACK, ASPAC_ACK=A0because of lost SACKs.

because of

ASPUP_ACK

in ACTIVE state

=A0

SCTP-SACK=A0=A0=A0=A0=A0=A0=A0 ------------->=A0 Reached the SCTP l= ayer of SGP

=A0

In the above behavior the M3UA at SGP thinks that the ASP is in ACTIVE= state whereas it is not the case.=A0 Since ASP is in INACTIVE state, all t= he data packets that were sent by SGP will be dropped (without sending any = error message back to network).=A0 The above problem will lead to a potenti= al message loss in the network.

=A0

Considering the above behavior, I think the state machine should be tu= ned accordingly.

=A0

Please pass on the comments on this.

=A0

Thanks & Regards,
Naveen.

-----I= nline Attachment Follows-----

_______________________________________________
Sigtran mailing lis= t
Sigtran@ietf.org
https://www.ietf.org/mailm= an/listinfo/sigtran

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

--
There are only 10 t= ype of people in this World...Those who understand binary and those who don= t

--001636c5a5674d123f0495ba691a-- From David.Laight@ACULAB.COM Tue Nov 23 08:12:10 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 3DB4328C128 for ; Tue, 23 Nov 2010 08:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_BAD_LINEBREAK=0.5, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRLS5ve5kZey for ; Tue, 23 Nov 2010 08:12:09 -0800 (PST) Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by core3.amsl.com (Postfix) with SMTP id 61CD628C124 for ; Tue, 23 Nov 2010 08:12:08 -0800 (PST) Received: (qmail 7600 invoked from network); 23 Nov 2010 16:13:05 -0000 Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 23 Nov 2010 16:13:05 -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 06116-02 for ; Tue, 23 Nov 2010 16:13:03 +0000 (GMT) Received: (qmail 7532 invoked by uid 599); 23 Nov 2010 16:13:03 -0000 Received: from unknown (HELO saturn3.Aculab.com) (10.202.163.5) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Tue, 23 Nov 2010 16:13:03 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8B29.298B88D0" Date: Tue, 23 Nov 2010 16:12:01 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Something improper with ASP state change procedures. Thread-Index: AcuLG7qeeaWEYv4zQgS0Pkmk/H9kVwAC5aXA From: "David Laight" To: X-Virus-Scanned: by iCritical at mx0.aculab.com Subject: Re: [Sigtran] Something improper with ASP state change procedures. X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: ,