From sigtran-bounces@ietf.org Wed Jan 04 00:18:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu128-00046u-JS; Wed, 04 Jan 2006 00:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu127-00046f-0L for sigtran@megatron.ietf.org; Wed, 04 Jan 2006 00:17:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07023 for ; Wed, 4 Jan 2006 00:16:44 -0500 (EST) From: srivastava.rishi@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu17V-0007gD-DI for sigtran@ietf.org; Wed, 04 Jan 2006 00:23:35 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 4B721205F6 for ; Wed, 4 Jan 2006 10:33:38 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 2DF3F205E1 for ; Wed, 4 Jan 2006 10:33:38 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 10:47:40 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jan 2006 10:47:39 +0530 Message-ID: <897DA809E857CD40A8419CF517948E210173825B@blr-k1-msg.wipro.com> Thread-Topic: no of segments limit on CODT Thread-Index: AcYQ7i5Ugwu2YTXNSqCpo07LDnK1rQ== To: X-OriginalArrivalTime: 04 Jan 2006 05:17:40.0506 (UTC) FILETIME=[2F18E7A0:01C610EE] X-Spam-Score: 0.3 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Subject: [Sigtran] no of segments limit on CODT X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1502704510==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1502704510== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C610EE.2ED7CF64" This is a multi-part message in MIME format. ------_=_NextPart_001_01C610EE.2ED7CF64 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 While segmenting CLDT message there is a limit on number of segments a message can be broken into (A maximum of 16 segments can be sent for one N-UNITDATA request primitive) .=20 =20 Is the same limit applicable for CODT message as well,=20 =20 Thanks,=20 Rishi Srivastava Wipro Technologies Bangalore =20 =20 ------_=_NextPart_001_01C610EE.2ED7CF64 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

While segmenting CLDT = message there is a limit on number of segments a message can be broken into =  (A maximum of 16 segments

can be sent for one = N-UNITDATA request primitive) .

 

Is the same limit = applicable for CODT message as well,

 

Thanks, =

Rishi = Srivastava

Wipro = Technologies

Bangalore<= /p>

 

 

------_=_NextPart_001_01C610EE.2ED7CF64-- --===============1502704510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1502704510==-- From sigtran-bounces@ietf.org Wed Jan 04 00:53:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu1ad-0001zc-Nj; Wed, 04 Jan 2006 00:53:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu1ac-0001zX-8K for sigtran@megatron.ietf.org; Wed, 04 Jan 2006 00:53:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10159 for ; Wed, 4 Jan 2006 00:52:23 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[+aJyfcAzOVD6Jz7LuJQaS7UHO89xTZjM]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu1g0-0000J0-Ml for sigtran@ietf.org; Wed, 04 Jan 2006 00:59:15 -0500 Received: from ns.pigworks.openss7.net (IDENT:iCdgiZsPOJpCl5pgPjsaSTkhaORvJdSk@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k045rFw04346; Tue, 3 Jan 2006 22:53:15 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k045rEg17253; Tue, 3 Jan 2006 22:53:14 -0700 Date: Tue, 3 Jan 2006 22:53:14 -0700 From: "Brian F. G. Bidulock" To: srivastava.rishi@wipro.com Subject: Re: [Sigtran] no of segments limit on CODT Message-ID: <20060103225314.A17217@openss7.org> Mail-Followup-To: srivastava.rishi@wipro.com, sigtran@ietf.org References: <897DA809E857CD40A8419CF517948E210173825B@blr-k1-msg.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <897DA809E857CD40A8419CF517948E210173825B@blr-k1-msg.wipro.com>; from srivastava.rishi@wipro.com on Wed, Jan 04, 2006 at 10:47:39AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org srivastava.rishi, No. --brian srivastava.rishi@wipro.com wrote: (Wed, 04 Jan 2006 10:47:39) > > Hi, > > > While segmenting CLDT message there is a limit on number of segments a > message can be broken into (A maximum of 16 segments > > can be sent for one N-UNITDATA request primitive) . > > > Is the same limit applicable for CODT message as well, > > > Thanks, > > Rishi Srivastava > > Wipro Technologies > > Bangalore > _______________________________________________ > 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 From sigtran-bounces@ietf.org Thu Jan 05 03:40:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQfx-0005ad-HU; Thu, 05 Jan 2006 03:40:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQfu-0005aY-Ae for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 03:40:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11858 for ; Thu, 5 Jan 2006 03:39:30 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuQlX-0000hD-Qb for sigtran@ietf.org; Thu, 05 Jan 2006 03:46:37 -0500 Received: by nproxy.gmail.com with SMTP id c29so1092501nfb for ; Thu, 05 Jan 2006 00:40:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dFdINvDPQs90Lwp+ScqDcVewsL/Qz3hEi7CvBXbVk1Al+yxfyjSyQLLSRMUH7sb1Tf/rYGgIZou8MD+nPL5WGl9sI5ISzQQ/SeONvrj5JcaUVzVJXP2RcEQEddRHGmXOTmZOGFloSxJoTJybfi2reciL4WnhUUgMjh7r1D11kRE= Received: by 10.48.254.13 with SMTP id b13mr675137nfi; Thu, 05 Jan 2006 00:40:42 -0800 (PST) Received: by 10.48.1.13 with HTTP; Thu, 5 Jan 2006 00:40:42 -0800 (PST) Message-ID: <17b146d60601050040y3c09266kdcc3c10b944e49e4@mail.gmail.com> Date: Thu, 5 Jan 2006 09:40:42 +0100 From: Ilie Glib To: bidulock@openss7.org, srivastava.rishi@wipro.com, sigtran@ietf.org Subject: Re: [Sigtran] no of segments limit on CODT In-Reply-To: <20060103225314.A17217@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <897DA809E857CD40A8419CF517948E210173825B@blr-k1-msg.wipro.com> <20060103225314.A17217@openss7.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Brian, I guess you meant, that CODT is not segmented (at least it is not visible to SUA, since segmentation is done by SCTP). When interworking with SS7, there cannot be more than 16 CODT representing one SCCP/SUA-User message (in both directions on the SGP-ASP interface). Regards Ilie On 1/4/06, Brian F. G. Bidulock wrote: > srivastava.rishi, > > No. > > --brian > > srivastava.rishi@wipro.com wrote: (Wed, 04 Jan 20= 06 10:47:39) > > > > Hi, > > > > > > While segmenting CLDT message there is a limit on number of segments= a > > message can be broken into (A maximum of 16 segments > > > > can be sent for one N-UNITDATA request primitive) . > > > > > > Is the same limit applicable for CODT message as well, > > > > > > Thanks, > > > > Rishi Srivastava > > > > Wipro Technologies > > > > Bangalore > > > _______________________________________________ > > 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 > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 05 03:53:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQs0-0000gI-Fe; Thu, 05 Jan 2006 03:53:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQry-0000gD-O2 for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 03:53:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13359 for ; Thu, 5 Jan 2006 03:51:58 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuQxb-00012T-FK for sigtran@ietf.org; Thu, 05 Jan 2006 03:59:05 -0500 Received: from nproxy.gmail.com ([64.233.182.194]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EuQrw-0002LF-BW for sigtran@ietf.org; Thu, 05 Jan 2006 03:53:12 -0500 Received: by nproxy.gmail.com with SMTP id l37so1143510nfc for ; Thu, 05 Jan 2006 00:52:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=OIW3KvjwL82jjPYN2ZMP7wTK+xZgd+SWPMOaXcRihwMLHBXDmipYP9+TeAPZnRzUGoW0+r4YEyu4203cezjijxFMfUDomWmN1YA0VqkxrPn6OgbpHAV24qj+U3CAOT0TUQZEk4RpZmdGuq0lbQNVnDTz7nCpc9xcTqOdLYsL6zc= Received: by 10.48.247.14 with SMTP id u14mr674397nfh; Thu, 05 Jan 2006 00:51:52 -0800 (PST) Received: by 10.48.1.13 with HTTP; Thu, 5 Jan 2006 00:51:52 -0800 (PST) Message-ID: <17b146d60601050051r8004a3ga173b2b933e41a55@mail.gmail.com> Date: Thu, 5 Jan 2006 09:51:52 +0100 From: Ilie Glib To: SIGTRAN MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: [Sigtran] Responses to SGPs X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Folks Section 1.5.2. Address Mapping at the ASP says An ASP routes responses to the SGP that it received messages from. The response will utilize the routing context from the received messages. What messages are meant by "response" in this context? I assume these are response messages triggered by SUA layer itself (like CLDR, ERROR, etc.). Response messages sent by SCCP/SUA users can be sent to any SGP, unless they use CO Service. Apropos, how can it be guaranted that CO messages go to the same SGP? Shall there be a DRN label per SGP? Thank you in advance -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 05 04:00:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQzA-00033n-GZ; Thu, 05 Jan 2006 04:00:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQz8-00032S-P6 for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 04:00:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14006 for ; Thu, 5 Jan 2006 03:59:22 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[lTeWeSmEzB8ofXA+sDr6TaStWe4khWx6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuR4j-0001Pz-TX for sigtran@ietf.org; Thu, 05 Jan 2006 04:06:29 -0500 Received: from ns.pigworks.openss7.net (IDENT:zOWI4irTYbA0Tp+Fczz2HtFmh86eJWJ2@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0590Hw02656; Thu, 5 Jan 2006 02:00:18 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0590Hu07590; Thu, 5 Jan 2006 02:00:17 -0700 Date: Thu, 5 Jan 2006 02:00:17 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] no of segments limit on CODT Message-ID: <20060105020017.A4946@openss7.org> Mail-Followup-To: Ilie Glib , srivastava.rishi@wipro.com, sigtran@ietf.org References: <897DA809E857CD40A8419CF517948E210173825B@blr-k1-msg.wipro.com> <20060103225314.A17217@openss7.org> <17b146d60601050040y3c09266kdcc3c10b944e49e4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601050040y3c09266kdcc3c10b944e49e4@mail.gmail.com>; from ilie.glib@googlemail.com on Thu, Jan 05, 2006 at 09:40:42AM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, I think that you are confusing CODT and CLDT. There is no limits on the number of Service Interface Data Units (SIDUs) sent by the user to represent a single Service Data Unit (SDU) for the CODT message. The "more bit" in the "Sequence Number" parameter, when set in the CODT, indicates that the next SIDU (Data) belongs to the same SDU. ...and there is no limit. > Is the same limit applicable for CODT message as well, So, the answer to your question is "No." Or, maybe I should have said read X.213, Q.711 and then RFC 3868. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 05 04:18:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRDy-0000Gr-3f; Thu, 05 Jan 2006 04:15:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRDu-0000Gc-Vo for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 04:15:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15420 for ; Thu, 5 Jan 2006 04:14:37 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[FmF0RACL1cLb5ORmBwQb/vtWlisbPXQx]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuRJY-0001w1-Vy for sigtran@ietf.org; Thu, 05 Jan 2006 04:21:45 -0500 Received: from ns.pigworks.openss7.net (IDENT:p+Z+DVsjINAxJTcVrzsB7Oy/oFrjTbId@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k059Fqw02899; Thu, 5 Jan 2006 02:15:52 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k059Fqq07886; Thu, 5 Jan 2006 02:15:52 -0700 Date: Thu, 5 Jan 2006 02:15:51 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] Responses to SGPs Message-ID: <20060105021551.B4946@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601050051r8004a3ga173b2b933e41a55@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601050051r8004a3ga173b2b933e41a55@mail.gmail.com>; from ilie.glib@googlemail.com on Thu, Jan 05, 2006 at 09:51:52AM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, Please see comments below... Ilie Glib wrote: (Thu, 05 Jan 2006 09:51:52) > Hello Folks > > Section > 1.5.2. Address Mapping at the ASP > > says > > An ASP routes responses to the SGP that it received messages from. > The response will utilize the routing context from the received > messages. > > > What messages are meant by "response" in this context? Gee, probably messages sent by the AS. > > I assume these are response messages triggered by SUA layer itself > (like CLDR, ERROR, etc.). Response messages sent by SCCP/SUA users can > be sent to any SGP, unless they use CO Service. SUA users do not choose the SGP, the SUA layer at the ASP does. > > Apropos, how can it be guaranted that CO messages go to the same SGP? > Shall there be a DRN label per SGP? The passage just says that the ASP routes back to the same SGP. It does not mean that the earth will stop in its rotation if the ASP uses another SGP for which it is active (or another SG for that matter). Switching SGPs is more complicated. See draft-bidulock-sigtran-corid-03.txt. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 05 10:59:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXWl-0002lt-Ai; Thu, 05 Jan 2006 10:59:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXWi-0002lL-GX for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 10:59:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00896 for ; Thu, 5 Jan 2006 10:58:29 -0500 (EST) Received: from web35415.mail.mud.yahoo.com ([66.163.179.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuXcM-0007Z4-FB for sigtran@ietf.org; Thu, 05 Jan 2006 11:05:39 -0500 Received: (qmail 62589 invoked by uid 60001); 5 Jan 2006 15:59:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1g69xa+jPbOmEBl3oDIj4f/8gUcKZuPYAMx2RipF98o24hSctNvQSilK4zBiT9ZG+5hHwu9rWZ00qeYIBMack+nK99v9QsuK1jY8c1kKeMd8O99S7By+oLzPWrM1a9/BSpdI4mWoZrkjifG0BWIAJAgzgAEbBBojmQONOZleIVw= ; Message-ID: <20060105155927.62587.qmail@web35415.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35415.mail.mud.yahoo.com via HTTP; Thu, 05 Jan 2006 07:59:27 PST Date: Thu, 5 Jan 2006 07:59:27 -0800 (PST) From: Stanislav Ivanovich To: SIGTRAN MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sigtran] Transfer of N-STATE_request in SUA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0816165968==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0816165968== Content-Type: multipart/alternative; boundary="0-24507395-1136476767=:61434" Content-Transfer-Encoding: 8bit --0-24507395-1136476767=:61434 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello SIGTRAN community, In standard SCCP there is a primitive called N-STATE_request which transfers management information (in-service/out-of-service) from SCCP-user to SCCP. How is this information conveyed between SGP and ASP? Is ASP allowed to send DUNA message to SGP by containing SSN (thus having DUNA corresponding to N-STATE primitive)? regards/ Stanislav Ivanovich --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-24507395-1136476767=:61434 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello SIGTRAN community,
 
In standard SCCP there is a primitive called N-STATE_request which transfers management information (in-service/out-of-service) from SCCP-user to SCCP.
 
How is this information conveyed between SGP and ASP?
Is ASP allowed to send DUNA message to SGP by containing SSN (thus having DUNA corresponding to N-STATE primitive)?
 
regards/ Stanislav Ivanovich

Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-24507395-1136476767=:61434-- --===============0816165968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0816165968==-- From sigtran-bounces@ietf.org Thu Jan 05 11:22:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXsO-00038K-9w; Thu, 05 Jan 2006 11:22:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXsM-00038D-Vj for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 11:22:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04293 for ; Thu, 5 Jan 2006 11:20:52 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[sz3arjRtpAUuVD5Piqyzx4873sAlgwQK]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuXy4-0008U6-7y for sigtran@ietf.org; Thu, 05 Jan 2006 11:28:01 -0500 Received: from ns.pigworks.openss7.net (IDENT:RsxupeMEyH51FGoFud5TzsTZHKCL28Ks@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k05GM1w10523; Thu, 5 Jan 2006 09:22:01 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k05GM0u06711; Thu, 5 Jan 2006 09:22:00 -0700 Date: Thu, 5 Jan 2006 09:22:00 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA Message-ID: <20060105092200.A6576@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060105155927.62587.qmail@web35415.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060105155927.62587.qmail@web35415.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Thu, Jan 05, 2006 at 07:59:27AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. --brian Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > Hello SIGTRAN community, > > > > In standard SCCP there is a primitive called N-STATE_request which > transfers management information (in-service/out-of-service) from > SCCP-user to SCCP. > > > > How is this information conveyed between SGP and ASP? > > Is ASP allowed to send DUNA message to SGP by containing SSN (thus > having DUNA corresponding to N-STATE primitive)? > > > > regards/ Stanislav Ivanovich > _________________________________________________________________ > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > References > > 1. http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.com/broadband/ > _______________________________________________ > 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 From sigtran-bounces@ietf.org Thu Jan 05 11:45:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYFI-0001EL-LL; Thu, 05 Jan 2006 11:45:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYFH-0001DR-8S for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 11:45:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07375 for ; Thu, 5 Jan 2006 11:44:31 -0500 (EST) Received: from web35412.mail.mud.yahoo.com ([66.163.179.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuYKx-00015H-Sl for sigtran@ietf.org; Thu, 05 Jan 2006 11:51:40 -0500 Received: (qmail 37259 invoked by uid 60001); 5 Jan 2006 16:45:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lGUn+PybYJkHoAgSqMaTIdLm8KjxYE6HTYHaNRnPmODDoMOzyDxL5PRd1zwAVjbLCMw9nW3AfmRaYyUHUsM7mTwdboYvfGo1Ydv5cucLg0gcMq7zXlUTfOtwbS2ZCIV4R2V26FEua02cKLIzTKjFSOkuetlLIp4k60m2PNz3m+4= ; Message-ID: <20060105164535.37257.qmail@web35412.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35412.mail.mud.yahoo.com via HTTP; Thu, 05 Jan 2006 08:45:35 PST Date: Thu, 5 Jan 2006 08:45:35 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA To: SIGTRAN In-Reply-To: <20060105092200.A6576@openss7.org> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1683774423==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1683774423== Content-Type: multipart/alternative; boundary="0-621700312-1136479535=:35766" Content-Transfer-Encoding: 8bit --0-621700312-1136479535=:35766 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Brian, You didn't understand my question. You refer to section 4.5.1. which is related to handling of SSNM messages at SGP. I asked about N_STATE_request (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP to SCCP at SGP. I would appreciate answer to my questions with YES or NO. regards/ Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. --brian Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > Hello SIGTRAN community, > > > > In standard SCCP there is a primitive called N-STATE_request which > transfers management information (in-service/out-of-service) from > SCCP-user to SCCP. > > > > How is this information conveyed between SGP and ASP? > > Is ASP allowed to send DUNA message to SGP by containing SSN (thus > having DUNA corresponding to N-STATE primitive)? > > > > regards/ Stanislav Ivanovich > _________________________________________________________________ > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > References > > 1. http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.com/broadband/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-621700312-1136479535=:35766 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Brian,
 
You didn't understand my question. You refer to section 4.5.1. which is related to handling of SSNM messages at SGP. I asked about N_STATE_request (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP to SCCP at SGP.
 
I would appreciate answer to my questions with YES or NO.
 
regards/ Stanislav Ivanovich


"Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
Stanislav,

Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE.

--brian

Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27)
>
> Hello SIGTRAN community,
>
>
>
> In standard SCCP there is a primitive called N-STATE_request which
> transfers management information (in-service/out-of-service) from
> SCCP-user to SCCP.
>
>
>
> How is this information conveyed between SGP and ASP?
>
> Is ASP allowed to send DUNA message to SGP by containing SSN (thus
> having DUNA corresponding to N-STATE primitive)?
>
>
>
> regards/ Stanislav Ivanovich
> _________________________________________________________________
>
> [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less
>
> References
>
> 1. http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.com/broadband/

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


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

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-621700312-1136479535=:35766-- --===============1683774423== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1683774423==-- From sigtran-bounces@ietf.org Thu Jan 05 11:52:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYM0-0004cV-6A; Thu, 05 Jan 2006 11:52:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYLy-0004cQ-Tx for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 11:52:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08540 for ; Thu, 5 Jan 2006 11:51:27 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[h9IhxlKw3FwYApkcaitHmvh6wuXjvrE9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYRg-0001V2-Hs for sigtran@ietf.org; Thu, 05 Jan 2006 11:58:38 -0500 Received: from ns.pigworks.openss7.net (IDENT:nMFGV6mySIOBPzchItpo14O3PCoo/g5g@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k05Gqdw11004; Thu, 5 Jan 2006 09:52:39 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k05Gqd006993; Thu, 5 Jan 2006 09:52:39 -0700 Date: Thu, 5 Jan 2006 09:52:38 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA Message-ID: <20060105095238.A6977@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060105092200.A6576@openss7.org> <20060105164535.37257.qmail@web35412.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060105164535.37257.qmail@web35412.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Thu, Jan 05, 2006 at 08:45:35AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, You didn't read section 3.4. --brian Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 08:45:35) > > Brian, > > > > You didn't understand my question. You refer to section 4.5.1. which > is related to handling of SSNM messages at SGP. I asked about > N_STATE_request (not N_STATE_indication) which is supposed to be sent > from SCCP-user at ASP to SCCP at SGP. > > > > I would appreciate answer to my questions with YES or NO. > > > > regards/ Stanislav Ivanovich > > "Brian F. G. Bidulock" wrote: > > Stanislav, > Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. > --brian > Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > > > Hello SIGTRAN community, > > > > > > > > In standard SCCP there is a primitive called N-STATE_request > which > > transfers management information (in-service/out-of-service) from > > SCCP-user to SCCP. > > > > > > > > How is this information conveyed between SGP and ASP? > > > > Is ASP allowed to send DUNA message to SGP by containing SSN > (thus > > having DUNA corresponding to N-STATE primitive)? > > > > > > > > regards/ Stanislav Ivanovich > > _________________________________________________________________ > > > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or > less > > > > References > > > > 1. > http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo > .yahoo.com/broadband/ > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _________________________________________________________________ > > Yahoo! Photos > Ring in the New Year with [1]Photo Calendars. Add photos, events, > holidays, whatever. > > References > > 1. http://us.rd.yahoo.com/mail_us/taglines/photos/*http://pg.photos.yahoo.com/ph//page?.file=calendar_splash.html&.dir= > _______________________________________________ > 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 From sigtran-bounces@ietf.org Thu Jan 05 11:53:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYMk-00052I-Re; Thu, 05 Jan 2006 11:53:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYMj-00052A-5t for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 11:53:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08685 for ; Thu, 5 Jan 2006 11:52:13 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYSQ-0001Vz-6J for sigtran@ietf.org; Thu, 05 Jan 2006 11:59:23 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 8B23CF851A for ; Thu, 5 Jan 2006 11:52:55 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k05Gqrud015991 for ; Thu, 5 Jan 2006 11:52:55 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA Date: Thu, 5 Jan 2006 11:34:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060105164535.37257.qmail@web35412.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, The answer to your question is "No". The behavior you are mentioning is controlled with ASPAC/ASPIA, i.e. with AS state. Thanks, Tolga -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Thursday, January 05, 2006 11:46 AM To: SIGTRAN Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA Brian, You didn't understand my question. You refer to section 4.5.1. which is related to handling of SSNM messages at SGP. I asked about N_STATE_request (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP to SCCP at SGP. I would appreciate answer to my questions with YES or NO. regards/ Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. --brian Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > Hello SIGTRAN community, > > > > In standard SCCP there is a primitive called N-STATE_request which > transfers management information (in-service/out-of-service) from > SCCP-user to SCCP. > > > > How is this information conveyed between SGP and ASP? > > Is ASP allowed to send DUNA message to SGP by containing SSN (thus > having DUNA corresponding to N-STATE primitive)? > > > > regards/ Stanislav Ivanovich > _________________________________________________________________ > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > References > > 1. http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co m/broadband/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 05 12:19:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYh3-0006bI-5J; Thu, 05 Jan 2006 12:14:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYh0-0006YS-Fx for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 12:14:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11932 for ; Thu, 5 Jan 2006 12:13:11 -0500 (EST) Received: from web35414.mail.mud.yahoo.com ([66.163.179.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuYmh-0002Q4-3Q for sigtran@ietf.org; Thu, 05 Jan 2006 12:20:21 -0500 Received: (qmail 80160 invoked by uid 60001); 5 Jan 2006 17:14:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3bgRYk/Vd7VN7nYPIowwI5jTeDXOqYqXMmPQCCrvJbnji03l4RCOK5vLNb58Vb5u18KoyxJoZkXW9ZDer0YEvLbzbfM0pBt9jA5hnBj+RpsdPc2MPanbZ1gbL6m87h+vUldLHaxgK0dD0a4c+bY2fUovjuYMtbUDbHF0ySyCtb8= ; Message-ID: <20060105171414.80158.qmail@web35414.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35414.mail.mud.yahoo.com via HTTP; Thu, 05 Jan 2006 09:14:14 PST Date: Thu, 5 Jan 2006 09:14:14 -0800 (PST) From: Stanislav Ivanovich Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA To: SIGTRAN In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0690022232==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0690022232== Content-Type: multipart/alternative; boundary="0-1562712229-1136481254=:77386" Content-Transfer-Encoding: 8bit --0-1562712229-1136481254=:77386 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Tolga, Brian, Brian I read all the sections in the SUA and the reason why I am asking this question is that Tolga's answer below is the only way how a user is supposed to generate N-STATE_request for a particular SCCP subsystem. However I consider this fault in SUA specification for the following reasons: 1) there are no conceptual problems of having DUNA message containing N_STATE-request sent from ASP to SGP within a particular AS for the same reason why it is not problem of having N-STATE_request sent from SCCP-user to SCCP. 2) Using ASP TM messages for this management is very problematic since it actually says that it is not possible to independently manage several SCCP subsystems that are part of the same AS. It forces implementors to support multiple AS'es per signaling process just to have separate SCCP subsystems separately manageable! If you think otherwise why do you forbid sending DUNA from ASP to SGP which is to carry N-STATE_request fro independent SCCP subsystems that are part of the same AS? What is the problem of having this? regards/ Stanislav Ivanovich Tolga Asveren wrote: Stanislav, The answer to your question is "No". The behavior you are mentioning is controlled with ASPAC/ASPIA, i.e. with AS state. Thanks, Tolga -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Thursday, January 05, 2006 11:46 AM To: SIGTRAN Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA Brian, You didn't understand my question. You refer to section 4.5.1. which is related to handling of SSNM messages at SGP. I asked about N_STATE_request (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP to SCCP at SGP. I would appreciate answer to my questions with YES or NO. regards/ Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. --brian Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > Hello SIGTRAN community, > > > > In standard SCCP there is a primitive called N-STATE_request which > transfers management information (in-service/out-of-service) from > SCCP-user to SCCP. > > > > How is this information conveyed between SGP and ASP? > > Is ASP allowed to send DUNA message to SGP by containing SSN (thus > having DUNA corresponding to N-STATE primitive)? > > > > regards/ Stanislav Ivanovich > _________________________________________________________________ > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > References > > 1. http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co m/broadband/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-1562712229-1136481254=:77386 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Tolga, Brian,
 
Brian I read all the sections in the SUA and the reason why I am asking this question is that Tolga's answer below is the only way how a user is supposed to generate N-STATE_request for a particular SCCP subsystem.
 
However I consider this fault in SUA specification for the following reasons:
 
1) there are no conceptual problems of having DUNA message containing N_STATE-request sent from ASP to SGP within a particular AS for the same reason why it is not problem of having N-STATE_request sent from SCCP-user to SCCP.
 
2) Using ASP TM messages for this management is very problematic since it actually says that it is not possible to independently manage several SCCP subsystems that are part of the same AS. It forces implementors to support multiple AS'es per signaling process just to have separate SCCP subsystems separately manageable!!
 
If you think otherwise why do you forbid sending DUNA from ASP to SGP which is to carry N-STATE_request fro independent SCCP subsystems that are part of the same AS? What is the problem of having this?
 
regards/ Stanislav Ivanovich
 


Tolga Asveren <asveren@ulticom.com> wrote:
Stanislav,

The answer to your question is "No". The behavior you are mentioning is
controlled with ASPAC/ASPIA, i.e. with AS state.

Thanks,
Tolga


-----Original Message-----
From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of
Stanislav Ivanovich
Sent: Thursday, January 05, 2006 11:46 AM
To: SIGTRAN
Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA


Brian,

You didn't understand my question.! You refer to section 4.5.1. which is
related to handling of SSNM messages at SGP. I asked about N_STATE_request
(not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP
to SCCP at SGP.

I would appreciate answer to my questions with YES or NO.

regards/ Stanislav Ivanovich


"Brian F. G. Bidulock" wrote:
Stanislav,

Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE.

--brian

Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27)
>
> Hello SIGTRAN community,
>
>
>
> In standard SCCP there is a primitive called N-STATE_request which
> transfers management information (in-service/out-of-service) from
> SCCP-user to SCCP.
>
>
>
> How is this information conveyed between SGP and ASP?
>
> Is ASP allowed to send DUNA message to SGP by containing SSN (thus
> having DUNA corresponding to N-STA! TE primitive)?
>
>
>
> regards/ Stanislav Ivanovich
> _________________________________________________________________
>
> [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less
>
> References
>
> 1.
http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co
m/broadband/

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


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





Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays,
whatever.



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

Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-1562712229-1136481254=:77386-- --===============0690022232== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0690022232==-- From sigtran-bounces@ietf.org Thu Jan 05 13:08:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZXA-0004ny-0W; Thu, 05 Jan 2006 13:08:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZX8-0004nt-4z for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 13:08:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20306 for ; Thu, 5 Jan 2006 13:07:02 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZcq-0004it-JX for sigtran@ietf.org; Thu, 05 Jan 2006 13:14:13 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id FFFFF20DD6 for ; Thu, 5 Jan 2006 13:08:03 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k05I7w4L022188 for ; Thu, 5 Jan 2006 13:08:02 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA Date: Thu, 5 Jan 2006 12:49:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060105171414.80158.qmail@web35414.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Thursday, January 05, 2006 12:14 PM To: SIGTRAN Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA Tolga, Brian, Brian I read all the sections in the SUA and the reason why I am asking this question is that Tolga's answer below is the only way how a user is supposed to generate N-STATE_request for a particular SCCP subsystem. However I consider this fault in SUA specification for the following reasons: 1) there are no conceptual problems of having DUNA message containing N_STATE-request sent from ASP to SGP within a particular AS for the same reason why it is not problem of having N-STATE_request sent from SCCP-user to SCCP. 2) Using ASP TM messages for this management is very problematic since it actually says that it is not possible to independently manage several SCCP subsystems that are part of the same AS. It forces implementors to support multiple AS'es per signaling process just to have separate SCCP subsystems separately manageable!! [TOLGA]OTOH, one could argue that AS is an entity which becomes available/unavailable as a whole, i.e. if it has multiple subsystems, they should be in-service/out-of-service simultaneously. So, what you consider as problematic is IMO a direct consequence of the AS concept. If you think otherwise why do you forbid sending DUNA from ASP to SGP which is to carry N-STATE_request fro independent SCCP subsystems that are part of the same AS? What is the problem of having this? regards/ Stanislav Ivanovich Tolga Asveren wrote: Stanislav, The answer to your question is "No". The behavior you are mentioning is controlled with ASPAC/ASPIA, i.e. with AS state. Thanks, Tolga -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Thursday, January 05, 2006 11:46 AM To: SIGTRAN Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA Brian, You didn't understand my question.! You refer to section 4.5.1. which is related to handling of SSNM messages at SGP. I asked about N_STATE_request (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP to SCCP at SGP. I would appreciate answer to my questions with YES or NO. regards/ Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. --brian Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > Hello SIGTRAN community, > > > > In standard SCCP there is a primitive called N-STATE_request which > transfers management information (in-service/out-of-service) from > SCCP-user to SCCP. > > > > How is this information conveyed between SGP and ASP? > > Is ASP allowed to send DUNA message to SGP by containing SSN (thus > having DUNA corresponding to N-STA! TE primitive)? > > > > regards/ Stanislav Ivanovich > _________________________________________________________________ > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > References > > 1. http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co m/broadband/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran Yahoo! DSL Something to write home about. Just $16.99/mo. or less _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 05 13:33:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZvF-0003IG-2i; Thu, 05 Jan 2006 13:33:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZvC-0003I8-J1 for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 13:33:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23773 for ; Thu, 5 Jan 2006 13:31:54 -0500 (EST) Received: from web35415.mail.mud.yahoo.com ([66.163.179.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eua0v-0005dS-I3 for sigtran@ietf.org; Thu, 05 Jan 2006 13:39:06 -0500 Received: (qmail 42522 invoked by uid 60001); 5 Jan 2006 18:32:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aDRq99g0Bv4r7AHF6wSAVBoSyuLWF9pHgtrMETrNe2HyPUZU+5zfu5uj5lCYIPUbkrmm7aU4pVhWqewByhRYPkmX9lvETKlgGS5dR239RxmHLMjfs3EG4TFvTy7bYnhg6wp6QVz8bbbHz6I8I2Mf8eb7J6YcQGaf1kFBgLCAjH4= ; Message-ID: <20060105183221.42520.qmail@web35415.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35415.mail.mud.yahoo.com via HTTP; Thu, 05 Jan 2006 10:32:21 PST Date: Thu, 5 Jan 2006 10:32:21 -0800 (PST) From: Stanislav Ivanovich Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA To: SIGTRAN In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0478684235==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0478684235== Content-Type: multipart/alternative; boundary="0-1727717539-1136485941=:38936" Content-Transfer-Encoding: 8bit --0-1727717539-1136485941=:38936 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Tolga, I disagree that not having possibility of managing separate SCCP subsystems is a consequence of the AS concept. In other words I do not see any conceptual problems with this -> I have one AS which is a set of several independent SCCP subsystems. I want to have possibility to operate the AS as a whole but I do not want to loos control over SCCP subsystems within the AS separately. Another problem is that this leads to necessity of having multiple AS'es on the other side in SE model which is mandatory and even more affecting traffic sate of remote applications! What if I have a remote process which does not support optional DE neither it supports multiple AS'es. However locally I have an AS with several SCCP subsystems within it. If I want to manage them separately I need support for either optional DE at remote side or support for multiple AS'es per remote process in SE (since ASP TM messages in SE affect two AS'es on each side). I think we should update SUA and allow DUNA for N-STATE_request to be sent from ASP to SGP. This does not require any conceptual change but removal of this "administrative" (i.e. not conceptual) restriction. Are you saying that there are conceptual problems for this? thanks/ stanislav Tolga Asveren wrote: Stanislav, -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Thursday, January 05, 2006 12:14 PM To: SIGTRAN Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA Tolga, Brian, Brian I read all the sections in the SUA and the reason why I am asking this question is that Tolga's answer below is the only way how a user is supposed to generate N-STATE_request for a particular SCCP subsystem. However I consider this fault in SUA specification for the following reasons: 1) there are no conceptual problems of having DUNA message containing N_STATE-request sent from ASP to SGP within a particular AS for the same reason why it is not problem of having N-STATE_request sent from SCCP-user to SCCP. 2) Using ASP TM messages for this management is very problematic since it actually says that it is not possible to independently manage several SCCP subsystems that are part of the same AS. It forces implementors to support multiple AS'es per signaling process just to have separate SCCP subsystems separately manageable!! [TOLGA]OTOH, one could argue that AS is an entity which becomes available/unavailable as a whole, i.e. if it has multiple subsystems, they should be in-service/out-of-service simultaneously. So, what you consider as problematic is IMO a direct consequence of the AS concept. If you think otherwise why do you forbid sending DUNA from ASP to SGP which is to carry N-STATE_request fro independent SCCP subsystems that are part of the same AS? What is the problem of having this? regards/ Stanislav Ivanovich Tolga Asveren wrote: Stanislav, The answer to your question is "No". The behavior you are mentioning is controlled with ASPAC/ASPIA, i.e. with AS state. Thanks, Tolga -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Thursday, January 05, 2006 11:46 AM To: SIGTRAN Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA Brian, You didn't understand my question.! You refer to section 4.5.1. which is related to handling of SSNM messages at SGP. I asked about N_STATE_request (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP to SCCP at SGP. I would appreciate answer to my questions with YES or NO. regards/ Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. --brian Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > Hello SIGTRAN community, > > > > In standard SCCP there is a primitive called N-STATE_request which > transfers management information (in-service/out-of-service) from > SCCP-user to SCCP. > > > > How is this information conveyed between SGP and ASP? > > Is ASP allowed to send DUNA message to SGP by containing SSN (thus > having DUNA corresponding to N-STA! TE primitive)? > > > > regards/ Stanislav Ivanovich > _________________________________________________________________ > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > References > > 1. http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co m/broadband/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran Yahoo! DSL Something to write home about. Just $16.99/mo. or less _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1727717539-1136485941=:38936 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Tolga,
 
I disagree that not having possibility of managing separate SCCP subsystems is a consequence of the AS concept. In other words I do not see any conceptual problems with this -> I have one AS which is a set of several independent SCCP subsystems. I want to have possibility to operate the AS as a whole but I do not want to loos control over SCCP subsystems within the AS separately.
 
Another problem is that this leads to necessity of having multiple AS'es on the other side in SE model which is mandatory and even more affecting traffic sate of remote applications!
 
What if I have a remote process which does not support optional DE neither it supports multiple AS'es. However locally I have an AS with several SCCP subsystems within it. If I want to manage them separately I need support for either optional DE at remote side or support for multiple AS'es per remote! process in SE (since ASP TM messages in SE affect two AS'es on each side).
 
I think we should update SUA and allow DUNA for N-STATE_request to be sent from ASP to SGP. This does not require any conceptual change but removal of this "administrative" (i.e. not conceptual) restriction.
 
Are you saying that there are conceptual problems for this?
 
thanks/ stanislav
 


Tolga Asveren <asveren@ulticom.com> wrote:
Stanislav,

-----Original Message-----
From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of
Stanislav Ivanovich
Sent: Thursday, January 05, 2006 12:14 PM
To: SIGTRAN
Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA


Tolga, Brian,

Brian I read all the sections in the SUA and the reason why I am asking this
question is that Tolga's answer below is the only way how a user is supposed
to generate N-STATE_request for a particular SCCP subsystem.

However I consider this fault in SUA specification for the following
reasons:

1) there are no conceptual problems of having DUNA message containing
N_STATE-request sent from ASP to SGP within a particular AS for the same
reason why it is not problem of having N-STATE_request sent from SCCP-user
to SCCP.

2) Using ASP TM messages for this management is very problematic since it
actually says that it is not possible to independently manage several SCCP
subsystems that are part of the same AS. It forces implementors to support
multiple AS'es per signaling process just to have separate SCCP subsystems
separately manageable!!
[TOLGA]OTOH, one could argue that AS is an entity which becomes
available/unavailable as a whole, i.e. if it ! has multiple subsystems, they
should be in-service/out-of-service simultaneously. So, what you consider as
problematic is IMO a direct consequence of the AS concept.

If you think otherwise why do you forbid sending DUNA from ASP to SGP which
is to carry N-STATE_request fro independent SCCP subsystems that are part of
the same AS? What is the problem of having this?

regards/ Stanislav Ivanovich



Tolga Asveren wrote:
Stanislav,

The answer to your question is "No". The behavior you are mentioning is
controlled with ASPAC/ASPIA, i.e. with AS state.

Thanks,
Tolga


-----Original Message-----
From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of
Stanislav Ivanovich
Sent: Thursday, January 05, 2006 11:46 AM
To: SIGTRAN
Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA


Brian,

You didn't understand my question.! You refer to section! 4.5.1. which is
related to handling of SSNM messages at SGP. I asked about N_STATE_request
(not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP
to SCCP at SGP.

I would appreciate answer to my questions with YES or NO.

regards/ Stanislav Ivanovich


"Brian F. G. Bidulock" wrote:
Stanislav,

Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE.

--brian

Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27)
>
> Hello SIGTRAN community,
>
>
>
> In standard SCCP there is a primitive called N-STATE_request which
> transfers management information (in-service/out-of-service) from
> SCCP-user to SCCP.
>
>
>
> How is this information conveyed between SGP and ASP?
>
> Is ASP allowed to send DUNA message to SGP by containing SSN (thus
> having DUNA corresponding to N-STA! TE primitive)?
>
>
>
&g! t; regards/ Stanislav Ivanovich
> _________________________________________________________________
>
> [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less
>
> References
>
> 1.
http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co
m/broadband/

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


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





Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays,
whatever.



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





Yahoo! DSL Something to write home about. Just $16.99/mo. or less



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

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1727717539-1136485941=:38936-- --===============0478684235== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0478684235==-- From sigtran-bounces@ietf.org Thu Jan 05 13:42:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eua3s-0002up-Gn; Thu, 05 Jan 2006 13:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eua3q-0002ui-GH for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 13:42:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24821 for ; Thu, 5 Jan 2006 13:40:50 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eua9W-0005zX-WC for sigtran@ietf.org; Thu, 05 Jan 2006 13:48:02 -0500 Received: by nproxy.gmail.com with SMTP id x37so158016nfc for ; Thu, 05 Jan 2006 10:41:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ptAW3h2rxGfKZlXSgmo9gMZo7FF4ADKTPPyyjlwRfEkfp1bmPbYZqiA0l5WqrZANMJi7lBQiQeakl66Rr11H2tKdugAujRig22ERfw1alb0k7Zy//8OIdLjr1PbOk4N9bIA3LlIL3v5tH2CQEoDOTEi86DSot5n35H4d7oi/FCk= Received: by 10.48.247.14 with SMTP id u14mr708686nfh; Thu, 05 Jan 2006 10:41:57 -0800 (PST) Received: by 10.48.1.13 with HTTP; Thu, 5 Jan 2006 10:41:57 -0800 (PST) Message-ID: <17b146d60601051041p79e50e06x61212b86ec336c57@mail.gmail.com> Date: Thu, 5 Jan 2006 19:41:57 +0100 From: Ilie Glib To: bidulock@openss7.org, Ilie Glib , srivastava.rishi@wipro.com, sigtran@ietf.org Subject: Re: [Sigtran] no of segments limit on CODT In-Reply-To: <20060105020017.A4946@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <897DA809E857CD40A8419CF517948E210173825B@blr-k1-msg.wipro.com> <20060103225314.A17217@openss7.org> <17b146d60601050040y3c09266kdcc3c10b944e49e4@mail.gmail.com> <20060105020017.A4946@openss7.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, I beg your pardon. I was mixing it, indeed. Thank you Ilie On 1/5/06, Brian F. G. Bidulock wrote: > Ilie, > > I think that you are confusing CODT and CLDT. > > There is no limits on the number of Service Interface Data Units > (SIDUs) sent by the user to represent a single Service Data Unit > (SDU) for the CODT message. The "more bit" in the "Sequence Number" > parameter, when set in the CODT, indicates that the next SIDU (Data) > belongs to the same SDU. ...and there is no limit. > > > Is the same limit applicable for CODT message as well, > > So, the answer to your question is "No." > > Or, maybe I should have said read X.213, Q.711 and then RFC 3868. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 05 13:50:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaC3-0004UG-Jy; Thu, 05 Jan 2006 13:50:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaC2-0004U8-Br for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 13:50:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25806 for ; Thu, 5 Jan 2006 13:49:18 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaHl-0006Hm-Rf for sigtran@ietf.org; Thu, 05 Jan 2006 13:56:30 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 89ABE27A42 for ; Thu, 5 Jan 2006 13:50:20 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k05IoI7Q025430 for ; Thu, 5 Jan 2006 13:50:19 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA Date: Thu, 5 Jan 2006 13:31:32 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060105183221.42520.qmail@web35415.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Thursday, January 05, 2006 1:32 PM To: SIGTRAN Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA Tolga, I disagree that not having possibility of managing separate SCCP subsystems is a consequence of the AS concept. In other words I do not see any conceptual problems with this -> I have one AS which is a set of several independent SCCP subsystems. I want to have possibility to operate the AS as a whole but I do not want to loos control over SCCP subsystems within the AS separately. [TOLGA]Although it has a wider meaning in the node, the concept of AS corresponds to a traffic range from SUA stack point of view. It makes sense to me that a traffic range is active/inactive, in-service/out-of-service as a whole. Afterall, if one wants finer granularity control of that range, one would define traffic ranges accordingly. Another problem is that this leads to necessity of having multiple AS'es on the other side in SE model which is mandatory and even more affecting traffic sate of remote applications! What if I have a remote process which does not support optional DE neither it supports multiple AS'es. However locally I have an AS with several SCCP subsystems within it. If I want to manage them separately I need support for either optional DE at remote side or support for multiple AS'es per remote! process in SE (since ASP TM messages in SE affect two AS'es on each side). [TOLGA]I personally do not see a problem with multiple SSNs in a SE-IPSP scenario -or I misunderstood the scenario you had in mind-. What probably needs to be done is to group corresponding SSNs in separate RKs. I think we should update SUA and allow DUNA for N-STATE_request to be sent from ASP to SGP. This does not require any conceptual change but removal of this "administrative" (i.e. not conceptual) restriction. Are you saying that there are conceptual problems for this? [TOLGA]What I am saying is that this sounds against the spirit of AS to me. You define traffic ranges, i.e. an atomic entity from SUA control procedures point of view, but want to have a finer granularity control on the same entity. thanks/ stanislav Tolga Asveren wrote: Stanislav, -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Thursday, January 05, 2006 12:14 PM To: SIGTRAN Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA Tolga, Brian, Brian I read all the sections in the SUA and the reason why I am asking this question is that Tolga's answer below is the only way how a user is supposed to generate N-STATE_request for a particular SCCP subsystem. However I consider this fault in SUA specification for the following reasons: 1) there are no conceptual problems of having DUNA message containing N_STATE-request sent from ASP to SGP within a particular AS for the same reason why it is not problem of having N-STATE_request sent from SCCP-user to SCCP. 2) Using ASP TM messages for this management is very problematic since it actually says that it is not possible to independently manage several SCCP subsystems that are part of the same AS. It forces implementors to support multiple AS'es per signaling process just to have separate SCCP subsystems separately manageable!! [TOLGA]OTOH, one could argue that AS is an entity which becomes available/unavailable as a whole, i.e. if it ! has multiple subsystems, they should be in-service/out-of-service simultaneously. So, what you consider as problematic is IMO a direct consequence of the AS concept. If you think otherwise why do you forbid sending DUNA from ASP to SGP which is to carry N-STATE_request fro independent SCCP subsystems that are part of the same AS? What is the problem of having this? regards/ Stanislav Ivanovich Tolga Asveren wrote: Stanislav, The answer to your question is "No". The behavior you are mentioning is controlled with ASPAC/ASPIA, i.e. with AS state. Thanks, Tolga -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Thursday, January 05, 2006 11:46 AM To: SIGTRAN Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA Brian, You didn't understand my question.! You refer to section! 4.5.1. which is related to handling of SSNM messages at SGP. I asked about N_STATE_request (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP to SCCP at SGP. I would appreciate answer to my questions with YES or NO. regards/ Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. --brian Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > Hello SIGTRAN community, > > > > In standard SCCP there is a primitive called N-STATE_request which > transfers management information (in-service/out-of-service) from > SCCP-user to SCCP. > > > > How is this information conveyed between SGP and ASP? > > Is ASP allowed to send DUNA message to SGP by containing SSN (thus > having DUNA corresponding to N-STA! TE primitive)? > > > &g! t; regards/ Stanislav Ivanovich > _________________________________________________________________ > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > References > > 1. http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co m/broadband/ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran Yahoo! DSL Something to write home about. Just $16.99/mo. or less _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 05 13:54:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaG1-0005hP-Un; Thu, 05 Jan 2006 13:54:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaG0-0005gv-QK for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 13:54:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26306 for ; Thu, 5 Jan 2006 13:53:24 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaLi-0006U6-O3 for sigtran@ietf.org; Thu, 05 Jan 2006 14:00:36 -0500 Received: by nproxy.gmail.com with SMTP id l35so1148939nfa for ; Thu, 05 Jan 2006 10:54:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tVrQrCe3A0PGeDwh+x9/LKW8wbMWCwyqpSMXem44RT96hJSBzGZ4DswkPjYSbR670pJS6dPzaYPDNu/1nyPUWeRcT1er38Ti7L32xMuKhRtF9OZRJLKTwfJf9zE2zijmLOGCsfmf/CTQiT/WnCtadaessK3S5ZRTy9X5u2bMsAI= Received: by 10.49.94.7 with SMTP id w7mr140940nfl; Thu, 05 Jan 2006 10:54:35 -0800 (PST) Received: by 10.48.1.13 with HTTP; Thu, 5 Jan 2006 10:54:35 -0800 (PST) Message-ID: <17b146d60601051054j3454b154g3f889dcd4140d22d@mail.gmail.com> Date: Thu, 5 Jan 2006 19:54:35 +0100 From: Ilie Glib To: Stanislav Ivanovich Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA In-Reply-To: <20060105183221.42520.qmail@web35415.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060105183221.42520.qmail@web35415.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Folks, you can look at the problem from another perspective. Section 3.4.1. Destination Unavailable (DUNA) says: The DUNA message is sent from the SG or relay node... According to SUA RFC an ASP can be equiped with relay function, that is it can be a relay node. So in principle DUNA message as such can be sent from an ASP. Unfortunately, as far as I can remember, SSP messagees cannot be relayed in SCCP. Thus DUNA message sent from a relay node cannot represent N-STATE_request primitive, though it can carry an N-PCSTATE primitive. Regards Ilie On 1/5/06, Stanislav Ivanovich wrote: > Tolga, > > I disagree that not having possibility of managing separate SCCP subsyste= ms > is a consequence of the AS concept. In other words I do not see any > conceptual problems with this -> I have one AS which is a set of several > independent SCCP subsystems. I want to have possibility to operate the AS= as > a whole but I do not want to loos control over SCCP subsystems within the= AS > separately. > > Another problem is that this leads to necessity of having multiple AS'es = on > the other side in SE model which is mandatory and even more affecting > traffic sate of remote applications! > > What if I have a remote process which does not support optional DE neithe= r > it supports multiple AS'es. However locally I have an AS with several SCC= P > subsystems within it. If I want to manage them separately I need support = for > either optional DE at remote side or support for multiple AS'es per remot= e! > process in SE (since ASP TM messages in SE affect two AS'es on each side)= . > > I think we should update SUA and allow DUNA for N-STATE_request to be sen= t > from ASP to SGP. This does not require any conceptual change but removal = of > this "administrative" (i.e. not conceptual) restriction. > > Are you saying that there are conceptual problems for this? > > thanks/ stanislav > > > > Tolga Asveren wrote: > > Stanislav, > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf= Of > Stanislav Ivanovich > Sent: Thursday, January 05, 2006 12:14 PM > To: SIGTRAN > Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA > > > Tolga, Brian, > > Brian I read all the sections in the SUA and the reason why I am asking t= his > question is that Tolga's answer below is the only way how a user is suppo= sed > to generate N-STATE_request for a particular SCCP subsystem. > > However I consider this fault in SUA specification for the following > reasons: > > 1) there are no conceptual problems of having DUNA message containing > N_STATE-request sent from ASP to SGP within a particular AS for the same > reason why it is not problem of having N-STATE_request sent from SCCP-use= r > to SCCP. > > 2) Using ASP TM messages for this management is very problematic since it > actually says that it is not possible to independently manage several SCC= P > subsystems that are part of the same AS. It forces implementors to suppor= t > multiple AS'es per signaling process just to have separate SCCP subsystem= s > separately manageable!! > [TOLGA]OTOH, one could argue that AS is an entity which becomes > available/unavailable as a whole, i.e. if it ! has multiple subsystems, t= hey > should be in-service/out-of-service simultaneously. So, what you consider= as > problematic is IMO a direct consequence of the AS concept. > > If you think otherwise why do you forbid sending DUNA from ASP to SGP whi= ch > is to carry N-STATE_request fro independent SCCP subsystems that are part= of > the same AS? What is the problem of having this? > > regards/ Stanislav Ivanovich > > > > Tolga Asveren wrote: > Stanislav, > > The answer to your question is "No". The behavior you are mentioning is > controlled with ASPAC/ASPIA, i.e. with AS state. > > Thanks, > Tolga > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf= Of > Stanislav Ivanovich > Sent: Thursday, January 05, 2006 11:46 AM > To: SIGTRAN > Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA > > > Brian, > > You didn't understand my question.! You refer to section! 4.5.1. which is > related to handling of SSNM messages at SGP. I asked about N_STATE_reques= t > (not N_STATE_indication) which is supposed to be sent from SCCP-user at A= SP > to SCCP at SGP. > > I would appreciate answer to my questions with YES or NO. > > regards/ Stanislav Ivanovich > > > "Brian F. G. Bidulock" wrote: > Stanislav, > > Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. > > --brian > > Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > > > Hello SIGTRAN community, > > > > > > > > In standard SCCP there is a primitive called N-STATE_request which > > transfers management information (in-service/out-of-service) from > > SCCP-user to SCCP. > > > > > > > > How is this information conveyed between SGP and ASP? > > > > Is ASP allowed to send DUNA message to SGP by containing SSN (thus > > having DUNA corresponding to N-STA! TE primitive)? > > > > > > > &g! t; regards/ Stanislav Ivanovich > > > _________________________________________________________________ > > > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > > > References > > > > 1. > http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=3D37474/*http://promo.yah= oo.co > m/broadband/ > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > > > > > Yahoo! Photos > Ring in the New Year with Photo Calendars. Add photos, events, holidays, > whatever. > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > > ________________________________ > Yahoo! Photos > Ring in the New Year with Photo Calendars. Add photos, events, holidays, > whatever. > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 05 14:14:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaZX-0008Tx-Te; Thu, 05 Jan 2006 14:14:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaZT-0008Ti-Tr for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 14:14:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29103 for ; Thu, 5 Jan 2006 14:13:31 -0500 (EST) Received: from web35412.mail.mud.yahoo.com ([66.163.179.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuafC-0007Qr-Mr for sigtran@ietf.org; Thu, 05 Jan 2006 14:20:43 -0500 Received: (qmail 17099 invoked by uid 60001); 5 Jan 2006 19:14:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eMKqmIAt/gU2TqTEn7kMzWNkheWY+DH8junQdb0s7SKWkIXg+HO0awJs9Ou0u1TQ36MIaOl70K7uZv8ncTSQy6lXew4wSOdjFK/840AJ0nrMqG7iqRopgkZmmI3E1SMghHEgJRFtZbcy33O+xrIeLyKnVH8cal9rqM2R+L2Z8Jk= ; Message-ID: <20060105191417.17097.qmail@web35412.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35412.mail.mud.yahoo.com via HTTP; Thu, 05 Jan 2006 11:14:17 PST Date: Thu, 5 Jan 2006 11:14:17 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA To: SIGTRAN In-Reply-To: <17b146d60601051054j3454b154g3f889dcd4140d22d@mail.gmail.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2041880903==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============2041880903== Content-Type: multipart/alternative; boundary="0-828032117-1136488457=:9285" Content-Transfer-Encoding: 8bit --0-828032117-1136488457=:9285 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Ilie, Tolga, I would be very happy to hear what Tolga and other will say about SUA relay in ASP (or IPSP)... but nevertheless good point... However it is irrelevant if SSP is relayed or not (actually in SCCP it is broadcasted upon reception of SSP from the originating SCCP where the subsystem is located). What is relevant is that: 1) SCCP-user can request N-STATE-Request, therefore ASP should be able to do it by means of DUNA. 2) If we do it through ASP TM then it implies either necessity for support of DE at remote side or support for multiple AS'es at remote side in SE. In my view this is unacceptable! I vote for removal of administrative and certainly not conceptual restriction in SUA to send DUNA with N-STATE_request primitive from ASP to SGP since current pointless restrictions puts extra requirements on remote processes. If one does not want it he/she does not need to use it... but allowing it cannot harm, can it? Any opinions from other people? /stanislav Ilie Glib wrote: Hello Folks, you can look at the problem from another perspective. Section 3.4.1. Destination Unavailable (DUNA) says: The DUNA message is sent from the SG or relay node... According to SUA RFC an ASP can be equiped with relay function, that is it can be a relay node. So in principle DUNA message as such can be sent from an ASP. Unfortunately, as far as I can remember, SSP messagees cannot be relayed in SCCP. Thus DUNA message sent from a relay node cannot represent N-STATE_request primitive, though it can carry an N-PCSTATE primitive. Regards Ilie On 1/5/06, Stanislav Ivanovich wrote: > Tolga, > > I disagree that not having possibility of managing separate SCCP subsystems > is a consequence of the AS concept. In other words I do not see any > conceptual problems with this -> I have one AS which is a set of several > independent SCCP subsystems. I want to have possibility to operate the AS as > a whole but I do not want to loos control over SCCP subsystems within the AS > separately. > > Another problem is that this leads to necessity of having multiple AS'es on > the other side in SE model which is mandatory and even more affecting > traffic sate of remote applications! > > What if I have a remote process which does not support optional DE neither > it supports multiple AS'es. However locally I have an AS with several SCCP > subsystems within it. If I want to manage them separately I need support for > either optional DE at remote side or support for multiple AS'es per remote! > process in SE (since ASP TM messages in SE affect two AS'es on each side). > > I think we should update SUA and allow DUNA for N-STATE_request to be sent > from ASP to SGP. This does not require any conceptual change but removal of > this "administrative" (i.e. not conceptual) restriction. > > Are you saying that there are conceptual problems for this? > > thanks/ stanislav > > > > Tolga Asveren wrote: > > Stanislav, > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of > Stanislav Ivanovich > Sent: Thursday, January 05, 2006 12:14 PM > To: SIGTRAN > Subject: RE: [Sigtran] Transfer of N-STATE_request in SUA > > > Tolga, Brian, > > Brian I read all the sections in the SUA and the reason why I am asking this > question is that Tolga's answer below is the only way how a user is supposed > to generate N-STATE_request for a particular SCCP subsystem. > > However I consider this fault in SUA specification for the following > reasons: > > 1) there are no conceptual problems of having DUNA message containing > N_STATE-request sent from ASP to SGP within a particular AS for the same > reason why it is not problem of having N-STATE_request sent from SCCP-user > to SCCP. > > 2) Using ASP TM messages for this management is very problematic since it > actually says that it is not possible to independently manage several SCCP > subsystems that are part of the same AS. It forces implementors to support > multiple AS'es per signaling process just to have separate SCCP subsystems > separately manageable!! > [TOLGA]OTOH, one could argue that AS is an entity which becomes > available/unavailable as a whole, i.e. if it ! has multiple subsystems, they > should be in-service/out-of-service simultaneously. So, what you consider as > problematic is IMO a direct consequence of the AS concept. > > If you think otherwise why do you forbid sending DUNA from ASP to SGP which > is to carry N-STATE_request fro independent SCCP subsystems that are part of > the same AS? What is the problem of having this? > > regards/ Stanislav Ivanovich > > > > Tolga Asveren wrote: > Stanislav, > > The answer to your question is "No". The behavior you are mentioning is > controlled with ASPAC/ASPIA, i.e. with AS state. > > Thanks, > Tolga > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of > Stanislav Ivanovich > Sent: Thursday, January 05, 2006 11:46 AM > To: SIGTRAN > Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA > > > Brian, > > You didn't understand my question.! You refer to section! 4.5.1. which is > related to handling of SSNM messages at SGP. I asked about N_STATE_request > (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP > to SCCP at SGP. > > I would appreciate answer to my questions with YES or NO. > > regards/ Stanislav Ivanovich > > > "Brian F. G. Bidulock" wrote: > Stanislav, > > Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. > > --brian > > Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > > > Hello SIGTRAN community, > > > > > > > > In standard SCCP there is a primitive called N-STATE_request which > > transfers management information (in-service/out-of-service) from > > SCCP-user to SCCP. > > > > > > > > How is this information conveyed between SGP and ASP? > > > > Is ASP allowed to send DUNA message to SGP by containing SSN (thus > > having DUNA corresponding to N-STA! TE primitive)? > > > > > > > &g! t; regards/ Stanislav Ivanovich > > > _________________________________________________________________ > > > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > > > References > > > > 1. > http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co > m/broadband/ > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > > > > > Yahoo! Photos > Ring in the New Year with Photo Calendars. Add photos, events, holidays, > whatever. > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > > ________________________________ > Yahoo! Photos > Ring in the New Year with Photo Calendars. Add photos, events, holidays, > whatever. > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > -- Ilie --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-828032117-1136488457=:9285 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Ilie, Tolga,
 
I would be very happy to hear what Tolga and other will say about SUA relay in ASP (or IPSP)... but nevertheless good point...
 
However it is irrelevant if SSP is relayed or not (actually in SCCP it is broadcasted upon reception of SSP from the originating SCCP where the subsystem is located).
 
What is relevant is that:
 
1) SCCP-user can request N-STATE-Request, therefore ASP should be able to do it by means of DUNA.
 
2) If we do it through ASP TM then it implies either necessity for support of DE at remote side or support for multiple AS'es at remote side in SE. In my view this is unacceptable!
 
I vote for removal of administrative and certainly not conceptual restriction in SUA to send DUNA with N-STATE_request primitive from ASP to SGP since current pointless restric! tions puts extra requirements on remote processes. If one does not want it he/she does not need to use it... but allowing it cannot harm, can it?
 
Any opinions from other people?
 
/stanislav
 


Ilie Glib <ilie.glib@googlemail.com> wrote:
Hello Folks,

you can look at the problem from another perspective.

Section 3.4.1. Destination Unavailable (DUNA)
says: The DUNA message is sent from the SG or relay node...

According to SUA RFC an ASP can be equiped with relay function, that
is it can be a relay node. So in principle DUNA message as such can be
sent from an ASP. Unfortunately, as far as I can remember, SSP
messagees cannot be relayed in SCCP. Thus DUNA message sent from a
relay node cannot represent N-STATE_request prim! itive, though it can
carry an N-PCSTATE primitive.

Regards

Ilie


On 1/5/06, Stanislav Ivanovich wrote:
> Tolga,
>
> I disagree that not having possibility of managing separate SCCP subsystems
> is a consequence of the AS concept. In other words I do not see any
> conceptual problems with this -> I have one AS which is a set of several
> independent SCCP subsystems. I want to have possibility to operate the AS as
> a whole but I do not want to loos control over SCCP subsystems within the AS
> separately.
>
> Another problem is that this leads to necessity of having multiple AS'es on
> the other side in SE model which is mandatory and even more affecting
> traffic sate of remote applications!
>
> What if I have a remote process which does not support optional DE neither
> it supports multiple AS'es. However locally I have an AS with s! everal SCCP
> subsystems within it. If I want to manage them separately I need support for
> either optional DE at remote side or support for multiple AS'es per remote!
> process in SE (since ASP TM messages in SE affect two AS'es on each side).
>
> I think we should update SUA and allow DUNA for N-STATE_request to be sent
> from ASP to SGP. This does not require any conceptual change but removal of
> this "administrative" (i.e. not conceptual) restriction.
>
> Are you saying that there are conceptual problems for this?
>
> thanks/ stanislav
>
>
>
> Tolga Asveren wrote:
>
> Stanislav,
>
> -----Original Message-----
> From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of
> Stanislav Ivanovich
> Sent: Thursday, January 05, 2006 12:14 PM
> To: SIGTRAN
> Subject: RE: [Sigtran] Transfer of N-STATE_req! uest in SUA
>
>
> Tolga, Brian,
>
> Brian I read all the sections in the SUA and the reason why I am asking this
> question is that Tolga's answer below is the only way how a user is supposed
> to generate N-STATE_request for a particular SCCP subsystem.
>
> However I consider this fault in SUA specification for the following
> reasons:
>
> 1) there are no conceptual problems of having DUNA message containing
> N_STATE-request sent from ASP to SGP within a particular AS for the same
> reason why it is not problem of having N-STATE_request sent from SCCP-user
> to SCCP.
>
> 2) Using ASP TM messages for this management is very problematic since it
> actually says that it is not possible to independently manage several SCCP
> subsystems that are part of the same AS. It forces implementors to support
> multiple AS'es per signaling process just to have separate SCCP subsystems
> separately manageable!!
> [TOLGA]OTOH, one could argue that AS is an entity which becomes
> available/unavailable as a whole, i.e. if it ! has multiple subsystems, they
> should be in-service/out-of-service simultaneously. So, what you consider as
> problematic is IMO a direct consequence of the AS concept.
>
> If you think otherwise why do you forbid sending DUNA from ASP to SGP which
> is to carry N-STATE_request fro independent SCCP subsystems that are part of
> the same AS? What is the problem of having this?
>
> regards/ Stanislav Ivanovich
>
>
>
> Tolga Asveren wrote:
> Stanislav,
>
> The answer to your question is "No". The behavior you are mentioning is
> controlled with ASPAC/ASPIA, i.e. with AS state.
>
> Thanks,
> Tolga
>
>
> -----Original Message-----
> From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of
> Stanislav Ivanovich
> Sent: Thursday, January 05, 2006 11:46 AM
> To: SIGTRAN
> Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA
>
>
> Brian,
>
> You didn't understand my question.! You refer to section! 4.5.1. which is
> related to handling of SSNM messages at SGP. I asked about N_STATE_request
> (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP
> to SCCP at SGP.
>
> I would appreciate answer to my questions with YES or NO.
>
> regards/ Stanislav Ivanovich
>
>
> "Brian F. G. Bidulock" wrote:
> Stanislav,
>
> Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE.
>
> --brian
>
> Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27)
> >
> > Hello SIGTRAN community,
> >
> >
> >
> ! > In standard SCCP there is a primitive called N-STATE_request which
> > transfers management information (in-service/out-of-service) from
> > SCCP-user to SCCP.
> >
> >
> >
> > How is this information conveyed between SGP and ASP?
> >
> > Is ASP allowed to send DUNA message to SGP by containing SSN (thus
> > having DUNA corresponding to N-STA! TE primitive)?
> >
> >
> >
> &g! t; regards/ Stanislav Ivanovich
> >
> _________________________________________________________________
> >
> > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less
> >
> > References
> >
> > 1.
> http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co
> m/broadband/
>
> > _______________________________________________
> > Sigtran mailing list
>! ; > Sigtran@ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
>
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/
>
>
>
>
>
> Yahoo! Photos
> Ring in the New Year with Photo Calendars. Add photos, events, holidays,
> whatever.
>
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
>
>
> Yahoo! DSL Something to write home about. Just $16.99/mo. or less
>
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
> ________________________________
> Yahoo! Photos
> Ring in the New Year with Photo Calendars. Add! photos, events, holidays,
> whatever.
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>


--
Ilie

Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-828032117-1136488457=:9285-- --===============2041880903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============2041880903==-- From sigtran-bounces@ietf.org Thu Jan 05 14:39:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euaxc-0001j1-7m; Thu, 05 Jan 2006 14:39:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euaxa-0001iw-KZ for sigtran@megatron.ietf.org; Thu, 05 Jan 2006 14:39:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02339 for ; Thu, 5 Jan 2006 14:38:26 -0500 (EST) Received: from web35404.mail.mud.yahoo.com ([66.163.179.113]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eub3H-0008O5-NU for sigtran@ietf.org; Thu, 05 Jan 2006 14:45:38 -0500 Received: (qmail 24731 invoked by uid 60001); 5 Jan 2006 19:37:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6nP53e/rCgq0hGt36aJuEv/rMCejdCF6OOJo3WejxzYMxAKL9LRu7OApyPBXfkOs6b3jDHlxXpOtzYqm56GjLdIt2m54Sfyi/zVeGnrvCZk7PUOxMPYpJiKb0xz6K8aBhll36Mn96dTpSlBiOyc2//4IBx1YxPMruXisuKNNTIA= ; Message-ID: <20060105193704.24729.qmail@web35404.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35404.mail.mud.yahoo.com via HTTP; Thu, 05 Jan 2006 11:37:04 PST Date: Thu, 5 Jan 2006 11:37:04 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA To: SIGTRAN In-Reply-To: <20060105191417.17097.qmail@web35412.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0563980245==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0563980245== Content-Type: multipart/alternative; boundary="0-40783880-1136489824=:22304" Content-Transfer-Encoding: 8bit --0-40783880-1136489824=:22304 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Oooops! I made serious mistake. I agree with Tolga since managing of separate SCCP subsystems by means of separate AS'es actually does not put any requirements on the remote processes in the IP networks since they are accessed by means of IPSP-IPSP protocol rather than ASP-SGP one. In both protocols (ASP-SGP and IPSP-IPSP) N-STATE_request is to be managed by ASP TM messages. thanks and regards/ Stanislav Stanislav Ivanovich wrote: Ilie, Tolga, I would be very happy to hear what Tolga and other will say about SUA relay in ASP (or IPSP)... but nevertheless good point... However it is irrelevant if SSP is relayed or not (actually in SCCP it is broadcasted upon reception of SSP from the originating SCCP where the subsystem is located). What is relevant is that: 1) SCCP-user can request N-STATE-Request, therefore ASP should be able to do it by means of DUNA. 2) If we do it through ASP TM then it implies either necessity for support of DE at remote side or support for multiple AS'es at remote side in SE. In my view this is unacceptable! I vote for removal of administrative and certainly not conceptual restriction in SUA to send DUNA with N-STATE_request primitive from ASP to SGP since current pointless restric! tions puts extra requirements on remote processes. If one does not want it he/she does not need to use it... but allowing it cannot harm, can it? Any opinions from other people? /stanislav Ilie Glib wrote: Hello Folks, you can look at the problem from another perspective. Section 3.4.1. Destination Unavailable (DUNA) says: The DUNA message is sent from the SG or relay node... According to SUA RFC an ASP can be equiped with relay function, that is it can be a relay node. So in principle DUNA message as such can be sent from an ASP. Unfortunately, as far as I can remember, SSP messagees cannot be relayed in SCCP. Thus DUNA message sent from a relay node cannot represent N-STATE_request prim! itive, though it can carry an N-PCSTATE primitive. Regards Ilie On 1/5/06, Stanislav Ivanovich wrote: > Tolga, > > I disagree that not having possibility of managing separate SCCP subsystems > is a consequence of the AS concept. In other words I do not see any > conceptual problems with this -> I have one AS which is a set of several > independent SCCP subsystems. I want to have possibility to operate the AS as > a whole but I do not want to loos control over SCCP subsystems within the AS > separately. > > Another problem is that this leads to necessity of having multiple AS'es on > the other side in SE model which is mandatory and even more affecting > traffic sate of remote applications! > > What if I have a remote process which does not support optional DE neither > it supports multiple AS'es. However locally I have an AS with s! everal SCCP > subsystems within it. If I want to manage them separately I need support for > either optional DE at remote side or support for multiple AS'es per remote! > process in SE (since ASP TM messages in SE affect two AS'es on each side). > > I think we should update SUA and allow DUNA for N-STATE_request to be sent > from ASP to SGP. This does not require any conceptual change but removal of > this "administrative" (i.e. not conceptual) restriction. > > Are you saying that there are conceptual problems for this? > > thanks/ stanislav > > > > Tolga Asveren wrote: > > Stanislav, > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of > Stanislav Ivanovich > Sent: Thursday, January 05, 2006 12:14 PM > To: SIGTRAN > Subject: RE: [Sigtran] Transfer of N-STATE_req! uest in SUA > > > Tolga, Brian, > > Brian I read all the sections in the SUA and the reason why I am asking this > question is that Tolga's answer below is the only way how a user is supposed > to generate N-STATE_request for a particular SCCP subsystem. > > However I consider this fault in SUA specification for the following > reasons: > > 1) there are no conceptual problems of having DUNA message containing > N_STATE-request sent from ASP to SGP within a particular AS for the same > reason why it is not problem of having N-STATE_request sent from SCCP-user > to SCCP. > > 2) Using ASP TM messages for this management is very problematic since it > actually says that it is not possible to independently manage several SCCP > subsystems that are part of the same AS. It forces implementors to support > multiple AS'es per signaling process just to have separate SCCP subsystems > separately manageable!! > [TOLGA]OTOH, one could argue that AS is an entity which becomes > available/unavailable as a whole, i.e. if it ! has multiple subsystems, they > should be in-service/out-of-service simultaneously. So, what you consider as > problematic is IMO a direct consequence of the AS concept. > > If you think otherwise why do you forbid sending DUNA from ASP to SGP which > is to carry N-STATE_request fro independent SCCP subsystems that are part of > the same AS? What is the problem of having this? > > regards/ Stanislav Ivanovich > > > > Tolga Asveren wrote: > Stanislav, > > The answer to your question is "No". The behavior you are mentioning is > controlled with ASPAC/ASPIA, i.e. with AS state. > > Thanks, > Tolga > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of > Stanislav Ivanovich > Sent: Thursday, January 05, 2006 11:46 AM > To: SIGTRAN > Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA > > > Brian, > > You didn't understand my question.! You refer to section! 4.5.1. which is > related to handling of SSNM messages at SGP. I asked about N_STATE_request > (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP > to SCCP at SGP. > > I would appreciate answer to my questions with YES or NO. > > regards/ Stanislav Ivanovich > > > "Brian F. G. Bidulock" wrote: > Stanislav, > > Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE. > > --brian > > Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27) > > > > Hello SIGTRAN community, > > > > > > > ! > In standard SCCP there is a primitive called N-STATE_request which > > transfers management information (in-service/out-of-service) from > > SCCP-user to SCCP. > > > > > > > > How is this information conveyed between SGP and ASP? > > > > Is ASP allowed to send DUNA message to SGP by containing SSN (thus > > having DUNA corresponding to N-STA! TE primitive)? > > > > > > > &g! t; regards/ Stanislav Ivanovich > > > _________________________________________________________________ > > > > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > > > References > > > > 1. > http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co > m/broadband/ > > > _______________________________________________ > > Sigtran mailing list >! ; > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > > > > > Yahoo! Photos > Ring in the New Year with Photo Calendars. Add photos, events, holidays, > whatever. > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > Yahoo! DSL Something to write home about. Just $16.99/mo. or less > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > > ________________________________ > Yahoo! Photos > Ring in the New Year with Photo Calendars. Add! photos, events, holidays, > whatever. > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > -- Ilie --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less_______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-40783880-1136489824=:22304 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Oooops! I made serious mistake.
 
I agree with Tolga since managing of separate SCCP subsystems by means of separate AS'es actually does not put any requirements on the remote processes in the IP networks since they are accessed by means of IPSP-IPSP protocol rather than ASP-SGP one. In both protocols (ASP-SGP and IPSP-IPSP) N-STATE_request is to be managed by ASP TM messages.
 
thanks and regards/ Stanislav
 


Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
Ilie, Tolga,
 
I would be very happy to hear what Tolga and other will say about SUA relay in ASP (or IPSP)... but nevertheless good point...
 
However it is irrelevant if SSP is relayed or not (actually in SCCP it is broad! casted upon reception of SSP from the originating SCCP where the subsystem is located).
 
What is relevant is that:
 
1) SCCP-user can request N-STATE-Request, therefore ASP should be able to do it by means of DUNA.
 
2) If we do it through ASP TM then it implies either necessity for support of DE at remote side or support for multiple AS'es at remote side in SE. In my view this is unacceptable!
 
I vote for removal of administrative and certainly not conceptual restriction in SUA to send DUNA with N-STATE_request primitive from ASP to SGP since current pointless restric! tions puts extra requirements on remote processes. If one does not want it he/she does not need to use it... but allowing it cannot harm, can it?
 
Any opinions from other people?
 
/stanislav
 


Ilie Glib <ilie.glib@googlemail.com> wrote:
Hello Folks,

you can look at the problem from another perspective.

Section 3.4.1. Destination Unavailable (DUNA)
says: The DUNA message is sent from the SG or relay node...

According to SUA RFC an ASP can be equiped with relay function, that
is it can be a relay node. So in principle DUNA message as such can be
sent from an ASP. Unfortunately, as far as I can remember, SSP
messagees cannot be relayed in SCCP. Thus DUNA message sent from a
relay node cannot represent N-STATE_request prim! itive, though it can
carry an N-PCSTATE primitive.

Regards

Ilie


On 1/5/06, Stanislav Ivanovich wrote:
> Tolga,
>
> I disagree that not having possibility of managing separate SCCP subsystems
>! ; is a consequence of the AS concept. In other words I do not see any
> conceptual problems with this -> I have one AS which is a set of several
> independent SCCP subsystems. I want to have possibility to operate the AS as
> a whole but I do not want to loos control over SCCP subsystems within the AS
> separately.
>
> Another problem is that this leads to necessity of having multiple AS'es on
> the other side in SE model which is mandatory and even more affecting
> traffic sate of remote applications!
>
> What if I have a remote process which does not support optional DE neither
> it supports multiple AS'es. However locally I have an AS with s! everal SCCP
> subsystems within it. If I want to manage them separately I need support for
> either optional DE at remote side or support for multiple AS'es per remote!
> process in SE (since ASP TM messages in SE affect two AS'es on each side).
>> I think we should update SUA and allow DUNA for N-STATE_request to be sent
> from ASP to SGP. This does not require any conceptual change but removal of
> this "administrative" (i.e. not conceptual) restriction.
>
> Are you saying that there are conceptual problems for this?
>
> thanks/ stanislav
>
>
>
> Tolga Asveren wrote:
>
> Stanislav,
>
> -----Original Message-----
> From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of
> Stanislav Ivanovich
> Sent: Thursday, January 05, 2006 12:14 PM
> To: SIGTRAN
> Subject: RE: [Sigtran] Transfer of N-STATE_req! uest in SUA
>
>
> Tolga, Brian,
>
> Brian I read all the sections in the SUA and the reason why I am asking this
> question is that Tolga's answer below is the only way how a user is supposed
> to generate N-STATE_request for a par! ticular SCCP subsystem.
>
> However I consider this fault in SUA specification for the following
> reasons:
>
> 1) there are no conceptual problems of having DUNA message containing
> N_STATE-request sent from ASP to SGP within a particular AS for the same
> reason why it is not problem of having N-STATE_request sent from SCCP-user
> to SCCP.
>
> 2) Using ASP TM messages for this management is very problematic since it
> actually says that it is not possible to independently manage several SCCP
> subsystems that are part of the same AS. It forces implementors to support
> multiple AS'es per signaling process just to have separate SCCP subsystems
> separately manageable!!
> [TOLGA]OTOH, one could argue that AS is an entity which becomes
> available/unavailable as a whole, i.e. if it ! has multiple subsystems, they
> should be in-service/out-of-service simultaneously. So, what you co! nsider as
> problematic is IMO a direct consequence of the AS concept.
>
> If you think otherwise why do you forbid sending DUNA from ASP to SGP which
> is to carry N-STATE_request fro independent SCCP subsystems that are part of
> the same AS? What is the problem of having this?
>
> regards/ Stanislav Ivanovich
>
>
>
> Tolga Asveren wrote:
> Stanislav,
>
> The answer to your question is "No". The behavior you are mentioning is
> controlled with ASPAC/ASPIA, i.e. with AS state.
>
> Thanks,
> Tolga
>
>
> -----Original Message-----
> From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of
> Stanislav Ivanovich
> Sent: Thursday, January 05, 2006 11:46 AM
> To: SIGTRAN
> Subject: Re: [Sigtran] Transfer of N-STATE_request in SUA
>
>
> Brian,
>
> You didn't understand my question.! Y! ou refer to section! 4.5.1. which is
> related to handling of SSNM messages at SGP. I asked about N_STATE_request
> (not N_STATE_indication) which is supposed to be sent from SCCP-user at ASP
> to SCCP at SGP.
>
> I would appreciate answer to my questions with YES or NO.
>
> regards/ Stanislav Ivanovich
>
>
> "Brian F. G. Bidulock" wrote:
> Stanislav,
>
> Read sections 4.5.1 and all of 3.4 of RFC 3868. Grep on N-STATE.
>
> --brian
>
> Stanislav Ivanovich wrote: (Thu, 05 Jan 2006 07:59:27)
> >
> > Hello SIGTRAN community,
> >
> >
> >
> ! > In standard SCCP there is a primitive called N-STATE_request which
> > transfers management information (in-service/out-of-service) from
> > SCCP-user to SCCP.
> >
> >
> >
> > How is this information conveyed between SGP and ASP?
> >!
> > Is ASP allowed to send DUNA message to SGP by containing SSN (thus
> > having DUNA corresponding to N-STA! TE primitive)?
> >
> >
> >
> &g! t; regards/ Stanislav Ivanovich
> >
> _________________________________________________________________
> >
> > [1]Yahoo! DSL Something to write home about. Just $16.99/mo. or less
> >
> > References
> >
> > 1.
> http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo.co
> m/broadband/
>
> > _______________________________________________
> > Sigtran mailing list
>! ; > Sigtran@ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
>
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/
>
>
>
>
>
> Yahoo! Photos
> Ring in the New Year with Ph! oto Calendars. Add photos, events, holidays,
> whatever.
>
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
>
>
> Yahoo! DSL Something to write home about. Just $16.99/mo. or less
>
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
> ________________________________
> Yahoo! Photos
> Ring in the New Year with Photo Calendars. Add! photos, events, holidays,
> whatever.
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>


--
Ilie

Yahoo! DSL Something to write home about. Just $16.99/mo. or less_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-40783880-1136489824=:22304-- --===============0563980245== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0563980245==-- From sigtran-bounces@ietf.org Fri Jan 06 03:54:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EunMt-0004AM-Os; Fri, 06 Jan 2006 03:54:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EunMr-0004AD-V4 for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 03:54:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16265 for ; Fri, 6 Jan 2006 03:53:21 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EunSi-0002YI-AQ for sigtran@ietf.org; Fri, 06 Jan 2006 04:00:41 -0500 Received: by nproxy.gmail.com with SMTP id x37so236485nfc for ; Fri, 06 Jan 2006 00:54:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=YBPuso+i/y/6PDjHEhPF/ut9+OeltlCs0Lupsp22PBrwZscJ8LemLYv+DZnHYiTApTbX3IsQ3rY4TReZKQK93mqss6o5NDSsKEFU+AMJ0KZGdaR2WHZ3/TOw8IvpUYjDmNFZSitiu96PzgurUivIpoZ3QhRg0FK1tRjMK+CCenU= Received: by 10.49.42.7 with SMTP id u7mr743010nfj; Fri, 06 Jan 2006 00:54:32 -0800 (PST) Received: by 10.48.1.13 with HTTP; Fri, 6 Jan 2006 00:54:31 -0800 (PST) Message-ID: <17b146d60601060054o1addbc2j81166c40249f3209@mail.gmail.com> Date: Fri, 6 Jan 2006 09:54:31 +0100 From: Ilie Glib To: SIGTRAN MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [Sigtran] Coordinated service outage cannot be initiated from an ASP (AS) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Folks, SUA RFC 3868 (section 3.4.6. Destination Restricted (DRST)) allows sending of DRST from SGs only. Therefore coordinated service outage cannot be initiated from an ASP (AS). In my view use of ASPTM is not equivalent to SCCP SOR and SOG messages, and ASP-Inactive cannot be translated to SOR in the SG. Is it a fault in the RFC or was it done on purpose? Thank you in advance -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 06 04:40:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euo4x-0001hv-B7; Fri, 06 Jan 2006 04:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euo4v-0001hY-KN for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 04:40:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18874 for ; Fri, 6 Jan 2006 04:38:52 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuoAl-0003vK-Do for sigtran@ietf.org; Fri, 06 Jan 2006 04:46:13 -0500 Received: from nproxy.gmail.com ([64.233.182.192]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Euo4r-0003sp-UV for sigtran@ietf.org; Fri, 06 Jan 2006 04:40:06 -0500 Received: by nproxy.gmail.com with SMTP id x37so240286nfc for ; Fri, 06 Jan 2006 01:39:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EwBe/ncEtrYraW/fpwgj2SE7+axZN7iCS6kIuurI8P/OCGqjVEqmnulxla6ylsAJDWlTqaC/qNNiNo8/yLm3zctaKABcuYXS7yLMneN2NlUVIOjpm5THSPn2U7IqUnORuHLjpNb+cVAuqVEfgLe7gjmi7s4ZzuJRgCgyX3IgoKM= Received: by 10.49.2.9 with SMTP id e9mr743527nfi; Fri, 06 Jan 2006 01:39:00 -0800 (PST) Received: by 10.48.1.13 with HTTP; Fri, 6 Jan 2006 01:39:00 -0800 (PST) Message-ID: <17b146d60601060139k5e79fe91h21378307418359fb@mail.gmail.com> Date: Fri, 6 Jan 2006 10:39:00 +0100 From: Ilie Glib To: SIGTRAN MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Subject: [Sigtran] DUNA applies to SG as a whole X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Folks Let's consider an SG with multiple SGPs. RFC 3868 says (1.2.2. Terminology) Where an SG contains more than one SGP, the SG is a logical entity and the contained SGPs are assumed to be coordinated into a single management view to the SS7 network and to the supported Application Servers. I interpret this statement so that SGPs of the same SG have identical connectivity to SS7 NW, in particular DUNA, DAVA messages sent from one SGP apply to all SGPs of this SG. Thus if an SGP sends a DUNA to an ASP, the ASP assumes that Affected SPC is unavailable through the SG, and this applies to all SGPs in the SG. section 3.4.1. of SUA RFC says 3.4.1. Destination Unavailable (DUNA) The DUNA message is sent from the SG or relay node to all concerned ASPs (servicing SCCP-users considered local to the SG or relay node, see chapter 1.3.1.1), when a destination or SCCP-user has become unreachable. The SUA-User at the ASP is expected to stop traffic to the affected destination or SCCP-user through the SG or relay node initiating the DUNA. Here SG is mentioned. Thus in case of multiple SGPs DUNA applies to SG as a whole. The same is valid for DUPU, and DAVA. Is this reading of the RFC statements correct? thank you in advance -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 06 11:34:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuuXn-0007c7-6l; Fri, 06 Jan 2006 11:34:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuuXl-0007bu-Gx for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 11:34:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12399 for ; Fri, 6 Jan 2006 11:33:03 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[EF7ONgbUzOAedD+Z1x7S29Katt3dCo2x]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euudf-00070b-Ie for sigtran@ietf.org; Fri, 06 Jan 2006 11:40:28 -0500 Received: from ns.pigworks.openss7.net (IDENT:a1IAdbIDW6doNJN92jyRasPkRcs+OAqg@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k06GY7w05209; Fri, 6 Jan 2006 09:34:07 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k06GY6a22747; Fri, 6 Jan 2006 09:34:06 -0700 Date: Fri, 6 Jan 2006 09:34:06 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] Coordinated service outage cannot be initiated from an ASP (AS) Message-ID: <20060106093406.A22566@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601060054o1addbc2j81166c40249f3209@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601060054o1addbc2j81166c40249f3209@mail.gmail.com>; from ilie.glib@googlemail.com on Fri, Jan 06, 2006 at 09:54:31AM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, Check back in the mail archive. This was discussed on several occasions before. --brian Ilie Glib wrote: (Fri, 06 Jan 2006 09:54:31) > Hello Folks, > > SUA RFC 3868 (section 3.4.6. Destination Restricted (DRST)) > > allows sending of DRST from SGs only. Therefore coordinated service > outage cannot be initiated from an ASP (AS). > In my view use of ASPTM is not equivalent to SCCP SOR and SOG > messages, and ASP-Inactive cannot be translated to SOR in the SG. > > > Is it a fault in the RFC or was it done on purpose? > > > 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 From sigtran-bounces@ietf.org Fri Jan 06 11:37:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euuaa-00085f-3y; Fri, 06 Jan 2006 11:37:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuuaY-00085Q-Je for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 11:37:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12557 for ; Fri, 6 Jan 2006 11:35:57 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[bqYHoVclto/i7pQqmaJNUXqMi/aBTOPn]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuugS-00075W-Vk for sigtran@ietf.org; Fri, 06 Jan 2006 11:43:22 -0500 Received: from ns.pigworks.openss7.net (IDENT:bf/46RKiqwnmZgo+mKtLmwqIO1tmh9hV@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k06GbBw05245; Fri, 6 Jan 2006 09:37:11 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k06GbBV22775; Fri, 6 Jan 2006 09:37:11 -0700 Date: Fri, 6 Jan 2006 09:37:11 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] DUNA applies to SG as a whole Message-ID: <20060106093711.B22566@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601060139k5e79fe91h21378307418359fb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601060139k5e79fe91h21378307418359fb@mail.gmail.com>; from ilie.glib@googlemail.com on Fri, Jan 06, 2006 at 10:39:00AM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, Ilie Glib wrote: (Fri, 06 Jan 2006 10:39:00) > Hello Folks > > Let's consider an SG with multiple SGPs. > > RFC 3868 says (1.2.2. Terminology) > > Where an SG contains more than one SGP, the > SG is a logical entity and the contained SGPs are assumed to be > coordinated into a single management view to the SS7 network and to > the supported Application Servers. > > I interpret this statement so that SGPs of the same SG have identical > connectivity to SS7 NW, in particular DUNA, DAVA messages sent from > one SGP apply to all SGPs of this SG. Thus if an SGP sends a DUNA to > an ASP, the ASP assumes that Affected SPC is unavailable through the > SG, and this applies to all SGPs in the SG. > > section 3.4.1. of SUA RFC says > > 3.4.1. Destination Unavailable (DUNA) > > The DUNA message > is sent from the SG or relay node to all concerned ASPs (servicing > SCCP-users considered local to the SG or relay node, see chapter > 1.3.1.1), when a destination or SCCP-user has become unreachable. The > SUA-User at the ASP is expected to stop traffic to the affected > destination or SCCP-user through the SG or relay node initiating the > DUNA. > > Here SG is mentioned. Thus in case of multiple SGPs DUNA applies to SG > as a whole. The same is valid for DUPU, and DAVA. > > Is this reading of the RFC statements correct? Yes. --brian > > 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 From sigtran-bounces@ietf.org Fri Jan 06 12:31:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvRB-0006ht-R2; Fri, 06 Jan 2006 12:31:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvR9-0006hl-Cj for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 12:31:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16701 for ; Fri, 6 Jan 2006 12:30:19 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuvX4-0000Tx-4W for sigtran@ietf.org; Fri, 06 Jan 2006 12:37:43 -0500 Received: by nproxy.gmail.com with SMTP id x37so56070nfc for ; Fri, 06 Jan 2006 09:31:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eZL3KU1Slnoq+xmO7zq1bbB8EzR6YDPl/2w8UOA+QQ0TLvZPW+CJX9syT3i18p1U688rErI18zYv/0tSJxKcTH4EZda2L4XKCoHqcjyH6DGvPhsQuxly77eFgzX6XZ6s6IVa56Kolnu9NJ5Q4/HMTGCwL8Z0Yr5k4fp4ujecu5U= Received: by 10.48.247.14 with SMTP id u14mr770482nfh; Fri, 06 Jan 2006 09:31:29 -0800 (PST) Received: by 10.48.1.13 with HTTP; Fri, 6 Jan 2006 09:31:29 -0800 (PST) Message-ID: <17b146d60601060931q97ea53ex586319a1e3626464@mail.gmail.com> Date: Fri, 6 Jan 2006 18:31:29 +0100 From: Ilie Glib To: bidulock@openss7.org, Ilie Glib , SIGTRAN Subject: Re: [Sigtran] Coordinated service outage cannot be initiated from an ASP (AS) In-Reply-To: <20060106093406.A22566@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17b146d60601060054o1addbc2j81166c40249f3209@mail.gmail.com> <20060106093406.A22566@openss7.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, I remember the outcome of the question in my recent mail on SOR/SOG. I have also searched for SOG/SOR and DRST, ASP on IETF mail archive and been not able to find the answer to my today's question. Today the question is a little bit different. The problem is that DRST message cannot be sent from ASPs according to current text in the SUA RFC, the implementers' guide does not provide any corrections. Note 1 in section 3.4.6. does not help either. Therefore an ASP cannot answer with an DRST representing SOG in response to a SOR received from an SS7 peer, and an ASP cannot request Coordinated service outage. The latter perhaps is not so important since it is rather unlikely that all ASPs serving an AS go out of service. Regards Ilie On 1/6/06, Brian F. G. Bidulock wrote: > Ilie, > > Check back in the mail archive. > This was discussed on several occasions before. > > --brian > > Ilie Glib wrote: (Fr= i, 06 Jan 2006 09:54:31) > > Hello Folks, > > > > SUA RFC 3868 (section 3.4.6. Destination Restricted (DRST)) > > > > allows sending of DRST from SGs only. Therefore coordinated service > > outage cannot be initiated from an ASP (AS). > > In my view use of ASPTM is not equivalent to SCCP SOR and SOG > > messages, and ASP-Inactive cannot be translated to SOR in the SG. > > > > > > Is it a fault in the RFC or was it done on purpose? > > > > > > 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/ > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 06 12:36:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvVw-0007gD-Fp; Fri, 06 Jan 2006 12:36:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvVu-0007g2-2E for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 12:36:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16963 for ; Fri, 6 Jan 2006 12:35:14 -0500 (EST) Received: from zcars04f.nortel.com ([47.129.242.57] helo=zcars04f.nortelnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euvbn-0000bf-RP for sigtran@ietf.org; Fri, 06 Jan 2006 12:42:38 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k06HZxK10718 for ; Fri, 6 Jan 2006 12:36:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] DUNA applies to SG as a whole Date: Fri, 6 Jan 2006 11:35:34 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E609AD8C30@zrc2hxm2.corp.nortel.com> Thread-Topic: [Sigtran] DUNA applies to SG as a whole Thread-Index: AcYS4CiWI1EhgQ0iSDuuZcXVDQU86AABTYdA From: "Daniel Cohn" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Does this apply to M3UA as well? The RFC (3332bis) seems to contain contradictory statements in this regard. Consider the following excerpt from 1.3.2.5: As shown in Figure 1 an ASP may be connected to multiple SGPs. In such a case a particular SS7 destination may be reachable via more than one SGP and/or SG, i.e., via more than one route. As MTP3 users only maintain status on a destination and not on a route basis, the M3UA layer must maintain the status (availability, restriction, and/or congestion of route to destination) of the individual routes, derive the overall availability or congestion status of the destination from the status of the individual routes, and inform the MTP3 users of this derived status whenever it changes. and this excerpt from A.2.2: From the perspective of the M3UA layer at an ASP, a particular SG is capable of transferring traffic to a provisioned SS7 destination X if an SCTP association with at least one SGP of the SG is established, the SGP has returned an acknowledgement to the ASP to indicate that the ASP is actively handling traffic for that destination X, the SGP has not indicated that the destination X is inaccessible and the SGP has not indicated MTP Restart. When an ASP is configured to use multiple SGPs for transferring traffic to the SS7 network, the ASP must maintain knowledge of the current capability of the SGPs to handle traffic to destinations of interest. Also, the statement in 1.4.1 regarding coordination of states across SGPs is worded as "SHOULD", which implies that other implementations are possible. To me this suggests that the ASP is responsible for maintaining the status of each destination on a per-SGP basis. Is it not possible for an SGP to be partially isolated from the SS7 network, such that some SS7 destinations are reachable and others are not? Since the SGP generally operates in server mode, it cannot simply terminate its SCTP association with the ASPs. The ASPs will try to re-establish. So, the only way it can inform the ASPs that a particular destination is unreachable is via the DUNA message. The example redundancy model contained in A.1 suggests that SGPs are processes within the same host. However, this is a restrictive definition, and I do not believe it is intended to be taken as normative text. In fact, SGPs are individually addressable, which suggests to me that they can indeed exist on separate physical hosts. In this case, the isolation of one SGP from the SS7 network should not be taken to mean that the whole SG is isolated. Since there is no "SGP Inactive" message, I see no other way to communicate this type of situation to the ASP. Comments? Thanks, Dan -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Brian F. G. Bidulock Sent: Friday, January 06, 2006 10:37 AM To: Ilie Glib Cc: SIGTRAN Subject: Re: [Sigtran] DUNA applies to SG as a whole Ilie, Ilie Glib wrote: (Fri, 06 Jan 2006 10:39:00) > Hello Folks >=20 > Let's consider an SG with multiple SGPs. >=20 > RFC 3868 says (1.2.2. Terminology) >=20 > Where an SG contains more than one SGP, the > SG is a logical entity and the contained SGPs are assumed to be > coordinated into a single management view to the SS7 network and to > the supported Application Servers. >=20 > I interpret this statement so that SGPs of the same SG have identical > connectivity to SS7 NW, in particular DUNA, DAVA messages sent from > one SGP apply to all SGPs of this SG. Thus if an SGP sends a DUNA to > an ASP, the ASP assumes that Affected SPC is unavailable through the > SG, and this applies to all SGPs in the SG. >=20 > section 3.4.1. of SUA RFC says >=20 > 3.4.1. Destination Unavailable (DUNA) >=20 > The DUNA message > is sent from the SG or relay node to all concerned ASPs (servicing > SCCP-users considered local to the SG or relay node, see chapter > 1.3.1.1), when a destination or SCCP-user has become unreachable. The > SUA-User at the ASP is expected to stop traffic to the affected > destination or SCCP-user through the SG or relay node initiating the > DUNA. >=20 > Here SG is mentioned. Thus in case of multiple SGPs DUNA applies to SG > as a whole. The same is valid for DUPU, and DAVA. >=20 > Is this reading of the RFC statements correct? Yes. --brian _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 06 13:10:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euw2S-0004w3-Ai; Fri, 06 Jan 2006 13:10:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euw2N-0004pz-VX for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 13:10:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19284 for ; Fri, 6 Jan 2006 13:08:48 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euw8J-0001eK-5G for sigtran@ietf.org; Fri, 06 Jan 2006 13:16:12 -0500 Received: from nproxy.gmail.com ([64.233.182.202]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Euw2M-00040j-Gj for sigtran@ietf.org; Fri, 06 Jan 2006 13:10:02 -0500 Received: by nproxy.gmail.com with SMTP id x37so60805nfc for ; Fri, 06 Jan 2006 10:08:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fLstccwHlQQnIznTZvtEHOFRfQrAwLjuLR+MpNyA5nSq7R4OGdeRZjpYOBFeqoUV5NSbaGomVyGX/gVfBocMoSwS/Jh53ug+DsQBbPXU3q20l07MkHfBd+loVEmFgJxnnbQmBD/h1Fd0DFirsGGQF/lqHovnBbpVLw3NiCEt/os= Received: by 10.48.163.10 with SMTP id l10mr773066nfe; Fri, 06 Jan 2006 10:08:59 -0800 (PST) Received: by 10.48.1.13 with HTTP; Fri, 6 Jan 2006 10:08:59 -0800 (PST) Message-ID: <17b146d60601061008s1cc9413fke24344b86904afc9@mail.gmail.com> Date: Fri, 6 Jan 2006 19:08:59 +0100 From: Ilie Glib To: Daniel Cohn Subject: Re: [Sigtran] DUNA applies to SG as a whole In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E609AD8C30@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <62B9B0847CC47543B6B3B5E26BD268E609AD8C30@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Dan, On 1/6/06, Daniel Cohn wrote: > To me this suggests that the ASP is responsible for maintaining the > status of each destination on a per-SGP basis. Is it not possible for > an SGP to be partially isolated from the SS7 network, such that some SS7 > destinations are reachable and others are not? Since the SGP generally > operates in server mode, it cannot simply terminate its SCTP association > with the ASPs. [Ilie ] the SGP can send ASP-Inactive-Ack to go inactive, and answer incoming ASPAC with an error "management blocking" to stay Inactive. But this does not solve your concerns. > The ASPs will try to re-establish. So, the only way it > can inform the ASPs that a particular destination is unreachable is via > the DUNA message. [Ilie ] I agree. Regards -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 06 13:27:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwJD-0002Pn-MB; Fri, 06 Jan 2006 13:27:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwJB-0002P8-1h for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 13:27:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20554 for ; Fri, 6 Jan 2006 13:26:07 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwP2-0002A4-Kn for sigtran@ietf.org; Fri, 06 Jan 2006 13:33:32 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id B174446B5D for ; Fri, 6 Jan 2006 13:26:56 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k06IQqdg026983 for ; Fri, 6 Jan 2006 13:26:55 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] DUNA applies to SG as a whole Date: Fri, 6 Jan 2006 13:07:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E609AD8C30@zrc2hxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Daniel, > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Daniel Cohn > Sent: Friday, January 06, 2006 12:36 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] DUNA applies to SG as a whole > > > Does this apply to M3UA as well? [TOLGA]Yes. > > The RFC (3332bis) seems to contain contradictory statements in this > regard. Consider the following excerpt from 1.3.2.5: > > As shown in Figure 1 an ASP may be connected to multiple SGPs. In > such a case a particular SS7 destination may be reachable via more > than one SGP and/or SG, i.e., via more than one route. As MTP3 users > only maintain status on a destination and not on a route basis, the > M3UA layer must maintain the status (availability, restriction, > and/or congestion of route to destination) of the individual routes, > derive the overall availability or congestion status of the > destination from the status of the individual routes, and inform the > MTP3 users of this derived status whenever it changes. > > and this excerpt from A.2.2: > > From the perspective of the M3UA layer at an ASP, a particular SG is > capable of transferring traffic to a provisioned SS7 destination X if > an SCTP association with at least one SGP of the SG is established, > the SGP has returned an acknowledgement to the ASP to indicate that > the ASP is actively handling traffic for that destination X, the SGP > has not indicated that the destination X is inaccessible and the SGP > has not indicated MTP Restart. When an ASP is configured to use > multiple SGPs for transferring traffic to the SS7 network, the ASP > must maintain knowledge of the current capability of the SGPs to > handle traffic to destinations of interest. > > Also, the statement in 1.4.1 regarding coordination of states across > SGPs is worded as "SHOULD", which implies that other implementations are > possible. > > To me this suggests that the ASP is responsible for maintaining the > status of each destination on a per-SGP basis. Is it not possible for > an SGP to be partially isolated from the SS7 network, such that some SS7 > destinations are reachable and others are not? Since the SGP generally > operates in server mode, it cannot simply terminate its SCTP association > with the ASPs. The ASPs will try to re-establish. So, the only way it > can inform the ASPs that a particular destination is unreachable is via > the DUNA message. [TOLGA]SG is a single entity form MTP3 point of view. Actually this is pretty much the practical meaning of SG, a group of SGPs with a unique MTP3 view. > > The example redundancy model contained in A.1 suggests that SGPs are > processes within the same host. However, this is a restrictive > definition, and I do not believe it is intended to be taken as normative > text. In fact, SGPs are individually addressable, which suggests to me > that they can indeed exist on separate physical hosts. In this case, > the isolation of one SGP from the SS7 network should not be taken to > mean that the whole SG is isolated. Since there is no "SGP Inactive" > message, I see no other way to communicate this type of situation to the > ASP. [TOLGA]I agree that it makes more sense to have SGPs in different hosts to provide host redundancy -BTW, I believe this is the case in Figure A-1 as well, please note that SGP1.1. and SGP1.2 are part of SG1, and they reside on different hosts-. What I don't understand is why this causes a problem from current M3UA procedures point of view. One has a distributed MTP3 implementation spanning multiple hosts, which acts as a single entity. Each of those hosts are different SGPs part of the same SG. For the problem of "SGP being isolated from SS7 network": a)A multi-SGP SG probably will have an internal messaging mechanism to provide a unique MTP3-view. So, messages can be forwarded to another SGP of the same SG, which have active links to SS7 network. b)Like Ilie has suggested, ASPIA-ACK could be used. > > Comments? > > Thanks, > Dan > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Brian F. G. Bidulock > Sent: Friday, January 06, 2006 10:37 AM > To: Ilie Glib > Cc: SIGTRAN > Subject: Re: [Sigtran] DUNA applies to SG as a whole > > Ilie, > > Ilie Glib wrote: > (Fri, 06 Jan 2006 10:39:00) > > Hello Folks > > > > Let's consider an SG with multiple SGPs. > > > > RFC 3868 says (1.2.2. Terminology) > > > > Where an SG contains more than one SGP, the > > SG is a logical entity and the contained SGPs are assumed to be > > coordinated into a single management view to the SS7 network and to > > the supported Application Servers. > > > > I interpret this statement so that SGPs of the same SG have identical > > connectivity to SS7 NW, in particular DUNA, DAVA messages sent from > > one SGP apply to all SGPs of this SG. Thus if an SGP sends a DUNA to > > an ASP, the ASP assumes that Affected SPC is unavailable through the > > SG, and this applies to all SGPs in the SG. > > > > section 3.4.1. of SUA RFC says > > > > 3.4.1. Destination Unavailable (DUNA) > > > > The DUNA message > > is sent from the SG or relay node to all concerned ASPs (servicing > > SCCP-users considered local to the SG or relay node, see chapter > > 1.3.1.1), when a destination or SCCP-user has become unreachable. > The > > SUA-User at the ASP is expected to stop traffic to the affected > > destination or SCCP-user through the SG or relay node initiating > the > > DUNA. > > > > Here SG is mentioned. Thus in case of multiple SGPs DUNA applies to SG > > as a whole. The same is valid for DUPU, and DAVA. > > > > Is this reading of the RFC statements correct? > > Yes. > > --brian > > > _______________________________________________ > 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 From sigtran-bounces@ietf.org Fri Jan 06 13:45:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwaH-00043P-70; Fri, 06 Jan 2006 13:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwaF-00042M-Bc for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 13:45:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21849 for ; Fri, 6 Jan 2006 13:43:47 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[87qIP/a7RCv9MRIEznXb798jtqzQbowE]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwgA-0002je-Ob for sigtran@ietf.org; Fri, 06 Jan 2006 13:51:12 -0500 Received: from ns.pigworks.openss7.net (IDENT:tNweg3fsiI85TzgngJFI/mOaxE10N4X9@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k06Iitw07435; Fri, 6 Jan 2006 11:44:55 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k06Iitt24262; Fri, 6 Jan 2006 11:44:55 -0700 Date: Fri, 6 Jan 2006 11:44:55 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] Coordinated service outage cannot be initiated from an ASP (AS) Message-ID: <20060106114454.A24248@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601060054o1addbc2j81166c40249f3209@mail.gmail.com> <20060106093406.A22566@openss7.org> <17b146d60601060931q97ea53ex586319a1e3626464@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601060931q97ea53ex586319a1e3626464@mail.gmail.com>; from ilie.glib@googlemail.com on Fri, Jan 06, 2006 at 06:31:29PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, You obviously did not look in the mail archive. Look in the mail archive. Look for Subject line "SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop" starting May 15, 2002. Hey, just search on SOG. --brian Ilie Glib wrote: (Fri, 06 Jan 2006 18:31:29) > Brian, > > I remember the outcome of the question in my recent mail on SOR/SOG. > I have also searched for SOG/SOR and DRST, ASP on IETF mail archive > and been not able to find the answer to my today's question. > > Today the question is a little bit different. > The problem is that DRST message cannot be sent from ASPs according to > current text in the SUA RFC, the implementers' guide does not provide > any corrections. Note 1 in section 3.4.6. does not help either. > Therefore an ASP cannot answer with an DRST representing SOG in > response to a SOR received from an SS7 peer, and an ASP cannot request > Coordinated service outage. The latter perhaps is not so important > since it is rather unlikely that all ASPs serving an AS go out of > service. > > Regards > > Ilie > > > On 1/6/06, Brian F. G. Bidulock wrote: > > Ilie, > > > > Check back in the mail archive. > > This was discussed on several occasions before. > > > > --brian > > > > Ilie Glib wrote: (Fri, 06 Jan 2006 09:54:31) > > > Hello Folks, > > > > > > SUA RFC 3868 (section 3.4.6. Destination Restricted (DRST)) > > > > > > allows sending of DRST from SGs only. Therefore coordinated service > > > outage cannot be initiated from an ASP (AS). > > > In my view use of ASPTM is not equivalent to SCCP SOR and SOG > > > messages, and ASP-Inactive cannot be translated to SOR in the SG. > > > > > > > > > Is it a fault in the RFC or was it done on purpose? > > > > > > > > > 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/ > > > > > -- > Ilie -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 06 13:57:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euwlu-0007Er-UD; Fri, 06 Jan 2006 13:57:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euwls-00079N-EK for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 13:57:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22619 for ; Fri, 6 Jan 2006 13:55:47 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[RqDvH+OPxKHag9IbDk1WA5fMKVU75LrL]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euwro-00035h-5D for sigtran@ietf.org; Fri, 06 Jan 2006 14:03:12 -0500 Received: from ns.pigworks.openss7.net (IDENT:YpvI5yd0F/P8XLcnGWYHbxPsu52qJkbl@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k06Iv1w07756; Fri, 6 Jan 2006 11:57:01 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k06Iv0u24383; Fri, 6 Jan 2006 11:57:00 -0700 Date: Fri, 6 Jan 2006 11:57:00 -0700 From: "Brian F. G. Bidulock" To: Daniel Cohn Subject: Re: [Sigtran] DUNA applies to SG as a whole Message-ID: <20060106115700.B24248@openss7.org> Mail-Followup-To: Daniel Cohn , sigtran@ietf.org References: <62B9B0847CC47543B6B3B5E26BD268E609AD8C30@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E609AD8C30@zrc2hxm2.corp.nortel.com>; from cohn@nortel.com on Fri, Jan 06, 2006 at 11:35:34AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Daniel, Daniel Cohn wrote: (Fri, 06 Jan 2006 11:35:34) > status of each destination on a per-SGP basis. Is it not possible for > an SGP to be partially isolated from the SS7 network, such that some SS7 > destinations are reachable and others are not? Since the SGP generally > operates in server mode, it cannot simply terminate its SCTP association > with the ASPs. The ASPs will try to re-establish. So, the only way it > can inform the ASPs that a particular destination is unreachable is via > the DUNA message. The proper procedure for partial isolation is unsolicited ASP Inactive Ack to affected AS. Yes, the ASP will periodically attempt to reactivate the AS, as it should. Sending DUNA for partial isolation is incorrect: it tells all ASPs in the AS that no SGP in the SG can reach the destination. > The example redundancy model contained in A.1 suggests that SGPs are > processes within the same host. However, this is a restrictive > definition, and I do not believe it is intended to be taken as normative > text. In fact, SGPs are individually addressable, which suggests to me > that they can indeed exist on separate physical hosts. In this case, > the isolation of one SGP from the SS7 network should not be taken to > mean that the whole SG is isolated. Since there is no "SGP Inactive" > message, I see no other way to communicate this type of situation to the > ASP. Unsolicited ASP Inactive Ack is effectively an "SGP Inactive" message. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 06 13:59:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euwnl-0007zk-P8; Fri, 06 Jan 2006 13:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euwni-0007zZ-4P for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 13:58:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22843 for ; Fri, 6 Jan 2006 13:57:41 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euwte-0003Ar-FV for sigtran@ietf.org; Fri, 06 Jan 2006 14:05:07 -0500 Received: by nproxy.gmail.com with SMTP id x37so66489nfc for ; Fri, 06 Jan 2006 10:58:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jOGndY+IXt90xbaMMCgrNvNr01rAET47jP2S1+iUlKbE32amGOLF3yise60QagL8uVYb6ij/6aE6fNO6BnZsFVBB0wK6/viiYhDMM+RnxLA10RwKqJp02aDw/mzcDIBw0h0ANNUQJGdzaiLXv59aVP2LQGFzuORgnfb8rkj5iCs= Received: by 10.48.30.17 with SMTP id d17mr775155nfd; Fri, 06 Jan 2006 10:58:55 -0800 (PST) Received: by 10.48.1.13 with HTTP; Fri, 6 Jan 2006 10:58:55 -0800 (PST) Message-ID: <17b146d60601061058q78731c03p12a00c5336d5fa53@mail.gmail.com> Date: Fri, 6 Jan 2006 19:58:55 +0100 From: Ilie Glib To: Tolga Asveren Subject: Re: [Sigtran] DUNA applies to SG as a whole In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <62B9B0847CC47543B6B3B5E26BD268E609AD8C30@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Dan, Draft draft-ietf-sigtran-rfc3332bis-05.txt has the following statement 3.4.1 Destination Unavailable (DUNA) The DUNA message is sent from an SGP in an SG to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are unreachable. It is also sent by an SGP in response to a message from the ASP to an unreachable SS7 destination. As an implementation option the SG may suppress the sending of subsequent "response" DUNA messages regarding a certain unreachable SS7 destination for a certain period to give the remote side time to react. If there is no alternate route via another SG, the MTP3-User at the ASP is expected to stop traffic to the affected destination via the SG as per the defined MTP3-User procedures. Thus I believe that in M3UA every SGP upon receiving a message towards an unreachable destination sooner or later will answer with a DUNA to the ASP. But of couse some traffic can be lost, which can be saved if there is another SG with connectivity to the affected SPC. Apropo, SUA RFC does not have a statement like "DUNA is also sent by an SGP in response to a message from the ASP to an unreachable SS7 destination" So I could imagine an implementation that sends DUNAs from one SGP only. Regards Ilie On 1/6/06, Tolga Asveren wrote: > Daniel, > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Daniel Cohn > > Sent: Friday, January 06, 2006 12:36 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] DUNA applies to SG as a whole > > > > > > Does this apply to M3UA as well? > [TOLGA]Yes. > > > > The RFC (3332bis) seems to contain contradictory statements in this > > regard. Consider the following excerpt from 1.3.2.5: > > > > As shown in Figure 1 an ASP may be connected to multiple SGPs. In > > such a case a particular SS7 destination may be reachable via more > > than one SGP and/or SG, i.e., via more than one route. As MTP3 users > > only maintain status on a destination and not on a route basis, the > > M3UA layer must maintain the status (availability, restriction, > > and/or congestion of route to destination) of the individual routes, > > derive the overall availability or congestion status of the > > destination from the status of the individual routes, and inform the > > MTP3 users of this derived status whenever it changes. > > > > and this excerpt from A.2.2: > > > > From the perspective of the M3UA layer at an ASP, a particular SG is > > capable of transferring traffic to a provisioned SS7 destination X i= f > > an SCTP association with at least one SGP of the SG is established, > > the SGP has returned an acknowledgement to the ASP to indicate that > > the ASP is actively handling traffic for that destination X, the SGP > > has not indicated that the destination X is inaccessible and the SGP > > has not indicated MTP Restart. When an ASP is configured to use > > multiple SGPs for transferring traffic to the SS7 network, the ASP > > must maintain knowledge of the current capability of the SGPs to > > handle traffic to destinations of interest. > > > > Also, the statement in 1.4.1 regarding coordination of states across > > SGPs is worded as "SHOULD", which implies that other implementations ar= e > > possible. > > > > To me this suggests that the ASP is responsible for maintaining the > > status of each destination on a per-SGP basis. Is it not possible for > > an SGP to be partially isolated from the SS7 network, such that some SS= 7 > > destinations are reachable and others are not? Since the SGP generally > > operates in server mode, it cannot simply terminate its SCTP associatio= n > > with the ASPs. The ASPs will try to re-establish. So, the only way it > > can inform the ASPs that a particular destination is unreachable is via > > the DUNA message. > [TOLGA]SG is a single entity form MTP3 point of view. Actually this is > pretty much the practical meaning of SG, a group of SGPs with a unique MT= P3 > view. > > > > > > The example redundancy model contained in A.1 suggests that SGPs are > > processes within the same host. However, this is a restrictive > > definition, and I do not believe it is intended to be taken as normativ= e > > text. In fact, SGPs are individually addressable, which suggests to me > > that they can indeed exist on separate physical hosts. In this case, > > the isolation of one SGP from the SS7 network should not be taken to > > mean that the whole SG is isolated. Since there is no "SGP Inactive" > > message, I see no other way to communicate this type of situation to th= e > > ASP. > [TOLGA]I agree that it makes more sense to have SGPs in different hosts t= o > provide host redundancy -BTW, I believe this is the case in Figure A-1 as > well, please note that SGP1.1. and SGP1.2 are part of SG1, and they resid= e > on different hosts-. > > What I don't understand is why this causes a problem from current M3UA > procedures point of view. One has a distributed MTP3 implementation spann= ing > multiple hosts, which acts as a single entity. Each of those hosts are > different SGPs part of the same SG. > > For the problem of "SGP being isolated from SS7 network": > a)A multi-SGP SG probably will have an internal messaging mechanism to > provide a unique MTP3-view. So, messages can be forwarded to another SGP = of > the same SG, which have active links to SS7 network. > b)Like Ilie has suggested, ASPIA-ACK could be used. > > > > Comments? > > > > Thanks, > > Dan > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > > Behalf Of Brian F. G. Bidulock > > Sent: Friday, January 06, 2006 10:37 AM > > To: Ilie Glib > > Cc: SIGTRAN > > Subject: Re: [Sigtran] DUNA applies to SG as a whole > > > > Ilie, > > > > Ilie Glib wrote: > > (Fri, 06 Jan 2006 10:39:00) > > > Hello Folks > > > > > > Let's consider an SG with multiple SGPs. > > > > > > RFC 3868 says (1.2.2. Terminology) > > > > > > Where an SG contains more than one SGP, the > > > SG is a logical entity and the contained SGPs are assumed to be > > > coordinated into a single management view to the SS7 network and t= o > > > the supported Application Servers. > > > > > > I interpret this statement so that SGPs of the same SG have identical > > > connectivity to SS7 NW, in particular DUNA, DAVA messages sent from > > > one SGP apply to all SGPs of this SG. Thus if an SGP sends a DUNA to > > > an ASP, the ASP assumes that Affected SPC is unavailable through the > > > SG, and this applies to all SGPs in the SG. > > > > > > section 3.4.1. of SUA RFC says > > > > > > 3.4.1. Destination Unavailable (DUNA) > > > > > > The DUNA message > > > is sent from the SG or relay node to all concerned ASPs (servicing > > > SCCP-users considered local to the SG or relay node, see chapter > > > 1.3.1.1), when a destination or SCCP-user has become unreachable. > > The > > > SUA-User at the ASP is expected to stop traffic to the affected > > > destination or SCCP-user through the SG or relay node initiating > > the > > > DUNA. > > > > > > Here SG is mentioned. Thus in case of multiple SGPs DUNA applies to S= G > > > as a whole. The same is valid for DUPU, and DAVA. > > > > > > Is this reading of the RFC statements correct? > > > > Yes. > > > > --brian > > > > > > _______________________________________________ > > 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 > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 06 14:25:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxDE-0002k7-G3; Fri, 06 Jan 2006 14:25:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxDC-0002jh-M5 for sigtran@megatron.ietf.org; Fri, 06 Jan 2006 14:25:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25392 for ; Fri, 6 Jan 2006 14:24:01 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[WzZVIp59p4rxWoYEY6RHtrFZRiXE2fVp]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuxJ7-0004CU-FK for sigtran@ietf.org; Fri, 06 Jan 2006 14:31:26 -0500 Received: from ns.pigworks.openss7.net (IDENT:nc2Njtglmgtr1ed5w0tsI6aiqbthTCN0@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k06JPEw08226; Fri, 6 Jan 2006 12:25:14 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k06JPDT24779; Fri, 6 Jan 2006 12:25:13 -0700 Date: Fri, 6 Jan 2006 12:25:13 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] DUNA applies to SG as a whole Message-ID: <20060106122513.B23036@openss7.org> Mail-Followup-To: Ilie Glib , Tolga Asveren , sigtran@ietf.org References: <62B9B0847CC47543B6B3B5E26BD268E609AD8C30@zrc2hxm2.corp.nortel.com> <17b146d60601061058q78731c03p12a00c5336d5fa53@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601061058q78731c03p12a00c5336d5fa53@mail.gmail.com>; from ilie.glib@googlemail.com on Fri, Jan 06, 2006 at 07:58:55PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sigtran@ietf.org, Tolga Asveren X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, Ilie Glib wrote: (Fri, 06 Jan 2006 19:58:55) > Dan, > > Draft draft-ietf-sigtran-rfc3332bis-05.txt has the following statement > > 3.4.1 Destination Unavailable (DUNA) > > The DUNA message is sent from an SGP in an SG to all concerned ASPs > to indicate that the SG has determined that one or more SS7 > destinations are unreachable. It is also sent by an SGP in response > to a message from the ASP to an unreachable SS7 destination. As an > implementation option the SG may suppress the sending of subsequent > "response" DUNA messages regarding a certain unreachable SS7 > destination for a certain period to give the remote side time to > react. If there is no alternate route via another SG, the MTP3-User > at the ASP is expected to stop traffic to the affected destination > via the SG as per the defined MTP3-User procedures. > > Thus I believe that in M3UA every SGP upon receiving a message towards > an unreachable destination sooner or later will answer with a DUNA to > the ASP. But of couse some traffic can be lost, which can be saved if > there is another SG with connectivity to the affected SPC. > > Apropo, SUA RFC does not have a statement like "DUNA is also sent by > an SGP in response to a message from the ASP to an unreachable SS7 > destination" > So I could imagine an implementation that sends DUNAs from one SGP only. > > What is sent to the MTP-User and what the MTP-User expects of the MTP layer is specified in SS7 standards, not in M3UA. The bis document makes statements that are out of scope here and should have moved the statement to the non-normative appendix. An SG would be best generate DUNA to each ASP in each affected AS under the following conditions: a) In the case where the AS point code is hosted by the SG, DUNA is generated under the same conditions that MTP-PAUSE would be generated to local MTP-Users are the SG. b) In the case of the multiple SG as STP configuration, DUNA is generated under the same conditions that TFP would be generated and sent to the AS point code, were the AS point code a normal SS7 SEP. Understand? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 10:08:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvydD-0001E8-HL; Mon, 09 Jan 2006 10:08:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvydB-0001E3-QM for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 10:08:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20331 for ; Mon, 9 Jan 2006 10:07:03 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvyjX-0007QG-7d for sigtran@ietf.org; Mon, 09 Jan 2006 10:15:06 -0500 Received: from nproxy.gmail.com ([64.233.182.206]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Evycv-0001oU-Ve for sigtran@ietf.org; Mon, 09 Jan 2006 10:08:06 -0500 Received: by nproxy.gmail.com with SMTP id n28so120818nfc for ; Mon, 09 Jan 2006 07:07:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=N4/BGi9gPOvNMF3JVrWJru1sKYsw/39f6xDkyG9by4culwwD7Z0qANd9CcI5k0F6ZUo/02QwAzFf78QvtjZP4GvGQ7CQ+i6CErs4xG2ZhBEhp+HYAerUtDr6PKnF1w/Ynp7LMbiBQ9Z+XL1dzE/5AwAn7qLzAlgJah4MDUyZEqg= Received: by 10.48.255.7 with SMTP id c7mr913107nfi; Mon, 09 Jan 2006 07:07:00 -0800 (PST) Received: by 10.48.1.13 with HTTP; Mon, 9 Jan 2006 07:07:00 -0800 (PST) Message-ID: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> Date: Mon, 9 Jan 2006 16:07:00 +0100 From: Ilie Glib To: SIGTRAN MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Subject: [Sigtran] Upper boundary of Adaptation Layers X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Folks, In my current understanding of the SIGTRAN: - SUA and M3UA RFCs define the primitives of the adaptation layers towards their users in Section "1.6.1. Definition of the upper boundary". SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the complete definition of the primitives towards the users, therefore SIGTRAN supports existing SCCP/MTP users without them being aware of the fact that SIGTRAN is used for the transport of messages. SIGTRAN concepts and the corresponding entities/objects like AS, RK, RC, IPSP, ASP, and SGP are not part of the currently standardized upper boundary of M3UA (SUA). Thus today's SIGTRAN users do not know anything about those concepts. Can you please confirm this view or tell me if I'm mislead by my interpretation ? Is their any attempt in SIGTRAN WG to define an extended upper boundary for xxUA that gives the option of managing entities like AS, RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced services expected from adaptation layers ? Thank you in advance -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 10:19:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvyoM-000390-Gy; Mon, 09 Jan 2006 10:19:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvyoK-00038v-Lo for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 10:19:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21027 for ; Mon, 9 Jan 2006 10:18:34 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[kpJv24sUaM4t8HZfaLzgUbWB0tH7GHUX]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evyuo-0007jR-4K for sigtran@ietf.org; Mon, 09 Jan 2006 10:26:37 -0500 Received: from ns.pigworks.openss7.net (IDENT:TqrAjfxZGJ9iTk+4lHmeVKq8krKYDDxa@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k09FJYw18016; Mon, 9 Jan 2006 08:19:34 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k09FJYG10687; Mon, 9 Jan 2006 08:19:34 -0700 Date: Mon, 9 Jan 2006 08:19:33 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] Upper boundary of Adaptation Layers Message-ID: <20060109081933.A10655@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com>; from ilie.glib@googlemail.com on Mon, Jan 09, 2006 at 04:07:00PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, This can be true for the strict backhaul scenario. It is not necessarily true for the multiple SG as STP scenario, nor IPSP, nor for SCCP Relay. SUA already defines an enhanced SUA User that can use IP addresses or Host names in called or calling party addresses, and is thus aware of SUA. --brian Ilie Glib wrote: (Mon, 09 Jan 2006 16:07:00) > Hello Folks, > > In my current understanding of the SIGTRAN: > > - SUA and M3UA RFCs define the primitives of the adaptation layers > towards their users in Section "1.6.1. Definition of the upper > boundary". > SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the > complete definition of the primitives towards the users, therefore > SIGTRAN supports existing > SCCP/MTP users without them being aware of the fact that SIGTRAN is > used for the transport of messages. > SIGTRAN concepts and the corresponding entities/objects like AS, RK, > RC, IPSP, ASP, and SGP are not part of the currently standardized > upper boundary of M3UA (SUA). > Thus today's SIGTRAN users do not know anything about those concepts. > > Can you please confirm this view or tell me if I'm mislead by my > interpretation ? > > Is their any attempt in SIGTRAN WG to define an extended upper > boundary for xxUA that gives the option of managing entities like AS, > RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced > services expected from adaptation layers ? > > 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 From sigtran-bounces@ietf.org Mon Jan 09 10:21:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvypU-0003OZ-86; Mon, 09 Jan 2006 10:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvypS-0003OR-EZ for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 10:21:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21081 for ; Mon, 9 Jan 2006 10:19:44 -0500 (EST) Received: from phl-28-b-170.phl.dsl.cerfnet.com ([63.242.157.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evyvw-0007lF-69 for sigtran@ietf.org; Mon, 09 Jan 2006 10:27:47 -0500 Received: from bn001320 (bn001320 [192.168.1.61]) by phl-28-b-170.phl.dsl.cerfnet.com (8.12.8/8.12.8) with SMTP id k09FKgoj003118 for ; Mon, 9 Jan 2006 10:20:43 -0500 From: "Barry Nagelberg" To: "SIGTRAN" Subject: RE: [Sigtran] Upper boundary of Adaptation Layers Date: Mon, 9 Jan 2006 10:22:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, Your summary of the current architecture is mostly correct. The most important part of your summary is that "SIGTRAN supports existing SCCP/MTP users without them being aware of the fact that SIGTRAN is used for the transport of messages." This is the entire reason for the existance of SIGTRAN. SIGTRAN is a bridging mechanism designed to allow legacy SCCP/MTP3 users to take advantage of cheap IP transport without having to modify their legacy protocol stacks. Any attempt to make SCCP/MTP3 users aware of SIGTRAN would make SIGTRAN almost worthless. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Ilie Glib Sent: Monday, January 09, 2006 10:07 AM To: SIGTRAN Subject: [Sigtran] Upper boundary of Adaptation Layers Hello Folks, In my current understanding of the SIGTRAN: - SUA and M3UA RFCs define the primitives of the adaptation layers towards their users in Section "1.6.1. Definition of the upper boundary". SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the complete definition of the primitives towards the users, therefore SIGTRAN supports existing SCCP/MTP users without them being aware of the fact that SIGTRAN is used for the transport of messages. SIGTRAN concepts and the corresponding entities/objects like AS, RK, RC, IPSP, ASP, and SGP are not part of the currently standardized upper boundary of M3UA (SUA). Thus today's SIGTRAN users do not know anything about those concepts. Can you please confirm this view or tell me if I'm mislead by my interpretation ? Is their any attempt in SIGTRAN WG to define an extended upper boundary for xxUA that gives the option of managing entities like AS, RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced services expected from adaptation layers ? Thank you in advance -- Ilie _______________________________________________ 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 From sigtran-bounces@ietf.org Mon Jan 09 10:27:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evyvq-0005ED-La; Mon, 09 Jan 2006 10:27:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evyvn-0005Dv-GP for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 10:27:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21638 for ; Mon, 9 Jan 2006 10:26:17 -0500 (EST) Received: from web35403.mail.mud.yahoo.com ([66.163.179.112]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Evz2E-0007zp-Jg for sigtran@ietf.org; Mon, 09 Jan 2006 10:34:20 -0500 Received: (qmail 42156 invoked by uid 60001); 9 Jan 2006 15:27:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YIQZar7EeSk1U1HKTMgkp5P87QK4R/SxBzGxkAfz/i4TQD0grZgYRPXQZSImKPNeNwSsCQ2pjx5bX6XA/jR1WAOBjRg/YIndrkgxuNZCxTnGX3VGQT3vkemUjL5EG/TMBPzJN/ALojSea6R9SzKsKNTHq76BA2tYTYNrlpCgsJc= ; Message-ID: <20060109152717.42154.qmail@web35403.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35403.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2006 07:27:17 PST Date: Mon, 9 Jan 2006 07:27:17 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers To: SIGTRAN In-Reply-To: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1096531727==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1096531727== Content-Type: multipart/alternative; boundary="0-237121334-1136820437=:39032" Content-Transfer-Encoding: 8bit --0-237121334-1136820437=:39032 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, Since I find Ilie's questions ambiguous I will extend his questions by asking: 1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP process states) indepdnednetly on MTP-user or SCCP-user applications by making these applications idendepndtz on the ASP/IPSP state? 2) If such layer exisits and if M3UA and SUA are not just and only protocls but also boxes/layers which have a place in the signalling system which is to isolate user functions on ASP/IPSP state shold such layer own the control on ASP/IPSP states? For example SCCP subsystem does not want to handle traffic. In legacy systems SCCP-user applications own the control on the SCCP-subsystem state change thus they control appaearance on N-STATE_request primitive on SCCP API. However if one thinks that xxUA is not just a set of protocls (ASP-SGP and IPSP-IPSP) but also a box which contains a functionality which is to isolate user functions on SIGTRAN concepts (like ASP/IPSP) does that imply that such box should own commands for AS state change, i.e. it is SUA box but not SCCP user function which owns control on AS state change, see section 1.6.3. in xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management: M-ASP_ACTIVE request Direction: LM -> SUA Purpose: LM requests ASP to send an ASP Active message to its peer. M-ASP_INACTIVE request Direction: LM -> SUA Purpose: LM requests ASP to send an ASP Inactive message to its peer. Is this an RFC fault? regards/ stanislav Ilie Glib wrote: Hello Folks, In my current understanding of the SIGTRAN: - SUA and M3UA RFCs define the primitives of the adaptation layers towards their users in Section "1.6.1. Definition of the upper boundary". SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the complete definition of the primitives towards the users, therefore SIGTRAN supports existing SCCP/MTP users without them being aware of the fact that SIGTRAN is used for the transport of messages. SIGTRAN concepts and the corresponding entities/objects like AS, RK, RC, IPSP, ASP, and SGP are not part of the currently standardized upper boundary of M3UA (SUA). Thus today's SIGTRAN users do not know anything about those concepts. Can you please confirm this view or tell me if I'm mislead by my interpretation ? Is their any attempt in SIGTRAN WG to define an extended upper boundary for xxUA that gives the option of managing entities like AS, RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced services expected from adaptation layers ? Thank you in advance -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-237121334-1136820437=:39032 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
 
Since I find Ilie's questions ambiguous I will extend his questions by asking:
 
1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP process states) indepdnednetly on MTP-user or SCCP-user applications by making these applications idendepndtz on the ASP/IPSP state?
 
2) If such layer exisits and if M3UA and SUA are not just and only protocls but also boxes/layers which have a place in the signalling system which is to isolate user functions on ASP/IPSP state shold such layer own the control on ASP/IPSP states?
 
For example SCCP subsystem does not want to handle traffic. In legacy systems SCCP-user applications own the control on the SCCP-subsystem state change thus they control appaearance on N-STATE_request primitive on SCCP API.
However if one thinks that xxUA is not just a set of protocls (ASP-SGP and IPSP-IPSP) but also a box which contains a functionality which is to isolate user functions on SIGTRAN concepts (like ASP/IPSP) does that imply that such box should own commands for AS state change, i.e. it is SUA box but not SCCP user function which owns control on AS state change, see section 1.6.3. in xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management:
 
M-ASP_ACTIVE request
Direction: LM -> SUA
Purpose: LM requests ASP to send an ASP Active message to its peer.
M-ASP_INACTIVE request
Direction: LM -> SUA
Purpose: LM requests ASP to send an ASP Inactive message to its
peer.
 
Is this an RFC fault?
 
 
regards/ stanislav


Ilie Glib <ilie.glib@googlemail.com> wrote:
Hello Folks,

In my current understanding of the SIGTRAN:

- SUA and M3UA RFCs define the primitives of the adaptation layers
towards their users in Section "1.6.1. Definition of the upper
boundary".
SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the
complete definition of the primitives towards the users, therefore
SIGTRAN supports existing
SCCP/MTP users without them being aware of the fact that SIGTRAN is
used for the transport of messages.
SIGTRAN concepts and the corresponding entities/objects like AS, RK,
RC, IPSP, ASP, and SGP are not part of the currently standardized
upper boundary of M3UA (SUA).
Thus today's SIGTRAN users do not know anything about those concepts.

Can you please confirm this view or tell me if I'm mislead by my
interpretation ?

Is their any attempt in SIGTRAN WG to define! an extended upper
boundary for xxUA that gives the option of managing entities like AS,
RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced
services expected from adaptation layers ?

Thank you in advance

--
Ilie

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

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-237121334-1136820437=:39032-- --===============1096531727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1096531727==-- From sigtran-bounces@ietf.org Mon Jan 09 10:34:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evz2C-0006a4-Gh; Mon, 09 Jan 2006 10:34:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evz2A-0006ZE-Fj for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 10:34:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22156 for ; Mon, 9 Jan 2006 10:32:51 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[4EeJpLxsnuBrnq39dLRqIthMR+PIGqb4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evz8g-0008F8-GB for sigtran@ietf.org; Mon, 09 Jan 2006 10:40:54 -0500 Received: from ns.pigworks.openss7.net (IDENT:7KSJpfnoGQc2V1bQDx1BU2kWiqpT3d4K@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k09FY8w18202; Mon, 9 Jan 2006 08:34:08 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k09FY7q10968; Mon, 9 Jan 2006 08:34:07 -0700 Date: Mon, 9 Jan 2006 08:34:07 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers Message-ID: <20060109083407.A10921@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> <20060109152717.42154.qmail@web35403.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060109152717.42154.qmail@web35403.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Mon, Jan 09, 2006 at 07:27:17AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Stanislav Ivanovich wrote: (Mon, 09 Jan 2006 07:27:17) ---X-snip-X--- > > M-ASP_ACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Active message to its peer. > M-ASP_INACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Inactive message to its > peer. > > Is this an RFC fault? No. SCCP also requires local management. N-STATE request is not an SCCP/SCCP-User primitive. It is an SCCP/SCCP Management primitive. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 11:22:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzmV-0006kP-1x; Mon, 09 Jan 2006 11:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzmT-0006k5-NL for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 11:22:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28750 for ; Mon, 9 Jan 2006 11:20:42 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evzsz-0002W8-L4 for sigtran@ietf.org; Mon, 09 Jan 2006 11:28:46 -0500 Received: by nproxy.gmail.com with SMTP id c29so52443nfb for ; Mon, 09 Jan 2006 08:21:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qJnwfuBALKkdeX+A/Gr95E9Uk8wZmPg4iRKuqykeGBZpTXiidDMXOXsLQ4P5QuUVe4/akj0zBjBF/bWh3Z6+oKjj2p7YgxErxuWR+wjdNDfWi2gxwQM3NyUkHGdr3SS/h6UySBnr/dHIOCOswdNSKXDQdLzDHWdW6kUuKeqAtrQ= Received: by 10.48.30.17 with SMTP id d17mr919461nfd; Mon, 09 Jan 2006 08:21:57 -0800 (PST) Received: by 10.48.1.13 with HTTP; Mon, 9 Jan 2006 08:21:57 -0800 (PST) Message-ID: <17b146d60601090821v6956a220w3380c9affb8c4011@mail.gmail.com> Date: Mon, 9 Jan 2006 17:21:57 +0100 From: Ilie Glib To: bidulock@openss7.org, Ilie Glib , SIGTRAN Subject: Re: [Sigtran] Upper boundary of Adaptation Layers In-Reply-To: <20060109081933.A10655@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> <20060109081933.A10655@openss7.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Brian, I can not agree with you that SUA enables applications to use IP addresses. Indeed Source and Destination addresses can contain IP addresses, but this is an implicit impact on the xxUA users rather than an explicit impact. Currently section "1.6.1. Definition of the upper boundary" does not extend SS7 primitives. If this extension is wanted it shall be in the standard documents (RFCs). Apropos Source and Destination addresses cannot contain hostnames. IMHO hostnames are much more usefull than IP addresses. If it is wanted that xxUA become a true standard the content of the upper boundary shall be defined down to the last bit. what do you mean by > It is not necessarily true for the multiple SG as STP scenario, ? See below for one more question. Thank you in advance Ilie On 1/9/06, Brian F. G. Bidulock wrote: > Ilie, > > This can be true for the strict backhaul scenario. [Ilie] Do you mean SGP to ASP interface (assuming ASP does not have relay capability)? > It is not necessarily true for the multiple SG as STP scenario, nor IPSP, > nor for SCCP Relay. SUA already defines an enhanced SUA User > that can use IP addresses or Host names in called or calling > party addresses, and is thus aware of SUA. > > --brian > > Ilie Glib wrote: (Mon, 09 Jan 2006 16:07:00) > > Hello Folks, > > > > In my current understanding of the SIGTRAN: > > > > - SUA and M3UA RFCs define the primitives of the adaptation layers > > towards their users in Section "1.6.1. Definition of the upper > > boundary". > > SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the > > complete definition of the primitives towards the users, therefore > > SIGTRAN supports existing > > SCCP/MTP users without them being aware of the fact that SIGTRAN is > > used for the transport of messages. > > SIGTRAN concepts and the corresponding entities/objects like AS, RK, > > RC, IPSP, ASP, and SGP are not part of the currently standardized > > upper boundary of M3UA (SUA). > > Thus today's SIGTRAN users do not know anything about those concepts. > > > > Can you please confirm this view or tell me if I'm mislead by my > > interpretation ? > > > > Is their any attempt in SIGTRAN WG to define an extended upper > > boundary for xxUA that gives the option of managing entities like AS, > > RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced > > services expected from adaptation layers ? > > > > 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/ > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 11:36:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew00p-0002wW-Jc; Mon, 09 Jan 2006 11:36:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew00o-0002wR-6a for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 11:36:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29849 for ; Mon, 9 Jan 2006 11:35:31 -0500 (EST) Received: from web35404.mail.mud.yahoo.com ([66.163.179.113]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew07K-00030K-TC for sigtran@ietf.org; Mon, 09 Jan 2006 11:43:35 -0500 Received: (qmail 41926 invoked by uid 60001); 9 Jan 2006 16:36:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pGLzWivSmRgs4qTzYoxW1a960+x9AdMyjAZCbB/rS9vEYMC2AW3JoR1AmSYd0m3OrFMehg4em+QkxsOAjvbv/GowtVHRtJYin2+XcQPt/5DO4rDfpZowDgRcTVRTY4sDJ5/qnpbzaSdp0tv53i7tPOGXCmOrroZBkukjXjPnAjo= ; Message-ID: <20060109163640.41923.qmail@web35404.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35404.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2006 08:36:40 PST Date: Mon, 9 Jan 2006 08:36:40 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers To: SIGTRAN In-Reply-To: <20060109083407.A10921@openss7.org> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0259302837==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0259302837== Content-Type: multipart/alternative; boundary="0-540456303-1136824600=:38999" Content-Transfer-Encoding: 8bit --0-540456303-1136824600=:38999 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Brian, Tolga, Brian, are you saying that SCCP-user function is not owner of the management of its resources, i.e. user function does not own control if/how/when it can withdraw from the traffic? For example an SCCP-user application in ISDN networks installed in an SCCP-subsystem has to do certain checks when and how and if it can withdraw from the traffic, and another SCCP-user application in WCDMA networks installed in an SCCP-subsystem performs other checks different from the first ones. So these cheks cannot be part of SCCP and for this reason ITU-T puts it in SCCP-user applications by introducing N-STATE_request primitive. Are you saying that SUA layer (which should replace SCCP) should own command which is to remove an SCCP-user from traffic (i.e. generate ASP_INACTIVE message)? If so how do you make your SUA box/layer application independet since each application has its own checks and actions performed when withdrawing from the traffic? Tolga, I read your comments on the question posted on 4th of November by Prasad Shashank at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05292.html and answers from you at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05295.html and http://www1.ietf.org/mail-archive/web/sigtran/current/msg05297.html. I completely agree with you but in order to make it clear I just want to make it more explicit: 1) Is the user application the entitiy which sends traffic from a local ASP/IPSP or it is in xxUA "box/layer" responsiblity which is to be indepednet on applications and which decides which local (!) IPSP/ASP to use. In other words is it that you have one application supported by xxUA box/layer and within this xxUA box/layer you have 2 or more local IPSP/ASP processes and it is then in this xxUA box/layer responisbility to chose right ASP/IPSP? In my view you install an application in a process and when this applicaton clone generates traffic it is unambiguous which local ASP/IPSP to use since the local process is application resource (clone). Please confirm or deny my understanding. 2) In my view xxUA is not a box/layer but only a set of protocls (ASP-SGP and IPSP-IPSP). ASP/IPSP is a user application entity own and controlled by the application. However possibly being wrong I need answer on this -> is it true that xxUA specifications manadate (!) that there must (!) be a layer/box which is to own control on which local ASP/IPSP to use when sending traffic. 3) I kindly ask you to comment SUA example above and Brian's point about the fact that applications do not own control on their wiothdrawal from or statrting of traffic. many thanks and regards/ stanislav "Brian F. G. Bidulock" wrote: Stanislav, Stanislav Ivanovich wrote: (Mon, 09 Jan 2006 07:27:17) ---X-snip-X--- > > M-ASP_ACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Active message to its peer. > M-ASP_INACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Inactive message to its > peer. > > Is this an RFC fault? No. SCCP also requires local management. N-STATE request is not an SCCP/SCCP-User primitive. It is an SCCP/SCCP Management primitive. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-540456303-1136824600=:38999 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Brian, Tolga,
 
Brian, are you saying that SCCP-user function is not owner of the management of its resources, i.e. user function does not own control if/how/when it can withdraw from the traffic?
 
For example an SCCP-user application in ISDN networks installed in an SCCP-subsystem has to do certain checks when and how and if it can withdraw from the traffic, and another SCCP-user application in WCDMA networks installed in an SCCP-subsystem performs other checks different from the first ones. So these cheks cannot be part of SCCP and for this reason ITU-T puts it in SCCP-user applications by introducing N-STATE_request primitive. Are you saying that SUA layer (which should replace SCCP) should own command which is to remove an SCCP-user from traffic (i.e. generate ASP_INACTIVE message)? If so how do you make your SUA box/layer application independet since each application has its own chec! ks and actions performed when withdrawing from the traffic?
 
 
 
I completely agree with you but in order to make it clear I just want to make it more explicit:
 
1) Is the user application the entitiy which sends tr! affic from a local ASP/IPSP or it is in xxUA "box/layer" responsiblity which is to be indepednet on applications and which decides which local (!) IPSP/ASP to use.
In other words is it that you have one application supported by xxUA box/layer and within this xxUA box/layer you have 2 or more local IPSP/ASP processes and it is then in this xxUA box/layer responisbility to chose right ASP/IPSP?
 
In my view you install an application in a process and when this applicaton clone generates traffic it is unambiguous which local ASP/IPSP to use since the local process is application resource (clone). Please confirm or deny my understanding.
 
 
2) In my view xxUA is not a box/layer but only a set of protocls (ASP-SGP and IPSP-IPSP). ASP/IPSP is a user application entity own and controlled by the application. However possibly being wrong I need answer on this -> is it! true that xxUA specifications manadate (!) that there must (!) be a layer/box which is to own control on which local ASP/IPSP to use when sending traffic.
 
3) I kindly ask you to comment SUA example above and Brian's point about the fact that applications do not own control on their wiothdrawal from or statrting of traffic.
 
many thanks and regards/ stanislav
 


"Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
Stanislav,

Stanislav Ivanovich wrote: (Mon, 09 Jan 2006 07:27:17)

---X-snip-X---
>
> M-ASP_ACTIVE request
> Direction: LM -> SUA
> Purpose: LM requests ASP to send an ASP Active message to its peer.
> M-ASP_INACTIVE request
> Direction: LM -> SUA
> Purpose: LM requests ASP ! to send an ASP Inactive message to its
> peer.
>
> Is this an RFC fault?

No. SCCP also requires local management. N-STATE request is not an
SCCP/SCCP-User primitive. It is an SCCP/SCCP Management primitive.

--brian

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

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-540456303-1136824600=:38999-- --===============0259302837== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0259302837==-- From sigtran-bounces@ietf.org Mon Jan 09 11:38:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew02m-00039p-9O; Mon, 09 Jan 2006 11:38:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew02l-00039a-2v for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 11:38:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29976 for ; Mon, 9 Jan 2006 11:37:32 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew09H-00034G-5o for sigtran@ietf.org; Mon, 09 Jan 2006 11:45:36 -0500 Received: by nproxy.gmail.com with SMTP id c29so55310nfb for ; Mon, 09 Jan 2006 08:38:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HunDj9Gt5BY2louOK11VQDxEMk20Y2AOlsCO2kmzsbx/3Wlst0ZtN7sF1V0Mqovd+gK2oKtoq1AhV+rH5ExeUEklueqTwmKpvhlPEL+mjrtX7pabF8dmr2L0aHqNH8UpoJGxCnfyp6nMumeS1nPm+0S0iF1o/5wsF7fqNIuZeng= Received: by 10.49.94.7 with SMTP id w7mr352590nfl; Mon, 09 Jan 2006 08:38:15 -0800 (PST) Received: by 10.48.1.13 with HTTP; Mon, 9 Jan 2006 08:38:15 -0800 (PST) Message-ID: <17b146d60601090838y64223824l29b68fc7719e0419@mail.gmail.com> Date: Mon, 9 Jan 2006 17:38:15 +0100 From: Ilie Glib To: Barry Nagelberg Subject: Re: [Sigtran] Upper boundary of Adaptation Layers In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Barry, thank you for your answer. I agree 100% with your statements. My intention was to stress that current SIGTRAN RFCs do not extend SS7 primitives, and as a consequence do not put any requirements on the user applications. In case an extension of SS7 primitives is wanted this extension shall be documented in IETF standards. For instance the draft-asveren-sigtran-m3uaipsp-00.txt may be the right place to document such extensions of services that M3UA Layer provides to its users in IPSP to IPSP scenario. Regards Ilie On 1/9/06, Barry Nagelberg wrote: > Ilie, > > Your summary of the current architecture is mostly correct. > > The most important part of your summary is that "SIGTRAN supports existin= g SCCP/MTP users without them being aware of > the fact that SIGTRAN is used for the transport of messages." > > This is the entire reason for the existance of SIGTRAN. SIGTRAN is a brid= ging mechanism designed to allow legacy > SCCP/MTP3 users to take advantage of cheap IP transport without having to= modify their legacy protocol stacks. > > Any attempt to make SCCP/MTP3 users aware of SIGTRAN would make SIGTRAN a= lmost worthless. > > Barry Nagelberg > Adax, Inc. > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Ilie Glib > Sent: Monday, January 09, 2006 10:07 AM > To: SIGTRAN > Subject: [Sigtran] Upper boundary of Adaptation Layers > > > Hello Folks, > > In my current understanding of the SIGTRAN: > > - SUA and M3UA RFCs define the primitives of the adaptation layers > towards their users in Section "1.6.1. Definition of the upper > boundary". > SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the > complete definition of the primitives towards the users, therefore > SIGTRAN supports existing > SCCP/MTP users without them being aware of the fact that SIGTRAN is > used for the transport of messages. > SIGTRAN concepts and the corresponding entities/objects like AS, RK, > RC, IPSP, ASP, and SGP are not part of the currently standardized > upper boundary of M3UA (SUA). > Thus today's SIGTRAN users do not know anything about those concepts. > > Can you please confirm this view or tell me if I'm mislead by my > interpretation ? > > Is their any attempt in SIGTRAN WG to define an extended upper > boundary for xxUA that gives the option of managing entities like AS, > RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced > services expected from adaptation layers ? > > Thank you in advance > > -- > Ilie > > _______________________________________________ > 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 > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 11:46:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0AH-0005lG-3A; Mon, 09 Jan 2006 11:46:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0AF-0005l6-Qp for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 11:46:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00514 for ; Mon, 9 Jan 2006 11:45:17 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew0Gj-0003JC-It for sigtran@ietf.org; Mon, 09 Jan 2006 11:53:18 -0500 Received: from nproxy.gmail.com ([64.233.182.201]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ew0AB-0006SO-HK for sigtran@ietf.org; Mon, 09 Jan 2006 11:46:31 -0500 Received: by nproxy.gmail.com with SMTP id l23so55724nfc for ; Mon, 09 Jan 2006 08:44:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PfGRY/4wHaLef0KovVgE45HiznRoeNCZ7tpIBCIn19r4RjVIaCNNxMuwMjNJsuwux5MaZr1bO8BBERTnly//Lu3R7owwm7AjDcvGMyFLcBDMTYCq4tW8r5SJm3jwXXxf67AhWk9P/igC+2Bj4s2upBqPDl++tSLA5x9K4TZA5uU= Received: by 10.48.247.14 with SMTP id u14mr921953nfh; Mon, 09 Jan 2006 08:44:59 -0800 (PST) Received: by 10.48.1.13 with HTTP; Mon, 9 Jan 2006 08:44:59 -0800 (PST) Message-ID: <17b146d60601090844n300cd1b2k7916960ac88140b5@mail.gmail.com> Date: Mon, 9 Jan 2006 17:44:59 +0100 From: Ilie Glib To: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers In-Reply-To: <20060109152717.42154.qmail@web35403.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> <20060109152717.42154.qmail@web35403.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Stanislav, On 1/9/06, Stanislav Ivanovich wrote: > Hello, > > Since I find Ilie's questions ambiguous I will extend his questions by > asking: > > 1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP > process states) indepdnednetly on MTP-user or SCCP-user applications by > making these applications idendepndtz on the ASP/IPSP state? > [Ilie] I have not questioned that, in my view this is a fact written in stone (RFCs). check e.g. the SIGTRAN applicability draft: http://tools.ietf.org/html/draft-ietf-sigtran-signalling-over-sctp-applic-0= 9.txt > 2) If such layer exisits and if M3UA and SUA are not just and only protoc= ls > but also boxes/layers which have a place in the signalling system which i= s > to isolate user functions on ASP/IPSP state shold such layer own the cont= rol > on ASP/IPSP states? > > For example SCCP subsystem does not want to handle traffic. In legacy > systems SCCP-user applications own the control on the SCCP-subsystem stat= e > change thus they control appaearance on N-STATE_request primitive on SCCP > API. > However if one thinks that xxUA is not just a set of protocls (ASP-SGP an= d > IPSP-IPSP) but also a box which contains a functionality which is to isol= ate > user functions on SIGTRAN concepts (like ASP/IPSP) does that imply that s= uch > box should own commands for AS state change, i.e. it is SUA box but not S= CCP > user function which owns control on AS state change, see section 1.6.3. i= n > xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Manageme= nt: > > M-ASP_ACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Active message to its peer. > M-ASP_INACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Inactive message to its > peer. > > Is this an RFC fault? > > > regards/ stanislav > > > Ilie Glib wrote: > Hello Folks, > > In my current understanding of the SIGTRAN: > > - SUA and M3UA RFCs define the primitives of the adaptation layers > towards their users in Section "1.6.1. Definition of the upper > boundary". > SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the > complete definition of the primitives towards the users, therefore > SIGTRAN supports existing > SCCP/MTP users without them being aware of the fact that SIGTRAN is > used for the transport of messages. > SIGTRAN concepts and the corresponding entities/objects like AS, RK, > RC, IPSP, ASP, and SGP are not part of the currently standardized > upper boundary of M3UA (SUA). > Thus today's SIGTRAN users do not know anything about those concepts. > > Can you please confirm this view or tell me if I'm mislead by my > interpretation ? > > Is their any attempt in SIGTRAN WG to define! an extended upper > boundary for xxUA that gives the option of managing entities like AS, > RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced > services expected from adaptation layers ? > > Thank you in advance > > -- > Ilie > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > > ________________________________ > Yahoo! Photos > Ring in the New Year with Photo Calendars. Add photos, events, holidays, > whatever. > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 11:49:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0D2-00066h-9k; Mon, 09 Jan 2006 11:49:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0D0-00066a-Uv for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 11:49:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00680 for ; Mon, 9 Jan 2006 11:48:08 -0500 (EST) Received: from web35407.mail.mud.yahoo.com ([66.163.179.116]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew0JY-0003Mu-0u for sigtran@ietf.org; Mon, 09 Jan 2006 11:56:12 -0500 Received: (qmail 34720 invoked by uid 60001); 9 Jan 2006 16:48:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fYuZ8ECwogrycz8AqdMluS2heZ7Zd8AqHv4RRdgzfnCD0XIM7CSIlPWVak7gzZVSjARvyXb9BjnSewT9G1bKPaf/My5utIj0Kp80mGMiP/lJnS01/Ik8vRfUG/N1ErlO1mu08eVyexh1K2UXvVAVuZbIAXIpjhnn1denrh5z+iw= ; Message-ID: <20060109164803.34718.qmail@web35407.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35407.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2006 08:48:03 PST Date: Mon, 9 Jan 2006 08:48:03 -0800 (PST) From: Stanislav Ivanovich Subject: RE: [Sigtran] Upper boundary of Adaptation Layers To: SIGTRAN In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1040267810==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1040267810== Content-Type: multipart/alternative; boundary="0-1114893862-1136825283=:30914" Content-Transfer-Encoding: 8bit --0-1114893862-1136825283=:30914 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Barry, Which entitiy controls the start and removal of application from traffic? Is it MTP/SCCP or User Parts/SCCP-users? When for example SCCP-user requests N-STATE_request which is to be translated into ASP-INACTIVE who controls the AS state? Is it SUA "layer" or SCCP-user application? regards/ Stanislav Barry Nagelberg wrote: Ilie, Your summary of the current architecture is mostly correct. The most important part of your summary is that "SIGTRAN supports existing SCCP/MTP users without them being aware of the fact that SIGTRAN is used for the transport of messages." This is the entire reason for the existance of SIGTRAN. SIGTRAN is a bridging mechanism designed to allow legacy SCCP/MTP3 users to take advantage of cheap IP transport without having to modify their legacy protocol stacks. Any attempt to make SCCP/MTP3 users aware of SIGTRAN would make SIGTRAN almost worthless. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Ilie Glib Sent: Monday, January 09, 2006 10:07 AM To: SIGTRAN Subject: [Sigtran] Upper boundary of Adaptation Layers Hello Folks, In my current understanding of the SIGTRAN: - SUA and M3UA RFCs define the primitives of the adaptation layers towards their users in Section "1.6.1. Definition of the upper boundary". SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the complete definition of the primitives towards the users, therefore SIGTRAN supports existing SCCP/MTP users without them being aware of the fact that SIGTRAN is used for the transport of messages. SIGTRAN concepts and the corresponding entities/objects like AS, RK, RC, IPSP, ASP, and SGP are not part of the currently standardized upper boundary of M3UA (SUA). Thus today's SIGTRAN users do not know anything about those concepts. Can you please confirm this view or tell me if I'm mislead by my interpretation ? Is their any attempt in SIGTRAN WG to define an extended upper boundary for xxUA that gives the option of managing entities like AS, RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced services expected from adaptation layers ? Thank you in advance -- Ilie _______________________________________________ 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 --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-1114893862-1136825283=:30914 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Barry,
 
Which entitiy controls the start and removal of application from traffic? Is it MTP/SCCP or User Parts/SCCP-users?
 
When for example SCCP-user requests N-STATE_request which is to be translated into ASP-INACTIVE who controls the AS state? Is it SUA "layer" or SCCP-user application?
 
regards/ Stanislav
 


Barry Nagelberg <barryn@adax.com> wrote:
Ilie,

Your summary of the current architecture is mostly correct.

The most important part of your summary is that "SIGTRAN supports existing SCCP/MTP users without them being aware of
the fact that SIGTRAN is used for the transport of messages."

This is the entire reason for the existance of SIGTRAN. SIGTRAN is a bridging mechanism designed to allow legacy
SCCP/MTP3 users to take advantage of cheap IP transport without having to modify their legacy protocol stacks.

Any attempt to make SCCP/MTP3 users aware of SIGTRAN would make SIGTRAN almost worthless.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On
Behalf Of Ilie Glib
Sent: Monday, January 09, 2006 10:07 AM
To: SIGTRAN
Subject: [Sigtran] Upper boundary of Adaptation Layers


Hello Folks,

In my current understanding of the SIGTRAN:

- SUA and M3UA RFCs define the primitives of the adaptation layers
towards their users in Section "1.6.1. Definition of the upper
boundary".
SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the
complete definition of the primitives towards the users, therefore
SIGTRAN supports existing
SCCP/MTP users without them being aware of the fact that SIGTRAN is
used for the trans! port of messages.
SIGTRAN concepts and the corresponding entities/objects like AS, RK,
RC, IPSP, ASP, and SGP are not part of the currently standardized
upper boundary of M3UA (SUA).
Thus today's SIGTRAN users do not know anything about those concepts.

Can you please confirm this view or tell me if I'm mislead by my
interpretation ?

Is their any attempt in SIGTRAN WG to define an extended upper
boundary for xxUA that gives the option of managing entities like AS,
RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced
services expected from adaptation layers ?

Thank you in advance

--
Ilie

_______________________________________________
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

Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-1114893862-1136825283=:30914-- --===============1040267810== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1040267810==-- From sigtran-bounces@ietf.org Mon Jan 09 11:54:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0HY-0006sh-0F; Mon, 09 Jan 2006 11:54:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0HU-0006sD-ML for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 11:54:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01185 for ; Mon, 9 Jan 2006 11:52:45 -0500 (EST) Received: from web35401.mail.mud.yahoo.com ([66.163.179.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew0O1-0003YG-Ic for sigtran@ietf.org; Mon, 09 Jan 2006 12:00:50 -0500 Received: (qmail 45863 invoked by uid 60001); 9 Jan 2006 16:53:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HSMAVpYm7vBJ1yDYlIg2uecDYXAj7puebi6XHvHF7bUvBglWQ4uiieZjKiRpEZqFCckklWDYGylrTEdCpGGqGTxstbFFu+CanAjf1DOr19IyVqNeKGSw7XSeV8wQyMUQxUcfdAFPZtLI/g/f55YAPvZqlFfpFz077CGvwpCdrQc= ; Message-ID: <20060109165355.45861.qmail@web35401.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35401.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2006 08:53:55 PST Date: Mon, 9 Jan 2006 08:53:55 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers To: SIGTRAN In-Reply-To: <17b146d60601090844n300cd1b2k7916960ac88140b5@mail.gmail.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1088706368==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1088706368== Content-Type: multipart/alternative; boundary="0-2040975039-1136825635=:33941" Content-Transfer-Encoding: 8bit --0-2040975039-1136825635=:33941 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Ilie, Please first let us hear Tolga and Brian on my last mail about this issue. If you now claim that you didn't question that user function should own control for activation/deactivation of AS please tell us what was your point in this question that you sent me on my private mail and which I simply copy/pasted and forwarded: ------------------------------------------------------------------------------------------------------------------- [Ilie Glib] After all what is the point for ASP Activation commands in xxUA layers (see section 1.6.3. in xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management) M-ASP_ACTIVE request Direction: LM -> SUA Purpose: LM requests ASP to send an ASP Active message to its peer. M-ASP_INACTIVE request Direction: LM -> SUA Purpose: LM requests ASP to send an ASP Inactive message to its peer. Is this an RFC fault? ------------------------------------------------------------------------------------------------------------------- /stanislav Ilie Glib wrote: Hello Stanislav, On 1/9/06, Stanislav Ivanovich wrote: > Hello, > > Since I find Ilie's questions ambiguous I will extend his questions by > asking: > > 1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP > process states) indepdnednetly on MTP-user or SCCP-user applications by > making these applications idendepndtz on the ASP/IPSP state? > [Ilie] I have not questioned that, in my view this is a fact written in stone (RFCs). check e.g. the SIGTRAN applicability draft: http://tools.ietf.org/html/draft-ietf-sigtran-signalling-over-sctp-applic-09.txt > 2) If such layer exisits and if M3UA and SUA are not just and only protocls > but also boxes/layers which have a place in the signalling system which is > to isolate user functions on ASP/IPSP state shold such layer own the control > on ASP/IPSP states? > > For example SCCP subsystem does not want to handle traffic. In legacy > systems SCCP-user applications own the control on the SCCP-subsystem state > change thus they control appaearance on N-STATE_request primitive on SCCP > API. > However if one thinks that xxUA is not just a set of protocls (ASP-SGP and > IPSP-IPSP) but also a box which contains a functionality which is to isolate > user functions on SIGTRAN concepts (like ASP/IPSP) does that imply that such > box should own commands for AS state change, i.e. it is SUA box but not SCCP > user function which owns control on AS state change, see section 1.6.3. in > xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management: > > M-ASP_ACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Active message to its peer. > M-ASP_INACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Inactive message to its > peer. > > Is this an RFC fault? > > > regards/ stanislav > > > Ilie Glib wrote: > Hello Folks, > > In my current understanding of the SIGTRAN: > > - SUA and M3UA RFCs define the primitives of the adaptation layers > towards their users in Section "1.6.1. Definition of the upper > boundary". > SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the > complete definition of the primitives towards the users, therefore > SIGTRAN supports existing > SCCP/MTP users without them being aware of the fact that SIGTRAN is > used for the transport of messages. > SIGTRAN concepts and the corresponding entities/objects like AS, RK, > RC, IPSP, ASP, and SGP are not part of the currently standardized > upper boundary of M3UA (SUA). > Thus today's SIGTRAN users do not know anything about those concepts. > > Can you please confirm this view or tell me if I'm mislead by my > interpretation ? > > Is their any attempt in SIGTRAN WG to define! an extended upper > boundary for xxUA that gives the option of managing entities like AS, > RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced > services expected from adaptation layers ? > > Thank you in advance > > -- > Ilie > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > > ________________________________ > Yahoo! Photos > Ring in the New Year with Photo Calendars. Add photos, events, holidays, > whatever. > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > -- Ilie --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-2040975039-1136825635=:33941 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello Ilie,
 
Please first let us hear Tolga and Brian on my last mail about this issue.
 
If you now claim that you didn't question that user function should own control for activation/deactivation of AS please tell us what was your point in this question that you sent me on my private mail and which I simply copy/pasted and forwarded:
 
-------------------------------------------------------------------------------------------------------------------
[Ilie Glib] After all what is the point for ASP Activation commands in xxUA layers (see section 1.6.3. in xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management)
M-ASP_ACTIVE request
Direction: LM -> SUA
Purpose: LM requests ASP to send an ASP Active message to its peer.
M-ASP_INACTIVE request
Direction: LM -> SUA
Purpose: LM requests ASP to send an ASP Inactive message to its
peer.
Is this an RFC fault?
-------------------------------------------------------------------------------------------------------------------
 
 
/stanislav
 


Ilie Glib <ilie.glib@googlemail.com> wrote:
Hello Stanislav,

On 1/9/06, Stanislav Ivanovich wrote:
> Hello,
>
> Since I find Ilie's questions ambiguous I will extend his questions by
> asking:
>
> 1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP
> process states) indepdnednetly on MTP-user or SCCP-user applications by
> making these applications idendepndtz on the ASP/IPSP state?
>

[Ilie] I have not questioned that, in my view this is a fact written
in stone (RFCs).
check e.g. the SIGTRAN applicability draft:
http://tools.ietf.org/html/draft-ietf-sigtran-signalling-over-sctp-applic-09.txt

> 2) If such layer exisits and if M3UA and SUA are not just and only protocls
> but also boxes/layers which have a place in the signalling system which is
> to isolate user functions on ASP/IPSP state shold such layer own the control
> on ASP/IPSP states?
>
> For example SCCP subsystem does not want to handle traffic. In legacy
> systems SCCP-user applications own the control on the SCCP-subsystem state
> change thus they control appaearance on N-STATE_request primitive on SCCP
> API.
> However if one thinks that xxUA is not just a set of protocls (ASP-SGP and
> IPSP-IPSP) but also a box which contains a functionality which is to isolate
> user functions on SIGT! RAN concepts (like ASP/IPSP) does that imply that such
> box should own commands for AS state change, i.e. it is SUA box but not SCCP
> user function which owns control on AS state change, see section 1.6.3. in
> xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management:
>
> M-ASP_ACTIVE request
> Direction: LM -> SUA
> Purpose: LM requests ASP to send an ASP Active message to its peer.
> M-ASP_INACTIVE request
> Direction: LM -> SUA
> Purpose: LM requests ASP to send an ASP Inactive message to its
> peer.
>
> Is this an RFC fault?
>
>
> regards/ stanislav
>
>
> Ilie Glib wrote:
> Hello Folks,
>
> In my current understanding of the SIGTRAN:
>
> - SUA and M3UA RFCs define the primitives of the adaptation layers
> towards their users in Section "1.6.1. Definition of the upper
> boundary".
> SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the
> complete definition of the primitives towards the users, therefore
> SIGTRAN supports existing
> SCCP/MTP users without them being aware of the fact that SIGTRAN is
> used for the transport of messages.
> SIGTRAN concepts and the corresponding entities/objects like AS, RK,
> RC, IPSP, ASP, and SGP are not part of the currently standardized
> upper boundary of M3UA (SUA).
> Thus today's SIGTRAN users do not know anything about those concepts.
>
> Can you please confirm this view or tell me if I'm mislead by my
> interpretation ?
>
> Is their any attempt in SIGTRAN WG to define! an extended upper
> boundary for xxUA that gives the option of managing entities like AS,
> RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced
> services expected from adaptation layers ?
>
> ! Thank you in advance
>
> --
> Ilie
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
> ________________________________
> Yahoo! Photos
> Ring in the New Year with Photo Calendars. Add photos, events, holidays,
> whatever.
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>


--
Ilie

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-2040975039-1136825635=:33941-- --===============1088706368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1088706368==-- From sigtran-bounces@ietf.org Mon Jan 09 12:01:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0OF-0008O7-IF; Mon, 09 Jan 2006 12:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0OD-0008Na-7O for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 12:01:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01690 for ; Mon, 9 Jan 2006 11:59:42 -0500 (EST) Received: from phl-28-b-170.phl.dsl.cerfnet.com ([63.242.157.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew0Uh-0003lk-5W for sigtran@ietf.org; Mon, 09 Jan 2006 12:07:46 -0500 Received: from bn001320 (bn001320 [192.168.1.61]) by phl-28-b-170.phl.dsl.cerfnet.com (8.12.8/8.12.8) with SMTP id k09H0soj003610 for ; Mon, 9 Jan 2006 12:00:55 -0500 From: "Barry Nagelberg" To: "SIGTRAN" Subject: RE: [Sigtran] Upper boundary of Adaptation Layers Date: Mon, 9 Jan 2006 12:02:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060109164803.34718.qmail@web35407.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Both entities. You are describing an API msg (N-STATE req) and the resulting SUA action. The critical part is that the SCCP-user doesn't know (and shouldn't know) how the API msg is handled "under the hood". Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Monday, January 09, 2006 11:48 AM To: SIGTRAN Subject: RE: [Sigtran] Upper boundary of Adaptation Layers Barry, Which entitiy controls the start and removal of application from traffic? Is it MTP/SCCP or User Parts/SCCP-users? When for example SCCP-user requests N-STATE_request which is to be translated into ASP-INACTIVE who controls the AS state? Is it SUA "layer" or SCCP-user application? regards/ Stanislav Barry Nagelberg wrote: Ilie, Your summary of the current architecture is mostly correct. The most important part of your summary is that "SIGTRAN supports existing SCCP/MTP users without them being aware of the fact that SIGTRAN is used for the transport of messages." This is the entire reason for the existance of SIGTRAN. SIGTRAN is a bridging mechanism designed to allow legacy SCCP/MTP3 users to take advantage of cheap IP transport without having to modify their legacy protocol stacks. Any attempt to make SCCP/MTP3 users aware of SIGTRAN would make SIGTRAN almost worthless. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Ilie Glib Sent: Monday, January 09, 2006 10:07 AM To: SIGTRAN Subject: [Sigtran] Upper boundary of Adaptation Layers Hello Folks, In my current understanding of the SIGTRAN: - SUA and M3UA RFCs define the primitives of the adaptation layers towards their users in Section "1.6.1. Definition of the upper boundary". SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the complete definition of the primitives towards the users, therefore SIGTRAN supports existing SCCP/MTP users without them being aware of the fact that SIGTRAN is used for the trans! port of messages. SIGTRAN concepts and the corresponding entities/objects like AS, RK, RC, IPSP, ASP, and SGP are not part of the currently standardized upper boundary of M3UA (SUA). Thus today's SIGTRAN users do not know anything about those concepts. Can you please confirm this view or tell me if I'm mislead by my interpretation ? Is their any attempt in SIGTRAN WG to define an extended upper boundary for xxUA that gives the option of managing entities like AS, RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced services expected from adaptation layers ? Thank you in advance -- Ilie _______________________________________________ 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 Yahoo! DSL Something to write home about. Just $16.99/mo. or less _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 12:16:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0cJ-0004Y8-0y; Mon, 09 Jan 2006 12:15:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0cI-0004XW-5l for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 12:15:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04042 for ; Mon, 9 Jan 2006 12:14:15 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew0ip-0004cf-6T for sigtran@ietf.org; Mon, 09 Jan 2006 12:22:19 -0500 Received: by nproxy.gmail.com with SMTP id n28so140088nfc for ; Mon, 09 Jan 2006 09:15:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HIWtk9GhFfbTe7WczM8l9X3ypYJ3nublq1xUN1Jf9+nLA5hBvyMnpldCt2cQ7YR73LTMOAksLTaodFiLdxMPkIPhHzPIP+mEaBXurbXrEUne9pff7nj/XlEyLa/5aj0YDxEt7bKNM6VK4F3Vyr3E8dA+Uot93gJRigTE1/Af0Cg= Received: by 10.48.163.10 with SMTP id l10mr925233nfe; Mon, 09 Jan 2006 09:15:27 -0800 (PST) Received: by 10.48.1.13 with HTTP; Mon, 9 Jan 2006 09:15:27 -0800 (PST) Message-ID: <17b146d60601090915r5d9e3bceo2f299e4e8da02f9e@mail.gmail.com> Date: Mon, 9 Jan 2006 18:15:27 +0100 From: Ilie Glib To: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers In-Reply-To: <20060109165355.45861.qmail@web35401.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17b146d60601090844n300cd1b2k7916960ac88140b5@mail.gmail.com> <20060109165355.45861.qmail@web35401.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, I did not want to post this question on the SIGTRAN list. I do not have any doubts that SUA, or M3UA layers can activate and deactivate ASPs on request from SUA/M3UA Layer Management On 1/9/06, Stanislav Ivanovich wrote: > Hello Ilie, > > Please first let us hear Tolga and Brian on my last mail about this issue= . > > If you now claim that you didn't question that user function should own > control for activation/deactivation of AS please tell us what was your po= int > in this question that you sent me on my private mail and which I simply > copy/pasted and forwarded: > > -------------------------------------------------------------------------= ------------------------------------------ > [Ilie Glib] After all what is the point for ASP Activation commands in xx= UA > layers (see section 1.6.3. in xxUA RFCs, e.g. Definition of the Boundary > between SUA and Layer Management) > M-ASP_ACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Active message to its peer. > M-ASP_INACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Inactive message to its > peer. > Is this an RFC fault? > -------------------------------------------------------------------------= ------------------------------------------ > > > /stanislav > > > > Ilie Glib wrote: > Hello Stanislav, > > On 1/9/06, Stanislav Ivanovich wrote: > > Hello, > > > > Since I find Ilie's questions ambiguous I will extend his questions by > > asking: > > > > 1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP > > process states) indepdnednetly on MTP-user or SCCP-user applications by > > making these applications idendepndtz on the ASP/IPSP state? > > > > [Ilie] I have not questioned that, in my view this is a fact written > in stone (RFCs). > check e.g. the SIGTRAN applicability draft: > http://tools.ietf.org/html/draft-ietf-sigtran-signalling-over-sctp-applic= -09.txt > > > 2) If such layer exisits and if M3UA and SUA are not just and only > protocls > > but also boxes/layers which have a place in the signalling system which= is > > to isolate user functions on ASP/IPSP state shold such layer own the > control > > on ASP/IPSP states? > > > > For example SCCP subsystem does not want to handle traffic. In legacy > > systems SCCP-user applications own the control on the SCCP-subsystem st= ate > > change thus they control appaearance on N-STATE_request primitive on SC= CP > > API. > > However if one thinks that xxUA is not just a set of protocls (ASP-SGP = and > > IPSP-IPSP) but also a box which contains a functionality which is to > isolate > > user functions on SIGT! RAN concepts (like ASP/IPSP) does that imply th= at > such > > box should own commands for AS state change, i.e. it is SUA box but not > SCCP > > user function which owns control on AS state change, see section 1.6.3.= in > > xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer > Management: > > > > M-ASP_ACTIVE request > > Direction: LM -> SUA > > Purpose: LM requests ASP to send an ASP Active message to its peer. > > M-ASP_INACTIVE request > > Direction: LM -> SUA > > Purpose: LM requests ASP to send an ASP Inactive message to its > > peer. > > > > Is this an RFC fault? > > > > > > regards/ stanislav > > > > > > Ilie Glib wrote: > > Hello Folks, > > > > In my current understanding of the SIGTRAN: > > > > - SUA and M3UA RFCs define the primitives of the adaptation layers > > towards their users in Section "1.6.1. Definition of the upper > > boundary". > > SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the > > complete definition of the primitives towards the users, therefore > > SIGTRAN supports existing > > SCCP/MTP users without them being aware of the fact that SIGTRAN is > > used for the transport of messages. > > SIGTRAN concepts and the corresponding entities/objects like AS, RK, > > RC, IPSP, ASP, and SGP are not part of the currently standardized > > upper boundary of M3UA (SUA). > > Thus today's SIGTRAN users do not know anything about those concepts. > > > > Can you please confirm this view or tell me if I'm mislead by my > > interpretation ? > > > > Is their any attempt in SIGTRAN WG to define! an extended upper > > boundary for xxUA that gives the option of managing entities like AS, > > RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced > > services expected from adaptation layers ? > > > > ! Thank you in advance > > > > -- > > Ilie > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > ________________________________ > > Yahoo! Photos > > Ring in the New Year with Photo Calendars. Add photos, events, holidays= , > > whatever. > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > -- > Ilie > > > > ________________________________ > Yahoo! Photos > Ring in the New Year with Photo Calendars. Add photos, events, holidays, > whatever. > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 12:32:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0sR-0004kF-Lb; Mon, 09 Jan 2006 12:32:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0sQ-0004kA-Ea for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 12:32:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05593 for ; Mon, 9 Jan 2006 12:30:55 -0500 (EST) Received: from web35414.mail.mud.yahoo.com ([66.163.179.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew0yx-0005FO-L5 for sigtran@ietf.org; Mon, 09 Jan 2006 12:39:00 -0500 Received: (qmail 68452 invoked by uid 60001); 9 Jan 2006 17:32:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ETejsz1dWUhnwpIWEnTrHcesZEQCECbhfvp3Bj/qCfnhQ9xO7jPUzkv5W/ZTPa9THc2/yEnn0Sc+4NZWRlYjoOpw3UlGVS+hF4+eVPF341oXPVDplJMz8pOChHTZGHMi5hK6CwPmDOZ2Nvko8y8gRESKnszve/AlgPAsWF5qim4= ; Message-ID: <20060109173204.68450.qmail@web35414.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35414.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2006 09:32:04 PST Date: Mon, 9 Jan 2006 09:32:04 -0800 (PST) From: Stanislav Ivanovich Subject: RE: [Sigtran] Upper boundary of Adaptation Layers To: SIGTRAN In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145427066==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0145427066== Content-Type: multipart/alternative; boundary="0-655782810-1136827924=:68448" --0-655782810-1136827924=:68448 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA05593 Barry, =20 I agree that user applications are to be isolated from the underlaying = layers (i.e. SCTP, IP etc...). However I completely disagree that as you = say both (!) entities (i.e. MTP/SCCP and their users) control the acitvat= ion/deactivation of applications in the traffic! Instead in the legacy sy= stems (and even in pure logic) it is in application responsiblity to know= if/how/when to start/stop handling traffic. =20 In my view: =20 1) The concept "AS and Signalling Process" is a concept of redundancy o= f application resources not transmisson ones. Unlike MTP and SCCP which are desinged to solve transmisson related pro= blems M3UA and SUA are not desinged for that! They are only external prot= ocls (not some magic boxes/layers) which control only application redunda= cy. MTP and SCCP also have redundancy but there is another type of redund= acy namely transmission resource redundancy =20 2) ASP/IPSP is not transmission resource (like SGP) but instead a proce= ssing resource -> you load a particular application in one or several ASP= /IPSP'es. So each ASP/IPSP is a clone of application. i.e. each applicati= on know in advance which local IP address + port number to use since it o= s bound to that endpoint during installation. =20 3) Even in legacy systems it is in applications which control redundanc= y of applications (ie. algortihm to use when loadsahring between remote a= pplication clones is owned by applications not MTP or SCCP). =20 =20 /Stanislav Ivanovich =20 Barry Nagelberg wrote: Stanislav, Both entities. You are describing an API msg (N-STATE req) and the result= ing SUA action. The critical part is that the SCCP-user doesn't know (and shouldn't know)= how the API msg is handled "under the hood". Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf= Of Stanislav Ivanovich Sent: Monday, January 09, 2006 11:48 AM To: SIGTRAN Subject: RE: [Sigtran] Upper boundary of Adaptation Layers Barry, Which entitiy controls the start and removal of application from traffic?= Is it MTP/SCCP or User Parts/SCCP-users? When for example SCCP-user requests N-STATE_request which is to be transl= ated into ASP-INACTIVE who controls the AS state? Is it SUA "layer" or SCCP-user application? regards/ Stanislav Barry Nagelberg wrote: Ilie, Your summary of the current architecture is mostly correct. The most important part of your summary is that "SIGTRAN supports existin= g SCCP/MTP users without them being aware of the fact that SIGTRAN is used for the transport of messages." This is the entire reason for the existance of SIGTRAN. SIGTRAN is a brid= ging mechanism designed to allow legacy SCCP/MTP3 users to take advantage of cheap IP transport without having to= modify their legacy protocol stacks. Any attempt to make SCCP/MTP3 users aware of SIGTRAN would make SIGTRAN a= lmost worthless. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Ilie Glib Sent: Monday, January 09, 2006 10:07 AM To: SIGTRAN Subject: [Sigtran] Upper boundary of Adaptation Layers Hello Folks, In my current understanding of the SIGTRAN: - SUA and M3UA RFCs define the primitives of the adaptation layers towards their users in Section "1.6.1. Definition of the upper boundary". SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the complete definition of the primitives towards the users, therefore SIGTRAN supports existing SCCP/MTP users without them being aware of the fact that SIGTRAN is used for the trans! port of messages. SIGTRAN concepts and the corresponding entities/objects like AS, RK, RC, IPSP, ASP, and SGP are not part of the currently standardized upper boundary of M3UA (SUA). Thus today's SIGTRAN users do not know anything about those concepts. Can you please confirm this view or tell me if I'm mislead by my interpretation ? Is their any attempt in SIGTRAN WG to define an extended upper boundary for xxUA that gives the option of managing entities like AS, RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced services expected from adaptation layers ? Thank you in advance -- Ilie _______________________________________________ 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 Yahoo! DSL Something to write home about. Just $16.99/mo. or less _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran =20 =09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! --0-655782810-1136827924=:68448 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA05593
Barry,
 
I agree that user applications= are to be isolated from the underlaying layers (i.e. SCTP, IP etc...). H= owever I completely disagree that as you say both (!) entities (i.e. MTP/= SCCP and their users) control the acitvation/deactivation of applications= in the traffic! Instead in the legacy systems (and even in pure logic) i= t is in application responsiblity to know if/how/when to start/stop handl= ing traffic.
 
In my view:
 = ;
1) The concept "AS and Signalling Process" is a concept of = redundancy of application resources not transmisson ones.
Unl= ike MTP and SCCP which are desinged to solve transmisson related problems= M3UA and SUA are not desinged for that! They are only external protocls = (not some magic boxes/layers) which control only application redunda= cy. MTP and SCCP also have redundancy but there is another type of r= edundacy namely transmission resource redundancy
 
2) ASP/IPSP is not transmissio= n resource (like SGP) but instead a processing resource -> you load a = particular application in one or several ASP/IPSP'es. So each ASP/IPSP is= a clone of application. i.e. each application know in advance which loca= l IP address + port number to use since it os bound to that endpoint= during installation.
 
3) Even in legacy sy= stems it is in applications which control redundancy of applications (ie.= algortihm to use when loadsahring between remote application clones is o= wned by applications not MTP or SCCP).
 
&nb= sp;
/Stanislav Ivanovich


Barry Nage= lberg <barryn@adax.com> wrote:
Stanislav,

Both entities. You are describing an API msg= (N-STATE req) and the resulting SUA action.

The critical part is that the SCCP-user doesn't know (and= shouldn't know) how the API msg is handled "under the hood".

Barr= y Nagelberg
Adax, Inc.

-----Original Message-----
From: sigt= ran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanis= lav Ivanovichh
Sent: Monday, January 09, 2006 11:48 AM
To: SIGTRAN<= BR>Subject: RE: [Sigtran] Upper boundary of Adaptation Layers


= Barry,

Which entitiy controls the start and removal of application= from traffic? Is it MTP/SCCP or User Parts/SCCP-users?

When for e= xample SCCP-user requests N-STATE_request which is to be translated into = ASP-INACTIVE who controls the AS
state? Is it SUA "layer" or SCCP-user= application?

regards/ Stanislav



Barry Nagelberg wrote:
Ilie,

Your summary of the current archite= cture is mostly correct.

The most important part of your summary i= s that "SIGTRAN supports existing SCCP/MTP users without them being aware of
the fact that SIGTRAN is used for the tra= nsport of messages."

This is the entire reason for the existance o= f SIGTRAN. SIGTRAN is a bridging mechanism designed to allow legacy
SC= CP/MTP3 users to take advantage of cheap IP transport without having to m= odify their legacy protocol stacks.

Any attempt to make SCCP/MTP3 = users aware of SIGTRAN would make SIGTRAN almost worthless.

Barry = Nagelberg
Adax, Inc.

-----Original Message-----
From: sigtra= n-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On
Behalf Of Ilie = Glib
Sennt: Monday, January 09, 2006 10:07 AM
To: SIGTRAN
Subjec= t: [Sigtran] Upper boundary of Adaptation Layers


Hello Folks,<= BR>
In my current understanding of the SIGTRAN:

- SUA and M3UA = RFCs define the primitives of the adaptation layers
towards their user= s in Section "1.6.1. Definition of the upper
boundary".
SUA and M3U= A RFCs simply refer to ITU-T and ANSI standards for the
complete definition of the primitives towards the users, ther= efore
SIGTRAN supports existing
SCCP/MTP users without them being a= ware of the fact that SIGTRAN is
used for the trans! port of messages.=
SIGTRAN concepts and the corresponding entities/objects like AS, RK,<= BR>RC, IPSP, ASP, and SGP are not part of the currently standardized
u= pper boundary of M3UA (SUA).
Thus today's SIGTRAN users do not know an= ything about those concepts.

Can you please confirm this view or t= ell me if I'm mislead by my
interpretation ?

Is their any attem= pt in SIGTRAN WG to define an extended upper
boundary for xxUA that gi= ves the option of managing entities like AS,
RK, RC, IPSP, ASP, and SG= P to xxUA users and what are the enhanced
services expected from adapt= ation layers ?

Thank you in advance

--
Ilie

_____= __________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtr= an


_______________________________________________
Sigtran = mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinf= o/sigtran





Yahoo! DSL Something to write home about= . Just $16.99/mo. or less


____________________________________= ___________
Sigtran mailing list
Sigtran@ietf.org
https://www1.i= etf.org/mailman/listinfo/sigtran

Yahoo! Photos =96 Showcase holiday pictures in hardcover=20 Photo Bo= oks. You design it and we=92ll bind it! --0-655782810-1136827924=:68448-- --===============0145427066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0145427066==-- From sigtran-bounces@ietf.org Mon Jan 09 12:33:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0ta-00050G-Mj; Mon, 09 Jan 2006 12:33:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0tY-000503-UV for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 12:33:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05669 for ; Mon, 9 Jan 2006 12:32:05 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew105-0005Hq-KV for sigtran@ietf.org; Mon, 09 Jan 2006 12:40:10 -0500 Received: by nproxy.gmail.com with SMTP id n15so219004nfc for ; Mon, 09 Jan 2006 09:33:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bq/80qCo66VcZyTIoUUacypJMFuOfyAAgpdM6i+IIbAMHm9ti1Opi9yKa55/d8ZMokyi6UChQb6AFBst6OJG6osD/PA8qU6MlT993RgiFVdjI0S/8ckgM3IvDr4uiasP59IPFHWadT1XwySySDIwDxX+kRKSfB9VPTZ2416Lltg= Received: by 10.48.248.11 with SMTP id v11mr7502nfh; Mon, 09 Jan 2006 09:33:20 -0800 (PST) Received: by 10.48.1.13 with HTTP; Mon, 9 Jan 2006 09:33:19 -0800 (PST) Message-ID: <17b146d60601090933q5047827en2109e0f68628798a@mail.gmail.com> Date: Mon, 9 Jan 2006 18:33:19 +0100 From: Ilie Glib To: bidulock@openss7.org, Ilie Glib , SIGTRAN Subject: Re: [Sigtran] Coordinated service outage cannot be initiated from an ASP (AS) In-Reply-To: <20060106114454.A24248@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17b146d60601060054o1addbc2j81166c40249f3209@mail.gmail.com> <20060106093406.A22566@openss7.org> <17b146d60601060931q97ea53ex586319a1e3626464@mail.gmail.com> <20060106114454.A24248@openss7.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, I am sorry about bothering you with my mails, but obviously I am not the first one who asks this same question. > > You obviously did not look in the mail archive. > I swear on The Bible I have searched the IETF site, but my search was powered by... ;). You can try yourself to search for SOR SOG TCAP traffic stop. Thank you very much indeed for your help. -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 12:39:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0zg-0007Qa-QB; Mon, 09 Jan 2006 12:39:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0zf-0007QS-3T for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 12:39:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06006 for ; Mon, 9 Jan 2006 12:38:24 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew16B-0005R9-O9 for sigtran@ietf.org; Mon, 09 Jan 2006 12:46:29 -0500 Received: by nproxy.gmail.com with SMTP id c29so63478nfb for ; Mon, 09 Jan 2006 09:39:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NXE75koqp4ZPG7qFdslCAn1jm3nXQWVKjMWL8HJ12jj91xdj0drDeI5aqLtn6T9RavECMdhEAM2cvg+0qlOiIbVv+73sv/AfG592BXyYpadk816R3ByVKlT96UPYMtrGuBH6MnHzA3g3HvSha95fUSONn6OLUDbpIO0blgjgXP8= Received: by 10.49.94.7 with SMTP id w7mr357853nfl; Mon, 09 Jan 2006 09:39:06 -0800 (PST) Received: by 10.48.1.13 with HTTP; Mon, 9 Jan 2006 09:39:06 -0800 (PST) Message-ID: <17b146d60601090939r3d9865d0j4aba07e2dbe810ed@mail.gmail.com> Date: Mon, 9 Jan 2006 18:39:06 +0100 From: Ilie Glib To: bidulock@openss7.org, Ilie Glib , Tolga Asveren , sigtran@ietf.org Subject: Re: [Sigtran] DUNA applies to SG as a whole In-Reply-To: <20060106122513.B23036@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <62B9B0847CC47543B6B3B5E26BD268E609AD8C30@zrc2hxm2.corp.nortel.com> <17b146d60601061058q78731c03p12a00c5336d5fa53@mail.gmail.com> <20060106122513.B23036@openss7.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian thank you very much indeed for your kind help and patience Ilie On 1/6/06, Brian F. G. Bidulock wrote: > Ilie, > > Ilie Glib wrote: (Fr= i, 06 Jan 2006 19:58:55) > > Dan, > > > > Draft draft-ietf-sigtran-rfc3332bis-05.txt has the following statement > > > > 3.4.1 Destination Unavailable (DUNA) > > > > The DUNA message is sent from an SGP in an SG to all concerned ASPs > > to indicate that the SG has determined that one or more SS7 > > destinations are unreachable. It is also sent by an SGP in response > > to a message from the ASP to an unreachable SS7 destination. As an > > implementation option the SG may suppress the sending of subsequent > > "response" DUNA messages regarding a certain unreachable SS7 > > destination for a certain period to give the remote side time to > > react. If there is no alternate route via another SG, the MTP3-User > > at the ASP is expected to stop traffic to the affected destination > > via the SG as per the defined MTP3-User procedures. > > > > Thus I believe that in M3UA every SGP upon receiving a message towards > > an unreachable destination sooner or later will answer with a DUNA to > > the ASP. But of couse some traffic can be lost, which can be saved if > > there is another SG with connectivity to the affected SPC. > > > > Apropo, SUA RFC does not have a statement like "DUNA is also sent by > > an SGP in response to a message from the ASP to an unreachable SS7 > > destination" > > So I could imagine an implementation that sends DUNAs from one SGP only= . > > > > > > What is sent to the MTP-User and what the MTP-User expects of the > MTP layer is specified in SS7 standards, not in M3UA. The bis document > makes statements that are out of scope here and should have moved the > statement to the non-normative appendix. > > An SG would be best generate DUNA to each ASP in each affected AS > under the following conditions: > > a) In the case where the AS point code is hosted by the SG, DUNA is > generated under the same conditions that MTP-PAUSE would be generated > to local MTP-Users are the SG. > > b) In the case of the multiple SG as STP configuration, DUNA is > generated under the same conditions that TFP would be generated and > sent to the AS point code, were the AS point code a normal SS7 SEP. > > Understand? > > --brian > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 13:18:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1bD-0002GF-Ul; Mon, 09 Jan 2006 13:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1bC-0002Fw-7U for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 13:18:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09279 for ; Mon, 9 Jan 2006 13:17:10 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew1hi-0006qy-5L for sigtran@ietf.org; Mon, 09 Jan 2006 13:25:16 -0500 Received: by nproxy.gmail.com with SMTP id l37so185923nfc for ; Mon, 09 Jan 2006 10:18:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CC1e3g6qrKS9K3ty58SjpIVlMlBMMJQIhl6xPqZrieF1a597trSuIhWpPqfQQu4rfpWtDfJjeY6szXrOFDUbVGm6dU2/fhXnkSf2ZO0R+T3FV31eyRRWQJmKf1VKbw3lg8H3gvRzAQz1ad/G9/2RZRwb6q9m0b0jXACUmOerDCo= Received: by 10.48.3.13 with SMTP id 13mr922961nfc; Mon, 09 Jan 2006 08:49:53 -0800 (PST) Received: by 10.48.1.13 with HTTP; Mon, 9 Jan 2006 08:49:53 -0800 (PST) Message-ID: <17b146d60601090849g4489b48bsfd0823aa4ab3f9de@mail.gmail.com> Date: Mon, 9 Jan 2006 17:49:53 +0100 From: Ilie Glib To: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers In-Reply-To: <17b146d60601090844n300cd1b2k7916960ac88140b5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> <20060109152717.42154.qmail@web35403.mail.mud.yahoo.com> <17b146d60601090844n300cd1b2k7916960ac88140b5@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav I should correct myself. I mean that there are no doubts that there are xxUA Layers, and applications residing on top of them depend on them as SCCP-Users, depend on SCCP services. Regards Ilie On 1/9/06, Ilie Glib wrote: > Hello Stanislav, > > On 1/9/06, Stanislav Ivanovich wrote: > > Hello, > > > > Since I find Ilie's questions ambiguous I will extend his questions by > > asking: > > > > 1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP > > process states) indepdnednetly on MTP-user or SCCP-user applications by > > making these applications idendepndtz on the ASP/IPSP state? > > > > [Ilie] I have not questioned that, in my view this is a fact written > in stone (RFCs). > check e.g. the SIGTRAN applicability draft: > http://tools.ietf.org/html/draft-ietf-sigtran-signalling-over-sctp-applic= -09.txt > > > 2) If such layer exisits and if M3UA and SUA are not just and only prot= ocls > > but also boxes/layers which have a place in the signalling system which= is > > to isolate user functions on ASP/IPSP state shold such layer own the co= ntrol > > on ASP/IPSP states? > > > > For example SCCP subsystem does not want to handle traffic. In legacy > > systems SCCP-user applications own the control on the SCCP-subsystem st= ate > > change thus they control appaearance on N-STATE_request primitive on SC= CP > > API. > > However if one thinks that xxUA is not just a set of protocls (ASP-SGP = and > > IPSP-IPSP) but also a box which contains a functionality which is to is= olate > > user functions on SIGTRAN concepts (like ASP/IPSP) does that imply that= such > > box should own commands for AS state change, i.e. it is SUA box but not= SCCP > > user function which owns control on AS state change, see section 1.6.3.= in > > xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Manage= ment: > > > > M-ASP_ACTIVE request > > Direction: LM -> SUA > > Purpose: LM requests ASP to send an ASP Active message to its peer. > > M-ASP_INACTIVE request > > Direction: LM -> SUA > > Purpose: LM requests ASP to send an ASP Inactive message to its > > peer. > > > > Is this an RFC fault? > > > > > > regards/ stanislav > > > > > > Ilie Glib wrote: > > Hello Folks, > > > > In my current understanding of the SIGTRAN: > > > > - SUA and M3UA RFCs define the primitives of the adaptation layers > > towards their users in Section "1.6.1. Definition of the upper > > boundary". > > SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the > > complete definition of the primitives towards the users, therefore > > SIGTRAN supports existing > > SCCP/MTP users without them being aware of the fact that SIGTRAN is > > used for the transport of messages. > > SIGTRAN concepts and the corresponding entities/objects like AS, RK, > > RC, IPSP, ASP, and SGP are not part of the currently standardized > > upper boundary of M3UA (SUA). > > Thus today's SIGTRAN users do not know anything about those concepts. > > > > Can you please confirm this view or tell me if I'm mislead by my > > interpretation ? > > > > Is their any attempt in SIGTRAN WG to define! an extended upper > > boundary for xxUA that gives the option of managing entities like AS, > > RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced > > services expected from adaptation layers ? > > > > Thank you in advance > > > > -- > > Ilie > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > ________________________________ > > Yahoo! Photos > > Ring in the New Year with Photo Calendars. Add photos, events, holidays= , > > whatever. > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > -- > Ilie > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 13:58:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2E9-0004qi-V7; Mon, 09 Jan 2006 13:58:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2E8-0004qd-SM for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 13:58:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12209 for ; Mon, 9 Jan 2006 13:57:25 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[nwO+L/QWuo+7uilJv+ZX8h6aTsFQta/5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2Kh-00085k-5x for sigtran@ietf.org; Mon, 09 Jan 2006 14:05:31 -0500 Received: from ns.pigworks.openss7.net (IDENT:w5HcwfvMk8LfmIu3O8EFRE8XDxTC510V@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k09Iwgw21269; Mon, 9 Jan 2006 11:58:42 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k09Iwgj12905; Mon, 9 Jan 2006 11:58:42 -0700 Date: Mon, 9 Jan 2006 11:58:41 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] Upper boundary of Adaptation Layers Message-ID: <20060109115841.B12775@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> <20060109081933.A10655@openss7.org> <17b146d60601090821v6956a220w3380c9affb8c4011@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601090821v6956a220w3380c9affb8c4011@mail.gmail.com>; from ilie.glib@googlemail.com on Mon, Jan 09, 2006 at 05:21:57PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, Ilie Glib wrote: (Mon, 09 Jan 2006 17:21:57) > Hello Brian, > > I can not agree with you that SUA enables applications to use IP > addresses. Indeed Source and Destination addresses can contain IP > addresses, but this is an implicit impact on the xxUA users rather > than an explicit impact. Currently section "1.6.1. Definition of the > upper boundary" does not extend SS7 primitives. If this extension is > wanted it shall be in the standard documents (RFCs). Don't be absurd. 1.6.1 says that the standard SCCP/SCCP-User primitives are supported. It does not say that nothing else is supported or supportable. It does not say that no other primitives shall be used. It is just the list of intentionally supported primitives. There are, I hope you realize, more national protocol variants than just ITU or ANSI. > > Apropos Source and Destination addresses cannot contain hostnames. > IMHO hostnames are much more usefull than IP addresses. > > If it is wanted that xxUA become a true standard the content of the > upper boundary shall be defined down to the last bit. Actually, the upper boundary at the ASP is a local matter. There are no requirements placed on the boundary. It certainly does not have to specified to the bit. > > what do you mean by > > It is not necessarily true for the multiple SG as STP scenario, > ? I mean it is not necessarily true for the multiples SG as STP scenario. > > See below for one more question. > > Thank you in advance > > Ilie > On 1/9/06, Brian F. G. Bidulock wrote: > > Ilie, > > > > This can be true for the strict backhaul scenario. > > [Ilie] Do you mean SGP to ASP interface (assuming ASP does not have > relay capability)? No. SG to ASP interface where the Provider protocol layer (e.g., SCCP) is located at the SG. That is, the ASP's point-code is hosted at the SG. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 14:17:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2W5-0001gd-JD; Mon, 09 Jan 2006 14:17:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2W4-0001g6-7b for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 14:17:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13395 for ; Mon, 9 Jan 2006 14:15:56 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[4zjrqsfrV8mgQOOcjeekOPNFaD/8AOrx]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2cb-0000CR-I8 for sigtran@ietf.org; Mon, 09 Jan 2006 14:24:02 -0500 Received: from ns.pigworks.openss7.net (IDENT:iJ/UpL7B7cbObzJHT5U5nhO0nyRE8k6d@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k09JHCw21562; Mon, 9 Jan 2006 12:17:12 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k09JHCt13259; Mon, 9 Jan 2006 12:17:12 -0700 Date: Mon, 9 Jan 2006 12:17:12 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers Message-ID: <20060109121712.C12775@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060109083407.A10921@openss7.org> <20060109163640.41923.qmail@web35404.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060109163640.41923.qmail@web35404.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Mon, Jan 09, 2006 at 08:36:40AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Stanislav Ivanovich wrote: (Mon, 09 Jan 2006 08:36:40) > > Brian, Tolga, > > > > Brian, are you saying that SCCP-user function is not owner of the > management of its resources, i.e. user function does not own control > if/how/when it can withdraw from the traffic? See Figure 10/Q.1400. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 14:20:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2ZN-0002ig-Ph; Mon, 09 Jan 2006 14:20:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2ZL-0002hl-6K for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 14:20:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13737 for ; Mon, 9 Jan 2006 14:19:19 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[w2Ccj5rYLXBHWYf/z+fI7IS4T3f8bhKR]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2fr-0000L9-Qd for sigtran@ietf.org; Mon, 09 Jan 2006 14:27:25 -0500 Received: from ns.pigworks.openss7.net (IDENT:j57/KqiFe1D4qTiGmAMv18sNIqT8CzkD@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k09JKZw21604; Mon, 9 Jan 2006 12:20:35 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k09JKZP13301; Mon, 9 Jan 2006 12:20:35 -0700 Date: Mon, 9 Jan 2006 12:20:34 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] Coordinated service outage cannot be initiated from an ASP (AS) Message-ID: <20060109122034.D12775@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601060054o1addbc2j81166c40249f3209@mail.gmail.com> <20060106093406.A22566@openss7.org> <17b146d60601060931q97ea53ex586319a1e3626464@mail.gmail.com> <20060106114454.A24248@openss7.org> <17b146d60601090933q5047827en2109e0f68628798a@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601090933q5047827en2109e0f68628798a@mail.gmail.com>; from ilie.glib@googlemail.com on Mon, Jan 09, 2006 at 06:33:19PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: aafbb359257cdee39d68c7ac7bccd638 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ilie, The thread is attached. --brian Ilie Glib wrote: (Mon, 09 Jan 2006 18:33:19) > Brian, > > I am sorry about bothering you with my mails, but obviously I am not > the first one who asks this same question. > > > > > You obviously did not look in the mail archive. > > > I swear on The Bible I have searched the IETF site, but my search was > powered by... ;). You can try yourself to search for SOR SOG TCAP > traffic stop. > > Thank you very much indeed for your help. > > -- > Ilie -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --8t9RHnE3ZwKMSgU+ Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost (IDENT:brian@localhost [127.0.0.1]) by bfgbhome.inetint.com (8.9.3/8.9.3) with ESMTP id CAA20321 for ; Thu, 30 May 2002 02:00:06 -0500 Received: from mail.dallas.net by localhost with POP3 (fetchmail-5.3.1) for brian@localhost (single-drop); Thu, 30 May 2002 02:00:06 -0500 (CDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by dallas.net (8.12.2/8.12.2) with ESMTP id g4U6lxD3003858 for ; Thu, 30 May 2002 01:47:59 -0500 (CDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA29933; Thu, 30 May 2002 02:37:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA29900 for ; Thu, 30 May 2002 02:37:49 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24257 for ; Thu, 30 May 2002 02:37:23 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4U6dKa27757 for ; Thu, 30 May 2002 09:39:21 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 May 2002 09:37:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 30 May 2002 09:37:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop Date: Thu, 30 May 2002 09:37:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FDE1@esebe004.NOE.Nokia.com> Thread-Topic: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop Thread-Index: AcH910gO7qMWJSswTeWbzVTuvThE4AJCeQcAAC14ONA= To: , Cc: X-OriginalArrivalTime: 30 May 2002 06:37:47.0683 (UTC) FILETIME=[8330A730:01C207A4] X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA29901 Sender: sigtran-admin@ietf.org Errors-To: sigtran-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Signaling Transport X-BeenThere: sigtran@ietf.org X-Loop: brian@pigworks.dallas.net X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 8bit Hi Francois & Brian, I would support someone documenting how to solve this for SUA. It could be placed in an implementation guide or an extension. John > -----Original Message----- > From: ext Zannin, Francois [mailto:Francois.Zannin@hp.com] > Sent: 29 May, 2002 10:31 > To: bidulock@openss7.org > Cc: sigtran@ietf.org > Subject: RE: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and > TCAP traffic stop > > > > Brian and others, > > What about the TCAP close dialog? A solution should be to use > the ACTIVE message with a void TID range for the concerned > RC. In that case, no new transaction will be initiated > through the "exiting" ASP until it decide to send the > INACTIVE once all it's dialog are close. > > This behavior of the INACTIVE message on the SG must be > specified if we want to have SG/AS that can inter operate for > different vendor! > > This consideration should be included in the draft or an > implementation guide. > > Francois Z. > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Friday, May 17, 2002 9:16 PM > > To: Zannin, Francois > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] SUA: Indication from ASP to SGP for > SOR/SOG and > > TCAP traffic stop > > > > > > Francois, > > > > IMO the existing text is sufficient. > > > > --brian > > > > Zannin, Francois wrote: > > (Fri, 17 May 2002 10:56:50) > > > Brian, > > > > > > You are right about note 1 associated to the DRST. A > > reading shows that > > > N-COORD indication and confirm means a message from the ASP > > to the SG(p), > > > can we modify the text that describe the DRST (text coming > > from M3UA) > > > that may give some doubts about the possibility to send > > this message from > > > an ASP to a SGP. > > > > > > " 3.4.6 Destination Restricted (DRST) > > > > > > The DRST message is optionally sent from the SG to all > concerned > > > ASPs ... " > > > >>> There is no information saying that the DRST can be > > send from the ASP to the SGP. > > > > > > " This message is optional for the SG to send and it is > > optional for > > > the ASP to act on any information received in the message." > > > >>> This information may be completed to specify that it is > > not optional when the DRST is used to carry the SOR/SOG messages. > > > > > > > > > My concern was also about the possibility stop new > > transaction for a specific ASP. > > > I understand that the right solution should be to use TUA > > instead of SUA for TCAP > > > but while the TID range is included in the SUA protocol, it > > may be a good idea to > > > have all the messages needed to handle TCAP transactions. > > > > > > Because the DRST can be used to carry SOR/SOG from the ASP > > to the SGP, what else > > > can be used to carry this "TCAP" needed message from the > > ASP to the SGP? > > > > > > Francois. > > > > > > > > > > -----Original Message----- > > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > > Sent: Wednesday, May 15, 2002 8:35 PM > > > > To: Zannin, Francois > > > > Cc: sigtran@ietf.org > > > > Subject: Re: [Sigtran] SUA: Indication from ASP to SGP > > for SOR/SOG and > > > > TCAP traffic stop > > > > > > > > > > > > Francois, > > > > > > > > If you read Note 1 under the DRST message you will see that > > > > the message is for both the SG to AS direction and the AS > > > > to SG direction for N-COORD. This is all four: requestion > > > > indication, response and confirmation. There is nothing > > > > missing. > > > > > > > > --brian > > > > > > > > Zannin, Francois wrote: > > > > (Wed, 15 May 2002 11:07:55) > > > > > Hi, > > > > > > > > > > In the SUA draft, top-level application or management > > > > > application can be synchronized through N_COORD primitives > > > > > in a SSNM DRST message. > > > > > > > > > > This message exists only from the SG (p) to the AS (p). > > > > > When the application (or the AS management) receive an > > > > > N-COORD request and need to respond by a N_COORD response, > > > > > which message from the ASP to the SGP must be used to carry > > > > > this information? > > > > > > > > > > If an indication has to be added to transport this > information, > > > > > isn't it an opportunity to also add the missing message that > > > > > can be used to inform a SG (p) that an ASP do not need to > > > > > receive any "new" transaction for TCAP applications? > > > > > > > > > > Francois. > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sigtran mailing list > > > > > Sigtran@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > -- > > > > Brian F. G. Bidulock > > > > bidulock@openss7.org > > > > http://www.openss7.org/ > > > > > > > > -- > > 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 --8t9RHnE3ZwKMSgU+ Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost (IDENT:brian@localhost [127.0.0.1]) by bfgbhome.inetint.com (8.9.3/8.9.3) with ESMTP id QAA15032 for ; Wed, 29 May 2002 16:00:22 -0500 Received: from mail.dallas.net by localhost with POP3 (fetchmail-5.3.1) for brian@localhost (single-drop); Wed, 29 May 2002 16:00:22 -0500 (CDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by dallas.net (8.12.2/8.12.2) with ESMTP id g4TKrHdN020778 for ; Wed, 29 May 2002 15:53:18 -0500 (CDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16537; Wed, 29 May 2002 16:45:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16505 for ; Wed, 29 May 2002 16:44:59 -0400 (EDT) Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-42-202.dallas.net [209.44.42.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02627 for ; Wed, 29 May 2002 16:44:32 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id MAA11985; Wed, 29 May 2002 12:32:17 -0500 Date: Wed, 29 May 2002 12:32:17 -0500 From: "Brian F. G. Bidulock" To: "Zannin, Francois" Cc: sigtran@ietf.org Subject: Re: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop Message-ID: <20020529123217.B4332@openss7.org> Reply-To: bidulock@openss7.org Mail-Followup-To: "Zannin, Francois" , sigtran@ietf.org References: <06CAA4D3753C53408D2CE6340B68444214C3A6@vbeexc02.emea.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <06CAA4D3753C53408D2CE6340B68444214C3A6@vbeexc02.emea.cpqcorp.net>; from Francois.Zannin@hp.com on Wed, May 29, 2002 at 09:31:25AM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: sigtran-admin@ietf.org Errors-To: sigtran-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Signaling Transport X-BeenThere: sigtran@ietf.org X-Loop: brian@pigworks.dallas.net X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 Francois, I'm sorry but there is really no way to do this with SUA as it stands. I proposed a registration/deregistration of TIDs some time back, but it was replaced with the inferior lable approach (which doesn't keep state for things like transactions or connections). For transactions, use TUA to get past this defficiency. CO is out of luck unless the WG would like to consider including registration/deregistration of connections again. I had actually hoped that this issues would have been properly resolved before the SUA was moved forward, however, there are those who have had a hard time understanding the problem. Thus the inferior solution. --brian Zannin, Francois wrote: (Wed, 29 May 2002 09:31:25) > > Brian and others, > > What about the TCAP close dialog? A solution should be to use the ACTIVE > message with a void TID range for the concerned RC. In that case, no new > transaction will be initiated through the "exiting" ASP until it decide to > send the INACTIVE once all it's dialog are close. > > This behavior of the INACTIVE message on the SG must be specified if we want > to have SG/AS that can inter operate for different vendor! > > This consideration should be included in the draft or an implementation > guide. > > Francois Z. > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Friday, May 17, 2002 9:16 PM > > To: Zannin, Francois > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and > > TCAP traffic stop > > > > > > Francois, > > > > IMO the existing text is sufficient. > > > > --brian > > > > Zannin, Francois wrote: > > (Fri, 17 May 2002 10:56:50) > > > Brian, > > > > > > You are right about note 1 associated to the DRST. A > > reading shows that > > > N-COORD indication and confirm means a message from the ASP > > to the SG(p), > > > can we modify the text that describe the DRST (text coming > > from M3UA) > > > that may give some doubts about the possibility to send > > this message from > > > an ASP to a SGP. > > > > > > " 3.4.6 Destination Restricted (DRST) > > > > > > The DRST message is optionally sent from the SG to all concerned > > > ASPs ... " > > > >>> There is no information saying that the DRST can be > > send from the ASP to the SGP. > > > > > > " This message is optional for the SG to send and it is > > optional for > > > the ASP to act on any information received in the message." > > > >>> This information may be completed to specify that it is > > not optional when the DRST is used to carry the SOR/SOG messages. > > > > > > > > > My concern was also about the possibility stop new > > transaction for a specific ASP. > > > I understand that the right solution should be to use TUA > > instead of SUA for TCAP > > > but while the TID range is included in the SUA protocol, it > > may be a good idea to > > > have all the messages needed to handle TCAP transactions. > > > > > > Because the DRST can be used to carry SOR/SOG from the ASP > > to the SGP, what else > > > can be used to carry this "TCAP" needed message from the > > ASP to the SGP? > > > > > > Francois. > > > > > > > > > > -----Original Message----- > > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > > Sent: Wednesday, May 15, 2002 8:35 PM > > > > To: Zannin, Francois > > > > Cc: sigtran@ietf.org > > > > Subject: Re: [Sigtran] SUA: Indication from ASP to SGP > > for SOR/SOG and > > > > TCAP traffic stop > > > > > > > > > > > > Francois, > > > > > > > > If you read Note 1 under the DRST message you will see that > > > > the message is for both the SG to AS direction and the AS > > > > to SG direction for N-COORD. This is all four: requestion > > > > indication, response and confirmation. There is nothing > > > > missing. > > > > > > > > --brian > > > > > > > > Zannin, Francois wrote: > > > > (Wed, 15 May 2002 11:07:55) > > > > > Hi, > > > > > > > > > > In the SUA draft, top-level application or management > > > > > application can be synchronized through N_COORD primitives > > > > > in a SSNM DRST message. > > > > > > > > > > This message exists only from the SG (p) to the AS (p). > > > > > When the application (or the AS management) receive an > > > > > N-COORD request and need to respond by a N_COORD response, > > > > > which message from the ASP to the SGP must be used to carry > > > > > this information? > > > > > > > > > > If an indication has to be added to transport this information, > > > > > isn't it an opportunity to also add the missing message that > > > > > can be used to inform a SG (p) that an ASP do not need to > > > > > receive any "new" transaction for TCAP applications? > > > > > > > > > > Francois. > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sigtran mailing list > > > > > Sigtran@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > -- > > > > Brian F. G. Bidulock > > > > bidulock@openss7.org > > > > http://www.openss7.org/ > > > > > > > > -- > > Brian F. G. Bidulock > > bidulock@openss7.org > > http://www.openss7.org/ > > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --8t9RHnE3ZwKMSgU+ Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost (IDENT:brian@localhost [127.0.0.1]) by bfgbhome.inetint.com (8.9.3/8.9.3) with ESMTP id CAA05514 for ; Wed, 29 May 2002 02:45:05 -0500 Received: from mail.dallas.net by localhost with POP3 (fetchmail-5.3.1) for brian@localhost (single-drop); Wed, 29 May 2002 02:45:06 -0500 (CDT) Received: from lists.herlein.com (root@m205-237.dsl.tsoft.com [198.144.205.237]) by dallas.net (8.12.2/8.12.2) with ESMTP id g4T7X0jg023785 for ; Wed, 29 May 2002 02:33:01 -0500 (CDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by lists.herlein.com (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g4T7WRq18373 for ; Wed, 29 May 2002 00:32:27 -0700 Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.94.66]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id C35CC3D2D; Wed, 29 May 2002 00:40:06 -0700 (PDT) Received: from vbeexc02.emea.cpqcorp.net ([16.188.146.229]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 May 2002 09:31:27 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop Date: Wed, 29 May 2002 09:31:25 +0200 Message-ID: <06CAA4D3753C53408D2CE6340B68444214C3A6@vbeexc02.emea.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop Thread-Index: AcH910gO7qMWJSswTeWbzVTuvThE4AJCeQcA From: "Zannin, Francois" To: Cc: X-OriginalArrivalTime: 29 May 2002 07:31:27.0581 (UTC) FILETIME=[D7FC58D0:01C206E2] X-MIME-Autoconverted: from quoted-printable to 8bit by dallas.net id g4T7X0jg023785 X-Loop: brian@pigworks.dallas.net X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 8bit Brian and others, What about the TCAP close dialog? A solution should be to use the ACTIVE message with a void TID range for the concerned RC. In that case, no new transaction will be initiated through the "exiting" ASP until it decide to send the INACTIVE once all it's dialog are close. This behavior of the INACTIVE message on the SG must be specified if we want to have SG/AS that can inter operate for different vendor! This consideration should be included in the draft or an implementation guide. Francois Z. > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Friday, May 17, 2002 9:16 PM > To: Zannin, Francois > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and > TCAP traffic stop > > > Francois, > > IMO the existing text is sufficient. > > --brian > > Zannin, Francois wrote: > (Fri, 17 May 2002 10:56:50) > > Brian, > > > > You are right about note 1 associated to the DRST. A > reading shows that > > N-COORD indication and confirm means a message from the ASP > to the SG(p), > > can we modify the text that describe the DRST (text coming > from M3UA) > > that may give some doubts about the possibility to send > this message from > > an ASP to a SGP. > > > > " 3.4.6 Destination Restricted (DRST) > > > > The DRST message is optionally sent from the SG to all concerned > > ASPs ... " > > >>> There is no information saying that the DRST can be > send from the ASP to the SGP. > > > > " This message is optional for the SG to send and it is > optional for > > the ASP to act on any information received in the message." > > >>> This information may be completed to specify that it is > not optional when the DRST is used to carry the SOR/SOG messages. > > > > > > My concern was also about the possibility stop new > transaction for a specific ASP. > > I understand that the right solution should be to use TUA > instead of SUA for TCAP > > but while the TID range is included in the SUA protocol, it > may be a good idea to > > have all the messages needed to handle TCAP transactions. > > > > Because the DRST can be used to carry SOR/SOG from the ASP > to the SGP, what else > > can be used to carry this "TCAP" needed message from the > ASP to the SGP? > > > > Francois. > > > > > > > -----Original Message----- > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: Wednesday, May 15, 2002 8:35 PM > > > To: Zannin, Francois > > > Cc: sigtran@ietf.org > > > Subject: Re: [Sigtran] SUA: Indication from ASP to SGP > for SOR/SOG and > > > TCAP traffic stop > > > > > > > > > Francois, > > > > > > If you read Note 1 under the DRST message you will see that > > > the message is for both the SG to AS direction and the AS > > > to SG direction for N-COORD. This is all four: requestion > > > indication, response and confirmation. There is nothing > > > missing. > > > > > > --brian > > > > > > Zannin, Francois wrote: > > > (Wed, 15 May 2002 11:07:55) > > > > Hi, > > > > > > > > In the SUA draft, top-level application or management > > > > application can be synchronized through N_COORD primitives > > > > in a SSNM DRST message. > > > > > > > > This message exists only from the SG (p) to the AS (p). > > > > When the application (or the AS management) receive an > > > > N-COORD request and need to respond by a N_COORD response, > > > > which message from the ASP to the SGP must be used to carry > > > > this information? > > > > > > > > If an indication has to be added to transport this information, > > > > isn't it an opportunity to also add the missing message that > > > > can be used to inform a SG (p) that an ASP do not need to > > > > receive any "new" transaction for TCAP applications? > > > > > > > > Francois. > > > > > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > -- > > > Brian F. G. Bidulock > > > bidulock@openss7.org > > > http://www.openss7.org/ > > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > --8t9RHnE3ZwKMSgU+ Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost (IDENT:brian@localhost [127.0.0.1]) by bfgbhome.inetint.com (8.9.3/8.9.3) with ESMTP id OAA13570 for ; Fri, 17 May 2002 14:20:07 -0500 Received: from mail.dallas.net by localhost with POP3 (fetchmail-5.3.1) for brian@localhost (single-drop); Fri, 17 May 2002 14:20:07 -0500 (CDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by dallas.net (8.12.2/8.12.2) with ESMTP id g4HJJeBw000848 for ; Fri, 17 May 2002 14:19:40 -0500 (CDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26447; Fri, 17 May 2002 15:16:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26422 for ; Fri, 17 May 2002 15:16:01 -0400 (EDT) Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-42-198.dallas.net [209.44.42.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28591 for ; Fri, 17 May 2002 15:15:45 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id OAA13525; Fri, 17 May 2002 14:15:48 -0500 Date: Fri, 17 May 2002 14:15:47 -0500 From: "Brian F. G. Bidulock" To: "Zannin, Francois" Cc: sigtran@ietf.org Subject: Re: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop Message-ID: <20020517141547.B8369@openss7.org> Reply-To: bidulock@openss7.org Mail-Followup-To: "Zannin, Francois" , sigtran@ietf.org References: <06CAA4D3753C53408D2CE6340B68444214C3A3@vbeexc02.emea.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <06CAA4D3753C53408D2CE6340B68444214C3A3@vbeexc02.emea.cpqcorp.net>; from Francois.Zannin@hp.com on Fri, May 17, 2002 at 10:56:50AM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: sigtran-admin@ietf.org Errors-To: sigtran-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Signaling Transport X-BeenThere: sigtran@ietf.org X-Loop: brian@pigworks.dallas.net X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 Francois, IMO the existing text is sufficient. --brian Zannin, Francois wrote: (Fri, 17 May 2002 10:56:50) > Brian, > > You are right about note 1 associated to the DRST. A reading shows that > N-COORD indication and confirm means a message from the ASP to the SG(p), > can we modify the text that describe the DRST (text coming from M3UA) > that may give some doubts about the possibility to send this message from > an ASP to a SGP. > > " 3.4.6 Destination Restricted (DRST) > > The DRST message is optionally sent from the SG to all concerned > ASPs ... " > >>> There is no information saying that the DRST can be send from the ASP to the SGP. > > " This message is optional for the SG to send and it is optional for > the ASP to act on any information received in the message." > >>> This information may be completed to specify that it is not optional when the DRST is used to carry the SOR/SOG messages. > > > My concern was also about the possibility stop new transaction for a specific ASP. > I understand that the right solution should be to use TUA instead of SUA for TCAP > but while the TID range is included in the SUA protocol, it may be a good idea to > have all the messages needed to handle TCAP transactions. > > Because the DRST can be used to carry SOR/SOG from the ASP to the SGP, what else > can be used to carry this "TCAP" needed message from the ASP to the SGP? > > Francois. > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Wednesday, May 15, 2002 8:35 PM > > To: Zannin, Francois > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and > > TCAP traffic stop > > > > > > Francois, > > > > If you read Note 1 under the DRST message you will see that > > the message is for both the SG to AS direction and the AS > > to SG direction for N-COORD. This is all four: requestion > > indication, response and confirmation. There is nothing > > missing. > > > > --brian > > > > Zannin, Francois wrote: > > (Wed, 15 May 2002 11:07:55) > > > Hi, > > > > > > In the SUA draft, top-level application or management > > > application can be synchronized through N_COORD primitives > > > in a SSNM DRST message. > > > > > > This message exists only from the SG (p) to the AS (p). > > > When the application (or the AS management) receive an > > > N-COORD request and need to respond by a N_COORD response, > > > which message from the ASP to the SGP must be used to carry > > > this information? > > > > > > If an indication has to be added to transport this information, > > > isn't it an opportunity to also add the missing message that > > > can be used to inform a SG (p) that an ASP do not need to > > > receive any "new" transaction for TCAP applications? > > > > > > Francois. > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > -- > > Brian F. G. Bidulock > > bidulock@openss7.org > > http://www.openss7.org/ > > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --8t9RHnE3ZwKMSgU+ Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost (IDENT:brian@localhost [127.0.0.1]) by bfgbhome.inetint.com (8.9.3/8.9.3) with ESMTP id EAA05086 for ; Fri, 17 May 2002 04:00:06 -0500 Received: from mail.dallas.net by localhost with POP3 (fetchmail-5.3.1) for brian@localhost (single-drop); Fri, 17 May 2002 04:00:09 -0500 (CDT) Received: from ultra5.oklahoma.net (ultra5.oklahoma.net [208.2.112.8]) by dallas.net (8.12.2/8.12.2) with ESMTP id g4H8vN5W021149 for ; Fri, 17 May 2002 03:57:27 -0500 (CDT) Received: from lists.herlein.com (root@m205-237.dsl.tsoft.com [198.144.205.237]) by ultra5.oklahoma.net (8.12.0.Beta19/8.12.0.Beta12) with ESMTP id g4H8um8D024337 for ; Fri, 17 May 2002 03:56:49 -0500 (CDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by lists.herlein.com (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g4H8usq05132 for ; Fri, 17 May 2002 01:56:54 -0700 Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.94.66]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 7C505151D; Fri, 17 May 2002 02:01:17 -0700 (PDT) Received: from vbeexc02.emea.cpqcorp.net ([16.188.146.229]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 17 May 2002 10:56:51 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 17 May 2002 10:56:50 +0200 Message-ID: <06CAA4D3753C53408D2CE6340B68444214C3A3@vbeexc02.emea.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop Thread-Index: AcH8P/7ANnZlOjsITuOUJHYTJD9UVQBPbEPw From: "Zannin, Francois" To: , Cc: "Zannin, Francois" X-OriginalArrivalTime: 17 May 2002 08:56:51.0593 (UTC) FILETIME=[C92D8790:01C1FD80] X-MIME-Autoconverted: from quoted-printable to 8bit by dallas.net id g4H8vN5W021149 X-Loop: brian@pigworks.dallas.net X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 8bit Brian, You are right about note 1 associated to the DRST. A reading shows that N-COORD indication and confirm means a message from the ASP to the SG(p), can we modify the text that describe the DRST (text coming from M3UA) that may give some doubts about the possibility to send this message from an ASP to a SGP. " 3.4.6 Destination Restricted (DRST) The DRST message is optionally sent from the SG to all concerned ASPs ... " >>> There is no information saying that the DRST can be send from the ASP to the SGP. " This message is optional for the SG to send and it is optional for the ASP to act on any information received in the message." >>> This information may be completed to specify that it is not optional when the DRST is used to carry the SOR/SOG messages. My concern was also about the possibility stop new transaction for a specific ASP. I understand that the right solution should be to use TUA instead of SUA for TCAP but while the TID range is included in the SUA protocol, it may be a good idea to have all the messages needed to handle TCAP transactions. Because the DRST can be used to carry SOR/SOG from the ASP to the SGP, what else can be used to carry this "TCAP" needed message from the ASP to the SGP? Francois. > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Wednesday, May 15, 2002 8:35 PM > To: Zannin, Francois > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and > TCAP traffic stop > > > Francois, > > If you read Note 1 under the DRST message you will see that > the message is for both the SG to AS direction and the AS > to SG direction for N-COORD. This is all four: requestion > indication, response and confirmation. There is nothing > missing. > > --brian > > Zannin, Francois wrote: > (Wed, 15 May 2002 11:07:55) > > Hi, > > > > In the SUA draft, top-level application or management > > application can be synchronized through N_COORD primitives > > in a SSNM DRST message. > > > > This message exists only from the SG (p) to the AS (p). > > When the application (or the AS management) receive an > > N-COORD request and need to respond by a N_COORD response, > > which message from the ASP to the SGP must be used to carry > > this information? > > > > If an indication has to be added to transport this information, > > isn't it an opportunity to also add the missing message that > > can be used to inform a SG (p) that an ASP do not need to > > receive any "new" transaction for TCAP applications? > > > > Francois. > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > --8t9RHnE3ZwKMSgU+ Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost (IDENT:brian@localhost [127.0.0.1]) by bfgbhome.inetint.com (8.9.3/8.9.3) with ESMTP id NAA10491 for ; Wed, 15 May 2002 13:45:05 -0500 Received: from mail.dallas.net by localhost with POP3 (fetchmail-5.3.1) for brian@localhost (single-drop); Wed, 15 May 2002 13:45:05 -0500 (CDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by dallas.net (8.12.2/8.12.2) with ESMTP id g4FIgZii009915 for ; Wed, 15 May 2002 13:42:35 -0500 (CDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20277; Wed, 15 May 2002 14:40:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20245 for ; Wed, 15 May 2002 14:40:37 -0400 (EDT) Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-42-198.dallas.net [209.44.42.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17242 for ; Wed, 15 May 2002 14:40:18 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id NAA10003; Wed, 15 May 2002 13:35:26 -0500 Date: Wed, 15 May 2002 13:35:25 -0500 From: "Brian F. G. Bidulock" To: "Zannin, Francois" Cc: sigtran@ietf.org Subject: Re: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop Message-ID: <20020515133525.A8745@openss7.org> Reply-To: bidulock@openss7.org Mail-Followup-To: "Zannin, Francois" , sigtran@ietf.org References: <06CAA4D3753C53408D2CE6340B68444210DE4A@vbeexc02.emea.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <06CAA4D3753C53408D2CE6340B68444210DE4A@vbeexc02.emea.cpqcorp.net>; from Francois.Zannin@hp.com on Wed, May 15, 2002 at 11:07:55AM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: sigtran-admin@ietf.org Errors-To: sigtran-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Signaling Transport X-BeenThere: sigtran@ietf.org X-Loop: brian@pigworks.dallas.net X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 Francois, If you read Note 1 under the DRST message you will see that the message is for both the SG to AS direction and the AS to SG direction for N-COORD. This is all four: requestion indication, response and confirmation. There is nothing missing. --brian Zannin, Francois wrote: (Wed, 15 May 2002 11:07:55) > Hi, > > In the SUA draft, top-level application or management > application can be synchronized through N_COORD primitives > in a SSNM DRST message. > > This message exists only from the SG (p) to the AS (p). > When the application (or the AS management) receive an > N-COORD request and need to respond by a N_COORD response, > which message from the ASP to the SGP must be used to carry > this information? > > If an indication has to be added to transport this information, > isn't it an opportunity to also add the missing message that > can be used to inform a SG (p) that an ASP do not need to > receive any "new" transaction for TCAP applications? > > Francois. > > > _______________________________________________ > 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 --8t9RHnE3ZwKMSgU+ Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost (IDENT:brian@localhost [127.0.0.1]) by bfgbhome.inetint.com (8.9.3/8.9.3) with ESMTP id NAA09458 for ; Wed, 15 May 2002 13:15:06 -0500 Received: from mail.dallas.net by localhost with POP3 (fetchmail-5.3.1) for brian@localhost (single-drop); Wed, 15 May 2002 13:15:06 -0500 (CDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by dallas.net (8.12.2/8.12.2) with ESMTP id g4FIBGT2028832 for ; Wed, 15 May 2002 13:11:16 -0500 (CDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18089; Wed, 15 May 2002 14:09:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29642 for ; Wed, 15 May 2002 05:08:39 -0400 (EDT) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22429 for ; Wed, 15 May 2002 05:08:14 -0400 (EDT) Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.94.66]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 4F03A297E for ; Wed, 15 May 2002 02:07:45 -0700 (PDT) Received: from vbeexc02.emea.cpqcorp.net ([16.188.146.229]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 11:07:56 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 15 May 2002 11:07:55 +0200 Message-ID: <06CAA4D3753C53408D2CE6340B68444210DE4A@vbeexc02.emea.cpqcorp.net> Thread-Topic: SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop Thread-Index: AcH775+ODrFtv2ZJEdauIwCQJ3WUmQ== From: "Zannin, Francois" To: X-OriginalArrivalTime: 15 May 2002 09:07:56.0655 (UTC) FILETIME=[00C26FF0:01C1FBF0] X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA29643 Subject: [Sigtran] SUA: Indication from ASP to SGP for SOR/SOG and TCAP traffic stop Sender: sigtran-admin@ietf.org Errors-To: sigtran-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Signaling Transport X-BeenThere: sigtran@ietf.org X-Loop: brian@pigworks.dallas.net X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 8bit Hi, In the SUA draft, top-level application or management application can be synchronized through N_COORD primitives in a SSNM DRST message. This message exists only from the SG (p) to the AS (p). When the application (or the AS management) receive an N-COORD request and need to respond by a N_COORD response, which message from the ASP to the SGP must be used to carry this information? If an indication has to be added to transport this information, isn't it an opportunity to also add the missing message that can be used to inform a SG (p) that an ASP do not need to receive any "new" transaction for TCAP applications? Francois. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --8t9RHnE3ZwKMSgU+-- From sigtran-bounces@ietf.org Mon Jan 09 14:23:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2c9-0003Oe-2M; Mon, 09 Jan 2006 14:23:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2c8-0003OV-C7 for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 14:23:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13997 for ; Mon, 9 Jan 2006 14:22:12 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[ifMV0rm/+jlf4s7iFYHdh+zLdkcYslNc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2if-0000Sl-VN for sigtran@ietf.org; Mon, 09 Jan 2006 14:30:19 -0500 Received: from ns.pigworks.openss7.net (IDENT:s/yXQq7LQmgp5ZxTxlfnJC4RlhprK8QF@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k09JNTw21631; Mon, 9 Jan 2006 12:23:29 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k09JNTv13316; Mon, 9 Jan 2006 12:23:29 -0700 Date: Mon, 9 Jan 2006 12:23:29 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers Message-ID: <20060109122329.E12775@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060109173204.68450.qmail@web35414.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060109173204.68450.qmail@web35414.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Mon, Jan 09, 2006 at 09:32:04AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Stanislav Ivanovich wrote: (Mon, 09 Jan 2006 09:32:04) > > Barry, > > > > I agree that user applications are to be isolated from the underlaying > layers (i.e. SCTP, IP etc...). However I completely disagree that as > you say both (!) entities (i.e. MTP/SCCP and their users) control the > acitvation/deactivation of applications in the traffic! Instead in the > legacy systems (and even in pure logic) it is in application > responsiblity to know if/how/when to start/stop handling traffic. > See Figure 10/Q.1400 and then reconsider Barry's answer. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 14:55:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew36q-0003bv-Q7; Mon, 09 Jan 2006 14:55:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew36o-0003bD-Q6 for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 14:55:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17209 for ; Mon, 9 Jan 2006 14:53:54 -0500 (EST) Received: from web35406.mail.mud.yahoo.com ([66.163.179.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew3DN-0001PQ-DV for sigtran@ietf.org; Mon, 09 Jan 2006 15:02:01 -0500 Received: (qmail 63672 invoked by uid 60001); 9 Jan 2006 19:55:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=arCp6iZ2vt6IIbCumlx4XCNv3Rg//gmGpF3/Gdv4GC1Y4KpWKKC/oUVufGRKZtkR8IzmNRiNGkhT2KTPw7ejzB2aALdFvcHEgIntqpthC2YVec4MFYByq0TbmbVCOSvZZ3K87zvMorgW8ua1nd+MrBxSxJL+n1LPGQNOHrrzAx0= ; Message-ID: <20060109195503.63667.qmail@web35406.mail.mud.yahoo.com> Received: from [83.131.76.151] by web35406.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2006 11:55:03 PST Date: Mon, 9 Jan 2006 11:55:03 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers To: SIGTRAN In-Reply-To: <20060109115841.B12775@openss7.org> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2055638587==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============2055638587== Content-Type: multipart/alternative; boundary="0-1949130023-1136836503=:61482" --0-1949130023-1136836503=:61482 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA17209 Thank You very much Brian, now I 100% agree with You! =20 I think that you pointed the very essential (!) property of all xxUA sp= ecifications: =20 -----------------------------------------------------------------------= - [Brian F. G. Bidulock] Actually, the upper boundary at the ASP is a local matter. There are no requirements placed on the boundary. It certainly does not have to specified to the bit. -----------------------------------------------------------------------= - =20 This is all what I have been saying and the essential of the dispute be= tween me and Ilie Glib! =20 My point was -> xxUA specifications do not mandate xxUA box/layer but i= nstead leave up to implementation to chose how should the protocol be imp= lemented. This does not mean that xxUA specifications forbid layered appo= rach (i.e. a box with upper boundary) but certainly do not manadate any! = xxUA specification only specify external protocl but not any boxes/layers= - this is manatory everything else is implementation choice! =20 Thank You once again for Your cooperation! =20 with very best reagrds/ Stanislav Ivanovich =20 =20 "Brian F. G. Bidulock" wrote: Ilie, Ilie Glib wrote: (Mon, 09 Jan 2006 17:21:57) > Hello Brian, >=20 > I can not agree with you that SUA enables applications to use IP > addresses. Indeed Source and Destination addresses can contain IP > addresses, but this is an implicit impact on the xxUA users rather > than an explicit impact. Currently section "1.6.1. Definition of the > upper boundary" does not extend SS7 primitives. If this extension is > wanted it shall be in the standard documents (RFCs). Don't be absurd. 1.6.1 says that the standard SCCP/SCCP-User primitives are supported. It does not say that nothing else is supported or supportable. It does not say that no other primitives shall be used. It is just the list of intentionally supported primitives. There are, I hope you realize, more national protocol variants than just ITU or ANSI. >=20 > Apropos Source and Destination addresses cannot contain hostnames. > IMHO hostnames are much more usefull than IP addresses. >=20 > If it is wanted that xxUA become a true standard the content of the > upper boundary shall be defined down to the last bit. Actually, the upper boundary at the ASP is a local matter. There are no requirements placed on the boundary. It certainly does not have to specified to the bit. >=20 > what do you mean by > > It is not necessarily true for the multiple SG as STP scenario, > ? I mean it is not necessarily true for the multiples SG as STP scenario. >=20 > See below for one more question. >=20 > Thank you in advance >=20 > Ilie > On 1/9/06, Brian F. G. Bidulock wrote: > > Ilie, > > > > This can be true for the strict backhaul scenario. >=20 > [Ilie] Do you mean SGP to ASP interface (assuming ASP does not have > relay capability)? No. SG to ASP interface where the Provider protocol layer (e.g., SCCP) is located at the SG. That is, the ASP's point-code is hosted at the SG. --brian --=20 Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran =20 =09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! --0-1949130023-1136836503=:61482 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA17209
Thank You very much Brian, now I 100% agree with You!
&n= bsp;
I think that you pointed the very essential (!) property= of all xxUA specifications:
 
-------------= -----------------------------------------------------------
[= Brian F. G. Bidulock]
Actually, thee upper boundary at the ASP is a = local matter. There are no
requirements placed on the boundary. It cer= tainly does not have to
specified to the bit.
--------------= ----------------------------------------------------------
&n= bsp;
This is all what I have been saying and the essential of= the dispute between me and Ilie Glib!
 
My = point was -> xxUA specifications do not mandate xxUA box/layer but ins= tead leave up to implementation to chose how should the protocol be imple= mented. This does not mean that xxUA specifications forbid layered appora= ch (i.e. a box with upper boundary) but certainly do not manadate any! xxUA specification only specify external protocl bu= t not any boxes/layers - this is manatory everything else is implementati= on choice!
 
Thank You once again for Your c= ooperation!
 
with very best reagrds/ Stanis= lav Ivanovich
 


"Brian F. G. B= idulock" <bidulock@openss7.org> wrote:
Ilie,

Ilie Glib wrote: (Mon, 09 Jan 2006 17:21:= 57)
> Hello Brian,
>
> I can not agree with you that S= UA enables applications to use IP
> addresses. Indeed Source and De= stination addresses can contain IP
> addresses, but this is an impl= icit impact on the xxUA users rather
> than an explicit impact. Cur= rently section "1.6.1. Definition of the
> upper boundary" does not= extend SS7 primitives. If this extension is
> wanted it shall be in the standard documents (RFCs).

Don't be abs= urd. 1.6.1 says that the standard SCCP/SCCP-User primitives
are suppor= ted. It does not say that nothing else is supported or
supportable. It= does not say that no other primitives shall be used.
It is just the l= ist of intentionally supported primitives.

There are, I hope you r= ealize, more national protocol variants than just
ITU or ANSI.

= >
> Apropos Source and Destination addresses cannot contain hos= tnames.
> IMHO hostnames are much more usefull than IP addresses.>
> If it is wanted that xxUA become a true standard the cont= ent of the
> upper boundary shall be defined down to the last bit.<= BR>
Actually, the upper boundary at the ASP is a local matter. There a= re no
requirements placed on the boundary. It certainly does not have = to
specified to the bit.

>
> what do you mean by
&= gt; > It is not necessarily true for the multiple SG as STP scenario,
> ?

I mean it is not necessari= ly true for the multiples SG as STP scenario.

>
> See be= low for one more question.
>
> Thank you in advance
> =
> Ilie
> On 1/9/06, Brian F. G. Bidulock wrote:
> > Ilie,
> >
> > This can be true f= or the strict backhaul scenario.
>
> [Ilie] Do you mean SGP = to ASP interface (assuming ASP does not have
> relay capability)?
No. SG to ASP interface where the Provider protocol layer (e.g., SC= CP)
is located at the SG. That is, the ASP's point-code is hosted at t= he
SG.

--brian

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

____________________________= ____________________
Sigtran mailing list
Sigtran@ietf.org
https= ://www1.ietf.org/mailman/listinfo/sigtran

Yahoo! Photos =96 Showcase holiday pictures in hardcover=20 Photo Bo= oks. You design it and we=92ll bind it! --0-1949130023-1136836503=:61482-- --===============2055638587== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============2055638587==-- From sigtran-bounces@ietf.org Mon Jan 09 16:36:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew4h1-0002Wt-3c; Mon, 09 Jan 2006 16:36:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew4gx-0002WM-EX for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 16:36:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00584 for ; Mon, 9 Jan 2006 16:35:20 -0500 (EST) Received: from web35404.mail.mud.yahoo.com ([66.163.179.113]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew4nR-0006qq-HK for sigtran@ietf.org; Mon, 09 Jan 2006 16:43:27 -0500 Received: (qmail 98390 invoked by uid 60001); 9 Jan 2006 21:34:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=atHy03nAJC6VQlySucgFXdbCXLAokxaOJdKmEY4+1aM/4FvZxzZn2uWHDBYUJNYnOOFbuCy7JWBR8bQ7lDLfwzNwsuExx8xAwN0jNzpHmPpr6XPpLEMOSs6k97P5DWGGavMGuNwnWzvMXJvkAXHcy/jpL4cv27hbeC5R6+RgTKw= ; Message-ID: <20060109213417.98388.qmail@web35404.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35404.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2006 13:34:17 PST Date: Mon, 9 Jan 2006 13:34:17 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers To: SIGTRAN In-Reply-To: <20060109122329.E12775@openss7.org> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0766138259==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0766138259== Content-Type: multipart/alternative; boundary="0-1547407325-1136842457=:98374" Content-Transfer-Encoding: 8bit --0-1547407325-1136842457=:98374 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Brian, I can only confirm what I told Barry! ITU-T specifications are very clear and I have read the ITU-T Q.1400 specification and there is nothing contradictory there to my point that each SCCP-user function controls its own traffic state -> there is no other way but to leave the user-function to control this since it is application dependent (i.e. each SCCP-user application can have its own management). ITU-T Q.1400 ch. 7 "Management Functionality": "Figure 10 shows that each entity in the protocol architecture has a Level Management Entity (LME) associated with it. The LME may be more or less explicitly defined within the level. For example, in the SCCP, there are a number of management functions (e.g. SSN management) which constitute the LME for the SCCP." I do not have any problems with this since indeed SCCP management (like any other piece of functionality) has to be configured. For example SCCP Management must be configured in order to know to which remote SCCP subsystems the SCCP Management has to send SSP when it performs SSP broadcast. Another example is that "SCCP Signalling point congested" procedure as part of SCCP Management has also to be configured by the SCCP LM. However ITU-T Q.1400 certainly does not tell you that SCCP owns the functionality which is to remove the local SCCP-user form the service (or put it into service). Specifications are clear and in accordance to pure logic -> only SCCP-user entity can control logic which is to check if/how/when it can withdraw from traffic or start handling traffic! See ITU-T Q.711 "Functional description of the signalling connection control part", sec. 6.3 "SCCP management", sub-sec. 6.3.2.3.2 "STATE", "The "N-STATE request" primitive (Table 16) is used to inform the SCCP management about the status of the originating user. The "N-STATE indication" primitive is used to inform an SCCP user accordingly." Note that N-xxx means Network Layer primitive (according to OSI model) i.e. primitive from Network Layer to its user function! / stanislav "Brian F. G. Bidulock" wrote: Stanislav, Stanislav Ivanovich wrote: (Mon, 09 Jan 2006 09:32:04) > > Barry, > > > > I agree that user applications are to be isolated from the underlaying > layers (i.e. SCTP, IP etc...). However I completely disagree that as > you say both (!) entities (i.e. MTP/SCCP and their users) control the > acitvation/deactivation of applications in the traffic! Instead in the > legacy systems (and even in pure logic) it is in application > responsiblity to know if/how/when to start/stop handling traffic. > See Figure 10/Q.1400 and then reconsider Barry's answer. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1547407325-1136842457=:98374 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Brian,
 
I can only confirm what I told Barry!
 
ITU-T specifications are very clear and I have read the ITU-T Q.1400 specification and there is nothing contradictory there to my point that each SCCP-user function controls its own traffic state -> there is no other way but to leave the user-function to control this since it is application dependent (i.e. each SCCP-user application can have its own management).
 
ITU-T Q.1400 ch. 7 "Management Functionality":

"Figure 10 shows that each entity in the protocol architecture has a Level Management Entity (LME) associated with it.
The LME may be more or less explicitly defined within the level. For example, in the SCCP, there are a number of
management functions (e.g. SSN management) which constitute the LME for the SCCP."
 
I do not have any problems with this since indeed SCCP man! agement (like any other piece of functionality) has to be configured. For example SCCP Management must be configured in order to know to which remote SCCP subsystems the SCCP Management has to send SSP when it performs SSP broadcast. Another example is that "SCCP Signalling point congested" procedure as part of SCCP Management has also to be configured by the SCCP LM.
 
However ITU-T Q.1400 certainly does not tell you that SCCP owns the functionality which is to remove the local SCCP-user form the service (or put it into service). Specifications are clear and in accordance to pure logic -> only SCCP-user entity can control logic which is to check if/how/when it can withdraw from traffic or start handling traffic!
 
See ITU-T Q.711 "Functional description of the signalling connection control part", sec. 6.3 "SCCP management", sub-sec. 6.3.2.3.2 "STATE",

"The "N-STATE request" primitive (Table 16) ! is used to inform the SCCP management about the status of the originating user. The "N-STATE indication" primitive is used to inform an SCCP user accordingly."
 
Note that N-xxx means Network Layer primitive (according to OSI model) i.e. primitive from Network Layer to its user function!
 
/ stanislav
 


"Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
Stanislav,

Stanislav Ivanovich wrote: (Mon, 09 Jan 2006 09:32:04)
>
> Barry,
>
>
>
> I agree that user applications are to be isolated from the underlaying
> layers (i.e. SCTP, IP etc...). However I completely disagree that as
> you say both (!) entities (i.e. MTP/SCCP and their users) control the
> acitvation/deactivation of applications in the tr! affic! Instead in the
> legacy systems (and even in pure logic) it is in application
> responsiblity to know if/how/when to start/stop handling traffic.
>

See Figure 10/Q.1400 and then reconsider Barry's answer.

--brian



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

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1547407325-1136842457=:98374-- --===============0766138259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0766138259==-- From sigtran-bounces@ietf.org Mon Jan 09 17:22:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5Ph-0007w3-0a; Mon, 09 Jan 2006 17:22:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5Pd-0007vy-KD for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 17:22:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03526 for ; Mon, 9 Jan 2006 17:21:30 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[HStXeicKY9KUv15U0FUsxHpiiRtnWJYa]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew5WB-0008CY-Oa for sigtran@ietf.org; Mon, 09 Jan 2006 17:29:38 -0500 Received: from ns.pigworks.openss7.net (IDENT:fX546tAh6kR2Jr62rgtH5p6ow4wFA0ZL@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k09MMgw24436; Mon, 9 Jan 2006 15:22:42 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k09MMfa15112; Mon, 9 Jan 2006 15:22:41 -0700 Date: Mon, 9 Jan 2006 15:22:41 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers Message-ID: <20060109152241.B15027@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060109122329.E12775@openss7.org> <20060109213417.98388.qmail@web35404.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060109213417.98388.qmail@web35404.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Mon, Jan 09, 2006 at 01:34:17PM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Perhaps you can point to where in Q.711 the SCCP user is attached to or removed from an NSAP. ;) This is a local management function. Attaching to an NSAP is equivalent to activating an AS, detaching, deactivating. The address of the NSAP itself is the RK. Attaching and detaching a user at an NSAP is ASP Active and ASP Inactive for the AS with the RK associated with the NSAP. Understand? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 17:54:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5tv-0001KD-17; Mon, 09 Jan 2006 17:54:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5tt-0001K4-7C for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 17:54:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05786 for ; Mon, 9 Jan 2006 17:52:45 -0500 (EST) Received: from web35414.mail.mud.yahoo.com ([66.163.179.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ew60S-0000jT-TA for sigtran@ietf.org; Mon, 09 Jan 2006 18:00:53 -0500 Received: (qmail 32738 invoked by uid 60001); 9 Jan 2006 22:53:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=J++NvYLMdFaqMcWPZbbT+Zd4jH+fTcdTzuvK71S8eKDdPwaSmzUSaC4CfXGC1ijHijpWm3ZFPlbhSeqJhqbW8hoxLYYFOvZISRrzn5eXkYWBsuGCDNCpJtVrP16UYFbbwrhuSTQErHwdBq5KugLoq8efiGxkb4FnVV232QgxtIA= ; Message-ID: <20060109225355.32736.qmail@web35414.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35414.mail.mud.yahoo.com via HTTP; Mon, 09 Jan 2006 14:53:55 PST Date: Mon, 9 Jan 2006 14:53:55 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers To: SIGTRAN In-Reply-To: <20060109152241.B15027@openss7.org> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1906294381==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1906294381== Content-Type: multipart/alternative; boundary="0-220518061-1136847235=:30114" Content-Transfer-Encoding: 8bit --0-220518061-1136847235=:30114 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Brian, You actually confirm my point -> attaching/deattaching, activation/deactivation... all of these activities are performed by non-SCCP functionality, i.e. it is not SCCP that attaches or activates an SCCP subsystem but user that attaches to the service or activates itself for the traffic exchanged with the service! Users attach to service not vice versa! You cannot also find in SCCP specifications that SCCP service attaches local users... Anyway, our dispute was that according to you N-STATE_request is not a primitive between SCCP and SCCP-user but between SCCP and SCCP-LM. As I showed this is not the case but instead as I pointed it is the primitive between SCCP and SCCP-user application! By the way, are you saying that N-STATE_request from an SCCP-user application should not generate ASP_INACTIVE on the external interface??? Do you remember our last week's discussion about this -> your point was that ASP is not allowed to send DUNA reflecting N-STATE_request but instead that is to be done by ASP_ACTIVE/INACTIVE? Look at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05667.html best regards/ Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Perhaps you can point to where in Q.711 the SCCP user is attached to or removed from an NSAP. ;) This is a local management function. Attaching to an NSAP is equivalent to activating an AS, detaching, deactivating. The address of the NSAP itself is the RK. Attaching and detaching a user at an NSAP is ASP Active and ASP Inactive for the AS with the RK associated with the NSAP. Understand? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-220518061-1136847235=:30114 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Brian,
 
You actually confirm my point -> attaching/deattaching, activation/deactivation... all of these activities are performed by non-SCCP functionality, i.e. it is not SCCP that attaches or activates an SCCP subsystem but user that attaches to the service or activates itself for the traffic exchanged with the service! Users attach to service not vice versa!
 
You cannot also find in SCCP specifications that SCCP service attaches local users...
 
 
Anyway, our dispute was that according to you N-STATE_request is not a primitive between SCCP and SCCP-user but between SCCP and SCCP-LM. As I showed this is not the case but instead as I pointed it is the primitive between SCCP and SCCP-user application!
 
By the way, are you saying that N-STATE_request from an SCCP-user application should not generate ASP_INACTIVE on the external interface??? Do you remember our last week's discussion about this -> your point was that ASP is not allowed to send DUNA reflecting N-STATE_request but instead that is to be done by ASP_ACTIVE/INACTIVE? Look at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05667.html
 
 
best regards/ Stanislav Ivanovich
  


"Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
Stanislav,

Perhaps you can point to where in Q.711 the SCCP user is attached to
or removed from an NSAP. ;)

This is a local management function. Attaching to an NSAP is equivalent
to activating an AS, detaching, deactivating. The address of the NSAP
itself is the RK. At! taching and detaching a user at an NSAP is ASP Active
and ASP Inactive for the AS with the RK associated with the NSAP.

Understand?

--brian

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

Yahoo! DSL Something to write home about. Just $16.99/mo. or less --0-220518061-1136847235=:30114-- --===============1906294381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1906294381==-- From sigtran-bounces@ietf.org Mon Jan 09 18:47:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew6ja-0008Vq-Sa; Mon, 09 Jan 2006 18:47:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew6jY-0008Vj-OT for sigtran@megatron.ietf.org; Mon, 09 Jan 2006 18:47:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08582 for ; Mon, 9 Jan 2006 18:46:09 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[VksHRajVkkiALHldoVmFdpNyo67EBl0O]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew6q9-00024N-EE for sigtran@ietf.org; Mon, 09 Jan 2006 18:54:17 -0500 Received: from ns.pigworks.openss7.net (IDENT:yejWD0IIxHglSG+nyOXW1UgonnvR6mug@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k09NlQw25565; Mon, 9 Jan 2006 16:47:26 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k09NlPV16408; Mon, 9 Jan 2006 16:47:25 -0700 Date: Mon, 9 Jan 2006 16:47:25 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers Message-ID: <20060109164725.A15809@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060109152241.B15027@openss7.org> <20060109225355.32736.qmail@web35414.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060109225355.32736.qmail@web35414.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Mon, Jan 09, 2006 at 02:53:55PM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, No, the N-STATE Request does not necessarily originate at the Subsystem (SCCP-User). This is particularly true of TCAP, which separates these management functions from the user functions. Also not that N-STATE Request does not have sufficient information for SCCP to do its job. It must be determined whether an out of service subsystem is a transient or permanent condition. Furthermore, a separate interface than that used to transfer data on a connection (CONS) must be used to signal that a connection-oriented subsystem is out of service, and again, it must be signalled whether it is a transient or permanent condition. Although TCAP can bind to multiple NSAPs for the same subsystem, and each can receive N-STATE indication, N-STATE request must is sent by a separate management function. Nevertheless, your SCCP-User at the ASP can issue N-STATE Request to SUA at the ASP to its heart's content. SUA will translate this to ASP Active/Inactive. At the SG, the SG is responsible for determining the availability of the subsystem (from AS availablility) and issuing local N-STATE Requests as necessary. At the SG, N-STATE Request does not come from the user, it is generated by the NIF to present a single management view of the subsystem to the SS7 network and other SCCP users. --brian Stanislav Ivanovich wrote: (Mon, 09 Jan 2006 14:53:55) > > Brian, > > > > You actually confirm my point -> attaching/deattaching, > activation/deactivation... all of these activities are performed by > non-SCCP functionality, i.e. it is not SCCP that attaches or activates > an SCCP subsystem but user that attaches to the service or activates > itself for the traffic exchanged with the service! Users attach to > service not vice versa! > > > > You cannot also find in SCCP specifications that SCCP service attaches > local users... > > > > > > Anyway, our dispute was that according to you N-STATE_request is not a > primitive between SCCP and SCCP-user but between SCCP and SCCP-LM. As > I showed this is not the case but instead as I pointed it is the > primitive between SCCP and SCCP-user application! > > > > By the way, are you saying that N-STATE_request from an SCCP-user > application should not generate ASP_INACTIVE on the external > interface??? Do you remember our last week's discussion about this -> > your point was that ASP is not allowed to send DUNA > reflecting N-STATE_request but instead that is to be done by > ASP_ACTIVE/INACTIVE? Look at > [1]http://www1.ietf.org/mail-archive/web/sigtran/current/msg05667.html > > > > > > best regards/ Stanislav Ivanovich -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 09 20:36:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew8RI-0000om-Pp; Mon, 09 Jan 2006 20:36:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew8RF-0000o6-Vr; Mon, 09 Jan 2006 20:36:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17498; Mon, 9 Jan 2006 20:35:21 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew8Xp-0005mU-Cp; Mon, 09 Jan 2006 20:43:30 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0A1aHi05183; Mon, 9 Jan 2006 17:36:17 -0800 (PST) Message-Id: <200601100136.k0A1aHi05183@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 09 Jan 2006 17:36:16 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sigtran@ietf.org, rfc-editor@rfc-editor.org Subject: [Sigtran] RFC 4233 on Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4233 Title: Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer Author(s): K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom Status: Standards Track Date: January 2006 Mailbox: kmorneau@cisco.com, mkalla@telcordia.com, selvam@trideaworks.com, greg@signatustechnologies.com Pages: 73 Characters: 157857 Obsoletes: 3057 I-D Tag: draft-ietf-sigtran-rfc3057bis-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4233.txt This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. This document obsoletes RFC 3057. This document is a product of the Signaling Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <060109173514.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4233 --OtherAccess Content-Type: Message/External-body; name="rfc4233.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <060109173514.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --NextPart-- From sigtran-bounces@ietf.org Tue Jan 10 06:02:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHGr-0002on-2C; Tue, 10 Jan 2006 06:02:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHGp-0002oi-61 for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 06:02:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21981 for ; Tue, 10 Jan 2006 06:01:11 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwHNV-00050M-TG for sigtran@ietf.org; Tue, 10 Jan 2006 06:09:26 -0500 Received: from nproxy.gmail.com ([64.233.182.206]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EwHGm-0003rI-BJ for sigtran@ietf.org; Tue, 10 Jan 2006 06:02:28 -0500 Received: by nproxy.gmail.com with SMTP id n28so241373nfc for ; Tue, 10 Jan 2006 03:00:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hW1eFid5+dFPdEyq6Xm+nB74coDolRB0Gwq/o7Rk/yenaRinnN0p2S0uURJ0jrsv5aqKD/8h1f5pwK5H2XuIHJDl+uJ5zM34PcQ+CoNUdiXlOGxaiO0R10/zDU2C0zlDuBt3iI8rqaKHeO7cWvbGBnxlIcKn0uYsSYxvGQcBQ2k= Received: by 10.49.2.9 with SMTP id e9mr980922nfi; Tue, 10 Jan 2006 03:00:53 -0800 (PST) Received: by 10.48.1.13 with HTTP; Tue, 10 Jan 2006 03:00:52 -0800 (PST) Message-ID: <17b146d60601100300w6ec282f7o8ede4090edd165dc@mail.gmail.com> Date: Tue, 10 Jan 2006 12:00:52 +0100 From: Ilie Glib To: bidulock@openss7.org, Ilie Glib , SIGTRAN Subject: Re: [Sigtran] Upper boundary of Adaptation Layers In-Reply-To: <20060109115841.B12775@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> <20060109081933.A10655@openss7.org> <17b146d60601090821v6956a220w3380c9affb8c4011@mail.gmail.com> <20060109115841.B12775@openss7.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Brian, On 1/9/06, Brian F. G. Bidulock wrote: > Ilie, > > Ilie Glib wrote: (Mo= n, 09 Jan 2006 17:21:57) > > Hello Brian, > > > > I can not agree with you that SUA enables applications to use IP > > addresses. Indeed Source and Destination addresses can contain IP > > addresses, but this is an implicit impact on the xxUA users rather > > than an explicit impact. Currently section "1.6.1. Definition of the > > upper boundary" does not extend SS7 primitives. If this extension is > > wanted it shall be in the standard documents (RFCs). > > Don't be absurd. 1.6.1 says that the standard SCCP/SCCP-User primitives > are supported. [Ilie] Therefore an implementation of SUA Layer in may not have any other primitives than SCCP/SCCP-User primitives. Is this correct? >It does not say that nothing else is supported or > supportable. It does not say that no other primitives shall be used. > It is just the list of intentionally supported primitives. > > There are, I hope you realize, more national protocol variants than just > ITU or ANSI. > > > > > Apropos Source and Destination addresses cannot contain hostnames. > > IMHO hostnames are much more usefull than IP addresses. > > > > If it is wanted that xxUA become a true standard the content of the > > upper boundary shall be defined down to the last bit. > > Actually, the upper boundary at the ASP is a local matter. There are no > requirements placed on the boundary. It certainly does not have to > specified to the bit. [Ilie] This was just a poetical exaggeration. I interpret your statement above, that it is an implementation matter whether other than SCCP/SCCP-User primitives are introduced or not. By the way are there any standardized SCCP/SUA (M3UA) user applications/protocols that use other primitives that those mentioned in 1.6.1? I have not heard of any. My opinion is that it is not possible to standardize an xxUA-User /Application (which uses an extended service as compared to SCCP/MTP3) without having the SUA/M3UA upper boundary well defined, at the level the ITU-T defines SCCP-User primitives, or alternatively this new standard of the application shall refine its lower boundary. Do you agree? With the current definition of the xxUA upper boundary all User Applications will rely on the definitions in the SS7 (section 1.6.1 in the RFCs). If some vendors will implement extensions to the primitives in 1.6.1, those will be most probably due to internal system architecture. Regards -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 07:11:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwILr-0001bf-VZ; Tue, 10 Jan 2006 07:11:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwILp-0001ba-6z for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 07:11:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25674 for ; Tue, 10 Jan 2006 07:10:25 -0500 (EST) Received: from web35402.mail.mud.yahoo.com ([66.163.179.111]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwIST-0006iW-Pw for sigtran@ietf.org; Tue, 10 Jan 2006 07:18:41 -0500 Received: (qmail 51443 invoked by uid 60001); 10 Jan 2006 12:11:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1Ux5Bi/9VwjLsAm6H62A3zdyA823P4+Rzsd26MLrVimMrRsjhiCJsEsFo57klYhYYywfL9Nmx3Myg3sp6B3EBMQgB5ZsjSIYiMakRWF1HHSDIOmy2HfSEl3vlF/0IFUJQjzhMzi1cubipdElh6u+pHCXHfmLTVgJlF835PBZSSY= ; Message-ID: <20060110121132.51441.qmail@web35402.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35402.mail.mud.yahoo.com via HTTP; Tue, 10 Jan 2006 04:11:32 PST Date: Tue, 10 Jan 2006 04:11:32 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Upper boundary of Adaptation Layers To: SIGTRAN In-Reply-To: <17b146d60601090849g4489b48bsfd0823aa4ab3f9de@mail.gmail.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0855067756==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0855067756== Content-Type: multipart/alternative; boundary="0-1111905908-1136895092=:51171" Content-Transfer-Encoding: 8bit --0-1111905908-1136895092=:51171 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Ilie, Please read Brian's statement that I 100% agree with: ------------------------------------------------------------------------ [Brian F. G. Bidulock] Actually, the upper boundary at the ASP is a local matter. There are no requirements placed on the boundary. It certainly does not have to specified to the bit. ------------------------------------------------------------------------ What Brian claims here is what I believe is the very essential (!) truth for all xxUA specifications. It is very important here to note that this is not so because of some agreement with the SIGTRAN community but rather a consequence of the very fundamental SIGTRAN concepts -> ASP/IPSP is an application resource not transmission one. For example no one would ever accept that M3UA specifies internal (!) boundaries of MTP3-user applications which use M3UA protocol. The same is the case for any other xxUA. The point is -> IPSP/ASP'es are application processes whose internal structure is irrelevant for xxUA specifications. What these specifications mandate is only external protocol i.e. behavior of the application processes on the external interface. Internal structure of application processes i.e. should there be any particular layer/box is irrelevant for the xxUA specifications. Therefore it is not true that xxUA specifications do mandate any particular layer/box which must have defined upper boundary. It is not true that xxUA specifications say "there MUST be a layer within an application process". However xxUA specifications do not forbid layered approach -> you can implement since it is not visible externally -> externally is only important that ASP/IPSP (application clones) behave according to xxUA protocols. Nevertheless applications are APS/IPSP'es which control their own resources -> activation/deactivation... therfore applications (!) control behavior on the external xxUA protocol rather then some magic xxUA box/layer -> there is no such box in xxUA specifications but you can implement them as implementation choice! Specifications only specify external protocols not internal ones! / stanislav Ilie Glib wrote: Stanislav I should correct myself. I mean that there are no doubts that there are xxUA Layers, and applications residing on top of them depend on them as SCCP-Users, depend on SCCP services. Regards Ilie On 1/9/06, Ilie Glib wrote: > Hello Stanislav, > > On 1/9/06, Stanislav Ivanovich wrote: > > Hello, > > > > Since I find Ilie's questions ambiguous I will extend his questions by > > asking: > > > > 1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP > > process states) indepdnednetly on MTP-user or SCCP-user applications by > > making these applications idendepndtz on the ASP/IPSP state? > > > > [Ilie] I have not questioned that, in my view this is a fact written > in stone (RFCs). > check e.g. the SIGTRAN applicability draft: > http://tools.ietf.org/html/draft-ietf-sigtran-signalling-over-sctp-applic-09.txt > > > 2) If such layer exisits and if M3UA and SUA are not just and only protocls > > but also boxes/layers which have a place in the signalling system which is > > to isolate user functions on ASP/IPSP state shold such layer own the control > > on ASP/IPSP states? > > > > For example SCCP subsystem does not want to handle traffic. In legacy > > systems SCCP-user applications own the control on the SCCP-subsystem state > > change thus they control appaearance on N-STATE_request primitive on SCCP > > API. > > However if one thinks that xxUA is not just a set of protocls (ASP-SGP and > > IPSP-IPSP) but also a box which contains a functionality which is to isolate > > user functions on SIGTRAN concepts (like ASP/IPSP) does that imply that such > > box should own commands for AS state change, i.e. it is SUA box but not SCCP > > user function which owns control on AS state change, see section 1.6.3. in > > xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management: > > > > M-ASP_ACTIVE request > > Direction: LM -> SUA > > Purpose: LM requests ASP to send an ASP Active message to its peer. > > M-ASP_INACTIVE request > > Direction: LM -> SUA > > Purpose: LM requests ASP to send an ASP Inactive message to its > > peer. > > > > Is this an RFC fault? > > > > > > regards/ stanislav > > > > > > Ilie Glib wrote: > > Hello Folks, > > > > In my current understanding of the SIGTRAN: > > > > - SUA and M3UA RFCs define the primitives of the adaptation layers > > towards their users in Section "1.6.1. Definition of the upper > > boundary". > > SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the > > complete definition of the primitives towards the users, therefore > > SIGTRAN supports existing > > SCCP/MTP users without them being aware of the fact that SIGTRAN is > > used for the transport of messages. > > SIGTRAN concepts and the corresponding entities/objects like AS, RK, > > RC, IPSP, ASP, and SGP are not part of the currently standardized > > upper boundary of M3UA (SUA). > > Thus today's SIGTRAN users do not know anything about those concepts. > > > > Can you please confirm this view or tell me if I'm mislead by my > > interpretation ? > > > > Is their any attempt in SIGTRAN WG to define! an extended upper > > boundary for xxUA that gives the option of managing entities like AS, > > RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced > > services expected from adaptation layers ? > > > > Thank you in advance > > > > -- > > Ilie > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > ________________________________ > > Yahoo! Photos > > Ring in the New Year with Photo Calendars. Add photos, events, holidays, > > whatever. > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > -- > Ilie > -- Ilie --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1111905908-1136895092=:51171 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Ilie,
 
Please read Brian's statement that I 100% agree with:
 
------------------------------------------------------------------------
[Brian F. G. Bidulock]
Actually, the upper boundary at the ASP is a local matter. There are no
requirements placed on the boundary. It certainly does not have to
specified to the bit.
------------------------------------------------------------------------
 
What Brian claims here is what I believe is the very essential (!) truth for all xxUA specifications. It is very important here to note that this is not so because of some agreement with the SIGTRAN community but rather a consequence of the very fundamental SIGTRAN concepts -> ASP/IPSP is an application resource not transmission one.
 
For example no one would ever accept that M3UA specifies internal (!) boundaries of MTP3-user appl! ications which use M3UA protocol. The same is the case for any other xxUA.
 
The point is -> IPSP/ASP'es are application processes whose internal structure is irrelevant for xxUA specifications. What these specifications mandate is only external protocol i.e. behavior of the application processes on the external interface. Internal structure of application processes i.e. should there be any particular layer/box is irrelevant for the xxUA specifications.
 
Therefore it is not true that xxUA specifications do mandate any particular layer/box which must have defined upper boundary. It is not true that xxUA specifications say "there MUST be a layer within an application process". However xxUA specifications do not forbid layered approach -> you can implement since it is not visible externally -> externally is only important that ASP/IPSP (application clones) behave according to xxUA protocols.
 
Nevertheless applications are APS/IPSP'es which control their own resources -> activation/deactivation... therfore applications (!) control behavior on the external xxUA protocol rather then some magic xxUA box/layer -> there is no such box in xxUA specifications but you can implement them as implementation choice! Specifications only specify external protocols not internal ones!
 
/ stanislav
 


Ilie Glib <ilie.glib@googlemail.com> wrote:
Stanislav

I should correct myself. I mean that there are no doubts that there
are xxUA Layers, and applications residing on top of them depend on
them as SCCP-Users, depend on SCCP services.

Regards

Ilie

On 1/9/06, Ilie Glib wrote:
> Hello Stanislav,
>
> On! 1/9/06, Stanislav Ivanovich wrote:
> > Hello,
> >
> > Since I find Ilie's questions ambiguous I will extend his questions by
> > asking:
> >
> > 1) Is there a layer which owns state of SIGTRAN objects (like ASP/IPSP
> > process states) indepdnednetly on MTP-user or SCCP-user applications by
> > making these applications idendepndtz on the ASP/IPSP state?
> >
>
> [Ilie] I have not questioned that, in my view this is a fact written
> in stone (RFCs).
> check e.g. the SIGTRAN applicability draft:
> http://tools.ietf.org/html/draft-ietf-sigtran-signalling-over-sctp-applic-09.txt
>
> > 2) If such layer exisits and if M3UA and SUA are not just and only protocls
> > but also boxes/layers which have a place in the signalling system which is
> > to isolate user functions on ASP/IPSP state shold such layer own the control
> > on ASP/IPSP states?
> >
> > For example SCCP subsystem does not want to handle traffic. In legacy
> > systems SCCP-user applications own the control on the SCCP-subsystem state
> > change thus they control appaearance on N-STATE_request primitive on SCCP
> > API.
> > However if one thinks that xxUA is not just a set of protocls (ASP-SGP and
> > IPSP-IPSP) but also a box which contains a functionality which is to isolate
> > user functions on SIGTRAN concepts (like ASP/IPSP) does that imply that such
> > box should own commands for AS state change, i.e. it is SUA box but not SCCP
> > user function which owns control on AS state change, see section 1.6.3. in
> > xxUA RFCs, e.g. Definition of the Boundary between SUA and Layer Management:
> >
> > M-ASP_ACTIVE request
> > Direction: LM -> SUA
> > Purpose: LM requests ASP ! to send an ASP Active message to its peer.
> > M-ASP_INACTIVE request
> > Direction: LM -> SUA
> > Purpose: LM requests ASP to send an ASP Inactive message to its
> > peer.
> >
> > Is this an RFC fault?
> >
> >
> > regards/ stanislav
> >
> >
> > Ilie Glib wrote:
> > Hello Folks,
> >
> > In my current understanding of the SIGTRAN:
> >
> > - SUA and M3UA RFCs define the primitives of the adaptation layers
> > towards their users in Section "1.6.1. Definition of the upper
> > boundary".
> > SUA and M3UA RFCs simply refer to ITU-T and ANSI standards for the
> > complete definition of the primitives towards the users, therefore
> > SIGTRAN supports existing
> > SCCP/MTP users without them being aware of the fact that SIGTRAN is
> > used for the t! ransport of messages.
> > SIGTRAN concepts and the corresponding entities/objects like AS, RK,
> > RC, IPSP, ASP, and SGP are not part of the currently standardized
> > upper boundary of M3UA (SUA).
> > Thus today's SIGTRAN users do not know anything about those concepts.
> >
> > Can you please confirm this view or tell me if I'm mislead by my
> > interpretation ?
> >
> > Is their any attempt in SIGTRAN WG to define! an extended upper
> > boundary for xxUA that gives the option of managing entities like AS,
> > RK, RC, IPSP, ASP, and SGP to xxUA users and what are the enhanced
> > services expected from adaptation layers ?
> >
> > Thank you in advance
> >
> > --
> > Ilie
> >
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran@ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> >
> > ________________________________
> > Yahoo! Photos
> > Ring in the New Year with Photo Calendars. Add photos, events, holidays,
> > whatever.
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran@ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> >
>
>
> --
> Ilie
>


--
Ilie

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1111905908-1136895092=:51171-- --===============0855067756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0855067756==-- From sigtran-bounces@ietf.org Tue Jan 10 09:08:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKBG-000507-EI; Tue, 10 Jan 2006 09:08:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKBE-0004xZ-KB for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 09:08:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05173 for ; Tue, 10 Jan 2006 09:07:35 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[EPjYsciEq8ZfRo1RthKkCp0JuREwcZ2W]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwKHw-0002I4-HC for sigtran@ietf.org; Tue, 10 Jan 2006 09:15:52 -0500 Received: from ns.pigworks.openss7.net (IDENT:kCSlrnGmBhd7W5Jx5v5P2/crbP3G0R3Z@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0AE8hw19278; Tue, 10 Jan 2006 07:08:43 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0AE8gp29319; Tue, 10 Jan 2006 07:08:42 -0700 Date: Tue, 10 Jan 2006 07:08:42 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] Upper boundary of Adaptation Layers Message-ID: <20060110070842.B29048@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> <20060109081933.A10655@openss7.org> <17b146d60601090821v6956a220w3380c9affb8c4011@mail.gmail.com> <20060109115841.B12775@openss7.org> <17b146d60601100300w6ec282f7o8ede4090edd165dc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601100300w6ec282f7o8ede4090edd165dc@mail.gmail.com>; from ilie.glib@googlemail.com on Tue, Jan 10, 2006 at 12:00:52PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, Ilie Glib wrote: (Tue, 10 Jan 2006 12:00:52) > Hello Brian, > > On 1/9/06, Brian F. G. Bidulock wrote: > > Ilie, > > > > Ilie Glib wrote: (Mon, 09 Jan 2006 17:21:57) > > > Hello Brian, > > > > > > I can not agree with you that SUA enables applications to use IP > > > addresses. Indeed Source and Destination addresses can contain IP > > > addresses, but this is an implicit impact on the xxUA users rather > > > than an explicit impact. Currently section "1.6.1. Definition of the > > > upper boundary" does not extend SS7 primitives. If this extension is > > > wanted it shall be in the standard documents (RFCs). > > > > Don't be absurd. 1.6.1 says that the standard SCCP/SCCP-User primitives > > are supported. > > [Ilie] Therefore an implementation of SUA Layer in may not have any > other primitives than SCCP/SCCP-User primitives. Is this correct? > Read on: > >It does not say that nothing else is supported or > > supportable. It does not say that no other primitives shall be used. > > It is just the list of intentionally supported primitives. > > > > There are, I hope you realize, more national protocol variants than just > > ITU or ANSI. > > > > > > > > Apropos Source and Destination addresses cannot contain hostnames. > > > IMHO hostnames are much more usefull than IP addresses. > > > > > > If it is wanted that xxUA become a true standard the content of the > > > upper boundary shall be defined down to the last bit. > > > > Actually, the upper boundary at the ASP is a local matter. There are no > > requirements placed on the boundary. It certainly does not have to > > specified to the bit. > > [Ilie] This was just a poetical exaggeration. > > I interpret your statement above, that it is an implementation matter > whether other than SCCP/SCCP-User primitives are introduced or not. > By the way are there any standardized SCCP/SUA (M3UA) user > applications/protocols that use other primitives that those mentioned > in 1.6.1? > I have not heard of any. > My opinion is that it is not possible to standardize an xxUA-User > /Application (which uses an extended service as compared to > SCCP/MTP3) without having the SUA/M3UA upper boundary well defined, at > the level the ITU-T defines SCCP-User primitives, or alternatively > this new standard of the application shall refine its lower boundary. > Do you agree? > > With the current definition of the xxUA upper boundary all User > Applications will rely on the definitions in the SS7 (section 1.6.1 in > the RFCs). > If some vendors will implement extensions to the primitives in 1.6.1, > those will be most probably due to internal system architecture. I don't know what you mean by "rely on." All SS7 stacks are vendor specific. The only thing an application can rely upon is the interface provided by the vendor. The closest to an application interface standard is the Network Provider Interface (NPI) from UNIX International (OSI Work Group) [now OpenGroup], which provides X.210 support for X.213 and can, therefore, be applied to SCCP. The NPI uses N_BIND_REQ/N_BIND_ACK instead of N-STATE Request/Indication, and N_UDERR_IND/N_DISCON_IND instead of N-NOTICE and N-PCSTATE. Q.713 even provides mapping of SCCP causes into X.213 causes so the OSI header files for NPI are usable. The other UAs have no API standard whatsoever. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 11:40:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMYB-0002iM-CG; Tue, 10 Jan 2006 11:40:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMYA-0002iH-0V for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 11:40:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19719 for ; Tue, 10 Jan 2006 11:39:25 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMep-0008W4-9b for Sigtran@ietf.org; Tue, 10 Jan 2006 11:47:42 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0AGcUVI095304 for ; Tue, 10 Jan 2006 08:38:32 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <001e01c61604$700a20b0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Tue, 10 Jan 2006 19:39:26 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1235/Sun Jan 8 10:13:01 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Subject: [Sigtran] Multiple SCTP associations X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0199290687==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0199290687== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C6161D.90F6BDB0" This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C6161D.90F6BDB0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, It seems that multiple SCTP associations established between the same = two signaling processes are not [explicitly] prohibited. 1. Is it legal for a signaling process to establish more than one SCTP = association to the same AS/SG where these multiple associations are = served by different signaling processes? 2. Is it legal for a signaling process to establish more than one SCTP = association to the same signaling process at the remote side? (I feel that the 2nd case may be reasonable only when the remote side = does not support multi-homed SCTP endpoints.) Regards, Sergey Mikhailov. ------=_NextPart_000_001B_01C6161D.90F6BDB0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi,
 
It seems that multiple SCTP = associations=20 established between the same two signaling processes are not = [explicitly]=20 prohibited.
 
1.
Is it legal for a signaling process to = establish more than one SCTP association to the = same AS/SG=20 where these multiple associations are served by different signaling=20 processes?
 
2.
Is it legal for a signaling process to = establish=20 more than one SCTP association to the same signaling process at the = remote=20 side?
 
(I feel that the 2nd case may be = reasonable only=20 when the remote side does not support multi-homed SCTP = endpoints.)
 
 
Regards,
Sergey = Mikhailov.
------=_NextPart_000_001B_01C6161D.90F6BDB0-- --===============0199290687== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0199290687==-- From sigtran-bounces@ietf.org Tue Jan 10 11:52:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMju-00071K-G4; Tue, 10 Jan 2006 11:52:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMjs-00070p-Nq for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 11:52:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20607 for ; Tue, 10 Jan 2006 11:51:32 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMqa-0000RV-Mt for sigtran@ietf.org; Tue, 10 Jan 2006 11:59:50 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id FD665D2F3F for ; Tue, 10 Jan 2006 11:52:28 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0AGqQvE016328 for ; Tue, 10 Jan 2006 11:52:27 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SCTP associations Date: Tue, 10 Jan 2006 11:33:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001e01c61604$700a20b0$150f0f0a@smikhailov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Sergey Mikhailov Sent: Tuesday, January 10, 2006 11:39 AM To: SIGTRAN Subject: [Sigtran] Multiple SCTP associations Hi, It seems that multiple SCTP associations established between the same two signaling processes are not [explicitly] prohibited. 1. Is it legal for a signaling process to establish more than one SCTP association to the same AS/SG where these multiple associations are served by different signaling processes? [TOLGA]Yes, this is how host redundancy is achieved (I assume you talk about M3UA/SUA). There are multiple ASPs serving an AS, and multiple SGPs in a SG, and there is a SCTP association between each SGP/ASP pair -well, obviously it is not mandatory-. 2. Is it legal for a signaling process to establish more than one SCTP association to the same signaling process at the remote side? (I feel that the 2nd case may be reasonable only when the remote side does not support multi-homed SCTP endpoints.) [TOLGA]Multiple SCTP assocaitions between two etities will have problems with ASP state machine if you follow it strictly considering the state transitions associated with events from SCTP. This is easy to overcome with a some reasonable reinterpretation. OTOH, multiple SCTP associations won't be a replacement for SCTP multihoming support because SCTP multihoming provided network/NIC redundancy without loss/missequencing of messages. Regards, Sergey Mikhailov. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 11:59:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMqe-0008M1-21; Tue, 10 Jan 2006 11:59:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMqb-0008Lf-SP for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 11:59:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21056 for ; Tue, 10 Jan 2006 11:58:30 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMxL-0000fb-NV for sigtran@ietf.org; Tue, 10 Jan 2006 12:06:48 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id DEE3096BBA for ; Tue, 10 Jan 2006 11:59:40 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0AGxcCL017058 for ; Tue, 10 Jan 2006 11:59:39 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Upper boundary of Adaptation Layers Date: Tue, 10 Jan 2006 11:40:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060109163640.41923.qmail@web35404.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Monday, January 09, 2006 11:37 AM To: SIGTRAN Subject: Re: [Sigtran] Upper boundary of Adaptation Layers Brian, Tolga, Brian, are you saying that SCCP-user function is not owner of the management of its resources, i.e. user function does not own control if/how/when it can withdraw from the traffic? For example an SCCP-user application in ISDN networks installed in an SCCP-subsystem has to do certain checks when and how and if it can withdraw from the traffic, and another SCCP-user application in WCDMA networks installed in an SCCP-subsystem performs other checks different from the first ones. So these cheks cannot be part of SCCP and for this reason ITU-T puts it in SCCP-user applications by introducing N-STATE_request primitive. Are you saying that SUA layer (which should replace SCCP) should own command which is to remove an SCCP-user from traffic (i.e. generate ASP_INACTIVE message)? If so how do you make your SUA box/layer application independet since each application has its own chec! ks and actions performed when withdrawing from the traffic? Tolga, I read your comments on the question posted on 4th of November by Prasad Shashank at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05292.html and answers from you at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05295.html and http://www1.ietf.org/mail-archive/web/sigtran/current/msg05297.html. I completely agree with you but in order to make it clear I just want to make it more explicit: 1) Is the user application the entitiy which sends tr! affic from a local ASP/IPSP or it is in xxUA "box/layer" responsiblity which is to be indepednet on applications and which decides which local (!) IPSP/ASP to use. In other words is it that you have one application supported by xxUA box/layer and within this xxUA box/layer you have 2 or more local IPSP/ASP processes and it is then in this xxUA box/layer responisbility to chose right ASP/IPSP? In my view you install an application in a process and when this applicaton clone generates traffic it is unambiguous which local ASP/IPSP to use since the local process is application resource (clone). Please confirm or deny my understanding. [TOLGA]Yes, I agree with your interpretation. It probably is not wrong from SIGTRAN point of view to build a system with the other approach but I don't know why one would like to do that. 2) In my view xxUA is not a box/layer but only a set of protocls (ASP-SGP and IPSP-IPSP). ASP/IPSP is a user application entity own and controlled by the application. However possibly being wrong I need answer on this -> is it! true that xxUA specifications manadate (!) that there must (!) be a layer/box which is to own control on which local ASP/IPSP to use when sending traffic. 3) I kindly ask you to comment SUA example above and Brian's point about the fact that applications do not own control on their wiothdrawal from or statrting of traffic. [TOLGA]For that issue, I think similar to the clarifications stated in the list by Brian. many thanks and regards/ stanislav "Brian F. G. Bidulock" wrote: Stanislav, Stanislav Ivanovich wrote: (Mon, 09 Jan 2006 07:27:17) ---X-snip-X--- > > M-ASP_ACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP to send an ASP Active message to its peer. > M-ASP_INACTIVE request > Direction: LM -> SUA > Purpose: LM requests ASP ! to send an ASP Inactive message to its > peer. > > Is this an RFC fault? No. SCCP also requires local management. N-STATE request is not an SCCP/SCCP-User primitive. It is an SCCP/SCCP Management primitive. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 12:00:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMrH-00006H-Kf; Tue, 10 Jan 2006 12:00:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMrG-00005f-24 for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 12:00:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21104 for ; Tue, 10 Jan 2006 11:59:10 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMxv-0000gb-Rj for sigtran@ietf.org; Tue, 10 Jan 2006 12:07:25 -0500 Received: by nproxy.gmail.com with SMTP id c29so207176nfb for ; Tue, 10 Jan 2006 09:00:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ei6pzoAdri83Qh5Eor8N8NJsYL9Rd/48rHzCpLgUUx8yxBBwME7w6Wd85sKZdHfWXJ8DWKMs8IIVYG7EiRMmJPzzlnLzDTx3R6qx4yeQM7J4GUHX7BRx7FzVZDOOYlFj2q6O21WT96BqHlTtdd2AEf5fzh8isb1mdiXFStyGQTI= Received: by 10.49.94.7 with SMTP id w7mr428140nfl; Tue, 10 Jan 2006 06:49:31 -0800 (PST) Received: by 10.48.1.13 with HTTP; Tue, 10 Jan 2006 06:49:31 -0800 (PST) Message-ID: <17b146d60601100649p6f3cf8a5l1d897534e97fabbb@mail.gmail.com> Date: Tue, 10 Jan 2006 15:49:31 +0100 From: Ilie Glib To: bidulock@openss7.org, Ilie Glib , SIGTRAN Subject: Re: [Sigtran] Upper boundary of Adaptation Layers In-Reply-To: <20060110070842.B29048@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> <20060109081933.A10655@openss7.org> <17b146d60601090821v6956a220w3380c9affb8c4011@mail.gmail.com> <20060109115841.B12775@openss7.org> <17b146d60601100300w6ec282f7o8ede4090edd165dc@mail.gmail.com> <20060110070842.B29048@openss7.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, I am happy about your statements > > [Ilie] Therefore an implementation of SUA Layer in may not have any > > other primitives than SCCP/SCCP-User primitives. Is this correct? > > > > Read on: > > > >It does not say that nothing else is supported or > > > supportable. It does not say that no other primitives shall be used. > > > It is just the list of intentionally supported primitives. > > I don't know what you mean by "rely on." [Ilie] My understanding is that SCCP-users are standardized as application layers using services provided by SCCP in its primitives to the SCCP-Users. Thus applications rely (read use) SCCP upper boundary as of Q.711. >All SS7 stacks are vendor > specific. The only thing an application can rely upon is the interface > provided by the vendor. > [Ilie] I believe it is not very difficult for SCCP User applications to change from SCCP layer of one vendor to another (or from SCCP use to SUA), they anyway follow the primitives of Q.711. -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 12:17:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwN6W-0004jZ-Ri; Tue, 10 Jan 2006 12:16:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwN6U-0004cx-Br for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 12:16:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22396 for ; Tue, 10 Jan 2006 12:14:54 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwNDD-0001FO-BA for Sigtran@ietf.org; Tue, 10 Jan 2006 12:23:12 -0500 Received: by nproxy.gmail.com with SMTP id c29so209565nfb for ; Tue, 10 Jan 2006 09:16:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KKZjGAI4Fcs07BIufHtNQX2j3PUhTyYluImoXCrGOh5M+q9mG/0pJMbNkOQ4ICHnEDuw7xRrGaJGZ/Njgq9Lgu6pX7Pw73Dv3N0+Yfk4gIWPXs7kIEo1BVMTU8wowSz0kYeDgs/sKP9gRrBrWXiGi+x54x5s6EEbkF6ZYvvAM7o= Received: by 10.49.94.7 with SMTP id w7mr441115nfl; Tue, 10 Jan 2006 09:16:07 -0800 (PST) Received: by 10.48.1.13 with HTTP; Tue, 10 Jan 2006 09:16:07 -0800 (PST) Message-ID: <17b146d60601100916o7dc29a9eh4a1debcf9770452b@mail.gmail.com> Date: Tue, 10 Jan 2006 18:16:07 +0100 From: Ilie Glib To: Sergey Mikhailov Subject: Re: [Sigtran] Multiple SCTP associations In-Reply-To: <001e01c61604$700a20b0$150f0f0a@smikhailov> MIME-Version: 1.0 References: <001e01c61604$700a20b0$150f0f0a@smikhailov> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0585031558==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0585031558== Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 Content-Disposition: inline Content-Transfer-Encoding: base64 SGVsbG8gU2VyZ2V5LAoKSXQgaXMgbm90IHBvc3NpYmxlIHRvIGhhdmUgdHdvIFNDVFAgYXNzb2Np YXRpb25zIGJldHdlZW4gdHdvClNpZ25hbGxpbmcgcHJvY2Vzc2VzIGJ5IGRlZmluaXRpb24sIHNp bmNlIGFuIGFzc29jaWF0aW9uIGNvbm5lY3RzIHR3bwpTQ1RQIGVuZHBvaW50cyBhbmQgYSBTaWdu YWxsaW5nIFByb2Nlc3MgaXMgY2hhcmFjdGVyaXplZCBieSBpdHMgU0NUUAplbmRwb2ludC4gSWYg eW91IHVzZSBhbm90aGVyIHBvcnQgbnVtYmVyLCBvciB1c2UgZHluYW1pYyBwb3J0IG51bWJlcnMK eW91IGdldCBhbm90aGVyIFNpZ25hbGxpbmcgUHJvY2Vzcy4KCkl0IGlzIHBvc3NpYmxlIHRoYXQg eW91IGhhdmUgdGhlIHNhbWUgU2lnbmFsbGluZyBQcm9jZXNzIHVzaW5nCmRpZmZlcmVudCBTQ1RQ IGVuZHBvaW50cyBkdXJpbmcgbm9uLW92ZXJsYXBwaW5nIHRpbWUgcGVyaW9kcywgdGhlbiB0aGUK U2lnbmFsbGluZyBQcm9jZXNzIHNoYWxsIGlkZW50aWZ5IGl0c2VsZiB2aWEgQVNQX0lELgoKVG9s Z2EgcG9pbnRlZCBpdCByaWdodCwgb25lIGNvbnNlcXVlbmNlIGlzIHRoYXQgc3RhdGUgbWFjaGlu ZXMgd2lsbCBub3Qgd29yay4KCvDPy8EsINDPy8EKCklsaWUKCk9uIDEvMTAvMDYsIFNlcmdleSBN aWtoYWlsb3YgPHNtaWtoYWlsb3ZAbGlua2JpdC5jb20+IHdyb3RlOgo+IEhpLAo+Cj4gSXQgc2Vl bXMgdGhhdCBtdWx0aXBsZSBTQ1RQIGFzc29jaWF0aW9ucyBlc3RhYmxpc2hlZCBiZXR3ZWVuIHRo ZSBzYW1lIHR3bwo+IHNpZ25hbGluZyBwcm9jZXNzZXMgYXJlIG5vdCBbZXhwbGljaXRseV0gcHJv aGliaXRlZC4KPgo+IDEuCj4gSXMgaXQgbGVnYWwgZm9yIGEgc2lnbmFsaW5nIHByb2Nlc3MgdG8g ZXN0YWJsaXNoIG1vcmUgdGhhbiBvbmUgU0NUUAo+IGFzc29jaWF0aW9uIHRvIHRoZSBzYW1lIEFT L1NHIHdoZXJlIHRoZXNlIG11bHRpcGxlIGFzc29jaWF0aW9ucyBhcmUgc2VydmVkCj4gYnkgZGlm ZmVyZW50IHNpZ25hbGluZyBwcm9jZXNzZXM/Cj4KPiAyLgo+IElzIGl0IGxlZ2FsIGZvciBhIHNp Z25hbGluZyBwcm9jZXNzIHRvIGVzdGFibGlzaCBtb3JlIHRoYW4gb25lIFNDVFAKPiBhc3NvY2lh dGlvbiB0byB0aGUgc2FtZSBzaWduYWxpbmcgcHJvY2VzcyBhdCB0aGUgcmVtb3RlIHNpZGU/Cj4K PiAoSSBmZWVsIHRoYXQgdGhlIDJuZCBjYXNlIG1heSBiZSByZWFzb25hYmxlIG9ubHkgd2hlbiB0 aGUgcmVtb3RlIHNpZGUgZG9lcwo+IG5vdCBzdXBwb3J0IG11bHRpLWhvbWVkIFNDVFAgZW5kcG9p bnRzLikKPgo+Cj4gUmVnYXJkcywKPiBTZXJnZXkgTWlraGFpbG92Lgo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gU2lndHJhbiBtYWlsaW5nIGxpc3QK PiBTaWd0cmFuQGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lndHJhbgo+Cj4KPgoKCi0tCklsaWUK --===============0585031558== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0585031558==-- From sigtran-bounces@ietf.org Tue Jan 10 13:29:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOFW-0003E3-3p; Tue, 10 Jan 2006 13:29:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOFU-0003Du-Da for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 13:29:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27417 for ; Tue, 10 Jan 2006 13:28:16 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwOMD-0003UR-Ug for sigtran@ietf.org; Tue, 10 Jan 2006 13:36:35 -0500 Received: by nproxy.gmail.com with SMTP id l23so221279nfc for ; Tue, 10 Jan 2006 10:29:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=R1OXfHOidSbykLsNncXY0QIujGjFwxrbtl4JsC/T3/Y5pxKI/RK1GwFX3Ea+x1taXmGM7EgJLqNZhUr1I0f+AdlpQWGos/Ru79+vUH/JEQfvqFxwTUZwMhlY6TNXdWmB0GlGKzom4E1ito4/BuCPxl9b9qFF9VZD/d5zH1oP4G8= Received: by 10.49.42.7 with SMTP id u7mr1017052nfj; Tue, 10 Jan 2006 10:29:32 -0800 (PST) Received: by 10.48.1.13 with HTTP; Tue, 10 Jan 2006 10:29:32 -0800 (PST) Message-ID: <17b146d60601101029s477a3f40ub1ac15f0fc949f37@mail.gmail.com> Date: Tue, 10 Jan 2006 19:29:32 +0100 From: Ilie Glib To: SIGTRAN MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Subject: [Sigtran] Multiple SUA SGs, sending for SSP from SGs X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Folks, Let's consider two SUA SGs which provide connectivity to an SSN in IP netwo= rk. SUA RFC (section 5.1.2.3.) suggests sending an SSP from an SG when the AS serving the SSN goes inactive in the SG and I also assume in case the SG loses connectivity to the AS. 5.1.2.3. Unsuccessful ASP Fail-over scenario ASP-a1 ASP-a2 SG SEP (Primary) (Backup) +-------------ASP Inactive-------------> <-----------ASP Inactive ACK-----------+ <--------------------NTFY (AS Pending)-+ <--NTFY (AS Pending)-+ After some time elapses (i.e., timeout). +--------SSP--------> <--------SST--------+ <-------------------NTFY (AS Inactive)-+ <-NTFY (AS Inactive)-+ What shall be done in multiple SGs scenario when the SSN is allowed via another SG? Is this a realistic example? Thank you in advance -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 13:41:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOQg-00086g-Om; Tue, 10 Jan 2006 13:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOQe-00084j-Vz for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 13:41:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28495 for ; Tue, 10 Jan 2006 13:39:44 -0500 (EST) Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwOXK-0003t6-Ka for sigtran@ietf.org; Tue, 10 Jan 2006 13:48:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jan 2006 13:40:48 -0500 Message-ID: <0901D1988E815341A0103206A834DA07A5BFB4@mdmxm02.ciena.com> Thread-Topic: start of work on an M2PA IG Thread-Index: AcYWFV/c11FaGiEHRO+ZrnmOTv8bfA== From: "Ong, Lyndon" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Sigtran] start of work on an M2PA IG X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0653078261==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0653078261== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61615.60347ED8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61615.60347ED8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 Jeff Craig has kindly volunteered to start up an M2PA IG with results of implementation=20 and testing of the M2PA. Tom George was the main editor, but due to a change in work will not be able to lead work in this area. =20 If you are interested in participating in this work, please send an email to Jeff at jeffrey.craig@tekelec.com. =20 Cheers, =20 L. Ong ------_=_NextPart_001_01C61615.60347ED8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Folks,
 
Jeff = Craig has=20 kindly volunteered to start up an M2PA IG with results of implementation =
and = testing of the=20 M2PA.  Tom George was the main editor, but due to a change=20 in
work = will not be=20 able to lead work in this area.
 
If you = are=20 interested in participating in this work, please send an email to Jeff=20 at
jeffrey.craig@tekelec.com.<= /SPAN>
 
Cheers,
 
L.=20 Ong
------_=_NextPart_001_01C61615.60347ED8-- --===============0653078261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0653078261==-- From sigtran-bounces@ietf.org Tue Jan 10 13:47:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOXG-0001jP-12; Tue, 10 Jan 2006 13:47:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOXE-0001jG-Fa for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 13:47:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29106 for ; Tue, 10 Jan 2006 13:46:36 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwOdv-00048f-V9 for sigtran@ietf.org; Tue, 10 Jan 2006 13:54:55 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 5A17BF497E for ; Tue, 10 Jan 2006 13:47:39 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0AIlZfc026257 for ; Tue, 10 Jan 2006 13:47:39 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Date: Tue, 10 Jan 2006 13:28:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <17b146d60601101029s477a3f40ub1ac15f0fc949f37@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, Multiple SG scenarios are overall a bit problematic -or better said require some care and attention-. This is due to the fact that the SCCP layer for AS is hosted on SG and if you have multiple SGs, you will have multiple copies of the same SCCP instance which do not know about each others state -if they knew, they would be part of the same SG-. OTOH, for most practical cases, one prbably can survive. If we consider your example, I would expect ASP to send ASPIA to both SGs, causing each ot them to send SSP -probably only of them would receive SST though-. Maybe slightly more interesting scenario is, what happens if ASP looses connectivity to only one SG? This would cause the subsystem to be available in one SG and unavailable on the other one, not something we want to have. OTOH, we should remember multihoming feature of SCTP and what it practically means to us: SCTP multihoming provides network/NIC redundancy, i.e. loss of association is an indication for host failure. So, in the scenario I described if it is ASP which is down, both SGs will detect loss of association. If it is one SG which is down, it won't be able to send SSP. In any case, one should be careful with multi-SG scenarios. Thanks, Tolga > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Ilie Glib > Sent: Tuesday, January 10, 2006 1:30 PM > To: SIGTRAN > Subject: [Sigtran] Multiple SUA SGs, sending for SSP from SGs > > > Hello Folks, > > Let's consider two SUA SGs which provide connectivity to an SSN > in IP network. > SUA RFC (section 5.1.2.3.) suggests sending an SSP from an SG when the > AS serving the SSN goes inactive in the SG and I also assume in case > the SG loses connectivity to the AS. > > 5.1.2.3. Unsuccessful ASP Fail-over scenario > > ASP-a1 ASP-a2 SG SEP > (Primary) (Backup) > +-------------ASP Inactive-------------> > <-----------ASP Inactive ACK-----------+ > <--------------------NTFY (AS Pending)-+ > <--NTFY (AS Pending)-+ > After some time elapses (i.e., timeout). > +--------SSP--------> > <--------SST--------+ > <-------------------NTFY (AS Inactive)-+ > <-NTFY (AS Inactive)-+ > > > > What shall be done in multiple SGs scenario when the SSN is allowed > via another SG? > > Is this a realistic example? > > Thank you in advance > > -- > Ilie > > _______________________________________________ > 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 From sigtran-bounces@ietf.org Tue Jan 10 14:46:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwPS2-0000xF-0V; Tue, 10 Jan 2006 14:46:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwPS0-0000wK-HO for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 14:46:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02991 for ; Tue, 10 Jan 2006 14:45:16 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[nfTekZ9XBOlGGaOogE6k9Tx+Fh1u5ssJ]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwPYk-0005nJ-Hi for sigtran@ietf.org; Tue, 10 Jan 2006 14:53:36 -0500 Received: from ns.pigworks.openss7.net (IDENT:S6zBvFO1I1ao1c6FEcuI/A9OKzv2SYcJ@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0AJkPw24387; Tue, 10 Jan 2006 12:46:25 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0AJkPj32598; Tue, 10 Jan 2006 12:46:25 -0700 Date: Tue, 10 Jan 2006 12:46:25 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] Upper boundary of Adaptation Layers Message-ID: <20060110124625.A31878@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601090707l6bb0a035k57483360dfdf14c2@mail.gmail.com> <20060109081933.A10655@openss7.org> <17b146d60601090821v6956a220w3380c9affb8c4011@mail.gmail.com> <20060109115841.B12775@openss7.org> <17b146d60601100300w6ec282f7o8ede4090edd165dc@mail.gmail.com> <20060110070842.B29048@openss7.org> <17b146d60601100649p6f3cf8a5l1d897534e97fabbb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601100649p6f3cf8a5l1d897534e97fabbb@mail.gmail.com>; from ilie.glib@googlemail.com on Tue, Jan 10, 2006 at 03:49:31PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, Ilie Glib wrote: (Tue, 10 Jan 2006 15:49:31) > Brian, > > I am happy about your statements > > > > [Ilie] Therefore an implementation of SUA Layer in may not have any > > > other primitives than SCCP/SCCP-User primitives. Is this correct? > > > > > > > Read on: > > > > > >It does not say that nothing else is supported or > > > > supportable. It does not say that no other primitives shall be used. > > > > It is just the list of intentionally supported primitives. > > > > I don't know what you mean by "rely on." > > [Ilie] My understanding is that SCCP-users are standardized as > application layers using services provided by SCCP in its primitives > to the SCCP-Users. Thus applications rely (read use) SCCP upper > boundary as of Q.711. > > >All SS7 stacks are vendor > > specific. The only thing an application can rely upon is the interface > > provided by the vendor. > > > [Ilie] I believe it is not very difficult for SCCP User applications > to change from SCCP layer of one vendor to another (or from SCCP use > to SUA), they anyway follow the primitives of Q.711. It was our objective when formulating the specifications to permit an implementation that follows the primitives of Q.711 and the interface described in the SDLs of Q.714 (or similar specifications, such as ANSI T1.112) to be able to use SUA in a manner transparent to that of SCCP. Thus, as Barry noted, permitting an implementation of MTP2, MTP3 or SCCP to present the same interface to the MTP, MTP User, and SCCP User from M2UA, M3UA and SUA as is presented by a specific implementation of MTP2, MTP3 and SCCP. It was considered important to ease implementation of M2UA, M3UA and SUA within an existing SS7 protocol stack implementation, as well as a conceptual test of adequacy of the protocol. However, note that the approach is only applicable to the pure backhaul case (exporting the SS7/SS7-User interface from SG to ASP). For the IPSP and multiple SG as STP scenarios things are somewhat different at the IPSP and SG. For multiple SGs as STP, a richer interface is required at the SG (between the SS7 stack and the NIF) to support the scenario, and the protocol between the SG and ASPs more closely resembles an SG-SG interface. For IPSP the protocol is again different. SGs as STP requires a higher level of understanding of the specific SS7 network, but is largely a local matter at the SG and how the SG iteracts with the SS7 network, which is, to some degree, outside the scope of the specifications. The statements in the specs about NIF and SG interactions with the SS7 network are, therefore, largely illustrative. See, for example, section 4.7.4 in SUA. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 14:47:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwPSp-0001B7-KZ; Tue, 10 Jan 2006 14:47:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwPSo-0001B2-HD for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 14:47:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03099 for ; Tue, 10 Jan 2006 14:46:06 -0500 (EST) Received: from web35413.mail.mud.yahoo.com ([66.163.179.122]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwPZU-0005pp-GT for sigtran@ietf.org; Tue, 10 Jan 2006 14:54:26 -0500 Received: (qmail 34521 invoked by uid 60001); 10 Jan 2006 19:47:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=n0M7KkN40bw7nok6Ko1OB95rys8NldY5F4HFDZCEZqdFiBrqkhO5fRqiK43+2F3HsbgOLzeTGc2aqZOv+KoGqTqKRLSu6EE0BI5b2dAKoZ7VjY9ZyQTBXUqrP4P8pjd4ZsuYz1M40PcwA5kVE7Pn1436wJcJePUH/zkxZ0CHp60= ; Message-ID: <20060110194707.34519.qmail@web35413.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35413.mail.mud.yahoo.com via HTTP; Tue, 10 Jan 2006 11:47:07 PST Date: Tue, 10 Jan 2006 11:47:07 -0800 (PST) From: Stanislav Ivanovich Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs To: SIGTRAN In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1598773797==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1598773797== Content-Type: multipart/alternative; boundary="0-2129005773-1136922427=:32429" Content-Transfer-Encoding: 8bit --0-2129005773-1136922427=:32429 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, I agree with Tolga! I would even say -> why would one after all have several SGW'es for the same application??? What is it for? If one wants reliability of transmission resources (SGW'es) then one installs several SGP'es in the same SGW and provides one logical access point for each application to SS7 network. What would be the benefit of multiple SGW per application after all??? Does anyone know that? regards/ Stanislav Tolga Asveren wrote: Ilie, Multiple SG scenarios are overall a bit problematic -or better said require some care and attention-. This is due to the fact that the SCCP layer for AS is hosted on SG and if you have multiple SGs, you will have multiple copies of the same SCCP instance which do not know about each others state -if they knew, they would be part of the same SG-. OTOH, for most practical cases, one prbably can survive. If we consider your example, I would expect ASP to send ASPIA to both SGs, causing each ot them to send SSP -probably only of them would receive SST though-. Maybe slightly more interesting scenario is, what happens if ASP looses connectivity to only one SG? This would cause the subsystem to be available in one SG and unavailable on the other one, not something we want to have. OTOH, we should remember multihoming feature of SCTP and what it practically means to us: SCTP multihoming provides network/NIC redundancy, i.e. loss of association is an indication for host failure. So, in the scenario I described if it is ASP which is down, both SGs will detect loss of association. If it is one SG which is down, it won't be able to send SSP. In any case, one should be careful with multi-SG scenarios. Thanks, Tolga > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Ilie Glib > Sent: Tuesday, January 10, 2006 1:30 PM > To: SIGTRAN > Subject: [Sigtran] Multiple SUA SGs, sending for SSP from SGs > > > Hello Folks, > > Let's consider two SUA SGs which provide connectivity to an SSN > in IP network. > SUA RFC (section 5.1.2.3.) suggests sending an SSP from an SG when the > AS serving the SSN goes inactive in the SG and I also assume in case > the SG loses connectivity to the AS. > > 5.1.2.3. Unsuccessful ASP Fail-over scenario > > ASP-a1 ASP-a2 SG SEP > (Primary) (Backup) > +-------------ASP Inactive-------------> > <-----------ASP Inactive ACK-----------+ > <--------------------NTFY (AS Pending)-+ > <--NTFY (AS Pending)-+ > After some time elapses (i.e., timeout). > +--------SSP--------> > <--------SST--------+ > <-------------------NTFY (AS Inactive)-+ > <-NTFY (AS Inactive)-+ > > > > What shall be done in multiple SGs scenario when the SSN is allowed > via another SG? > > Is this a realistic example? > > Thank you in advance > > -- > Ilie > > _______________________________________________ > 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 --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-2129005773-1136922427=:32429 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi all,
 
I agree with Tolga!
 
I would even say -> why would one after all have several SGW'es for the same application??? What is it for?
 
If one wants reliability of transmission resources (SGW'es) then one installs several SGP'es in the same SGW and provides one logical access point for each application to SS7 network.
 
 
What would be the benefit of multiple SGW per application after all??? Does anyone know that?
 
regards/ Stanislav
 


Tolga Asveren <asveren@ulticom.com> wrote:
Ilie,

Multiple SG scenarios are overall a bit problematic -or better said require
some care and attention-. This is due to the fact that the SCCP layer for AS
is hosted on SG and if you have multiple SGs, you will have multiple copies
of the same SCCP instance which do not know about each others state -if they
knew, they would be part of the same SG-.

OTOH, for most practical cases, one prbably can survive. If we consider your
example, I would expect ASP to send ASPIA to both SGs, causing each ot them
to send SSP -probably only of them would receive SST though-.

Maybe slightly more interesting scenario is, what happens if ASP looses
connectivity to only one SG? This would cause the subsystem to be available
in one SG and unavailable on the other one, not something we want to have.
OTOH, we should remember multihoming feature of SCTP and what it practically
means to us: SCTP multihoming provides network/NIC redundancy, i.e. loss of
association is an indication for host failure. So, in the scenario I
described if it is ASP which is down, both SGs will detect loss of
association. ! If it is one SG which is down, it won't be able to send SSP.

In any case, one should be careful with multi-SG scenarios.

Thanks,
Tolga


> -----Original Message-----
> From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On
> Behalf Of Ilie Glib
> Sent: Tuesday, January 10, 2006 1:30 PM
> To: SIGTRAN
> Subject: [Sigtran] Multiple SUA SGs, sending for SSP from SGs
>
>
> Hello Folks,
>
> Let's consider two SUA SGs which provide connectivity to an SSN
> in IP network.
> SUA RFC (section 5.1.2.3.) suggests sending an SSP from an SG when the
> AS serving the SSN goes inactive in the SG and I also assume in case
> the SG loses connectivity to the AS.
>
> 5.1.2.3. Unsuccessful ASP Fail-over scenario
>
> ASP-a1 ASP-a2 SG SEP
> (Primary) (Backup)
> +-------------ASP Inactive------------->
> <-----------ASP Inactive ACK-----------+
> <--------------------NTFY (AS Pending)-+
> <--NTFY (AS Pending)-+
> After some time elapses (i.e., timeout).
> +--------SSP-------->
> <--------SST--------+
> <-------------------NTFY (AS Inactive)-+
> <-NTFY (AS Inactive)-+
>
>
>
> What shall be done in multiple SGs scenario when the SSN is allowed
> via another SG?
>
> Is this a realistic example?
>
> Thank you in advance
>
> --
> Ilie
>
> _______________________________________________
> 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

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-2129005773-1136922427=:32429-- --===============1598773797== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1598773797==-- From sigtran-bounces@ietf.org Tue Jan 10 15:05:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwPkI-0006Fc-HD; Tue, 10 Jan 2006 15:05:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwPkG-0006Eh-PN for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 15:05:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04264 for ; Tue, 10 Jan 2006 15:04:08 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwPr0-0006Ll-Qx for sigtran@ietf.org; Tue, 10 Jan 2006 15:12:28 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 35A561947C for ; Tue, 10 Jan 2006 15:05:08 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0AK57Qd002711 for ; Tue, 10 Jan 2006 15:05:08 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Date: Tue, 10 Jan 2006 14:45:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060110194707.34519.qmail@web35413.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Tuesday, January 10, 2006 2:47 PM To: SIGTRAN Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Hi all, I agree with Tolga! I would even say -> why would one after all have several SGW'es for the same application??? What is it for? If one wants reliability of transmission resources (SGW'es) then one installs several SGP'es in the same SGW and provides one logical access point for each application to SS7 network. What would be the benefit of multiple SGW per application after all??? Does anyone know that? [TOLGA]I think, this may makes sense to provide geographical redundancy for SG services. It may be not very efficient to have a geographically distributed SG consisting of multiple SGPs, e.g. where SGPs are in different cities, if one considers that they have to provide a uniqie view of SCCP/MTP3 layer they are hosting. OTOH, I believe using SG-SG kind of approach is a better alternative rather than ASP/SGP multi-SG mechanism, because with SG-SG, there is no remote hosting of SCCP/MTP3 layers, thus no problem of multiple copies of the same SCCP/MTP3 instance, which are not synchronized. regards/ Stanislav Tolga Asveren wrote: Ilie, Multiple SG scenarios are overall a bit problematic -or better said require some care and attention-. This is due to the fact that the SCCP layer for AS is hosted on SG and if you have multiple SGs, you will have multiple copies of the same SCCP instance which do not know about each others state -if they knew, they would be part of the same SG-. OTOH, for most practical cases, one prbably can survive. If we consider your example, I would expect ASP to send ASPIA to both SGs, causing each ot them to send SSP -probably only of them would receive SST though-. Maybe slightly more interesting scenario is, what happens if ASP looses connectivity to only one SG? This would cause the subsystem to be available in one SG and unavailable on the other one, not something we want to have. OTOH, we should remember multihoming feature of SCTP and what it practically means to us: SCTP multihoming provides network/NIC redundancy, i.e. loss of association is an indication for host failure. So, in the scenario I described if it is ASP which is down, both SGs will detect loss of association. ! If it is one SG which is down, it won't be able to send SSP. In any case, one should be careful with multi-SG scenarios. Thanks, Tolga > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Ilie Glib > Sent: Tuesday, January 10, 2006 1:30 PM > To: SIGTRAN > Subject: [Sigtran] Multiple SUA SGs, sending for SSP from SGs > > > Hello Folks, > > Let's consider two SUA SGs which provide connectivity to an SSN > in IP network. > SUA RFC (section 5.1.2.3.) suggests sending an SSP from an SG when the > AS serving the SSN goes inactive in the SG and I also assume in case > the SG loses connectivity to the AS. > > 5.1.2.3. Unsuccessful ASP Fail-over scenario > > ASP-a1 ASP-a2 SG SEP > (Primary) (Backup) > +-------------ASP Inactive-------------> > <-----------ASP Inactive ACK-----------+ > <--------------------NTFY (AS Pending)-+ > <--NTFY (AS Pending)-+ > After some time elapses (i.e., timeout). > +--------SSP--------> > <--------SST--------+ > <-------------------NTFY (AS Inactive)-+ > <-NTFY (AS Inactive)-+ > > > > What shall be done in multiple SGs scenario when the SSN is allowed > via another SG? > > Is this a realistic example? > > Thank you in advance > > -- > Ilie > > _______________________________________________ > 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 Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 15:21:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQ0C-0001N4-Qq; Tue, 10 Jan 2006 15:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQ0B-0001Mz-Cm for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 15:21:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05332 for ; Tue, 10 Jan 2006 15:20:34 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[TaGR7a5SFTL4pFmVmeVCu85EJdYnMYUN]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQ6w-0006lI-Tn for sigtran@ietf.org; Tue, 10 Jan 2006 15:28:55 -0500 Received: from ns.pigworks.openss7.net (IDENT:3SBMU5J6r8SaDFkb0L5ElKGonFUuP/aG@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0AKLrw25138; Tue, 10 Jan 2006 13:21:53 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0AKLrX00608; Tue, 10 Jan 2006 13:21:53 -0700 Date: Tue, 10 Jan 2006 13:21:52 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Message-ID: <20060110132152.B31878@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601101029s477a3f40ub1ac15f0fc949f37@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601101029s477a3f40ub1ac15f0fc949f37@mail.gmail.com>; from ilie.glib@googlemail.com on Tue, Jan 10, 2006 at 07:29:32PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, I think Tolga's remarks are more applicable to M3UA than SUA. MTP does not provide messaging for user management. This is partly the responsibiliy of the MTP User itself. So, for example, when ISUP receives MTP-STATUS indicating user part unavailabilty (corresponding to UPU), ISUP can send UPT to test for return to service of the user part, but UPT is an ISUP message, not an MTP message. With RK granularity of a Network Appearance, the ASP needs to send DUNA, DAVA, DRST, SCON (corresponding to TFP, TFA, TFR, TFC) and the SG needs to work those messages and AS availability into a management view of the network appearance, point code and user part. With RK granularity of a point code, multiple SGs as STP can treat the AS as though it were any (A-link) attached SEP. That is, when the AS is inactive at the SG, it can send TFP for the AS point code, but this does not stop traffic from being routed via the alternate SG (associated STP in the STP pair). When RK granularity is that of an SI value, it is still possible for an SG as STP supporting the ANSI "Alias" point code concept (see ATIS T1.111/2000) to suppress issuing UPU and, instead, route traffic to the associated STP in the STP pair. SUA, OTOH, supports management of SCCP Users. In the case of SUA, for RK at Network Appearance granularity, the ASP needs to send DUNA, DAVA, DRST, SCON (corresponding to TFP, TFA, TFR, TFC, and SSP, SSA, SOR/SOG, SSC) and the SG needs to work those messages and AS availability into a management view of the network appearance, point code and subsystem. When RK granulariy is that of a point code, the ASP needs to send DUNA, DAVA, DRST, SCON (corresponding to SSP, SSA, SOR/SOG, SSC) for affected subsystems and the SG needs to work those messages and AS availability into a management view of the point code and subsystems. When RK granularity is that of a subsystem, the ASP uses AS activation only for subsystem management and the SG needs to work AS availability into a management view of the subsystem. For RK granulariy beneath a subsystem (e.g, global title or global title range), the ASP uses AS activation only for management and the SG needs to use AS avialability to coordinate a management view of the state of the subsystem. As regards when an SG as STP sends SSP or SSA, this is peformed in accordance with SS7 standards (for both local and remote broadcast and responsive methods), given the management view of the subsystem at the STP as formulated above. Contrary to Tolga's statements, for SUA, and in general, an SG (as STP and SCCP relay), will not send SSP when the subsystem is available via the associated STP. Furthermore, if the subsystem is replicated, unavailability of one entity in an entity set does not cause the subsystem to be prohibited if the another entity in the entity set is available. But, for both M3UA and SUA, this is largely a matter of MTP transfer and SCCP relay management and provisioning at the STPs and is outside of the scope of M3UA and SUA. When formulating the specifications, we took some care to ensure that sufficient messaging existed within the M3UA and SUA protocols to support the multiple SG as STP scenarios. For M3UA, the message is largely complete (there are cases where it would be good to send DUPU from the ASP, and load sharing is quite broken, requiring an approach similar to that described in draft-bidulock-sigtran-loadsel to fix it). For SUA, OTOH, the multiple SG as STP scenario is largely broken for connection-oriented protocol classes (the STP is unnaturally and untransparently forced to couple connection sections) and DRN/TID labelling is inadequate for the scenario. I proposed some years ago a registration mechanism that would fully support the multiple SG as STP scenario and it was included in the SUA drafts, but later removed in favor of the broken DRN/TID labeling mechanism. You will find many references to this defect on the mail archives. --brian Ilie Glib wrote: (Tue, 10 Jan 2006 19:29:32) > Hello Folks, > > Let's consider two SUA SGs which provide connectivity to an SSN in IP network. > SUA RFC (section 5.1.2.3.) suggests sending an SSP from an SG when the > AS serving the SSN goes inactive in the SG and I also assume in case > the SG loses connectivity to the AS. > > 5.1.2.3. Unsuccessful ASP Fail-over scenario > > ASP-a1 ASP-a2 SG SEP > (Primary) (Backup) > +-------------ASP Inactive-------------> > <-----------ASP Inactive ACK-----------+ > <--------------------NTFY (AS Pending)-+ > <--NTFY (AS Pending)-+ > After some time elapses (i.e., timeout). > +--------SSP--------> > <--------SST--------+ > <-------------------NTFY (AS Inactive)-+ > <-NTFY (AS Inactive)-+ > > > > What shall be done in multiple SGs scenario when the SSN is allowed > via another SG? > > Is this a realistic example? > > 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 From sigtran-bounces@ietf.org Tue Jan 10 15:32:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQAM-0004WA-9G; Tue, 10 Jan 2006 15:32:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQAK-0004W5-GF for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 15:32:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05913 for ; Tue, 10 Jan 2006 15:31:03 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[YxOpDS+W4TOlo9LQ3Fuv+W9oiS4Q1iAH]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQH5-00070i-6S for sigtran@ietf.org; Tue, 10 Jan 2006 15:39:24 -0500 Received: from ns.pigworks.openss7.net (IDENT:IHDzWKBZiACF7xkIwdpxg3M2LSpwthrf@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0AKWJw25330; Tue, 10 Jan 2006 13:32:19 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0AKWHb00816; Tue, 10 Jan 2006 13:32:17 -0700 Date: Tue, 10 Jan 2006 13:32:16 -0700 From: "Brian F. G. Bidulock" To: "Ong, Lyndon" Subject: Re: [Sigtran] start of work on an M2PA IG Message-ID: <20060110133216.C31878@openss7.org> Mail-Followup-To: "Ong, Lyndon" , sigtran@ietf.org References: <0901D1988E815341A0103206A834DA07A5BFB4@mdmxm02.ciena.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0901D1988E815341A0103206A834DA07A5BFB4@mdmxm02.ciena.com>; from Lyong@Ciena.com on Tue, Jan 10, 2006 at 01:40:48PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Lyndon, Good. Perhaps a good start would be to add a section providing some clarifying remarks on PO mechanism (SN syncrhonization and when data is sent) as it was brought up on the list several times and only a slight modification made to the text of the RFC before it was published. I would like to see comments on draft-bidulock-sigtran-m2pa-test-06 so that the document can be finalized and published as an INFORMATIONAL RFC. Comments? --brian Lyndon Ong wrote: (Tue, 10 Jan 2006 13:40:48) > > Hi Folks, > > > > Jeff Craig has kindly volunteered to start up an M2PA IG with results > of implementation > > and testing of the M2PA. Tom George was the main editor, but due to a > change in > > work will not be able to lead work in this area. > > > > If you are interested in participating in this work, please send an > email to Jeff at > > [1]jeffrey.craig@tekelec.com. > > > > Cheers, > > > > L. Ong > > References > > 1. mailto:jeffrey.craig@tekelec.com > _______________________________________________ > 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 From sigtran-bounces@ietf.org Tue Jan 10 15:38:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQGE-0005hG-0C; Tue, 10 Jan 2006 15:38:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQGC-0005h7-KK for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 15:38:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06324 for ; Tue, 10 Jan 2006 15:37:07 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[3PLOalU30rC4eCNgMMMK95Hgg8i3kYQH]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQMx-0007BQ-Bv for sigtran@ietf.org; Tue, 10 Jan 2006 15:45:28 -0500 Received: from ns.pigworks.openss7.net (IDENT:KHc0G2MTWl/nPFEPURt1ClYwQXgHbNvI@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0AKcPw25390; Tue, 10 Jan 2006 13:38:25 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0AKcPb00859; Tue, 10 Jan 2006 13:38:25 -0700 Date: Tue, 10 Jan 2006 13:38:25 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Message-ID: <20060110133825.D31878@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060110194707.34519.qmail@web35413.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060110194707.34519.qmail@web35413.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Tue, Jan 10, 2006 at 11:47:07AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Stanislav Ivanovich wrote: (Tue, 10 Jan 2006 11:47:07) > > Hi all, > > > > I agree with Tolga! > > > > I would even say -> why would one after all have several SGW'es for > the same application??? What is it for? > > > > If one wants reliability of transmission resources (SGW'es) then one > installs several SGP'es in the same SGW and provides one logical > access point for each application to SS7 network. > > > > > > What would be the benefit of multiple SGW per application after all??? > Does anyone know that? It is a common practice in the SS7 network: one that we intended the specifications to support. There are two (maybe three) common interconnect arrangements in the SS7 network: F-link, A-link and B/D-link. F-link interconnect is handled by IPSP and SG/ASP backhaul. A-link and B/D-link require multiple SG as STP arrangement. A transit network (not just an access network) would also require an SG-SG arrangement for M3UA (or IPSP with relay). SUA already handles transit networks with SUA relay and does not require an SG-SG protocol. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 16:00:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQbk-0003LR-6o; Tue, 10 Jan 2006 16:00:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQbi-0003Kn-26 for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 16:00:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08324 for ; Tue, 10 Jan 2006 15:59:21 -0500 (EST) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQiS-00089T-Tm for sigtran@ietf.org; Tue, 10 Jan 2006 16:07:42 -0500 Received: from [192.168.1.101] (p508F5B39.dip.t-dialin.net [80.143.91.57]) by ilsa.franken.de (Postfix) with ESMTP id 0F154245D1; Tue, 10 Jan 2006 22:00:35 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20060110133216.C31878@openss7.org> References: <0901D1988E815341A0103206A834DA07A5BFB4@mdmxm02.ciena.com> <20060110133216.C31878@openss7.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <16116f77269b8046020f413d985a3f9e@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Sigtran] start of work on an M2PA IG Date: Tue, 10 Jan 2006 22:00:33 +0100 To: bidulock@openss7.org X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: "Ong, Lyndon" , sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Dear all, see my comment in-line. Best regards Michael On Jan 10, 2006, at 21:32 Uhr, Brian F. G. Bidulock wrote: > Lyndon, > > Good. Perhaps a good start would be to add a section providing some > clarifying remarks on PO mechanism (SN syncrhonization and when data is > sent) as it was brought up on the list several times and only a slight > modification made to the text of the RFC before it was published. > > I would like to see comments on draft-bidulock-sigtran-m2pa-test-06 > so that the document can be finalized and published as an INFORMATIONAL > RFC. Are test suites in the scope of the WG or the IETF? > > Comments? > > --brian > > Lyndon Ong wrote: > (Tue, 10 Jan 2006 13:40:48) >> >> Hi Folks, >> >> >> >> Jeff Craig has kindly volunteered to start up an M2PA IG with >> results >> of implementation >> >> and testing of the M2PA. Tom George was the main editor, but due >> to a >> change in >> >> work will not be able to lead work in this area. >> >> >> >> If you are interested in participating in this work, please >> send an >> email to Jeff at >> >> [1]jeffrey.craig@tekelec.com. >> >> >> >> Cheers, >> >> >> >> L. Ong >> >> References >> >> 1. mailto:jeffrey.craig@tekelec.com > >> _______________________________________________ >> 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 From sigtran-bounces@ietf.org Tue Jan 10 16:58:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwRVw-0006mj-TV; Tue, 10 Jan 2006 16:58:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwRVu-0006mY-W2 for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 16:58:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12355 for ; Tue, 10 Jan 2006 16:57:27 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwRch-0001W8-0i for sigtran@ietf.org; Tue, 10 Jan 2006 17:05:47 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id B52B7458A2 for ; Tue, 10 Jan 2006 16:58:28 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0ALwPZx012110 for ; Tue, 10 Jan 2006 16:58:28 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Date: Tue, 10 Jan 2006 16:39:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060110132152.B31878@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, I tried to look to the issue only from SIGTRAN point of view abot what can be done with mechanisms described in SUA/M3UA. The SCCP mechanisms you describe could be helpful but I am not sure how -just brain exercising here-: *) The situation of an SG is different than an STP, SG hosts the SCCP layer, which becomes unavailable, OTOH, STP doesn't. So, I am not sure whether it would be correct to compare their behavior and expect from SG not to send SSP, despite corresponding AS is no more ACTIVE. *) Do we expect SCCP not to send SSP, if there is a replicated subsystem? Tolga > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Brian F. G. Bidulock > Sent: Tuesday, January 10, 2006 3:22 PM > To: Ilie Glib > Cc: SIGTRAN > Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs > > > Ilie, > > I think Tolga's remarks are more applicable to M3UA than SUA. MTP does > not provide messaging for user management. This is partly the > responsibiliy of the MTP User itself. So, for example, when ISUP > receives MTP-STATUS indicating user part unavailabilty (corresponding to > UPU), ISUP can send UPT to test for return to service of the user part, > but UPT is an ISUP message, not an MTP message. > > With RK granularity of a Network Appearance, the ASP needs to send DUNA, > DAVA, DRST, SCON (corresponding to TFP, TFA, TFR, TFC) and the SG needs > to work those messages and AS availability into a management view of the > network appearance, point code and user part. > > With RK granularity of a point code, multiple SGs as STP can treat the > AS as though it were any (A-link) attached SEP. That is, when the AS is > inactive at the SG, it can send TFP for the AS point code, but this does > not stop traffic from being routed via the alternate SG (associated STP > in the STP pair). > > When RK granularity is that of an SI value, it is still possible for an > SG as STP supporting the ANSI "Alias" point code concept (see ATIS > T1.111/2000) to suppress issuing UPU and, instead, route traffic to the > associated STP in the STP pair. > > SUA, OTOH, supports management of SCCP Users. In the case of SUA, for > RK at Network Appearance granularity, the ASP needs to send DUNA, DAVA, > DRST, SCON (corresponding to TFP, TFA, TFR, TFC, and SSP, SSA, SOR/SOG, > SSC) and the SG needs to work those messages and AS availability into a > management view of the network appearance, point code and subsystem. > > When RK granulariy is that of a point code, the ASP needs to send DUNA, > DAVA, DRST, SCON (corresponding to SSP, SSA, SOR/SOG, SSC) for affected > subsystems and the SG needs to work those messages and AS availability > into a management view of the point code and subsystems. > > When RK granularity is that of a subsystem, the ASP uses AS activation > only for subsystem management and the SG needs to work AS availability > into a management view of the subsystem. > > For RK granulariy beneath a subsystem (e.g, global title or global title > range), the ASP uses AS activation only for management and the SG needs > to use AS avialability to coordinate a management view of the state of > the subsystem. > > As regards when an SG as STP sends SSP or SSA, this is peformed in > accordance with SS7 standards (for both local and remote broadcast and > responsive methods), given the management view of the subsystem at the > STP as formulated above. Contrary to Tolga's statements, for SUA, and > in general, an SG (as STP and SCCP relay), will not send SSP when the > subsystem is available via the associated STP. Furthermore, if the > subsystem is replicated, unavailability of one entity in an entity set > does not cause the subsystem to be prohibited if the another entity in > the entity set is available. > > But, for both M3UA and SUA, this is largely a matter of MTP transfer and > SCCP relay management and provisioning at the STPs and is outside of the > scope of M3UA and SUA. > > When formulating the specifications, we took some care to ensure that > sufficient messaging existed within the M3UA and SUA protocols to > support the multiple SG as STP scenarios. > > For M3UA, the message is largely complete (there are cases where it > would be good to send DUPU from the ASP, and load sharing is quite > broken, requiring an approach similar to that described in > draft-bidulock-sigtran-loadsel to fix it). > > For SUA, OTOH, the multiple SG as STP scenario is largely broken for > connection-oriented protocol classes (the STP is unnaturally and > untransparently forced to couple connection sections) and DRN/TID > labelling is inadequate for the scenario. I proposed some years ago > a registration mechanism that would fully support the multiple SG as > STP scenario and it was included in the SUA drafts, but later removed > in favor of the broken DRN/TID labeling mechanism. You will find many > references to this defect on the mail archives. > > --brian > > > Ilie Glib wrote: > (Tue, 10 Jan 2006 19:29:32) > > Hello Folks, > > > > Let's consider two SUA SGs which provide connectivity to an SSN > in IP network. > > SUA RFC (section 5.1.2.3.) suggests sending an SSP from an SG when the > > AS serving the SSN goes inactive in the SG and I also assume in case > > the SG loses connectivity to the AS. > > > > 5.1.2.3. Unsuccessful ASP Fail-over scenario > > > > ASP-a1 ASP-a2 SG SEP > > (Primary) (Backup) > > +-------------ASP Inactive-------------> > > <-----------ASP Inactive ACK-----------+ > > <--------------------NTFY (AS Pending)-+ > > <--NTFY (AS Pending)-+ > > After some time elapses (i.e., timeout). > > +--------SSP--------> > > <--------SST--------+ > > <-------------------NTFY (AS Inactive)-+ > > <-NTFY (AS Inactive)-+ > > > > > > > > What shall be done in multiple SGs scenario when the SSN is allowed > > via another SG? > > > > Is this a realistic example? > > > > 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 From sigtran-bounces@ietf.org Tue Jan 10 17:03:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwRau-0007oB-V9; Tue, 10 Jan 2006 17:03:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwRat-0007o5-7y for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 17:03:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12633 for ; Tue, 10 Jan 2006 17:02:36 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[x/IAhf4GVZJz2my0rulE1focoY2lMuCw]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwRhe-0001eT-RE for sigtran@ietf.org; Tue, 10 Jan 2006 17:10:56 -0500 Received: from ns.pigworks.openss7.net (IDENT:ERgR/yUpl0s4YALSmWaJ89EW7noKOYRZ@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0AM3lw26961; Tue, 10 Jan 2006 15:03:47 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0AM3j501929; Tue, 10 Jan 2006 15:03:45 -0700 Date: Tue, 10 Jan 2006 15:03:44 -0700 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Sigtran] start of work on an M2PA IG Message-ID: <20060110150344.A1511@openss7.org> Mail-Followup-To: Michael Tuexen , "Ong, Lyndon" , sigtran@ietf.org References: <0901D1988E815341A0103206A834DA07A5BFB4@mdmxm02.ciena.com> <20060110133216.C31878@openss7.org> <16116f77269b8046020f413d985a3f9e@lurchi.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <16116f77269b8046020f413d985a3f9e@lurchi.franken.de>; from Michael.Tuexen@lurchi.franken.de on Tue, Jan 10, 2006 at 10:00:33PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Ong, Lyndon" , sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Michael, Michael Tuexen wrote: (Tue, 10 Jan 2006 22:00:33) > Dear all, > > see my comment in-line. > > Best regards > Michael > > On Jan 10, 2006, at 21:32 Uhr, Brian F. G. Bidulock wrote: > > > Lyndon, > > > > Good. Perhaps a good start would be to add a section providing some > > clarifying remarks on PO mechanism (SN syncrhonization and when data is > > sent) as it was brought up on the list several times and only a slight > > modification made to the text of the RFC before it was published. > > > > I would like to see comments on draft-bidulock-sigtran-m2pa-test-06 > > so that the document can be finalized and published as an INFORMATIONAL > > RFC. > Are test suites in the scope of the WG or the IETF? The IETF has released INFORMATIONAL testing RFCs (even conformance tests) for other protocols and algorithms. Some that might be of interest are: RFC 2202, 2268, 2398, 3158. Perhaps the closest in intent and content is RFC 3158. There many be more recent examples. But more so that a test specification (it is really just a suggestion to implementers and for standards bodies concerned with such things to accept, modify or reject), the test document illustrates some specific behaviours of the protocol not addressed in such detail in the specification, in terms well known to testers of MTP Link implementations. As such, it is in fitting with the purpose of Informational RFCs ("not representing an Internet community consensus or recommendation"). We could probably use some BCPs for the UAs rather than mucking with the protocols with I-Gs ad infinitum. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 17:06:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwRdj-0008VP-BH; Tue, 10 Jan 2006 17:06:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwRdh-0008VK-T0 for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 17:06:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12810 for ; Tue, 10 Jan 2006 17:05:30 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[jL/EPq1uP3Ts9dLGzH/4LgmBOp38gI2T]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwRkT-0001jK-Fx for sigtran@ietf.org; Tue, 10 Jan 2006 17:13:50 -0500 Received: from ns.pigworks.openss7.net (IDENT:TLT76FLmGkunBfLs2fXJFxMTrtrcJ39t@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0AM6kw27008; Tue, 10 Jan 2006 15:06:47 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0AM6kp01992; Tue, 10 Jan 2006 15:06:46 -0700 Date: Tue, 10 Jan 2006 15:06:46 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Message-ID: <20060110150646.B1511@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20060110132152.B31878@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from asveren@ulticom.com on Tue, Jan 10, 2006 at 04:39:03PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Under SUA, even an ASP can have an SCCP relay function, meaning that even an ASP can behave as an STP. You are still thinking from an M3UA perspective. --brian Tolga Asveren wrote: (Tue, 10 Jan 2006 16:39:03) > Brian, > > I tried to look to the issue only from SIGTRAN point of view abot what can > be done with mechanisms described in SUA/M3UA. The SCCP mechanisms you > describe could be helpful but I am not sure how -just brain exercising > here-: > > *) The situation of an SG is different than an STP, SG hosts the SCCP layer, > which becomes unavailable, OTOH, STP doesn't. So, I am not sure whether it > would be correct to compare their behavior and expect from SG not to send > SSP, despite corresponding AS is no more ACTIVE. > > *) Do we expect SCCP not to send SSP, if there is a replicated subsystem? > > > Tolga -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 17:28:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwRyX-00066F-4w; Tue, 10 Jan 2006 17:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwRyV-00063l-K9 for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 17:28:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14591 for ; Tue, 10 Jan 2006 17:27:00 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwS5G-0002Pm-CR for sigtran@ietf.org; Tue, 10 Jan 2006 17:35:20 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id C842F694DB for ; Tue, 10 Jan 2006 17:28:04 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0AMS24R013881 for ; Tue, 10 Jan 2006 17:28:03 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Date: Tue, 10 Jan 2006 17:08:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060110150646.B1511@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ah O.K., I forget for a while the "undocumented" relaying functionality of SUA :-) In any case, personally I don't see how it may be usefull for multiple SG scenario because SCCPs are locally hosted in SGs. Relaying messages is a different story. > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Tuesday, January 10, 2006 5:07 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs > > > Tolga, > > Under SUA, even an ASP can have an SCCP relay function, meaning that even > an ASP can behave as an STP. You are still thinking from an M3UA > perspective. > > --brian > > Tolga Asveren wrote: > (Tue, 10 Jan 2006 16:39:03) > > Brian, > > > > I tried to look to the issue only from SIGTRAN point of view > abot what can > > be done with mechanisms described in SUA/M3UA. The SCCP mechanisms you > > describe could be helpful but I am not sure how -just brain exercising > > here-: > > > > *) The situation of an SG is different than an STP, SG hosts > the SCCP layer, > > which becomes unavailable, OTOH, STP doesn't. So, I am not sure > whether it > > would be correct to compare their behavior and expect from SG > not to send > > SSP, despite corresponding AS is no more ACTIVE. > > > > *) Do we expect SCCP not to send SSP, if there is a replicated > subsystem? > > > > > > Tolga > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 17:47:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSGu-0002p8-9X; Tue, 10 Jan 2006 17:47:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSGs-0002p3-Ne for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 17:47:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15765 for ; Tue, 10 Jan 2006 17:45:59 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[yyhUA3nsG/xmTNBEfrIhmBQn5HZ5ueqi]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwSNe-0002wi-P6 for sigtran@ietf.org; Tue, 10 Jan 2006 17:54:20 -0500 Received: from ns.pigworks.openss7.net (IDENT:ebcV8Jpt17aKBfoZr76cXaKldLcmO94l@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0AMlGw27458; Tue, 10 Jan 2006 15:47:16 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0AMlFC02494; Tue, 10 Jan 2006 15:47:15 -0700 Date: Tue, 10 Jan 2006 15:47:15 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Message-ID: <20060110154715.A2346@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20060110150646.B1511@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from asveren@ulticom.com on Tue, Jan 10, 2006 at 05:08:40PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Tue, 10 Jan 2006 17:08:40) > > Ah O.K., I forget for a while the "undocumented" relaying functionality of > SUA :-) > > In any case, personally I don't see how it may be usefull for multiple SG > scenario because SCCPs are locally hosted in SGs. Relaying messages is a > different story. SCCPs are only locally hosted at an SG in the pure backhaul case. In the multiple SG as STP scenario, and in the SCCP relay scenario, SCCPs can also be hosted at the ASP or IPSP. M3UA is not so different. MTPs can be locally hosted at the ASP in the multiple SG as STP scenario. It was always the intention for M3UA to support this scenario. E.g, section 1.3.2 of RFC 3332: ... However, in the case where an ASP is connected to more than one SG, the M3UA layer at an ASP should maintain the status of configured SS7 destinations and route messages according to the availability and congestion status of the routes to these destinations via each SG. Also see Section 1.4.1 and Figure 1. See also, Figure 5 in the Appendix, Appendix A.2.2. There are additional passages throughout the document. In fact, this is the sole purpose of the DRST message: see section 3.4.6. SUA simply provides the additional mechanism (as does SCCP) of managing the availability of SCCP User across such an arrangement. M3UA provides only partial MTP User availabilty (DUPU) management, as does MTP3 (UPU). These are fundamental capabilities required to meet the objective of providing transparent interworking to the SS7 network. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 17:54:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSOF-0004gx-3r; Tue, 10 Jan 2006 17:54:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSOE-0004gs-8j for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 17:54:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16418 for ; Tue, 10 Jan 2006 17:53:34 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwSV1-0003Ex-Cw for sigtran@ietf.org; Tue, 10 Jan 2006 18:01:55 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 47F1F19478 for ; Tue, 10 Jan 2006 17:54:35 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0AMsYVV015242 for ; Tue, 10 Jan 2006 17:54:35 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Date: Tue, 10 Jan 2006 17:35:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060110154715.A2346@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, You also know as much as I do that SCCP (and MTP3 for M3UA) is hosted on SGs, the interface between SG and ASP mimics SCCP/SCCP-User (MTP3/MTP3-User interface for M3UA) interface. It is true that for multiple SG scenario ASPs have a small portion of MTP3 functionality, but this does not mean that MTP3 is actually not hosted on SG, e.g. it is still SG generating management messages for SCCP/MTP3. Tolga > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Tuesday, January 10, 2006 5:47 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs > > > Tolga, > > Tolga Asveren wrote: (Tue, 10 Jan 2006 > 17:08:40) > > > > Ah O.K., I forget for a while the "undocumented" relaying > functionality of > > SUA :-) > > > > In any case, personally I don't see how it may be usefull for > multiple SG > > scenario because SCCPs are locally hosted in SGs. Relaying messages is a > > different story. > > SCCPs are only locally hosted at an SG in the pure backhaul case. In > the multiple SG as STP scenario, and in the SCCP relay scenario, SCCPs > can also be hosted at the ASP or IPSP. > > M3UA is not so different. MTPs can be locally hosted at the ASP in the > multiple SG as STP scenario. It was always the intention for M3UA to > support this scenario. > > E.g, section 1.3.2 of RFC 3332: > > ... However, in the case where an ASP is connected to more than one > SG, the M3UA layer at an ASP should maintain the status of configured > SS7 destinations and route messages according to the availability and > congestion status of the routes to these destinations via each SG. > > Also see Section 1.4.1 and Figure 1. See also, Figure 5 in the > Appendix, Appendix A.2.2. There are additional passages throughout the > document. > > In fact, this is the sole purpose of the DRST message: see section > 3.4.6. > > SUA simply provides the additional mechanism (as does SCCP) of managing > the availability of SCCP User across such an arrangement. M3UA provides > only partial MTP User availabilty (DUPU) management, as does MTP3 (UPU). > > These are fundamental capabilities required to meet the objective of > providing transparent interworking to the SS7 network. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 19:55:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwUH7-0001z6-1z; Tue, 10 Jan 2006 19:55:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwUH5-0001yd-82 for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 19:55:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26948 for ; Tue, 10 Jan 2006 19:54:18 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[IA+xvhcUS+YSX91QFOVcyvwNoaLiiyMz]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwUNs-0007Yq-4M for sigtran@ietf.org; Tue, 10 Jan 2006 20:02:41 -0500 Received: from ns.pigworks.openss7.net (IDENT:v3Vp4e39LyL8MG4wN6f48KlCVHeLnm9+@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0B0tXw29595; Tue, 10 Jan 2006 17:55:33 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0B0tXr03786; Tue, 10 Jan 2006 17:55:33 -0700 Date: Tue, 10 Jan 2006 17:55:33 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Message-ID: <20060110175533.A3748@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20060110154715.A2346@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from asveren@ulticom.com on Tue, Jan 10, 2006 at 05:35:12PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, I disagree. An instance of MTP is identified by a point code and the point code resides at the ASPs in the multiple SG as STP scenario. The point code is not local to the MTP stack at the SG in the SS7 sense when RK is at PC granularity or above. This is a necessary situation to properly support the multiple SG as STP scenario. --brian Tolga Asveren wrote: (Tue, 10 Jan 2006 17:35:12) > Brian, > > You also know as much as I do that SCCP (and MTP3 for M3UA) is hosted on > SGs, the interface between SG and ASP mimics SCCP/SCCP-User (MTP3/MTP3-User > interface for M3UA) interface. It is true that for multiple SG scenario ASPs > have a small portion of MTP3 functionality, but this does not mean that MTP3 > is actually not hosted on SG, e.g. it is still SG generating management > messages for SCCP/MTP3. > > Tolga > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 10 20:17:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwUc3-0000XE-0T; Tue, 10 Jan 2006 20:17:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwUc2-0000VL-2v for sigtran@megatron.ietf.org; Tue, 10 Jan 2006 20:17:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28239 for ; Tue, 10 Jan 2006 20:15:57 -0500 (EST) Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwUip-000899-BO for sigtran@ietf.org; Tue, 10 Jan 2006 20:24:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] start of work on an M2PA IG Date: Tue, 10 Jan 2006 20:16:53 -0500 Message-ID: <0901D1988E815341A0103206A834DA07A5C00A@mdmxm02.ciena.com> Thread-Topic: [Sigtran] start of work on an M2PA IG Thread-Index: AcYWMcxfFXg0PP8HToOsZFeF6KkCTwAGs9Ig From: "Ong, Lyndon" To: , "Michael Tuexen" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org I will raise the subject with our A-Ds to get further guidance. =20 BTW, on Processor Outage, Jeff did identify this as a major area needing clarification. Cheers, Lyndon=20 -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]=20 Sent: Tuesday, January 10, 2006 2:04 PM To: Michael Tuexen Cc: Ong, Lyndon; sigtran@ietf.org Subject: Re: [Sigtran] start of work on an M2PA IG Michael, Michael Tuexen wrote: (Tue, 10 Jan 2006 22:00:33) > Dear all, >=20 > see my comment in-line. >=20 > Best regards > Michael >=20 > On Jan 10, 2006, at 21:32 Uhr, Brian F. G. Bidulock wrote: >=20 > > Lyndon, > > > > Good. Perhaps a good start would be to add a section providing some > > clarifying remarks on PO mechanism (SN syncrhonization and when data > > is > > sent) as it was brought up on the list several times and only a=20 > > slight modification made to the text of the RFC before it was published. > > > > I would like to see comments on draft-bidulock-sigtran-m2pa-test-06 > > so that the document can be finalized and published as an=20 > > INFORMATIONAL RFC. > Are test suites in the scope of the WG or the IETF? The IETF has released INFORMATIONAL testing RFCs (even conformance tests) for other protocols and algorithms. Some that might be of interest are: RFC 2202, 2268, 2398, 3158. Perhaps the closest in intent and content is RFC 3158. There many be more recent examples. But more so that a test specification (it is really just a suggestion to implementers and for standards bodies concerned with such things to accept, modify or reject), the test document illustrates some specific behaviours of the protocol not addressed in such detail in the specification, in terms well known to testers of MTP Link implementations. As such, it is in fitting with the purpose of Informational RFCs ("not representing an Internet community consensus or recommendation"). We could probably use some BCPs for the UAs rather than mucking with the protocols with I-Gs ad infinitum. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 01:33:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwZY0-0003t4-SL; Wed, 11 Jan 2006 01:33:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwZXx-0003s3-He for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 01:33:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18061 for ; Wed, 11 Jan 2006 01:32:04 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwZei-00007S-6z for sigtran@ietf.org; Wed, 11 Jan 2006 01:40:27 -0500 Received: by zproxy.gmail.com with SMTP id i11so94930nzi for ; Tue, 10 Jan 2006 22:33:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ZOM2gLSMwJGIyp4Qfe5kzjc1tEx97UJemvlck/eqr7hQqpnPs6/zy1ajuvwctpyN9cI/6L8vaM83oeZG97FGdNa8+jvmFI0c7dzEk+R/D1Wi0/vFnbIAA+AUBPOm7MXtT+8fJUnsWv9FAvguEto2jjfi4dgvexfLK067yMJx9XE= Received: by 10.65.141.19 with SMTP id t19mr89388qbn; Tue, 10 Jan 2006 22:33:17 -0800 (PST) Received: by 10.65.112.5 with HTTP; Tue, 10 Jan 2006 22:33:17 -0800 (PST) Message-ID: Date: Wed, 11 Jan 2006 14:33:17 +0800 From: Binggang Liu To: sigtran@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Sigtran] In IUA, one AS to multiple SGs connection X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0212335005==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0212335005== Content-Type: multipart/alternative; boundary="----=_Part_107796_25318197.1136961197942" ------=_Part_107796_25318197.1136961197942 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Folks, My question is: is it allowed that one AS connect to multiple SGs, in IUA? If no, Why? If yes, is there any requirement about ASP? Can the AS use only one ASP to connect to all these SGs or it must employ one ASP for each SG? Thank you! Regards, Binggang Liu ------=_Part_107796_25318197.1136961197942 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi, Folks,
 
My question is: is it allowed that one AS connect to multiple SGs, in = IUA?
 
If no, Why?
 
If yes, is there any requirement about ASP? Can the AS use only o= ne ASP to connect to all these SGs or it must employ one ASP for each = SG?
 
Thank you!
 
Regards,
Binggang Liu
 ------=_Part_107796_25318197.1136961197942-- --===============0212335005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0212335005==-- From sigtran-bounces@ietf.org Wed Jan 11 04:21:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwcAT-0003ZE-Rx; Wed, 11 Jan 2006 04:21:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwcAR-0003W3-Db for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 04:21:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26695 for ; Wed, 11 Jan 2006 04:19:58 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwcHI-0004LI-ET for Sigtran@ietf.org; Wed, 11 Jan 2006 04:28:26 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0B9IcGm099417; Wed, 11 Jan 2006 01:18:41 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <003f01c61690$291f32d0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: , References: Subject: Re: [Sigtran] Multiple SCTP associations Date: Wed, 11 Jan 2006 12:19:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1235/Sun Jan 8 10:13:01 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Ilie, thank you for your valuable replies on the subject! Please let me know, if I misinterpreted your answers. 1. As far as I understand it, an SCTP endpoint, to say it strictly, may have only one SCTP association; and a signaling process may use multiple SCTP endpoints (and hence multiple SCTP associations) for communication with different signaling processes of one AS/SG. 2. Multiple SCTP associations between the same two signaling processes, while not prohibited, will require reinterpretation of SCTP-to-ULP events (to keep communication status and ASP states consistent across multiple SCTP associations), such as NETWORK STATUS CHANGE, COMMUNICATION UP/LOST/ERROR, RESTART and SHUTDOWN COMPLETE events (RFC2960). Regards, Sergey Mikhailov. ----- Original Message ----- From: "Tolga Asveren" To: Sent: Tuesday, January 10, 2006 7:33 PM Subject: RE: [Sigtran] Multiple SCTP associations > Sergey, > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf > Of > Sergey Mikhailov > Sent: Tuesday, January 10, 2006 11:39 AM > To: SIGTRAN > Subject: [Sigtran] Multiple SCTP associations > > > Hi, > > It seems that multiple SCTP associations established between the same two > signaling processes are not [explicitly] prohibited. > > 1. > Is it legal for a signaling process to establish more than one SCTP > association to the same AS/SG where these multiple associations are served > by different signaling processes? > [TOLGA]Yes, this is how host redundancy is achieved (I assume you talk > about > M3UA/SUA). There are multiple ASPs serving an AS, and multiple SGPs in a > SG, > and there is a SCTP association between each SGP/ASP pair -well, obviously > it is not mandatory-. > > 2. > Is it legal for a signaling process to establish more than one SCTP > association to the same signaling process at the remote side? > > (I feel that the 2nd case may be reasonable only when the remote side does > not support multi-homed SCTP endpoints.) > [TOLGA]Multiple SCTP assocaitions between two etities will have problems > with ASP state machine if you follow it strictly considering the state > transitions associated with events from SCTP. This is easy to overcome > with > a some reasonable reinterpretation. OTOH, multiple SCTP associations won't > be a replacement for SCTP multihoming support because SCTP multihoming > provided network/NIC redundancy without loss/missequencing of messages. > > Regards, > Sergey Mikhailov. > > > > _______________________________________________ > 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 From sigtran-bounces@ietf.org Wed Jan 11 04:29:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwcHv-0006By-32; Wed, 11 Jan 2006 04:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwcHt-0006Bt-Ep for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 04:29:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27137 for ; Wed, 11 Jan 2006 04:27:40 -0500 (EST) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwcOk-0004Yj-WD for sigtran@ietf.org; Wed, 11 Jan 2006 04:36:08 -0500 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0B9Sci09169 for ; Wed, 11 Jan 2006 10:28:38 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jan 2006 09:28:37 -0000 Message-ID: <78C698004E263B488351B16611F3379F05A72746@zharhxm1.corp.nortel.com> Thread-Topic: DPNSS (DUA) RFC Updates & Clarifications Thread-Index: AcYWkWaStOhaRoGrQgifgRkMKBrtKQ== From: "Michael Mentz" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [Sigtran] DPNSS (DUA) RFC Updates & Clarifications X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1560393806==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1560393806== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61691.66E78062" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61691.66E78062 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I would like to propose some additional information that I have done on the DUA RFC draft document. We have found a number of areas (specifically in areas of physical maintenance and the handling of DLC failures) that are not covered and can be open to interpretation. We also have clarifications to be made wrt. DASS2 as this has subtle differences with DPNSS that the RFC also needs to be aware of. Obviously, these are the kind of scenarios where an RFC needs good guidance on the correct approach to take. Am I to assume that I can post an updated document to this list for consideration and review? just the diffs? Please advise, Thanks, Mike Mentz ------_=_NextPart_001_01C61691.66E78062 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DPNSS (DUA) RFC Updates & Clarifications

Hi all,

I would like to propose some additional = information that I have done on the DUA RFC draft document.
We have found a number of areas  = (specifically in areas of physical maintenance and the handling of DLC = failures)  that are not covered and can be open to = interpretation.

We also have clarifications to be made = wrt. DASS2 as this has subtle differences with DPNSS that the RFC also = needs to be aware of.

Obviously, these are the kind of = scenarios where an RFC needs good guidance on the correct approach to = take.

Am I to assume that I can post an = updated document to this list for consideration and review? just the = diffs?

Please advise,

Thanks,
Mike Mentz

------_=_NextPart_001_01C61691.66E78062-- --===============1560393806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1560393806==-- From sigtran-bounces@ietf.org Wed Jan 11 05:53:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewdc5-0004xy-A1; Wed, 11 Jan 2006 05:53:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewdc4-0004xm-1G for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 05:53:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01641 for ; Wed, 11 Jan 2006 05:52:36 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewdiu-0006ey-My for Sigtran@ietf.org; Wed, 11 Jan 2006 06:01:03 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0BApmQK099804; Wed, 11 Jan 2006 02:51:51 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <005901c6169d$2ce1cd30$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "Binggang Liu" References: Subject: Re: [Sigtran] In IUA, one AS to multiple SGs connection Date: Wed, 11 Jan 2006 13:52:42 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1237/Tue Jan 10 07:53:20 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1296931314==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1296931314== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01C616B6.4B412FA0" This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C616B6.4B412FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Binggang, Although I didn't find it in IUA specification, I don't think it differs = from M3UA at this point. The RFC3332 (and RFC3332bis05 draft as well) for M3UA states (section = 1.3.2.5): "As shown in Figure 1 an ASP may be connected to multiple SGPs. In such = a case a particular SS7 destination may be reachable via more than one = SGP and/or SG, i.e., via more than one route. As MTP3 users only = maintain status on a destination and not on a route basis, the M3UA = layer must maintain the status (availability, restriction, and/or = congestion of route to destination) of the individual routes, derive the = overall availability or congestion status of the destination from the = status of the individual routes, and inform the MTP3 users of this = derived status whenever it changes." Thus, I think that no restrictions are implied on an AS implementation: = it may use single ASP to connect to all necessary SGs/SGPs as well as = use multiple ASPs for that purpose. =20 Sergey Mikhailov. ----- Original Message -----=20 From: Binggang Liu=20 To: sigtran@ietf.org=20 Sent: Wednesday, January 11, 2006 9:33 AM Subject: [Sigtran] In IUA, one AS to multiple SGs connection Hi, Folks, My question is: is it allowed that one AS connect to multiple SGs, in = IUA? If no, Why? If yes, is there any requirement about ASP? Can the AS use only one = ASP to connect to all these SGs or it must employ one ASP for each SG? Thank you! Regards, Binggang Liu -------------------------------------------------------------------------= ----- _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran ------=_NextPart_000_0056_01C616B6.4B412FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Binggang,
 
Although I didn't find it in IUA = specification, I=20 don't think it differs from M3UA at this point.
 
The RFC3332 (and RFC3332bis05 draft as = well) for=20 M3UA states (section 1.3.2.5):
 
"As shown in Figure 1 an ASP may = be connected=20 to multiple SGPs. In such a case a particular SS7 destination may be = reachable=20 via more than one SGP and/or SG, i.e., via more than one route. As MTP3 = users=20 only maintain status on a destination and not on a route basis, the M3UA = layer=20 must maintain the status (availability, restriction, and/or congestion = of route=20 to destination) of the individual routes, derive the overall = availability or=20 congestion status of the destination from the status of the individual = routes,=20 and inform the MTP3 users of this derived status whenever it=20 changes."
 
Thus, I think that no restrictions are = implied on=20 an AS implementation: it may use single ASP to connect to all necessary = SGs/SGPs=20 as well as use multiple ASPs for that purpose.
 
   
Sergey Mikhailov.
 
 
----- Original Message -----
From:=20 Binggang=20 Liu
Sent: Wednesday, January 11, = 2006 9:33=20 AM
Subject: [Sigtran] In IUA, one = AS to=20 multiple SGs connection

Hi, Folks,
 
My question is: is it allowed that one AS connect to multiple = SGs, in=20 IUA?
 
If no, Why?
 
If yes, is there any requirement about ASP? Can the AS use = only one=20 ASP to connect to all these SGs or it must employ one ASP for = each=20 SG?
 
Thank you!
 
Regards,
Binggang Liu

_______________________________________________
Sigtran = mailing=20 = list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtra= n
------=_NextPart_000_0056_01C616B6.4B412FA0-- --===============1296931314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1296931314==-- From sigtran-bounces@ietf.org Wed Jan 11 06:11:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewdsf-0000nP-Fs; Wed, 11 Jan 2006 06:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewdse-0000n6-FB for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 06:11:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02611 for ; Wed, 11 Jan 2006 06:09:44 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[ebZXzTPvKKuTKXhKbsxI5WTC1rAY21Xi]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwdzW-00074O-4A for Sigtran@ietf.org; Wed, 11 Jan 2006 06:18:11 -0500 Received: from ns.pigworks.openss7.net (IDENT:GdBW/jVceUyE+85+LDMwIMGGvR9RvWwA@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0BBAxw07534; Wed, 11 Jan 2006 04:10:59 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0BBAws09736; Wed, 11 Jan 2006 04:10:58 -0700 Date: Wed, 11 Jan 2006 04:10:58 -0700 From: "Brian F. G. Bidulock" To: Sergey Mikhailov Subject: Re: [Sigtran] Multiple SCTP associations Message-ID: <20060111041058.A9053@openss7.org> Mail-Followup-To: Sergey Mikhailov , asveren@ulticom.com, ilie.glib@googlemail.com, SIGTRAN References: <003f01c61690$291f32d0$150f0f0a@smikhailov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <003f01c61690$291f32d0$150f0f0a@smikhailov>; from smikhailov@linkbit.com on Wed, Jan 11, 2006 at 12:19:29PM +0300 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id k0BBAxw07534 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN , asveren@ulticom.com X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, I am not agreeing with Tolga much lately... It was never our intention to allow more than one SCTP association between a given pair of processes to persist. E.g. RFC 3332 1.3.2.4: ... In order to [sic] avoid redundant SCTP associations between two M3UA peers, one side (client) SHOULD be designated to establish the SCTP association, or M3UA configuration information established to detect redundant associations (e.g., via knowledge of the expected local and remote SCTP endpoint addresses). This passage makes it clear that measures are to be taken to avoid multiple associations. Also, an ASP Identifier is required whenever multiple ASPs exist at the same endpoint. If the provided ASP Identifier is missing, ERR("ASP Identifier Required") is returned to ASP Up. If the ASP Identifier is not unique, ERR("Invalid ASP Identifier") is returned to ASP Up. Therefore, multiple associations to the same ASP will not allow ASP Up to proceed on all but one of them. This is the same for both M3UA (RFC 3332 Section 3.8.1) and SUA (RFC 3868 Section 3.9.12). --brian On Wed, 11 Jan 2006, Sergey Mikhailov wrote: > Tolga, Ilie, > thank you for your valuable replies on the subject! >=20 > Please let me know, if I misinterpreted your answers. >=20 > 1. > As far as I understand it, an SCTP endpoint, to say it strictly, may ha= ve=20 > only one SCTP association; and a signaling process may use multiple SCT= P=20 > endpoints (and hence multiple SCTP associations) for communication with= =20 > different signaling processes of one AS/SG. >=20 > 2. > Multiple SCTP associations between the same two signaling processes, wh= ile=20 > not prohibited, will require reinterpretation of SCTP-to-ULP events (to= keep=20 > communication status and ASP states consistent across multiple SCTP=20 > associations), such as NETWORK STATUS CHANGE, COMMUNICATION UP/LOST/ERR= OR,=20 > RESTART and SHUTDOWN COMPLETE events (RFC2960). >=20 >=20 > Regards, > Sergey Mikhailov. >=20 >=20 >=20 > ----- Original Message -----=20 > From: "Tolga Asveren" > To: > Sent: Tuesday, January 10, 2006 7:33 PM > Subject: RE: [Sigtran] Multiple SCTP associations >=20 >=20 > > Sergey, > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Be= half > > Of > > Sergey Mikhailov > > Sent: Tuesday, January 10, 2006 11:39 AM > > To: SIGTRAN > > Subject: [Sigtran] Multiple SCTP associations > > > > > > Hi, > > > > It seems that multiple SCTP associations established between the same= two > > signaling processes are not [explicitly] prohibited. > > > > 1. > > Is it legal for a signaling process to establish more than one SCTP > > association to the same AS/SG where these multiple associations are s= erved > > by different signaling processes? > > [TOLGA]Yes, this is how host redundancy is achieved (I assume you tal= k > > about > > M3UA/SUA). There are multiple ASPs serving an AS, and multiple SGPs i= n a > > SG, > > and there is a SCTP association between each SGP/ASP pair -well, obvi= ously > > it is not mandatory-. > > > > 2. > > Is it legal for a signaling process to establish more than one SCTP > > association to the same signaling process at the remote side? > > > > (I feel that the 2nd case may be reasonable only when the remote side= does > > not support multi-homed SCTP endpoints.) > > [TOLGA]Multiple SCTP assocaitions between two etities will have probl= ems > > with ASP state machine if you follow it strictly considering the stat= e > > transitions associated with events from SCTP. This is easy to overcom= e > > with > > a some reasonable reinterpretation. OTOH, multiple SCTP associations = won't > > be a replacement for SCTP multihoming support because SCTP multihomin= g > > provided network/NIC redundancy without loss/missequencing of message= s. > > > > Regards, > > Sergey Mikhailov. > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > >=20 >=20 > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 06:15:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwdxC-0002Cl-1k; Wed, 11 Jan 2006 06:15:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewdx8-0002Ce-U9 for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 06:15:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02884 for ; Wed, 11 Jan 2006 06:14:22 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[LpzsEfAyGAG3OUWOFJr39Qfs0EKe0G3u]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewe42-0007CL-9y for sigtran@ietf.org; Wed, 11 Jan 2006 06:22:50 -0500 Received: from ns.pigworks.openss7.net (IDENT:JNKXsLmcFCTMfCPVc/kMlYbN5RGczsq+@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0BBFdw07597; Wed, 11 Jan 2006 04:15:39 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0BBFcv09779; Wed, 11 Jan 2006 04:15:38 -0700 Date: Wed, 11 Jan 2006 04:15:38 -0700 From: "Brian F. G. Bidulock" To: Binggang Liu Subject: Re: [Sigtran] In IUA, one AS to multiple SGs connection Message-ID: <20060111041538.B9053@openss7.org> Mail-Followup-To: Binggang Liu , sigtran@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from liubinggang@gmail.com on Wed, Jan 11, 2006 at 02:33:17PM +0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Binggang, Its conceivable, but why would you want to do it? --brian Binggang Liu wrote: (Wed, 11 Jan 2006 14:33:17) > > Hi, Folks, > > > > My question is: is it allowed that one AS connect to multiple SGs, in > IUA? > > > > If no, Why? > > > > If yes, is there any requirement about ASP? Can the AS use only one > ASP to connect to all these SGs or it must employ one ASP for each SG? > > > > Thank you! > > > > Regards, > > Binggang Liu > _______________________________________________ > 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 From sigtran-bounces@ietf.org Wed Jan 11 06:29:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EweAZ-0005zu-4m; Wed, 11 Jan 2006 06:29:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EweAX-0005yZ-C3 for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 06:29:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03735 for ; Wed, 11 Jan 2006 06:28:13 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EweHQ-0007aG-9B for Sigtran@ietf.org; Wed, 11 Jan 2006 06:36:41 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0BBROeN000365; Wed, 11 Jan 2006 03:27:25 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <006e01c616a2$24be1d70$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: References: <003f01c61690$291f32d0$150f0f0a@smikhailov> <20060111041058.A9053@openss7.org> Subject: Re: [Sigtran] Multiple SCTP associations Date: Wed, 11 Jan 2006 14:28:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1237/Tue Jan 10 07:53:20 2006 on linkbit2 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by linkbit2.linkbit.com id k0BBROeN000365 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, Yes, I agree. Thank you for pointing me to 1.3.2.4, now it seems clear. Sergey Mikhailov. ----- Original Message -----=20 From: "Brian F. G. Bidulock" To: "Sergey Mikhailov" Cc: ; ; "SIGTRAN"=20 Sent: Wednesday, January 11, 2006 2:10 PM Subject: Re: [Sigtran] Multiple SCTP associations > Sergey, > > I am not agreeing with Tolga much lately... > > It was never our intention to allow more than one SCTP association > between a given pair of processes to persist. > > E.g. RFC 3332 1.3.2.4: > > ... In order to [sic] avoid redundant SCTP associations between two > M3UA peers, one side (client) SHOULD be designated to establish the > SCTP association, or M3UA configuration information established to > detect redundant associations (e.g., via knowledge of the expected > local and remote SCTP endpoint addresses). > > This passage makes it clear that measures are to be taken to avoid > multiple associations. > > Also, an ASP Identifier is required whenever multiple ASPs exist at > the same endpoint. If the provided ASP Identifier is missing, > ERR("ASP Identifier Required") is returned to ASP Up. If the ASP > Identifier is not unique, ERR("Invalid ASP Identifier") is returned > to ASP Up. Therefore, multiple associations to the same ASP will not > allow ASP Up to proceed on all but one of them. > > This is the same for both M3UA (RFC 3332 Section 3.8.1) and SUA > (RFC 3868 Section 3.9.12). > > --brian > > On Wed, 11 Jan 2006, Sergey Mikhailov wrote: > >> Tolga, Ilie, >> thank you for your valuable replies on the subject! >> >> Please let me know, if I misinterpreted your answers. >> >> 1. >> As far as I understand it, an SCTP endpoint, to say it strictly, may h= ave >> only one SCTP association; and a signaling process may use multiple SC= TP >> endpoints (and hence multiple SCTP associations) for communication wit= h >> different signaling processes of one AS/SG. >> >> 2. >> Multiple SCTP associations between the same two signaling processes,=20 >> while >> not prohibited, will require reinterpretation of SCTP-to-ULP events (t= o=20 >> keep >> communication status and ASP states consistent across multiple SCTP >> associations), such as NETWORK STATUS CHANGE, COMMUNICATION=20 >> UP/LOST/ERROR, >> RESTART and SHUTDOWN COMPLETE events (RFC2960). >> >> >> Regards, >> Sergey Mikhailov. >> >> >> >> ----- Original Message -----=20 >> From: "Tolga Asveren" >> To: >> Sent: Tuesday, January 10, 2006 7:33 PM >> Subject: RE: [Sigtran] Multiple SCTP associations >> >> >> > Sergey, >> > >> > -----Original Message----- >> > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On=20 >> > Behalf >> > Of >> > Sergey Mikhailov >> > Sent: Tuesday, January 10, 2006 11:39 AM >> > To: SIGTRAN >> > Subject: [Sigtran] Multiple SCTP associations >> > >> > >> > Hi, >> > >> > It seems that multiple SCTP associations established between the sam= e=20 >> > two >> > signaling processes are not [explicitly] prohibited. >> > >> > 1. >> > Is it legal for a signaling process to establish more than one SCTP >> > association to the same AS/SG where these multiple associations are=20 >> > served >> > by different signaling processes? >> > [TOLGA]Yes, this is how host redundancy is achieved (I assume you ta= lk >> > about >> > M3UA/SUA). There are multiple ASPs serving an AS, and multiple SGPs = in=20 >> > a >> > SG, >> > and there is a SCTP association between each SGP/ASP pair -well,=20 >> > obviously >> > it is not mandatory-. >> > >> > 2. >> > Is it legal for a signaling process to establish more than one SCTP >> > association to the same signaling process at the remote side? >> > >> > (I feel that the 2nd case may be reasonable only when the remote sid= e=20 >> > does >> > not support multi-homed SCTP endpoints.) >> > [TOLGA]Multiple SCTP assocaitions between two etities will have=20 >> > problems >> > with ASP state machine if you follow it strictly considering the sta= te >> > transitions associated with events from SCTP. This is easy to overco= me >> > with >> > a some reasonable reinterpretation. OTOH, multiple SCTP associations= =20 >> > won't >> > be a replacement for SCTP multihoming support because SCTP multihomi= ng >> > provided network/NIC redundancy without loss/missequencing of messag= es. >> > >> > Regards, >> > Sergey Mikhailov. >> > >> > >> > >> > _______________________________________________ >> > 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 > > --=20 > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 > bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 > http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 > =A6 Therefore all progress depends on the =A6 > =A6 unreasonable man. -- George Bernard Shaw =A6 >=20 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 07:04:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EweiM-0008JI-Fi; Wed, 11 Jan 2006 07:04:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EweiK-0008JD-Vn for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 07:04:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06028 for ; Wed, 11 Jan 2006 07:03:08 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwepE-0000A7-2S for Sigtran@ietf.org; Wed, 11 Jan 2006 07:11:37 -0500 Received: by nproxy.gmail.com with SMTP id q29so7732nfc for ; Wed, 11 Jan 2006 04:04:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=owyYpsa8DLFC6b1UeABMEGnurVF722zfNVu4KwD9tB2IYZWrTRbHVF1d/x/2O/r1pDSGtQw/n/vrnljDvdq6m7pfHdubu5LHtm+Xx5k/3VzfMdm5WYyh1biWlaFohXD+l206dGKrJYoYp6/CJG01QP+wpEkn8yPvKQiJ/8TxH54= Received: by 10.48.14.17 with SMTP id 17mr41581nfn; Wed, 11 Jan 2006 04:04:25 -0800 (PST) Received: by 10.48.1.13 with HTTP; Wed, 11 Jan 2006 04:04:25 -0800 (PST) Message-ID: <17b146d60601110404k4f2ca902o9cbf92db4be0ff32@mail.gmail.com> Date: Wed, 11 Jan 2006 13:04:25 +0100 From: Ilie Glib To: Sergey Mikhailov Subject: Re: [Sigtran] Multiple SCTP associations In-Reply-To: <003f01c61690$291f32d0$150f0f0a@smikhailov> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <003f01c61690$291f32d0$150f0f0a@smikhailov> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN , asveren@ulticom.com X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, On 1/11/06, Sergey Mikhailov wrote: > Tolga, Ilie, > thank you for your valuable replies on the subject! > > Please let me know, if I misinterpreted your answers. > > 1. > As far as I understand it, an SCTP endpoint, to say it strictly, may have > only one SCTP association; [Ilie] An SCTP endpoint may have at most one association towards another SCTP endpoint. The SCTP association is a couple of SCTP endpoints. An SCTP endpoint can be an endpoint of multiple SCTP associations. Regards -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 07:11:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwepB-0000lD-4H; Wed, 11 Jan 2006 07:11:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewep9-0000l8-DP for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 07:11:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06441 for ; Wed, 11 Jan 2006 07:10:11 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewew1-0000Ls-G2 for sigtran@ietf.org; Wed, 11 Jan 2006 07:18:39 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Jan 2006 07:11:21 -0500 X-IronPort-AV: i="3.99,355,1131339600"; d="scan'208,217"; a="80011238:sNHT44600040" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0BCBHJf026062; Wed, 11 Jan 2006 07:11:18 -0500 (EST) Received: from xmb-rtp-209.amer.cisco.com ([64.102.31.11]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 07:11:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sigtran] DPNSS (DUA) RFC Updates & Clarifications Date: Wed, 11 Jan 2006 07:11:16 -0500 Message-ID: <542F2F9C2CDE6B40A775125727674ECA01079849@xmb-rtp-209.amer.cisco.com> Thread-Topic: [Sigtran] DPNSS (DUA) RFC Updates & Clarifications Thread-Index: AcYWkWaStOhaRoGrQgifgRkMKBrtKQAFqy3w From: "Ken A Morneault \(kmorneau\)" To: "Michael Mentz" , X-OriginalArrivalTime: 11 Jan 2006 12:11:30.0139 (UTC) FILETIME=[279A7AB0:01C616A8] X-Spam-Score: 0.6 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0994728201==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0994728201== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C616A8.20112C89" This is a multi-part message in MIME format. ------_=_NextPart_001_01C616A8.20112C89 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Michael, =20 Either is fine (modified doc or diffs). =20 Regards, =20 Ken ________________________________ From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Michael Mentz Sent: Wednesday, January 11, 2006 4:29 AM To: sigtran@ietf.org Subject: [Sigtran] DPNSS (DUA) RFC Updates & Clarifications Hi all,=20 I would like to propose some additional information that I have done on the DUA RFC draft document.=20 We have found a number of areas (specifically in areas of physical maintenance and the handling of DLC failures) that are not covered and can be open to interpretation. We also have clarifications to be made wrt. DASS2 as this has subtle differences with DPNSS that the RFC also needs to be aware of. Obviously, these are the kind of scenarios where an RFC needs good guidance on the correct approach to take.=20 Am I to assume that I can post an updated document to this list for consideration and review? just the diffs?=20 Please advise,=20 Thanks,=20 Mike Mentz=20 ------_=_NextPart_001_01C616A8.20112C89 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DPNSS (DUA) RFC Updates & Clarifications
 
 
Michael,
 
Either is fine (modified doc or = diffs).
 
Regards,
 
Ken

From: sigtran-bounces@ietf.org=20 [mailto:sigtran-bounces@ietf.org] On Behalf Of Michael=20 Mentz
Sent: Wednesday, January 11, 2006 4:29 AM
To:=20 sigtran@ietf.org
Subject: [Sigtran] DPNSS (DUA) RFC Updates = &=20 Clarifications

Hi all,

I would like to propose some additional = information=20 that I have done on the DUA RFC draft document.
We have found a number of areas  (specifically in areas of = physical=20 maintenance and the handling of DLC failures)  that are not covered = and can=20 be open to interpretation.

We also have clarifications to be made = wrt. DASS2 as=20 this has subtle differences with DPNSS that the RFC also needs to be = aware=20 of.

Obviously, these are the kind of = scenarios where an=20 RFC needs good guidance on the correct approach to take.

Am I to assume that I can post an updated = document to=20 this list for consideration and review? just the diffs?

Please advise,

Thanks,
Mike=20 Mentz

------_=_NextPart_001_01C616A8.20112C89-- --===============0994728201== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0994728201==-- From sigtran-bounces@ietf.org Wed Jan 11 07:47:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfNi-00049I-Lf; Wed, 11 Jan 2006 07:47:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfNh-00048i-Ja for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 07:47:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08613 for ; Wed, 11 Jan 2006 07:45:53 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwfUZ-0001Jx-CB for Sigtran@ietf.org; Wed, 11 Jan 2006 07:54:20 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0BCjArj000725; Wed, 11 Jan 2006 04:45:11 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <00c501c616ad$01c63cc0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "Ilie Glib" References: <003f01c61690$291f32d0$150f0f0a@smikhailov> <17b146d60601110404k4f2ca902o9cbf92db4be0ff32@mail.gmail.com> Subject: Re: [Sigtran] Multiple SCTP associations Date: Wed, 11 Jan 2006 15:45:58 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1237/Tue Jan 10 07:53:20 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Thanks, Ilie. Regards, Sergey Mikhailov. ----- Original Message ----- From: "Ilie Glib" To: "Sergey Mikhailov" Cc: ; "SIGTRAN" Sent: Wednesday, January 11, 2006 3:04 PM Subject: Re: [Sigtran] Multiple SCTP associations > Sergey, > > On 1/11/06, Sergey Mikhailov wrote: >> Tolga, Ilie, >> thank you for your valuable replies on the subject! >> >> Please let me know, if I misinterpreted your answers. >> >> 1. >> As far as I understand it, an SCTP endpoint, to say it strictly, may have >> only one SCTP association; > > [Ilie] An SCTP endpoint may have at most one association towards > another SCTP endpoint. The SCTP association is a couple of SCTP > endpoints. > An SCTP endpoint can be an endpoint of multiple SCTP associations. > > Regards > > -- > Ilie > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 08:07:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewfh5-0002az-Pl; Wed, 11 Jan 2006 08:07:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewfh4-0002Yi-6V for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 08:07:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10423 for ; Wed, 11 Jan 2006 08:05:53 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewfnw-0002Av-Nv for sigtran@ietf.org; Wed, 11 Jan 2006 08:14:23 -0500 Received: by nproxy.gmail.com with SMTP id q29so15865nfc for ; Wed, 11 Jan 2006 05:07:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sXYejg1fGVTT5Kcpv2MRfvJjjb6F1nnJ9IlnJdfiAm7ec4z/yeuGtKED9r8Mhwmzs93/Wgh1zQaIKvEg5gVVV38dqML0pVbl1kGvuDDa1qK+iVQWfxabTyypKd7sN75vNebLJRKXzOrxjHk2yfqY6LBlMPS2Gj6f5UAPt+H+Bxo= Received: by 10.48.14.17 with SMTP id 17mr45711nfn; Wed, 11 Jan 2006 05:07:09 -0800 (PST) Received: by 10.48.1.13 with HTTP; Wed, 11 Jan 2006 05:07:09 -0800 (PST) Message-ID: <17b146d60601110507u134114c5ie4b46f5267daad18@mail.gmail.com> Date: Wed, 11 Jan 2006 14:07:09 +0100 From: Ilie Glib To: bidulock@openss7.org, Tolga Asveren , sigtran@ietf.org Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs In-Reply-To: <20060110175533.A3748@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060110154715.A2346@openss7.org> <20060110175533.A3748@openss7.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, Tolga thank you very much indeed for your answers. I think it is not possible to have multiple SGs without them playing the role of STPs. Therefore "multiple SG as STP scenario" is equivalent to "multiple SGs scenario". That is STP is always part of SG in this case and in case of SUA the SG deals with (owns) capability (alias) pointcodes. Is my understanding correct? Does it apply to both SUA and M3UA? By the way capability (alias) pointcodes is not an ITU-T term, is the function of mimicking capability (alias) pointcodes an implementation issue for the SG? Thank you in advance Ilie On 1/11/06, Brian F. G. Bidulock wrote: > Tolga, > > I disagree. An instance of MTP is identified by a point code and the > point code resides at the ASPs in the multiple SG as STP scenario. The > point code is not local to the MTP stack at the SG in the SS7 sense when > RK is at PC granularity or above. This is a necessary situation to prope= rly > support the multiple SG as STP scenario. > > --brian > > Tolga Asveren wrote: (Tue, 10 Jan 2006 17:35:1= 2) > > Brian, > > > > You also know as much as I do that SCCP (and MTP3 for M3UA) is hosted o= n > > SGs, the interface between SG and ASP mimics SCCP/SCCP-User (MTP3/MTP3-= User > > interface for M3UA) interface. It is true that for multiple SG scenario= ASPs > > have a small portion of MTP3 functionality, but this does not mean that= MTP3 > > is actually not hosted on SG, e.g. it is still SG generating management > > messages for SCCP/MTP3. > > > > Tolga > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 08:09:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewfiw-00036w-1D; Wed, 11 Jan 2006 08:09:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewfiu-00036D-Gf for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 08:09:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10574 for ; Wed, 11 Jan 2006 08:07:47 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewfpl-0002Es-Sz for sigtran@ietf.org; Wed, 11 Jan 2006 08:16:17 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id ED29DA8540 for ; Wed, 11 Jan 2006 08:08:47 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0BD8gGm029104 for ; Wed, 11 Jan 2006 08:08:47 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SCTP associations Date: Wed, 11 Jan 2006 07:49:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <003f01c61690$291f32d0$150f0f0a@smikhailov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, > -----Original Message----- > From: Sergey Mikhailov [mailto:smikhailov@linkbit.com] > Sent: Wednesday, January 11, 2006 4:19 AM > To: asveren@ulticom.com; ilie.glib@googlemail.com > Cc: SIGTRAN > Subject: Re: [Sigtran] Multiple SCTP associations > > > Tolga, Ilie, > thank you for your valuable replies on the subject! > > Please let me know, if I misinterpreted your answers. > > 1. > As far as I understand it, an SCTP endpoint, to say it strictly, may have > only one SCTP association; and a signaling process may use multiple SCTP > endpoints (and hence multiple SCTP associations) for communication with > different signaling processes of one AS/SG. [TOLGA]Yes. > > 2. > Multiple SCTP associations between the same two signaling > processes, while > not prohibited, will require reinterpretation of SCTP-to-ULP > events (to keep > communication status and ASP states consistent across multiple SCTP > associations), such as NETWORK STATUS CHANGE, COMMUNICATION > UP/LOST/ERROR, > RESTART and SHUTDOWN COMPLETE events (RFC2960). [TOLGA]The protocol never intends to use multiple associations between two signaling entities. If you follow that path -for some reason-, both sides will need to agree on the chneges necessary to support that scenario, i.e. it won't be a solution compliant with the protocol. > > > Regards, > Sergey Mikhailov. > > > > ----- Original Message ----- > From: "Tolga Asveren" > To: > Sent: Tuesday, January 10, 2006 7:33 PM > Subject: RE: [Sigtran] Multiple SCTP associations > > > > Sergey, > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf > Of > Sergey Mikhailov > Sent: Tuesday, January 10, 2006 11:39 AM > To: SIGTRAN > Subject: [Sigtran] Multiple SCTP associations > > > Hi, > > It seems that multiple SCTP associations established between the same two > signaling processes are not [explicitly] prohibited. > > 1. > Is it legal for a signaling process to establish more than one SCTP > association to the same AS/SG where these multiple associations are served > by different signaling processes? > [TOLGA]Yes, this is how host redundancy is achieved (I assume you talk > about > M3UA/SUA). There are multiple ASPs serving an AS, and multiple SGPs in a > SG, > and there is a SCTP association between each SGP/ASP pair -well, obviously > it is not mandatory-. > > 2. > Is it legal for a signaling process to establish more than one SCTP > association to the same signaling process at the remote side? > > (I feel that the 2nd case may be reasonable only when the remote side does > not support multi-homed SCTP endpoints.) > [TOLGA]Multiple SCTP assocaitions between two etities will have problems > with ASP state machine if you follow it strictly considering the state > transitions associated with events from SCTP. This is easy to overcome > with > a some reasonable reinterpretation. OTOH, multiple SCTP associations won't > be a replacement for SCTP multihoming support because SCTP multihoming > provided network/NIC redundancy without loss/missequencing of messages. > > Regards, > Sergey Mikhailov. > > > > _______________________________________________ > 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 From sigtran-bounces@ietf.org Wed Jan 11 08:16:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfnT-0004W0-94; Wed, 11 Jan 2006 08:13:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfnQ-0004Vq-Ok for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 08:13:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10887 for ; Wed, 11 Jan 2006 08:12:28 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwfuL-0002MV-Aw for sigtran@ietf.org; Wed, 11 Jan 2006 08:20:57 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 3117610D1E for ; Wed, 11 Jan 2006 08:13:39 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0BDDcJP029510 for ; Wed, 11 Jan 2006 08:13:39 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Date: Wed, 11 Jan 2006 07:54:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060110175533.A3748@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Tuesday, January 10, 2006 7:56 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs > > > Tolga, > > I disagree. An instance of MTP is identified by a point code and the > point code resides at the ASPs in the multiple SG as STP scenario. The > point code is not local to the MTP stack at the SG in the SS7 sense when > RK is at PC granularity or above. This is a necessary situation > to properly > support the multiple SG as STP scenario. [TOLGA]Even for PC granularity RKs, it is SG which controls/creates the unique view of the signaling enitity to the network, so one has to have necessary MTP3 procedures to support that. BTW, I wouldn't call hosting MTP3 logic in SG as "a PC in MTP3 stack in SG", it is just providing necessary procedures to have the unique view of the signaling enitity and generating corresponding network messages -and it is the multiple clones of the same unique view on different SGs, which are not synchronized, which may create issues for multiple-SG scenarios-. > > --brian > > Tolga Asveren wrote: (Tue, 10 Jan 2006 > 17:35:12) > > Brian, > > > > You also know as much as I do that SCCP (and MTP3 for M3UA) is hosted on > > SGs, the interface between SG and ASP mimics SCCP/SCCP-User > (MTP3/MTP3-User > > interface for M3UA) interface. It is true that for multiple SG > scenario ASPs > > have a small portion of MTP3 functionality, but this does not > mean that MTP3 > > is actually not hosted on SG, e.g. it is still SG generating management > > messages for SCCP/MTP3. > > > > Tolga > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 08:19:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfsZ-0005gN-ND; Wed, 11 Jan 2006 08:19:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfsY-0005gA-Uc for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 08:19:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11201 for ; Wed, 11 Jan 2006 08:17:46 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[twi91DuHFQOtRqWQimp1yawFincyT95l]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwfzR-0002Us-J1 for sigtran@ietf.org; Wed, 11 Jan 2006 08:26:15 -0500 Received: from ns.pigworks.openss7.net (IDENT:J+qXWrU+5OOv+UMcPSxKGg2CxDoHsxEV@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0BDIww10001; Wed, 11 Jan 2006 06:18:58 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0BDIw211267; Wed, 11 Jan 2006 06:18:58 -0700 Date: Wed, 11 Jan 2006 06:18:58 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Message-ID: <20060111061858.C9053@openss7.org> Mail-Followup-To: Ilie Glib , Tolga Asveren , sigtran@ietf.org References: <20060110154715.A2346@openss7.org> <20060110175533.A3748@openss7.org> <17b146d60601110507u134114c5ie4b46f5267daad18@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601110507u134114c5ie4b46f5267daad18@mail.gmail.com>; from ilie.glib@googlemail.com on Wed, Jan 11, 2006 at 02:07:09PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sigtran@ietf.org, Tolga Asveren X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, Ilie Glib wrote: (Wed, 11 Jan 2006 14:07:09) > Brian, Tolga > > thank you very much indeed for your answers. > > I think it is not possible to have multiple SGs without them playing > the role of STPs. I don't think so. Do you have an example? > Therefore "multiple SG as STP scenario" is equivalent to "multiple SGs > scenario". Don't think so. > That is STP is always part of SG in this case and in case of SUA the > SG deals with (owns) capability (alias) pointcodes. Other than alias point codes are possible. > > Is my understanding correct? I don't think that you are there yet. > Does it apply to both SUA and M3UA? Did I not decribe this? > By the way capability (alias) pointcodes is not an ITU-T term, is the > function of mimicking capability (alias) pointcodes an implementation > issue for the SG? It in ANSI term from ATIS T1.111 and T1.112. ---brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 08:20:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewftd-0005zS-1G; Wed, 11 Jan 2006 08:20:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewftb-0005zL-Aa for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 08:20:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11268 for ; Wed, 11 Jan 2006 08:18:50 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[pjKOAkxuR5k4Mf47reHx+lDaG4sTIPQw]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewg0V-0002X8-VU for sigtran@ietf.org; Wed, 11 Jan 2006 08:27:20 -0500 Received: from ns.pigworks.openss7.net (IDENT:2fcR6P11lV5TzOtBqYvfHhG7JMzWMX7j@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0BDK7w10036; Wed, 11 Jan 2006 06:20:07 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0BDK7911300; Wed, 11 Jan 2006 06:20:07 -0700 Date: Wed, 11 Jan 2006 06:20:06 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Message-ID: <20060111062006.D9053@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20060110175533.A3748@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from asveren@ulticom.com on Wed, Jan 11, 2006 at 07:54:11AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Wed, 11 Jan 2006 07:54:11) > Brian, > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Tuesday, January 10, 2006 7:56 PM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs > > > > > > Tolga, > > > > I disagree. An instance of MTP is identified by a point code and the > > point code resides at the ASPs in the multiple SG as STP scenario. The > > point code is not local to the MTP stack at the SG in the SS7 sense when > > RK is at PC granularity or above. This is a necessary situation > > to properly > > support the multiple SG as STP scenario. > [TOLGA]Even for PC granularity RKs, it is SG which controls/creates the > unique view of the signaling enitity to the network, so one has to have > necessary MTP3 procedures to support that. > > BTW, I wouldn't call hosting MTP3 logic in SG as "a PC in MTP3 stack in SG", > it is just providing necessary procedures to have the unique view of the > signaling enitity and generating corresponding network messages -and it is > the multiple clones of the same unique view on different SGs, which are not > synchronized, which may create issues for multiple-SG scenarios-. STPs do this all day long. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 08:23:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewfwm-0006rw-Ol; Wed, 11 Jan 2006 08:23:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewfwl-0006pp-IP for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 08:23:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11522 for ; Wed, 11 Jan 2006 08:22:06 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewg3f-0002ce-R5 for sigtran@ietf.org; Wed, 11 Jan 2006 08:30:36 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 307A982F43 for ; Wed, 11 Jan 2006 08:23:14 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0BDN9Kc000204 for ; Wed, 11 Jan 2006 08:23:13 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SCTP associations Date: Wed, 11 Jan 2006 08:03:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org one correction below... > -----Original Message----- > From: sigtran-bounces@ietf.org > [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren > Sent: Wednesday, January 11, 2006 7:49 AM > To: sigtran@ietf.org > Subject: RE: [Sigtran] Multiple SCTP associations > > > Sergey, > > > -----Original Message----- > > From: Sergey Mikhailov [mailto:smikhailov@linkbit.com] > > Sent: Wednesday, January 11, 2006 4:19 AM > > To: asveren@ulticom.com; ilie.glib@googlemail.com > > Cc: SIGTRAN > > Subject: Re: [Sigtran] Multiple SCTP associations > > > > > > Tolga, Ilie, > > thank you for your valuable replies on the subject! > > > > Please let me know, if I misinterpreted your answers. > > > > 1. > > As far as I understand it, an SCTP endpoint, to say it > strictly, may have > > only one SCTP association; and a signaling process may use multiple SCTP > > endpoints (and hence multiple SCTP associations) for communication with > > different signaling processes of one AS/SG. > [TOLGA]Yes. [TOLGA]Actually no. Each signaling process is an SCTP endpoint. You have different SCTP associations from this endpoint to different SCTP endpoints. SCTP endpoint ==> local IP addresses, port SCTP association ==> A relationship between two SCTP endpoints > > > > 2. > > Multiple SCTP associations between the same two signaling > > processes, while > > not prohibited, will require reinterpretation of SCTP-to-ULP > > events (to keep > > communication status and ASP states consistent across multiple SCTP > > associations), such as NETWORK STATUS CHANGE, COMMUNICATION > > UP/LOST/ERROR, > > RESTART and SHUTDOWN COMPLETE events (RFC2960). > [TOLGA]The protocol never intends to use multiple associations between two > signaling entities. If you follow that path -for some reason-, both sides > will need to agree on the chneges necessary to support that scenario, i.e. > it won't be a solution compliant with the protocol. > > > > > > Regards, > > Sergey Mikhailov. > > > > > > > > ----- Original Message ----- > > From: "Tolga Asveren" > > To: > > Sent: Tuesday, January 10, 2006 7:33 PM > > Subject: RE: [Sigtran] Multiple SCTP associations > > > > > > > Sergey, > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org > [mailto:sigtran-bounces@ietf.org]On Behalf > > Of > > Sergey Mikhailov > > Sent: Tuesday, January 10, 2006 11:39 AM > > To: SIGTRAN > > Subject: [Sigtran] Multiple SCTP associations > > > > > > Hi, > > > > It seems that multiple SCTP associations established between > the same two > > signaling processes are not [explicitly] prohibited. > > > > 1. > > Is it legal for a signaling process to establish more than one SCTP > > association to the same AS/SG where these multiple associations > are served > > by different signaling processes? > > [TOLGA]Yes, this is how host redundancy is achieved (I assume you talk > > about > > M3UA/SUA). There are multiple ASPs serving an AS, and multiple SGPs in a > > SG, > > and there is a SCTP association between each SGP/ASP pair > -well, obviously > > it is not mandatory-. > > > > 2. > > Is it legal for a signaling process to establish more than one SCTP > > association to the same signaling process at the remote side? > > > > (I feel that the 2nd case may be reasonable only when the > remote side does > > not support multi-homed SCTP endpoints.) > > [TOLGA]Multiple SCTP assocaitions between two etities will have problems > > with ASP state machine if you follow it strictly considering the state > > transitions associated with events from SCTP. This is easy to overcome > > with > > a some reasonable reinterpretation. OTOH, multiple SCTP > associations won't > > be a replacement for SCTP multihoming support because SCTP multihoming > > provided network/NIC redundancy without loss/missequencing of messages. > > > > Regards, > > Sergey Mikhailov. > > > > > > > > _______________________________________________ > > 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 From sigtran-bounces@ietf.org Wed Jan 11 08:49:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwgLx-0007Cv-60; Wed, 11 Jan 2006 08:49:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwgLv-0007Cq-NX for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 08:49:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13395 for ; Wed, 11 Jan 2006 08:48:07 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwgSp-0003NU-Lt for Sigtran@ietf.org; Wed, 11 Jan 2006 08:56:37 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0BDlWwf001011; Wed, 11 Jan 2006 05:47:33 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <00de01c616b5$b869a220$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "Tolga Asveren" References: Subject: Re: [Sigtran] Multiple SCTP associations Date: Wed, 11 Jan 2006 16:48:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1237/Tue Jan 10 07:53:20 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, some comments below. >> > >> > 1. >> > As far as I understand it, an SCTP endpoint, to say it >> strictly, may have >> > only one SCTP association; and a signaling process may use multiple >> > SCTP >> > endpoints (and hence multiple SCTP associations) for communication with >> > different signaling processes of one AS/SG. >> [TOLGA]Yes. > [TOLGA]Actually no. Each signaling process is an SCTP endpoint. You have > different SCTP associations from this endpoint to different SCTP > endpoints. [Sergey] Ok, now I'm agree. > > SCTP endpoint ==> local IP addresses, port [Sergey] I would consider an SCTP endpoint this way: SCTP endpoint ==> combination of a set of destination transport addresses and a set of source transport addresses (see SCTP endpoint definition on Page 13 of the RFC 2960). > SCTP association ==> A relationship between two SCTP endpoints [Sergey] Agree. >> [TOLGA]The protocol never intends to use multiple associations between >> two >> signaling entities. If you follow that path -for some reason-, both sides >> will need to agree on the chneges necessary to support that scenario, >> i.e. >> it won't be a solution compliant with the protocol. [Sergey] Ok. Regards, Sergey Mikhailov. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 09:12:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewghz-0005q7-4h; Wed, 11 Jan 2006 09:12:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewghw-0005pt-Sm for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 09:12:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15058 for ; Wed, 11 Jan 2006 09:10:52 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewgoq-00045N-Vt for Sigtran@ietf.org; Wed, 11 Jan 2006 09:19:22 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0BEA6o0001106; Wed, 11 Jan 2006 06:10:13 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <010b01c616b8$e32d05d0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "Binggang Liu" References: Subject: Re: [Sigtran] In IUA, one AS to multiple SGs connection Date: Wed, 11 Jan 2006 17:10:58 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1237/Tue Jan 10 07:53:20 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0705352092==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0705352092== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0108_01C616D1.FD867060" This is a multi-part message in MIME format. ------=_NextPart_000_0108_01C616D1.FD867060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Binggang, you can also see an example IUA logical network architecture in Appendix = A of the new RFC 4233 (page 70). Regards, Sergey Mikhailov. ----- Original Message -----=20 From: Binggang Liu=20 To: sigtran@ietf.org=20 Sent: Wednesday, January 11, 2006 9:33 AM Subject: [Sigtran] In IUA, one AS to multiple SGs connection Hi, Folks, My question is: is it allowed that one AS connect to multiple SGs, in = IUA? If no, Why? If yes, is there any requirement about ASP? Can the AS use only one = ASP to connect to all these SGs or it must employ one ASP for each SG? Thank you! Regards, Binggang Liu -------------------------------------------------------------------------= ----- _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran ------=_NextPart_000_0108_01C616D1.FD867060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Binggang,
 
you can also see an example IUA logical = network=20 architecture in Appendix A of the new RFC 4233 (page 70).
 
 
Regards,
Sergey Mikhailov.
 
 
----- Original Message -----
From:=20 Binggang=20 Liu
Sent: Wednesday, January 11, = 2006 9:33=20 AM
Subject: [Sigtran] In IUA, one = AS to=20 multiple SGs connection

Hi, Folks,
 
My question is: is it allowed that one AS connect to multiple = SGs, in=20 IUA?
 
If no, Why?
 
If yes, is there any requirement about ASP? Can the AS use = only one=20 ASP to connect to all these SGs or it must employ one ASP for = each=20 SG?
 
Thank you!
 
Regards,
Binggang Liu

_______________________________________________
Sigtran = mailing=20 = list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtra= n
------=_NextPart_000_0108_01C616D1.FD867060-- --===============0705352092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0705352092==-- From sigtran-bounces@ietf.org Wed Jan 11 09:33:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewh2P-0003nq-L2; Wed, 11 Jan 2006 09:33:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewh2O-0003nc-Id for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 09:33:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16567 for ; Wed, 11 Jan 2006 09:31:59 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewh9F-0004kv-FU for sigtran@ietf.org; Wed, 11 Jan 2006 09:40:26 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id FEFC12D035 for ; Wed, 11 Jan 2006 09:33:02 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0BEWxSg007517 for ; Wed, 11 Jan 2006 09:32:59 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Date: Wed, 11 Jan 2006 09:13:32 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060111062006.D9053@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, [..snip..] > > [TOLGA]Even for PC granularity RKs, it is SG which controls/creates the > > unique view of the signaling enitity to the network, so one has to have > > necessary MTP3 procedures to support that. > > > > BTW, I wouldn't call hosting MTP3 logic in SG as "a PC in MTP3 > stack in SG", > > it is just providing necessary procedures to have the unique view of the > > signaling enitity and generating corresponding network messages > -and it is > > the multiple clones of the same unique view on different SGs, > which are not > > synchronized, which may create issues for multiple-SG scenarios-. > > STPs do this all day long. [TOLGA]On the practical side of how things work, I agree with you that with multiple-SG acting as STP scenario where RKs are in PC granularity, the possibly different views of the hosted PC are less of a problem. In such a case hosting necessary MTP3 logic for AS maps pretty much to route management from functionality point of view. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 15:03:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmC5-0006OU-T0; Wed, 11 Jan 2006 15:03:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmC4-0006NL-5y for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 15:03:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08770 for ; Wed, 11 Jan 2006 15:02:18 -0500 (EST) Received: from smtp02.tekelec.com ([198.89.42.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwmJ1-0005sk-OY for sigtran@ietf.org; Wed, 11 Jan 2006 15:10:52 -0500 Received: from dcex05.tekelec.com (dcex05.tekelec.com [172.28.104.65]) by smtp02.tekelec.com (8.12.10/8.12.10) with ESMTP id k0BJx1Il011008 for ; Wed, 11 Jan 2006 13:59:07 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex05.tekelec.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 14:03:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jan 2006 14:03:10 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E717026A71F4@DCEVS2.tekelec.com> Thread-Topic: (M2PA) M2PA Implementor's Guide Kickoff Thread-Index: AcYW6gvA0eYHQPKjQCWn81VvAo+34Q== From: "Craig, Jeffrey" To: X-OriginalArrivalTime: 11 Jan 2006 20:03:11.0676 (UTC) FILETIME=[0CA24FC0:01C616EA] X-Spam-Score: 0.8 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Subject: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1790760866==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1790760866== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C616EA.0C381D08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C616EA.0C381D08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, =20 As Lyndon Ong stated in a prior post, I've agreed to lead the effort in creating an M2PA Implementor's Guide. I am busy working on it,=20 but I have not yet submitted a draft. When I do submit it, it will have the lovely name 'draft-ietf-sigtran-m2pa-ig-00.txt'. =20 In the meantime, I would like to kick-off discussion and solicit ideas for the following: =20 * preference for IG content (delta document vs. replacement document) * specific defects and remedies * clarifications =20 At the bottom of this post is a memo I drafted describing my proposals for the IG, as well as the preliminary list of 'defects'. Comments and questions are welcome. =20 Regards, =20 Jeff =20 =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=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 M2PA Implementor's Guide: Defect Summary v0.1 Jeff Craig 1/11/06 =20 The primary goal of the M2PA Implementor's Guide (IG) is to identify and fix RFC 4165 defects. The most important defects are those that can lead to interoperability problems between M2PA peers. (Some would argue these are the only defects.) =20 As lead editor, my proposed approach for the M2PA IG is: A M2PA RFC=20 passage is defective if the community agrees that the passage is either incorrect or unclear. Reasonable requests for clarification will be honored. =20 I propose for the IG to address each defect by listing the applicable original text followed by the new text. The applicable text may be non-contiguous. This means that the IG will contain changes for the=20 previous RFC, rather than replacing the RFC in its entirety. =20 ------------------------------------------------------------------------ --- The following is a draft summary of defects that I have gathered from the SIGTRAN listserv archives, as well as from my company's experience during M2PA development and deployment: =20 (ordered by M2PA RFC section) =20 1) 1.7.3: Clarify that stream 0 in each direction SHOULD be given higher priority than stream 1 in each direction. Forward reference 4.1.8. =20 2) 2.2.2: Clarify initial FSN per MTP3 standard. =20 3) 2.3.1: Clarify that an "empty User Data message" is a=20 message having the Command Message Header, the User Data message type, the M2PA-specific Message Header, and no Message Data. =20 4) 2.3.2: Provide a table that lists the equivant Q.703 MTP2 FISU or LSSU for each M2PA LS Message. =20 4) 4: Clarify that interoperability between M2PA peers requires that each implementation meets the requirements of same=20 MTP2 specification. Clarify that the M2PA protocol does not provide a mechanism for determining the MTP2 variant implemented by the peer. =20 5) 4.1.4: Distinguish M2PA behavior during Aligned Not Ready and Processor Outage state equivalents. Clarify M2PA sequence number synchronization procedure upon Processor Outage recovery. Clarify M2PA treatment of LS Ready during Aligned Not Ready and Processor Outage state equivalents. Address need for timer in support of sequence number=20 synchronization upon exiting Processor Outage state equivalent. =20 6) 4.1.5: Clarify that after receiving LS Busy and prior to receiving LS Busy Ended non-empty M2PA User Data Message MUST NOT be sent and empty M2PA User Data Message (ACK) MAY be sent. =20 7) 4.1.5: Clarify M2PA behavior during simultaneous local busy=20 and local processor outage conditions. =20 8) 4.1.5: Clarify M2PA management of T7 when remote busy clears. =20 9) 4.1.8: Clarify meaning of giving "higher priority" to the Link Status association stream. =20 10) 4.1.9: Clarify M2PA treatment of received messages having a higher (newer) version. =20 11) 4.2.1: Clarify M2PA treatment of FSN for non-empty User Data,=20 empty User Data, and Link Status messages. =20 12) 4.2.1: Clarify M2PA initial FSN based upon MTP2 variant. =20 13) 4.2.1: Clarify M2PA treatment of BSN for non-empty User Data,=20 empty User Data, and Link Status messages (in general), and Link Status Ready messages (in particular). =20 14) 5.4: Update Figure 16 to accurately decribe M2PA behavior during processor outage. =20 15) 5.4: Provide new figure depicting M2PA message flows during aligned not ready state equivalent. =20 16) NEW: Provide better recommendations for M2PA timer values, since=20 the cited MTP2 standards apply to dedicated physical transports having different characteristics (e.g. bit rates, latency) than SCTP networks. ------_=_NextPart_001_01C616EA.0C381D08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello=20 All,
 
As Lyndon=20 Ong stated in a prior post, I've agreed to lead the = effort
in creating=20 an M2PA Implementor's Guide. I am busy working on it,=20
but I have=20 not yet submitted a draft. When I do submit it, it will
have the=20 lovely name 'draft-ietf-sigtran-m2pa-ig-00.txt'.
 
In the=20 meantime, I would like to kick-off discussion and solicit=20 ideas
for the=20 following:
 
* preference=20 for IG content (delta document vs. replacement = document)
* specific=20 defects and remedies
* clarifications
 
At the=20 bottom of this post is a memo I drafted describing my=20 proposals
for the IG,=20 as well as the preliminary list of 'defects'. = Comments
and=20 questions are welcome.
 
Regards,
 
Jeff
 
=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=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
M2PA=20 Implementor's Guide: Defect Summary
v0.1
Jeff=20 Craig
1/11/06
 
The primary=20 goal of the M2PA Implementor's Guide (IG) is to identify and
fix RFC = 4165=20 defects. The most important defects are those that can lead
to=20 interoperability problems between M2PA peers. (Some would argue=20 these
are the only=20 defects.)
 
As lead=20 editor, my proposed approach for the M2PA IG is: A M2PA RFC
passage = is=20 defective if the community agrees that the passage is = either
incorrect or=20 unclear. Reasonable requests for clarification will=20 be
honored.
 
I propose=20 for the IG to address each defect by listing the applicable
original = text=20 followed by the new text. The applicable text may be
non-contiguous. = This=20 means that the IG will contain changes for the
previous RFC, rather = than=20 replacing the RFC in its entirety.
 
----------------------------------------------= -----------------------------
The=20 following is a draft summary of defects that I have gathered from = the
SIGTRAN=20 listserv archives, as well as from my company's experience
during = M2PA=20 development and deployment:
 
(ordered by=20 M2PA RFC section)
 

 1) = 1.7.3: Clarify=20 that stream 0 in each direction SHOULD be=20 given
       higher priority than = stream 1 in=20 each direction. Forward
       = reference=20 4.1.8.
 
 2) 2.2.2: Clarify initial FSN per MTP3 standard.
 
 3) 2.3.1: Clarify that an "empty User Data message" is a=20
       message having the Command = Message=20 Header, the User Data
       message = type, the=20 M2PA-specific Message Header, and = no
      =20 Message Data.
 
 4) 2.3.2: Provide a table that lists the equivant Q.703 MTP2=20 FISU
       or LSSU for each M2PA LS=20 Message.
      
 4) 4: Clarify = that=20 interoperability between M2PA peers=20 requires
       that each = implementation meets=20 the requirements of same
       MTP2=20 specification. Clarify that the M2PA protocol does=20 not
       provide a mechanism for = determining=20 the MTP2 variant
       implemented by = the=20 peer.
 
 5) 4.1.4: Distinguish M2PA behavior during Aligned Not Ready=20 and
           =   =20 Processor Outage state=20 equivalents.
         &nb= sp;=20 Clarify M2PA sequence number synchronization=20 procedure
          =    =20 upon Processor Outage=20 recovery.
          = =20 Clarify M2PA treatment of LS Ready during Aligned=20 Not
           =   =20 Ready and Processor Outage state=20 equivalents.
         &nb= sp;=20 Address need for timer in support of sequence number=20
           &nb= sp; =20 synchronization upon exiting Processor Outage=20 state
          &nbs= p;  =20 equivalent.
 
 6) 4.1.5: Clarify that after receiving LS = Busy=20 and prior to
    receiving LS Busy Ended non-empty = M2PA User=20 Data Message
    MUST NOT be sent and empty M2PA User = Data=20 Message (ACK) MAY be
    sent.
 
 7) = 4.1.5:=20 Clarify M2PA behavior during simultaneous local busy =
    and=20 local processor outage conditions.
 
 8) 4.1.5: Clarify = M2PA=20 management of T7 when remote busy clears.
 
 9) 4.1.8: = Clarify=20 meaning of giving "higher priority" to the Link
    = Status=20 association stream.
 
10) 4.1.9: Clarify M2PA treatment of = received=20 messages having a
    higher (newer) = version.
 =20
11) 4.2.1: Clarify M2PA treatment of FSN for non-empty User Data,=20
    empty User Data, and Link Status=20 messages.
 
12) 4.2.1: Clarify M2PA initial FSN based upon = MTP2=20 variant.
 
13) 4.2.1: Clarify M2PA treatment of BSN for = non-empty=20 User Data,
    empty User Data, and Link Status = messages (in=20 general), and
    Link Status Ready messages (in=20 particular).
 
14) 5.4: Update Figure 16 to accurately = decribe M2PA=20 behavior during
    processor outage.
 
15) 5.4: Provide new figure depicting M2PA message flows=20 during
    aligned not ready state equivalent.
 
16) NEW: Provide better recommendations for M2PA timer values, = since=20
    the cited MTP2 standards apply to dedicated = physical=20 transports
    having different characteristics (e.g. = bit=20 rates, latency) than
    SCTP=20 networks.
------_=_NextPart_001_01C616EA.0C381D08-- --===============1790760866== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1790760866==-- From sigtran-bounces@ietf.org Wed Jan 11 15:38:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewmk0-0007Q7-Ue; Wed, 11 Jan 2006 15:38:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewmjz-0007Pv-Rw for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 15:38:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10936 for ; Wed, 11 Jan 2006 15:37:22 -0500 (EST) Received: from [142.179.199.224] (helo=gw.openss7.com ident=[kAFTYQfyXGTLdaN0iYqNS9hmpNUeparH]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewmqd-0006lB-8Z for sigtran@ietf.org; Wed, 11 Jan 2006 15:45:56 -0500 Received: from ns.pigworks.openss7.net (IDENT:IStP56IvlPlcyNTx2SZDViRQbL/8eRzc@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0BKbew19371; Wed, 11 Jan 2006 13:37:40 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0BKbeZ15804; Wed, 11 Jan 2006 13:37:40 -0700 Date: Wed, 11 Jan 2006 13:37:40 -0700 From: "Brian F. G. Bidulock" To: "Craig, Jeffrey" Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Message-ID: <20060111133740.A14574@openss7.org> Mail-Followup-To: "Craig, Jeffrey" , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E717026A71F4@DCEVS2.tekelec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <58292FA6B3EEFD49AEDAF6597E21E717026A71F4@DCEVS2.tekelec.com>; from Jeffrey.Craig@tekelec.com on Wed, Jan 11, 2006 at 02:03:10PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Jeffrey, I prefer the usual delta format. There are no defects in the document that I know of. (I would not have passed the RFC by 48 hours if I knew of any.) I think all of these "clarifications" (except one for PO) are unnecessary. Most of these were not mentioned even in passing on the mailing list. The I-G should try to represent consensus, addressing issues raised on the mailing list or from interop tests, and should not be the editor's personal pet peeve list for the specification. Timer values should be addressed in an AS, not in the PS. See draft-bidulock-sigtran-m2pa-test for specific examples of procedures if you think the RFC lacks examples. --brian Craig, Jeffrey wrote: (Wed, 11 Jan 2006 14:03:10) > > Hello All, > > As Lyndon Ong stated in a prior post, I've agreed to lead the effort > in creating an M2PA Implementor's Guide. I am busy working on it, > but I have not yet submitted a draft. When I do submit it, it will > have the lovely name 'draft-ietf-sigtran-m2pa-ig-00.txt'. > > In the meantime, I would like to kick-off discussion and solicit ideas > for the following: > > * preference for IG content (delta document vs. replacement document) > * specific defects and remedies > * clarifications > > At the bottom of this post is a memo I drafted describing my proposals > for the IG, as well as the preliminary list of 'defects'. Comments > and questions are welcome. > > Regards, > > Jeff -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 16:17:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwnI6-0000YP-Bw; Wed, 11 Jan 2006 16:13:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwnI4-0000YG-5b for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 16:13:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14117 for ; Wed, 11 Jan 2006 16:12:34 -0500 (EST) Received: from [142.179.199.224] (helo=gw.openss7.com ident=[XlEDTYPH++1ywbY9HmRFIVIe0Z3dNFsZ]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwnOf-0008FB-QO for sigtran@ietf.org; Wed, 11 Jan 2006 16:21:09 -0500 Received: from ns.pigworks.openss7.net (IDENT:fzKgVPicgo4hSbaDKgmdjW+SOMKZxkGm@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0BLCxw20551; Wed, 11 Jan 2006 14:12:59 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0BLCxn16346; Wed, 11 Jan 2006 14:12:59 -0700 Date: Wed, 11 Jan 2006 14:12:58 -0700 From: "Brian F. G. Bidulock" To: "Craig, Jeffrey" Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Message-ID: <20060111141258.A16304@openss7.org> Mail-Followup-To: "Craig, Jeffrey" , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E717026A71F4@DCEVS2.tekelec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <58292FA6B3EEFD49AEDAF6597E21E717026A71F4@DCEVS2.tekelec.com>; from Jeffrey.Craig@tekelec.com on Wed, Jan 11, 2006 at 02:03:10PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Jeffrey, I did rework Figure 16 just prior to finalization of the RFC. I believe that it does accurately describe M2PA behaviour during PO. What problem did you think that there was with the figure? --brian Craig, Jeffrey wrote: (Wed, 11 Jan 2006 14:03:10) > > 14) 5.4: Update Figure 16 to accurately decribe M2PA behavior during > processor outage. > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 11 16:32:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewna4-0000rf-5K; Wed, 11 Jan 2006 16:32:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewna2-0000qw-Vv for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 16:32:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15701 for ; Wed, 11 Jan 2006 16:31:08 -0500 (EST) Received: from smtp03.tekelec.com ([198.89.42.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewngz-0000YE-K6 for sigtran@ietf.org; Wed, 11 Jan 2006 16:39:42 -0500 Received: from dcex04.tekelec.com (dcex04.tekelec.com [172.28.104.64]) by smtp03.tekelec.com (8.12.10/8.12.10) with ESMTP id k0BLTFju015345; Wed, 11 Jan 2006 15:29:15 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex04.tekelec.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 15:32:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Date: Wed, 11 Jan 2006 15:32:17 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E717026DA55E@DCEVS2.tekelec.com> Thread-Topic: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Thread-Index: AcYW7zi1d82byF4gS8a0XnVqhZ4WQwAAWl4Q From: "Craig, Jeffrey" To: X-OriginalArrivalTime: 11 Jan 2006 21:32:18.0460 (UTC) FILETIME=[7F90CDC0:01C616F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Brian, > and should not be the editor's personal pet peeve list for the specification=20 Personal pet peeves? Many of the defects I listed I obtained straight from other's posts on the SIGTRAN listserv. I posted them as a proposal to kickoff discussion. I look forward to other's comments. If the community agrees to your strict=20 definition of 'defect' and that there are no M2PA 'defects', then there won't be a M2PA IG. If the only 'defect' is the processor outage text, then that is what the M2PA IG will address and nothing else. Regards, Jeff -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Brian F. G. Bidulock Sent: Wednesday, January 11, 2006 3:38 PM To: Craig, Jeffrey Cc: sigtran@ietf.org Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Jeffrey, I prefer the usual delta format. There are no defects in the document that I know of. (I would not have passed the RFC by 48 hours if I knew of any.) I think all of these "clarifications" (except one for PO) are unnecessary. Most of these were not mentioned even in passing on the mailing list. The I-G should try to represent consensus, addressing issues raised on the mailing list or from interop tests, and should not be the editor's personal pet peeve list for the specification. Timer values should be addressed in an AS, not in the PS. See draft-bidulock-sigtran-m2pa-test for specific examples of procedures if you think the RFC lacks examples. --brian Craig, Jeffrey wrote: (Wed, 11 Jan 2006 14:03:10) >=20 > Hello All, >=20 > As Lyndon Ong stated in a prior post, I've agreed to lead the effort > in creating an M2PA Implementor's Guide. I am busy working on it, > but I have not yet submitted a draft. When I do submit it, it will > have the lovely name 'draft-ietf-sigtran-m2pa-ig-00.txt'. >=20 > In the meantime, I would like to kick-off discussion and solicit ideas > for the following: >=20 > * preference for IG content (delta document vs. replacement document) > * specific defects and remedies > * clarifications >=20 > At the bottom of this post is a memo I drafted describing my proposals > for the IG, as well as the preliminary list of 'defects'. Comments > and questions are welcome. >=20 > Regards, >=20 > Jeff -- 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 From sigtran-bounces@ietf.org Wed Jan 11 16:53:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewnuj-0007Zr-2z; Wed, 11 Jan 2006 16:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewnuh-0007Zk-QK for sigtran@megatron.ietf.org; Wed, 11 Jan 2006 16:53:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17109 for ; Wed, 11 Jan 2006 16:52:30 -0500 (EST) Received: from [142.179.199.224] (helo=gw.openss7.com ident=[78ru9fpyD+B46ocFuCX4Oz/KKC+zgKqF]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewo1K-0001CM-Jd for sigtran@ietf.org; Wed, 11 Jan 2006 17:01:05 -0500 Received: from ns.pigworks.openss7.net (IDENT:7G38XQbUd+Kramc+CPfN35foXprMNQOD@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0BLqtw21616; Wed, 11 Jan 2006 14:52:55 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0BLqtY16682; Wed, 11 Jan 2006 14:52:55 -0700 Date: Wed, 11 Jan 2006 14:52:55 -0700 From: "Brian F. G. Bidulock" To: "Craig, Jeffrey" Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Message-ID: <20060111145255.A16599@openss7.org> Mail-Followup-To: "Craig, Jeffrey" , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E717026DA55E@DCEVS2.tekelec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <58292FA6B3EEFD49AEDAF6597E21E717026DA55E@DCEVS2.tekelec.com>; from Jeffrey.Craig@tekelec.com on Wed, Jan 11, 2006 at 03:32:17PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Jeffrey, Perhaps you could start by formulating at least a problem statement for each item that you think presents a problem. It might also be an idea to consult the authors of the RFC. Maybe start with PO and Figure 16. What problem is there with the text or the example? I don't see any problem. Also, I don't believe that there are any outstanding problems with the document at all. --brian Craig, Jeffrey wrote: (Wed, 11 Jan 2006 15:32:17) > Hello Brian, > > > and should not be the editor's personal pet peeve list for the > specification > > Personal pet peeves? Many of the defects I listed I obtained straight > from > other's posts on the SIGTRAN listserv. I posted them as a proposal to > kickoff > discussion. > > I look forward to other's comments. If the community agrees to your > strict > definition of 'defect' and that there are no M2PA 'defects', then there > won't be > a M2PA IG. If the only 'defect' is the processor outage text, then that > is what > the M2PA IG will address and nothing else. > > Regards, > > Jeff -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 12 13:42:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex7Ol-0000Iw-V2; Thu, 12 Jan 2006 13:42:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex7Ok-0000Io-VZ for sigtran@megatron.ietf.org; Thu, 12 Jan 2006 13:42:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07048 for ; Thu, 12 Jan 2006 13:40:50 -0500 (EST) Received: from smtp02.tekelec.com ([198.89.42.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex7Vr-0004gz-Uv for sigtran@ietf.org; Thu, 12 Jan 2006 13:49:35 -0500 Received: from dcex05.tekelec.com (dcex05.tekelec.com [172.28.104.65]) by smtp02.tekelec.com (8.12.10/8.12.10) with ESMTP id k0CIbZIP003660; Thu, 12 Jan 2006 12:37:35 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex05.tekelec.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 12:41:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Date: Thu, 12 Jan 2006 12:41:49 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E717026DAC00@DCEVS2.tekelec.com> Thread-Topic: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Thread-Index: AcYW+cMk1BG8mgsTSdy+sIQdHYYi8QArU6FA From: "Craig, Jeffrey" To: X-OriginalArrivalTime: 12 Jan 2006 18:41:50.0911 (UTC) FILETIME=[D9E26CF0:01C617A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Brian, Both Figures 15 and 16 are defective in that they fail to accurately depict the L3L2 and L2L3 primitives that are essential to the procedures being described. The processor outage section is defective in that it fails to adequately address the aligned not ready state. It also fails to adequately address the ambiguity in treatment of received LSR based upon stream. I am working on detailed problem descriptions and=20 proposed new text and new figures that addresses=20 my concerns. Stay tuned. As far as you not seeing any defects in the document, I am not surprised, since you were an author. I think the RFC can better serve its audience by being clear to everyone, not just the authors. Regards, Jeff=20 -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]=20 Sent: Wednesday, January 11, 2006 4:53 PM To: Craig, Jeffrey Cc: sigtran@ietf.org Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Jeffrey, Perhaps you could start by formulating at least a problem statement for each item that you think presents a problem. It might also be an idea to consult the authors of the RFC. Maybe start with PO and Figure 16. What problem is there with the text or the example? I don't see any problem. Also, I don't believe that there are any outstanding problems with the document at all. --brian Craig, Jeffrey wrote: (Wed, 11 Jan 2006 15:32:17) > Hello Brian, >=20 > > and should not be the editor's personal pet peeve list for the > specification >=20 > Personal pet peeves? Many of the defects I listed I obtained straight=20 > from other's posts on the SIGTRAN listserv. I posted them as a=20 > proposal to kickoff discussion. >=20 > I look forward to other's comments. If the community agrees to your=20 > strict definition of 'defect' and that there are no M2PA 'defects',=20 > then there won't be a M2PA IG. If the only 'defect' is the processor=20 > outage text, then that is what the M2PA IG will address and nothing=20 > else. >=20 > Regards, >=20 > Jeff -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 12 13:57:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex7di-0007NS-Kd; Thu, 12 Jan 2006 13:57:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex7dg-0007ND-U4 for sigtran@megatron.ietf.org; Thu, 12 Jan 2006 13:57:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08665 for ; Thu, 12 Jan 2006 13:56:15 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[lZMf0vkRW1194PcsSsB4yERns39DM+eE]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex7kq-0005Oe-5G for sigtran@ietf.org; Thu, 12 Jan 2006 14:05:01 -0500 Received: from ns.pigworks.openss7.net (IDENT:dcdY1OluIuGhR1v7JOBvqpVXMDkFZ6VI@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0CIvUw13655; Thu, 12 Jan 2006 11:57:30 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0CIvTe31137; Thu, 12 Jan 2006 11:57:29 -0700 Date: Thu, 12 Jan 2006 11:57:29 -0700 From: "Brian F. G. Bidulock" To: "Craig, Jeffrey" Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Message-ID: <20060112115729.A30954@openss7.org> Mail-Followup-To: "Craig, Jeffrey" , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E717026DAC00@DCEVS2.tekelec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <58292FA6B3EEFD49AEDAF6597E21E717026DAC00@DCEVS2.tekelec.com>; from Jeffrey.Craig@tekelec.com on Thu, Jan 12, 2006 at 12:41:49PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Craig, I hope your descriptions are less vague than they are in this note. I look forward to commenting on your draft. Perhaps you should call it draft-craig-m2pa-ig because it is already far from consensus. The RFC _is_ the current consensus. --brian Craig, Jeffrey wrote: (Thu, 12 Jan 2006 12:41:49) > Hello Brian, > > Both Figures 15 and 16 are defective in that they fail > to accurately depict the L3L2 and L2L3 primitives that > are essential to the procedures being described. > > The processor outage section is defective in that it > fails to adequately address the aligned not ready state. > It also fails to adequately address the ambiguity in > treatment of received LSR based upon stream. > > I am working on detailed problem descriptions and > proposed new text and new figures that addresses > my concerns. Stay tuned. > > As far as you not seeing any defects in the document, > I am not surprised, since you were an author. I think > the RFC can better serve its audience by being clear > to everyone, not just the authors. > > Regards, > > Jeff > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 12 18:30:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBuA-0002NQ-Me; Thu, 12 Jan 2006 18:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBu8-0002NI-Ag for sigtran@megatron.ietf.org; Thu, 12 Jan 2006 18:30:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05550 for ; Thu, 12 Jan 2006 18:29:31 -0500 (EST) Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExC1J-0008P8-Tw for sigtran@ietf.org; Thu, 12 Jan 2006 18:38:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Date: Thu, 12 Jan 2006 18:30:36 -0500 Message-ID: <0901D1988E815341A0103206A834DA07A5C237@mdmxm02.ciena.com> Thread-Topic: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Thread-Index: AcYXqv6zRFD5/U/DQjeObwVt1HwEiAAJGPOw From: "Ong, Lyndon" To: , "Craig, Jeffrey" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi Folks, Let's cool things down, please! Jeff's initial draft should in fact be draft-craig-sigtran-m2pa-ig since it will not yet have been agreed to be a WG draft. Our intention should be to identify any areas of M2PA that may lead to problems with interoperable implementations, based on our experience. This is different from saying the M2PA RFC is=20 "wrong" - Brian is perfectly correct that the RFC is the standing agreement. Cheers, Lyndon -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Brian F. G. Bidulock Sent: Thursday, January 12, 2006 10:57 AM To: Craig, Jeffrey Cc: sigtran@ietf.org Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Craig, I hope your descriptions are less vague than they are in this note. I look forward to commenting on your draft. Perhaps you should call it draft-craig-m2pa-ig because it is already far from consensus. The RFC _is_ the current consensus. --brian Craig, Jeffrey wrote: (Thu, 12 Jan 2006 12:41:49) > Hello Brian, >=20 > Both Figures 15 and 16 are defective in that they fail to accurately=20 > depict the L3L2 and L2L3 primitives that are essential to the=20 > procedures being described. >=20 > The processor outage section is defective in that it fails to=20 > adequately address the aligned not ready state. > It also fails to adequately address the ambiguity in treatment of=20 > received LSR based upon stream. >=20 > I am working on detailed problem descriptions and proposed new text=20 > and new figures that addresses my concerns. Stay tuned. >=20 > As far as you not seeing any defects in the document, I am not=20 > surprised, since you were an author. I think the RFC can better serve=20 > its audience by being clear to everyone, not just the authors. >=20 > Regards, >=20 > Jeff >=20 --=20 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 From sigtran-bounces@ietf.org Fri Jan 13 11:25:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRk6-0006FH-3C; Fri, 13 Jan 2006 11:25:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRk4-0006EV-CC for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 11:25:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19607 for ; Fri, 13 Jan 2006 11:24:09 -0500 (EST) Received: from web35414.mail.mud.yahoo.com ([66.163.179.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExRrN-0002AX-27 for sigtran@ietf.org; Fri, 13 Jan 2006 11:33:08 -0500 Received: (qmail 82556 invoked by uid 60001); 13 Jan 2006 16:24:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bDg1PCSgDkffKIfp/6g/xm+LzO8AJ9TAmQjT7XnbJpNiLxdNXBcvdbf0stXFK8hr8LaAzDnf/RE9emBuz2kVntN5HNMIvGQZptVpDI5X7DNG8xp9YtQkTZsNPDZG9SPmE/7grgV7hzT5LvgADxxGbOW1XEa4DnR7qJdLYI+avJs= ; Message-ID: <20060113162404.82554.qmail@web35414.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35414.mail.mud.yahoo.com via HTTP; Fri, 13 Jan 2006 08:24:04 PST Date: Fri, 13 Jan 2006 08:24:04 -0800 (PST) From: Stanislav Ivanovich To: SIGTRAN MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [Sigtran] Some very fundamental SIGTRAN question X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1779084233==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1779084233== Content-Type: multipart/alternative; boundary="0-1156188548-1137169444=:75829" Content-Transfer-Encoding: 8bit --0-1156188548-1137169444=:75829 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello SIGTRAN community, I have a very serious dispute with my colleague about very fundamental point of the SIGTRAN xxUA protocols. Although I know the answer to the following question I am sending it to the SIGTRAN forum just to have some sort of argument and official proof. Therefore I kindly ask you to give a judgment on whose standpoint is correct: My colleague's view: 1) xxUA concepts are concepts of transmission related functions since M3UA replaces MTP and SUA replaces SCCP 2) Because of point 1 above xxUA specifications do mandate (!) a box/layer which is to contain all the xxUA concepts (AS, RK, SGP, ASP, IPSP...) so that application entities and operations of these are completely non-related to xxUA entities and operations Example: ASP/IPSP is object in the xxUA layer/box and operation of it is done in that box -> always (!) and this is not subject to vendor/implementor's choice. Therefore they do not represent application instances/clones. 3) Because of point 1 AS is not application but address (or set of SS7 addresses) therefore AS concept belongs to transport stack not to application layers 4) Because of point 1 ASP/IPSP is transmission resource since it is visible as endpoint (set of IP addresses + port number) therefore ASP/IPSP concept belongs to transport stack not to application layers 5) xxUA protocols are protocols designed to solve transmission related problems (like having multiple IP addresses used for different directions, scale transmission capacity in case a SCTP host is limited in capacity etc...) 6) Management of all the xxUA entities is done in LM of the xxUA box/layer according to xxUA specifications and this is not application management and it is not in implementor's choice! My view: 1) xxUA specifications do not specify (or mandate!) any box/layer especially not one which is to perform or address transmission related functions. Instead xxUA specifications specify only two protocols (namely SGP-ASP and IPSP-IPSP) which are originally designed/tailored to address application (not transmission!) redundancy. Everything inside (ASP/IPSP/SGP) is implementor's choice and certainly not specified mandated in xxUA specifications. I.e. xxUA specifications do not forbid an implementor to implement a layered structure within an ASP/IPSP process but with respect to specifications it is the matter of implementation and not subject to specifications. 2) In the SIGTRAN concept transmssion related problems are addressed by SCTP/IP/Ethernet... and underlying function/mechanisms/tools. Of course rapping of principles is possible thus one can see an Ethernet board as ASP/IPSP so addrsssing transmission redundacy is visible on the xxUA protocls (i.e. new Ethernet boards imply new ASP_ID's) but this is not for what xxUA protocls are originally designed for! Originally addressing transmssion related problems should not reflect on the xxUA protocol. 3) AS is not an SS7 address but application (i.e. functionality)! The fact that AS has SS7 address(es) in order to be externally visible certainly does not imply that AS itself is an SS7 address (or set of addresses).Therefore the concept of AS is certainly not transmission layer concept! 4) ASP/IPSP are application processes i.e. application clones. In other words ASP/IPSP is container into which you load your application (or part of it) - to be illustratvie into which you load program code which represents AS (or several AS'es). The fact ASP/IPSP has an endpoint in order to be externally visible certainly does not imply that ASP/IPSP itself is an endpoint. Therefore the concept of ASP/IPSP is certainly not transmission layer concept! 5) AS granularity, AS management and AS redundancy are all in application designer responsibility! This is already the case in legacy systems. If applications want reliability then they support multiple instances (clones, processes... whatever you call them) of their logic. This is not the task of transmission layers. 6) SUA and M3UA both say in section 1.2 "Terminology" - "Application Server Process (ASP) - An Application Server Process serves as an active or backup process of an Application Server" - "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-peer fashion." Therefore ASP/IPSP'es are clones of appliccations and not some entities in a magic box/layer thus not related to applications -> if one does not want application clones he/she does not need several ASP/IPSP'es. Originally in the spirit of xxUA specifications! Again, raping of prinipcles is possible (e.g. an Ethernet board maybe can be an IPSP/ASP so having many boards implies many ASP/IPSP'es and at the same time only one application insatnce) but I want to know what is it originally designed/tailored for! Whose opinion is correct? Many thanks! best regards/ Stanislav Ivanovich --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1156188548-1137169444=:75829 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello SIGTRAN community,
 
I have a very serious dispute with my colleague about very fundamental point of the SIGTRAN xxUA protocols. Although I know the answer to the following question I am sending it to the SIGTRAN forum just to have some sort of argument and official proof. Therefore I kindly ask you to give a judgment on whose standpoint is correct:
 
My colleague's view:
 
1) xxUA concepts are concepts of transmission related functions since M3UA replaces MTP and SUA replaces SCCP
 
2) Because of point 1 above xxUA specifications do mandate (!) a box/layer which is to contain all the xxUA concepts (AS, RK, SGP, ASP, IPSP...) so that application entities and operations of these are completely non-related to xxUA entities and operations
 
Example: ASP/IPSP is object in the xxUA laye! r/box and operation of it is done in that box -> always (!) and this is not subject to vendor/implementor's choice. Therefore they do not represent application instances/clones.
 
3) Because of point 1 AS is not application but address (or set of SS7 addresses) therefore AS concept belongs to transport stack not to application layers
 
4) Because of point 1 ASP/IPSP is transmission resource since it is visible as endpoint (set of IP addresses + port number) therefore ASP/IPSP concept belongs to transport stack not to application layers
 
5) xxUA protocols are protocols designed to solve transmission related problems (like having multiple IP addresses used for different directions, scale transmission capacity in case a SCTP host is limited in capacity etc...)
 
6) Management of all the xxUA entities is done in LM of the xxUA box/layer according to xxUA specifications and this! is not application management and it is not in implementor's choice!
 
 
 
My view:
 
1) xxUA specifications do not specify (or mandate!) any box/layer especially not one which is to perform or address transmission related functions. Instead xxUA specifications specify only two protocols (namely SGP-ASP and IPSP-IPSP) which are originally designed/tailored to address application (not transmission!) redundancy. Everything inside (ASP/IPSP/SGP) is implementor's choice and certainly not specified mandated in xxUA specifications. I.e. xxUA specifications do not forbid an implementor to implement a layered structure within an ASP/IPSP process but with respect to specifications it is the matter of implementation and not subject to specifications.
 
2)  In the SIGTRAN concept transmssion related problems are addressed by SCTP/IP/Ethernet... and underlying function/mechanisms/tools.
Of course rapping of principles is possible thus one can see an Ethernet board as ASP/IPSP so addrsssing transmission redundacy is visible on the xxUA protocls (i.e. new Ethernet boards imply new ASP_ID's) but this is not for what xxUA protocls are originally designed for!
Originally addressing transmssion related problems should not reflect on the xxUA protocol.
 
3) AS is not an SS7 address but application (i.e. functionality)!
The fact that AS has SS7 address(es) in order to be externally visible certainly does not imply that AS itself is an SS7 address (or set of addresses).Therefore the concept of AS is certainly not transmission layer concept!
 
4) ASP/IPSP are application processes i.e. application clones.
In other words ASP/IPSP is container into which you load your application (or part of it) - to be illustratvie into which you load program ! code which represents AS (or several AS'es).
The fact ASP/IPSP has an endpoint in order to be externally visible certainly does not imply that ASP/IPSP itself is an endpoint. Therefore the concept of ASP/IPSP is certainly not transmission layer concept!
 
5) AS granularity, AS management and AS redundancy are all in application designer responsibility!
This is already the case in legacy systems. If applications want reliability then they support multiple instances (clones, processes... whatever you call them) of their logic. This is not the task of transmission layers.
 
6) SUA and M3UA both say in section 1.2 "Terminology"
 
- "Application Server Process (ASP) - An Application Server Process serves as an active or backup process of an Application Server"
- "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-p! eer fashion."
Therefore ASP/IPSP'es are clones of appliccations and not some entities in a magic box/layer thus not related to applications -> if one does not want application clones he/she does not need several ASP/IPSP'es. Originally in the spirit of xxUA specifications!
 
Again, raping of prinipcles is possible (e.g. an Ethernet board maybe can be an IPSP/ASP so having many boards implies many ASP/IPSP'es and at the same time only one application insatnce) but I want to know what is it originally designed/tailored for!
 
Whose opinion is correct?
 
Many thanks!
 
best regards/ Stanislav Ivanovich
 

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1156188548-1137169444=:75829-- --===============1779084233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1779084233==-- From sigtran-bounces@ietf.org Fri Jan 13 12:22:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExSdb-0004I9-W4; Fri, 13 Jan 2006 12:22:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExSdZ-0004Eg-Hx for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 12:22:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23313 for ; Fri, 13 Jan 2006 12:21:30 -0500 (EST) Received: from phl-28-b-170.phl.dsl.cerfnet.com ([63.242.157.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExSku-00044C-JH for sigtran@ietf.org; Fri, 13 Jan 2006 12:30:29 -0500 Received: from bn001320 (bn001320 [192.168.1.61]) by phl-28-b-170.phl.dsl.cerfnet.com (8.12.8/8.12.8) with SMTP id k0DHMeoj029312 for ; Fri, 13 Jan 2006 12:22:40 -0500 From: "Barry Nagelberg" To: "SIGTRAN" Subject: RE: [Sigtran] Some very fundamental SIGTRAN question Date: Fri, 13 Jan 2006 12:24:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060113162404.82554.qmail@web35414.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, 1) Your colleague is correct. xUA is a SIGnalling TRANsport (SIGTRAN) protocol, designed to transport legacy SS7 signalling over modern packet networks. Nothing more and nothing less. Your definition has several errors: a) SGP/ASP/IPSP aren't protocols. They are network elements. b) Not "everything inside (ASP/IPSP/SGP) is implementor's choice". There are many "MUSTS" and "MUST NOTS" in the specs. 2) Your colleague is wrong. No particular layers are mandated by the xUA spec. There are some RECOMMENDED layers, such as SCTP and Layer Manager, but the internal implementation is not MANDATED. You are also wrong. The xUA protocols must be concerned with transmission of traffic. xUA, as an SCTP-user, must supervise and control the operation of the SCTP layer. 3) You are both correct. At the SGP, the AS is essentially an addressing concept. At the ASP, the AS is essentially an application concept. 4) You are both correct. At the SGP, the ASP is a transport concept (there is a 1:1 relationship between ASP and SCTP association). At the ASP, the concept of ASP is an instantiation of an AS. 5) You are both correct. xUA handles transport. At the ASP, xUA handles granularity of Application Services - for example, how many instantiations, or ASPs, are necessary to handle the traffic for an Application Server. 6) Your colleague is wrong. The interaction between Layer Manager and xUA is simply a recommendation. It's not a mandatory part of the spec. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Friday, January 13, 2006 11:24 AM To: SIGTRAN Subject: [Sigtran] Some very fundamental SIGTRAN question Hello SIGTRAN community, I have a very serious dispute with my colleague about very fundamental point of the SIGTRAN xxUA protocols. Although I know the answer to the following question I am sending it to the SIGTRAN forum just to have some sort of argument and official proof. Therefore I kindly ask you to give a judgment on whose standpoint is correct: My colleague's view: 1) xxUA concepts are concepts of transmission related functions since M3UA replaces MTP and SUA replaces SCCP 2) Because of point 1 above xxUA specifications do mandate (!) a box/layer which is to contain all the xxUA concepts (AS, RK, SGP, ASP, IPSP...) so that application entities and operations of these are completely non-related to xxUA entities and operations Example: ASP/IPSP is object in the xxUA laye! r/box and operation of it is done in that box -> always (!) and this is not subject to vendor/implementor's choice. Therefore they do not represent application instances/clones. 3) Because of point 1 AS is not application but address (or set of SS7 addresses) therefore AS concept belongs to transport stack not to application layers 4) Because of point 1 ASP/IPSP is transmission resource since it is visible as endpoint (set of IP addresses + port number) therefore ASP/IPSP concept belongs to transport stack not to application layers 5) xxUA protocols are protocols designed to solve transmission related problems (like having multiple IP addresses used for different directions, scale transmission capacity in case a SCTP host is limited in capacity etc...) 6) Management of all the xxUA entities is done in LM of the xxUA box/layer according to xxUA specifications and this! is not application management and it is not in implementor's choice! My view: 1) xxUA specifications do not specify (or mandate!) any box/layer especially not one which is to perform or address transmission related functions. Instead xxUA specifications specify only two protocols (namely SGP-ASP and IPSP-IPSP) which are originally designed/tailored to address application (not transmission!) redundancy. Everything inside (ASP/IPSP/SGP) is implementor's choice and certainly not specified mandated in xxUA specifications. I.e. xxUA specifications do not forbid an implementor to implement a layered structure within an ASP/IPSP process but with respect to specifications it is the matter of implementation and not subject to specifications. 2) In the SIGTRAN concept transmssion related problems are addressed by SCTP/IP/Ethernet... and underlying function/mechanisms/tools. Of course rapping of principles is possible thus one can see an Ethernet board as ASP/IPSP so addrsssing transmission redundacy is visible on the xxUA protocls (i.e. new Ethernet boards imply new ASP_ID's) but this is not for what xxUA protocls are originally designed for! Originally addressing transmssion related problems should not reflect on the xxUA protocol. 3) AS is not an SS7 address but application (i.e. functionality)! The fact that AS has SS7 address(es) in order to be externally visible certainly does not imply that AS itself is an SS7 address (or set of addresses).Therefore the concept of AS is certainly not transmission layer concept! 4) ASP/IPSP are application processes i.e. application clones. In other words ASP/IPSP is container into which you load your application (or part of it) - to be illustratvie into which you load program ! code which represents AS (or several AS'es). The fact ASP/IPSP has an endpoint in order to be externally visible certainly does not imply that ASP/IPSP itself is an endpoint. Therefore the concept of ASP/IPSP is certainly not transmission layer concept! 5) AS granularity, AS management and AS redundancy are all in application designer responsibility! This is already the case in legacy systems. If applications want reliability then they support multiple instances (clones, processes... whatever you call them) of their logic. This is not the task of transmission layers. 6) SUA and M3UA both say in section 1.2 "Terminology" - "Application Server Process (ASP) - An Application Server Process serves as an active or backup process of an Application Server" - "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-p! eer fashion." Therefore ASP/IPSP'es are clones of appliccations and not some entities in a magic box/layer thus not related to applications -> if one does not want application clones he/she does not need several ASP/IPSP'es. Originally in the spirit of xxUA specifications! Again, raping of prinipcles is possible (e.g. an Ethernet board maybe can be an IPSP/ASP so having many boards implies many ASP/IPSP'es and at the same time only one application insatnce) but I want to know what is it originally designed/tailored for! Whose opinion is correct? Many thanks! best regards/ Stanislav Ivanovich Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 13 12:49:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExT31-0002O1-Q9; Fri, 13 Jan 2006 12:49:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExT30-0002Nt-Jm for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 12:49:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24744 for ; Fri, 13 Jan 2006 12:47:49 -0500 (EST) Received: from web35404.mail.mud.yahoo.com ([66.163.179.113]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExTAM-0004uA-67 for sigtran@ietf.org; Fri, 13 Jan 2006 12:56:47 -0500 Received: (qmail 12718 invoked by uid 60001); 13 Jan 2006 17:49:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gBz5YtfVDZwOymAn4C+L0lzT9oUtvVWcwZLk3EjsOh3JYsS4dXlSwJDE1DJeHdXiQZGJ78TGxv2hpIZNg95cqyt7pWfa5REOz7BrmYmvjqJliZYEZs39j5MAI/4W0QTZOX71z3dIDz2HcLbq3xsQyWuM1AusI1o0p1KXDN/e+pA= ; Message-ID: <20060113174900.12715.qmail@web35404.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35404.mail.mud.yahoo.com via HTTP; Fri, 13 Jan 2006 09:49:00 PST Date: Fri, 13 Jan 2006 09:49:00 -0800 (PST) From: Stanislav Ivanovich Subject: RE: [Sigtran] Some very fundamental SIGTRAN question To: SIGTRAN In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0826679228==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0826679228== Content-Type: multipart/alternative; boundary="0-437135907-1137174540=:12668" Content-Transfer-Encoding: 8bit --0-437135907-1137174540=:12668 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Barry, First, thank you for yopur reply however seeing your answers I think that you didn't understand my view: I kindly ask you to look into my comments below and possibly reconsider your answers. many thanks and regards/ Stanislav Ivanovich Barry Nagelberg wrote: Stanislav, 1) Your colleague is correct. xUA is a SIGnalling TRANsport (SIGTRAN) protocol, designed to transport legacy SS7 signalling over modern packet networks. Nothing more and nothing less. ------------------------------------------------------------------ [Stanisalv Ivanovich] I do not question that SIGTRAN does address transport functions. However I have just said thatSIGTRAN concept you address these functions by SCTP and lower layers. xxUA protols (M3UA, SUA) do not solve transssion problems. ------------------------------------------------------------------ Your definition has several errors: a) SGP/ASP/IPSP aren't protocols. They are network elements. ------------------------------------------------------------------ [Stanisalv Ivanovich] You haven't understood my point. I do not question that ASP/IPSP/SGP'es are entities. Of course they are! What I said is that xxUA specifications specify only protocols between these entities without specifying internal SIgnalling Process structure. ------------------------------------------------------------------ b) Not "everything inside (ASP/IPSP/SGP) is implementor's choice". There are many "MUSTS" and "MUST NOTS" in the specs. ------------------------------------------------------------------ [Stanisalv Ivanovich] This is true and I do not question that! What I said is that xxUA specifications do not manadate internal ASP/IPSP layering structure but only external behavior of these entities! ------------------------------------------------------------------- 2) Your colleague is wrong. No particular layers are mandated by the xUA spec. There are some RECOMMENDED layers, such as SCTP and Layer Manager, but the internal implementation is not MANDATED. You are also wrong. The xUA protocols must be concerned with transmission of traffic. xUA, as an SCTP-user, must supervise and control the operation of the SCTP layer. ------------------------------------------------------------------- [Stanisalv Ivanovich] My point is -> ASP/IPSP is a user function. Of course it uses SCTP and it has to address interaction with it. However internal ASP/IPSP structure is irrelevant for the xxUA specificatons. This is all what I have said. ------------------------------------------------------------------- 3) You are both correct. At the SGP, the AS is essentially an addressing concept. At the ASP, the AS is essentially an application concept. ------------------------------------------------------------------- [Stanisalv Ivanovich] I think we cannot be both correct since these are contradictory statements. SS7 address is not application which you load into a process. My colleagues point is that AS is not application but SS7 address (or set of addressses) my point is that eventohugh AS has SS7 address it is not that (afterall AS has also RC). Anyway AS is an application (i.e. user function) that you load into a application process. ------------------------------------------------------------------- 4) You are both correct. At the SGP, the ASP is a transport concept (there is a 1:1 relationship between ASP and SCTP association). At the ASP, the concept of ASP is an instantiation of an AS. ------------------------------------------------------------------- [Stanisalv Ivanovich] I think we cannot be both correct since these are contradictory statements. Againmy point is -> if ASP/IPSP has endpoint it is not one. Endpoints are entities maintained in SCTP. ASP/IPSP is a process into which you load an application (AS) and which youi bind to an endpoint. Just because you bind it to a endpoint does not mean that ASP/IPSP is endpoint -> endpoitns are maintained in SCTP! ------------------------------------------------------------------- 5) You are both correct. xUA handles transport. At the ASP, xUA handles granularity of Application Services - for example, how many instantiations, or ASPs, are necessary to handle the traffic for an Application Server. ------------------------------------------------------------------- [Stanisalv Ivanovich] I do not quite understand you here. Are you telling me that M3UA or SUA protocls are desinged for adding extra trnasmsion resources??? So by adding new Ethernet boards is reflected on xxUA protocol? ------------------------------------------------------------------- 6) Your colleague is wrong. The interaction between Layer Manager and xUA is simply a recommendation. It's not a mandatory part of the spec. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Friday, January 13, 2006 11:24 AM To: SIGTRAN Subject: [Sigtran] Some very fundamental SIGTRAN question Hello SIGTRAN community, I have a very serious dispute with my colleague about very fundamental point of the SIGTRAN xxUA protocols. Although I know the answer to the following question I am sending it to the SIGTRAN forum just to have some sort of argument and official proof. Therefore I kindly ask you to give a judgment on whose standpoint is correct: My colleague's view: 1) xxUA concepts are concepts of transmission related functions since M3UA replaces MTP and SUA replaces SCCP 2) Because of point 1 above xxUA specifications do mandate (!) a box/layer which is to contain all the xxUA concepts (AS, RK, SGP, ASP, IPSP...) so that application entities and operations of these are completely non-related to xxUA entities and operations Example: ASP/IPSP is object in the xxUA laye! r/box and operation of it is done in that box -> always (!) and this is not subject to vendor/implementor's choice. Therefore they do not represent application instances/clones. 3) Because of point 1 AS is not application but address (or set of SS7 addresses) therefore AS concept belongs to transport stack not to application layers 4) Because of point 1 ASP/IPSP is transmission resource since it is visible as endpoint (set of IP addresses + port number) therefore ASP/IPSP concept belongs to transport stack not to application layers 5) xxUA protocols are protocols designed to solve transmission related problems (like having multiple IP addresses used for different directions, scale transmission capacity in case a SCTP host is limited in capacity etc...) 6) Management of all the xxUA entities is done in LM of the xxUA box/layer according to xxUA specifications and this! is not application management and it is not in implementor's choice! My view: 1) xxUA specifications do not specify (or mandate!) any box/layer especially not one which is to perform or address transmission related functions. Instead xxUA specifications specify only two protocols (namely SGP-ASP and IPSP-IPSP) which are originally designed/tailored to address application (not transmission!) redundancy. Everything inside (ASP/IPSP/SGP) is implementor's choice and certainly not specified mandated in xxUA specifications. I.e. xxUA specifications do not forbid an implementor to implement a layered structure within an ASP/IPSP process but with respect to specifications it is the matter of implementation and not subject to specifications. 2) In the SIGTRAN concept transmssion related problems are addressed by SCTP/IP/Ethernet... and underlying function/mechanisms/tools. Of course rapping of principles is possible thus one can see an Ethernet board as ASP/IPSP so addrsssing transmission redundacy is visible on the xxUA protocls (i.e. new Ethernet boards imply new ASP_ID's) but this is not for what xxUA protocls are originally designed for! Originally addressing transmssion related problems should not reflect on the xxUA protocol. 3) AS is not an SS7 address but application (i.e. functionality)! The fact that AS has SS7 address(es) in order to be externally visible certainly does not imply that AS itself is an SS7 address (or set of addresses).Therefore the concept of AS is certainly not transmission layer concept! 4) ASP/IPSP are application processes i.e. application clones. In other words ASP/IPSP is container into which you load your application (or part of it) - to be illustratvie into which you load program ! code which represents AS (or several AS'es). The fact ASP/IPSP has an endpoint in order to be externally visible certainly does not imply that ASP/IPSP itself is an endpoint. Therefore the concept of ASP/IPSP is certainly not transmission layer concept! 5) AS granularity, AS management and AS redundancy are all in application designer responsibility! This is already the case in legacy systems. If applications want reliability then they support multiple instances (clones, processes... whatever you call them) of their logic. This is not the task of transmission layers. 6) SUA and M3UA both say in section 1.2 "Terminology" - "Application Server Process (ASP) - An Application Server Process serves as an active or backup process of an Application Server" - "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-p! eer fashion." Therefore ASP/IPSP'es are clones of appliccations and not some entities in a magic box/layer thus not related to applications -> if one does not want application clones he/she does not need several ASP/IPSP'es. Originally in the spirit of xxUA specifications! Again, raping of prinipcles is possible (e.g. an Ethernet board maybe can be an IPSP/ASP so having many boards implies many ASP/IPSP'es and at the same time only one application insatnce) but I want to know what is it originally designed/tailored for! Whose opinion is correct? Many thanks! best regards/ Stanislav Ivanovich Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-437135907-1137174540=:12668 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Barry,
 
First, thank you for yopur reply however seeing your answers I think that you didn't understand my view:
 
I kindly ask you to look into my comments below and possibly reconsider your answers.
 
many thanks and regards/ Stanislav Ivanovich
 

Barry Nagelberg <barryn@adax.com> wrote:
Stanislav,

1) Your colleague is correct. xUA is a SIGnalling TRANsport (SIGTRAN) protocol, designed to transport legacy SS7
signalling over modern packet networks. Nothing more and nothing less.
------------------------------------------------------------------
[Stanisalv Ivanovich] I do not question that SIGTRAN does address transport functions. However I have just said thatSIGTRAN concept yo! u address these functions by SCTP and lower layers. xxUA protols (M3UA, SUA) do not solve transssion problems.
------------------------------------------------------------------

Your definition has several errors:
a) SGP/ASP/IPSP aren't protocols. They are network elements.
------------------------------------------------------------------
[Stanisalv Ivanovich] You haven't understood my point. I do not question that ASP/IPSP/SGP'es are entities. Of course they are!
What I said is that xxUA specifications specify only protocols between these entities without specifying internal SIgnalling Process structure.
------------------------------------------------------------------

b) Not "everything inside (ASP/IPSP/SGP) is implementor's choice". There are many "MUSTS" and "MUST NOTS" in the specs.
------------------------------------------------------------------
[Stanisalv Ivanovich] This is true and I do not question that! What I said is that xxUA specifications do not manadate internal ASP/IPSP layering structure but only external behavior of these entities!
-------------------------------------------------------------------

2) Your colleague is wrong. No particular layers are mandated by the xUA spec. There are some RECOMMENDED layers, such
as SCTP and Layer Manager, but the internal implementation is not MANDATED.

You are also wrong. The xUA protocols must be concerned with transmission of traffic. xUA, as an SCTP-user, must
supervise and control the operation of the SCTP layer.
 
-------------------------------------------------------------------
[Stanisalv Ivanovich] My point is -> ASP/IPSP is a user function. Of course it uses SCTP and it has to address interaction with it. However internal ASP/IPSP structure is irrelevant for the xxUA specificatons. This is al! l what I have said.
-------------------------------------------------------------------

3) You are both correct. At the SGP, the AS is essentially an addressing concept. At the ASP, the AS is essentially an
application concept.
-------------------------------------------------------------------
[Stanisalv Ivanovich] I think we cannot be both correct since these are contradictory statements. SS7 address is not application which you load into a process. My colleagues point is that AS is not application but SS7 address (or set of addressses) my point is that eventohugh AS has SS7 address it is not that (afterall AS has also RC). Anyway AS is an application (i.e. user function) that you load into a application process.
-------------------------------------------------------------------
 
4) You are both correct. At the SGP, the ASP is a transport concept (there is a 1:1 relationship between A! SP and SCTP
association). At the ASP, the concept of ASP is an instantiation of an AS.
-------------------------------------------------------------------
[Stanisalv Ivanovich] I think we cannot be both correct since these are contradictory statements. Againmy point is -> if ASP/IPSP has endpoint it is not one. Endpoints are entities maintained in SCTP. ASP/IPSP is a process into which you load an application (AS) and which youi bind to an endpoint. Just because you bind it to a endpoint does not mean that ASP/IPSP is endpoint -> endpoitns are maintained in SCTP!
-------------------------------------------------------------------

5) You are both correct. xUA handles transport. At the ASP, xUA handles granularity of Application Services - for
example, how many instantiations, or ASPs, are necessary to handle the traffic for an Application Server.
-------------------------------------------------------------------
[Stanisalv Ivanovich] I do not quite understand you here.
Are you telling me that M3UA or SUA protocls are desinged for adding extra trnasmsion resources???
So by adding new Ethernet boards is reflected on xxUA protocol?
-------------------------------------------------------------------
 
6) Your colleague is wrong. The interaction between Layer Manager and xUA is simply a recommendation. It's not a
mandatory part of the spec.

Barry Nagelberg
Adax, Inc.

-----Original Message-----
From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich
Sent: Friday, January 13, 2006 11:24 AM
To: SIGTRAN
Subject: [Sigtran] Some very fundamental SIGTRAN question


Hello SIGTRAN community,

I have a very serious dispute with my colleague about very fundamental! point of the SIGTRAN xxUA protocols. Although I
know the answer to the following question I am sending it to the SIGTRAN forum just to have some sort of argument and
official proof. Therefore I kindly ask you to give a judgment on whose standpoint is correct:

My colleague's view:

1) xxUA concepts are concepts of transmission related functions since M3UA replaces MTP and SUA replaces SCCP

2) Because of point 1 above xxUA specifications do mandate (!) a box/layer which is to contain all the xxUA concepts
(AS, RK, SGP, ASP, IPSP...) so that application entities and operations of these are completely non-related to xxUA
entities and operations

Example: ASP/IPSP is object in the xxUA laye! r/box and operation of it is done in that box -> always (!) and this is
not subject to vendor/implementor's choice. Therefore they do not represent application instances/clones.

3) Because of point 1 AS is not application but address (or set of SS7 a! ddresses) therefore AS concept belongs to
transport stack not to application layers

4) Because of point 1 ASP/IPSP is transmission resource since it is visible as endpoint (set of IP addresses + port
number) therefore ASP/IPSP concept belongs to transport stack not to application layers


5) xxUA protocols are protocols designed to solve transmission related problems (like having multiple IP addresses used
for different directions, scale transmission capacity in case a SCTP host is limited in capacity etc...)

6) Management of all the xxUA entities is done in LM of the xxUA box/layer according to xxUA specifications and this! is
not application management and it is not in implementor's choice!



My view:

1) xxUA specifications do not specify (or mandate!) any box/layer especially not one which is to perform or address
transmission related functions. Instead xxUA specifications specify only two protocols (namely SGP-ASP and IPSP-IPSP)
which are originally designed/tailored to address application (not transmission!) redundancy. Everything inside
(ASP/IPSP/SGP) is implementor's choice and certainly not specified mandated in xxUA specifications. I.e. xxUA
specifications do not forbid an implementor to implement a layered structure within an ASP/IPSP process but with respect
to specifications it is the matter of implementation and not subject to specifications.

2) In the SIGTRAN concept transmssion related problems are addressed by SCTP/IP/Ethernet... and underlying
function/mechanisms/tools.
Of course rapping of principles is possible thus one can see an Ethernet board as ASP/IPSP so addrsssing transmission
redundacy is visible on the xxUA protocls (i.e. new Ethernet boards imply new ASP_ID's) but this is not for what xxUA
protocls are originally designed for!
Originally addressing transmssion related problems should not reflect on the xxUA protocol.

3) AS! is not an SS7 address but application (i.e. functionality)!
The fact that AS has SS7 address(es) in order to be externally visible certainly does not imply that AS itself is an SS7
address (or set of addresses).Therefore the concept of AS is certainly not transmission layer concept!

4) ASP/IPSP are application processes i.e. application clones.
In other words ASP/IPSP is container into which you load your application (or part of it) - to be illustratvie into
which you load program ! code which represents AS (or several AS'es).
The fact ASP/IPSP has an endpoint in order to be externally visible certainly does not imply that ASP/IPSP itself is an
endpoint. Therefore the concept of ASP/IPSP is certainly not transmission layer concept!

5) AS granularity, AS management and AS redundancy are all in application designer responsibility!
This is already the case in legacy systems. If applications want reliability then they support multiple instances
(c! lones, processes... whatever you call them) of their logic. This is not the task of transmission layers.

6) SUA and M3UA both say in section 1.2 "Terminology"

- "Application Server Process (ASP) - An Application Server Process serves as an active or backup process of an
Application Server"
- "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP,
except that it uses SUA in a peer-to-p! eer fashion."

Therefore ASP/IPSP'es are clones of appliccations and not some entities in a magic box/layer thus not related to
applications -> if one does not want application clones he/she does not need several ASP/IPSP'es. Originally in the
spirit of xxUA specifications!

Again, raping of prinipcles is possible (e.g. an Ethernet board maybe can be an IPSP/ASP so having many boards implies
many ASP/IPSP'es and at the same time only one application insatnce) but I want to know what is it originally
designed/tailored for!

Whose opinion is correct?

Many thanks!

best regards/ Stanislav Ivanovich



Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.


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

Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-437135907-1137174540=:12668-- --===============0826679228== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0826679228==-- From sigtran-bounces@ietf.org Fri Jan 13 13:16:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTTu-0008O1-W3; Fri, 13 Jan 2006 13:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTTs-0008Nn-LR for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 13:16:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26355 for ; Fri, 13 Jan 2006 13:15:35 -0500 (EST) Received: from ottgw.pt.com ([206.191.2.130] helo=krang.ottawa.pt.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExTbC-0005nY-SX for sigtran@ietf.org; Fri, 13 Jan 2006 13:24:33 -0500 Received: from [207.81.15.208] (lucius.ottawa.pt.com [207.81.15.208]) by krang.ottawa.pt.com (8.12.8/8.12.8) with ESMTP id k0DIGJIM025377; Fri, 13 Jan 2006 13:16:24 -0500 Message-ID: <43C7EEE9.4070505@pt.com> Date: Fri, 13 Jan 2006 13:18:17 -0500 From: Andrew Booth User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ong, Lyndon" Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff References: <0901D1988E815341A0103206A834DA07A5C237@mdmxm02.ciena.com> In-Reply-To: <0901D1988E815341A0103206A834DA07A5C237@mdmxm02.ciena.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: sigtran@ietf.org, bidulock@openss7.org, "Craig, Jeffrey" X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi Lyndon, Thanks for clarifying the path forward. So far I've heard comments downplaying the need for an Implementor's Guide. For what it's worth, I think an M2PA Implementor's Guide is a worthwhile effort. I think the current RFC is good, but there are areas that are hard to understand. This is especially true of the processor outage section. I think some clarifications could make the protocol easier to implement, which should mean fewer incorrect implementations, which would help interoperability. Additional examples or deployment considerations could also help. It may also be appropriate to add requirements to M2PA implementations, I'm thinking in particular in explicitly specifying how long an implementation should wait for LS READY at the end of processor outage. It looks like this is already contained in Jeff's list, so I expect it will be discussed in due course and either accepted or not. As a closing note, I know that internally our interpretation of the M2PA spec was not painless. There were a number of cases where we spent hours looking through Q.703, through the RFC, and considering and generating test cases (we didn't find the latest draft of the test spec at the time). In the end there were a number of decisions that we took that involved a reasonable amount of deduction. Sometimes ambiguity is good, in that it doesn't constrain implementations, other times it just makes it hard to know if you're doing the right thing. I think an I-G could help ease the pain of future generations of M2PA developers. Regards, Andrew Ong, Lyndon wrote: >Hi Folks, > >Let's cool things down, please! Jeff's initial draft should in fact >be draft-craig-sigtran-m2pa-ig since it will not yet have been agreed to >be a WG draft. Our intention should be to identify any areas of M2PA >that may lead to problems with interoperable implementations, based >on our experience. This is different from saying the M2PA RFC is >"wrong" - Brian is perfectly correct that the RFC is the standing >agreement. > >Cheers, > >Lyndon > >-----Original Message----- >From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On >Behalf Of Brian F. G. Bidulock >Sent: Thursday, January 12, 2006 10:57 AM >To: Craig, Jeffrey >Cc: sigtran@ietf.org >Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff > >Craig, > >I hope your descriptions are less vague than they are in this note. I >look forward to commenting on your draft. Perhaps you should call it >draft-craig-m2pa-ig because it is already far from consensus. The RFC >_is_ the current consensus. > >--brian > >Craig, Jeffrey wrote: >(Thu, 12 Jan 2006 12:41:49) > > >>Hello Brian, >> >>Both Figures 15 and 16 are defective in that they fail to accurately >>depict the L3L2 and L2L3 primitives that are essential to the >>procedures being described. >> >>The processor outage section is defective in that it fails to >>adequately address the aligned not ready state. >>It also fails to adequately address the ambiguity in treatment of >>received LSR based upon stream. >> >>I am working on detailed problem descriptions and proposed new text >>and new figures that addresses my concerns. Stay tuned. >> >>As far as you not seeing any defects in the document, I am not >>surprised, since you were an author. I think the RFC can better serve >>its audience by being clear to everyone, not just the authors. >> >>Regards, >> >>Jeff >> >> >> > > > -- Andrew Booth Signaling Systems Group Performance Technologies www.pt.com +1-613-237-4344 fax: +1-613-237-5277 Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 13 13:41:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTru-0006bW-G7; Fri, 13 Jan 2006 13:41:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTrr-0006bJ-T2 for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 13:41:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27757 for ; Fri, 13 Jan 2006 13:40:22 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[xRkapFTCblbDfKVq4A1fzEjqgxgGXFF+]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExTzD-0006ep-Dv for sigtran@ietf.org; Fri, 13 Jan 2006 13:49:21 -0500 Received: from ns.pigworks.openss7.net (IDENT:FK6fNKDgihxyMdPjztNCKC0Uqcbn4nN0@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0DIfaw04931; Fri, 13 Jan 2006 11:41:36 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0DIfas14782; Fri, 13 Jan 2006 11:41:36 -0700 Date: Fri, 13 Jan 2006 11:41:35 -0700 From: "Brian F. G. Bidulock" To: Barry Nagelberg Subject: Re: [Sigtran] Some very fundamental SIGTRAN question Message-ID: <20060113114135.A14722@openss7.org> Mail-Followup-To: Barry Nagelberg , SIGTRAN References: <20060113162404.82554.qmail@web35414.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from barryn@adax.com on Fri, Jan 13, 2006 at 12:24:39PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Barry, Good call! --brian Barry Nagelberg wrote: (Fri, 13 Jan 2006 12:24:39) > Stanislav, > > 1) Your colleague is correct. xUA is a SIGnalling TRANsport (SIGTRAN) > protocol, designed to transport legacy SS7 signalling over modern > packet networks. Nothing more and nothing less. > > Your definition has several errors: > a) SGP/ASP/IPSP aren't protocols. They are network elements. > b) Not "everything inside (ASP/IPSP/SGP) is implementor's choice". > There are many "MUSTS" and "MUST NOTS" in the specs. > > 2) Your colleague is wrong. No particular layers are mandated by the > xUA spec. There are some RECOMMENDED layers, such as SCTP and Layer > Manager, but the internal implementation is not MANDATED. > > You are also wrong. The xUA protocols must be concerned with > transmission of traffic. xUA, as an SCTP-user, must supervise and > control the operation of the SCTP layer. > > 3) You are both correct. At the SGP, the AS is essentially an > addressing concept. At the ASP, the AS is essentially an application > concept. > > 4) You are both correct. At the SGP, the ASP is a transport concept > (there is a 1:1 relationship between ASP and SCTP association). At the > ASP, the concept of ASP is an instantiation of an AS. > > 5) You are both correct. xUA handles transport. At the ASP, xUA > handles granularity of Application Services - for example, how many > instantiations, or ASPs, are necessary to handle the traffic for an > Application Server. > > 6) Your colleague is wrong. The interaction between Layer Manager and > xUA is simply a recommendation. It's not a mandatory part of the spec. > > Barry Nagelberg > Adax, Inc. > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 13 13:45:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTvd-0007cv-7A; Fri, 13 Jan 2006 13:45:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTvb-0007cg-74 for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 13:45:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28061 for ; Fri, 13 Jan 2006 13:44:13 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[RQLqtx7LS3z/IV7NyegDX090xrt91G+3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExU2x-0006oH-Qr for sigtran@ietf.org; Fri, 13 Jan 2006 13:53:12 -0500 Received: from ns.pigworks.openss7.net (IDENT:G8KmuJGhGjHJ98+XrZ0IJZHNohzldoj6@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0DIjVw05037; Fri, 13 Jan 2006 11:45:31 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0DIjU814817; Fri, 13 Jan 2006 11:45:30 -0700 Date: Fri, 13 Jan 2006 11:45:30 -0700 From: "Brian F. G. Bidulock" To: Andrew Booth Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Message-ID: <20060113114530.B14722@openss7.org> Mail-Followup-To: Andrew Booth , "Ong, Lyndon" , "Craig, Jeffrey" , sigtran@ietf.org References: <0901D1988E815341A0103206A834DA07A5C237@mdmxm02.ciena.com> <43C7EEE9.4070505@pt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <43C7EEE9.4070505@pt.com>; from abooth@pt.com on Fri, Jan 13, 2006 at 01:18:17PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "Ong, Lyndon" , "Craig, Jeffrey" , sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Andrew, Would you like to see the test spec become and informational RFC? --brian Andrew Booth wrote: (Fri, 13 Jan 2006 13:18:17) > Hi Lyndon, > > Thanks for clarifying the path forward. > > So far I've heard comments downplaying the need for an Implementor's > Guide. For what it's worth, I think an M2PA Implementor's Guide is a > worthwhile effort. > > I think the current RFC is good, but there are areas that are hard to > understand. This is especially true of the processor outage section. I > think some clarifications could make the protocol easier to implement, > which should mean fewer incorrect implementations, which would help > interoperability. Additional examples or deployment considerations > could also help. > > It may also be appropriate to add requirements to M2PA implementations, > I'm thinking in particular in explicitly specifying how long an > implementation should wait for LS READY at the end of processor outage. > It looks like this is already contained in Jeff's list, so I expect it > will be discussed in due course and either accepted or not. > > As a closing note, I know that internally our interpretation of the M2PA > spec was not painless. There were a number of cases where we spent > hours looking through Q.703, through the RFC, and considering and > generating test cases (we didn't find the latest draft of the test spec > at the time). In the end there were a number of decisions that we took > that involved a reasonable amount of deduction. Sometimes ambiguity is > good, in that it doesn't constrain implementations, other times it just > makes it hard to know if you're doing the right thing. I think an I-G > could help ease the pain of future generations of M2PA developers. > > Regards, > Andrew > > Ong, Lyndon wrote: > > >Hi Folks, > > > >Let's cool things down, please! Jeff's initial draft should in fact > >be draft-craig-sigtran-m2pa-ig since it will not yet have been agreed to > >be a WG draft. Our intention should be to identify any areas of M2PA > >that may lead to problems with interoperable implementations, based > >on our experience. This is different from saying the M2PA RFC is > >"wrong" - Brian is perfectly correct that the RFC is the standing > >agreement. > > > >Cheers, > > > >Lyndon > > > >-----Original Message----- > >From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > >Behalf Of Brian F. G. Bidulock > >Sent: Thursday, January 12, 2006 10:57 AM > >To: Craig, Jeffrey > >Cc: sigtran@ietf.org > >Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff > > > >Craig, > > > >I hope your descriptions are less vague than they are in this note. I > >look forward to commenting on your draft. Perhaps you should call it > >draft-craig-m2pa-ig because it is already far from consensus. The RFC > >_is_ the current consensus. > > > >--brian > > > >Craig, Jeffrey wrote: > >(Thu, 12 Jan 2006 12:41:49) > > > > > >>Hello Brian, > >> > >>Both Figures 15 and 16 are defective in that they fail to accurately > >>depict the L3L2 and L2L3 primitives that are essential to the > >>procedures being described. > >> > >>The processor outage section is defective in that it fails to > >>adequately address the aligned not ready state. > >>It also fails to adequately address the ambiguity in treatment of > >>received LSR based upon stream. > >> > >>I am working on detailed problem descriptions and proposed new text > >>and new figures that addresses my concerns. Stay tuned. > >> > >>As far as you not seeing any defects in the document, I am not > >>surprised, since you were an author. I think the RFC can better serve > >>its audience by being clear to everyone, not just the authors. > >> > >>Regards, > >> > >>Jeff > >> > >> > >> > > > > > > > > -- > Andrew Booth > Signaling Systems Group > Performance Technologies > www.pt.com > +1-613-237-4344 > fax: +1-613-237-5277 > > Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter. -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 13 14:53:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExUz3-0006j0-3I; Fri, 13 Jan 2006 14:53:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExUz1-0006iv-HI for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 14:53:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02329 for ; Fri, 13 Jan 2006 14:51:49 -0500 (EST) Received: from web35401.mail.mud.yahoo.com ([66.163.179.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExV6O-0000fq-GZ for sigtran@ietf.org; Fri, 13 Jan 2006 15:00:49 -0500 Received: (qmail 65597 invoked by uid 60001); 13 Jan 2006 19:53:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WJfjAd12ttlf9o1ddI0aHdrw7PLBGx/JNMB2+1tBfH6xg9sCwKKZPA3RZS+t0PP6Bkj4m61AhF6rZJGHA2hqGneQDirC/gBcGlBcFy674ZIW05V5NZs/f0t6maPzB44uIdI0JnfpMCe2325BdjsfG/NUHvw1hEyhWXRX0PftyKc= ; Message-ID: <20060113195301.65595.qmail@web35401.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35401.mail.mud.yahoo.com via HTTP; Fri, 13 Jan 2006 11:53:01 PST Date: Fri, 13 Jan 2006 11:53:01 -0800 (PST) From: Stanislav Ivanovich Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs To: SIGTRAN In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0711734897==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0711734897== Content-Type: multipart/alternative; boundary="0-803379941-1137181981=:63453" Content-Transfer-Encoding: 8bit --0-803379941-1137181981=:63453 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Tolga, Brian, I see that both of you agree that in this case at ASP place we must have MTP3 (or SCCP) logic if one wants to use this configuration scenario. I think no one can question this! However the essential problem is which protocol we are to use? In my view this is the essence of the dispute. If we are to allow that ASP (or IPSP) can contain MTP or SCCP logic then the difference between the processes disappears (e.g. ASP/IPSP/SGP all can do relay/gateway/host applications) as we saw from the discussion we had last year (see thread "[Sigtran] AS concepts and Relay in SUA and M3UA" starting from December 14th 2005). So why then different protocols (ASP-SGP and IPSP-IPSP in SE and DE flavors)? However, according to Tolga's idea SG-SG protocol does support this -> i.e. MTP3/SCCP layers communicate without AS concepts in between! What is the redundancy scheme which ASP-SGP or IPSP-IPSP communication can give you and SGP-SGP communication cannot give you if in this cases ASP/IPSP'es only contain MTP3/SCCP layers (i.e. without application logic)? OTOH, I see some problems of utilizing AS concepts in between two MTP3/SCCP layers (regardless of how you call the hosting processes).... / Stanislav Tolga Asveren wrote: Brian, [..snip..] > > [TOLGA]Even for PC granularity RKs, it is SG which controls/creates the > > unique view of the signaling enitity to the network, so one has to have > > necessary MTP3 procedures to support that. > > > > BTW, I wouldn't call hosting MTP3 logic in SG as "a PC in MTP3 > stack in SG", > > it is just providing necessary procedures to have the unique view of the > > signaling enitity and generating corresponding network messages > -and it is > > the multiple clones of the same unique view on different SGs, > which are not > > synchronized, which may create issues for multiple-SG scenarios-. > > STPs do this all day long. [TOLGA]On the practical side of how things work, I agree with you that with multiple-SG acting as STP scenario where RKs are in PC granularity, the possibly different views of the hosted PC are less of a problem. In such a case hosting necessary MTP3 logic for AS maps pretty much to route management from functionality point of view. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-803379941-1137181981=:63453 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Tolga, Brian,
 
I see that both of you agree that in this case at ASP place we must have MTP3 (or SCCP) logic if one wants to use this configuration scenario. I think no one can question this!
 
However the essential problem is which protocol we are to use? In my view this is the essence of the dispute. If we are to allow that ASP (or IPSP) can contain MTP or SCCP logic then the difference between the processes disappears (e.g. ASP/IPSP/SGP all can do relay/gateway/host applications) as we saw from the discussion we had last year (see thread "[Sigtran] AS concepts and Relay in SUA and M3UA" starting from December 14th 2005). So why then different protocols (ASP-SGP and IPSP-IPSP in SE and DE flavors)?
 
However, according to Tolga's idea SG-SG protocol does support this -> i.e. MTP3/SCCP layers communicate without AS concepts in between!
 
What is the redundancy scheme which ASP-SGP or IPSP-IPSP communication can give you and SGP-SGP communication cannot give you if in this cases ASP/IPSP'es only contain MTP3/SCCP layers (i.e. without application logic)?
 
OTOH, I see some problems of utilizing AS concepts in between two MTP3/SCCP layers (regardless of how you call the hosting processes)....
 
/ Stanislav
 


Tolga Asveren <asveren@ulticom.com> wrote:
Brian,

[..snip..]
> > [TOLGA]Even for PC granularity RKs, it is SG which controls/creates the
> > unique view of the signaling enitity to the network, so one has to have
> > necessary MTP3 procedures to support that.
> >
> > BTW, I wouldn't call hosting MTP3 logic in SG as "a P! C in MTP3
> stack in SG",
> > it is just providing necessary procedures to have the unique view of the
> > signaling enitity and generating corresponding network messages
> -and it is
> > the multiple clones of the same unique view on different SGs,
> which are not
> > synchronized, which may create issues for multiple-SG scenarios-.
>
> STPs do this all day long.
[TOLGA]On the practical side of how things work, I agree with you that with
multiple-SG acting as STP scenario where RKs are in PC granularity, the
possibly different views of the hosted PC are less of a problem. In such a
case hosting necessary MTP3 logic for AS maps pretty much to route
management from functionality point of view.



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

Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-803379941-1137181981=:63453-- --===============0711734897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0711734897==-- From sigtran-bounces@ietf.org Fri Jan 13 15:19:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExVOj-0007DL-5o; Fri, 13 Jan 2006 15:19:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExVOh-0007Cy-LT for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 15:19:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04353 for ; Fri, 13 Jan 2006 15:18:21 -0500 (EST) Received: from web35402.mail.mud.yahoo.com ([66.163.179.111]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExVW1-0001lb-0D for sigtran@ietf.org; Fri, 13 Jan 2006 15:27:20 -0500 Received: (qmail 52143 invoked by uid 60001); 13 Jan 2006 20:19:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4gN/VbLsLZsvM361UcJ/mJXr/wlATyvAg6nSNEvQ9PKJG92vm/WYPOMvrFpY/poNasT6D7c9DB+7OHVzbcClnpGp63a54bMZaxuRWXkXh8CnIB6X5bX13n+VAScl9nPE0wXGf5NdehSGUcqJOcJBV7lxmUl+FBoqPRELkNc3xG4= ; Message-ID: <20060113201929.52141.qmail@web35402.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35402.mail.mud.yahoo.com via HTTP; Fri, 13 Jan 2006 12:19:29 PST Date: Fri, 13 Jan 2006 12:19:29 -0800 (PST) From: Stanislav Ivanovich Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs To: SIGTRAN MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1004173449==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1004173449== Content-Type: multipart/alternative; boundary="0-516895282-1137183569=:40837" --0-516895282-1137183569=:40837 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA04353 Hello, =20 In addition to the last mail: =20 The original idea was to have one user function at ASP connected to 2 S= GW (thus two independent SCCP/MTP layers). So in order to solve this we s= aid -> we need an (i.e. 1) MTP/SCCP layer at ASP place which is to commun= icate with independent MTP/SCCP layers at SGW'es side. =20 However here you again have one user function connected to one MTP/SCCP= layer. This is exactly what the Tolga's SGP-SGP solution covers. The onl= y difference is that ASP-SGP and IPSP-IPSP protocols do mandate use of AS= concepts with all the restrictions which imply from these protocols... w= hich we do not have in SGP-SGP protocol. =20 So again we have very fundamental question -> what does AS/RC concept p= rovide us with on the interface between two MTP/SCCP relay equipped proce= sses? =20 It brings us just restrictions and problems nothing else! =20 / stanislav =20 =20 Stanislav Ivanovich wrote: Tolga, Brian, =20 I see that both of you agree that in this case at ASP place we must hav= e MTP3 (or SCCP) logic if one wants to use this configuration scenario. I= think no one can question this! =20 However the essential problem is which protocol we are to use? In my vi= ew this is the essence of the dispute. If we are to allow that ASP (or IP= SP) can contain MTP or SCCP logic then the difference between the process= es disappears (e.g. ASP/IPSP/SGP all can do relay/gateway/host applicatio= ns) as we saw from the discussion we had last year (see thread "[Sigtran]= AS concepts and Relay in SUA and M3UA" starting from December 14th 2005)= . So why then different protocols (ASP-SGP and IPSP-IPSP in SE and DE fla= vors)? =20 However, according to Tolga's idea SG-SG protocol does support this -> = i.e. MTP3/SCCP layers communicate without AS concepts in between! =20 What is the redundancy scheme which ASP-SGP or IPSP-IPSP communication = can give you and SGP-SGP communication cannot give you if in this cases A= SP/IPSP'es only contain MTP3/SCCP layers (i.e. without application logic)= ? =20 OTOH, I see some problems of utilizing AS concepts in between two MTP3/= SCCP layers (regardless of how you call the hosting processes).... =20 / Stanislav =20 =20 Tolga Asveren wrote: Brian, [..snip..] > > [TOLGA]Even for PC granularity RKs, it is SG which controls/creates t= he > > unique view of the signaling enitity to the network, so one has to ha= ve > > necessary MTP3 procedures to support that. > > > > BTW, I wouldn't call hosting MTP3 logic in SG as "a PC in MTP3 > stack in SG", > > it is just providing necessary procedures to have the unique view of = the > > signaling enitity and generating corresponding network messages > -and it is > > the multiple clones of the same unique view on different SGs, > which are not > > synchronized, which may create issues for multiple-SG scenarios-. > > STPs do this all day long. [TOLGA]On the practical side of how things work, I agree with you that wi= th multiple-SG acting as STP scenario where RKs are in PC granularity, the possibly different views of the hosted PC are less of a problem. In such = a case hosting necessary MTP3 logic for AS maps pretty much to route management from functionality point of view. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran =20 =20 --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands = ASAP. =20 =09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! --0-516895282-1137183569=:40837 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA04353
Hello,
 
In addition to the last mail:<= /DIV>
 
The original idea was to have one use= r function at ASP connected to 2 SGW (thus two independent SCCP/MTP layer= s). So in order to solve this we said -> we need an (i.e. 1) MTP/SCCP = layer at ASP place which is to communicate with independent MTP/SCCP laye= rs at SGW'es side.
 
However here you again = have one user function connected to one MTP/SCCP layer. This is exactly w= hat the Tolga's SGP-SGP solution covers. The only difference is that ASP-= SGP and IPSP-IPSP protocols do mandate use of AS concepts with all the re= strictions which imply from these protocols... which we do not have in SG= P-SGP protocol.
 
So again we have very fund= amental question -> what does AS/RC concept provide us with on the int= erface between two MTP/SCCP relay equipped processes?
 <= /DIV>
It brings us just restrictions and problems nothing else!
 
/ stanislav
=
 


Stanislav Ivanovich <stanislav_= ivanovich@yahoo.com> wrote:
Tolga, Brian,
 
I see that both = of you agree that in this case at ASP place we must have MTP3 (or SCCP) l= ogic if one wants to use this configuration scenario. I think no one can = question this!
 
However the essential probl= em is which protocol we are to use? In my view this is the essence of the= dispute. If we are to allow that ASP (or IPSP) can contain MTP or SCCP l= ogic then the difference between the processes disappears (e.g. ASP/IPSP/= SGP all can do relay/gateway/host applications) as we saw from the discus= sion we had last year (see thread "[Sigtran] AS concepts and Relay in SUA= and M3UA" starting from December 14th 2005). So why then different protocols (ASP-SGP and IPSP-IPSP in SE and DE&nb= sp;flavors)?
 
However, according to Tolga's= idea SG-SG protocol does support this -> i.e. MTP3/SCCP layers commun= icate without AS concepts in between!
 
What= is the redundancy scheme which ASP-SGP or IPSP-IPSP communication can gi= ve you and SGP-SGP communication cannot give you if in this cases AS= P/IPSP'es only contain MTP3/SCCP layers (i.e. without application logic)?=
 
OTOH, I see some problems of ut= ilizing AS concepts in between two MTP3/SCCP layers (regardless of&n= bsp;how you call the hosting processes)....
 
/ Stanislav
 


Tolga Asveren = <asveren@ulticom.com> wrote:
Brian,

[..snip..]
> > [TOLGA]Even for PC granularity RKs, it is SG which controls/creates the<= BR>> > unique view of the signaling enitity to the network, so one = has to have
> > necessary MTP3 procedures to support that.
&g= t; >
> > BTW, I wouldn't call hosting MTP3 logic in SG as "a = PC in MTP3
> stack in SG",
> > it is just providing necess= ary procedures to have the unique view of the
> > signaling enit= ity and generating corresponding network messages
> -and it is
&= gt; > the multiple clones of the same unique view on different SGs,> which are not
> > synchronized, which may create issues fo= r multiple-SG scenarios-.
>
> STPs do this all day long.
[= TOLGA]On the practical side of how things work, I agree with you that wit= h
multiple-SG acting as STP scenario where RKs are in PC granularity, = the
possibly different views of the hosted PC are less of a problem. I= n such a
case hosting necessary MTP3 logic for AS maps pretty much to route
management from functionality point of v= iew.



_______________________________________________
Si= gtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/l= istinfo/sigtran

= Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP.<= /DIV>

Yahoo! Photos =96 Showcase holiday pictures in hardcover=20 Photo Bo= oks. You design it and we=92ll bind it! --0-516895282-1137183569=:40837-- --===============1004173449== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1004173449==-- From sigtran-bounces@ietf.org Fri Jan 13 16:45:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWjU-0002z7-9A; Fri, 13 Jan 2006 16:45:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWjS-0002xS-LA for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 16:45:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13956 for ; Fri, 13 Jan 2006 16:43:51 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExWqq-0006Jp-5i for sigtran@ietf.org; Fri, 13 Jan 2006 16:52:52 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9367453E8E for ; Fri, 13 Jan 2006 16:44:59 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0DLiuk2001583 for ; Fri, 13 Jan 2006 16:44:58 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Date: Fri, 13 Jan 2006 16:26:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060113195301.65595.qmail@web35401.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: unknown X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Friday, January 13, 2006 2:53 PM To: SIGTRAN Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Tolga, Brian, I see that both of you agree that in this case at ASP place we must have MTP3 (or SCCP) logic if one wants to use this configuration scenario. I think no one can question this! [TOLGA]Just to prevent a possible confusion, not a fullblown MTP3 logic though, just enough to select the "right" SG. However the essential problem is which protocol we are to use? In my view this is the essence of the dispute. If we are to allow that ASP (or IPSP) can contain MTP or SCCP logic then the difference between the processes disappears (e.g. ASP/IPSP/SGP all can do relay/gateway/host applications) as we saw from the discussion we had last year (see thread "[Sigtran] AS concepts and Relay in SUA and M3UA" starting from December 14th 2005). So why then different protocols (ASP-SGP and IPSP-IPSP in SE and DE flavors)? However, according to Tolga's idea SG-SG protocol does support this -> i.e. MTP3/SCCP layers communicate without AS concepts in between! [TOLGA]First of all I have to say that the credit for SG-SG does not belong to me alone. There were other people contributing to it as well from very early on, when the idea came up during initial IPSP discussions -I believe more than 4 years ago :-)-, or afterwards to review the SG-SG drafts. What is the redundancy scheme which ASP-SGP or IPSP-IPSP communication can give you and SGP-SGP communication cannot give you if in this cases ASP/IPSP'es only contain MTP3/SCCP layers (i.e. without application logic)? [TOLGA]From redundancy point of view, probably there is no major difference -or better said, I personally don't see something which couldn't be added to SG-SG in this regard, if there is a need-. AFAICS, the main advantage of ASP/SGP model is to allow routing on AS level, i.e. in sub-PC granularity. OTOH, if PC boundaries are crossed, I find SG-SG model more natural and efficient because it is a true peer-to-peer model and does not require hosting MTP3/SCCP logic on a remote node on behalf of AS. OTOH, I see some problems of utilizing AS concepts in between two MTP3/SCCP layers (regardless of how you call the hosting processes).... [TOLGA]Yes, here I agree with you and actually if one considers that ASP/SGP interface is mimicing MTP3/MTP3-User Part (SCCP/SCCP-User Part for SUA) interface, this is not a suprise. That type of interface is more suitable to distribute traffic for a single signaling entity -whether it be MTP3 or SCCP- to multiple application logic processing nodes. / Stanislav Tolga Asveren wrote: Brian, [..snip..] > > [TOLGA]Even for PC granularity RKs, it is SG which controls/creates the > > unique view of the signaling enitity to the network, so one has to have > > necessary MTP3 procedures to support that. > > > > BTW, I wouldn't call hosting MTP3 logic in SG as "a P! C in MTP3 > stack in SG", > > it is just providing necessary procedures to have the unique view of the > > signaling enitity and generating corresponding network messages > -and it is > > the multiple clones of the same unique view on different SGs, > which are not > > synchronized, which may create issues for multiple-SG scenarios-. > > STPs do this all day long. [TOLGA]On the practical side of how things work, I agree with you that with multiple-SG acting as STP scenario where RKs are in PC granularity, the possibly different views of the hosted PC are less of a problem. In such a case hosting necessary MTP3 logic for AS maps pretty much to route management from functionality point of view. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 13 18:03:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXxH-0006wV-N3; Fri, 13 Jan 2006 18:03:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXxC-0006vX-NJ for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 18:03:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19072 for ; Fri, 13 Jan 2006 18:02:07 -0500 (EST) Received: from ottgw.pt.com ([206.191.2.130] helo=krang.ottawa.pt.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExY4Y-0000iX-Q2 for sigtran@ietf.org; Fri, 13 Jan 2006 18:11:09 -0500 Received: from [207.81.15.208] (lucius.ottawa.pt.com [207.81.15.208]) by krang.ottawa.pt.com (8.12.8/8.12.8) with ESMTP id k0DN31IM026139; Fri, 13 Jan 2006 18:03:03 -0500 Message-ID: <43C8321C.3020409@pt.com> Date: Fri, 13 Jan 2006 18:05:00 -0500 From: Andrew Booth User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff References: <0901D1988E815341A0103206A834DA07A5C237@mdmxm02.ciena.com> <43C7EEE9.4070505@pt.com> <20060113114530.B14722@openss7.org> In-Reply-To: <20060113114530.B14722@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: 7bit Cc: "Ong, Lyndon" , "Craig, Jeffrey" , sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi Brian, In summary, I think having reference test cases recorded somewhere as an informational resource would be appreciated by many. I don't know what the best format is. The test spec does seem to overlap somewhat with additional examples in the I-G. I do still think the I-G is a worthwhile exercise. The rest of this email contains further details. BTW, The IETF web site references draft-bidulock-sigtran-m2pa-test-06, but it does not seem to provide the document when requested. Hence I cannot comment on whether I agree with the contents of that particular draft. In the past however I have found the draft M2PA test specifications to be useful both for constructing test cases and as a source of (non-authoritative) examples. A number of people here have used the M2PA test documents as references when constructing conformance test suites and have found them quite useful and clear. So, I think there is a lot of value in having the work you've done in some IETF document. An informational RFC is one choice, though I've heard objections on the list that conformance tests are out of scope. I'll admit to ignorance here on IETF policies at that level. As an idea, what do you and Jeff think of moving the "test spec" to an appendix of an I-G? Some advantages - As an appendix the information could still be informational rather than normative - the "test cases" could serve as examples that could help clarify existing text and procedures. - with only one M2PA document to worry about, the working group focus will probably be better. It will certainly be easier to keep examples and changes (if any) in synch if it's one document. - examples formulated as tests makes it easy for implementors to pull out test cases. - it may be more palatable to IETF procedures to consider an appendix full of examples rather that an informational test spec. - it may help eliminate a lot of duplication between a "test spec" document and extra exampes in an I-G This is just an idea, hopefully no one will shoot me over it. In particular, the test document is reasonably long as I recall and I'm not sure if Jeff would be interested in taking on that much extra text, especially so early on in the I-G process. Including the test spec in the I-G would certainly increase the work load involved in an I-G. Does that answer your question? Andrew Brian F. G. Bidulock wrote: >Andrew, > >Would you like to see the test spec become and informational RFC? > >--brian > >Andrew Booth wrote: (Fri, 13 Jan 2006 13:18:17) > > >>Hi Lyndon, >> >>Thanks for clarifying the path forward. >> >>So far I've heard comments downplaying the need for an Implementor's >>Guide. For what it's worth, I think an M2PA Implementor's Guide is a >>worthwhile effort. >> >>I think the current RFC is good, but there are areas that are hard to >>understand. This is especially true of the processor outage section. I >>think some clarifications could make the protocol easier to implement, >>which should mean fewer incorrect implementations, which would help >>interoperability. Additional examples or deployment considerations >>could also help. >> >>It may also be appropriate to add requirements to M2PA implementations, >>I'm thinking in particular in explicitly specifying how long an >>implementation should wait for LS READY at the end of processor outage. >>It looks like this is already contained in Jeff's list, so I expect it >>will be discussed in due course and either accepted or not. >> >>As a closing note, I know that internally our interpretation of the M2PA >>spec was not painless. There were a number of cases where we spent >>hours looking through Q.703, through the RFC, and considering and >>generating test cases (we didn't find the latest draft of the test spec >>at the time). In the end there were a number of decisions that we took >>that involved a reasonable amount of deduction. Sometimes ambiguity is >>good, in that it doesn't constrain implementations, other times it just >>makes it hard to know if you're doing the right thing. I think an I-G >>could help ease the pain of future generations of M2PA developers. >> >>Regards, >>Andrew >> >>Ong, Lyndon wrote: >> >> >> >>>Hi Folks, >>> >>>Let's cool things down, please! Jeff's initial draft should in fact >>>be draft-craig-sigtran-m2pa-ig since it will not yet have been agreed to >>>be a WG draft. Our intention should be to identify any areas of M2PA >>>that may lead to problems with interoperable implementations, based >>>on our experience. This is different from saying the M2PA RFC is >>>"wrong" - Brian is perfectly correct that the RFC is the standing >>>agreement. >>> >>>Cheers, >>> >>>Lyndon >>> >>>-----Original Message----- >>>From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On >>>Behalf Of Brian F. G. Bidulock >>>Sent: Thursday, January 12, 2006 10:57 AM >>>To: Craig, Jeffrey >>>Cc: sigtran@ietf.org >>>Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff >>> >>>Craig, >>> >>>I hope your descriptions are less vague than they are in this note. I >>>look forward to commenting on your draft. Perhaps you should call it >>>draft-craig-m2pa-ig because it is already far from consensus. The RFC >>>_is_ the current consensus. >>> >>>--brian >>> >>>Craig, Jeffrey wrote: >>>(Thu, 12 Jan 2006 12:41:49) >>> >>> >>> >>> >>>>Hello Brian, >>>> >>>>Both Figures 15 and 16 are defective in that they fail to accurately >>>>depict the L3L2 and L2L3 primitives that are essential to the >>>>procedures being described. >>>> >>>>The processor outage section is defective in that it fails to >>>>adequately address the aligned not ready state. >>>>It also fails to adequately address the ambiguity in treatment of >>>>received LSR based upon stream. >>>> >>>>I am working on detailed problem descriptions and proposed new text >>>>and new figures that addresses my concerns. Stay tuned. >>>> >>>>As far as you not seeing any defects in the document, I am not >>>>surprised, since you were an author. I think the RFC can better serve >>>>its audience by being clear to everyone, not just the authors. >>>> >>>>Regards, >>>> >>>>Jeff >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>-- >>Andrew Booth >>Signaling Systems Group >>Performance Technologies >>www.pt.com >>+1-613-237-4344 >>fax: +1-613-237-5277 >> >>Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter. >> >> > > > -- Andrew Booth Signaling Systems Group Performance Technologies www.pt.com +1-613-237-4344 fax: +1-613-237-5277 Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 13 18:33:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYQR-0007rN-3a; Fri, 13 Jan 2006 18:33:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYQP-0007rI-8r for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 18:33:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21470 for ; Fri, 13 Jan 2006 18:32:18 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[2fQSn/ZpGu5DsVZqQQRZISzwb060VNaO]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExYXo-0001v3-FP for sigtran@ietf.org; Fri, 13 Jan 2006 18:41:20 -0500 Received: from ns.pigworks.openss7.net (IDENT:hl80rLsBOsUNCV1phxstD9Rvh4pUHwSn@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0DNXOw09894; Fri, 13 Jan 2006 16:33:24 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0DNXOW18309; Fri, 13 Jan 2006 16:33:24 -0700 Date: Fri, 13 Jan 2006 16:33:23 -0700 From: "Brian F. G. Bidulock" To: Andrew Booth Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff Message-ID: <20060113163323.A18076@openss7.org> Mail-Followup-To: Andrew Booth , "Ong, Lyndon" , "Craig, Jeffrey" , sigtran@ietf.org References: <0901D1988E815341A0103206A834DA07A5C237@mdmxm02.ciena.com> <43C7EEE9.4070505@pt.com> <20060113114530.B14722@openss7.org> <43C8321C.3020409@pt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <43C8321C.3020409@pt.com>; from abooth@pt.com on Fri, Jan 13, 2006 at 06:05:00PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "Ong, Lyndon" , "Craig, Jeffrey" , sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Andrew, Andrew Booth wrote: (Fri, 13 Jan 2006 18:05:00) > Hi Brian, > > In summary, I think having reference test cases recorded somewhere as an > informational resource would be appreciated by many. I don't know what > the best format is. The test spec does seem to overlap somewhat with > additional examples in the I-G. I do still think the I-G is a > worthwhile exercise. The rest of this email contains further details. > > BTW, The IETF web site references draft-bidulock-sigtran-m2pa-test-06, > but it does not seem to provide the document when requested. Hence I > cannot comment on whether I agree with the contents of that particular > draft. They messed up: (I think they only published the .pdf format) You can view all formats here: http://www.openss7.org/docs/draft-bidulock-sigtran-m2pa-test-06.txt http://www.openss7.org/docs/draft-bidulock-sigtran-m2pa-test-06.ps http://www.openss7.org/docs/draft-bidulock-sigtran-m2pa-test-06.pdf > > In the past however I have found the draft M2PA test specifications to > be useful both for constructing test cases and as a source of > (non-authoritative) examples. A number of people here have used the > M2PA test documents as references when constructing conformance test > suites and have found them quite useful and clear. > > So, I think there is a lot of value in having the work you've done in > some IETF document. An informational RFC is one choice, though I've > heard objections on the list that conformance tests are out of scope. > I'll admit to ignorance here on IETF policies at that level. If it sits on the IETF servers for 6 months, and there are no violent objections from the WG, I can request personally that it be published as an Information RFC and it likely would. However, I wanted to vette it by the WG and give an opportunity to have it formally revied reviewed by the WG before publication. > > As an idea, what do you and Jeff think of moving the "test spec" to an > appendix of an I-G? Some advantages > > - As an appendix the information could still be informational rather > than normative > > - the "test cases" could serve as examples that could help clarify > existing text and procedures. > > - with only one M2PA document to worry about, the working group focus > will probably be better. > It will certainly be easier to keep examples and changes (if any) in > synch if it's one document. > > - examples formulated as tests makes it easy for implementors to pull > out test cases. > > - it may be more palatable to IETF procedures to consider an appendix > full of examples > rather that an informational test spec. > > - it may help eliminate a lot of duplication between a "test spec" > document and extra exampes in an I-G > > This is just an idea, hopefully no one will shoot me over it. In > particular, the test document is reasonably long as I recall and I'm not > sure if Jeff would be interested in taking on that much extra text, > especially so early on in the I-G process. Including the test spec in > the I-G would certainly increase the work load involved in an I-G. Its a possibility. Typically we use IGs in this WG as a delta document for a replacement RFC. Would the material then go as a non-normative appendix in a 'bis' RFC? It would be a strange document in the end: RFC 4165 is 53 pages and the test spec is 140 pages. It just strikes me that structurally it is probably better as a separate document. Also, don't let the title "Implementer's Guide" fool you: it is really only such in the ITU-T sense. In the ITU-T sense, IG means "Specification_Errata that_was_not_caught_before_the_document_was_formally_approved_and_that_we_are now_just_pretending_is_a_different_interpretation." > > Does that answer your question? Yes, thank you. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 13 18:44:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYb5-0001sb-Vm; Fri, 13 Jan 2006 18:44:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYb3-0001sQ-TB for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 18:44:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22177 for ; Fri, 13 Jan 2006 18:43:18 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[n3VTLpnv7Cb1JnXrTgWI65Jp4fylLftB]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExYiT-0002LJ-9A for sigtran@ietf.org; Fri, 13 Jan 2006 18:52:21 -0500 Received: from ns.pigworks.openss7.net (IDENT:NHxxIydnora7ZOi3v0rypR+pLbeOKt89@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0DNiew10053; Fri, 13 Jan 2006 16:44:40 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0DNidt18406; Fri, 13 Jan 2006 16:44:39 -0700 Date: Fri, 13 Jan 2006 16:44:39 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Message-ID: <20060113164439.B18076@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060113201929.52141.qmail@web35402.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060113201929.52141.qmail@web35402.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Fri, Jan 13, 2006 at 12:19:29PM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Neither the ASP-SGP nor IPSP-IPSP models require you to use AS or RC. Define 1 AS per ASP only and give it RC value 0. Make that AS an entire point code (or network appearance for that matter). Then this RK:AS:RC 3-tuple that bothers you so much falls away. --brian Stanislav Ivanovich wrote: (Fri, 13 Jan 2006 12:19:29) > > Hello, > > > > In addition to the last mail: > > > > The original idea was to have one user function at ASP connected to 2 > SGW (thus two independent SCCP/MTP layers). So in order to solve this > we said -> we need an (i.e. 1) MTP/SCCP layer at ASP place which is to > communicate with independent MTP/SCCP layers at SGW'es side. > > > > However here you again have one user function connected to one > MTP/SCCP layer. This is exactly what the Tolga's SGP-SGP solution > covers. The only difference is that ASP-SGP and IPSP-IPSP protocols do > mandate use of AS concepts with all the restrictions which imply from > these protocols... which we do not have in SGP-SGP protocol. > > > > So again we have very fundamental question -> what does AS/RC concept > provide us with on the interface between two MTP/SCCP relay equipped > processes? > > > > It brings us just restrictions and problems nothing else! > > > > / stanislav > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 13 21:48:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExbSW-0002fa-2F; Fri, 13 Jan 2006 21:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExbSS-0002fO-Cc for sigtran@megatron.ietf.org; Fri, 13 Jan 2006 21:48:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10671 for ; Fri, 13 Jan 2006 21:46:38 -0500 (EST) Received: from web35403.mail.mud.yahoo.com ([66.163.179.112]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExbZs-0002XK-O8 for sigtran@ietf.org; Fri, 13 Jan 2006 21:55:41 -0500 Received: (qmail 89623 invoked by uid 60001); 14 Jan 2006 02:47:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cqtvMU2GVKTRcjoQCFD9BdAW0gAItqPkG2y4JRk9IXfks5m70yWsVmvWIwXKP4OehNpn6H9bD0ehsXTdCKwNQRbc2aEegyfIrT6HeuFE9t/Y6On414Daeo/zlwrJbEr/wrUZL9NkHIqEjUbxgSWvDny3mm0NWkLiJ8yIwBHc/Lk= ; Message-ID: <20060114024749.89621.qmail@web35403.mail.mud.yahoo.com> Received: from [83.131.22.128] by web35403.mail.mud.yahoo.com via HTTP; Fri, 13 Jan 2006 18:47:49 PST Date: Fri, 13 Jan 2006 18:47:49 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs To: SIGTRAN In-Reply-To: <20060113164439.B18076@openss7.org> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1284101358==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1284101358== Content-Type: multipart/alternative; boundary="0-285393903-1137206869=:87967" Content-Transfer-Encoding: 8bit --0-285393903-1137206869=:87967 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear Brian and Tolga, First, thank you Tolga and Brian, indeed very much for your great contribution and patience both of you show to all of us SIGTRAN implementors every single day by answering long questions! Please, I kindly ask you to have just a little bit more patience with this (in my view) very essential issue. As we have seen here whatever question one arise (in this case multiple SG'es or something else) he/she will finish at the core of the issue which I am to be honest very afraid of. Brian, I really see no problems in understanding AS concepts when they apply on interface between MTP3/SCCP and their user-functions or in-between two user-functions whatever you call the hosting processes. However when one applies this concept in between two MTP3/SCCP instances I have tremendous conceptual problems. I understand your proposal Brian and this seems reasonable -> if one does not want/like the AS concept in between two MTP3/SCCP instances then he/she does not need to use it (to be honest I thought it was mandatory since RC was mandatory parameter is DATA messages of SUA but now I see that this is not the case). However if one vendor supports this (because he understands this) and my company does not support this (because I do not understand it) this brings my company in serious disadvantage! Therefore regardless of implementation of a particular feature the xxUA protocols offer I first need to fully understand all the capabilities/possibilities the specifications give me. My point is that in my current understanding AS concept in between two MTP3/SCCP instances brings me just restrictions (i.e. some configurations are not possible), while OTOH I get nothing "in-return" (e.g. better redundancy... etc). In my view SGP-SGP brings you the same redundancy as ASP-SGP and IPSP-IPSP protocols while it does not impose any kind of restrictions. Which restrictions? Here are just few of them: 1) if AS is to be used in between 2 MTP3/SCCP instances then it implies that AS represents an SS7 destination. However in MTP3/SCCP networks relay can be easily built because when one sends traffic it is irrelevant what is the state of the sending entity. What only matters is the accessibility state of remote destination. For example if I have SGP connected to ASP equipped with relay which serves local user for 2-100 and supports relay for 2-200 then according to xxUA specifications ASP must not send (!) traffic until it is not prepared to receive any. So ASP has to activate its (local) receiver for 2-100 just to make 2-200 possible to send traffic over it to SGP!?! Why this? This would imply that ASP has to register 2-200 at SGP also what is very different from SCCP/MTP3 relay. In MTP3/SCCP networks one can have a sender sending over relay and receiving traffic over another independent relay. My comment is -> This has serious consequence on building of relay networks based on these AS principles. It is obvious why in both M3UA and SUA specifications it is explicitly said ASP is not allowed to send (!) until it is activated itself within an AS at SGP (thus be able to receive) -> this is how User Parts (or SCCP users) work: if they are not connected to MTP3/SCCP layers then they will not be able to either send or receive traffic. However if we do not understand AS'es as MTP3/SCCP user functions but as SS7 addresses in between two MTP3/SCCP instances then this becomes serious restriction. Note that removing restriction for ASP/IPSP to send (!) traffic regardless of its activation within an AS is not "administrative" but has serious technical consequence -> moving of SSNM messages from SGP to ASP from ACTIVE to DOWN state... 2) In traditional MTP/SCCP networks one can have destination SPC1 reachable over two STP functions STP1 and STP2 while SPC2 reachable over only STP1 for example. However by having the AS concept one is not allowed to have at SPCx place (for example an IPSP) an SS7 address in two different AS'es. So AS1 cannot be (SPC1, SPC2) and STP1 is a process supporting AS1 while AS2 is (SPC1) and STP2 is supporting AS2. Because of resolution problems at SPCx place which must have AS configuration in this way: AS1 (SPC1) supported by STP1 and STP2 and AS2 (SPC2) supported by STP1 one must introduce 2 AS'es at STP1 place! This kind of influence of one node on the configuration of other one you cannot find in traditional SS7 networks! Another practical problem! 3) Please Brian, I kindly ask you to make your opinion about this (I would very much appreciate opinions of other SUA RFC co-authors as well!) -> if we allow that ASP/IPSP hosts MTP3/SCCP layers then this is not only against basic definition in the SUA paper itself: e.g. SUA RFC section 1.2.2. "Terminology": "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-peer fashion." but even more -> this is very serious conceptual problem! Why do we define several process types and 2 different protocols if there is no difference between the processes? By reading all the threads last weeks I see that even ASP can send SSNM messages towards SGP, IPSP can send and receive SSNM so actually even the difference between the protocols themselves disappears! This is very serious conceptual problem for which I haven't still received any convincing answer -> the only answers I received are these: ---------------------------------------- [John Loughney] "Process-types, in my view, are illustrative text, to give an implementor an idea of what we are talking about - however, they are not meant that each capability MUST be implemented as a separate process." ---------------------------------------- [John Loughney] "The notion of a process, IMO, is an implementation issue - different OSes may behave different." ---------------------------------------- see thread "[Sigtran] AS concepts and Relay in SUA and M3UA" I am really very sorry but this does not sound very convincing, does it? 4) If the essence of the AS concept is a redundancy concept (AS is served by several signaling processes) then there is no redundancy scheme which SGP-SGP concept does not provide and which could be provided by existing protocols (ASP-SGP and IPSP-IPSP). However advantage if SGP-SGP model is that it does not suffer from the restrictions/problems described in point 1-3 above. However SGP-SGP concept provides us with the resolution of all the problems described in points 1-3 above and at the same time it preserves the existing protocols and keeps the signaling process definition clear and consistent! Tolga, Thank you for your comments! I do not only understand this: [Tolga Asveren] "AFAICS, the main advantage of ASP/SGP model is to allow routing on AS level, i.e. in sub-PC granularity." In my view this is not effectively possible. Yes, one can have AS configured as User Part of SCCP SSN (i.e. granularity below SPC). However, in my view, this does not imply that relay based on this is effectively possible! This is for the following reasons: 1) How would STP based on finer granularity support this kind of management? When a process receives DUPU indicating UPU or SSP then it will not try to divert traffic to another "STP" since it assumes that the user function is dead rather then STP connection to it. Especially if we are to relay that UPU/SSP message into SS7 network... 2) Different types of traffic granularity require support for different types of Traffic Management in order to support relay based on different granularities. ANSI MTP is a good example -> there you can find the concept of Cluster Destinations. However the essence of this concept is that it is unique granularity across all the STP nodes which is not the subject of "bilateral" agreement between two adjacent STP nodes what we have with IPSP processes equipped with relay capability. In other words in ANSI MTP networks all the STP across the network that is to use Cluster concept use the same (!) traffic granularity which is supported by the same Traffic Management which is not subject to agreement between two STP nodes but spans across the whole network. In xxUA networks we have management by SSNM and AS is the agreement between two adjacent nodes... All in all - in my opinion not very efficient... Thank you both Brian and Tolga once again for your great support to SIGTRAN community as well as your patience! with best regards/ Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Neither the ASP-SGP nor IPSP-IPSP models require you to use AS or RC. Define 1 AS per ASP only and give it RC value 0. Make that AS an entire point code (or network appearance for that matter). Then this RK:AS:RC 3-tuple that bothers you so much falls away. --brian Stanislav Ivanovich wrote: (Fri, 13 Jan 2006 12:19:29) > > Hello, > > > > In addition to the last mail: > > > > The original idea was to have one user function at ASP connected to 2 > SGW (thus two independent SCCP/MTP layers). So in order to solve this > we said -> we need an (i.e. 1) MTP/SCCP layer at ASP place which is to > communicate with independent MTP/SCCP layers at SGW'es side. > > > > However here you again have one user function connected to one > MTP/SCCP layer. This is exactly what the Tolga's SGP-SGP solution > covers. The only difference is that ASP-SGP and IPSP-IPSP protocols do > mandate use of AS concepts with all the restrictions which imply from > these protocols... which we do not have in SGP-SGP protocol. > > > > So again we have very fundamental question -> what does AS/RC concept > provide us with on the interface between two MTP/SCCP relay equipped > processes? > > > > It brings us just restrictions and problems nothing else! > > > > / stanislav > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-285393903-1137206869=:87967 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Dear Brian and Tolga,
 
First, thank you Tolga and Brian, indeed very much for your great contribution and patience both of you show to all of us SIGTRAN implementors every single day by answering long questions!
 
Please, I kindly ask you to have just a little bit more patience with this (in my view) very essential issue. As we have seen here whatever question one arise (in this case multiple SG'es or something else) he/she will finish at the core of the issue which I am to be honest very afraid of.
 
 
Brian,
 
I really see no problems in understanding AS concepts when they apply on interface between MTP3/SCCP and their user-functions or in-between two user-functions whatever you call the hosting processes. However when one applies this concept in between two MTP3/SCCP instances I have tremendous conceptual problems.
 
I understand your proposal Brian and this seems reasonable -> if one does not want/like the AS concept in between two MTP3/SCCP instances then he/she does not need to use it (to be honest I thought it was mandatory since RC was mandatory parameter is DATA messages of SUA but now I see that this is not the case). However if one vendor supports this (because he understands this) and my company does not support this (because I do not understand it) this brings my company in serious disadvantage! Therefore regardless of implementation of a particular feature the xxUA protocols offer I first need to fully understand all the capabilities/possibilities the specifications give me.
 
My point is that in my current understanding AS concept in between two MTP3/SCCP instances brings me just restrictions (i.e. some configurations are not possible), while OTOH I get nothing "in-return"  (e.g. better redundancy... etc). In my view SGP-SGP brings you the same redundancy as ASP-SGP and IPSP-IPSP protocols while it does not impose any kind of restrictions. Which restrictions?
 
Here are just few of them:
 
1) if AS is to be used in between 2 MTP3/SCCP instances then it implies that AS represents an SS7 destination. However in MTP3/SCCP networks relay can be easily built because when one sends traffic it is irrelevant what is the state of the sending entity. What only matters is the accessibility state of remote destination.
For example if I have SGP connected to ASP equipped with relay which serves local user for 2-100 and supports relay for 2-200 then according to xxUA specifications ASP must not send (!) traffic until it is not prepared to receive any. So ASP has to activate its (local) receiver for 2-100 just to make 2-200 possible to send traffic over it to SGP!?! Why this?
This! would imply that ASP has to register 2-200 at SGP also what is very different from SCCP/MTP3 relay. In MTP3/SCCP networks one can have a sender sending over relay and receiving traffic over another independent relay.
 
My comment is -> This has serious consequence on building of relay networks based on these AS principles. It is obvious why in both M3UA and SUA specifications it is explicitly said ASP is not allowed to send (!) until it is activated itself within an AS at SGP (thus be able to receive) -> this is how User Parts (or SCCP users) work: if they are not connected to MTP3/SCCP layers then they will not be able to either send or receive traffic. However if we do not understand AS'es as MTP3/SCCP user functions but as SS7 addresses in between two MTP3/SCCP instances then this becomes serious restriction.
Note that removing restriction for ASP/IPSP to send (!) traffic regardless of its activation within an AS is not "administrative" but has serious technical consequence -> moving of SSNM messages from SGP to ASP from ACTIVE to DOWN state...
 
2) In traditional MTP/SCCP networks one can have destination SPC1 reachable over two STP functions STP1 and STP2 while SPC2 reachable over only STP1 for example.
However by having the AS concept one is not allowed to have at SPCx place (for example an IPSP) an SS7 address in two different AS'es. So AS1 cannot be (SPC1, SPC2) and STP1 is a process supporting AS1 while AS2 is (SPC1) and STP2 is supporting AS2. Because of resolution problems at SPCx place which must have AS configuration in this way: AS1 (SPC1) supported by STP1 and STP2 and AS2 (SPC2) supported by STP1 one must introduce 2 AS'es at STP1 place!
This kind of influence of one node on the configuration of other one you cannot find in traditional SS7 networks! Another practical problem!
 
!
3) Please Brian, I kindly ask you to make your opinion about this (I would very much appreciate opinions of other SUA RFC co-authors as well!) -> if we allow that ASP/IPSP hosts MTP3/SCCP layers then this is not only against basic definition in the SUA paper itself:
 
e.g. SUA RFC section 1.2.2. "Terminology":
"IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-peer fashion."
 
but even more -> this is very serious conceptual problem!
 
Why do we define several process types and 2 different protocols if there is no difference between the processes?
By reading all the threads last weeks I see that even ASP can send SSNM messages towards SGP, IPSP can send and receive SSNM so actually even the difference between the protocols themselves disappears!
This is very serious conceptual problem for which I haven't still received any convincing answer -> the only answers I received are these:
----------------------------------------
[John Loughney]
"Process-types, in my view, are illustrative text, to give an implementor an idea of what we are talking about - however, they are not meant that each capability MUST be implemented as a separate process."
----------------------------------------
[John Loughney]
"The notion of a process, IMO, is an implementation issue - different OSes may behave different."
----------------------------------------
see thread "[Sigtran] AS concepts and Relay in SUA and M3UA"
 
I am really very sorry but this does not sound very convincing, does it?
 
 
4) If the essence of the AS concept is a redundancy ! concept (AS is served by several signaling processes) then there is no redundancy scheme which SGP-SGP concept does not provide and which could be provided by existing protocols (ASP-SGP and IPSP-IPSP). However advantage if SGP-SGP model is that it does not suffer from the restrictions/problems described in point 1-3 above.
However SGP-SGP concept provides us with the resolution of all the problems described in points 1-3 above and at the same time it preserves the existing protocols and keeps the signaling process definition clear and consistent!
 
 
Tolga,
Thank you for your comments!
 
I do not only understand this:
 
[Tolga Asveren]
"AFAICS, the main advantage of ASP/SGP model is to allow routing on AS level, i.e. in sub-PC granularity."
 
In my view this is not effectively possible. Yes, one can have AS co! nfigured as User Part of SCCP SSN (i.e. granularity below SPC). However, in my view, this does not imply that relay based on this is effectively possible!
 
This is for the following reasons:
 
1) How would STP based on finer granularity support this kind of management? When a process receives DUPU indicating UPU or SSP then it will not try to divert traffic to another "STP" since it assumes that the user function is dead rather then STP connection to it. Especially if we are to relay that UPU/SSP message into SS7 network...
 
2) Different types of traffic granularity require support for different types of Traffic Management in order to support relay based on different granularities.
ANSI MTP is a good example -> there you can find the concept of Cluster Destinations. However the essence of this concept is that it is unique granularity across all the STP nodes&nb! sp;which is not the subject of "bilateral" agreement between two adjacent STP nodes what we have with IPSP processes equipped with relay capability.
In other words in ANSI MTP networks all the STP across the network that is to use Cluster concept use the same (!) traffic granularity which is supported by the same Traffic Management which is not subject to agreement between two STP nodes but spans across the whole network.
In xxUA networks we have management by SSNM and AS is the agreement between two adjacent nodes... All in all - in my opinion not very efficient...
 
 
 
Thank you both Brian and Tolga once again for your great support to SIGTRAN community as well as your patience!
 
with best regards/ Stanislav Ivanovich
 


"Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
Stanislav,

Neither the ASP-SGP nor IPSP-IPSP models require you to use AS or RC.
Define 1 AS per ASP only and give it RC value 0. Make that AS an entire
point code (or network appearance for that matter). Then this RK:AS:RC
3-tuple that bothers you so much falls away.

--brian

Stanislav Ivanovich wrote: (Fri, 13 Jan 2006 12:19:29)
>
> Hello,
>
>
>
> In addition to the last mail:
>
>
>
> The original idea was to have one user function at ASP connected to 2
> SGW (thus two independent SCCP/MTP layers). So in order to solve this
> we said -> we need an (i.e. 1) MTP/SCCP layer at ASP place which is to
> communicate with independent MTP/SCCP layers at SGW'es side.
>
>
>
> However here you again have one user function connected to one
> MTP/SCCP layer. This ! is exactly what the Tolga's SGP-SGP solution
> covers. The only difference is that ASP-SGP and IPSP-IPSP protocols do
> mandate use of AS concepts with all the restrictions which imply from
> these protocols... which we do not have in SGP-SGP protocol.
>
>
>
> So again we have very fundamental question -> what does AS/RC concept
> provide us with on the interface between two MTP/SCCP relay equipped
> processes?
>
>
>
> It brings us just restrictions and problems nothing else!
>
>
>
> / stanislav
>


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

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-285393903-1137206869=:87967-- --===============1284101358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1284101358==-- From sigtran-bounces@ietf.org Sun Jan 15 13:44:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyCrc-0003dz-MI; Sun, 15 Jan 2006 13:44:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyCq3-0002fN-9G for sigtran@megatron.ietf.org; Sun, 15 Jan 2006 13:42:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12059 for ; Sun, 15 Jan 2006 12:00:26 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[wSphyynvxrdkF04htz2AAOMPlWC+wM9T]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exhd4-00011G-Td for sigtran@ietf.org; Sat, 14 Jan 2006 04:23:23 -0500 Received: from ns.pigworks.openss7.net (IDENT:IUJeaHcIqPL+IeSmoKLgt41fk91Zm1te@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0E9Faw19911; Sat, 14 Jan 2006 02:15:36 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0E9Faj24149; Sat, 14 Jan 2006 02:15:36 -0700 Date: Sat, 14 Jan 2006 02:15:35 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Message-ID: <20060114021535.C18076@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060113164439.B18076@openss7.org> <20060114024749.89621.qmail@web35403.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060114024749.89621.qmail@web35403.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Fri, Jan 13, 2006 at 06:47:49PM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, I think you are still way off base by thinking that the AS is so foreign to SS7. Think of an RK:AS:RC 3-tuple as identifying an MTP-SAP or SCCP-SAP. An SCCP-User at an SCCP-SAP does track the state of remote SCCP-SAPs (Users) of which it is concerned (i.e., that it sends to), and those are, in all but the most exceptional of cases, the SCCP-SAPs that send to it. Nevertheles, the RK:AS:RC simply identifies the SCCP-SAP and is therefore, really just an SCCP-SAPI. For many SS7 implementations, the SCCP-SAPI is just Network Identifier, Point Code and Subsystem Number. For SUA it can also be IP Address and be restricted further to a Global Title range. The same is true for M3UA. An MTP-User at an MTP-SAP does track the state of remote MTP-SAPs (Users) (again to which it sends), and those are, again, in all but the most exceptional of cases, the MTP-SAPs that send to it. Nevertheless, the RK:AS:RC simply identifies the MTP-SAP and is therefore, really just an MTP-SAPI. Also, for may SS7 implementations, the MTP-SAPI is a Network Identifier, Point Code an and SI value. For some, it is just a Network Identifier and Point Code. For others it is a Network Identifier. Just because you can define any Routing Key under the Sun does not mean that all of them will be useful or even rational. Certainly the most useful ones are those that correspond to SS7 MTP-SAPs and SCCP-SAPs. Finer granularity allows distribution of applications over a broader number of hosts than is otherwise possible, without allocation of unique point codes. Because some National point code numbering spaces are exhausted, providing the capability of distributing applications without requiring point code assignment is a necessary evil. I really don't see any limitations with the RK:AS:RC approach to MTP-SAPIs and SCCP-SAPIs. In fact, a single RK:AS:RC can identify multiple MTP-SAPs or SCCP-SAPs and, therefore, better identifies the user behind the SAPs instead of just the SAPs themselves, as would be accomplished by only addressing individual SAPs. Now, MTP Transfer can be large in scope (i.e., entire National signalling networks at a primary STP), and a RK based on NA alone would permit this. SCCP, OTOH, is not so large in scope. SCCP Relay can be as granular as the coupling of specific connection sections for protocol class 2 and 3 relay. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 16 04:38:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyQoQ-0003om-4A; Mon, 16 Jan 2006 04:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyQoN-0003oe-LS for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 04:38:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27487 for ; Mon, 16 Jan 2006 04:36:40 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyQwG-0001UE-Dq for Sigtran@ietf.org; Mon, 16 Jan 2006 04:46:13 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0G9Zqr6027329 for ; Mon, 16 Jan 2006 01:35:53 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <00e001c61a80$661adb50$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Mon, 16 Jan 2006 12:36:52 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1242/Sat Jan 14 16:00:41 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Subject: [Sigtran] Ordering within RK parameter of M3UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0774029967==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0774029967== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01C61A99.8740B0C0" This is a multi-part message in MIME format. ------=_NextPart_000_00D9_01C61A99.8740B0C0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, It seems quite open to interpretation (from 3.2 and 3.6.1 of 3332bis05), = whether Destination Point Code, Service Indicators and Originating Point = Code List parameters (which may be repeated as a grouping) must follow = in exactly this order or not. >From 3.6.1: Note: The Destination Point Code, Service Indicators, and Originating Point Code List parameters MAY be repeated as a grouping within the Routing Key parameter, in the structure shown above. It think that there is now requirement to their ordering inside a = grouping, but have to admit that this is just my interprertation. Any opinions? Best Regards, Sergey Mikhailov. ------=_NextPart_000_00D9_01C61A99.8740B0C0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi,
 
It seems quite open to=20 interpretation (from 3.2 and 3.6.1 of 3332bis05), whether = Destination Point=20 Code, Service Indicators and Originating Point Code List parameters = (which may=20 be repeated as a grouping) must follow in exactly this order or=20 not.
 
From 3.6.1:
 
      Note: The Destination Point Code, = Service=20 Indicators, and
      Originating Point Code = List=20 parameters MAY be repeated as a
      = grouping=20 within the Routing Key parameter, in the structure=20 shown
      above.

It=20 think that there is now requirement to their ordering inside a grouping, = but=20 have to admit that this is just my interprertation.
Any opinions?
 
 
Best Regards,
Sergey = Mikhailov.
------=_NextPart_000_00D9_01C61A99.8740B0C0-- --===============0774029967== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0774029967==-- From sigtran-bounces@ietf.org Mon Jan 16 04:40:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyQr8-0004cB-1R; Mon, 16 Jan 2006 04:40:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyQr6-0004bC-8K for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 04:40:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27701 for ; Mon, 16 Jan 2006 04:39:28 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyQyz-0001fE-2t for Sigtran@ietf.org; Mon, 16 Jan 2006 04:49:02 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0G9cor8027344 for ; Mon, 16 Jan 2006 01:38:51 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <00ef01c61a80$cfe73510$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Mon, 16 Jan 2006 12:39:50 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1242/Sat Jan 14 16:00:41 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Sigtran] Ordering within RK parameter of M3UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0883769453==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0883769453== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E6_01C61A99.F13F1700" This is a multi-part message in MIME format. ------=_NextPart_000_00E6_01C61A99.F13F1700 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable (there was typos, sorry) I think that there is no requirement to their ordering inside a = grouping, but I have to admit that this is just my interprertation. Regards, Sergey Mikhailov. ------=_NextPart_000_00E6_01C61A99.F13F1700 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
(there was typos, = sorry)
 
I think that there is no requirement to = their=20 ordering inside a grouping, but I have to admit that this is just my=20 interprertation.
 
 
Regards,
Sergey = Mikhailov.
------=_NextPart_000_00E6_01C61A99.F13F1700-- --===============0883769453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0883769453==-- From sigtran-bounces@ietf.org Mon Jan 16 05:06:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyRFg-0003JI-HX; Mon, 16 Jan 2006 05:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyRFe-0003JD-RU for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 05:06:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29559 for ; Mon, 16 Jan 2006 05:04:51 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[MXtINnugAcCDG+49VWtijpMcWBt450nc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyRNX-0002VB-QL for Sigtran@ietf.org; Mon, 16 Jan 2006 05:14:25 -0500 Received: from ns.pigworks.openss7.net (IDENT:JGkNYvDZb0RUZJRMbPUp5HttUJWSuKGF@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0GA63E00992; Mon, 16 Jan 2006 03:06:03 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0GA62D31456; Mon, 16 Jan 2006 03:06:02 -0700 Date: Mon, 16 Jan 2006 03:06:02 -0700 From: "Brian F. G. Bidulock" To: Sergey Mikhailov Subject: Re: [Sigtran] Ordering within RK parameter of M3UA Message-ID: <20060116030602.A31344@openss7.org> Mail-Followup-To: Sergey Mikhailov , SIGTRAN References: <00e001c61a80$661adb50$150f0f0a@smikhailov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <00e001c61a80$661adb50$150f0f0a@smikhailov>; from smikhailov@linkbit.com on Mon, Jan 16, 2006 at 12:36:52PM +0300 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id k0GA63E00992 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, Read Section 3.2: ... Where more than one parameter is included in a message, the parameters may be in any order, except where explicitly mandated. A receiver SHOULD accept the parameters in any order. ... --brian On Mon, 16 Jan 2006, Sergey Mikhailov wrote: >=20 > Hi, >=20 >=20 >=20 > It seems quite open to interpretation (from 3.2 and 3.6.1 = of > 3332bis05), whether Destination Point Code, Service Indicators a= nd > Originating Point Code List parameters (which may be repeated as= a > grouping) must follow in exactly this order or not. >=20 >=20 >=20 > From 3.6.1: >=20 >=20 >=20 > Note: The Destination Point Code, Service Indicators, and > Originating Point Code List parameters MAY be repeated as a > grouping within the Routing Key parameter, in the structu= re > shown > above. > It think that there is now requirement to their ordering inside= a > grouping, but have to admit that this is just my interprertation. >=20 > Any opinions? >=20 >=20 >=20 >=20 >=20 > Best Regards, >=20 > Sergey Mikhailov. > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 16 05:25:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyRYZ-00087N-EO; Mon, 16 Jan 2006 05:25:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyRYX-00084u-UY for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 05:25:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01007 for ; Mon, 16 Jan 2006 05:24:21 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyRgQ-00036T-UB for Sigtran@ietf.org; Mon, 16 Jan 2006 05:33:56 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0GANSNS027614; Mon, 16 Jan 2006 02:23:38 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <013701c61a87$11bffde0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "Brian F. G. Bidulock" References: <00e001c61a80$661adb50$150f0f0a@smikhailov> <20060116030602.A31344@openss7.org> Subject: Re: [Sigtran] Ordering within RK parameter of M3UA Date: Mon, 16 Jan 2006 13:24:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1243/Sun Jan 15 10:35:18 2006 on linkbit2 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by linkbit2.linkbit.com id k0GANSNS027614 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, thank you for your reply. Do you mean that the phrase "MAY be repeated as a grouping within the Routing Key parameter, in the structure shown above" (in that Note from 3.6.1) explicitly mandates (like mentioned in 3.2) the ordering? Or it ha= s just illustrative meaning? Regards, Sergey Mikhailov. ----- Original Message -----=20 From: "Brian F. G. Bidulock" To: "Sergey Mikhailov" Cc: "SIGTRAN" Sent: Monday, January 16, 2006 1:06 PM Subject: Re: [Sigtran] Ordering within RK parameter of M3UA > Sergey, > > Read Section 3.2: > > ... > > Where more than one parameter is included in a message, the > parameters may be in any order, except where explicitly mandated. A > receiver SHOULD accept the parameters in any order. > ... > > --brian > > On Mon, 16 Jan 2006, Sergey Mikhailov wrote: > >> >> Hi, >> >> >> >> It seems quite open to interpretation (from 3.2 and 3.6.1 = of >> 3332bis05), whether Destination Point Code, Service Indicators = and >> Originating Point Code List parameters (which may be repeated a= s a >> grouping) must follow in exactly this order or not. >> >> >> >> From 3.6.1: >> >> >> >> Note: The Destination Point Code, Service Indicators, and >> Originating Point Code List parameters MAY be repeated as a >> grouping within the Routing Key parameter, in the struct= ure >> shown >> above. >> It think that there is now requirement to their ordering insid= e a >> grouping, but have to admit that this is just my interprertation. >> >> Any opinions? >> >> >> >> >> >> Best Regards, >> >> Sergey Mikhailov. > >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www1.ietf.org/mailman/listinfo/sigtran > > > --=20 > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 > bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 > http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 > =A6 Therefore all progress depends on the =A6 > =A6 unreasonable man. -- George Bernard Shaw =A6 > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 16 06:20:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySPg-0004ho-Tq; Mon, 16 Jan 2006 06:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySPg-0004ha-0C for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 06:20:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04273 for ; Mon, 16 Jan 2006 06:19:15 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[T4o1ZS7L+rPWQ5WIgVIa+fvO4fttQTC9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EySXZ-0004bi-EB for Sigtran@ietf.org; Mon, 16 Jan 2006 06:28:50 -0500 Received: from ns.pigworks.openss7.net (IDENT:nQq+9UmdKveDPfGPHHC9rmz/XzCHsPEm@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0GBKaE02581; Mon, 16 Jan 2006 04:20:36 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0GBKaL32599; Mon, 16 Jan 2006 04:20:36 -0700 Date: Mon, 16 Jan 2006 04:20:35 -0700 From: "Brian F. G. Bidulock" To: Sergey Mikhailov Subject: Re: [Sigtran] Ordering within RK parameter of M3UA Message-ID: <20060116042035.A32475@openss7.org> Mail-Followup-To: Sergey Mikhailov , SIGTRAN References: <00e001c61a80$661adb50$150f0f0a@smikhailov> <20060116030602.A31344@openss7.org> <013701c61a87$11bffde0$150f0f0a@smikhailov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <013701c61a87$11bffde0$150f0f0a@smikhailov>; from smikhailov@linkbit.com on Mon, Jan 16, 2006 at 01:24:29PM +0300 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id k0GBKaE02581 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, Logically, the repeated structure only needs to start with Destination Point Code (to identify a new group of parameters). The order of the parameters other than DPC within the repeated structure is unimportant. Likely, Local-RK-Identifier and Traffic Mode should come first, but they don't have to. So, one would expect to find Local-RK-Identifier somewhere within the lis= t of parameters, and, optionally, a Traffic Mode somewhere within the list = of parameters, an at least one Destination Point Code somewhere within the l= ist of parameters. The optional parameters associated with a given DPC would occur between the DPC and either the next DPC or the end of the Routing K= ey. Is this not obvious to you? --brian On Mon, 16 Jan 2006, Sergey Mikhailov wrote: > Brian, >=20 > thank you for your reply. >=20 > Do you mean that the phrase "MAY be repeated as a grouping within the > Routing Key parameter, in the structure shown above" (in that Note from > 3.6.1) explicitly mandates (like mentioned in 3.2) the ordering? Or it = has > just illustrative meaning? >=20 > Regards, > Sergey Mikhailov. >=20 >=20 >=20 > ----- Original Message -----=20 > From: "Brian F. G. Bidulock" > To: "Sergey Mikhailov" > Cc: "SIGTRAN" > Sent: Monday, January 16, 2006 1:06 PM > Subject: Re: [Sigtran] Ordering within RK parameter of M3UA >=20 >=20 > > Sergey, > > > > Read Section 3.2: > > > > ... > > > > Where more than one parameter is included in a message, the > > parameters may be in any order, except where explicitly mandated. A > > receiver SHOULD accept the parameters in any order. > > ... > > > > --brian > > > > On Mon, 16 Jan 2006, Sergey Mikhailov wrote: > > > >> > >> Hi, > >> > >> > >> > >> It seems quite open to interpretation (from 3.2 and 3.6.= 1 of > >> 3332bis05), whether Destination Point Code, Service Indicator= s and > >> Originating Point Code List parameters (which may be repeated= as a > >> grouping) must follow in exactly this order or not. > >> > >> > >> > >> From 3.6.1: > >> > >> > >> > >> Note: The Destination Point Code, Service Indicators, and > >> Originating Point Code List parameters MAY be repeated as a > >> grouping within the Routing Key parameter, in the stru= cture > >> shown > >> above. > >> It think that there is now requirement to their ordering ins= ide a > >> grouping, but have to admit that this is just my interprertation. > >> > >> Any opinions? > >> > >> > >> > >> > >> > >> Best Regards, > >> > >> Sergey Mikhailov. > > > >> _______________________________________________ > >> Sigtran mailing list > >> Sigtran@ietf.org > >> https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > --=20 > > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the = =A6 > > bidulock@openss7.org =A6 world; the unreasonable one persists in = =A6 > > http://www.openss7.org/ =A6 trying to adapt the world to himself. = =A6 > > =A6 Therefore all progress depends on the =A6 > > =A6 unreasonable man. -- George Bernard Shaw =A6 > > --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 16 06:52:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySud-0004Of-3r; Mon, 16 Jan 2006 06:52:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySuc-0004OC-0a for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 06:52:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06135 for ; Mon, 16 Jan 2006 06:51:13 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyT2W-0005ce-Sk for Sigtran@ietf.org; Mon, 16 Jan 2006 07:00:49 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0GBoZT3028211; Mon, 16 Jan 2006 03:50:35 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <015101c61a93$37661730$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: References: <00e001c61a80$661adb50$150f0f0a@smikhailov> <20060116030602.A31344@openss7.org> <013701c61a87$11bffde0$150f0f0a@smikhailov> <20060116042035.A32475@openss7.org> Subject: Re: [Sigtran] Ordering within RK parameter of M3UA Date: Mon, 16 Jan 2006 14:51:35 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1243/Sun Jan 15 10:35:18 2006 on linkbit2 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by linkbit2.linkbit.com id k0GBoZT3028211 X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, thank you for this explanation. If we accept this limitation (DPC always starts the repeated structure),=20 then the following Routing Key parameter, containing parameters in the=20 specified order, is incorrect (and receiver must reply with ERROR message= ),=20 even though it can be read unambiguously: Local-RK-Identifier Routing Context Traffic Mode Type DPC OPC List OPC List DPC Is it obvious for receiver to consider this message incorrect rather than= to=20 accept it (since the second OPC List is clearly related to the second DPC= )? To say generally, is it incorrect in this particular situation for a=20 receiver to judge on the message correctness by ability to read it=20 unambiguously? (Because it seems there is no explicitly mandated ordering= =20 specified regarding DPC, is there?) Thank you very much, Sergey Mikhailov. ----- Original Message -----=20 From: "Brian F. G. Bidulock" To: "Sergey Mikhailov" Cc: "SIGTRAN" Sent: Monday, January 16, 2006 2:20 PM Subject: Re: [Sigtran] Ordering within RK parameter of M3UA > Sergey, > > Logically, the repeated structure only needs to start with Destination > Point Code (to identify a new group of parameters). The order of > the parameters other than DPC within the repeated structure is > unimportant. Likely, Local-RK-Identifier and Traffic Mode should come > first, but they don't have to. > > So, one would expect to find Local-RK-Identifier somewhere within the l= ist > of parameters, and, optionally, a Traffic Mode somewhere within the lis= t=20 > of > parameters, an at least one Destination Point Code somewhere within the= =20 > list > of parameters. The optional parameters associated with a given DPC wou= ld > occur between the DPC and either the next DPC or the end of the Routing= =20 > Key. > > Is this not obvious to you? > > --brian > > On Mon, 16 Jan 2006, Sergey Mikhailov wrote: > >> Brian, >> >> thank you for your reply. >> >> Do you mean that the phrase "MAY be repeated as a grouping within the >> Routing Key parameter, in the structure shown above" (in that Note fro= m >> 3.6.1) explicitly mandates (like mentioned in 3.2) the ordering? Or it= =20 >> has >> just illustrative meaning? >> >> Regards, >> Sergey Mikhailov. >> >> >> >> ----- Original Message -----=20 >> From: "Brian F. G. Bidulock" >> To: "Sergey Mikhailov" >> Cc: "SIGTRAN" >> Sent: Monday, January 16, 2006 1:06 PM >> Subject: Re: [Sigtran] Ordering within RK parameter of M3UA >> >> >> > Sergey, >> > >> > Read Section 3.2: >> > >> > ... >> > >> > Where more than one parameter is included in a message, the >> > parameters may be in any order, except where explicitly mandated. = A >> > receiver SHOULD accept the parameters in any order. >> > ... >> > >> > --brian >> > >> > On Mon, 16 Jan 2006, Sergey Mikhailov wrote: >> > >> >> >> >> Hi, >> >> >> >> >> >> >> >> It seems quite open to interpretation (from 3.2 and 3.6= .1=20 >> >> of >> >> 3332bis05), whether Destination Point Code, Service Indicato= rs=20 >> >> and >> >> Originating Point Code List parameters (which may be repeate= d=20 >> >> as a >> >> grouping) must follow in exactly this order or not. >> >> >> >> >> >> >> >> From 3.6.1: >> >> >> >> >> >> >> >> Note: The Destination Point Code, Service Indicators, and >> >> Originating Point Code List parameters MAY be repeated as = a >> >> grouping within the Routing Key parameter, in the=20 >> >> structure >> >> shown >> >> above. >> >> It think that there is now requirement to their ordering=20 >> >> inside a >> >> grouping, but have to admit that this is just my interprertation. >> >> >> >> Any opinions? >> >> >> >> >> >> >> >> >> >> >> >> Best Regards, >> >> >> >> Sergey Mikhailov. >> > >> >> _______________________________________________ >> >> Sigtran mailing list >> >> Sigtran@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/sigtran >> > >> > >> > --=20 >> > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the= =A6 >> > bidulock@openss7.org =A6 world; the unreasonable one persists in = =A6 >> > http://www.openss7.org/ =A6 trying to adapt the world to himself.= =A6 >> > =A6 Therefore all progress depends on the = =A6 >> > =A6 unreasonable man. -- George Bernard Shaw = =A6 >> > > > --=20 > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 > bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 > http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 > =A6 Therefore all progress depends on the =A6 > =A6 unreasonable man. -- George Bernard Shaw =A6 >=20 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 16 07:57:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyTvU-0004Hc-DK; Mon, 16 Jan 2006 07:57:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyTvS-0004HX-5J for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 07:57:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09849 for ; Mon, 16 Jan 2006 07:56:09 -0500 (EST) Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyU3K-0007p5-B8 for sigtran@ietf.org; Mon, 16 Jan 2006 08:05:45 -0500 Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id C367F3469C8 for ; Mon, 16 Jan 2006 04:57:20 -0800 (PST) Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id B639F3469C7 for ; Mon, 16 Jan 2006 04:57:20 -0800 (PST) Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 04:57:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jan 2006 18:27:15 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F02C1D04@in-exchange> Thread-Topic: Regarding IUA - TEI Query Request message in RFC 4233 Thread-Index: AcYanGBAabaLoi69RKqvMvOqRSOi4Q== From: "Ravi Kanojia" To: X-OriginalArrivalTime: 16 Jan 2006 12:57:18.0735 (UTC) FILETIME=[61F5B1F0:01C61A9C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Subject: [Sigtran] Regarding IUA - TEI Query Request message in RFC 4233 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0653872994==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0653872994== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61A9C.5FFD84C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61A9C.5FFD84C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 While going through latest IUA RFC (RFC 4233), we observed that a new management message "TEI query request" added. Management messages for IUA (RFC 4233) and DUA have an overlap i.e. the same message number has been used twice =20 Message Group 0 & Message Type 5=20 IUA - TEI query request, and DUA - DLC status request. =20 What will be the possible resolution of this issue? =20 Best Regards, Ravi Kanojia ------_=_NextPart_001_01C61A9C.5FFD84C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

 

=

While going through latest IUA RFC (RFC 4233), we observed that a new management = message “TEI query request” added.

Management messages for IUA (RFC 4233) and DUA have an overlap i.e. the same = message number has been used twice

 

=

Message Group 0 & Message Type 5

IUA = - TEI query request, and

DUA = - DLC status request.

 

=

What will be the possible = resolution of this issue?

 

=

Best = Regards,

Ravi Kanojia

------_=_NextPart_001_01C61A9C.5FFD84C0-- --===============0653872994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0653872994==-- From sigtran-bounces@ietf.org Mon Jan 16 08:01:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyTzB-000573-PV; Mon, 16 Jan 2006 08:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyTz9-00056p-U3 for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 08:01:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10069 for ; Mon, 16 Jan 2006 07:59:59 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[u+Lxecb2F40fuu4XLFaw6uGYFpO1yggS]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyU71-0007yC-3w for Sigtran@ietf.org; Mon, 16 Jan 2006 08:09:35 -0500 Received: from ns.pigworks.openss7.net (IDENT:mctXfVJ6KfCn2LdTgRwaKu4q2F0k2eV0@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0GD1EE04415; Mon, 16 Jan 2006 06:01:14 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0GD1D101668; Mon, 16 Jan 2006 06:01:14 -0700 Date: Mon, 16 Jan 2006 06:01:13 -0700 From: "Brian F. G. Bidulock" To: Sergey Mikhailov Subject: Re: [Sigtran] Ordering within RK parameter of M3UA Message-ID: <20060116060113.B32475@openss7.org> Mail-Followup-To: Sergey Mikhailov , SIGTRAN References: <00e001c61a80$661adb50$150f0f0a@smikhailov> <20060116030602.A31344@openss7.org> <013701c61a87$11bffde0$150f0f0a@smikhailov> <20060116042035.A32475@openss7.org> <015101c61a93$37661730$150f0f0a@smikhailov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <015101c61a93$37661730$150f0f0a@smikhailov>; from smikhailov@linkbit.com on Mon, Jan 16, 2006 at 02:51:35PM +0300 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id k0GD1EE04415 X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, You are welcome to accept it. --brian On Mon, 16 Jan 2006, Sergey Mikhailov wrote: > Brian, > thank you for this explanation. >=20 > If we accept this limitation (DPC always starts the repeated structure)= ,=20 > then the following Routing Key parameter, containing parameters in the=20 > specified order, is incorrect (and receiver must reply with ERROR messa= ge),=20 > even though it can be read unambiguously: >=20 > Local-RK-Identifier > Routing Context > Traffic Mode Type > DPC > OPC List > OPC List > DPC >=20 > Is it obvious for receiver to consider this message incorrect rather th= an to=20 > accept it (since the second OPC List is clearly related to the second D= PC)? > To say generally, is it incorrect in this particular situation for a=20 > receiver to judge on the message correctness by ability to read it=20 > unambiguously? (Because it seems there is no explicitly mandated orderi= ng=20 > specified regarding DPC, is there?) >=20 >=20 > Thank you very much, > Sergey Mikhailov. >=20 >=20 >=20 > ----- Original Message -----=20 > From: "Brian F. G. Bidulock" > To: "Sergey Mikhailov" > Cc: "SIGTRAN" > Sent: Monday, January 16, 2006 2:20 PM > Subject: Re: [Sigtran] Ordering within RK parameter of M3UA >=20 >=20 > > Sergey, > > > > Logically, the repeated structure only needs to start with Destinatio= n > > Point Code (to identify a new group of parameters). The order of > > the parameters other than DPC within the repeated structure is > > unimportant. Likely, Local-RK-Identifier and Traffic Mode should com= e > > first, but they don't have to. > > > > So, one would expect to find Local-RK-Identifier somewhere within the= list > > of parameters, and, optionally, a Traffic Mode somewhere within the l= ist=20 > > of > > parameters, an at least one Destination Point Code somewhere within t= he=20 > > list > > of parameters. The optional parameters associated with a given DPC w= ould > > occur between the DPC and either the next DPC or the end of the Routi= ng=20 > > Key. > > > > Is this not obvious to you? > > > > --brian > > > > On Mon, 16 Jan 2006, Sergey Mikhailov wrote: > > > >> Brian, > >> > >> thank you for your reply. > >> > >> Do you mean that the phrase "MAY be repeated as a grouping within th= e > >> Routing Key parameter, in the structure shown above" (in that Note f= rom > >> 3.6.1) explicitly mandates (like mentioned in 3.2) the ordering? Or = it=20 > >> has > >> just illustrative meaning? > >> > >> Regards, > >> Sergey Mikhailov. > >> > >> > >> > >> ----- Original Message -----=20 > >> From: "Brian F. G. Bidulock" > >> To: "Sergey Mikhailov" > >> Cc: "SIGTRAN" > >> Sent: Monday, January 16, 2006 1:06 PM > >> Subject: Re: [Sigtran] Ordering within RK parameter of M3UA > >> > >> > >> > Sergey, > >> > > >> > Read Section 3.2: > >> > > >> > ... > >> > > >> > Where more than one parameter is included in a message, the > >> > parameters may be in any order, except where explicitly mandated.= A > >> > receiver SHOULD accept the parameters in any order. > >> > ... > >> > > >> > --brian > >> > > >> > On Mon, 16 Jan 2006, Sergey Mikhailov wrote: > >> > > >> >> > >> >> Hi, > >> >> > >> >> > >> >> > >> >> It seems quite open to interpretation (from 3.2 and 3= .6.1=20 > >> >> of > >> >> 3332bis05), whether Destination Point Code, Service Indica= tors=20 > >> >> and > >> >> Originating Point Code List parameters (which may be repea= ted=20 > >> >> as a > >> >> grouping) must follow in exactly this order or not. > >> >> > >> >> > >> >> > >> >> From 3.6.1: > >> >> > >> >> > >> >> > >> >> Note: The Destination Point Code, Service Indicators, an= d > >> >> Originating Point Code List parameters MAY be repeated a= s a > >> >> grouping within the Routing Key parameter, in the=20 > >> >> structure > >> >> shown > >> >> above. > >> >> It think that there is now requirement to their ordering=20 > >> >> inside a > >> >> grouping, but have to admit that this is just my interprertati= on. > >> >> > >> >> Any opinions? > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> Best Regards, > >> >> > >> >> Sergey Mikhailov. > >> > > >> >> _______________________________________________ > >> >> Sigtran mailing list > >> >> Sigtran@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/sigtran > >> > > >> > > >> > --=20 > >> > Brian F. G. Bidulock =A6 The reasonable man adapts himself to t= he =A6 > >> > bidulock@openss7.org =A6 world; the unreasonable one persists i= n =A6 > >> > http://www.openss7.org/ =A6 trying to adapt the world to himsel= f. =A6 > >> > =A6 Therefore all progress depends on th= e =A6 > >> > =A6 unreasonable man. -- George Bernard Sha= w =A6 > >> > > > > > --=20 > > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the = =A6 > > bidulock@openss7.org =A6 world; the unreasonable one persists in = =A6 > > http://www.openss7.org/ =A6 trying to adapt the world to himself. = =A6 > > =A6 Therefore all progress depends on the =A6 > > =A6 unreasonable man. -- George Bernard Shaw =A6 > >=20 --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 16 08:37:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyUYF-0006zJ-0T; Mon, 16 Jan 2006 08:37:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyUYD-0006z8-E1 for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 08:37:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13394 for ; Mon, 16 Jan 2006 08:36:12 -0500 (EST) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyUg0-0001PG-Ps for sigtran@ietf.org; Mon, 16 Jan 2006 08:45:49 -0500 Received: from [194.95.73.187] (unknown [194.95.73.187]) by ilsa.franken.de (Postfix) with ESMTP id EF1E5245CD; Mon, 16 Jan 2006 14:37:16 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F02C1D04@in-exchange> References: <22F058C3ED9D784E90CE473F2A9847F02C1D04@in-exchange> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <1588fc67db22fbc05de8e0a281428ec7@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Sigtran] Regarding IUA - TEI Query Request message in RFC 4233 Date: Mon, 16 Jan 2006 14:37:13 +0100 To: "Ravi Kanojia" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hmmm, from http://www.iana.org/assignments/sigtran-adapt Management (MGMT) Message (0) Value Description Reference ----- --------------------------------------- --------- 0 Error (ERR) =20 [RFC3057],[RFC3331],[RFC3332], [RFC3868], =20 [draft-ietf-sigtran-dua-07.txt], [RFC3807] 1 Notify (NTFY) =20 [RFC3057],[RFC3331],[RFC3332], [RFC3868], =20 [draft-ietf-sigtran-dua-07.txt], [RFC3807] 2 TEI Status Request [RFC3057],[RFC3807] 3 TEI Status Confirm [RFC3057],[RFC3807] 4 TEI Status Indication [RFC3057],[RFC3807] 5 DLC Status Request =20 [draft-ietf-sigtran-dua-07.txt] 6 DLC Status Confirm =20 [draft-ietf-sigtran-dua-07.txt] 7 DLC Status Indication =20 [draft-ietf-sigtran-dua-07.txt] Is it possible that IANA missed the assignment for the TEI query=20 request? Was there an IANA considerations section in the ID? (I have to admitt that=20= I never looked at the ID). Best regards Michael On Jan 16, 2006, at 13:57 Uhr, Ravi Kanojia wrote: > > Hi, > =A0 > While going through latest IUA RFC (RFC 4233), we observed that a new=20= > management message =93TEI query request=94 added. > Management messages for IUA (RFC 4233) and DUA have an overlap i.e.=20 > the same message number has been used twice > =A0 > Message Group 0 & Message Type 5 > IUA - TEI query request, and > DUA - DLC status request. > =A0 > What will be the possible resolution of this issue? > =A0 > Best Regards, > Ravi Kanojia > _______________________________________________ > 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 From sigtran-bounces@ietf.org Mon Jan 16 08:49:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyUjc-0002KW-S4; Mon, 16 Jan 2006 08:49:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyUjb-0002Hm-1H for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 08:49:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14027 for ; Mon, 16 Jan 2006 08:47:57 -0500 (EST) Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyUrV-0001ka-FM for sigtran@ietf.org; Mon, 16 Jan 2006 08:57:35 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 4DEB148592 for ; Mon, 16 Jan 2006 08:48:52 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k0GDmnMi024076 for ; Mon, 16 Jan 2006 08:48:51 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Date: Mon, 16 Jan 2006 08:29:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060114024749.89621.qmail@web35403.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Stanislav Ivanovich Sent: Friday, January 13, 2006 9:48 PM To: SIGTRAN Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs Dear Brian and Tolga, First, thank you Tolga and Brian, indeed very much for your great contribution and patience both of you show to all of us SIGTRAN implementors every single day by answering long questions! Please, I kindly ask you to have just a little bit more patience with this (in my view) very essential issue. As we have seen here whatever question one arise (in this case multiple SG'es or something else) he/she will finish at the core of the issue which I am to be honest very afraid of. Brian, I really see no problems in understanding AS concepts when they apply on interface between MTP3/SCCP and their user-functions or in-between two user-functions whatever you call the hosting processes. However when one applies this concept in between two MTP3/SCCP instances I have tremendous conceptual problems. I understand your proposal Brian and this seems reasonable -> if one does not want/like the AS concept in between two MTP3/SCCP instances then he/she does not need to use it (to be honest I thought it was mandatory since RC was mandatory parameter is DATA messages of SUA but now I see that this is not the case). However if one vendor supports this (because he understands this) and my company does not support this (because I do not understand it) this brings my company in serious disadvantage! Therefore regardless of implementation of a particular feature the xxUA protocols offer I first need to fully understand all the capabilities/possibilities the specifications give me. [TOLGA]Actually using one RK on an association does not change anything much in terms of using "AS concept". It still is there, just implicitly identified. My point is that in my current understanding AS concept in between two MTP3/SCCP instances brings me just restrictions (i.e. some configurations are not possible), while OTOH I get nothing "in-return" (e.g. better redundancy... etc). In my view SGP-SGP brings you the same redundancy as ASP-SGP and IPSP-IPSP protocols while it does not impose any kind of restrictions. Which restrictions? Here are just few of them: 1) if AS is to be used in between 2 MTP3/SCCP instances then it implies that AS represents an SS7 destination. However in MTP3/SCCP networks relay can be easily built because when one sends traffic it is irrelevant what is the state of the sending entity. What only matters is the accessibility state of remote destination. For example if I have SGP connected to ASP equipped with relay which serves local user for 2-100 and supports relay for 2-200 then according to xxUA specifications ASP must not send (!) traffic until it is not prepared to receive any. So ASP has to activate its (local) receiver for 2-100 just to make 2-200 possible to send traffic over it to SGP!?! Why this? This! would imply that ASP has to register 2-200 at SGP also what is very different from SCCP/MTP3 relay. In MTP3/SCCP networks one can have a sender sending over relay and receiving traffic over another independent relay. My comment is -> This has serious consequence on building of relay networks based on these AS principles. It is obvious why in both M3UA and SUA specifications it is explicitly said ASP is not allowed to send (!) until it is activated itself within an AS at SGP (thus be able to receive) -> this is how User Parts (or SCCP users) work: if they are not connected to MTP3/SCCP layers then they will not be able to either send or receive traffic. However if we do not understand AS'es as MTP3/SCCP user functions but as SS7 addresses in between two MTP3/SCCP instances then this becomes serious restriction. Note that removing restriction for ASP/IPSP to send (!) traffic regardless of its activation within an AS is not "administrative" but has serious technical consequence -> moving of SSNM messages from SGP to ASP from ACTIVE to DOWN state... [TOLGA]It is clear that ASP/SGP interface mimics MTP3/MTP-User and SCCP/SCCP-User interfaces for M3UA and SUA respectively. Hence, the corresponding MTP3, SCCP logic resides in SG. This is a nice model if SG does not act as STP.If SG acts as STP, MTP3 logic for AS is hosted at SG. As it stands right now, there is no relaying based on ASP/SGP model in M3UA -what "SUA relay" really means is a question mark to me, I personally think it probably is something similar to SG-SG for SUA based on PC+ SSN routing. IPSP for M3UA does not support realying and I think it doesn't for SUA as well. If one looks to the relationship between two MTP3-instances, one sees that it is a peer-to-peer relationship between two network layer entities. Such a relationship supports relaying. The relationship between MTP3/MTP3-User is a client/server relationship and does not support relaying. The relationship between two AS is a special one, is peer-to-peer but on application level and thus it is not logical to think of relaying there on signaling transport level. 2) In traditional MTP/SCCP networks one can have destination SPC1 reachable over two STP functions STP1 and STP2 while SPC2 reachable over only STP1 for example. However by having the AS concept one is not allowed to have at SPCx place (for example an IPSP) an SS7 address in two different AS'es. So AS1 cannot be (SPC1, SPC2) and STP1 is a process supporting AS1 while AS2 is (SPC1) and STP2 is supporting AS2. Because of resolution problems at SPCx place which must have AS configuration in this way: AS1 (SPC1) supported by STP1 and STP2 and AS2 (SPC2) supported by STP1 one must introduce 2 AS'es at STP1 place! This kind of influence of one node on the configuration of other one you cannot find in traditional SS7 networks! Another practical problem! [TOLGA]My first question to you is, why do you think that relaying using AS constructs is supported? It isn't -I excluse SUA realy here because I don't know what it officially means-. ! 3) Please Brian, I kindly ask you to make your opinion about this (I would very much appreciate opinions of other SUA RFC co-authors as well!) -> if we allow that ASP/IPSP hosts MTP3/SCCP layers then this is not only against basic definition in the SUA paper itself: e.g. SUA RFC section 1.2.2. "Terminology": "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-peer fashion." but even more -> this is very serious conceptual problem! Why do we define several process types and 2 different protocols if there is no difference between the processes? By reading all the threads last weeks I see that even ASP can send SSNM messages towards SGP, IPSP can send and receive SSNM so actually even the difference between the protocols themselves disappears! [TOLGA]This is not true, ASP can send only SCON -which IMO is a bug in M3UA/SUA, we should have had ASPCONG from very early on, Brian started to work on a draft for this-. The same holds true between IPSPs. This is very serious conceptual problem for which I haven't still received any convincing answer -> the only answers I received are these: ---------------------------------------- [John Loughney] "Process-types, in my view, are illustrative text, to give an implementor an idea of what we are talking about - however, they are not meant that each capability MUST be implemented as a separate process." ---------------------------------------- [John Loughney] "The notion of a process, IMO, is an implementation issue - different OSes may behave different." ---------------------------------------- see thread "[Sigtran] AS concepts and Relay in SUA and M3UA" I am really very sorry but this does not sound very convincing, does it? 4) If the essence of the AS concept is a redundancy ! concept (AS is served by several signaling processes) then there is no redundancy scheme which SGP-SGP concept does not provide and which could be provided by existing protocols (ASP-SGP and IPSP-IPSP). However advantage if SGP-SGP model is that it does not suffer from the restrictions/problems described in point 1-3 above. However SGP-SGP concept provides us with the resolution of all the problems described in points 1-3 above and at the same time it preserves the existing protocols and keeps the signaling process definition clear and consistent! Tolga, Thank you for your comments! I do not only understand this: [Tolga Asveren] "AFAICS, the main advantage of ASP/SGP model is to allow routing on AS level, i.e. in sub-PC granularity." In my view this is not effectively possible. Yes, one can have AS co! nfigured as User Part of SCCP SSN (i.e. granularity below SPC). However, in my view, this does not imply that relay based on this is effectively possible! This is for the following reasons: 1) How would STP based on finer granularity support this kind of management? When a process receives DUPU indicating UPU or SSP then it will not try to divert traffic to another "STP" since it assumes that the user function is dead rather then STP connection to it. Especially if we are to relay that UPU/SSP message into SS7 network... [TOLGA]I meant it in the other direction, i.e. for messages from SG to ASPs. The practical value of this depends also on the internal communication mechanisms of ASPs but still could be useful is SLS type of routing is not good enough, e.g. one has two applications on different SSN and prefers that ASP1 receives traffic for app1 and ASP2 for app2 unless one of them fails. This of course is only for ASP/SGP communication. 2) Different types of traffic granularity require support for different types of Traffic Management in order to support relay based on different granularities. ANSI MTP is a good example -> there you can find the concept of Cluster Destinations. However the essence of this concept is that it is unique granularity across all the STP nodes&nb! sp;which is not the subject of "bilateral" agreement between two adjacent STP nodes what we have with IPSP processes equipped with relay capability. In other words in ANSI MTP networks all the STP across the network that is to use Cluster concept use the same (!) traffic granularity which is supported by the same Traffic Management which is not subject to agreement between two STP nodes but spans across the whole network. In xxUA networks we have management by SSNM and AS is the agreement between two adjacent nodes... All in all - in my opinion not very efficient... [TOLGA]IPSP does not support relaying and if you look to the definition of it it simply doesn't make sense forcing it to support relaying. It is a direct relationship between two applications and any necessary relaying should happen on application layer, not on signaling transport. Overall, I think I agree with you. Thank you both Brian and Tolga once again for your great support to SIGTRAN community as well as your patience! with best regards/ Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Neither the ASP-SGP nor IPSP-IPSP models require you to use AS or RC. Define 1 AS per ASP only and give it RC value 0. Make that AS an entire point code (or network appearance for that matter). Then this RK:AS:RC 3-tuple that bothers you so much falls away. --brian Stanislav Ivanovich wrote: (Fri, 13 Jan 2006 12:19:29) > > Hello, > > > > In addition to the last mail: > > > > The original idea was to have one user function at ASP connected to 2 > SGW (thus two independent SCCP/MTP layers). So in order to solve this > we said -> we need an (i.e. 1) MTP/SCCP layer at ASP place which is to > communicate with independent MTP/SCCP layers at SGW'es side. > > > > However here you again have one user function connected to one > MTP/SCCP layer. This ! is exactly what the Tolga's SGP-SGP solution > covers. The only difference is that ASP-SGP and IPSP-IPSP protocols do > mandate use of AS concepts with all the restrictions which imply from > these protocols... which we do not have in SGP-SGP protocol. > > > > So again we have very fundamental question -> what does AS/RC concept > provide us with on the interface between two MTP/SCCP relay equipped > processes? > > > > It brings us just restrictions and problems nothing else! > > > > / stanislav > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 16 20:04:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyfHH-0000Zn-Qe; Mon, 16 Jan 2006 20:04:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyfHG-0000Zi-L7 for sigtran@megatron.ietf.org; Mon, 16 Jan 2006 20:04:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00608 for ; Mon, 16 Jan 2006 20:03:25 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyfPI-00049U-Gs for sigtran@ietf.org; Mon, 16 Jan 2006 20:13:08 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 16 Jan 2006 17:04:41 -0800 X-IronPort-AV: i="3.99,374,1131350400"; d="scan'208"; a="392399652:sNHT45188082" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0H14eQi022767; Mon, 16 Jan 2006 17:04:40 -0800 (PST) Received: from xmb-rtp-209.amer.cisco.com ([64.102.31.11]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 20:04:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] Regarding IUA - TEI Query Request message in RFC 4233 Date: Mon, 16 Jan 2006 20:04:38 -0500 Message-ID: <542F2F9C2CDE6B40A775125727674ECA010D4280@xmb-rtp-209.amer.cisco.com> Thread-Topic: [Sigtran] Regarding IUA - TEI Query Request message in RFC 4233 Thread-Index: AcYaopb3s3Enr59SRUmA6yHuXJFQMgAX1X0Q From: "Ken A Morneault \(kmorneau\)" To: "Michael Tuexen" , "Ravi Kanojia" X-OriginalArrivalTime: 17 Jan 2006 01:04:39.0991 (UTC) FILETIME=[FE2CE470:01C61B01] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Yes, it looks like this was missed. I'll talk to Lyndon about it. =20 Regards, Ken -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On = Behalf Of Michael Tuexen Sent: Monday, January 16, 2006 8:37 AM To: Ravi Kanojia Cc: sigtran@ietf.org Subject: Re: [Sigtran] Regarding IUA - TEI Query Request message in RFC = 4233 Hmmm, from http://www.iana.org/assignments/sigtran-adapt Management (MGMT) Message (0) Value Description Reference ----- --------------------------------------- --------- 0 Error (ERR) =20 [RFC3057],[RFC3331],[RFC3332], [RFC3868], =20 [draft-ietf-sigtran-dua-07.txt], [RFC3807] 1 Notify (NTFY) =20 [RFC3057],[RFC3331],[RFC3332], [RFC3868], =20 [draft-ietf-sigtran-dua-07.txt], [RFC3807] 2 TEI Status Request [RFC3057],[RFC3807] 3 TEI Status Confirm [RFC3057],[RFC3807] 4 TEI Status Indication [RFC3057],[RFC3807] 5 DLC Status Request =20 [draft-ietf-sigtran-dua-07.txt] 6 DLC Status Confirm =20 [draft-ietf-sigtran-dua-07.txt] 7 DLC Status Indication =20 [draft-ietf-sigtran-dua-07.txt] Is it possible that IANA missed the assignment for the TEI query = request? Was there an IANA considerations section in the ID? (I have to = admitt that I never looked at the ID). Best regards Michael On Jan 16, 2006, at 13:57 Uhr, Ravi Kanojia wrote: > > Hi, > =A0 > While going through latest IUA RFC (RFC 4233), we observed that a new=20 > management message "TEI query request" added. > Management messages for IUA (RFC 4233) and DUA have an overlap i.e.=20 > the same message number has been used twice > =A0 > Message Group 0 & Message Type 5 > IUA - TEI query request, and > DUA - DLC status request. > =A0 > What will be the possible resolution of this issue? > =A0 > Best Regards, > Ravi Kanojia > _______________________________________________ > 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 From sigtran-bounces@ietf.org Tue Jan 17 11:11:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytQS-0002M2-3Z; Tue, 17 Jan 2006 11:11:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytQP-0002LD-RT for sigtran@megatron.ietf.org; Tue, 17 Jan 2006 11:11:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27239 for ; Tue, 17 Jan 2006 11:09:49 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EytYY-0005qO-Qe for sigtran@ietf.org; Tue, 17 Jan 2006 11:19:40 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k0HGB3CD021330 for ; Tue, 17 Jan 2006 10:11:04 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Jan 2006 21:41:02 +0530 Message-ID: <3BE48DD0EC7D3948BC183931D9150C210316ABE6@ii0015exch001u.iprc.lucent.com> From: "S, Girish (Girish)" To: sigtran@ietf.org Date: Tue, 17 Jan 2006 21:41:00 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sigtran] M3UA RFC 3332 - Sec 4.3.1 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi, Please help me in understanding the significance of the "Local management intervention" in the following section from RFC 3332... **************************************************************************** ******************************** 4.3.1 ASP States The state of each remote ASP, in each AS that it is configured to operate, is maintained in the M3UA layer in the SGP. The state of a particular ASP in a particular AS changes due to events. The events include: * Reception of messages from the peer M3UA layer at the ASP; * Reception of some messages from the peer M3UA layer at other ASPs in the AS (e.g., ASP Active message indicating "Override"); * Reception of indications from the SCTP layer; or * Local Management intervention. **************************************************************************** ******************************** What would this mean ... ? How do I change the ASP state using this...? Regards, Girish _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 17 11:21:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyta9-00063n-QA; Tue, 17 Jan 2006 11:21:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyta8-00063d-78 for sigtran@megatron.ietf.org; Tue, 17 Jan 2006 11:21:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27954 for ; Tue, 17 Jan 2006 11:19:51 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[fjE51Oq7YCU9WK5V6JiYtxTLUgpzAwyF]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EytiF-0006AX-0t for sigtran@ietf.org; Tue, 17 Jan 2006 11:29:42 -0500 Received: from ns.pigworks.openss7.net (IDENT:/RgNHjeyW9hQ4c0xWI0HDRbyzoPnvShs@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0HGKpE09662; Tue, 17 Jan 2006 09:20:52 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0HGKn020060; Tue, 17 Jan 2006 09:20:49 -0700 Date: Tue, 17 Jan 2006 09:20:48 -0700 From: "Brian F. G. Bidulock" To: "S, Girish (Girish)" Subject: Re: [Sigtran] M3UA RFC 3332 - Sec 4.3.1 Message-ID: <20060117092048.D16429@openss7.org> Mail-Followup-To: "S, Girish (Girish)" , sigtran@ietf.org References: <3BE48DD0EC7D3948BC183931D9150C210316ABE6@ii0015exch001u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3BE48DD0EC7D3948BC183931D9150C210316ABE6@ii0015exch001u.iprc.lucent.com>; from girishs@lucent.com on Tue, Jan 17, 2006 at 09:41:00PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org S,, Using the Layer Management defined in Section 1.6.3. --brian S, Girish (Girish) wrote: (Tue, 17 Jan 2006 21:41:00) > Hi, > Please help me in understanding the significance of the "Local management > intervention" in the following section from RFC 3332... > > **************************************************************************** > ******************************** > 4.3.1 ASP States > > The state of each remote ASP, in each AS that it is configured to > operate, is maintained in the M3UA layer in the SGP. The state of a > particular ASP in a particular AS changes due to events. The events > include: > > * Reception of messages from the peer M3UA layer at the ASP; > * Reception of some messages from the peer M3UA layer at other ASPs > in the AS (e.g., ASP Active message indicating "Override"); > * Reception of indications from the SCTP layer; or > * Local Management intervention. > **************************************************************************** > ******************************** > > What would this mean ... ? How do I change the ASP state using this...? > > Regards, > > Girish > > > _______________________________________________ > 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 From sigtran-bounces@ietf.org Tue Jan 17 11:26:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytfK-0007lA-GY; Tue, 17 Jan 2006 11:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytfI-0007kB-Al for sigtran@megatron.ietf.org; Tue, 17 Jan 2006 11:26:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28371 for ; Tue, 17 Jan 2006 11:25:10 -0500 (EST) Received: from phl-28-b-170.phl.dsl.cerfnet.com ([63.242.157.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EytnP-0006LN-OE for sigtran@ietf.org; Tue, 17 Jan 2006 11:35:01 -0500 Received: from bn001320 (bn001320 [192.168.1.61]) by phl-28-b-170.phl.dsl.cerfnet.com (8.12.8/8.12.8) with SMTP id k0HGQPoj023389 for ; Tue, 17 Jan 2006 11:26:26 -0500 From: "Barry Nagelberg" To: Subject: RE: [Sigtran] M3UA RFC 3332 - Sec 4.3.1 Date: Tue, 17 Jan 2006 11:28:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3BE48DD0EC7D3948BC183931D9150C210316ABE6@ii0015exch001u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Girish, This is implementation-dependent. An implementation may offer a user interface through which the SGP-user could set the "administration" state of the ASP. For example, if the user doesn't want to accept a connection from a certain ASP, she/he could set the ASP "administration" state to INACTIVE. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of S, Girish (Girish) Sent: Tuesday, January 17, 2006 11:11 AM To: sigtran@ietf.org Subject: [Sigtran] M3UA RFC 3332 - Sec 4.3.1 Hi, Please help me in understanding the significance of the "Local management intervention" in the following section from RFC 3332... **************************************************************************** ******************************** 4.3.1 ASP States The state of each remote ASP, in each AS that it is configured to operate, is maintained in the M3UA layer in the SGP. The state of a particular ASP in a particular AS changes due to events. The events include: * Reception of messages from the peer M3UA layer at the ASP; * Reception of some messages from the peer M3UA layer at other ASPs in the AS (e.g., ASP Active message indicating "Override"); * Reception of indications from the SCTP layer; or * Local Management intervention. **************************************************************************** ******************************** What would this mean ... ? How do I change the ASP state using this...? Regards, Girish _______________________________________________ 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 From sigtran-bounces@ietf.org Tue Jan 17 23:59:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez5QE-00056b-TQ; Tue, 17 Jan 2006 23:59:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez5QA-00054z-TI for sigtran@megatron.ietf.org; Tue, 17 Jan 2006 23:59:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03234 for ; Tue, 17 Jan 2006 23:58:21 -0500 (EST) Received: from web53801.mail.yahoo.com ([206.190.36.196]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ez5YO-0001Jf-UJ for sigtran@ietf.org; Wed, 18 Jan 2006 00:08:19 -0500 Received: (qmail 44569 invoked by uid 60001); 18 Jan 2006 04:59:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QWmDACi0PIIGK+YWydM6cKj0TXlhlab3CGmyOprYHwX7QeK4Pf6hf9jYJOjTEwfyEeqo6aByF18QJujRLaWabMaPDPM75lZgLlDt12nVBP8p/EDh00dGHs57rQIHrqO6WH60uTH9NMuDQWNlElpA2ZAilOLtbGKKclbPK0NvgA0= ; Message-ID: <20060118045934.44563.qmail@web53801.mail.yahoo.com> Received: from [220.227.128.163] by web53801.mail.yahoo.com via HTTP; Tue, 17 Jan 2006 20:59:34 PST Date: Tue, 17 Jan 2006 20:59:34 -0800 (PST) From: Saraswati Bose To: Brian Bidulock , sigtran MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Sigtran] IUA: error conditions X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1903618957==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1903618957== Content-Type: multipart/alternative; boundary="0-1823800243-1137560374=:43694" Content-Transfer-Encoding: 8bit --0-1823800243-1137560374=:43694 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian, 1. Should we encode error message as " protocol error" in response to QOTM message received with IUA message header fields missing like DLCI etc? Or can we discard the message simply? 2. Should SG encode error message "protocol error" against DATA/UNITDATA INDICATION message received from ASP?Or can we discard the message simply? 3. Should ASP encode error message " protocol error" against DATA/UNITDATA REQ message received from SG?Or can we discard the message simply? Regards, Saraswati. --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1823800243-1137560374=:43694 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Brian,
 
1. Should we encode error message as " protocol error" in response to QOTM message received with IUA message header fields missing like DLCI etc? Or can we discard the message simply?
 
2. Should SG encode error message "protocol error" against DATA/UNITDATA INDICATION message received from ASP?Or can we discard the message simply?
 
3. Should ASP encode error message " protocol error" against DATA/UNITDATA REQ message received from SG?Or can we discard the message simply?
 
Regards,
Saraswati.

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1823800243-1137560374=:43694-- --===============1903618957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1903618957==-- From sigtran-bounces@ietf.org Wed Jan 18 00:34:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez5xN-0004cX-GS; Wed, 18 Jan 2006 00:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez5xL-0004bQ-Go for sigtran@megatron.ietf.org; Wed, 18 Jan 2006 00:34:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05995 for ; Wed, 18 Jan 2006 00:32:38 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[2Le4EX2SM/HbJZeoEoKi+7UOwwIkUVdu]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez65b-0002VC-AR for sigtran@ietf.org; Wed, 18 Jan 2006 00:42:36 -0500 Received: from ns.pigworks.openss7.net (IDENT:12fYX6W24Z6xhEmVGfUDALyzi3LWiSla@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0I5XmE03931; Tue, 17 Jan 2006 22:33:48 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0I5XmA01244; Tue, 17 Jan 2006 22:33:48 -0700 Date: Tue, 17 Jan 2006 22:33:47 -0700 From: "Brian F. G. Bidulock" To: Saraswati Bose Subject: Re: [Sigtran] IUA: error conditions Message-ID: <20060117223347.A1020@openss7.org> Mail-Followup-To: Saraswati Bose , sigtran References: <20060118045934.44563.qmail@web53801.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060118045934.44563.qmail@web53801.mail.yahoo.com>; from saraswatibose@yahoo.com on Tue, Jan 17, 2006 at 08:59:34PM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sigtran X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Saraswati, Saraswati Bose wrote: (Tue, 17 Jan 2006 20:59:34) > > Hi Brian, > > > > 1. Should we encode error message as " protocol error" in response to > QOTM message received with IUA message header fields missing like DLCI > etc? Or can we discard the message simply? > Sure. Another option is to drop the link or abort the association, because the peer has violated a requirement. > > > 2. Should SG encode error message "protocol error" against > DATA/UNITDATA INDICATION message received from ASP?Or can we discard > the message simply? > Come now... Read "Unexpected Message" under RFC 3057 Section 3.3.3.1. > > > 3. Should ASP encode error message " protocol error" against > DATA/UNITDATA REQ message received from SG?Or can we discard the > message simply? > Again, read "Unexpected Message" under RFC 3057 Section 3.3.3.1. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 18 03:59:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez99k-0007Ll-L0; Wed, 18 Jan 2006 03:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez99i-0007Lg-Ny for sigtran@megatron.ietf.org; Wed, 18 Jan 2006 03:59:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19638 for ; Wed, 18 Jan 2006 03:57:36 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez9I0-0000Ku-2X for sigtran@ietf.org; Wed, 18 Jan 2006 04:07:37 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k0I8wnLM001260; Wed, 18 Jan 2006 02:58:50 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Jan 2006 14:28:46 +0530 Message-ID: <3BE48DD0EC7D3948BC183931D9150C210316ABEA@ii0015exch001u.iprc.lucent.com> From: "S, Girish (Girish)" To: "'Barry Nagelberg'" , "'bidulock@openss7.org'" Subject: RE: [Sigtran] M3UA RFC 3332 - Sec 4.3.1 Date: Wed, 18 Jan 2006 14:26:18 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Thanks Barry, Brian, Barry, Brian and All, I wanted to know about this specific scenario which I picked from one of the previous discussions sometime back where, we have the following stacks at the both the ends. ******** IP ******** *IPSP-A* *IPSP-B* ******** ******** +------+ +------+ |SCCP- | |SCCP- | | User | | User | +------+ +------+ | SCCP | | SCCP | +------+ +------+ | M3UA | | M3UA | +------+ +------+ | SCTP | | SCTP | +------+ +------+ | IP | | IP | +------+ +------+ |________________| Scenario in question is as follows, 1. At the bring up time, SCCP-User at IPSP-A is not ready or "blocked" by the operator. 2. Layer Management of M3UA triggers the setting up of SCTP association and start of M3UA procedures. 3. This causes an ASP Active to be sent from IPSP-A to IPSP-B, indicating that the IPSP-A is ready to process signaling traffic for a particular application server. (But the SCCP-User at IPSP-A is still "blocked") Considering that the above sequence is to be maintained my question is, does the M3UA standard allow IPSP-A to make use of the "local management intervention" so that IPSP-A does not receive any traffic from IPSP-B until the SCCP-User becomes "not blocked" ? Section 1.4.5 of RFC 3332 says, "Local Management at an ASP may wish to stop traffic across an SCTP association to temporarily remove the association from service or to perform testing and maintenance activity. The function could optionally be used to control the start of traffic on to a newly available SCTP association." Any thoughts ? Regards, Girish -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Barry Nagelberg Sent: Tuesday, January 17, 2006 9:58 PM To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA RFC 3332 - Sec 4.3.1 Girish, This is implementation-dependent. An implementation may offer a user interface through which the SGP-user could set the "administration" state of the ASP. For example, if the user doesn't want to accept a connection from a certain ASP, she/he could set the ASP "administration" state to INACTIVE. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of S, Girish (Girish) Sent: Tuesday, January 17, 2006 11:11 AM To: sigtran@ietf.org Subject: [Sigtran] M3UA RFC 3332 - Sec 4.3.1 Hi, Please help me in understanding the significance of the "Local management intervention" in the following section from RFC 3332... **************************************************************************** ******************************** 4.3.1 ASP States The state of each remote ASP, in each AS that it is configured to operate, is maintained in the M3UA layer in the SGP. The state of a particular ASP in a particular AS changes due to events. The events include: * Reception of messages from the peer M3UA layer at the ASP; * Reception of some messages from the peer M3UA layer at other ASPs in the AS (e.g., ASP Active message indicating "Override"); * Reception of indications from the SCTP layer; or * Local Management intervention. **************************************************************************** ******************************** What would this mean ... ? How do I change the ASP state using this...? Regards, Girish _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 18 08:05:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzD03-0007hz-11; Wed, 18 Jan 2006 08:05:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzD00-0007hq-Nc for sigtran@megatron.ietf.org; Wed, 18 Jan 2006 08:05:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10182 for ; Wed, 18 Jan 2006 08:03:50 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[i8HzE5t72L9ji+eUP04uWjrL9fkpAOmJ]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzD8I-0000dY-3z for sigtran@ietf.org; Wed, 18 Jan 2006 08:13:53 -0500 Received: from ns.pigworks.openss7.net (IDENT:yUMDKRI4/TWeAo7WMe9RcO2FnZC9evON@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0ID56E12948; Wed, 18 Jan 2006 06:05:06 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0ID55j24964; Wed, 18 Jan 2006 06:05:05 -0700 Date: Wed, 18 Jan 2006 06:05:05 -0700 From: "Brian F. G. Bidulock" To: "S, Girish (Girish)" Subject: Re: [Sigtran] M3UA RFC 3332 - Sec 4.3.1 Message-ID: <20060118060505.A32578@openss7.org> Mail-Followup-To: "S, Girish (Girish)" , 'Barry Nagelberg' , sigtran@ietf.org References: <3BE48DD0EC7D3948BC183931D9150C210316ABEA@ii0015exch001u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3BE48DD0EC7D3948BC183931D9150C210316ABEA@ii0015exch001u.iprc.lucent.com>; from girishs@lucent.com on Wed, Jan 18, 2006 at 02:26:18PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: 'Barry Nagelberg' , sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org S,, You say the SCCP User is blocked, but not SCCP, correct? The SCCP-User at IPSP-B will not send traffic to the SCCP-User at IPSP-A until it receives SSA for the subsystem (which is currently prohibited). If the SCCP layer at IPSP-A receives traffic for an unavailable subsystem it will respond with SSP. --brian S, Girish (Girish) wrote: (Wed, 18 Jan 2006 14:26:18) > Thanks Barry, Brian, > > Barry, Brian and All, > > I wanted to know about this specific scenario which I picked from one of the > previous discussions sometime back where, we have the following stacks at > the both the ends. > > ******** IP ******** > *IPSP-A* *IPSP-B* > ******** ******** > > +------+ +------+ > |SCCP- | |SCCP- | > | User | | User | > +------+ +------+ > | SCCP | | SCCP | > +------+ +------+ > | M3UA | | M3UA | > +------+ +------+ > | SCTP | | SCTP | > +------+ +------+ > | IP | | IP | > +------+ +------+ > |________________| > > Scenario in question is as follows, > 1. At the bring up time, SCCP-User at IPSP-A is not ready or "blocked" by > the operator. > 2. Layer Management of M3UA triggers the setting up of SCTP association and > start of M3UA procedures. > 3. This causes an ASP Active to be sent from IPSP-A to IPSP-B, indicating > that the IPSP-A is ready to process signaling traffic for a particular > application server. (But the SCCP-User at IPSP-A is still "blocked") > > Considering that the above sequence is to be maintained my question is, does > the M3UA standard allow IPSP-A to make use of the "local management > intervention" so that IPSP-A does not receive any traffic from IPSP-B until > the SCCP-User becomes "not blocked" ? > > Section 1.4.5 of RFC 3332 says, > > "Local Management at an ASP may wish to stop traffic across an SCTP > association to temporarily remove the association from service or to perform > testing and maintenance activity. The function could optionally be used to > control the start of traffic on to a newly available SCTP association." > > Any thoughts ? > > Regards, > > Girish -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Jan 18 10:34:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFKF-0002uy-M2; Wed, 18 Jan 2006 10:34:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFKE-0002uq-Gl for sigtran@megatron.ietf.org; Wed, 18 Jan 2006 10:34:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25351 for ; Wed, 18 Jan 2006 10:32:51 -0500 (EST) Received: from [200.123.145.66] (helo=ad01.voipgroup.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzFSZ-0006Uj-4s for sigtran@ietf.org; Wed, 18 Jan 2006 10:42:56 -0500 MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Jan 2006 12:34:04 -0300 Message-ID: <1553FEFFDAE48E45B2D0AB20777EB57B297250@ad01.voipgroup.com> Thread-Topic: Start Point Thread-Index: AcYcRKEBHQxgaCtuRsCBeUI6QlJ1Wg== From: "Fernando BERRETTA" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [Sigtran] Start Point X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1492602023==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1492602023== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61C44.9D3D6DD0" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C61C44.9D3D6DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I'm new in Sigtran and I'm analyzing to implement it on our softswitch, where should I begin? Can someone help me? =20 Best Regards, Fernando =20 ------_=_NextPart_001_01C61C44.9D3D6DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I’m new in Sigtran and I’m analyzing to implement it on our softswitch, where should I begin? Can someone help = me?

 

Best Regards,

Fernando

 

------_=_NextPart_001_01C61C44.9D3D6DD0-- --===============1492602023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1492602023==-- From sigtran-bounces@ietf.org Wed Jan 18 12:58:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHZr-00057v-LQ; Wed, 18 Jan 2006 12:58:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHZp-00057l-VH for sigtran@megatron.ietf.org; Wed, 18 Jan 2006 12:58:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09019 for ; Wed, 18 Jan 2006 12:57:08 -0500 (EST) Received: from web37014.mail.mud.yahoo.com ([209.191.85.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzHiD-0003al-6z for sigtran@ietf.org; Wed, 18 Jan 2006 13:07:13 -0500 Received: (qmail 68948 invoked by uid 60001); 18 Jan 2006 17:58:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.nz; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5y9rBpIIio6K+Q376NDy6LP+YfbXzG4SzRRGTmM+rUQZ6/pwGEDtbZRkBb64/yX9Z4gLcjtzmfP9AjzpbZ0+a2fDIjYlZy5pCdZSpDFeZmUVyGBtv0ToT3RDvJXgj5hiHYt59SyagcX8G/fr7jVrKP7mXoLR5XKnJbPxCvyHc1M= ; Message-ID: <20060118175824.68946.qmail@web37014.mail.mud.yahoo.com> Received: from [212.117.81.29] by web37014.mail.mud.yahoo.com via HTTP; Thu, 19 Jan 2006 06:58:24 NZDT Date: Thu, 19 Jan 2006 06:58:24 +1300 (NZDT) From: Siu Chai Tho To: SIGTRAN MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sigtran] M3UA and SUA recommendations X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2012232755==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============2012232755== Content-Type: multipart/alternative; boundary="0-1462215019-1137607104=:67890" --0-1462215019-1137607104=:67890 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA09019 Hello SIGTRAN community ! =20 I have been reading the responses to questions posted on threads "Upper boundary of Adaptation Layers" http://www1.ietf.org/mail-archive/w= eb/sigtran/current/msg05691.html and "Some very fundamental SIGTRAN question" http://www1.ietf.org/mail-ar= chive/web/sigtran/current/msg05771.html and I wonder if my understanding of SIGTRAN standards is still right: =20 1) SUA and M3UA define signalling transport of SCCP-/MTP-user traffic o= ver an IP network =20 2) The terminology "=85 User Adaptation Layer" (name of the RFCs) seems= to define a layer, even though layer boundaries are not mandated to be f= ollowed by implementations. I also see that chapter 1.6 describes boundar= ies of this layer (are these just informative chapters ?). Even though an= implementation is free to not use layers, the M3UA/SUA protocol function= s are defined by use of a SUA/M3UA layer encapsulating protocol functions= such as signalling processes, state machines and other stuff. =20 3) I understand the concept of signalling processes ASP/IPSP and SGP as= entities that are seen as communication endpoints of SUA/M3UA protocol. = Is it correct to assume that these concepts only apply within the boundar= ies described in chapter 1.6 or are these concepts defined across those b= oundaries i.e. does the N-UNITDATA include ASP/IPSP identification ?? E.g. can any SCCP-user run over SUA without knowing about signalling proc= esses (how many, what type, etc.) as long as the upper boundary defined i= n chapter 1.6.1 is preserved ? =20 4) Is it possible to map (inside SUA layer) traffic from a single SCCP= -user (or MTP-user) instance (SCCP-SAP/MTP-SAP) into several SUA/M3UA com= munication flows managed by several (local) ASPs as well as mapping traff= ic from multiple SCCP-user (or MTP-user) instances into a single (local) = ASP ?=20 =20 5) Is it possible that multiple signalling processes share the same SCT= P endpoint (but different SCTP associations) for sending/receiveing messa= ges ? Example : Can I run ASP process (talking to a SGP) and an IPSP (talki= ng to another IPSP) over the same SCTP endpoint ? =20 6) Is the recommendation of a layered implementation seen as a benefit = or best current practice ? =20 Thank you Joe Send instant messages to your online friends http://au.messenger.yahoo.co= m=20 --0-1462215019-1137607104=:67890 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA09019
Hello SIGTRAN community !
 
=
I have been reading the responses to questions posted on threads
= "Upper boundary of Adaptation Layers" http://www1.ietf.org/mail-ar= chive/web/sigtran/current/msg05691.html
and "Some very fundamental= SIGTRAN question" http://www1.ietf.org/mail-archive/web/sigtran/c= urrent/msg05771.html
and I wonder if my understanding of SIGTRAN s= tandards is still right:
 
1) SUA and M3UA d= efine signalling transport of SCCP-/MTP-user traffic over an IP network
 
2) The terminology "=85 User Adaptation Lay= er" (name of the RFCs) seems to define a layer, even though layer bo= undaries are not mandated to be followed by implementations. I also see t= hat chapter 1.6 describes boundaries of this layer (are these just informative chapters ?). Even though an implementation i= s free to not use layers, the M3UA/SUA protocol functions are defined by = use of a SUA/M3UA layer encapsulating protocol functions such as signalli= ng processes, state machines and other stuff.
 
<= DIV>3) I understand the concept of signalling processes ASP/IPSP and SGP = as entities that are seen as communication endpoints of SUA/M3UA pro= tocol. Is it correct to assume that these concepts only apply within the = boundaries described in chapter 1.6 or are these concepts defined ac= ross those boundaries i.e. does the N-UNITDATA include ASP/IPSP iden= tification ??
E.g. can any SCCP-user run over SUA without knowing abou= t signalling processes (how many, what type, etc.) as long as the up= per boundary defined in chapter 1.6.1 is preserved ?
 
4) Is it possible to map (inside  SUA layer) traffic from= a single SCCP-user (or MTP-user) instance (SCCP-SAP/MTP-SAP) into several SUA/M3UA communication flows manage= d by several (local) ASPs as well as mapping traffic from multiple S= CCP-user (or MTP-user) instances into a single (local) ASP ?
 
5) Is it possible that multiple signalling processes = share the same SCTP endpoint (but different SCTP associations) for s= ending/receiveing messages ?
    Example : Can I run AS= P process (talking to a SGP) and an IPSP (talking to another IPSP) over t= he same SCTP endpoint ?
 
6) Is the rec= ommendation of a layered implementation seen as a benefit or best current= practice ?

Thank you
Joe

Send instan= t messages to your online friends http://au.messenger.yahoo.com=20 --0-1462215019-1137607104=:67890-- --===============2012232755== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============2012232755==-- From sigtran-bounces@ietf.org Wed Jan 18 13:36:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIAO-00072T-76; Wed, 18 Jan 2006 13:36:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIAN-00072N-Bu for sigtran@megatron.ietf.org; Wed, 18 Jan 2006 13:36:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11566 for ; Wed, 18 Jan 2006 13:34:53 -0500 (EST) Received: from web35413.mail.mud.yahoo.com ([66.163.179.122]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzIIg-0004h4-Ah for sigtran@ietf.org; Wed, 18 Jan 2006 13:44:59 -0500 Received: (qmail 88208 invoked by uid 60001); 18 Jan 2006 18:36:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5Xijz1xglAMMd9qazgzbhn12G21vMThNjKYWagFoebSjkq49gQUPm82fwb5ULmwgp0vaQFpWsM19+Z94ZrlKDtd7HIaG0H6u9AKGGIMaIm1KrX+/prM7qKF8nktlv4W0YCNm7gac984vP/fqTyDMZrstl8zzVYfZmdgCOODmNSQ= ; Message-ID: <20060118183600.88202.qmail@web35413.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35413.mail.mud.yahoo.com via HTTP; Wed, 18 Jan 2006 10:36:00 PST Date: Wed, 18 Jan 2006 10:36:00 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060118175824.68946.qmail@web37014.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0561978701==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0561978701== Content-Type: multipart/alternative; boundary="0-63822662-1137609360=:85983" --0-63822662-1137609360=:85983 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA11566 Siu Chai, =20 Please look bellow for the answers from my point of view. =20 / Stanisalv Ivanovich =20 Siu Chai Tho wrote: Hello SIGTRAN community ! =20 I have been reading the responses to questions posted on threads "Upper boundary of Adaptation Layers" http://www1.ietf.org/mail-archive/w= eb/sigtran/current/msg05691.html and "Some very fundamental SIGTRAN question" http://www1.ietf.org/mail-ar= chive/web/sigtran/current/msg05771.html and I wonder if my understanding of SIGTRAN standards is still right: =20 1) SUA and M3UA define signalling transport of SCCP-/MTP-user traffic o= ver an IP network [Stanislav Ivanovich] The specifications do much more than that. They e= ssentialy define a concept of application redundacy which is controlled b= y ASP SM/TM messages. =20 2) The terminology "=85 User Adaptation Layer" (name of the RFCs) seems= to define a layer, even though layer boundaries are not mandated to be f= ollowed by implementations. I also see that chapter 1.6 describes boundar= ies of this layer (are these just informative chapters ?). Even though an= implementation is free to not use layers, the M3UA/SUA protocol function= s are defined by use of a SUA/M3UA layer encapsulating protocol functions= such as signalling processes, state machines and other stuff. =20 [Stanislav Ivanovich] What specifications do tell you is how should sig= nalling processes behave on the external protocol and what is the functio= nality the prcesses should contain. Internal structure of signalling proc= esses is irrelevant for specifications. =20 =20 3) I understand the concept of signalling processes ASP/IPSP and SGP as= entities that are seen as communication endpoints of SUA/M3UA protocol. = Is it correct to assume that these concepts only apply within the boundar= ies described in chapter 1.6 or are these concepts defined across those b= oundaries i.e. does the N-UNITDATA include ASP/IPSP identification ?? =20 [Stanislav Ivanovich] No! ASP and IPSP are processes which contain user= functions what is not the case for SGP. For example SGP-ASP protocol is = designed to model communication between MTP3 and MTP3-user function for M= 3UA or SCCP and SCCP-user function for SUA. So ASP is container into whic= h you load your user function. The essentce of the AS concepts (which mak= e 80% of specifications for both M3UA and SUA) is that it supports applic= ation redundancy by means of ASP SM/TM messages. =20 Thus you have an ASP into which you load a traffic control application = and which is represented to SGP as AS =3D"ISUP for 2-100". Then if you wa= nt application redundacy you clone your application so you load it in ano= ther process (ASP2) and which connects to SGP for the same AS=3D"ISUP for= 2-100". So by means of AS related messages/concepts you control your app= lication reliability by supporting application redundancy. =20 =20 E.g. can any SCCP-user run over SUA without knowing about signalling proc= esses (how many, what type, etc.) as long as the upper boundary defined i= n chapter 1.6.1 is preserved ? [Stanislav Ivanovich] Yes, but as I said it is irrelevant for specifica= tions. They only mandate how your user function (ASP) is to behave extern= ally. Nothing else, nothing more. =20 =20 =20 4) Is it possible to map (inside SUA layer) traffic from a single SCCP= -user (or MTP-user) instance (SCCP-SAP/MTP-SAP) into several SUA/M3UA com= munication flows managed by several (local) ASPs as well as mapping traff= ic from multiple SCCP-user (or MTP-user) instances into a single (local) = ASP ?=20 =20 [Stanislav Ivanovich] Application granularity (ie. AS representation in= SS7 language) is implementation choice thus not subject to specification= s. But the specifications allow you to define your applications very flex= ibly (e.g. ISUP + BICC for DPC=3D2-100 shall be 1 AS). =20 =20 =20 5) Is it possible that multiple signalling processes share the same SCT= P endpoint (but different SCTP associations) for sending/receiveing messa= ges ? Example : Can I run ASP process (talking to a SGP) and an IPSP (talki= ng to another IPSP) over the same SCTP endpoint ? [Stanislav Ivanovich] Yes. =20 =20 6) Is the recommendation of a layered implementation seen as a benefit = or best current practice ? =20 [Stanislav Ivanovich] Again. This is implementation. You cannot answer = thuis queston by looking into xxUA specifications but instead by looking = into your current SS7 implementation product descriptions, sequence diagr= ams etc... =20 Thank you Joe Send instant messages to your online friends http://au.messenger.yahoo.= com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran =20 =09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! --0-63822662-1137609360=:85983 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA11566

Siu Chai,
 
Please look bellow for the = answers from my point of view.
 
/ Stanisalv= Ivanovich


Siu Chai Tho <siuchaitho@yahoo.co= .nz> wrote:
Hello SIGTRAN community !
 
I hav= e been reading the responses to questions posted on threads
"Upper bou= ndary of Adaptation Layers" http://www1.ietf.org/mail-archive/web/= sigtran/current/msg05691.html
and "Some very fundamental SIGTRAN q= uestion" http://www1.ietf.org/mail-archive/web/sigtran/current/msg= 05771.html
and I wonder if my understanding of SIGTRAN standards i= s still right:
 
1) SUA and M3UA define signalling transport of SCCP-/MTP-user traffic over an IP ne= twork
[Stanislav Ivanovich] The specifications do much more t= han that. They essentialy define a concept of application redundacy which= is controlled by ASP SM/TM messages.
 
2) T= he terminology "=85 User Adaptation Layer" (name of the RFCs) seems to de= fine a layer, even though layer boundaries are not mandated to be fo= llowed by implementations. I also see that chapter 1.6 describes boundari= es of this layer (are these just informative chapters ?). Even thoug= h an implementation is free to not use layers, the M3UA/SUA protocol func= tions are defined by use of a SUA/M3UA layer encapsulating protocol funct= ions such as signalling processes, state machines and other stuff.
=
 
[Stanislav Ivanovich] What specifications do tel= l you is how should signalling processes behave on the external protocol = and what is the functionality the prcesses should contain. Internal structure of signalling processes is irrelevant for sp= ecifications.
 
 
3) I unde= rstand the concept of signalling processes ASP/IPSP and SGP as entities t= hat are seen as communication endpoints of SUA/M3UA protocol. Is it = correct to assume that these concepts only apply within the boundaries&nb= sp;described in chapter 1.6 or are these concepts defined across those bo= undaries i.e. does the N-UNITDATA include ASP/IPSP identification ??=
 
[Stanislav Ivanovich] No! ASP and IPSP ar= e processes which contain user functions what is not the case for SGP. Fo= r example SGP-ASP protocol is designed to model communication between MTP= 3 and MTP3-user function for M3UA or SCCP and SCCP-user function for SUA.= So ASP is container into which you load your user function. The essentce= of the AS concepts (which make 80% of specifications for both M3UA and S= UA) is that it supports application redundancy by means of ASP SM/TM messages.
 
Thus you hav= e an ASP into which you load a traffic control application and which is r= epresented to SGP as AS =3D"ISUP for 2-100". Then if you want application= redundacy you clone your application so you load it in another process (= ASP2) and which connects to SGP for the same AS=3D"ISUP for 2-100". So by= means of AS related messages/concepts you control your application relia= bility by supporting application redundancy.
 

E.g. can any SCCP-user run over SUA without knowing about signalli= ng processes (how many, what type, etc.) as long as the upper bounda= ry defined in chapter 1.6.1 is preserved ?
[Stanislav Ivanovi= ch] Yes, but as I said it is irrelevant for specifications. They only man= date how your user function (ASP) is to behave externally. Nothing else, = nothing more.
 
 
 
4) Is it possible to map (inside  SUA layer) traffic from a single SCCP-user (or MTP-user) instance (SCCP-SAP/= MTP-SAP) into several SUA/M3UA communication flows managed by severa= l (local) ASPs as well as mapping traffic from multiple SCCP-user (o= r MTP-user) instances into a single (local) ASP ?
 
[Stanislav Ivanovich] Application granularity (ie. AS representa= tion in SS7 language) is implementation choice thus not subject to specif= ications. But the specifications allow you to define your applications ve= ry flexibly (e.g. ISUP + BICC for DPC=3D2-100 shall be 1 AS).
 
 
 
5) Is it possib= le that multiple signalling processes share the same SCTP endpoint (but d= ifferent SCTP associations) for sending/receiveing messages ?
&nb= sp;   Example : Can I run ASP process (talking to a SGP) and an= IPSP (talking to another IPSP) over the same SCTP endpoint ?
=
[Stanislav Ivanovich] Yes.
=20
 
 
6) Is the recommendation of a= layered implementation seen as a benefit or best current practice ?
 
[Stanislav Ivanovich] Again. This is implement= ation. You cannot answer thuis queston by looking into xxUA specification= s but instead by looking into your current SS7 implementation product des= criptions, sequence diagrams etc...

Thank you
Joe
Send instant messages to your online friends http://au.m= essenger.yahoo.com _______________________________________________
Sig= tran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/li= stinfo/sigtran

Yahoo! Photos =96 Showcase holiday pictures in hardcover=20 Photo Bo= oks. You design it and we=92ll bind it! --0-63822662-1137609360=:85983-- --===============0561978701== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0561978701==-- From sigtran-bounces@ietf.org Thu Jan 19 06:03:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzXZc-0005zp-JA; Thu, 19 Jan 2006 06:03:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzXZb-0005zK-Fc for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 06:03:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11662 for ; Thu, 19 Jan 2006 06:01:55 -0500 (EST) Received: from web37008.mail.mud.yahoo.com ([209.191.85.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzXi5-0002X7-BZ for sigtran@ietf.org; Thu, 19 Jan 2006 06:12:12 -0500 Received: (qmail 12435 invoked by uid 60001); 19 Jan 2006 11:03:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.nz; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XQGimsKNNBtHGkxzmnAfowzGXtxR1LiI+5uNs/lbZ2R+cLQ4b/+TLwwnTzI4lWoixTxUKtxXWGFfmXJcr+DCu7d5Tp/uU5qPOUdur3p5RPc91iLcsbnS+cGvrddOBY0FRYl6/HdOgPUV/ICBnvhLsDofq3FK1dCJE874mJxmAL4= ; Message-ID: <20060119110311.12433.qmail@web37008.mail.mud.yahoo.com> Received: from [212.117.81.29] by web37008.mail.mud.yahoo.com via HTTP; Fri, 20 Jan 2006 00:03:11 NZDT Date: Fri, 20 Jan 2006 00:03:11 +1300 (NZDT) From: Siu Chai Tho Subject: Re: [Sigtran] M3UA and SUA recommendations To: Stanislav Ivanovich , SIGTRAN In-Reply-To: <20060118183600.88202.qmail@web35413.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0693108980==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0693108980== Content-Type: multipart/alternative; boundary="0-1901922387-1137668591=:11261" Content-Transfer-Encoding: 8bit --0-1901922387-1137668591=:11261 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Stainislav, Stanislav Ivanovich wrote: [Stanislav Ivanovich] The specifications do much more than that. They essentialy define a concept of application redundacy which is controlled by ASP SM/TM messages. [Siu Chai Tho] I not understand this. Isn't it just signalling transport redundancy that is managed and it is an option for applications to use it for application redundancy or not ? RFC 2719 does not mention anything on SIG-user redundancy. [Stanislav Ivanovich] What specifications do tell you is how should signalling processes behave on the external protocol and what is the functionality the prcesses should contain. Internal structure of signalling processes is irrelevant for specifications. [Siu Chai Tho]I feel that you have misunderstood my question. I was trying to reassure that there are boundaries of a layer defined as mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC 2719. I understand that implementations can do whatever they like and are not forced to use layers. However, what is the purpose of using the word layer when there is no layer intended ? [Stanislav Ivanovich] No! ASP and IPSP are processes which contain user functions what is not the case for SGP. For example SGP-ASP protocol is designed to model communication between MTP3 and MTP3-user function for M3UA or SCCP and SCCP-user function for SUA. So ASP is container into which you load your user function. The essentce of the AS concepts (which make 80% of specifications for both M3UA and SUA) is that it supports application redundancy by means of ASP SM/TM messages. [Siu Chai Tho] ASP and IPSP contains user functions but SGP doesn't ? Isn't it just that any signalling process is just a communication endpoint for SUA/M3UA ? The user functions at the ASP or SCCP/MTP functions at the SGP reside in their own components or am I mistaken here ? [Stanislav Ivanovich] Application granularity (ie. AS representation in SS7 language) is implementation choice thus not subject to specifications. But the specifications allow you to define your applications very flexibly (e.g. ISUP + BICC for DPC=2-100 shall be 1 AS). [Siu Chai Tho] I was trying to ask if it is possible to map one MTP/SCCP-SAP (or AS) into multiple ASPs (inside the same node). If this is an implementation option as you indicate I'm happy with the answer. 6) Is the recommendation of a layered implementation seen as a benefit or best current practice ? [Stanislav Ivanovich] Again. This is implementation. You cannot answer thuis queston by looking into xxUA specifications but instead by looking into your current SS7 implementation product descriptions, sequence diagrams etc... [Siu Chai Tho]I have again the feeling that you understood me wrong. I was asking for a reasoning of the layer recommendation inside the RFCs. How do others implement it ? Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com --0-1901922387-1137668591=:11261 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello Stainislav,

Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
[Stanislav Ivanovich] The specifications do much more than that. They essentialy define a concept of application redundacy which is controlled by ASP SM/TM messages.
 
[Siu Chai Tho] I not understand this. Isn't it just signalling transport redundancy that is managed and it is an option for applications to use it for application redundancy or not ? RFC 2719 does not mention anything on SIG-user redundancy.
[Stanislav Ivanovich] What specifications do tell you is how should signalling processes behave on the external protocol and what is the functionality the prcesses should contain. Internal structure of signalling processes is irrelevant for specifications.
 
[Siu Chai Tho]I feel that you have misunderstood my question. I was trying to reassure that there are boundaries of a layer defined as mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC 2719. I understand that implementations can do whatever they like and are not forced to use layers. However, what is the purpose of using the word layer when there is no layer intended ?
[Stanislav Ivanovich] No! ASP and IPSP are processes wh! ich contain user functions what is not the case for SGP. For example SGP-ASP protocol is designed to model communication between MTP3 and MTP3-user function for M3UA or SCCP and SCCP-user function for SUA. So ASP is container into which you load your user function. The essentce of the AS concepts (which make 80% of specifications for both M3UA and SUA) is that it supports application redundancy by means of ASP SM/TM messages.
 
[Siu Chai Tho] ASP and IPSP contains user functions but SGP doesn't ? Isn't it just that any signalling process is just a communication endpoint for SUA/M3UA ? The user functions at the ASP or SCCP/MTP functions at the SGP reside in their own components or am I mistaken here ?
[Sta! nislav Ivanovich] Application granularity (ie. AS representation in SS7 language) is implementation choice thus not subject to specifications. But the specifications allow you to define your applications very flexibly (e.g. ISUP + BICC for DPC=2-100 shall be 1 AS).
 
[Siu Chai Tho] I was trying to ask if it is possible to map one MTP/SCCP-SAP (or AS) into multiple ASPs (inside the same node). If this is an implementation option as you indicate I'm happy with the answer.
6) Is the recommendation of a layered implementation seen as a benefit or best current practice ?
 
[Stanislav Ivanovich] Again. This is implementation. You cannot answer thuis queston by looking into xxUA specifications but instead by looking into your current SS7 implementation product descriptions, sequence diagrams etc...
 
[Siu Chai Tho]I have again the feeling that you understood me wrong. I was asking for a reasoning of the layer recommendation inside the RFCs. How do others implement it ?
 
Thank you,
Joe

Send instant messages to your online friends http://au.messenger.yahoo.com --0-1901922387-1137668591=:11261-- --===============0693108980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0693108980==-- From sigtran-bounces@ietf.org Thu Jan 19 06:23:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzXtH-00032x-1l; Thu, 19 Jan 2006 06:23:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzXtF-00032s-2j for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 06:23:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12887 for ; Thu, 19 Jan 2006 06:22:13 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[mqCpJpaI9TnNwgvd9/w8HHVP1Vrb9rV8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzY1k-00037I-Dq for sigtran@ietf.org; Thu, 19 Jan 2006 06:32:29 -0500 Received: from ns.pigworks.openss7.net (IDENT:QXeXTAyctYV6V9O0vhiAb3f1R+KzpW7s@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0JBNQE05968; Thu, 19 Jan 2006 04:23:26 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0JBNPR08336; Thu, 19 Jan 2006 04:23:25 -0700 Date: Thu, 19 Jan 2006 04:23:25 -0700 From: "Brian F. G. Bidulock" To: Siu Chai Tho Subject: Re: [Sigtran] M3UA and SUA recommendations Message-ID: <20060119042325.A8110@openss7.org> Mail-Followup-To: Siu Chai Tho , Stanislav Ivanovich , SIGTRAN References: <20060118183600.88202.qmail@web35413.mail.mud.yahoo.com> <20060119110311.12433.qmail@web37008.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060119110311.12433.qmail@web37008.mail.mud.yahoo.com>; from siuchaitho@yahoo.co.nz on Fri, Jan 20, 2006 at 12:03:11AM +1300 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Siu, Siu Chai Tho wrote: (Fri, 20 Jan 2006 00:03:11) > > Hello Stainislav, > Stanislav Ivanovich wrote: > > [Stanislav Ivanovich] The specifications do much more than that. They > essentialy define a concept of application redundacy which is > controlled by ASP SM/TM messages. > > > > [Siu Chai Tho] I not understand this. Isn't it just signalling > transport redundancy that is managed and it is an option for > applications to use it for application redundancy or not ? RFC 2719 > does not mention anything on SIG-user redundancy. You are correct. > > [Stanislav Ivanovich] What specifications do tell you is how should > signalling processes behave on the external protocol and what is the > functionality the prcesses should contain. Internal structure of > signalling processes is irrelevant for specifications. > > > > [Siu Chai Tho]I feel that you have misunderstood my question. I was > trying to reassure that there are boundaries of a layer defined as > mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC 2719. > I understand that implementations can do whatever they like and are > not forced to use layers. However, what is the purpose of using the > word layer when there is no layer intended ? What would you call it then? We refer to all of these UA as SS7-User Adaptation Layers. You don't like the word 'layer'? (You will find it on every page.) > > [Stanislav Ivanovich] No! ASP and IPSP are processes wh! ich contain > user functions what is not the case for SGP. For example SGP-ASP > protocol is designed to model communication between MTP3 and MTP3-user > function for M3UA or SCCP and SCCP-user function for SUA. So ASP is > container into which you load your user function. The essentce of the > AS concepts (which make 80% of specifications for both M3UA and SUA) > is that it supports application redundancy by means of ASP SM/TM > messages. > > > > [Siu Chai Tho] ASP and IPSP contains user functions but SGP doesn't ? > Isn't it just that any signalling process is just a communication > endpoint for SUA/M3UA ? The user functions at the ASP or SCCP/MTP > functions at the SGP reside in their own components or am I mistaken > here ? Implementation dependent. Also see, for example, last paragraph of RFC 3332 Section 1.4.2.4 [Page 13]. An SGP can even host an ASP of its own (and thus a User Part). > > [Sta! nislav Ivanovich] Application granularity (ie. AS representation > in SS7 language) is implementation choice thus not subject to > specifications. But the specifications allow you to define your > applications very flexibly (e.g. ISUP + BICC for DPC=2-100 shall be 1 > AS). > > > > [Siu Chai Tho] I was trying to ask if it is possible to map one > MTP/SCCP-SAP (or AS) into multiple ASPs (inside the same node). If > this is an implementation option as you indicate I'm happy with the > answer. Implementation dependent, however, the protocol supports multiple ASPs on the same host, even with dynamic port assignment using the ASP Identifier. --brian > > 6) Is the recommendation of a layered implementation seen as a benefit > or best current practice ? > > > > [Stanislav Ivanovich] Again. This is implementation. You cannot answer > thuis queston by looking into xxUA specifications but instead by > looking into your current SS7 implementation product descriptions, > sequence diagrams etc... > > > > [Siu Chai Tho]I have again the feeling that you understood me wrong. I > was asking for a reasoning of the layer recommendation inside the > RFCs. How do others implement it ? > > > > Thank you, > > Joe > > Send instant messages to your online friends > http://au.messenger.yahoo.com > _______________________________________________ > 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 From sigtran-bounces@ietf.org Thu Jan 19 06:47:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzYGY-0001E2-0g; Thu, 19 Jan 2006 06:47:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzYGW-0001Du-55 for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 06:47:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14271 for ; Thu, 19 Jan 2006 06:46:18 -0500 (EST) Received: from web37009.mail.mud.yahoo.com ([209.191.85.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzYP1-0003nv-Pk for sigtran@ietf.org; Thu, 19 Jan 2006 06:56:33 -0500 Received: (qmail 99681 invoked by uid 60001); 19 Jan 2006 11:47:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.nz; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5d7/KcFQQUPTKe1cH5/EtKrb0P7J/kmz8C/63BnfrqzyeERIg/4P1i2HMCE2Yx5C6dLbaptTLmX/kRRY/BGWFqYXrCBK9XCrMiYW+ZW11gwWC4XKeHL8ShWqy6CghnOlFfsxdS/pb+TfrEFzISecZ/KypDGf3Lsci3RYIGneJBg= ; Message-ID: <20060119114733.99678.qmail@web37009.mail.mud.yahoo.com> Received: from [212.117.81.29] by web37009.mail.mud.yahoo.com via HTTP; Fri, 20 Jan 2006 00:47:33 NZDT Date: Fri, 20 Jan 2006 00:47:33 +1300 (NZDT) From: Siu Chai Tho Subject: Re: [Sigtran] M3UA and SUA recommendations To: bidulock@openss7.org In-Reply-To: <20060119042325.A8110@openss7.org> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1512872909==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1512872909== Content-Type: multipart/alternative; boundary="0-488162793-1137671253=:99487" Content-Transfer-Encoding: 8bit --0-488162793-1137671253=:99487 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Brian, "Brian F. G. Bidulock" wrote: > [Stanislav Ivanovich] What specifications do tell you is how should > signalling processes behave on the external protocol and what is the > functionality the prcesses should contain. Internal structure of > signalling processes is irrelevant for specifications. > > > > [Siu Chai Tho]I feel that you have misunderstood my question. I was > trying to reassure that there are boundaries of a layer defined as > mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC 2719. > I understand that implementations can do whatever they like and are > not forced to use layers. However, what is the purpose of using the > word layer when there is no layer intended ? What would you call it then? We refer to all of these UA as SS7-User Adaptation Layers. You don't like the word 'layer'? (You will find it on every page.) [Siu Chai Tho] Sorry if I express myself wrong. I understood Stanislav's answer in a way that a UA would not be layer definition, but only definition of external behaviour. I think of UAs as defined protocol layers (with boundaries as defined in chapter 1.6) and that it's current best practise to implement layers with the defined boundaries. Is this true ? Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com --0-488162793-1137671253=:99487 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hello Brian,


"Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
> [Stanislav Ivanovich] What specifications do tell you is how should
> signalling processes behave on the external protocol and what is the
> functionality the prcesses should contain. Internal structure of
> signalling processes is irrelevant for specifications.
>
>
>
> [Siu Chai Tho]I feel that you have misunderstood my question. I was
> trying to reassure that there are boundaries of a layer defined as
> mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC 2719.
> I understand that implementations can do whatever they like and are
> not forced to use layers. However, what is the purpose of using the
> word layer when there is no layer intended ?

What wou! ld you call it then? We refer to all of these UA as SS7-User
Adaptation Layers. You don't like the word 'layer'? (You will find
it on every page.)
 
[Siu Chai Tho] Sorry if I express myself wrong. I understood Stanislav's answer in a way that a UA would not be layer definition, but only definition of external behaviour. I think of UAs as defined protocol layers (with boundaries as defined in chapter 1.6) and that it's current best practise to implement layers with the defined boundaries. Is this true ?
 
Thank you,
Joe

Send instant messages to your online friends http://au.messenger.yahoo.com --0-488162793-1137671253=:99487-- --===============1512872909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1512872909==-- From sigtran-bounces@ietf.org Thu Jan 19 06:54:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzYMx-0004DC-FU; Thu, 19 Jan 2006 06:54:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzYMw-0004AA-Ip for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 06:54:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14679 for ; Thu, 19 Jan 2006 06:52:56 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[r54XE88CG2jkm6OFKFdI7hQjPlXIqP2h]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzYVS-00040V-81 for sigtran@ietf.org; Thu, 19 Jan 2006 07:03:11 -0500 Received: from ns.pigworks.openss7.net (IDENT:yArOCjUlEanM+vJk3AumEHNuqX4/Lghb@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0JBsJE06614; Thu, 19 Jan 2006 04:54:19 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0JBsJX09183; Thu, 19 Jan 2006 04:54:19 -0700 Date: Thu, 19 Jan 2006 04:54:19 -0700 From: "Brian F. G. Bidulock" To: Siu Chai Tho Subject: Re: [Sigtran] M3UA and SUA recommendations Message-ID: <20060119045419.A9167@openss7.org> Mail-Followup-To: Siu Chai Tho , SIGTRAN References: <20060119042325.A8110@openss7.org> <20060119114733.99678.qmail@web37009.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060119114733.99678.qmail@web37009.mail.mud.yahoo.com>; from siuchaitho@yahoo.co.nz on Fri, Jan 20, 2006 at 12:47:33AM +1300 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Siu, Siu Chai Tho wrote: (Fri, 20 Jan 2006 00:47:33) > > Hello Brian, > > "Brian F. G. Bidulock" wrote: > > > [Stanislav Ivanovich] What specifications do tell you is how should > > signalling processes behave on the external protocol and what is the > > functionality the prcesses should contain. Internal structure of > > signalling processes is irrelevant for specifications. > > > > > > > > [Siu Chai Tho]I feel that you have misunderstood my question. I was > > trying to reassure that there are boundaries of a layer defined as > > mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC > 2719. > > I understand that implementations can do whatever they like and are > > not forced to use layers. However, what is the purpose of using the > > word layer when there is no layer intended ? > What would you call it then? We refer to all of these UA as SS7-User > Adaptation Layers. You don't like the word 'layer'? (You will find > it on every page.) > > > > [Siu Chai Tho] Sorry if I express myself wrong. I understood > Stanislav's answer in a way that a UA would not be layer definition, > but only definition of external behaviour. I think of UAs as defined > protocol layers (with boundaries as defined in chapter 1.6) and that > it's current best practise to implement layers with the defined > boundaries. Is this true ? Yes. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 19 08:16:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZag-0005OD-07; Thu, 19 Jan 2006 08:12:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZad-0005O3-EB for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 08:12:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21302 for ; Thu, 19 Jan 2006 08:11:09 -0500 (EST) Received: from web53809.mail.yahoo.com ([206.190.36.204]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzZjA-0006zM-SP for sigtran@ietf.org; Thu, 19 Jan 2006 08:21:25 -0500 Received: (qmail 95385 invoked by uid 60001); 19 Jan 2006 13:12:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xvbtjoBCWVsEL71wl0aacRGfr1q+xhVBpwzQrDnb757mIn+gnDOhp9T66uneHHHng4YS2MPuQ+XnwKuj7aiPnGlH0U2XH/OSn/kK+fnguryFJZZEh3apb5mIa6uPHGMc+SJBP4uRoX3VzRvwUHpLQ+3fGPDO20066sg2S9L7XXY= ; Message-ID: <20060119131226.95383.qmail@web53809.mail.yahoo.com> Received: from [220.227.128.163] by web53809.mail.yahoo.com via HTTP; Thu, 19 Jan 2006 05:12:26 PST Date: Thu, 19 Jan 2006 05:12:26 -0800 (PST) From: Saraswati Bose To: Brian Bidulock , sigtran MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Sigtran] Clarification of Sequence No.Parameter-(CODT) and ias timer X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0774943245==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0774943245== Content-Type: multipart/alternative; boundary="0-7940263-1137676346=:93352" --0-7940263-1137676346=:93352 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA21302 Hi Brian, =20 When M bit of sequence number parameter in received CODT is set to 0 th= en considering that no more data will be sent by the peer should the serv= er stop ias timer? Please suggest if other wise. =20 Saraswati. =09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! --0-7940263-1137676346=:93352 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA21302

Hi Brian,
 <= /DIV>
When M bit of sequence number parameter in received CODT is s= et to 0 then considering that no more data will be sent by the peer shoul= d the server stop ias timer?
Please suggest if other wise.
 
Saraswati.

Yahoo! Photos =96 Showcase holiday pictures in hardcover=20 Photo Bo= oks. You design it and we=92ll bind it! --0-7940263-1137676346=:93352-- --===============0774943245== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0774943245==-- From sigtran-bounces@ietf.org Thu Jan 19 08:16:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZbA-0005QW-Jz; Thu, 19 Jan 2006 08:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZb9-0005QQ-5r for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 08:13:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21341 for ; Thu, 19 Jan 2006 08:11:40 -0500 (EST) Received: from web53803.mail.yahoo.com ([206.190.36.198]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzZjf-0006zz-NP for sigtran@ietf.org; Thu, 19 Jan 2006 08:21:56 -0500 Received: (qmail 73691 invoked by uid 60001); 19 Jan 2006 13:12:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0n/4Xq120sOlt0hLl10+h7pksPz+xJ+QPh8dpVQsxJlgBVTM9lAS4gqfM9aHm15hASUn5ZeYo4KaB4ySMeEOE52ucT5HfjJC+1HGWIAIbbA2B/2hXMFnQz20LK0o2vwde8aY8Om6G/A/Q54EHcu/R+At7V3Ee36GaiMpcr74wk4= ; Message-ID: <20060119131235.73689.qmail@web53803.mail.yahoo.com> Received: from [220.227.128.163] by web53803.mail.yahoo.com via HTTP; Thu, 19 Jan 2006 05:12:35 PST Date: Thu, 19 Jan 2006 05:12:35 -0800 (PST) From: Saraswati Bose To: Brian Bidulock , sigtran MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Sigtran] SUA: Sequence No. in CODT and IAS timer X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0171829357==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0171829357== Content-Type: multipart/alternative; boundary="0-162273131-1137676355=:71798" --0-162273131-1137676355=:71798 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA21341 Hi Brian, =20 When M bit of sequence number parameter in received CODT is set to 0 th= en considering that no more data will be sent by the peer should the serv= er stop ias timer? Please suggest if other wise. =20 Saraswati. =09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! --0-162273131-1137676355=:71798 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA21341
Hi Brian,
 
When M bit = of sequence number parameter in received CODT is set to 0 then considerin= g that no more data will be sent by the peer should the server stop ias t= imer?
Please suggest if other wise.
 
=
Saraswati.

Yahoo! Photos =96 Showcase holiday pictures in hardcover=20 Photo Bo= oks. You design it and we=92ll bind it! --0-162273131-1137676355=:71798-- --===============0171829357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0171829357==-- From sigtran-bounces@ietf.org Thu Jan 19 08:16:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZag-0005OM-MS; Thu, 19 Jan 2006 08:12:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZad-0005O8-Qz for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 08:12:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21305 for ; Thu, 19 Jan 2006 08:11:09 -0500 (EST) Received: from web53809.mail.yahoo.com ([206.190.36.204]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzZj9-0006zL-Vx for sigtran@ietf.org; Thu, 19 Jan 2006 08:21:25 -0500 Received: (qmail 95378 invoked by uid 60001); 19 Jan 2006 13:12:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kRKLziYCWg5NxLMNn/jRH6p5XjDNl4GufTlrTOb28zXsAtStCgVx9yMsQIrwWGLbgkp8T3Lnt/cv5HErAkZ7CNO5oQJHQdGwbOgtbd0Vyj1M6XoikZf1Zz/q80Upr0MGCt+nydFSyp9+ac8mjFyMXq1FxYIn5nQm6fBA5VNMi/M= ; Message-ID: <20060119131224.95376.qmail@web53809.mail.yahoo.com> Received: from [220.227.128.163] by web53809.mail.yahoo.com via HTTP; Thu, 19 Jan 2006 05:12:24 PST Date: Thu, 19 Jan 2006 05:12:24 -0800 (PST) From: Saraswati Bose To: Brian Bidulock , sigtran MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Sigtran] Clarification of Sequence No.Parameter-(CODT) and ias timer X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0000114895==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0000114895== Content-Type: multipart/alternative; boundary="0-576490549-1137676344=:95026" Content-Transfer-Encoding: 8bit --0-576490549-1137676344=:95026 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian, When M bit of sequence number parameter in received CODT is set to 0 then considering that no more data will be sent by the peer should the server stop ias timer? Please suggest if other wise. Saraswati. --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-576490549-1137676344=:95026 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Brian,
 
When M bit of sequence number parameter in received CODT is set to 0 then considering that no more data will be sent by the peer should the server stop ias timer?
Please suggest if other wise.
 
Saraswati.

Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-576490549-1137676344=:95026-- --===============0000114895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0000114895==-- From sigtran-bounces@ietf.org Thu Jan 19 08:16:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZeE-000632-Rg; Thu, 19 Jan 2006 08:16:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZeD-00062n-Mb for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 08:16:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21553 for ; Thu, 19 Jan 2006 08:14:51 -0500 (EST) Received: from web53806.mail.yahoo.com ([206.190.36.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzZmk-00076a-3t for sigtran@ietf.org; Thu, 19 Jan 2006 08:25:07 -0500 Received: (qmail 53582 invoked by uid 60001); 19 Jan 2006 13:12:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oe3jeGiSNxrnhvN+ZNEc+LHQG79L5wmQ0J95f84b6TXJTh4UZBuZteKmKBnJZ/fppkiseCVZPootW9d/KN5RDJoN0v/0en5lkF4ONNORZjkhtqkXDhg9FZfHcEOI/GVA9b0wBq66Wa7HF6OfGqKr4QYu8KN7qSBFJFMatNkn3gk= ; Message-ID: <20060119131246.53580.qmail@web53806.mail.yahoo.com> Received: from [220.227.128.163] by web53806.mail.yahoo.com via HTTP; Thu, 19 Jan 2006 05:12:46 PST Date: Thu, 19 Jan 2006 05:12:46 -0800 (PST) From: Saraswati Bose To: Brian Bidulock , sigtran MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Sigtran] Clarification of Sequemce No.(CODT) and ias timer X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0254955900==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0254955900== Content-Type: multipart/alternative; boundary="0-1029349965-1137676366=:46176" Content-Transfer-Encoding: 8bit --0-1029349965-1137676366=:46176 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian, When M bit of sequence number parameter in received CODT is set to 0 then considering that no more data will be sent by the peer should the server stop ias timer? Please suggest if other wise. Saraswati. --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1029349965-1137676366=:46176 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Brian,
 
When M bit of sequence number parameter in received CODT is set to 0 then considering that no more data will be sent by the peer should the server stop ias timer?
Please suggest if other wise.
 
Saraswati.

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1029349965-1137676366=:46176-- --===============0254955900== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0254955900==-- From sigtran-bounces@ietf.org Thu Jan 19 09:28:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezalp-0005BS-Od; Thu, 19 Jan 2006 09:28:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezaln-0005B2-RZ for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 09:28:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26785 for ; Thu, 19 Jan 2006 09:26:45 -0500 (EST) Received: from web35411.mail.mud.yahoo.com ([66.163.179.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzauH-00011K-J8 for sigtran@ietf.org; Thu, 19 Jan 2006 09:37:02 -0500 Received: (qmail 64975 invoked by uid 60001); 19 Jan 2006 14:27:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=n+raoN35sx5xu9i6cMZMVOI0qHxMWACWe8fHK33aAab/TGsjO4CaKq5b+41gkuH0Yo/pVsQ8scpKRL7y1P7h+OKcCqwmgb/q/VYzoO+ZGch5/Ca7tecuq2B4bH+Bp9lDdAVp7pRft7SUteUFXYCA0+TY2y3OAqurbWpOJqRIfpA= ; Message-ID: <20060119142757.64973.qmail@web35411.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35411.mail.mud.yahoo.com via HTTP; Thu, 19 Jan 2006 06:27:57 PST Date: Thu, 19 Jan 2006 06:27:57 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060119045419.A9167@openss7.org> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1850336394==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1850336394== Content-Type: multipart/alternative; boundary="0-2024280933-1137680877=:64074" --0-2024280933-1137680877=:64074 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA26785 Siu Chai, =20 What is the layer if it does not have upper boundary??? =20 see http://www1.ietf.org/mail-archive/web/sigtran/current/msg05708.html -------------------------------------------------------------- [Brian F. G. Bidulock] Actually, the upper boundary at the ASP is a local matter. There are n= o requirements placed on the boundary. It certainly does not have to specified to the bit. -------------------------------------------------------------- =20 Are you telling me that xxUA specifications tell me that it is forbidde= n to use User Part commands (i.e. application commands for M3UA) for conn= ection to MTP and remote MTP destination (or commands owned by SCCP-user = functions for connection of SCCP subsystems and their activation/deactiva= tion to SCCP) as ASP SM/TM commands that trigger ASP SM/TM messages altho= ugh xxUA specifications say that there is a magic xxUA layer which owns t= hese commands??? =20 This is certainly not true! See also other related threads posted recently and comments from other = people as well... =20 / Stanislav Ivanovich =20 P.S: You will find that some people in one thread claim one thing and i= n the next thread next day the opposite thing for ther same issue ;-) Conclusion is -> you must be carefull when accepting anyone's ideas in = this forum! =20 =20 =20 =20 "Brian F. G. Bidulock" wrote: Siu, Siu Chai Tho wrote: (Fri, 20 Jan 2006 00:47:33) >=20 > Hello Brian, >=20 > "Brian F. G. Bidulock" wrote: >=20 > > [Stanislav Ivanovich] What specifications do tell you is how should > > signalling processes behave on the external protocol and what is the > > functionality the prcesses should contain. Internal structure of > > signalling processes is irrelevant for specifications. > > > > > > > > [Siu Chai Tho]I feel that you have misunderstood my question. I was > > trying to reassure that there are boundaries of a layer defined as > > mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC > 2719. > > I understand that implementations can do whatever they like and are > > not forced to use layers. However, what is the purpose of using the > > word layer when there is no layer intended ? > What would you call it then? We refer to all of these UA as SS7-User > Adaptation Layers. You don't like the word 'layer'? (You will find > it on every page.) >=20 >=20 >=20 > [Siu Chai Tho] Sorry if I express myself wrong. I understood > Stanislav's answer in a way that a UA would not be layer definition, > but only definition of external behaviour. I think of UAs as defined > protocol layers (with boundaries as defined in chapter 1.6) and that > it's current best practise to implement layers with the defined > boundaries. Is this true ? Yes. --brian --=20 Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran =20 =09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! --0-2024280933-1137680877=:64074 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA26785
Siu Chai,
 
What is the layer if it doe= s not have upper boundary???
 
see htt= p://www1.ietf.org/mail-archive/web/sigtran/current/msg05708.html
--------------------------------------------------------------
[Brian F. G. Bidulock]
Actually, the uppper boundar= y at the ASP is a local matter.  There are no
requirements placed= on the boundary.  It certainly does not have to
specified to the= bit.
--------------------------------------------------------------
 
Are you telling me that xxUA specifications= tell me that it is forbidden to use User Part commands (i.e. application= commands for M3UA) for connection to MTP and remote MTP destination (or = commands owned by SCCP-user functions for connection of SCCP subsystems a= nd their activation/deactivation to SCCP) as ASP SM/TM commands that trigger ASP SM/TM messages although xxUA specificati= ons say that there is a magic xxUA layer which owns these commands???
 
This is certainly not true!
See a= lso other related threads posted recently and comments from other people = as well...
 
/ Stanislav Ivanovich
 
P.S: You will find that some people in one thr= ead claim one thing and in the next thread next day the opposite thing fo= r ther same issue ;-)
Conclusion is -> you must be careful= l when accepting anyone's ideas in this forum!
 
=
 
 


"Brian F. G. Bid= ulock" <bidulock@openss7.org> wrote:
Siu,

Siu Chai Tho wrote: (Fri, 20 Jan 2006 00:47:= 33)
>
> Hello Brian,
>
> "Brian F. G. Bidulock" wrote:
>
> >= ; [Stanislav Ivanovich] What specifications do tell you is how should
= > > signalling processes behave on the external protocol and what i= s the
> > functionality the prcesses should contain. Internal st= ructure of
> > signalling processes is irrelevant for specificat= ions.
> >
> >
> >
> > [Siu Chai Tho]I= feel that you have misunderstood my question. I was
> > trying = to reassure that there are boundaries of a layer defined as
> > = mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC
> = 2719.
> > I understand that implementations can do whatever they= like and are
> > not forced to use layers. However, what is the= purpose of using the
> > word layer when there is no layer inte= nded ?
> What would you call it then? We refer to all of these UA a= s SS7-User
> Adaptation Layers. You don't like the word 'layer'? (You will find
> it on every page.)
>=
>
>
> [Siu Chai Tho] Sorry if I express myself wron= g. I understood
> Stanislav's answer in a way that a UA would not b= e layer definition,
> but only definition of external behaviour. I = think of UAs as defined
> protocol layers (with boundaries as defin= ed in chapter 1.6) and that
> it's current best practise to impleme= nt layers with the defined
> boundaries. Is this true ?

Yes.=

--brian

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

_____________________________________= ___________
Sigtran mailing list
Sigtran@ietf.org
https://www1.i= etf.org/mailman/listinfo/sigtran

Yahoo! Photos =96 Showcase holiday pictures in hardcover=20 Photo Bo= oks. You design it and we=92ll bind it! --0-2024280933-1137680877=:64074-- --===============1850336394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1850336394==-- From sigtran-bounces@ietf.org Thu Jan 19 09:48:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezb5o-0005sk-Pw; Thu, 19 Jan 2006 09:48:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezb5l-0005sS-5d for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 09:48:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28132 for ; Thu, 19 Jan 2006 09:47:22 -0500 (EST) Received: from phl-28-b-170.phl.dsl.cerfnet.com ([63.242.157.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbEF-0001h7-N2 for sigtran@ietf.org; Thu, 19 Jan 2006 09:57:39 -0500 Received: from bn001320 (bn001320 [192.168.1.61]) by phl-28-b-170.phl.dsl.cerfnet.com (8.12.8/8.12.8) with SMTP id k0JEmToj003918 for ; Thu, 19 Jan 2006 09:48:30 -0500 From: "Barry Nagelberg" To: "SIGTRAN" Subject: RE: [Sigtran] M3UA and SUA recommendations Date: Thu, 19 Jan 2006 09:50:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060119142757.64973.qmail@web35411.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by phl-28-b-170.phl.dsl.cerfnet.com id k0JEmToj003918 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Regarding the warning in your "P.S." - I have also encountered this probl= em. However I would rephrase your warning to: "You must be in accepting ideas in this forum." But this is just like everything else in life - sometimes you get good ad= vice, and sometimes you don't. You have to be selective in deciding what to accept and what to ignore. Above all, try t= o keep a positive attitude. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf= Of Stanislav Ivanovich Sent: Thursday, January 19, 2006 9:28 AM To: SIGTRAN Subject: Re: [Sigtran] M3UA and SUA recommendations Siu Chai, What is the layer if it does not have upper boundary??? see http://www1.ietf.org/mail-archive/web/sigtran/current/msg05708.html -------------------------------------------------------------- [Brian F. G. Bidulock] Actually, the uppper boundary at the ASP is a local matter. There are no requirements placed on the boundary. It certainly does not have to specified to the bit. -------------------------------------------------------------- Are you telling me that xxUA specifications tell me that it is forbidden = to use User Part commands (i.e. application commands for M3UA) for connection to MTP and remote MTP destination (or c= ommands owned by SCCP-user functions for connection of SCCP subsystems and their activation/deactivation to SCCP) = as ASP SM/TM commands that trigger ASP SM/TM messages although xxUA specifications say that there is a magic xxUA laye= r which owns these commands??? This is certainly not true! See also other related threads posted recently and comments from other pe= ople as well... / Stanislav Ivanovich P.S: You will find that some people in one thread claim one thing and in = the next thread next day the opposite thing for ther same issue ;-) Conclusion is -> you must be carefull when accepting anyone's ideas in th= is forum! "Brian F. G. Bidulock" wrote: Siu, Siu Chai Tho wrote: (Fri, 20 Jan 2006 00:47:33) > > Hello Brian, > > "Brian F. G. Bidulock" wrote: > > > [Stanislav Ivanovich] What specifications do tell you is how should > > signalling processes behave on the external protocol and what is the > > functionality the prcesses should contain. Internal structure of > > signalling processes is irrelevant for specifications. > > > > > > > > [Siu Chai Tho]I feel that you have misunderstood my question. I was > > trying to reassure that there are boundaries of a layer defined as > > mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC > 2719. > > I understand that implementations can do whatever they like and are > > not forced to use layers. However, what is the purpose of using the > > word layer when there is no layer intended ? > What would you call it then? We refer to all of these UA as SS7-User > Adaptation Layers. You don't like the word 'layer'? (You will find > it on every page.) > > > > [Siu Chai Tho] Sorry if I express myself wrong. I understood > Stanislav's answer in a way that a UA would not be layer definition, > but only definition of external behaviour. I think of UAs as defined > protocol layers (with boundaries as defined in chapter 1.6) and that > it's current best practise to implement layers with the defined > boundaries. Is this true ? Yes. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ ________________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 19 09:59:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbG5-0002kr-JY; Thu, 19 Jan 2006 09:59:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbG3-0002kl-5n for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 09:59:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29066 for ; Thu, 19 Jan 2006 09:58:00 -0500 (EST) Received: from web37010.mail.mud.yahoo.com ([209.191.85.95]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzbOa-00029T-AC for sigtran@ietf.org; Thu, 19 Jan 2006 10:08:17 -0500 Received: (qmail 97142 invoked by uid 60001); 19 Jan 2006 14:51:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.nz; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vILy50XSNKgL7P6dX5hnNKJ+QHOzTa1/nlr6E+rNObsd7DmxCAK9aqLTfIYjA0RCNHShqcwsXqgLtnqmDCyopq9RiwabhJhfhYNGeLarVDjtzfMQLWeTTvzyiMmhPVibXZLLpCyhj1r6TqTRQUQ4qhCUKsf5Foi4Zwi9X5xPgSo= ; Message-ID: <20060119145134.97139.qmail@web37010.mail.mud.yahoo.com> Received: from [212.117.81.29] by web37010.mail.mud.yahoo.com via HTTP; Fri, 20 Jan 2006 03:51:34 NZDT Date: Fri, 20 Jan 2006 03:51:34 +1300 (NZDT) From: Siu Chai Tho Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060119142757.64973.qmail@web35411.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0660187058==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0660187058== Content-Type: multipart/alternative; boundary="0-315494728-1137682294=:94787" Content-Transfer-Encoding: 8bit --0-315494728-1137682294=:94787 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Stanislav, Stanislav Ivanovich wrote: Siu Chai, What is the layer if it does not have upper boundary??? It does, read chapter 1.6.1 of the RFC 3868 and RFC 3332. How do you get to the idea that it does not have an upper boundary ? Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com --0-315494728-1137682294=:94787 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello Stanislav,

Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
Siu Chai,
 
What is the layer if it does not have upper boundary???
 
It does, read chapter 1.6.1 of the RFC 3868 and RFC 3332. How do you get to the idea that it does not have an upper boundary ?
 
Thank you,
Joe

Send instant messages to your online friends http://au.messenger.yahoo.com --0-315494728-1137682294=:94787-- --===============0660187058== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0660187058==-- From sigtran-bounces@ietf.org Thu Jan 19 10:12:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbSV-0006aZ-4o; Thu, 19 Jan 2006 10:12:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbST-0006a2-8q for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 10:12:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29853 for ; Thu, 19 Jan 2006 10:10:50 -0500 (EST) Received: from web35402.mail.mud.yahoo.com ([66.163.179.111]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ezbb1-0002ZE-9f for sigtran@ietf.org; Thu, 19 Jan 2006 10:21:08 -0500 Received: (qmail 99836 invoked by uid 60001); 19 Jan 2006 15:12:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lCL2k3o/uPmL41wD87QkEDbs8f7KIi9abshAQbqzz1J78FddxgKTg63Cw/6a53927dSpBC5W38zSo82q5kfn0vpwPjCVDopqb69tLQyg0M92PJETfXdjmBVaAHpT2y+Fnnfo/wjGrlsVWT54CVrEJbsk9AkU8/7NktOSqVBLchk= ; Message-ID: <20060119151204.99834.qmail@web35402.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35402.mail.mud.yahoo.com via HTTP; Thu, 19 Jan 2006 07:12:04 PST Date: Thu, 19 Jan 2006 07:12:04 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060119110311.12433.qmail@web37008.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1391820656==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1391820656== Content-Type: multipart/alternative; boundary="0-653308563-1137683524=:96249" Content-Transfer-Encoding: 8bit --0-653308563-1137683524=:96249 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Siu Chai, See my comments below. / Stanislav Siu Chai Tho wrote: Hello Stainislav, Stanislav Ivanovich wrote: [Stanislav Ivanovich] The specifications do much more than that. They essentialy define a concept of application redundacy which is controlled by ASP SM/TM messages. [Siu Chai Tho] I not understand this. Isn't it just signalling transport redundancy that is managed and it is an option for applications to use it for application redundancy or not ? RFC 2719 does not mention anything on SIG-user redundancy. [Stanislav Ivanovich] Certainly not! What do you think the AS ("Application Server") concept is about? Do you think that Application Server served by several ASP'es is for the sake of transmission redundancy??? Of course not! However it is true what you said that it is optinal to use. Where did I say that it was mandatory??? I did not say that! No one forces you that you must have several ASP/IPSP'es in one AS. You can have just one application process instance in each AS thus having no application redundancy. However this does not change anything about the point -> AS concept certainly is the concept of application redundancy where several application processes serve the same application (so if one fails the application survives). That is the point. If you do not need this then you do not use it. Transmission redundcy is addrssed by lower layer protocols and functions (SCTP, IP, Ethernet...). Of course SGP is relay process (not application one) so multiple SGP'es in one SGW is example of transmission related redundancy. Note however that SGP'es are not part of any AS (i.e. SGP'es do not send ASP SM/TM messages). [Stanislav Ivanovich] What specifications do tell you is how should signalling processes behave on the external protocol and what is the functionality the prcesses should contain. Internal structure of signalling processes is irrelevant for specifications. [Siu Chai Tho]I feel that you have misunderstood my question. I was trying to reassure that there are boundaries of a layer defined as mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC 2719. I understand that implementations can do whatever they like and are not forced to use layers. However, what is the purpose of using the word layer when there is no layer intended ? [Stanislav Ivanovich] I did understand you! However see my last mail sent to you with some references and points. [Stanislav Ivanovich] No! ASP and IPSP are processes which contain user functions what is not the case for SGP. For example SGP-ASP protocol is designed to model communication between MTP3 and MTP3-user function for M3UA or SCCP and SCCP-user function for SUA. So ASP is container into which you load your user function. The essentce of the AS concepts (which make 80% of specifications for both M3UA and SUA) is that it supports application redundancy by means of ASP SM/TM messages. [Siu Chai Tho] ASP and IPSP contains user functions but SGP doesn't ? Isn't it just that any signalling process is just a communication endpoint for SUA/M3UA ? The user functions at the ASP or SCCP/MTP functions at the SGP reside in their own components or am I mistaken here ? [Stanislav Ivanovich] Why then different process types??? Read terminology sections of both SUA and M3UA: "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-peer fashion." "Signalling Gateway Process (SGP) - A process instance of a Signalling Gateway. It serves as an active, load-sharing or broadcast process of a Signalling Gateway." [Stanislav Ivanovich] Application granularity (ie. AS representation in SS7 language) is implementation choice thus not subject to specifications. But the specifications allow you to define your applications very flexibly (e.g. ISUP + BICC for DPC=2-100 shall be 1 AS). [Siu Chai Tho] I was trying to ask if it is possible to map one MTP/SCCP-SAP (or AS) into multiple ASPs (inside the same node). If this is an implementation option as you indicate I'm happy with the answer. [Stanislav Ivanovich] SS7 addresses are external representation of an application (Application Server). If your local application (AS) is supported by several application processes (instances) then you use several ASP'es. If not then you use just one ASP. 6) Is the recommendation of a layered implementation seen as a benefit or best current practice ? [Stanislav Ivanovich] Again. This is implementation. You cannot answer thuis queston by looking into xxUA specifications but instead by looking into your current SS7 implementation product descriptions, sequence diagrams etc... [Siu Chai Tho]I have again the feeling that you understood me wrong. I was asking for a reasoning of the layer recommendation inside the RFCs. How do others implement it ? [Stanislav Ivanovich] I did understand you well. Please see my previous answers and refferences. Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-653308563-1137683524=:96249 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Siu Chai,
 
See my comments below.
 
/ Stanislav


Siu Chai Tho <siuchaitho@yahoo.co.nz> wrote:
Hello Stainislav,

Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
[Stanislav Ivanovich] The specifications do much more than that. They essentialy define a concept of application redundacy which is controlled by ASP SM/TM messages.
 
[Siu Chai Tho] I not understand this. Isn't it just signalling transport redundancy that is managed and it is an option for applicat! ions to use it for application redundancy or not ? RFC 2719 does not mention anything on SIG-user redundancy.
 
[Stanislav Ivanovich] Certainly not! What do you think the AS ("Application Server") concept is about?
Do you think that Application Server served by several ASP'es is for the sake of transmission redundancy??? Of course not!
However it is true what you said that it is optinal to use. Where did I say that it was mandatory??? I did not say that!
No one forces you that you must have several ASP/IPSP'es in one AS. You can have just one application process instance in each AS thus having no application redundancy. However this does not change anything about the point -> AS concept certainly is the concept of application redundancy where several application processes serve the same application (so if one fails the application survives). That is the point. If you do not need this then you do not use it.
Transmission redundcy is addrssed by lower layer protocols and functions (SCTP, IP, Ethernet...).
Of course SGP is relay process (not application one) so multiple SGP'es in one SGW is example of transmission related redundancy. Note however that SGP'es are not part of any AS (i.e. SGP'es do not send ASP SM/TM messages).
 
 
[Stanislav Ivanovich] What specifications do tell you is how should signalling processes behave on the external protocol and what is the functionality the prcesses should contain. Internal structure of signalling processes is irrelevant for specifications.
 
[Siu Chai Tho]I feel that you have misunderstood my question. I was trying to r! eassure that there are boundaries of a layer defined as mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC 2719. I understand that implementations can do whatever they like and are not forced to use layers. However, what is the purpose of using the word layer when there is no layer intended ?
 
[Stanislav Ivanovich] I did understand you!
However see my last mail sent to you with some references and points.
 
 
[Stanislav Ivanovich] No! ASP and IPSP are processes which contain user functions what is not the case for SGP. For example SGP-ASP protocol is designed to model communication between MTP3 and MTP3-user function for M3UA or SCCP and SCCP-user function for SUA. So ASP is cont! ainer into which you load your user function. The essentce of the AS concepts (which make 80% of specifications for both M3UA and SUA) is that it supports application redundancy by means of ASP SM/TM messages.
 
[Siu Chai Tho] ASP and IPSP contains user functions but SGP doesn't ? Isn't it just that any signalling process is just a communication endpoint for SUA/M3UA ? The user functions at the ASP or SCCP/MTP functions at the SGP reside in their own components or am I mistaken here ?
 
[Stanislav Ivanovich] Why then different process types???
Read terminology sections of both SUA and M3UA:
"IP Server Process (IPSP) - A process instance of an IP-based application.
An IPSP is essentially the same as an ASP, except that it uses SUA in a
peer-to-peer fashion."
"Signalling Gateway Process (SGP) - A process instance of a Signalling Gateway.  It serves as an ac! tive, load-sharing or broadcast process of a Signalling Gateway."
 
 
[Stanislav Ivanovich] Application granularity (ie. AS representation in SS7 language) is implementation choice thus not subject to specifications. But the specifications allow you to define your applications very flexibly (e.g. ISUP + BICC for DPC=2-100 shall be 1 AS).
 
[Siu Chai Tho] I was trying to ask if it is possible to map one MTP/SCCP-SAP (or AS) into multiple ASPs (inside the same node). If this is an implementation option as you indicate I'm happy with the answer.
 
[Stanislav Ivanovich] SS7 addresses are external representation of an application (Applicati! on Server). If your local application (AS) is supported by several application processes (instances) then you use several ASP'es. If not then you use just one ASP.
 
6) Is the recommendation of a layered implementation seen as a benefit or best current practice ?
 
[Stanislav Ivanovich] Again. This is implementation. You cannot answer thuis queston by looking into xxUA specifications but instead by looking into your current SS7 implementation product descriptions, sequence diagrams etc...
 
[Siu Chai Tho]I have again the feeling that you understood me wrong. I was asking for a reasoning of the layer recommendation inside the RFCs. How do others implement it ?
 
[Stanislav Ivanovich] I did understand you well. Please see my previous answers and refferences.
 
 
Thank you,
Joe
Send instant messages to your online friends http://au.messenger.yahoo.com

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-653308563-1137683524=:96249-- --===============1391820656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1391820656==-- From sigtran-bounces@ietf.org Thu Jan 19 10:21:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezbay-0001oL-4D; Thu, 19 Jan 2006 10:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezbaw-0001nr-CJ for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 10:21:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00456 for ; Thu, 19 Jan 2006 10:19:35 -0500 (EST) Received: from web35409.mail.mud.yahoo.com ([66.163.179.118]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzbjS-0002r3-Db for sigtran@ietf.org; Thu, 19 Jan 2006 10:29:53 -0500 Received: (qmail 99472 invoked by uid 60001); 19 Jan 2006 15:20:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kGwlQBlIUSXUY6D0PgibqDYbJlDB6x/I4YGtM4y8R/rsZNou97A3zoCcgST1JsqPMdEfPHBSZ0hVYFac46s7Hh/Z9Pwg2EpXhTmXSFIdhTj3WazNg6YvgBZaHmfkEFC+PooNS+qOvuNV9iMIxGQGg1RBoAVJS+Uk3a0Maoj+6Ao= ; Message-ID: <20060119152049.99470.qmail@web35409.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35409.mail.mud.yahoo.com via HTTP; Thu, 19 Jan 2006 07:20:49 PST Date: Thu, 19 Jan 2006 07:20:49 -0800 (PST) From: Stanislav Ivanovich Subject: RE: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0935046980==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0935046980== Content-Type: multipart/alternative; boundary="0-1040429011-1137684049=:97723" --0-1040429011-1137684049=:97723 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA00456 Barry, =20 I agree with you. I really did not mean to offend anyone but I must be = honest -> I have received mails from other SIGTRAN community members on m= y private mail address saying that (according to their opinions) SIGTRAN = forum is not always very productive place. =20 I am really very sorry but I must publicly confirm this! It makes me ve= ry frustrated when I hear one standpoint in one thread and the opposite o= ne next day, next thread from the same person. And at the same time RFC'e= s, IG'es remain the same... =20 My apology to anyone who might considered himself/herself offended by m= y previous mail. =20 with best regards/ Stanislav Ivanovich =20 =20 Barry Nagelberg wrote: Stanislav, Regarding the warning in your "P.S." - I have also encountered this probl= em. However I would rephrase your warning to: "You must be in accepting ideas in this forum." But this is just like everything else in life - sometimes you get good ad= vice, and sometimes you don't. You have to be selective in deciding what to accept and what to ignore. Above all, try t= o keep a positive attitude. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf= Of Stanislav Ivanovich Sent: Thursday, January 19, 2006 9:28 AM To: SIGTRAN Subject: Re: [Sigtran] M3UA and SUA recommendations Siu Chai, What is the layer if it does not have upper boundary??? see http://www1.ietf.org/mail-archive/web/sigtran/current/msg05708.html -------------------------------------------------------------- [Brian F. G. Bidulock] Actually, the uppper boundary at the ASP is a local matter. There are no requirements placed on the boundary. It certainly does not have to specified to the bit. -------------------------------------------------------------- Are you telling me that xxUA specifications tell me that it is forbidden = to use User Part commands (i.e. application commands for M3UA) for connection to MTP and remote MTP destination (or c= ommands owned by SCCP-user functions for connection of SCCP subsystems and their activation/deactivation to SCCP) = as ASP SM/TM commands that trigger ASP SM/TM messages although xxUA specifications say that there is a magic xxUA laye= r which owns these commands??? This is certainly not true! See also other related threads posted recently and comments from other pe= ople as well... / Stanislav Ivanovich P.S: You will find that some people in one thread claim one thing and in = the next thread next day the opposite thing for ther same issue ;-) Conclusion is -> you must be carefull when accepting anyone's ideas in th= is forum! "Brian F. G. Bidulock" wrote: Siu, Siu Chai Tho wrote: (Fri, 20 Jan 2006 00:47:33) > > Hello Brian, > > "Brian F. G. Bidulock" wrote: > > > [Stanislav Ivanovich] What specifications do tell you is how should > > signalling processes behave on the external protocol and what is the > > functionality the prcesses should contain. Internal structure of > > signalling processes is irrelevant for specifications. > > > > > > > > [Siu Chai Tho]I feel that you have misunderstood my question. I was > > trying to reassure that there are boundaries of a layer defined as > > mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC > 2719. > > I understand that implementations can do whatever they like and are > > not forced to use layers. However, what is the purpose of using the > > word layer when there is no layer intended ? > What would you call it then? We refer to all of these UA as SS7-User > Adaptation Layers. You don't like the word 'layer'? (You will find > it on every page.) > > > > [Siu Chai Tho] Sorry if I express myself wrong. I understood > Stanislav's answer in a way that a UA would not be layer definition, > but only definition of external behaviour. I think of UAs as defined > protocol layers (with boundaries as defined in chapter 1.6) and that > it's current best practise to implement layers with the defined > boundaries. Is this true ? Yes. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ ________________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran =20 =09 --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays,= whatever. --0-1040429011-1137684049=:97723 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA00456
Barry,
 
I agree with you. I reall= y did not mean to offend anyone but I must be honest -> I have receive= d mails from other SIGTRAN community members on my private mail address s= aying that (according to their opinions) SIGTRAN forum is not always very= productive place.
 
I am really very sorry = but I must publicly confirm this! It makes me very frustrated when I hear= one standpoint in one thread and the opposite one next day, next thread = from the same person. And at the same time RFC'es, IG'es remain the same.= ..
 
My apology to anyone who might consider= ed himself/herself offended by my previous mail.
 
=
with best regards/ Stanislav Ivanovich
 
<= DIV>

Barry Nagelberg <barryn@adax.com> wrote:<= /DIV>
Stanislav,

Regarding the warning in your "P.S." - I have a= lso encountered this problem.

However I would rephrase your warnin= g to:
"You must be in accepting ideas in this forum."=

But this is just like everything else in life - sometimes you get= good advice, and sometimes you don't. You have to be
selective in dec= iding what to accept and what to ignore. Above all, try to keep a positiv= e attitude.

Barry Nagelberg
Adax, Inc.

-----Original Mes= sage-----
From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.= org]On Behalf Of Stanislav Ivanovichh
Sent: Thursday, January 19, 2006= 9:28 AM
To: SIGTRAN
Subject: Re: [Sigtran] M3UA and SUA recommenda= tions


Siu Chai,

What is the layer if it does not have u= pper boundary???

see http://www1.ietf.org/mail-archive/web/sigtran= /current/msg05708.html
-----------------------------------------------= ---------------
[Brian F. G. Bidulock]
Actually, the uppper boundary at the ASP is a local matter.= There are no
requirements placed on the boundary. It certainly does n= ot have to
specified to the bit.
----------------------------------= ----------------------------

Are you telling me that xxUA specific= ations tell me thatt it is forbidden to use User Part commands (i.e. appl= ication
commands for M3UA) for connection to MTP and remote MTP destin= ation (or commands owned by SCCP-user functions for
connection of SCCP= subsystems and their activation/deactivation to SCCP) as ASP SM/TM comma= nds that trigger ASP SM/TM
messages although xxUA specifications say t= hat there is a magic xxUA layer which owns these commands???

This = is certainly not true!
See also other related threads posted recently = and comments from other people as well...

/ Stanislav Ivanovich
P.S: You will find that some people in one thread claim one thing an= d in the next thread next day the opposite thing for
ther same issue ;-)
Conclusion is -> you must be carefull w= hen accepting anyone's ideas in this forum!





"Brian= F. G. Bidulock" wrote:
Siu,

Siu Chai Tho= wrote: (Fri, 20 Jan 2006 00:47:33)
>
> Hello Brian,
><= BR>> "Brian F. G. Bidulock" wrote:
>
> > [Stanislav Iva= novich] What specifications do tell you is how should
> > signal= ling processes behave on the external protocol and what is the
> &g= t; functionality the prcesses should contain. Internal structure of
&g= t; > signalling processes is irrelevant for specifications.
> &g= t;
> >
> >
> > [Siu Chai Tho]I feel that you h= ave misunderstood my question. I was
> > trying to reassure that= there are boundaries of a layer defined as
> > mentioned in cha= pter 1.6 of RFC 3868 and also in chapter 3.1 RFC
> 2719.
> &g= t; I understand that implementations can do whatever they like and are
> > not forced to use layers. Howeve= r, what is the purpose of using the
> > word layer when there is= no layer intended ?
> What would you call it then? We refer to all= of these UA as SS7-User
> Adaptation Layers. You don't like the wo= rd 'layer'? (You will find
> it on every page.)
>
>
= >
> [Siu Chai Tho] Sorry if I express myself wrong. I understood=
> Stanislav's answer in a way that a UA would not be layer definit= ion,
> but only definition of external behaviour. I think of UAs as= defined
> protocol layers (with boundaries as defined in chapter 1= .6) and that
> it's current best practise to implement layers with = the defined
> boundaries. Is this true ?

Yes.

--brian=

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

_________________________________________________
= Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtr= an





Yahoo! Photos =96 Showcase holiday pictures in = hardcover
Photo Books. You design it and we=92ll bind it!


_= ______________________________________________
Sigtran mailing listSigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Yahoo! Photos
=20 Ring in the New Year with Photo Calendars. Add photos, events, holidays, w= hatever. --0-1040429011-1137684049=:97723-- --===============0935046980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0935046980==-- From sigtran-bounces@ietf.org Thu Jan 19 10:27:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezbgj-0003hs-7W; Thu, 19 Jan 2006 10:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezbgh-0003gR-8d for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 10:26:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00806 for ; Thu, 19 Jan 2006 10:25:32 -0500 (EST) Received: from web35409.mail.mud.yahoo.com ([66.163.179.118]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzbpE-00031M-J5 for sigtran@ietf.org; Thu, 19 Jan 2006 10:35:50 -0500 Received: (qmail 2081 invoked by uid 60001); 19 Jan 2006 15:26:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oNAjygaiek5XL0BzqXuS3eg39DqXmO+POJxiW6zFHEOx5sEOHBdG+CGOpGi2g9xCnafpIN6XVj7OxAIRRC/JIGm6i+cXu/cDxXAE2TYQXgXD4un02qUTWackzZzlX5MVzgR1elX5OcuuYnfTGh5jYud3qNmqoFX/CQh6ZpZEqKQ= ; Message-ID: <20060119152648.2079.qmail@web35409.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35409.mail.mud.yahoo.com via HTTP; Thu, 19 Jan 2006 07:26:48 PST Date: Thu, 19 Jan 2006 07:26:48 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060119145134.97139.qmail@web37010.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0551301697==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0551301697== Content-Type: multipart/alternative; boundary="0-1881193304-1137684408=:1513" Content-Transfer-Encoding: 8bit --0-1881193304-1137684408=:1513 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Siu Chai, What I am telling you is that it is informative but not normative refference you are pointing to! Reason? -> Beacuse it is inside one'e implementation thus not affecting behavior on the external protocol. You should not understand all the parts of any RFC paper as normative ones if they do not affect behavior on the external protocol. For example in my M3UA/SUA implementation I can see both layered and non-layered apporach as long as the ASP behaves accordingly when it communicates with SGP. / Stanislav Siu Chai Tho wrote: Hello Stanislav, Stanislav Ivanovich wrote: Siu Chai, What is the layer if it does not have upper boundary??? It does, read chapter 1.6.1 of the RFC 3868 and RFC 3332. How do you get to the idea that it does not have an upper boundary ? Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-1881193304-1137684408=:1513 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Siu Chai,
 
What I am telling you is that it is informative but not normative refference you are pointing to!
Reason? -> Beacuse it is inside one'e implementation thus not affecting behavior on the external protocol.
 
You should not understand all the parts of any RFC paper as normative ones if they do not affect behavior on the external protocol.
 
For example in my M3UA/SUA implementation I can see both layered and non-layered apporach as long as the ASP behaves accordingly when it communicates with SGP.
 
/ Stanislav
 
 

Siu Chai Tho <siuchaitho@yahoo.co.nz> wrote:
Hello Stanislav,

Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
Siu Chai,
 
What is the layer if it does not have upper boundary???
 
It does, read chapter 1.6.1 of the RFC 3868 and RFC 3332. How do you get to the idea that it does not have an upper boundary ?
 
Thank you,
Joe
Send instant messages to your online friends http://au.messenger.yahoo.com _______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-1881193304-1137684408=:1513-- --===============0551301697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0551301697==-- From sigtran-bounces@ietf.org Thu Jan 19 14:45:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezfib-0006QC-PM; Thu, 19 Jan 2006 14:45:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezfia-0006Q7-5y for sigtran@megatron.ietf.org; Thu, 19 Jan 2006 14:45:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21159 for ; Thu, 19 Jan 2006 14:43:45 -0500 (EST) Received: from smtp01.tekelec.com ([198.89.42.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezfr9-0002rW-DD for sigtran@ietf.org; Thu, 19 Jan 2006 14:54:05 -0500 Received: from dcex04.tekelec.com (dcex04.tekelec.com [172.28.104.64]) by smtp01.tekelec.com (8.12.10/8.12.10) with ESMTP id k0JJhi8T003192 for ; Thu, 19 Jan 2006 13:43:44 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex04.tekelec.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 13:44:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jan 2006 13:44:53 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E7170279D0E9@DCEVS2.tekelec.com> Thread-Topic: M2PA Alignment Question Thread-Index: AcYdMNE58bVB4bNlQnCAjmdl9vgnjw== From: "Davidson, Mark" To: X-OriginalArrivalTime: 19 Jan 2006 19:44:54.0433 (UTC) FILETIME=[D1EE5110:01C61D30] X-Spam-Score: 0.2 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 Subject: [Sigtran] M2PA Alignment Question X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1571618115==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1571618115== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61D30.D1D662C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61D30.D1D662C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following text regarding LSR suggests that M2PA is expected to=20 behave like Q.703, entering the Aligned-Ready state (with T1 running)=20 after Proving:=20 =20 =20 The Link Status Ready message replaces the FISU of MTP2 that is sent at the end of the proving period. The Link Status Ready message is used to verify that both ends have completed proving. When M2PA starts timer T1, it SHALL send a Link Status Ready message to its peer in the case where MTP2 would send a FISU after proving is complete. If the Link Status Ready message is sent, then M2PA MAY send additional Link Status Ready messages while timer T1 is running. These Link Status Ready messages are sent on the Link Status stream. =20 But the latter part of Figure 12 of RFC shows the right side going directly from Proving to In-Service. Is there some text that describes/requires this behavior? I understand there is a problem if you don't do this, as you need another LSR to move from Aligned-Ready to In-Service. But M2PA only requires one to be sent (even with repeated LSRs, once T1=20 is stopped on the left, the right side could get stuck). =20 =20 MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . . Start timer T3 . . . . Link Status Proving . . . . ------------------------------------> . . . . . . . . . . Link Status Proving . . <------------------------------------ . . . . . . . . Stop timer T3 . . . . . . . . . . Start timer T4 . . . . Link Status Proving . . . . ------------------------------------> . . ------------------------------------> . . ------------------------------------> . . ------------------------------------> . . ------------------------------------> . . ------------------------------------> . . . . . . . . Timer T4 expires . . . . . . . . . =20 Send Link Status Ready (one or more) and wait for the remote end to complete its proving period. =20 . . . . . . . Start timer T1 . . . . . . . . . . Link Status Ready . . . . ------------------------------------> . . . . . . . . . . . . . . . . Link Status Ready . . <------------------------------------ . . . . . . . . Stop timer T1 . . . . . . . . . In Service . . In Service <------------ . . ------------> . . . . . . ------_=_NextPart_001_01C61D30.D1D662C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The=20 following text regarding LSR suggests that M2PA is expected to=20
behave like=20 Q.703, entering the Aligned-Ready state (with = T1=20 running) 
after=20 Proving:
 
 
     The Link = Status Ready=20 message replaces the FISU of MTP2 that is sent
     at the end of the proving = period.  The Link Status Ready message is
     used to verify that both = ends have=20 completed proving.  When M2PA
     starts timer T1, it SHALL = send a=20 Link Status Ready message to its
     peer in the case where = MTP2 would=20 send a FISU after proving is
     complete.  If the = Link Status=20 Ready message is sent, then M2PA MAY
     send additional Link = Status Ready=20 messages while timer T1 is running.
     These Link Status Ready = messages=20 are sent on the Link Status stream.
 
But the=20 latter part of Figure 12 of RFC shows the right side going=20 directly
from Proving=20 to In-Service.  Is there some text that=20 describes/requires
this=20 behavior?  I understand there is a problem if you don't do=20 this,
as you need=20 another LSR to move from Aligned-Ready to In-Service. = But
M2PA only=20 requires one to be sent (even with repeated LSRs, = once T1=20
is stopped=20 on the left, the right side could get stuck).
 
 
      =20 MTP3       =20 M2PA       =20 SCTP       =20 SCTP       =20 M2PA       =20 MTP3
      =20 ----       =20 ----       =20 ----       =20 ----       =20 ----       =20 ----
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
       =20 .           Start = timer=20 T3         =20 .          =20 .          =20 .
       =20 .           Link = Status=20 Proving    =20 .          =20 .          =20 .
       =20 .          =20 ------------------------------------>     &nb= sp;    =20 .
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
       =20 .          =20 .          =20 .     Link Status=20 Proving          =20 .
       =20 .          =20 <------------------------------------     &nb= sp;    =20 .
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
       =20 .           Stop timer = T3          =20 .          =20 .          =20 .
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
       =20 .           Start = timer=20 T4         =20 .          =20 .          =20 .
       =20 .           Link = Status=20 Proving    =20 .          =20 .          =20 .
       =20 .          =20 ------------------------------------>     &nb= sp;    =20 .
       =20 .          =20 ------------------------------------>     &nb= sp;    =20 .
       =20 .          =20 ------------------------------------>     &nb= sp;    =20 .
       =20 .          =20 ------------------------------------>     &nb= sp;    =20 .
       =20 .          =20 ------------------------------------>     &nb= sp;    =20 .
       =20 .          =20 ------------------------------------>     &nb= sp;    =20 .
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
       =20 .           Timer T4=20 expires       =20 .          =20 .          =20 .
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
 
        = Send Link=20 Status Ready (one or more) and wait for the remote=20 end
        to complete its = proving=20 period.
 
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
       =20 .           Start = timer=20 T1         =20 .          =20 .          =20 .
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
       =20 .           Link = Status=20 Ready      =20 .          =20 .          =20 .
       =20 .          =20 ------------------------------------>     &nb= sp;    =20 .
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
       =20 .          =20 .          =20 .       Link Status=20 Ready          =20 .
       =20 .          =20 <------------------------------------     &nb= sp;    =20 .
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
       =20 .           Stop timer = T1          =20 .          =20 .          =20 .
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
        In=20 Service           =   =20 .          =20 .           In=20 Service
       =20 <------------         &nb= sp;=20 .          =20 .          =20 ------------>
       =20 .          =20 .          =20 .          =20 .          =20 .          =20 .
------_=_NextPart_001_01C61D30.D1D662C0-- --===============1571618115== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1571618115==-- From sigtran-bounces@ietf.org Fri Jan 20 00:48:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezp80-0004rS-K4; Fri, 20 Jan 2006 00:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezp7z-0004rK-3s for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 00:48:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08169 for ; Fri, 20 Jan 2006 00:46:35 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[aT1mnntweHiFrLksAxFyjd6v2GU9pB8s]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzpGf-000627-52 for sigtran@ietf.org; Fri, 20 Jan 2006 00:57:01 -0500 Received: from ns.pigworks.openss7.net (IDENT:s5f/5/1evVff99MkPOUPcvWJRZXibLAU@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0K5lwE26522; Thu, 19 Jan 2006 22:47:58 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0K5lwk21083; Thu, 19 Jan 2006 22:47:58 -0700 Date: Thu, 19 Jan 2006 22:47:57 -0700 From: "Brian F. G. Bidulock" To: "Davidson, Mark" Subject: Re: [Sigtran] M2PA Alignment Question Message-ID: <20060119224757.A20140@openss7.org> Mail-Followup-To: "Davidson, Mark" , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E7170279D0E9@DCEVS2.tekelec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <58292FA6B3EEFD49AEDAF6597E21E7170279D0E9@DCEVS2.tekelec.com>; from Mark.Davidson@tekelec.com on Thu, Jan 19, 2006 at 01:44:53PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 1.2 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Mark, This is shown in the normal alignement procedure test cases in 3.1.5 and 3.1.6 of draft-bidulock-sigtran-m2pa-test-06.txt (and the corresponding Q.781/1.5 and 1.6 test cases). If you implement a Q.703 state machine directly from the SDLs with no experience of the protocol, you may run into this problem. I ran into it almost 20 years ago when performing LSSU compression between the driver and the L2 state machine. If, for a normal Q.703 implementation, you perform the longstanding FISUs compression technique (only providing first and last indication from driver to state machine) with a state machine implemented directly from the SDLs you will get this hang. However, the state machines as described in the Q.703 SDLs have two or three race conditions that can cause problems too. Also, the Q.703 SDLs will accept but never generate alignment using MSU instead of FISU as shown in Q.781/1.6 and M2PA-TEST 3.1.6. You will find it on Q.703/Figure 8 Sheet 6 and 7 of 14. On Sheet 6, the SDLs send a FISU, accept FISUs/MSUs and enter the Aligned Ready state. On Sheet 7, it takes subsequent indication of a FISU or MSU to move to the In Service State. To generate alignment with MSU requires that the SDLs on Sheet 6 should check the Tx buffer and send MSU instead of FISU. For in service on receiving an MSU (ala Q.781/1.6) the SDLs on Q.703/Figure 16 (Sheed 3 of 6) should buffer received MSUs and mark received FISUs during initial alignment. Then on Q.703/Figure 8 (Sheet 7 of 14) the SDLs should detect whether an FISU/MSU was received prior to alignment complete and move directly to the in service state. Any thing else will not work as shown in Q.781/1.6 (the receiver will in fact force the in-service MSU to be retransmitted and test case Q.781/1.6 will fail). However, the text is overarching, and Q.703/Clause 7 does not say that terminal waits for either FISU or MSU after alignment is complete, it ways that it enters the aligned ready state and starts T1 after alignment is complete and cancels T1 when it moves to the in service state. What it does not say, is what moves it to the in service state. These are understandings of the nuances of the Q.703 SDLs that come with experience and has little to do with M2PA. What is probably more pertinent to current discussions regarding IG and the M2PA-TEST draft, is that Q.703 SDLs implemented precisely as described in Q.703 will fail test case Q.781/1.6. M2PA does not describe state machines so precisely. In any event, I don't think that M2PA needs to be correcting defects in the Q.703 SDLs. Nevertheless, just as Q.781 is itself a good guide to Q.703, the M2PA-TEST document provides a good set of examples of how the implementation is expected to behave. --brian Davidson, Mark wrote: (Thu, 19 Jan 2006 13:44:53) > > The following text regarding LSR suggests that M2PA is expected to > > behave like Q.703, entering the Aligned-Ready state (with T1 running) > > after Proving: > > > > > > The Link Status Ready message replaces the FISU of MTP2 that is > sent > at the end of the proving period. The Link Status Ready message > is > used to verify that both ends have completed proving. When M2PA > starts timer T1, it SHALL send a Link Status Ready message to its > peer in the case where MTP2 would send a FISU after proving is > complete. If the Link Status Ready message is sent, then M2PA > MAY > send additional Link Status Ready messages while timer T1 is > running. > These Link Status Ready messages are sent on the Link Status > stream. > > > > But the latter part of Figure 12 of RFC shows the right side going > directly > > from Proving to In-Service. Is there some text that > describes/requires > > this behavior? I understand there is a problem if you don't do this, > > as you need another LSR to move from Aligned-Ready to In-Service. But > > M2PA only requires one to be sent (even with repeated LSRs, once T1 > > is stopped on the left, the right side could get stuck). > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 20 04:16:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzsLx-0003mZ-Fk; Fri, 20 Jan 2006 04:14:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzsLm-0003l5-Mj for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 04:14:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23985 for ; Fri, 20 Jan 2006 04:13:03 -0500 (EST) Received: from hostree9f.alcatel.com ([143.209.238.159] helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzsUU-0004Qv-75 for sigtran@ietf.org; Fri, 20 Jan 2006 04:23:30 -0500 Received: from axes-mach01.usa.alcatel.com (axes-mach01.usa.alcatel.com [10.255.0.20]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id k0K9EGgK005251; Fri, 20 Jan 2006 03:14:17 -0600 Received: from [10.255.1.166] (ax-sp-pc114.usa.alcatel.com [10.255.1.166]) by axes-mach01.usa.alcatel.com (8.12.10+Sun/8.12.2) with ESMTP id k0K9Gree025953; Fri, 20 Jan 2006 14:46:54 +0530 (IST) Message-ID: <43D0AB5E.9030309@alcatel.com> Date: Fri, 20 Jan 2006 14:50:31 +0530 From: devayya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Sigtran] M2PA Alignment Question References: <58292FA6B3EEFD49AEDAF6597E21E7170279D0E9@DCEVS2.tekelec.com> <20060119224757.A20140@openss7.org> In-Reply-To: <20060119224757.A20140@openss7.org> X-Scanned-By: MIMEDefang 2.51 on 143.209.238.159 X-Spam-Score: 1.8 (+) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: sigtran@ietf.org, "Davidson, Mark" X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1294453807==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1294453807== Content-Type: multipart/alternative; boundary="------------000204080505030802080502" This is a multi-part message in MIME format. --------------000204080505030802080502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian, Consider another case. Suppose in AlignedReady state, PO is received from remote, we stop T1 timer and change the state to Processor outage state and if after some time MSU is received from remote, then does that mean that the remote PO is cleared and we need to change the state to Inservice state? Please clarify.. Thanks, devayya Brian F. G. Bidulock wrote: >Mark, > >This is shown in the normal alignement procedure test cases in 3.1.5 and >3.1.6 of draft-bidulock-sigtran-m2pa-test-06.txt (and the corresponding >Q.781/1.5 and 1.6 test cases). > >If you implement a Q.703 state machine directly from the SDLs with no >experience of the protocol, you may run into this problem. I ran into >it almost 20 years ago when performing LSSU compression between the >driver and the L2 state machine. If, for a normal Q.703 implementation, >you perform the longstanding FISUs compression technique (only providing >first and last indication from driver to state machine) with a state >machine implemented directly from the SDLs you will get this hang. > >However, the state machines as described in the Q.703 SDLs have two or >three race conditions that can cause problems too. Also, the Q.703 SDLs >will accept but never generate alignment using MSU instead of FISU as >shown in Q.781/1.6 and M2PA-TEST 3.1.6. > >You will find it on Q.703/Figure 8 Sheet 6 and 7 of 14. On Sheet 6, the >SDLs send a FISU, accept FISUs/MSUs and enter the Aligned Ready state. >On Sheet 7, it takes subsequent indication of a FISU or MSU to move to >the In Service State. To generate alignment with MSU requires that the >SDLs on Sheet 6 should check the Tx buffer and send MSU instead of FISU. >For in service on receiving an MSU (ala Q.781/1.6) the SDLs on >Q.703/Figure 16 (Sheed 3 of 6) should buffer received MSUs and mark >received FISUs during initial alignment. Then on Q.703/Figure 8 (Sheet >7 of 14) the SDLs should detect whether an FISU/MSU was received prior >to alignment complete and move directly to the in service state. Any >thing else will not work as shown in Q.781/1.6 (the receiver will in >fact force the in-service MSU to be retransmitted and test case >Q.781/1.6 will fail). > >However, the text is overarching, and Q.703/Clause 7 does not say that >terminal waits for either FISU or MSU after alignment is complete, it >ways that it enters the aligned ready state and starts T1 after >alignment is complete and cancels T1 when it moves to the in service >state. What it does not say, is what moves it to the in service state. > >These are understandings of the nuances of the Q.703 SDLs that come with >experience and has little to do with M2PA. What is probably more >pertinent to current discussions regarding IG and the M2PA-TEST draft, >is that Q.703 SDLs implemented precisely as described in Q.703 will fail >test case Q.781/1.6. M2PA does not describe state machines so >precisely. In any event, I don't think that M2PA needs to be correcting >defects in the Q.703 SDLs. > >Nevertheless, just as Q.781 is itself a good guide to Q.703, the >M2PA-TEST document provides a good set of examples of how the >implementation is expected to behave. > >--brian > >Davidson, Mark wrote: (Thu, 19 Jan 2006 13:44:53) > > >> The following text regarding LSR suggests that M2PA is expected to >> >> behave like Q.703, entering the Aligned-Ready state (with T1 running) >> >> after Proving: >> >> >> >> >> >> The Link Status Ready message replaces the FISU of MTP2 that is >> sent >> at the end of the proving period. The Link Status Ready message >> is >> used to verify that both ends have completed proving. When M2PA >> starts timer T1, it SHALL send a Link Status Ready message to its >> peer in the case where MTP2 would send a FISU after proving is >> complete. If the Link Status Ready message is sent, then M2PA >> MAY >> send additional Link Status Ready messages while timer T1 is >> running. >> These Link Status Ready messages are sent on the Link Status >> stream. >> >> >> >> But the latter part of Figure 12 of RFC shows the right side going >> directly >> >> from Proving to In-Service. Is there some text that >> describes/requires >> >> this behavior? I understand there is a problem if you don't do this, >> >> as you need another LSR to move from Aligned-Ready to In-Service. But >> >> M2PA only requires one to be sent (even with repeated LSRs, once T1 >> >> is stopped on the left, the right side could get stuck). >> >> >> > > > > --------------000204080505030802080502 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Brian,

Consider another case.
Suppose in AlignedReady state, PO is received from remote, we stop T1 timer and change the state to Processor outage state and if after some time MSU is received from remote, then does that mean that the remote PO is cleared and we need to change the state to Inservice state?

Please clarify..

Thanks,
devayya

Brian F. G. Bidulock wrote:
Mark,

This is shown in the normal alignement procedure test cases in 3.1.5 and
3.1.6 of draft-bidulock-sigtran-m2pa-test-06.txt (and the corresponding
Q.781/1.5 and 1.6 test cases).

If you implement a Q.703 state machine directly from the SDLs with no
experience of the protocol, you may run into this problem.  I ran into
it almost 20 years ago when performing LSSU compression between the
driver and the L2 state machine.  If, for a normal Q.703 implementation,
you perform the longstanding FISUs compression technique (only providing
first and last indication from driver to state machine) with a state
machine implemented directly from the SDLs you will get this hang.

However, the state machines as described in the Q.703 SDLs have two or
three race conditions that can cause problems too.  Also, the Q.703 SDLs
will accept but never generate alignment using MSU instead of FISU as
shown in Q.781/1.6 and M2PA-TEST 3.1.6.

You will find it on Q.703/Figure 8 Sheet 6 and 7 of 14. On Sheet 6, the
SDLs send a FISU, accept FISUs/MSUs and enter the Aligned Ready state.
On Sheet 7, it takes subsequent indication of a FISU or MSU to move to
the In Service State.  To generate alignment with MSU requires that the
SDLs on Sheet 6 should check the Tx buffer and send MSU instead of FISU.
For in service on receiving an MSU (ala Q.781/1.6) the SDLs on
Q.703/Figure 16 (Sheed 3 of 6) should buffer received MSUs and mark
received FISUs during initial alignment.  Then on Q.703/Figure 8 (Sheet
7 of 14) the SDLs should detect whether an FISU/MSU was received prior
to alignment complete and move directly to the in service state.  Any
thing else will not work as shown in Q.781/1.6 (the receiver will in
fact force the in-service MSU to be retransmitted and test case
Q.781/1.6 will fail).

However, the text is overarching, and Q.703/Clause 7 does not say that
terminal waits for either FISU or MSU after alignment is complete, it
ways that it enters the aligned ready state and starts T1 after
alignment is complete and cancels T1 when it moves to the in service
state.  What it does not say, is what moves it to the in service state.

These are understandings of the nuances of the Q.703 SDLs that come with
experience and has little to do with M2PA.  What is probably more
pertinent to current discussions regarding IG and the M2PA-TEST draft,
is that Q.703 SDLs implemented precisely as described in Q.703 will fail
test case Q.781/1.6.  M2PA does not describe state machines so
precisely.  In any event, I don't think that M2PA needs to be correcting
defects in the Q.703 SDLs.

Nevertheless, just as Q.781 is itself a good guide to Q.703, the
M2PA-TEST document provides a good set of examples of how the
implementation is expected to behave.

--brian

Davidson, Mark wrote:                          (Thu, 19 Jan 2006 13:44:53)
  
   The following text regarding LSR suggests that M2PA is expected to

   behave like Q.703, entering the Aligned-Ready state (with T1 running)

   after Proving:





         The  Link Status Ready message replaces the FISU of MTP2 that is
   sent
         at the end of the proving period.  The Link Status Ready message
   is
        used to verify that both ends have completed proving.  When M2PA
        starts timer T1, it SHALL send a Link Status Ready message to its
        peer in the case where MTP2 would send a FISU after proving is
         complete.   If  the Link Status Ready message is sent, then M2PA
   MAY
         send  additional  Link  Status  Ready messages while timer T1 is
   running.
         These  Link  Status  Ready  messages are sent on the Link Status
   stream.



   But  the  latter  part  of Figure 12 of RFC shows the right side going
   directly

   from    Proving    to   In-Service.    Is   there   some   text   that
   describes/requires

   this behavior?  I understand there is a problem if you don't do this,

   as you need another LSR to move from Aligned-Ready to In-Service. But

   M2PA only requires one to be sent (even with repeated LSRs, once T1

   is stopped on the left, the right side could get stuck).
--------------000204080505030802080502-- --===============1294453807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1294453807==-- From sigtran-bounces@ietf.org Fri Jan 20 04:47:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzsrM-0005Au-E4; Fri, 20 Jan 2006 04:47:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzsrL-0005Ap-1g for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 04:47:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25894 for ; Fri, 20 Jan 2006 04:45:39 -0500 (EST) Received: from web37012.mail.mud.yahoo.com ([209.191.85.97]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ezt01-0005Na-21 for sigtran@ietf.org; Fri, 20 Jan 2006 04:56:07 -0500 Received: (qmail 12670 invoked by uid 60001); 20 Jan 2006 09:46:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.nz; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vfcJVZA6Tgorqlt83qBIWwH4GbdPQkrdKkUJuwr4abim7KwUHRzr1MIcxG4G/QK4a3SLsVftrYkq/MLVS0lXg/nXTBymA51hrbbDJZkr4fXHUtOpGEhd771EiA77eii0T1D5haIIMGkkmIVFL/IrPZ0aC3X3TeBnNq1pF20kqtw= ; Message-ID: <20060120094655.12668.qmail@web37012.mail.mud.yahoo.com> Received: from [212.117.81.29] by web37012.mail.mud.yahoo.com via HTTP; Fri, 20 Jan 2006 22:46:55 NZDT Date: Fri, 20 Jan 2006 22:46:55 +1300 (NZDT) From: Siu Chai Tho Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060119152648.2079.qmail@web35409.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1298046306==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1298046306== Content-Type: multipart/alternative; boundary="0-281280728-1137750415=:11941" Content-Transfer-Encoding: 8bit --0-281280728-1137750415=:11941 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Stanislav, Stanislav Ivanovich wrote: You should not understand all the parts of any RFC paper as normative ones if they do not affect behavior on the external protocol. [Siu Chai Tho] No layer will ever be visible externally, it is essentially an abstract definition concept. This is not unique for SIGTRAN but goes for all protocol layers (such as defined in RFC 1122 or ITU-T SS7 specifications). Layering is a architectural design pattern and thus only applicable to implementations. Nevertheless it's an important architectural choice to choose layers. [...] [Stanislav Ivanovich] Why then different process types??? Read terminology sections of both SUA and M3UA: "IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-peer fashion." "Signalling Gateway Process (SGP) - A process instance of a Signalling Gateway. It serves as an ac! tive, load-sharing or broadcast process of a Signalling Gateway." Don't you need IPSP and ASP to serve the interface to the MTP/SCCPuser and the SGP to serve the interface to MTP/SCCP ? That in itself is a difference. The difference between ASP and IPSP is as you quoted above, an IPSP can talk to other IPSPs serving MTP/SCCP users. Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com --0-281280728-1137750415=:11941 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Stanislav,

Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
You should not understand all the parts of any RFC paper as normative ones if they do not affect behavior on the external protocol.
[Siu Chai Tho] No layer will ever be visible externally, it is essentially an abstract definition concept. This is not unique for SIGTRAN but goes for all protocol layers (such as defined in RFC 1122 or ITU-T SS7 specifications).
Layering is a architectural design pattern and thus only applicable to implementations. Nevertheless it's an important architectural choice to choose layers.
 
[...]
[Stanislav Ivanovich] Why then different process types??! ?
Read terminology sections of both SUA and M3UA:
"IP Server Process (IPSP) - A process instance of an IP-based application.
An IPSP is essentially the same as an ASP, except that it uses SUA in a
peer-to-peer fashion."
"Signalling Gateway Process (SGP) - A process instance of a Signalling Gateway.  It serves as an ac! tive, load-sharing or broadcast process of a Signalling Gateway."
Don't you need IPSP and ASP to serve the interface to the MTP/SCCPuser and the SGP to serve the interface to MTP/SCCP ? That in itself is a difference. The difference between ASP and IPSP is as you quoted above, an IPSP can talk to other IPSPs serving MTP/SCCP users.
 
Thank you,
Joe
 
 

Send instant messages to your online friends http://au.messenger.yahoo.com --0-281280728-1137750415=:11941-- --===============1298046306== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1298046306==-- From sigtran-bounces@ietf.org Fri Jan 20 07:14:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzvA9-0005YY-Li; Fri, 20 Jan 2006 07:14:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzvA8-0005Y8-MZ for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 07:14:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07136 for ; Fri, 20 Jan 2006 07:13:12 -0500 (EST) Received: from web53806.mail.yahoo.com ([206.190.36.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzvIn-0001qL-Q9 for sigtran@ietf.org; Fri, 20 Jan 2006 07:23:42 -0500 Received: (qmail 97228 invoked by uid 60001); 20 Jan 2006 12:14:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JwGD+1Z/Ev3j+eZS837wQ0mU8UrXmVOb3vvfXbDhCAfofp8BtFgDwgjIuE5aLxl6v3zpYPdcmjeN1p8DKYIPUtKv0uVumDSyQaU0cP8mjXweo7U9ZZZ9jUikkHAJgmYdjYqPTpNuO6yHhz3Vn/+Q7KiNw2vBxtXXjl1bAZjD9kE= ; Message-ID: <20060120121420.97226.qmail@web53806.mail.yahoo.com> Received: from [220.227.128.163] by web53806.mail.yahoo.com via HTTP; Fri, 20 Jan 2006 04:14:20 PST Date: Fri, 20 Jan 2006 04:14:20 -0800 (PST) From: Saraswati Bose To: Brian Bidulock , sigtran MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Sigtran] Clarification on Sequence No. in CODT and ias timer X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0913302250==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0913302250== Content-Type: multipart/alternative; boundary="0-1242451388-1137759260=:95177" Content-Transfer-Encoding: 8bit --0-1242451388-1137759260=:95177 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian, When M bit of sequence number parameter in received CODT is set to 0 then considering that no more data will be sent by the peer should the server stop "ias timer"? Please suggest if other wise. Saraswati. --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-1242451388-1137759260=:95177 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi Brian,
 
When M bit of sequence number parameter in received CODT is set to 0 then considering that no more data will be sent by the peer should the server stop "ias timer"?
Please suggest if other wise.
 
Saraswati.

Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP. --0-1242451388-1137759260=:95177-- --===============0913302250== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0913302250==-- From sigtran-bounces@ietf.org Fri Jan 20 09:41:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzxSG-00020u-Ov; Fri, 20 Jan 2006 09:41:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzxSF-0001zT-27 for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 09:41:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17717 for ; Fri, 20 Jan 2006 09:40:03 -0500 (EST) Received: from web35412.mail.mud.yahoo.com ([66.163.179.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ezxaw-0006Qu-NI for sigtran@ietf.org; Fri, 20 Jan 2006 09:50:33 -0500 Received: (qmail 56358 invoked by uid 60001); 20 Jan 2006 14:41:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bIuziVllrMUhJWEiOGLmCbV5BCKT390fDNvv2HVA4nihPYK2HJcuZ4TRkVKM5dct6IIU56ayqtfAgjOJfXSaFT7Y5awK/Kxv/EhrYigmWcf3nwtkoD1xIMIj8kYqlCKpNokMa01ETTfwm53fxhR2uibbXlbzVy3J7MdzJnxVUaU= ; Message-ID: <20060120144114.56354.qmail@web35412.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35412.mail.mud.yahoo.com via HTTP; Fri, 20 Jan 2006 06:41:14 PST Date: Fri, 20 Jan 2006 06:41:14 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060120094655.12668.qmail@web37012.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0667167539==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0667167539== Content-Type: multipart/alternative; boundary="0-951512294-1137768074=:54920" --0-951512294-1137768074=:54920 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA17717 Siu Chai, =20 Look below for my comments. =20 / Stanislav =20 =20 Siu Chai Tho wrote: Stanislav, Stanislav Ivanovich wrote: You should not understand all the parts of any RFC paper as normative= ones if they do not affect behavior on the external protocol. [Siu Chai Tho] No layer will ever be visible externally, it is essentia= lly an abstract definition concept. This is not unique for SIGTRAN but go= es for all protocol layers (such as defined in RFC 1122 or ITU-T SS7 spec= ifications). Layering is a architectural design pattern and thus only applicable to = implementations. Nevertheless it's an important architectural choice to c= hoose layers. =20 [...] =20 [Stanislav Ivanovich] Nonsense! Layering or not layering is certainly not visible on the external xxUA = protocols since it is implementation matter. For example I have two M3UA = ASP implementations: 1) One applies layered approach where traffic control appplication + su= pporting user part functions are kept intact while all the AS concepts a= re put within a layer called "M3UA ASP" which is managed separately. 2) In the second non-layered approach I decide to make modifications to= 3 SW components of traffic control application + 2 SW components of user= part functions because by looking into product manaulas, descriptions, s= equence diagrams (i.e. not in xxUA specifications but instead in my imple= mentation documents) I found that it is easier to make these modification= s than to introduce a separate "M3UA ASP" layer which shall be separately= controlled by its own management (commands)... =20 However both (!) of my ASP implementations when connected to SGP behave= strictly 100% in compliance with ASP-SGP protocol as defined in M3UA spe= cification! =20 So if I connect one of my M3UA ASP implementations to your M3UA SGP imp= lementation (which might be also 100% compliant with ASP-SGP protocol spe= cification) how can your SGP know which ASP implementation I use? Of course it cannot since the difference is externally not visible! The= rfore this is not specification (normative) issue but impelemtnation one.= If you claim opposite then what is the tool/mechanism used on the extern= al protocol (e.g. message, parameter, parameter value etc...) by which yo= u can tell the difference which ASP implementation I use??? =20 =20 [Stanislav Ivanovich] Why then different process types??! ? Read terminology sections of both SUA and M3UA: "IP Server Process (IPSP) - A process instance of an IP-based applicati= on. An IPSP is essentially the same as an ASP, except that it uses SUA in a peer-to-peer fashion." "Signalling Gateway Process (SGP) - A process instance of a Signalling Ga= teway. It serves as an ac! tive, load-sharing or broadcast process of a = Signalling Gateway." Don't you need IPSP and ASP to serve the interface to the MTP/SCCPuser = and the SGP to serve the interface to MTP/SCCP ? That in itself is a diff= erence. The difference between ASP and IPSP is as you quoted above, an IP= SP can talk to other IPSPs serving MTP/SCCP users. =20 [Stanislav Ivanovich] See my comments above (and the previous ones agai= n). =20 Thank you, Joe =20 =20 Send instant messages to your online friends http://au.messenger.yahoo.= com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran =20 =09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! --0-951512294-1137768074=:54920 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA17717
Siu Chai,
 
Look below for my comments.=
 
/ Stanislav
 

Siu Chai Tho <siuchaitho@yahoo.co.nz> wrote:
Stanislav,

Stani= slav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
=
You should not understand all th= e parts of any RFC paper as normative ones if they do not affect behavior= on the external protocol.
[Siu Chai Tho] No lay= er will ever be visible externally, it is essentially an abstract definit= ion concept. This is not unique for SIGTRAN but goes for all protocol lay= ers (such as defined in RFC 1122 or ITU-T SS7 specifications).
Layering is a architectural design pattern and thus only applicable to implementations. Nevertheless it's an important archi= tectural choice to choose layers.
 
[...]
 
[Stanislav Ivanovich] Nonsense!
= Layering or not layering is certainly not visible on the external xxUA pr= otocols since it is implementation matter. For example I have two M3UA AS= P implementations:
1) One applies layered approach where traf= fic control appplication + supporting user part functions are kept intact= while all the AS  concepts are put within a layer called "M3UA= ASP" which is managed separately.
2) In the second non-layer= ed approach I decide to make modifications to 3 SW components of tra= ffic control application + 2 SW components of user part functions because= by looking into product manaulas, descriptions, sequence diagrams (i.e. = not in xxUA specifications but instead in my implementation documents) I&= nbsp;found that it is easier to make these modifications than to introduce a separate "M3UA ASP" layer which s= hall be separately controlled by its own management (commands)...
=
 
However both (!) of my ASP implementations when c= onnected to SGP behave strictly 100% in compliance with ASP-SGP prot= ocol as defined in M3UA specification!
 
So = if I connect one of my M3UA ASP implementations to your M3= UA SGP implementation (which might be also 100% compliant with ASP-SGP pr= otocol specification) how can your SGP know which ASP implementation I us= e?
Of course it cannot since the difference is externall= y not visible! Therfore this is not specification (normative) i= ssue but impelemtnation one. If you claim opposite then what is the = tool/mechanism used on the external protocol (e.g. message, parameter, pa= rameter value etc...) by which you can tell the difference which ASP impl= ementation I use???
 
=20
 
[Stanis= lav Ivanovich] Why then different process types??! ?
Read ter= minology sections of both SUA and M3UA:
"IP Server Process (I= PSP) - A process instance of an IP-based application.
An IPSP is essen= tially the same as an ASP, except that it uses SUA in a
peer-to-peer f= ashion."
"Signalling Gateway Process (SGP) - A process instance of a S= ignalling Gateway.  It serves as an ac! tive, load-sharing or broadc= ast process of a Signalling Gateway."
Don'= t you need IPSP and ASP to serve the interface to the MTP/SCCPuser and th= e SGP to serve the interface to MTP/SCCP ? That in itself is a difference= . The difference between ASP and IPSP is as you quoted above, an IPSP can= talk to other IPSPs serving MTP/SCCP users.
 
[Stanislav Ivanovich] See my comments above (and the previous ones again).
 
Thank you,
Joe
 
 
Send instan= t messages to your online friends http://au.messenger.yahoo.com _________= ______________________________________
Sigtran mailing list
Sigtran= @ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Yahoo! Photos =96 Showcase holiday pictures in hardcover=20 Photo Bo= oks. You design it and we=92ll bind it! --0-951512294-1137768074=:54920-- --===============0667167539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0667167539==-- From sigtran-bounces@ietf.org Fri Jan 20 10:01:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzxlO-0000Gm-DJ; Fri, 20 Jan 2006 10:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzxlM-0000Fx-Vr for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 10:01:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19370 for ; Fri, 20 Jan 2006 09:59:49 -0500 (EST) Received: from web37004.mail.mud.yahoo.com ([209.191.85.89]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ezxu6-00076S-B2 for sigtran@ietf.org; Fri, 20 Jan 2006 10:10:20 -0500 Received: (qmail 89618 invoked by uid 60001); 20 Jan 2006 15:01:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.nz; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0ETJFtu/XIGAc2ga+0kOJDijrJsbHwuv5pWtZUJuxhIVi4grqaKEprSyzUXvym7Ib+mZ50rnNE5DkkSaeUWq4nGzvx+11YxhQ0dziLw53Ez9UXwXkfrA2usEXQELuM4ihwMn6Ss/3xdEpeR5r/8oUx6/duvgVF+2ovoZZqokBfY= ; Message-ID: <20060120150104.89616.qmail@web37004.mail.mud.yahoo.com> Received: from [212.117.81.29] by web37004.mail.mud.yahoo.com via HTTP; Sat, 21 Jan 2006 04:01:04 NZDT Date: Sat, 21 Jan 2006 04:01:04 +1300 (NZDT) From: Siu Chai Tho Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060120144114.56354.qmail@web35412.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1902823804==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1902823804== Content-Type: multipart/alternative; boundary="0-1939872938-1137769264=:77806" Content-Transfer-Encoding: 8bit --0-1939872938-1137769264=:77806 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello Stanislav, Stanislav Ivanovich wrote: Layering is a architectural design pattern and thus only applicable to implementations. Nevertheless it's an important architectural choice to choose layers. [...] [Stanislav Ivanovich] Nonsense! Layering or not layering is certainly not visible on the external xxUA protocols since it is implementation matter. For example I have two M3UA ASP implementations: 1) One applies layered approach where traffic control appplication + supporting user part functions are kept intact while all the AS concepts are put within a layer called "M3UA ASP" which is managed separately. 2) In the second non-layered approach I decide to make modifications to 3 SW components of traffic control application + 2 SW components of user part functions because by looking into product manaulas, descriptions, sequence diagrams (i.e. not in xxUA specifications but instead in my implementation documents) I found that it is easier to make these modifications than to introduce a separate "M3UA ASP" layer which shall be separately controlled by its own management (commands)... However both (!) of my ASP implementations when connected to SGP behave strictly 100% in compliance with ASP-SGP protocol as defined in M3UA specification! [Siu Chai Tho] I think you are questioning the usefulness of protocol layers in specifications. I didn't wanted to broaden the discussion to that level. I was merely trying to understand if the UAs define a layer or not. So far I think I received a positive answer. Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com --0-1939872938-1137769264=:77806 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello Stanislav,

Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
Layering is a architectural design pattern and thus only applicable to implementations. Nevertheless it's an important architectural choice to choose layers.
 
[...]
 
[Stanislav Ivanovich] Nonsense!
Layering or not layering is certainly not visible on the external xxUA protocols since it is implementation matter. For example I have two M3UA ASP implementations:
1) One applies layered approach where traffic control appplication + supporting user part functions are kept intact while all the AS  concepts are put within a layer called "M3UA ASP" which is managed separately.
2) In the second non-layered approach I decide to make modifications to 3 SW components of traffic control application + 2 SW components of user part functions because by looking into product manaulas, descriptions, sequence diagrams (i.e. not in xxUA specifications but instead in my implementation documents) I found that it is easier to make these modifications than to introduce a separate "M3UA ASP" layer which shall be separately controlled by its own management (commands)...
 
However both (!) of my ASP implementations when connected to SGP behave strictly 100% in compliance with ASP-SGP protocol as defined in M3UA specification!
[Siu Chai Tho] I think you are questioning the usefulness of protocol layers in specifications. I didn't wanted to broaden the discussion to that level. I was merely trying to understand if the UAs define a layer or not. So far I t! hink I received a positive answer.
 
Thank you,
Joe

Send instant messages to your online friends http://au.messenger.yahoo.com --0-1939872938-1137769264=:77806-- --===============1902823804== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1902823804==-- From sigtran-bounces@ietf.org Fri Jan 20 10:22:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezy5z-0007iI-4h; Fri, 20 Jan 2006 10:22:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezy5x-0007iD-I8 for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 10:22:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21034 for ; Fri, 20 Jan 2006 10:21:05 -0500 (EST) Received: from smtp03.tekelec.com ([198.89.42.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyEU-0007n6-0J for sigtran@ietf.org; Fri, 20 Jan 2006 10:31:24 -0500 Received: from dcex05.tekelec.com (dcex05.tekelec.com [172.28.104.65]) by smtp03.tekelec.com (8.12.10/8.12.10) with ESMTP id k0KFJ0ju028667; Fri, 20 Jan 2006 09:19:00 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex05.tekelec.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 09:22:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] M2PA Alignment Question Date: Fri, 20 Jan 2006 09:22:03 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E7170279D5BD@DCEVS2.tekelec.com> Thread-Topic: [Sigtran] M2PA Alignment Question Thread-Index: AcYdhRfqpzzDcZKYRs2582Ru6dHopAASbdgQAAAWwWA= From: "Davidson, Mark" To: X-OriginalArrivalTime: 20 Jan 2006 15:22:04.0825 (UTC) FILETIME=[44ECD890:01C61DD5] X-Spam-Score: 1.2 (+) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Cc: bidulock@openss7.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, Thank you for your informative response. =20 I agree that using an implementation which, for instance, filters duplicate FISUs in HW, would require changes to Q.703 SDLs in order to work. Also, I understand this is a fairly simple problem to work around. But if an implementation chooses not to deliver SUs to MTP2, then modifications to the SDLs are beyond the scope of Q.703, and not necessarily "defects." On the other hand, Q.781 tests acknowledge that FISU filtering is a fact of life. The heart of the issue though, is that M2PA specifically says to "follow the requirements of the applicable MTP2 specification" except as modified in the RFC. If using Q.703 as a basis, how is one supposed to know when to follow Q.703 and when not to? If Q.703 is considered defective, why is it chosen as the normative document? Why are these known "defects" not addressed in the RFC? I appreciate the effort you put in to your test plan draft, and I assure you is is widely used, but I would prefer issues such as this to be spelled out in something normative. -Mark -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Friday, January 20, 2006 12:48 AM To: Davidson, Mark Cc: sigtran@ietf.org Subject: Re: [Sigtran] M2PA Alignment Question Mark, This is shown in the normal alignement procedure test cases in 3.1.5 and 3.1.6 of draft-bidulock-sigtran-m2pa-test-06.txt (and the corresponding Q.781/1.5 and 1.6 test cases). If you implement a Q.703 state machine directly from the SDLs with no experience of the protocol, you may run into this problem. I ran into it almost 20 years ago when performing LSSU compression between the driver and the L2 state machine. If, for a normal Q.703 implementation, you perform the longstanding FISUs compression technique (only providing first and last indication from driver to state machine) with a state machine implemented directly from the SDLs you will get this hang. However, the state machines as described in the Q.703 SDLs have two or three race conditions that can cause problems too. Also, the Q.703 SDLs will accept but never generate alignment using MSU instead of FISU as shown in Q.781/1.6 and M2PA-TEST 3.1.6. You will find it on Q.703/Figure 8 Sheet 6 and 7 of 14. On Sheet 6, the SDLs send a FISU, accept FISUs/MSUs and enter the Aligned Ready state. On Sheet 7, it takes subsequent indication of a FISU or MSU to move to the In Service State. To generate alignment with MSU requires that the SDLs on Sheet 6 should check the Tx buffer and send MSU instead of FISU. For in service on receiving an MSU (ala Q.781/1.6) the SDLs on Q.703/Figure 16 (Sheed 3 of 6) should buffer received MSUs and mark received FISUs during initial alignment. Then on Q.703/Figure 8 (Sheet 7 of 14) the SDLs should detect whether an FISU/MSU was received prior to alignment complete and move directly to the in service state. Any thing else will not work as shown in Q.781/1.6 (the receiver will in fact force the in-service MSU to be retransmitted and test case Q.781/1.6 will fail). However, the text is overarching, and Q.703/Clause 7 does not say that terminal waits for either FISU or MSU after alignment is complete, it ways that it enters the aligned ready state and starts T1 after alignment is complete and cancels T1 when it moves to the in service state. What it does not say, is what moves it to the in service state. These are understandings of the nuances of the Q.703 SDLs that come with experience and has little to do with M2PA. What is probably more pertinent to current discussions regarding IG and the M2PA-TEST draft, is that Q.703 SDLs implemented precisely as described in Q.703 will fail test case Q.781/1.6. M2PA does not describe state machines so precisely. In any event, I don't think that M2PA needs to be correcting defects in the Q.703 SDLs. Nevertheless, just as Q.781 is itself a good guide to Q.703, the M2PA-TEST document provides a good set of examples of how the implementation is expected to behave. --brian Davidson, Mark wrote: (Thu, 19 Jan 2006 13:44:53) >=20 > The following text regarding LSR suggests that M2PA is expected to >=20 > behave like Q.703, entering the Aligned-Ready state (with T1 > running) >=20 > after Proving: >=20 >=20 >=20 >=20 >=20 > The Link Status Ready message replaces the FISU of MTP2 that is > sent > at the end of the proving period. The Link Status Ready message > is > used to verify that both ends have completed proving. When M2PA > starts timer T1, it SHALL send a Link Status Ready message to its > peer in the case where MTP2 would send a FISU after proving is > complete. If the Link Status Ready message is sent, then M2PA > MAY > send additional Link Status Ready messages while timer T1 is > running. > These Link Status Ready messages are sent on the Link Status > stream. >=20 >=20 >=20 > But the latter part of Figure 12 of RFC shows the right side going > directly >=20 > from Proving to In-Service. Is there some text that > describes/requires >=20 > this behavior? I understand there is a problem if you don't do=20 > this, >=20 > as you need another LSR to move from Aligned-Ready to In-Service.=20 > But >=20 > M2PA only requires one to be sent (even with repeated LSRs, once T1 >=20 > is stopped on the left, the right side could get stuck). >=20 -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 20 10:40:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyNS-0004z0-SK; Fri, 20 Jan 2006 10:40:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyNR-0004yX-Bx for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 10:40:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23356 for ; Fri, 20 Jan 2006 10:39:09 -0500 (EST) Received: from web35411.mail.mud.yahoo.com ([66.163.179.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzyW8-0000IF-Cx for sigtran@ietf.org; Fri, 20 Jan 2006 10:49:39 -0500 Received: (qmail 84037 invoked by uid 60001); 20 Jan 2006 15:40:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ukTxs014gduVghSpbEXJo+mo2+XzeTbnhDMKAfwO0wl5KAdCloyqX00xa+kyBGWOuyiIhhOShYLZfI7gVPkrn+EsmiY3VNmFcQRyTwiG86uvlBM1mNmjZGvSZscGot8SvO7IG5vKxddUxC587KNsdaD/saTgVZa/8AJHeRDoiOg= ; Message-ID: <20060120154022.84035.qmail@web35411.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35411.mail.mud.yahoo.com via HTTP; Fri, 20 Jan 2006 07:40:22 PST Date: Fri, 20 Jan 2006 07:40:22 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060120150104.89616.qmail@web37004.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1929639491==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1929639491== Content-Type: multipart/alternative; boundary="0-1699493218-1137771622=:81584" Content-Transfer-Encoding: 8bit --0-1699493218-1137771622=:81584 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Siu Chai, No, I am not questioning anything in xxUA specifications but instead pointing to the difference between normative and informative parts of them. / Stanislav Siu Chai Tho wrote: Hello Stanislav, Stanislav Ivanovich wrote: Layering is a architectural design pattern and thus only applicable to implementations. Nevertheless it's an important architectural choice to choose layers. [...] [Stanislav Ivanovich] Nonsense! Layering or not layering is certainly not visible on the external xxUA protocols since it is implementation matter. For example I have two M3UA ASP implementations: 1) One applies layered approach where traffic control appplication + supporting user part functions are kept intact while all the AS concepts are put within a layer called "M3UA ASP" which is managed separately. 2) In the second non-layered approach I decide to make modifications to 3 SW components of traffic control application + 2 SW components of user part functions because by looking into product manaulas, descriptions, sequence diagrams (i.e. not in xxUA specifications but instead in my implementation documents) I found that it is easier to make these modifications than to introduce a separate "M3UA ASP" layer which shall be separately controlled by its own management (commands)... However both (!) of my ASP implementations when connected to SGP behave strictly 100% in compliance with ASP-SGP protocol as defined in M3UA specification! [Siu Chai Tho] I think you are questioning the usefulness of protocol layers in specifications. I didn't wanted to broaden the discussion to that level. I was merely trying to understand if the UAs define a layer or not. So far I t! hink I received a positive answer. Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars. --0-1699493218-1137771622=:81584 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Siu Chai,
 
No, I am not questioning anything in xxUA specifications but instead pointing to the difference between normative and informative parts of them.
 
/ Stanislav
 
 


Siu Chai Tho <siuchaitho@yahoo.co.nz> wrote:
Hello Stanislav,

Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
Layering is a architectural design pattern and thus only applicable to implementations. Nevertheless it's an important architectural choice to choose layers.
 
[...]
 
[Stanislav Ivanovich] Nonsense!
Layering or not layering is certainly not visible on the external xxUA protocols since it is implementation matter. For example I have two M3UA ASP implementations:
1) One applies layered approach where traffic control appplication + supporting user part functions are kept intact while all the AS  concepts are put within a layer called "M3UA ASP" which is managed separately.
2) In the second non-layered approach I decide to make modifications to 3 SW components of traffic control application + 2 SW components of user part functions because by looking into product manaulas, descriptions, sequence diagrams (i.e. not in xxUA specifications but instead in my implementation documents) I found that it is easier to make these modifications than to introduce a separate "M3UA ASP" layer which shall be separately controlled by its own management (commands)...
 
However both (!) of my ASP implementations when connected to SGP behave strictly 100% in compliance with ASP-SGP protocol as defined in M3UA specification!
[Siu Chai Tho] I think you are questioning the usefulness of protocol layers in specifications. I didn't wanted to broaden the discussion to that level. I was merely trying to understand if the UAs define a layer or not. So far I t! hink I received a positive answer.
 
Thank you,
Joe
Send instant messages to your online friends http://au.messenger.yahoo.com _______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars. --0-1699493218-1137771622=:81584-- --===============1929639491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1929639491==-- From sigtran-bounces@ietf.org Fri Jan 20 11:21:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezz0w-0005ZD-Cj; Fri, 20 Jan 2006 11:21:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezz0u-0005Y5-7P for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 11:21:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26776 for ; Fri, 20 Jan 2006 11:19:53 -0500 (EST) Received: from uproxy.gmail.com ([66.249.92.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezz9b-0001k4-TD for sigtran@ietf.org; Fri, 20 Jan 2006 11:30:25 -0500 Received: by uproxy.gmail.com with SMTP id o2so41283uge for ; Fri, 20 Jan 2006 08:21:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=gigHwy28WuvCP8on9qlY8Au0pssQHPoALtIPjGUke9VhAfqUNbLGIfBaXT9VRCJ5F+oNTrSkIxWka0oMin9XIuf1drL/85IY6JpspNuRiqQylSHXkP/nYF12FZNhf6Y0b2NF8bSySKxXWAZS6CbhQ8r4Z/6xFHjGmhj0B9PKgzc= Received: by 10.48.3.10 with SMTP id 10mr155803nfc; Fri, 20 Jan 2006 08:21:12 -0800 (PST) Received: by 10.48.1.13 with HTTP; Fri, 20 Jan 2006 08:21:12 -0800 (PST) Message-ID: <17b146d60601200821g69582dc0se2a11eedcb9b25a3@mail.gmail.com> Date: Fri, 20 Jan 2006 17:21:12 +0100 From: Ilie Glib To: SIGTRAN , "bidulock@openss7.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 2.2 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: Subject: [Sigtran] SUA support for decoupled operation without final GTT at the SG X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello Brian, SIGTRAN community, as far as I can see from the SIGTRAN archive the support for decoupled operation without final GTT at the SG has been considered at early SUA stages. I find this proposal very useful. Brian, according to the mail archive you were the only proponent of this idea. Has it ever materialized into a description? Thank you in advance -- Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 20 12:27:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F002t-0001vJ-9R; Fri, 20 Jan 2006 12:27:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F002r-0001qa-Ub for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 12:27:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03022 for ; Fri, 20 Jan 2006 12:26:01 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[uRV3qXQkXjl6KCm3b7kmqP3z83qaJEBd]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00Bd-0004JR-5Q for sigtran@ietf.org; Fri, 20 Jan 2006 12:36:34 -0500 Received: from ns.pigworks.openss7.net (IDENT:ZJ/88jpzplhmsuzhKYJsKoUT7O1zqCAa@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0KHRHm03829; Fri, 20 Jan 2006 10:27:17 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0KHRH230158; Fri, 20 Jan 2006 10:27:17 -0700 Date: Fri, 20 Jan 2006 10:27:17 -0700 From: "Brian F. G. Bidulock" To: Ilie Glib Subject: Re: [Sigtran] SUA support for decoupled operation without final GTT at the SG Message-ID: <20060120102717.A29607@openss7.org> Mail-Followup-To: Ilie Glib , SIGTRAN References: <17b146d60601200821g69582dc0se2a11eedcb9b25a3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17b146d60601200821g69582dc0se2a11eedcb9b25a3@mail.gmail.com>; from ilie.glib@googlemail.com on Fri, Jan 20, 2006 at 05:21:12PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ilie, There is a ladder in the mail archive under the subject "RE: [SUA Issue 14] Changes and additions required for decoupled operation" throughout September 2001. This was Issue 14 at last call on SUA. A CO registration proposal was presented there that was initially placed in the SUA draft and then removed by the Editor (John) and the current Editor of the SUA I-G (Gery). Although a workable proposal was presented at the time, the issue was never fully addressed. If you want an SCTP-based protocol that works for SCCP, use Q.2220 over Q.2150.3 instead of SUA. --brian Ilie Glib wrote: (Fri, 20 Jan 2006 17:21:12) > Hello Brian, SIGTRAN community, > > as far as I can see from the SIGTRAN archive the support for decoupled > operation without final GTT at the SG has been considered at early SUA > stages. > > I find this proposal very useful. Brian, according to the mail archive > you were the only proponent of this idea. > > Has it ever materialized into a description? > > 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 From sigtran-bounces@ietf.org Fri Jan 20 12:28:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F003Y-0002LJ-Tn; Fri, 20 Jan 2006 12:28:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F003X-0002Kk-2Z for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 12:28:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03069 for ; Fri, 20 Jan 2006 12:26:42 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[Oe1uKVLNAiQpM2tQkgSiLc1v5hhbLFLn]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00CI-0004KX-7o for sigtran@ietf.org; Fri, 20 Jan 2006 12:37:15 -0500 Received: from ns.pigworks.openss7.net (IDENT:b/sIxKDs7kes5uH8MewD/9uTHHyuvxft@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0KHS7m03843; Fri, 20 Jan 2006 10:28:07 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0KHS6k30181; Fri, 20 Jan 2006 10:28:06 -0700 Date: Fri, 20 Jan 2006 10:28:06 -0700 From: "Brian F. G. Bidulock" To: devayya Subject: Re: [Sigtran] M2PA Alignment Question Message-ID: <20060120102806.B29607@openss7.org> Mail-Followup-To: devayya , "Davidson, Mark" , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E7170279D0E9@DCEVS2.tekelec.com> <20060119224757.A20140@openss7.org> <43D0AB5E.9030309@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <43D0AB5E.9030309@alcatel.com>; from devayya.bopaiah@alcatel.com on Fri, Jan 20, 2006 at 02:50:31PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sigtran@ietf.org, "Davidson, Mark" X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org devayya, Are you talking of Q.703 or M2PA? --brian devayya wrote: (Fri, 20 Jan 2006 14:50:31) > > Brian, > Consider another case. > Suppose in AlignedReady state, PO is received from remote, we stop T1 > timer and change the state to Processor outage state and if after some > time MSU is received from remote, then does that mean that the remote > PO is cleared and we need to change the state to Inservice state? > Please clarify.. > Thanks, > devayya > Brian F. G. Bidulock wrote: > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 20 12:35:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00Av-0006sj-9i; Fri, 20 Jan 2006 12:35:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00At-0006pQ-Ne for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 12:35:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03761 for ; Fri, 20 Jan 2006 12:34:19 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[JxUUNr7dMi2iVlOzCO55iBPzKHOKB8hu]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00Jf-0004bz-PA for sigtran@ietf.org; Fri, 20 Jan 2006 12:44:52 -0500 Received: from ns.pigworks.openss7.net (IDENT:vYv4N329XwdnwNsCrKsF0MKnwI2eNibS@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0KHZjm03922; Fri, 20 Jan 2006 10:35:45 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0KHZjj30262; Fri, 20 Jan 2006 10:35:45 -0700 Date: Fri, 20 Jan 2006 10:35:45 -0700 From: "Brian F. G. Bidulock" To: "Davidson, Mark" Subject: Re: [Sigtran] M2PA Alignment Question Message-ID: <20060120103545.C29607@openss7.org> Mail-Followup-To: "Davidson, Mark" , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E7170279D5BD@DCEVS2.tekelec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <58292FA6B3EEFD49AEDAF6597E21E7170279D5BD@DCEVS2.tekelec.com>; from Mark.Davidson@tekelec.com on Fri, Jan 20, 2006 at 09:22:03AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Mark, "The detailed functional breakdown shown in the following diagrams is intended to illustrate a reference model and to assist interpretation of the text in the earlier clauses. The stat transition diagrams are intended to show precisely the behaviour of the signalling system under normal and abnormal conditions AS VIEWED FROM A REMOTE LOCATION. It must be emphasized that the functional partitioining shown in the following diagrams is used only to facilitate understanding of the system behaviour and is NOT INTENDED TO SPECIFY THE FUNCTIONAL PARTITIONING TO BE ADOPTED IN A PRACTICAL IMPLEMENTATION OF THE SIGNALLING SYSTEM." Q.703/Clause 12. (Caps mine.) --brian Davidson, Mark wrote: (Fri, 20 Jan 2006 09:22:03) > Brian, > > Thank you for your informative response. > > I agree that using an implementation which, for instance, filters > duplicate FISUs in HW, would require changes to Q.703 SDLs in order to > work. Also, I understand this is a fairly simple problem to work > around. But if an implementation chooses not to deliver SUs to MTP2, > then modifications to the SDLs are beyond the scope of Q.703, and not > necessarily "defects." On the other hand, Q.781 tests acknowledge that > FISU filtering is a fact of life. > > The heart of the issue though, is that M2PA specifically says to "follow > the requirements of the applicable MTP2 specification" except as > modified in the RFC. If using Q.703 as a basis, how is one supposed to > know when to follow Q.703 and when not to? If Q.703 is considered > defective, why is it chosen as the normative document? Why are these > known "defects" not addressed in the RFC? > > I appreciate the effort you put in to your test plan draft, and I assure > you is is widely used, but I would prefer issues such as this to be > spelled out in something normative. > > -Mark > > > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Friday, January 20, 2006 12:48 AM > To: Davidson, Mark > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M2PA Alignment Question > > Mark, > > This is shown in the normal alignement procedure test cases in 3.1.5 and > 3.1.6 of draft-bidulock-sigtran-m2pa-test-06.txt (and the corresponding > Q.781/1.5 and 1.6 test cases). > > If you implement a Q.703 state machine directly from the SDLs with no > experience of the protocol, you may run into this problem. I ran into > it almost 20 years ago when performing LSSU compression between the > driver and the L2 state machine. If, for a normal Q.703 implementation, > you perform the longstanding FISUs compression technique (only providing > first and last indication from driver to state machine) with a state > machine implemented directly from the SDLs you will get this hang. > > However, the state machines as described in the Q.703 SDLs have two or > three race conditions that can cause problems too. Also, the Q.703 SDLs > will accept but never generate alignment using MSU instead of FISU as > shown in Q.781/1.6 and M2PA-TEST 3.1.6. > > You will find it on Q.703/Figure 8 Sheet 6 and 7 of 14. On Sheet 6, the > SDLs send a FISU, accept FISUs/MSUs and enter the Aligned Ready state. > On Sheet 7, it takes subsequent indication of a FISU or MSU to move to > the In Service State. To generate alignment with MSU requires that the > SDLs on Sheet 6 should check the Tx buffer and send MSU instead of FISU. > For in service on receiving an MSU (ala Q.781/1.6) the SDLs on > Q.703/Figure 16 (Sheed 3 of 6) should buffer received MSUs and mark > received FISUs during initial alignment. Then on Q.703/Figure 8 (Sheet > 7 of 14) the SDLs should detect whether an FISU/MSU was received prior > to alignment complete and move directly to the in service state. Any > thing else will not work as shown in Q.781/1.6 (the receiver will in > fact force the in-service MSU to be retransmitted and test case > Q.781/1.6 will fail). > > However, the text is overarching, and Q.703/Clause 7 does not say that > terminal waits for either FISU or MSU after alignment is complete, it > ways that it enters the aligned ready state and starts T1 after > alignment is complete and cancels T1 when it moves to the in service > state. What it does not say, is what moves it to the in service state. > > These are understandings of the nuances of the Q.703 SDLs that come with > experience and has little to do with M2PA. What is probably more > pertinent to current discussions regarding IG and the M2PA-TEST draft, > is that Q.703 SDLs implemented precisely as described in Q.703 will fail > test case Q.781/1.6. M2PA does not describe state machines so > precisely. In any event, I don't think that M2PA needs to be correcting > defects in the Q.703 SDLs. > > Nevertheless, just as Q.781 is itself a good guide to Q.703, the > M2PA-TEST document provides a good set of examples of how the > implementation is expected to behave. > > --brian > > Davidson, Mark wrote: (Thu, 19 Jan 2006 > 13:44:53) > > > > The following text regarding LSR suggests that M2PA is expected to > > > > behave like Q.703, entering the Aligned-Ready state (with T1 > > running) > > > > after Proving: > > > > > > > > > > > > The Link Status Ready message replaces the FISU of MTP2 that > is > > sent > > at the end of the proving period. The Link Status Ready > message > > is > > used to verify that both ends have completed proving. When > M2PA > > starts timer T1, it SHALL send a Link Status Ready message to > its > > peer in the case where MTP2 would send a FISU after proving is > > complete. If the Link Status Ready message is sent, then > M2PA > > MAY > > send additional Link Status Ready messages while timer T1 > is > > running. > > These Link Status Ready messages are sent on the Link > Status > > stream. > > > > > > > > But the latter part of Figure 12 of RFC shows the right side > going > > directly > > > > from Proving to In-Service. Is there some text > that > > describes/requires > > > > this behavior? I understand there is a problem if you don't do > > this, > > > > as you need another LSR to move from Aligned-Ready to In-Service. > > But > > > > M2PA only requires one to be sent (even with repeated LSRs, once T1 > > > > is stopped on the left, the right side could get stuck). > > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Jan 20 14:10:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01eq-0001DM-Qa; Fri, 20 Jan 2006 14:10:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01ep-0001CJ-UG for sigtran@megatron.ietf.org; Fri, 20 Jan 2006 14:10:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11368 for ; Fri, 20 Jan 2006 14:09:21 -0500 (EST) Received: from web35412.mail.mud.yahoo.com ([66.163.179.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F01nc-0007tC-M0 for sigtran@ietf.org; Fri, 20 Jan 2006 14:19:53 -0500 Received: (qmail 94819 invoked by uid 60001); 20 Jan 2006 19:10:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UcIFqr/EBipNCJ8k7MM0jyj8gNPSTGrZWeW0flDfGYrJpehwkQUjbeR7B8NJ/tQyZ4PGFUzpCS/gkluovh0VFmILobZKSUZDFgAphlIUUw15MGDOe7bYU2PFgaJzqgfeaN7VO362+9ki8zoEqu89FkGRLyDp7WbuG5KEE+HZm2E= ; Message-ID: <20060120191035.94817.qmail@web35412.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35412.mail.mud.yahoo.com via HTTP; Fri, 20 Jan 2006 11:10:35 PST Date: Fri, 20 Jan 2006 11:10:35 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060120154022.84035.qmail@web35411.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1770582180==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1770582180== Content-Type: multipart/alternative; boundary="0-310771530-1137784235=:93300" Content-Transfer-Encoding: 8bit --0-310771530-1137784235=:93300 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Siu Chai, In addition to the last mail, here is a practical example of my point that xxUA specifications certainly do not specify any box/layer (in terms of how ITU-T does it for MTP or SCCP or TCAP...) but instead xxUA specifications are only protocol specifications: NOTIFY chapters in xxUA specifications do not define any criteria how/when/if ASP/IPSP'es (application clones) should react to received NOTIFY message reporting insufficient resources. For example an AS consists of 3 application clones ASP1, ASP2 and ASP3 which are (like in all redundancy models) synchronized by application protocols (which are out of scope of xxUA specifications). If ASP2 is inactive and ASP3 fails while only ASP1 is active and working SGP may report insufficient resources to ASP2. Who do you think should respond to this NOTIFY? Can that do some "ASP xxUA layer/box" which does not contain application logic? Typically not since application logic is the owner of this decision. Anyway with very good reasons you do not have it specified in xxUA specifications and since the decision is normally in application logic therefore the upper interface itself is not normative but informative... If like you say xxUA is layer/box which MUST contain all the xxUA concepts and logic then how would that box answer NOTIFY if the criteria for this decision (as is the typically the case) is application owned? And each application can have its own criteria (e.g. if number of mobile subscibers is >xxx and ...then react with activation otherwise ignore...). As I said -> APS/IPSP'es are application processes and any layering inside them is out-of-scope of xxUA specifications. Any references there are only informative. What is said here for NOTIFY is similar for other xxUA chapters and messages... / Stanislav Ivanovich Stanislav Ivanovich wrote: Siu Chai, No, I am not questioning anything in xxUA specifications but instead pointing to the difference between normative and informative parts of them. / Stanislav Siu Chai Tho wrote: Hello Stanislav, Stanislav Ivanovich wrote: Layering is a architectural design pattern and thus only applicable to implementations. Nevertheless it's an important architectural choice to choose layers. [...] [Stanislav Ivanovich] Nonsense! Layering or not layering is certainly not visible on the external xxUA protocols since it is implementation matter. For example I have two M3UA ASP implementations: 1) One applies layered approach where traffic control appplication + supporting user part functions are kept intact while all the AS concepts are put within a layer called "M3UA ASP" which is managed separately. 2) In the second non-layered approach I decide to make modifications to 3 SW components of traffic control application + 2 SW components of user part functions because by looking into product manaulas, descriptions, sequence diagrams (i.e. not in xxUA specifications but instead in my implementation documents) I found that it is easier to make these modifications than to introduce a separate "M3UA ASP" layer which shall be separately controlled by its own management (commands)... However both (!) of my ASP implementations when connected to SGP behave strictly 100% in compliance with ASP-SGP protocol as defined in M3UA specification! [Siu Chai Tho] I think you are questioning the usefulness of protocol layers in specifications. I didn't wanted to broaden the discussion to that level. I was merely trying to understand if the UAs define a layer or not. So far I t! hink I received a positive answer. Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars._______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-310771530-1137784235=:93300 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Siu Chai,
 
In addition to the last mail, here is a practical example of my point that xxUA specifications certainly do not specify any box/layer (in terms of how ITU-T does it for MTP or SCCP or TCAP...) but instead xxUA specifications are only protocol specifications:
 
NOTIFY chapters in xxUA specifications do not define any criteria how/when/if ASP/IPSP'es (application clones) should react to received NOTIFY message reporting insufficient resources.
 
For example an AS consists of 3 application clones ASP1, ASP2 and ASP3 which are (like in all redundancy models) synchronized by application protocols (which are out of scope of xxUA specifications). If ASP2 is inactive and ASP3 fails while only ASP1 is active and working SGP may report insufficient resources to ASP2.
 
Who do you think should respond to this NOTIFY? Can that do some "ASP x! xUA layer/box" which does not contain application logic? Typically not since application logic is the owner of this decision. Anyway with very good reasons you do not have it specified in xxUA specifications and since the decision is normally in application logic therefore the upper interface itself is not normative but informative...
 
If like you say xxUA is layer/box which MUST contain all the xxUA concepts and logic then how would that box answer NOTIFY if the criteria for this decision (as is the typically the case) is application owned? And each application can have its own criteria (e.g. if number of mobile subscibers is >xxx and ...then react with activation otherwise ignore...).
 
As I said -> APS/IPSP'es are application processes and any layering inside them is out-of-scope of xxUA specifications. Any references there are only informative.
 
What is said here for NOTIFY is sim! ilar for other xxUA chapters and messages...

/ Stanislav Ivanovich
 
 

Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
Siu Chai,
 
No, I am not questioning anything in xxUA specifications but instead pointing to the difference between normative and informative parts of them.
 
/ Stanislav
 
 


Siu Chai Tho <siuchaitho@yahoo.co.nz> wrote:
Hello Stanislav,

Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
Layering is a architectural design pattern and thus only applicable to implementations. Nevertheless it's an important architectural choice to choose layers.
 
[...]
 
[Stanislav Ivanovich] Nonsense!
Layering or not layering is certainly not visible on the external xxUA protocols since it is implementation matter. For example I have two M3UA ASP implementations:
1) One applies layered approach where traffic control appplication + supporting user part functions are kept intact while all the AS  concepts are put within a layer called "M3UA ASP" which is managed separately.
2) In the second non-layered approach I decide to make modifications to 3 SW components of traffic control application + 2 SW components of user part functions because by looking in! to product manaulas, descriptions, sequence diagrams (i.e. not in xxUA specifications but instead in my implementation documents) I found that it is easier to make these modifications than to introduce a separate "M3UA ASP" layer which shall be separately controlled by its own management (commands)...
 
However both (!) of my ASP implementations when connected to SGP behave strictly 100% in compliance with ASP-SGP protocol as defined in M3UA specification!
[Siu Chai Tho] I think you are questioning the usefulness of protocol layers in specifications. I didn't wanted to broaden the discussion to that level. I was merely trying to understand if the UAs define a layer or not. So far I t! hink I received a positive answer.
 
Thank you,
Joe
Send instant messages to your online friends http://au.messenger.yahoo.com _______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars._______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-310771530-1137784235=:93300-- --===============1770582180== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1770582180==-- From sigtran-bounces@ietf.org Mon Jan 23 08:43:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F11yO-0008QC-A3; Mon, 23 Jan 2006 08:43:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F11yM-0008Q7-Ts for sigtran@megatron.ietf.org; Mon, 23 Jan 2006 08:43:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18524 for ; Mon, 23 Jan 2006 08:41:36 -0500 (EST) Received: from web37006.mail.mud.yahoo.com ([209.191.85.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F127a-000631-IN for sigtran@ietf.org; Mon, 23 Jan 2006 08:52:47 -0500 Received: (qmail 93500 invoked by uid 60001); 23 Jan 2006 13:42:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.nz; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UoRxsoeuZK6bAOGmA3pnEuHyJlUuPdjJ9rjkhkwSj2+USP7Z0bedConHpAi2KZztG6HiNheputo7fD0KSbhtMIhES0gR4B5EDYw45Q2jyN9tDoXzULZaQUBP7EmydWE07K3T0Bm94vTPqn91VpCc2zYp4CSCGodK2ZKNOUaJl/A= ; Message-ID: <20060123134248.93498.qmail@web37006.mail.mud.yahoo.com> Received: from [212.117.81.29] by web37006.mail.mud.yahoo.com via HTTP; Tue, 24 Jan 2006 02:42:48 NZDT Date: Tue, 24 Jan 2006 02:42:48 +1300 (NZDT) From: Siu Chai Tho Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060120191035.94817.qmail@web35412.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0482772073==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0482772073== Content-Type: multipart/alternative; boundary="0-64130256-1138023768=:91791" Content-Transfer-Encoding: 8bit --0-64130256-1138023768=:91791 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Stanislav, NOTIFY chapters in xxUA specifications do not define any criteria how/when/if ASP/IPSP'es (application clones) should react to received NOTIFY message reporting insufficient resources. [Siu Chai Tho] Please look into RFC 3868, chapter 4.3.4.5 "At the ASP, Layer Management is informed with an M-NOTIFY indication primitive." Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com --0-64130256-1138023768=:91791 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Stanislav,

NOTIFY chapters in xxUA specifications do not define any criteria how/when/if ASP/IPSP'es (application clones) should react to received NOTIFY message reporting insufficient resources.
[Siu Chai Tho] Please look into RFC 3868, chapter 4.3.4.5
"At the ASP, Layer Management is informed with an M-NOTIFY indication primitive."
 
Thank you,
Joe

Send instant messages to your online friends http://au.messenger.yahoo.com --0-64130256-1138023768=:91791-- --===============0482772073== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0482772073==-- From sigtran-bounces@ietf.org Mon Jan 23 10:20:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13UV-0001km-3G; Mon, 23 Jan 2006 10:20:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13UT-0001kg-12 for sigtran@megatron.ietf.org; Mon, 23 Jan 2006 10:20:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26607 for ; Mon, 23 Jan 2006 10:18:52 -0500 (EST) Received: from web35414.mail.mud.yahoo.com ([66.163.179.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F13dk-0001ev-T3 for sigtran@ietf.org; Mon, 23 Jan 2006 10:30:02 -0500 Received: (qmail 46214 invoked by uid 60001); 23 Jan 2006 15:20:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=23mlGIdDrV6oB5524lYSkJjSHE3ecRFEbx9AU1PVXIa5lFJ76ykO+4S+PlKKRXefReJqdpODOggcxoO4rOnbtfs/Uou4cbyGu9lg5mOIk1LRmtwsFwyDE97ONcRHJNlDUMJr3pRCV9eO8pgZA8ws4tjmDqkVJ7MrxdsPEbCMwlI= ; Message-ID: <20060123152006.46210.qmail@web35414.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35414.mail.mud.yahoo.com via HTTP; Mon, 23 Jan 2006 07:20:06 PST Date: Mon, 23 Jan 2006 07:20:06 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] M3UA and SUA recommendations To: SIGTRAN In-Reply-To: <20060123134248.93498.qmail@web37006.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0158165307==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0158165307== Content-Type: multipart/alternative; boundary="0-1445858152-1138029606=:45029" Content-Transfer-Encoding: 8bit --0-1445858152-1138029606=:45029 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Siu Chai, Then in this case (when applications are in charge of controlling standby state and possible reaction to this as is normally the case) you just have to understand "xxUA layer" <-> LM interface as "upper boundary" because application logic is the one which connects to MTP or SCCP (thus triggers sending of ASP ACTIVE/INAVTIVE etc...) and no problem ;-) However, if you understand LM as a configuration entitiy of "xxUA layer" not containing any application logic then you need to extend current "upper boudary" in the specifications... One way or another "upper boundary" depends on how you look at the "LM" thus is the matter of implementation rather than specification since specifications do not tell you that "LM" does or does not contain application logic. One way or another there is nothing conceptaully in between MTP3 (SGP) and User Part (ASP) or SCCP (SGP) and SCCP-user (ASP) -> evertyhing beyond this (e.g. layering) is just the implementation not visible on the external protocols... / Stanislav Ivanovich Siu Chai Tho wrote: Stanislav, NOTIFY chapters in xxUA specifications do not define any criteria how/when/if ASP/IPSP'es (application clones) should react to received NOTIFY message reporting insufficient resources. [Siu Chai Tho] Please look into RFC 3868, chapter 4.3.4.5 "At the ASP, Layer Management is informed with an M-NOTIFY indication primitive." Thank you, Joe Send instant messages to your online friends http://au.messenger.yahoo.com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1445858152-1138029606=:45029 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Siu Chai,
 
Then in this case (when applications are in charge of controlling standby state and possible reaction to this as is normally the case) you just have to understand "xxUA layer" <-> LM interface as "upper boundary" because application logic is the one which connects to MTP or SCCP (thus triggers sending of ASP ACTIVE/INAVTIVE etc...) and no problem ;-)
 
However, if you understand LM as a configuration entitiy of "xxUA layer" not containing any application logic then you need to extend current "upper boudary" in the specifications...
 
One way or another "upper boundary" depends on how you look at the "LM" thus is the matter of implementation rather than specification since specifications do not tell you that "LM" does or does not contain application logic. One way or another there is nothing conceptaully in between MTP3 (SGP) and User Part (ASP) or SCCP (SGP) and SCCP-user (ASP) -> evertyhing beyond this (e.g. layering) is just the implementation not visible on the external protocols...
 
/ Stanislav Ivanovich
 


Siu Chai Tho <siuchaitho@yahoo.co.nz> wrote:
Stanislav,

NOTIFY chapters in xxUA specifications do not define any criteria how/when/if ASP/IPSP'es (application clones) should react to received NOTIFY message reporting insufficient resources.
[Siu Chai Tho] Please look into RFC 3868, chapter 4.3.4.5
"At the ASP, Layer Management is informed with an M-NOTIFY indication primitive."
 
Thank you,
J! oe
Send instant messages to your online friends http://au.messenger.yahoo.com _______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1445858152-1138029606=:45029-- --===============0158165307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0158165307==-- From sigtran-bounces@ietf.org Tue Jan 24 00:47:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1H1T-0004Fx-HM; Tue, 24 Jan 2006 00:47:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1H1R-0004Fn-Uh for sigtran@megatron.ietf.org; Tue, 24 Jan 2006 00:47:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09262 for ; Tue, 24 Jan 2006 00:45:47 -0500 (EST) Received: from hostree9f.alcatel.com ([143.209.238.159] helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1HAh-0002TM-2u for sigtran@ietf.org; Tue, 24 Jan 2006 00:56:54 -0500 Received: from axes-mach01.usa.alcatel.com (axes-mach01.usa.alcatel.com [10.255.0.20]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id k0O5eHLS006770; Mon, 23 Jan 2006 23:46:51 -0600 Received: from [10.255.1.166] (ax-sp-pc114.usa.alcatel.com [10.255.1.166]) by axes-mach01.usa.alcatel.com (8.12.10+Sun/8.12.2) with ESMTP id k0NDgcHb004373; Mon, 23 Jan 2006 19:12:47 +0530 (IST) Message-ID: <43D4DE1F.1060803@alcatel.com> Date: Mon, 23 Jan 2006 19:16:07 +0530 From: devayya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Sigtran] M2PA Alignment Question References: <58292FA6B3EEFD49AEDAF6597E21E7170279D0E9@DCEVS2.tekelec.com> <20060119224757.A20140@openss7.org> <43D0AB5E.9030309@alcatel.com> <20060120102806.B29607@openss7.org> In-Reply-To: <20060120102806.B29607@openss7.org> X-Scanned-By: MIMEDefang 2.51 on 143.209.238.159 X-Spam-Score: 1.0 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0245828947==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0245828947== Content-Type: multipart/alternative; boundary="------------030900090908050903070703" This is a multi-part message in MIME format. --------------030900090908050903070703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian, I was talking about M2PA in this case. Please guide me. thanks, devayya Brian F. G. Bidulock wrote: >devayya, > >Are you talking of Q.703 or M2PA? > >--brian > >devayya wrote: (Fri, 20 Jan 2006 14:50:31) > > >> Brian, >> Consider another case. >> Suppose in AlignedReady state, PO is received from remote, we stop T1 >> timer and change the state to Processor outage state and if after some >> time MSU is received from remote, then does that mean that the remote >> PO is cleared and we need to change the state to Inservice state? >> Please clarify.. >> Thanks, >> devayya >> Brian F. G. Bidulock wrote: >> >> >> > > > --------------030900090908050903070703 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Brian,

I was talking about M2PA in this case. Please guide me.

thanks,
devayya


Brian F. G. Bidulock wrote:
devayya,

Are you talking of Q.703 or M2PA?

--brian

devayya wrote:                                   (Fri, 20 Jan 2006 14:50:31)
  
   Brian,
   Consider another case.
   Suppose  in AlignedReady state, PO is received from remote, we stop T1
   timer and change the state to Processor outage state and if after some
   time  MSU is received from remote, then does that mean that the remote
   PO is cleared and we need to change the state to Inservice state?
   Please clarify..
   Thanks,
   devayya
   Brian F. G. Bidulock wrote:
--------------030900090908050903070703-- --===============0245828947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0245828947==-- From sigtran-bounces@ietf.org Tue Jan 24 00:49:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1H3U-0004Xe-Q7; Tue, 24 Jan 2006 00:49:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1H3S-0004WF-US for sigtran@megatron.ietf.org; Tue, 24 Jan 2006 00:49:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09350 for ; Tue, 24 Jan 2006 00:47:52 -0500 (EST) Received: from hostreea2.alcatel.com ([143.209.238.162] helo=audl953.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1HCw-0002XA-9n for sigtran@ietf.org; Tue, 24 Jan 2006 00:59:11 -0500 Received: from axes-mach01.usa.alcatel.com (axes-mach01.usa.alcatel.com [10.255.0.20]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id k0O5j2Oo014761; Mon, 23 Jan 2006 23:49:11 -0600 Received: from [10.255.1.166] (ax-sp-pc114.usa.alcatel.com [10.255.1.166]) by axes-mach01.usa.alcatel.com (8.12.10+Sun/8.12.2) with ESMTP id k0N4FpHb019996; Mon, 23 Jan 2006 09:46:05 +0530 (IST) Message-ID: <43D45949.8080709@alcatel.com> Date: Mon, 23 Jan 2006 09:49:21 +0530 From: devayya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Sigtran] M2PA Alignment Question References: <58292FA6B3EEFD49AEDAF6597E21E7170279D0E9@DCEVS2.tekelec.com> <20060119224757.A20140@openss7.org> <43D0AB5E.9030309@alcatel.com> <20060120102806.B29607@openss7.org> In-Reply-To: <20060120102806.B29607@openss7.org> X-Scanned-By: MIMEDefang 2.51 on 143.209.238.162 X-Spam-Score: 1.0 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sigtran@ietf.org, "Davidson, Mark" X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1695490986==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1695490986== Content-Type: multipart/alternative; boundary="------------080208040500000605040906" This is a multi-part message in MIME format. --------------080208040500000605040906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian, I was talking about M2PA in this case. Please guide me. thanks, devayya Brian F. G. Bidulock wrote: >devayya, > >Are you talking of Q.703 or M2PA? > >--brian > >devayya wrote: (Fri, 20 Jan 2006 14:50:31) > > >> Brian, >> Consider another case. >> Suppose in AlignedReady state, PO is received from remote, we stop T1 >> timer and change the state to Processor outage state and if after some >> time MSU is received from remote, then does that mean that the remote >> PO is cleared and we need to change the state to Inservice state? >> Please clarify.. >> Thanks, >> devayya >> Brian F. G. Bidulock wrote: >> >> >> > > > --------------080208040500000605040906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Brian,

I was talking about M2PA in this case. Please guide me.

thanks,
devayya


Brian F. G. Bidulock wrote: 
devayya,

Are you talking of Q.703 or M2PA?

--brian

devayya wrote:                                   (Fri, 20 Jan 2006 14:50:31)
  
   Brian,
   Consider another case.
   Suppose  in AlignedReady state, PO is received from remote, we stop T1
   timer and change the state to Processor outage state and if after some
   time  MSU is received from remote, then does that mean that the remote
   PO is cleared and we need to change the state to Inservice state?
   Please clarify..
   Thanks,
   devayya
   Brian F. G. Bidulock wrote:
--------------080208040500000605040906-- --===============1695490986== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1695490986==-- From sigtran-bounces@ietf.org Tue Jan 24 01:59:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1I9b-0001ix-G6; Tue, 24 Jan 2006 01:59:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1I9V-0001iE-Cc for sigtran@megatron.ietf.org; Tue, 24 Jan 2006 01:59:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13821 for ; Tue, 24 Jan 2006 01:58:10 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[3JLrhj9jui5uD9igM5lGNoCPx/mNUT62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1IIw-0004sp-EL for sigtran@ietf.org; Tue, 24 Jan 2006 02:09:27 -0500 Received: from ns.pigworks.openss7.net (IDENT:TLhnFeOcSWDKWYz+opvCKS9btXniiVIS@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0O6xMw19996; Mon, 23 Jan 2006 23:59:22 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0O6xLO01870; Mon, 23 Jan 2006 23:59:21 -0700 Date: Mon, 23 Jan 2006 23:59:21 -0700 From: "Brian F. G. Bidulock" To: devayya Subject: Re: [Sigtran] M2PA Alignment Question Message-ID: <20060123235921.A1752@openss7.org> Mail-Followup-To: devayya , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E7170279D0E9@DCEVS2.tekelec.com> <20060119224757.A20140@openss7.org> <43D0AB5E.9030309@alcatel.com> <20060120102806.B29607@openss7.org> <43D4DE1F.1060803@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <43D4DE1F.1060803@alcatel.com>; from devayya.bopaiah@alcatel.com on Mon, Jan 23, 2006 at 07:16:07PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org devayya, In M2PA you need to receive a Status LPR to leave the Aligned Not Ready/RPO state. --brian devayya wrote: (Mon, 23 Jan 2006 19:16:07) > > Brian, > I was talking about M2PA in this case. Please guide me. > thanks, > devayya > Brian F. G. Bidulock wrote: > > devayya, > > Are you talking of Q.703 or M2PA? > > --brian > > devayya wrote: (Fri, 20 Jan 2006 14:50:31) > > > Brian, > Consider another case. > Suppose in AlignedReady state, PO is received from remote, we stop T1 > timer and change the state to Processor outage state and if after some > time MSU is received from remote, then does that mean that the remote > PO is cleared and we need to change the state to Inservice state? > Please clarify.. > Thanks, > devayya > Brian F. G. Bidulock wrote: > > > > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 24 02:06:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1IFu-0003aZ-2D; Tue, 24 Jan 2006 02:06:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1IFr-0003aN-9H for sigtran@megatron.ietf.org; Tue, 24 Jan 2006 02:06:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14176 for ; Tue, 24 Jan 2006 02:04:44 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1IPL-00055r-HJ for Sigtran@ietf.org; Tue, 24 Jan 2006 02:16:04 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0O73eYN071754 for ; Mon, 23 Jan 2006 23:03:41 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <004401c620b4$795bcfa0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Tue, 24 Jan 2006 10:04:44 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1247/Sat Jan 21 02:24:51 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: [Sigtran] DUA and V5UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1014692818==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1014692818== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C620CD.99DF98B0" This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C620CD.99DF98B0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, I have a question on terminology. DUA (RFC 4129) is considered just as extensions to IUA protocol (even = when having its own SCTP Payload protocol ID, no different port number, = and some differences from IUA, e.g. in DLCI field format in message = header), while V5UA (RFC 3807) is considered a protocol. Both RFCs say = that the respective UA "... builds on top of IUA, defining the necessary = extensions to IUA for a ... implementation." Is there a valid reason for such differentiation between "extensions to = the protocol" and "protocol" in this particular case of DUA and V5UA? Regards, Sergey Mikhailov. ------=_NextPart_000_003F_01C620CD.99DF98B0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have a question on = terminology.
 
DUA (RFC 4129) is considered just as = extensions to=20 IUA protocol (even when having its own SCTP Payload protocol ID, no = different=20 port number, and some differences from IUA, e.g. in DLCI field = format in=20 message header), while V5UA (RFC 3807) is considered a protocol. Both = RFCs say=20 that the respective UA "... builds on top of IUA, defining the = necessary=20 extensions to IUA for a ... implementation."
 
Is there a valid reason for such = differentiation=20 between "extensions to the protocol" and "protocol" in this particular = case of=20 DUA and V5UA?
 
 
Regards,
Sergey = Mikhailov.
------=_NextPart_000_003F_01C620CD.99DF98B0-- --===============1014692818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1014692818==-- From sigtran-bounces@ietf.org Tue Jan 24 04:40:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Kep-0005Ga-JN; Tue, 24 Jan 2006 04:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Ken-0005GS-6F for sigtran@megatron.ietf.org; Tue, 24 Jan 2006 04:40:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23347 for ; Tue, 24 Jan 2006 04:38:37 -0500 (EST) From: chen.puran@zte.com.cn Received: from [202.103.147.144] (helo=mail2.zte.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1KoI-0001mL-6C for sigtran@ietf.org; Tue, 24 Jan 2006 04:50:00 -0500 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 70900.1231352264; Tue, 24 Jan 2006 18:48:27 +0800 (CST) To: sigtran@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 24 Jan 2006 17:40:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September 14, 2004) at 2006-01-24 17:39:59 MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sigtran] sua ssnm messageand stram id X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1682903285==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1682903285== Content-type: text/plain; charset=GB2312 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 aGmjrA0KaW4gc3VhcmZjIDM4NjggIDQuNS4xDQqjug0KDQoNCkRVTkEsIERBVkEsIFNDT04sIGFu ZCBEUlNUIG1lc3NhZ2VzIGFyZSBzZW50IHNlcXVlbnRpYWxseSBhbmQNCiAgIHByb2Nlc3NlZCBh dCB0aGUgcmVjZWl2ZXIgaW4gdGhlIG9yZGVyIHNlbnQuICBTQ1RQIHN0cmVhbSAwIFNIT1VMRA0K ICAgTk9UIGJlIHVzZWQuICBUaGUgVW5vcmRlcmVkIGJpdCBpbiB0aGUgU0NUUCBEQVRBIGNodW5r IE1BWSBiZSB1c2VkDQogICBmb3IgdGhlIFNDT04gbWVzc2FnZS4NCg0KICAgU2VxdWVuY2luZyBp cyBub3QgcmVxdWlyZWQgZm9yIHRoZSBEVVBVIG9yIERBVUQgbWVzc2FnZXMsIHdoaWNoIE1BWQ0K ICAgYmUgc2VudCB1bm9yZGVyZWQuICBTQ1RQIHN0cmVhbSAwIGlzIHVzZWQsIHdpdGggb3B0aW9u YWwgdXNlIG9mIHRoZQ0KICAgVW5vcmRlcmVkIGJpdCBpbiB0aGUgU0NUUCBEQVRBIGNodW5rLg0K DQp3aHkgRFVOQSBEQVZBIHNob3VsZCBub3QgdXNlIHN0cmVtIDAgo7+jv6O/o78gaW4gbTN1YXJm YzMzMzIgaGFzIG5vIHRoZQ0Kc3RyZWFtIGRpc2NyaXB0aW9uoaMNCg0KDQoNCqHBocGhwaHBocGh waHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocENCiAuLi4uLi4uLi5MaXZl Li4uLi4uLi4uLi4uLi5TdHJvbmdlci4uLi4uLi4uLi4uLi4uLg0KocGhwaHBocGhwaHBocGhwaHB ocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGhwQ0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KxM++qcrQ0+q7qMyox/jXz76ju6jCtzY4 usXW0NDLzajRtrTzz8PW0NDE0dC+v9S6M0fGvcyoyO28/rb+sr8NCrXnu7Cjuig4NikyNaOtNTI4 NzI5MDQsIzAyNTgyOTA0DQq159PKo7pjaGVuLnB1cmFuQG1haWwuenRlLmNvbS5jbg0KTVNOOiBh YmJhX2VhZ2xlQGhvdG1haWwuY29tDQrTyrHgo7oyMTAwMTINCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCgoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0K0MXPorCyyKvJ+cP3o7qxvtPKvP6w/Lqs0MXPornp t6K8/sjLy/nU2tfp1q/L+dPQo6wNCreivP7Iy8v51NrX6davttS4w9PKvP7TtdPQy/nT0MiowPuh o8frvdPK1dXf16LS4g0KsaPD3KOszrS+rbeivP7Iy8rpw+bQ7b/Jo6yyu7XDz/LIzrrOtdoNCsj9 t73X6davus249sjLzbjCtrG+08q8/sv5uqzQxc+itcTIq7K/DQq78rK/t9aho9LUyc/J+cP3vfbK ytPD09q5pNf308q8/qGjDQpJbmZvcm1hdGlvbiBTZWN1cml0eSAgTm90aWNlo7oNClRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzDQpzb2xlbHkgcHJvcGVydHkgb2YgIHRo ZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIA0KVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29u ZmlkZW50aWFsLg0KUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvDQptYWlu dGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0bw0KZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbg0KdG8gb3RoZXJzLg0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCgo= --===============1682903285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1682903285==-- From sigtran-bounces@ietf.org Tue Jan 24 04:51:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Kpi-0008GW-Ew; Tue, 24 Jan 2006 04:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Kpg-0008GO-Br for sigtran@megatron.ietf.org; Tue, 24 Jan 2006 04:51:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23937 for ; Tue, 24 Jan 2006 04:49:55 -0500 (EST) From: Reynald.Le_Doeuff@alcatel.fr Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1KzC-0002Ab-W8 for sigtran@ietf.org; Tue, 24 Jan 2006 05:01:15 -0500 Received: from frmail27.netfr.alcatel.fr (frmail27.netfr.alcatel.fr [155.132.182.157]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k0O9pDT4000324 for ; Tue, 24 Jan 2006 10:51:14 +0100 To: sigtran@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Tue, 24 Jan 2006 10:51:11 +0100 X-MIMETrack: Serialize by Router on FRMAIL27/FR/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/24/2006 10:51:13, Serialize complete at 01/24/2006 10:51:13 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 1.1 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Sigtran] RFC 4233 - IUA - TEI status Messages X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1584689633==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multipart message in MIME format. --===============1584689633== Content-Type: multipart/alternative; boundary="=_alternative 00362047C1257100_=" This is a multipart message in MIME format. --=_alternative 00362047C1257100_= Content-Type: text/plain; charset="US-ASCII" Here are my questions : RFC 4233 # 3.3.3.3 TEI Status Messages (Request, Confirm, and Indication) The TEI Status messages are exchanged between IUA layer peers to request, confirm, and indicate the status of a particular TEI Q1 : what do you mean by "Status" -> is it the status of the Data Link for a particular TEI (SABME / UA + RR) -> or is it the TEI affectation as defined in Q.921 #5.3 (Identity request / Identity assigned) Q2 : what is the difference between "TEI Status Message (Request)" (cf 3.3.3.3) and "TEI Query Message (Request)" ? (cf 3.3.3.4). thank you Reynald --=_alternative 00362047C1257100_= Content-Type: text/html; charset="US-ASCII"
Here are my questions :

RFC 4233 # 3.3.3.3 TEI Status Messages (Request, Confirm, and Indication)

The TEI Status messages are exchanged between IUA layer peers to
   request, confirm, and indicate the status of a particular TEI

Q1 : what do you mean by "Status"
-> is it the status of the Data Link for a particular TEI (SABME / UA + RR)
-> or is it the TEI affectation as defined in Q.921 #5.3 (Identity request / Identity assigned)

Q2 : what is the difference between "TEI Status Message (Request)" (cf 3.3.3.3)
and "TEI Query Message (Request)" ? (cf 3.3.3.4).

thank you

Reynald --=_alternative 00362047C1257100_=-- --===============1584689633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1584689633==-- From sigtran-bounces@ietf.org Tue Jan 24 05:12:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1LAF-0005sL-8E; Tue, 24 Jan 2006 05:12:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1LAD-0005pO-30 for sigtran@megatron.ietf.org; Tue, 24 Jan 2006 05:12:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25653 for ; Tue, 24 Jan 2006 05:11:07 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[7YcKqcXbG41rrvKDUPt96Crmct4jtwBR]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1LJi-00031s-Rw for sigtran@ietf.org; Tue, 24 Jan 2006 05:22:28 -0500 Received: from ns.pigworks.openss7.net (IDENT:HZROb6IM12Oa7It0CLbmDmm9Q4ZhFErY@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0OACXw29849; Tue, 24 Jan 2006 03:12:33 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0OACXb03428; Tue, 24 Jan 2006 03:12:33 -0700 Date: Tue, 24 Jan 2006 03:12:33 -0700 From: "Brian F. G. Bidulock" To: chen.puran@zte.com.cn Subject: Re: [Sigtran] sua ssnm messageand stram id Message-ID: <20060124031233.A3384@openss7.org> Mail-Followup-To: chen.puran@zte.com.cn, sigtran@ietf.org References: Mime-Version: 1.0 User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from chen.puran@zte.com.cn on Tue, Jan 24, 2006 at 05:40:17PM +0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to base64 by gw.openss7.com id k0OACXw29849 X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1899973569==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1899973569== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Y2hlbi5wdXJhbiwNCg0KDQpjaGVuLnB1cmFuQHp0ZS5jb20uY24gd3JvdGU6ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKFR1ZSwgMjQgSmFuIDIwMDYgMTc6NDA6MTcp DQo+IGhpo6wNCj4gaW4gc3VhcmZjIDM4NjggIDQuNS4xDQo+IKO6DQo+IA0KPiANCj4gRFVO QSwgREFWQSwgU0NPTiwgYW5kIERSU1QgbWVzc2FnZXMgYXJlIHNlbnQgc2VxdWVudGlhbGx5 IGFuZA0KPiAgICBwcm9jZXNzZWQgYXQgdGhlIHJlY2VpdmVyIGluIHRoZSBvcmRlciBzZW50 LiAgU0NUUCBzdHJlYW0gMCBTSE9VTEQNCj4gICAgTk9UIGJlIHVzZWQuICBUaGUgVW5vcmRl cmVkIGJpdCBpbiB0aGUgU0NUUCBEQVRBIGNodW5rIE1BWSBiZSB1c2VkDQo+ICAgIGZvciB0 aGUgU0NPTiBtZXNzYWdlLg0KPiANCj4gICAgU2VxdWVuY2luZyBpcyBub3QgcmVxdWlyZWQg Zm9yIHRoZSBEVVBVIG9yIERBVUQgbWVzc2FnZXMsIHdoaWNoIE1BWQ0KPiAgICBiZSBzZW50 IHVub3JkZXJlZC4gIFNDVFAgc3RyZWFtIDAgaXMgdXNlZCwgd2l0aCBvcHRpb25hbCB1c2Ug b2YgdGhlDQo+ICAgIFVub3JkZXJlZCBiaXQgaW4gdGhlIFNDVFAgREFUQSBjaHVuay4NCj4g DQo+IHdoeSBEVU5BIERBVkEgc2hvdWxkIG5vdCB1c2Ugc3RyZW0gMCCjv6O/o7+jvyBpbiBt M3VhcmZjMzMzMiBoYXMgbm8gdGhlDQo+IHN0cmVhbSBkaXNjcmlwdGlvbqGjDQo+IA0KPiAN Cj4gDQo+IKHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGh waHBocENCj4gIC4uLi4uLi4uLkxpdmUuLi4uLi4uLi4uLi4uLlN0cm9uZ2VyLi4uLi4uLi4u Li4uLi4uDQo+IKHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGhwaHBocGhwaHB ocGhwaHBocENCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KPiDEz76pytDT6ruozKjH+NfPvqO7qMK3Nji6xdbQ0MvNqNG2tPPPw9bQ 0MTR0L6/1LozR8a9zKjI7bz+tv6yvw0KPiC157uwo7ooODYpMjWjrTUyODcyOTA0LCMwMjU4 MjkwNA0KPiC159PKo7pjaGVuLnB1cmFuQG1haWwuenRlLmNvbS5jbg0KPiBNU046IGFiYmFf ZWFnbGVAaG90bWFpbC5jb20NCj4g08qx4KO6MjEwMDEyDQo+ID09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KWW91IG11c3QgcmVtb3Zl IHRoZSBmb2xsb3dpbmcgbm90aWNlIHdoZW4geW91IHBvc3QgdG8gdGhpcyBsaXN0Lg0KDQot LWJyaWFuDQoNCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KPiDQxc+isLLIq8n5w/ejurG+08q8/rD8uqzQxc+iuem3orz+yMvL +dTa1+nWr8v509CjrA0KPiC3orz+yMvL+dTa1+nWr7bUuMPTyrz+07XT0Mv509DIqMD7oaPH 673TytXV39ei0uINCj4gsaPD3KOszrS+rbeivP7Iy8rpw+bQ7b/Jo6yyu7XDz/LIzrrOtdoN Cj4gyP23vdfp1q+6zbj2yMvNuMK2sb7Tyrz+y/m6rNDFz6K1xMirsr8NCj4gu/Kyv7fWoaPS 1MnPyfnD9732ysrTw9PauaTX99PKvP6how0KPiBJbmZvcm1hdGlvbiBTZWN1cml0eSAgTm90 aWNlo7oNCj4gVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMNCj4g c29sZWx5IHByb3BlcnR5IG9mICB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiANCj4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLg0KPiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8NCj4gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJl IG5vdCBwZXJtaXR0ZWQgdG8NCj4gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbg0KPiB0byBvdGhlcnMuDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQo+IA0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNpZ3RyYW4gbWFpbGluZyBsaXN0DQo+IFNp Z3RyYW5AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lndHJhbg0KDQoNCi0tIA0KQnJpYW4gRi4gRy4gQmlkdWxvY2sNCmJpZHVsb2NrQG9w ZW5zczcub3JnDQpodHRwOi8vd3d3Lm9wZW5zczcub3JnLw0K --===============1899973569== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1899973569==-- From sigtran-bounces@ietf.org Tue Jan 24 06:58:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1MoW-0001jA-KW; Tue, 24 Jan 2006 06:58:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1MoU-0001hg-Kw for sigtran@megatron.ietf.org; Tue, 24 Jan 2006 06:58:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04285 for ; Tue, 24 Jan 2006 06:56:46 -0500 (EST) Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Mxz-0006ou-MD for Sigtran@ietf.org; Tue, 24 Jan 2006 07:08:08 -0500 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0OBurp03814; Tue, 24 Jan 2006 06:56:53 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sigtran] DUA and V5UA Date: Tue, 24 Jan 2006 11:56:36 -0000 Message-ID: <78C698004E263B488351B16611F3379F05E87E71@zharhxm1.corp.nortel.com> Thread-Topic: [Sigtran] DUA and V5UA Thread-Index: AcYgtUk4mPbDkyO3RPa6ps7g2dAjgQAJD/9Q From: "Michael Mentz" To: "Sergey Mikhailov" , "SIGTRAN" X-Spam-Score: 0.6 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0794473368==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0794473368== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C620DD.3AEB4538" This is a multi-part message in MIME format. ------_=_NextPart_001_01C620DD.3AEB4538 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sergey, =20 This is a common question when first looking at the two specifications =20 In essence, the DUA 'extension' should be considered as actually being part of RFC3057 - ie, RFC3057+DUA Extension. =20 All the DUA extension does is introduce some extra messaging and handling in order for the RFC3057 ASP to also support DPNSS interfaces. This follows with the real world use of DPNSS/DASS2, alongside PRI - most vendors offer PRI and DPNSS/DASS2 interfaces on their box - hence the spec takes this into account. =20 Therefore, your RFC3057 ASP has interface identifiers that either use QPTM messaging for PRI/BRI/QSIG, or DPTM messaging for DPNSS/DASS2. =20 =20 For V5UA, the differences are far more fundamental - for one, V5UA uses a different Interface ID format, no doubt this is one of the primary reasons why it is split into it's own protocol. Interfaces Identifiers must be unique within the domain of their ASP, so V5UA cannot run alongside RFC3057 interfaces, and hence must run a separate ASP. Because there is a 1:1 mapping between an ASP and SCTP association, V5UA requires a different SCTP port number. There is probably many other reasons more fundamental than this... =20 =20 As for the SCTP PPID, the only use I have ever seen for this is in tools such as ethereal - it maybe useful to operator to see the QPTM/DPTM data split... =20 Hope this helps, =20 Mike ________________________________ From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Sergey Mikhailov Sent: 24 January 2006 07:05 To: SIGTRAN Subject: [Sigtran] DUA and V5UA Hi, =20 I have a question on terminology. =20 DUA (RFC 4129) is considered just as extensions to IUA protocol (even when having its own SCTP Payload protocol ID, no different port number, and some differences from IUA, e.g. in DLCI field format in message header), while V5UA (RFC 3807) is considered a protocol. Both RFCs say that the respective UA "... builds on top of IUA, defining the necessary extensions to IUA for a ... implementation." =20 Is there a valid reason for such differentiation between "extensions to the protocol" and "protocol" in this particular case of DUA and V5UA? =20 =20 Regards, Sergey Mikhailov. ------_=_NextPart_001_01C620DD.3AEB4538 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sergey,
 
This is a common question when first looking at = the two=20 specifications
 
In essence, the DUA 'extension' should be = considered as=20 actually being part of RFC3057 - ie, RFC3057+DUA = Extension.
 
All the DUA extension does is introduce some = extra=20 messaging and handling in order for the RFC3057 ASP to also support = DPNSS=20 interfaces.
This follows with the real world use of=20 DPNSS/DASS2, alongside PRI - most vendors offer PRI and DPNSS/DASS2 = interfaces on their box - hence the spec takes this into=20 account.
 
Therefore, your RFC3057 ASP has interface = identifiers that=20 either use QPTM messaging for PRI/BRI/QSIG, or DPTM messaging for=20 DPNSS/DASS2.
 
 
For V5UA, the differences are far more = fundamental - for=20 one, V5UA uses a different Interface ID format, no doubt this is one of = the=20 primary reasons why it is split into it's own = protocol.
Interfaces Identifiers must be unique within = the domain of=20 their ASP, so V5UA cannot run alongside RFC3057 interfaces, and hence = must run a=20 separate ASP.
Because there is a 1:1 mapping between an ASP = and SCTP=20 association, V5UA requires a different SCTP port = number.
There is probably many other reasons more = fundamental than=20 this...
 
 
As for the SCTP PPID, the only use I have ever = seen for=20 this is in tools such as ethereal - it maybe useful to operator to see = the=20 QPTM/DPTM data split...
 
Hope this helps,
 
Mike
From: sigtran-bounces@ietf.org=20 [mailto:sigtran-bounces@ietf.org] On Behalf Of Sergey=20 Mikhailov
Sent: 24 January 2006 07:05
To:=20 SIGTRAN
Subject: [Sigtran] DUA and V5UA

Hi,
 
I have a question on = terminology.
 
DUA (RFC 4129) is considered just as = extensions to=20 IUA protocol (even when having its own SCTP Payload protocol ID, no = different=20 port number, and some differences from IUA, e.g. in DLCI field = format in=20 message header), while V5UA (RFC 3807) is considered a protocol. Both = RFCs say=20 that the respective UA "... builds on top of IUA, defining the = necessary=20 extensions to IUA for a ... implementation."
 
Is there a valid reason for such = differentiation=20 between "extensions to the protocol" and "protocol" in this particular = case of=20 DUA and V5UA?
 
 
Regards,
Sergey = Mikhailov.
------_=_NextPart_001_01C620DD.3AEB4538-- --===============0794473368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0794473368==-- From sigtran-bounces@ietf.org Tue Jan 24 07:28:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NI0-0002BO-BC; Tue, 24 Jan 2006 07:28:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NHy-00024x-7K for sigtran@megatron.ietf.org; Tue, 24 Jan 2006 07:28:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06870 for ; Tue, 24 Jan 2006 07:27:15 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NRV-00083h-TU for Sigtran@ietf.org; Tue, 24 Jan 2006 07:38:38 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k0OCPUvN073170; Tue, 24 Jan 2006 04:25:56 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <008001c620e1$7e3e2450$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "Michael Mentz" References: <78C698004E263B488351B16611F3379F05E87E71@zharhxm1.corp.nortel.com> Subject: Re: [Sigtran] DUA and V5UA Date: Tue, 24 Jan 2006 15:26:26 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1247/Sat Jan 21 02:24:51 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1174040270==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1174040270== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01C620FA.8A6ADD90" This is a multi-part message in MIME format. ------=_NextPart_000_007D_01C620FA.8A6ADD90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for the explanation, Mike. Best regards, Sergey Mikhailov. ----- Original Message -----=20 From: Michael Mentz=20 To: Sergey Mikhailov ; SIGTRAN=20 Sent: Tuesday, January 24, 2006 2:56 PM Subject: RE: [Sigtran] DUA and V5UA Hi Sergey, This is a common question when first looking at the two specifications In essence, the DUA 'extension' should be considered as actually being = part of RFC3057 - ie, RFC3057+DUA Extension. All the DUA extension does is introduce some extra messaging and = handling in order for the RFC3057 ASP to also support DPNSS interfaces. This follows with the real world use of DPNSS/DASS2, alongside PRI - = most vendors offer PRI and DPNSS/DASS2 interfaces on their box - hence = the spec takes this into account. Therefore, your RFC3057 ASP has interface identifiers that either use = QPTM messaging for PRI/BRI/QSIG, or DPTM messaging for DPNSS/DASS2. For V5UA, the differences are far more fundamental - for one, V5UA = uses a different Interface ID format, no doubt this is one of the = primary reasons why it is split into it's own protocol. Interfaces Identifiers must be unique within the domain of their ASP, = so V5UA cannot run alongside RFC3057 interfaces, and hence must run a = separate ASP. Because there is a 1:1 mapping between an ASP and SCTP association, = V5UA requires a different SCTP port number. There is probably many other reasons more fundamental than this... As for the SCTP PPID, the only use I have ever seen for this is in = tools such as ethereal - it maybe useful to operator to see the = QPTM/DPTM data split... Hope this helps, Mike -------------------------------------------------------------------------= ----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On = Behalf Of Sergey Mikhailov Sent: 24 January 2006 07:05 To: SIGTRAN Subject: [Sigtran] DUA and V5UA Hi, I have a question on terminology. DUA (RFC 4129) is considered just as extensions to IUA protocol (even = when having its own SCTP Payload protocol ID, no different port number, = and some differences from IUA, e.g. in DLCI field format in message = header), while V5UA (RFC 3807) is considered a protocol. Both RFCs say = that the respective UA "... builds on top of IUA, defining the necessary = extensions to IUA for a ... implementation." Is there a valid reason for such differentiation between "extensions = to the protocol" and "protocol" in this particular case of DUA and V5UA? Regards, Sergey Mikhailov. ------=_NextPart_000_007D_01C620FA.8A6ADD90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you for the explanation, = Mike.
 
Best regards,
Sergey Mikhailov.
 
 
----- Original Message -----
From:=20 Michael = Mentz=20
To: Sergey Mikhailov ; SIGTRAN =
Sent: Tuesday, January 24, 2006 = 2:56=20 PM
Subject: RE: [Sigtran] DUA and = V5UA

Hi Sergey,
 
This is a common question when first looking = at the two=20 specifications
 
In essence, the DUA 'extension' should be = considered as=20 actually being part of RFC3057 - ie, RFC3057+DUA=20 Extension.
 
All the DUA extension does is introduce some = extra=20 messaging and handling in order for the RFC3057 ASP to also = support DPNSS=20 interfaces.
This follows with the real world use of=20 DPNSS/DASS2, alongside PRI - most vendors offer PRI and = DPNSS/DASS2=20 interfaces on their box - hence the spec takes this into=20 account.
 
Therefore, your RFC3057 ASP has interface = identifiers=20 that either use QPTM messaging for PRI/BRI/QSIG, or DPTM messaging for = DPNSS/DASS2.
 
 
For V5UA, the differences are far more = fundamental - for=20 one, V5UA uses a different Interface ID format, no doubt this is one = of the=20 primary reasons why it is split into it's own = protocol.
Interfaces Identifiers must be unique within = the domain=20 of their ASP, so V5UA cannot run alongside RFC3057 interfaces, and = hence must=20 run a separate ASP.
Because there is a 1:1 mapping between an ASP = and SCTP=20 association, V5UA requires a different SCTP port = number.
There is probably many other reasons more = fundamental=20 than this...
 
 
As for the SCTP PPID, the only use I have = ever seen for=20 this is in tools such as ethereal - it maybe useful to operator to see = the=20 QPTM/DPTM data split...
 
Hope this helps,
 
Mike
From: sigtran-bounces@ietf.org=20 [mailto:sigtran-bounces@ietf.org] On Behalf Of Sergey=20 Mikhailov
Sent: 24 January 2006 07:05
To:=20 SIGTRAN
Subject: [Sigtran] DUA and V5UA

Hi,
 
I have a question on = terminology.
 
DUA (RFC 4129) is considered just as = extensions=20 to IUA protocol (even when having its own SCTP Payload protocol ID, no = different port number, and some differences from IUA, e.g. in = DLCI field=20 format in message header), while V5UA (RFC 3807) is considered a = protocol.=20 Both RFCs say that the respective UA "... builds on top of IUA, = defining=20 the necessary extensions to IUA for a ... = implementation."
 
Is there a valid reason for such = differentiation=20 between "extensions to the protocol" and "protocol" in this particular = case of=20 DUA and V5UA?
 
 
Regards,
Sergey=20 Mikhailov.
------=_NextPart_000_007D_01C620FA.8A6ADD90-- --===============1174040270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1174040270==-- From sigtran-bounces@ietf.org Wed Jan 25 05:08:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1haE-0002rM-LQ; Wed, 25 Jan 2006 05:08:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1haD-0002pD-2y for sigtran@megatron.ietf.org; Wed, 25 Jan 2006 05:08:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27664 for ; Wed, 25 Jan 2006 05:07:24 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[dgzzhYb/VTW8OhGJu336dSs2juTI1S68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1hjt-0002CE-7f for sigtran@ietf.org; Wed, 25 Jan 2006 05:19:00 -0500 Received: from ns.pigworks.openss7.net (IDENT:p/P+x61/BfmC0QRN9ToUtQkgTMkoi26T@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0PA8cw22639; Wed, 25 Jan 2006 03:08:38 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0PA8bO15568; Wed, 25 Jan 2006 03:08:37 -0700 Date: Wed, 25 Jan 2006 03:08:37 -0700 From: "Brian F. G. Bidulock" To: Amit Ray Message-ID: <20060125030837.B12189@openss7.org> Mail-Followup-To: Amit Ray , sigtran@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from amit.ray@flextronicssoftware.com on Wed, Jan 25, 2006 at 10:27:48AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sigtran@ietf.org Subject: [Sigtran] Re: Query Regarding Alignment Message In M2PA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Amit, Amit Ray wrote: (Wed, 25 Jan 2006 10:27:48) > > > > > > Hi Brian, > I require some clarification regarding the Alignment > message in M2PA. > After SCTP connection establishment, when M2PA user start the link, first > message that is sent is an alignment > message. After that the normal or emergency proving is started. If a ready > message is received instead of a > alignment message from the peer followed by proving messages, should M2PA > discard all the proving messages > or should it continue with proving messages ignoring the fact that it is > received a ready(or other ) message instead of > alignment message. > > > Rgds > Amit Ray > Senior Software Engineer > Flextronics Software System > Gurgaon > Contact: 9899044017 Please remove the following when posting to this list: --brian > > *********************** FSS-Unclassified *********************** > "DISCLAIMER: This message is proprietary to Flextronics Software > Systems Limited (FSS) and is intended solely for the use of the > individual to whom it is addressed. It may contain privileged or > confidential information and should not be circulated or used for > any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. > If you are not the intended recipient, you are notified that you are > strictly prohibited from using, copying, altering, or disclosing > the contents of this message. FSS accepts no responsibility for > loss or damage arising from the use of the information transmitted > by this email including damage from virus." -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 26 12:03:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2AXL-0001wZ-KR; Thu, 26 Jan 2006 12:03:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2AXK-0001wR-J1 for sigtran@megatron.ietf.org; Thu, 26 Jan 2006 12:03:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04795 for ; Thu, 26 Jan 2006 12:02:21 -0500 (EST) Received: from smtp03.tekelec.com ([198.89.42.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2AhH-0004K6-2U for sigtran@ietf.org; Thu, 26 Jan 2006 12:14:14 -0500 Received: from dcex04.tekelec.com (dcex04.tekelec.com [172.28.104.64]) by smtp03.tekelec.com (8.12.10/8.12.10) with ESMTP id k0QH0Yju008733 for ; Thu, 26 Jan 2006 11:00:34 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex04.tekelec.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 11:03:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jan 2006 11:03:41 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E71702862D48@DCEVS2.tekelec.com> Thread-Topic: (M2PA) Question about Busy Procedure Thread-Index: AcYimnUQ90la6Fx8QTGOdj8r2kkV/g== From: "Craig, Jeffrey" To: X-OriginalArrivalTime: 26 Jan 2006 17:03:41.0734 (UTC) FILETIME=[7571D460:01C6229A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Subject: [Sigtran] (M2PA) Question about Busy Procedure X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello All, RFC4165 implies that M2PA should mark remote congestion condition and stop transmitting non-empty user data messages upon reception of LS Busy, whether or not its RTB contains a message (timer T7 is running).=20 Shouldn't the ANSI variant M2PA behave like T1.111.3 (Figure 13, sheet 4) MTP2 and ignore received LS Busy (SIB) when its RTB is empty? If not, and M2PA marks remote congestion condition when RTB is empty and does not start T6, how long, in the absence of received LS Busy Ended, should it continue to buffer MSUs received from MTP3 for transmission? RFC4165 states that M2PA must not acknowledge a received user data message that triggers (implementation-dependent) local congestion onset. Is this requirement intended to force the RTB of the peer to always be non-empty upon reception of LS Busy? Regards, Jeff =20 =20 =20 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 26 13:02:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BS6-0001Vn-RR; Thu, 26 Jan 2006 13:02:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BS1-0001Og-Ct for sigtran@megatron.ietf.org; Thu, 26 Jan 2006 13:02:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10453 for ; Thu, 26 Jan 2006 13:00:56 -0500 (EST) Received: from web35404.mail.mud.yahoo.com ([66.163.179.113]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2Bbz-000824-1f for sigtran@ietf.org; Thu, 26 Jan 2006 13:12:49 -0500 Received: (qmail 21531 invoked by uid 60001); 26 Jan 2006 18:02:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mQrAmhoLsMRBIXuOjFYetZs/LcYyg4Wgre2TBACc13Nfo1gvRnH977svh4+JOQ/KS/adBRUL8jifMdOUFkylTgO1jsRiPkxvqtPCpYx0L4MyF1wcO4Xvxp2N9ATUaow+vrHKhITuI0giyjraEadl5rXKCPYh60BwD+9glcWOYL4= ; Message-ID: <20060126180217.21529.qmail@web35404.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35404.mail.mud.yahoo.com via HTTP; Thu, 26 Jan 2006 10:02:17 PST Date: Thu, 26 Jan 2006 10:02:17 -0800 (PST) From: Stanislav Ivanovich To: SIGTRAN MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Sigtran] Can SUA Layer encapsulate MTP L3 layer/functionality? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0242936093==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0242936093== Content-Type: multipart/alternative; boundary="0-1009295881-1138298537=:13276" Content-Transfer-Encoding: 8bit --0-1009295881-1138298537=:13276 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello SIGTRAN community, The reason why I am writing this is because I have recently found very contradictory statements in this forum which seem to collide with relevant specifications. So I would like to hear some comments. There is no doubt that there is a very sharp distinction between M3UA and SUA. M3UA is real adaptation/coordination function which does not contain any MTP functionality but like all the other adaptation/coordination functions just provides access to functions provided in a substitute component. Thus for example in case of ITU-T SAAL one can find MTP-alike functions in ATM layer, SSCOP (retransmission etc...) so he/she just needs a coordination function in SSCF (Q.2140) which does not contain real functionality but only coordinates (maps) services expected from user to corresponding services in the new component which replaces the old ones. So like in this ITU-T example M3UA also does not essentially contain any MTP functions (that's is why it is called adaptation layer) but provides access to MTP-alike functions in new components which replace MTP. Thus one can find functionality similar to MTP L3 relay in IP layer or data error detection and correction functions of MTP L2 in SCTP. So M3UA just provides access for MTP-users to MTP-alike functions in new component (SCTP+IP+Physical layer) which replaces MTP layer. M3UA essentially behaves as SSCF of SAAL by coordinating access to MTP alike functions in the substitute component. However this SUA thing is really not adaptation layer of this kind. Does SIGTRAN provide us with substitute for GT, CL, CO... functions of SCCP? NO! Can one find GT alike function in IP or SCTP? NO! So what does SUA adapt? It is therefore clear that SUA "adaptation" layer must contain SCCP functions. However the question is should it contain MTP functions? E.g. MTP3 relay? Looking into SUA RFC it looks like that SUA layer cannot support MTP3 relay. (e.g. sec. 3.4.1. DUNA is sent only as N-STATE or N-PC-STATE indications, and many other similar references...). I have also recently heard from people here at the SIGTRAN forum that MTP3 relay does not make sense since we have corresponding function in IP relay... (when we spoke about SGP-SGP protocol which is being developed for M3UA to enable it to contain and use MTP3 relay functions). If MTP3 functions do not make sense within M3UA how can they make sense for SUA? thanks for the comments! kind regards/ Stanislav Ivanovich --------------------------------- Do you Yahoo!? With a free 1 GB, there's more in store with Yahoo! Mail. --0-1009295881-1138298537=:13276 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello SIGTRAN community,
 
The reason why I am writing this is because I have recently found very contradictory statements in this forum which seem to collide with relevant specifications. So I would like to hear some comments.
 
 
There is no doubt that there is a very sharp distinction between M3UA and SUA.
 
M3UA is real adaptation/coordination function which does not contain any MTP functionality but like all the other adaptation/coordination functions just provides access to functions provided in a substitute component.
 
Thus for example in case of ITU-T SAAL one can find MTP-alike functions in ATM layer, SSCOP (retransmission etc...) so he/she just needs a coordination function in SSCF (Q.2140) which does not contain real functionality but only coordinates (maps) services expected from user to corresponding servi! ces in the new component which replaces the old ones.
 
So like in this ITU-T example M3UA also does not essentially contain any MTP functions (that's is why it is called adaptation layer) but provides access to MTP-alike functions in new components which replace MTP. Thus one can find functionality similar to MTP L3 relay in IP layer or data error detection and correction functions of MTP L2 in SCTP. So M3UA just provides access for MTP-users to MTP-alike functions in new component (SCTP+IP+Physical layer) which replaces MTP layer. M3UA essentially behaves as SSCF of SAAL by coordinating access to MTP alike functions in the substitute component.
 
 
 
However this SUA thing is really not adaptation layer of this kind. Does SIGTRAN provide us with substitute for GT, CL, CO... functions of SCCP? NO!
Can one find GT alike function in IP or SCTP? NO!
 
! So what does SUA adapt?
 
It is therefore clear that SUA "adaptation" layer must contain SCCP functions.
 
However the question is should it contain MTP functions? E.g. MTP3 relay?
 
Looking into SUA RFC it looks like that SUA layer cannot support MTP3 relay. (e.g. sec. 3.4.1. DUNA is sent only as N-STATE or N-PC-STATE indications, and many other similar references...).
 
I have also recently heard from people here at the SIGTRAN forum that MTP3 relay does not make sense since we have corresponding function in IP relay... (when we spoke about SGP-SGP protocol which is being developed for M3UA to enable it to contain and use MTP3 relay functions).
 
If MTP3 functions do not make sense within M3UA how can they make sense for SUA?
 
thanks for the comments!
 
kind r! egards/ Stanislav Ivanovich
 

Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo! Mail. --0-1009295881-1138298537=:13276-- --===============0242936093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0242936093==-- From sigtran-bounces@ietf.org Thu Jan 26 13:11:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Baz-0008Br-Pw; Thu, 26 Jan 2006 13:11:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Baq-00089p-6C for sigtran@megatron.ietf.org; Thu, 26 Jan 2006 13:11:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11343 for ; Thu, 26 Jan 2006 13:10:04 -0500 (EST) Received: from web35410.mail.mud.yahoo.com ([66.163.179.119]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2Bkq-0008Oh-3d for sigtran@ietf.org; Thu, 26 Jan 2006 13:21:56 -0500 Received: (qmail 72796 invoked by uid 60001); 26 Jan 2006 18:11:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=baH2XFvLPLNw9pKwAx7mUPoLOdRONYwV+Ce8LHV1QvebBD0Tuuray7vrfo7clIdlUOIIqKGTCqHGm09rtq0/IVhrl1d1xcRAKh88NGW2GpyaWrmuFDZ4Zb4mnUwmzc4Tp8nLPnSzp/2ESfQZQwxtbAqDPI3MMkhe+aM5Q3jpI0c= ; Message-ID: <20060126181126.72794.qmail@web35410.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35410.mail.mud.yahoo.com via HTTP; Thu, 26 Jan 2006 10:11:26 PST Date: Thu, 26 Jan 2006 10:11:26 -0800 (PST) From: Stanislav Ivanovich To: SIGTRAN MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Sigtran] Re: Can SUA Layer encapsulate MTP L3 layer/functionality? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1195222471==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1195222471== Content-Type: multipart/alternative; boundary="0-1682464887-1138299086=:72503" Content-Transfer-Encoding: 8bit --0-1682464887-1138299086=:72503 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In addition to the last mail I want to add that it seems that SUA RFC provides SCCP alike relay (GT) since this relay is not managed by management messages thus no need for DUNA, DAVA messages what makes SUA RFC complkiant with the idea of having only SCCP relay in SUA. / Stanislav Ivanovich Stanislav Ivanovich wrote: Hello SIGTRAN community, The reason why I am writing this is because I have recently found very contradictory statements in this forum which seem to collide with relevant specifications. So I would like to hear some comments. There is no doubt that there is a very sharp distinction between M3UA and SUA. M3UA is real adaptation/coordination function which does not contain any MTP functionality but like all the other adaptation/coordination functions just provides access to functions provided in a substitute component. Thus for example in case of ITU-T SAAL one can find MTP-alike functions in ATM layer, SSCOP (retransmission etc...) so he/she just needs a coordination function in SSCF (Q.2140) which does not contain real functionality but only coordinates (maps) services expected from user to corresponding services in the new component which replaces the old ones. So like in this ITU-T example M3UA also does not essentially contain any MTP functions (that's is why it is called adaptation layer) but provides access to MTP-alike functions in new components which replace MTP. Thus one can find functionality similar to MTP L3 relay in IP layer or data error detection and correction functions of MTP L2 in SCTP. So M3UA just provides access for MTP-users to MTP-alike functions in new component (SCTP+IP+Physical layer) which replaces MTP layer. M3UA essentially behaves as SSCF of SAAL by coordinating access to MTP alike functions in the substitute component. However this SUA thing is really not adaptation layer of this kind. Does SIGTRAN provide us with substitute for GT, CL, CO... functions of SCCP? NO! Can one find GT alike function in IP or SCTP? NO! So what does SUA adapt? It is therefore clear that SUA "adaptation" layer must contain SCCP functions. However the question is should it contain MTP functions? E.g. MTP3 relay? Looking into SUA RFC it looks like that SUA layer cannot support MTP3 relay. (e.g. sec. 3.4.1. DUNA is sent only as N-STATE or N-PC-STATE indications, and many other similar references...). I have also recently heard from people here at the SIGTRAN forum that MTP3 relay does not make sense since we have corresponding function in IP relay... (when we spoke about SGP-SGP protocol which is being developed for M3UA to enable it to contain and use MTP3 relay functions). If MTP3 functions do not make sense within M3UA how can they make sense for SUA? thanks for the comments! kind regards/ Stanislav Ivanovich --------------------------------- Do you Yahoo!? With a free 1 GB, there's more in store with Yahoo! Mail. --------------------------------- Bring words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail. --0-1682464887-1138299086=:72503 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
In addition to the last mail I want to add that it seems that SUA RFC provides SCCP alike relay (GT) since this relay is not managed by management messages thus no need for DUNA, DAVA messages what makes SUA RFC complkiant with the idea of having only SCCP relay in SUA.
 
/ Stanislav Ivanovich


Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
Hello SIGTRAN community,
 
The reason why I am writing this is because I have recently found very contradictory statements in this forum which seem to collide with relevant specifications. So I would like to hear some comments.
 
 
There is no doubt that there is a very sharp distinction between M3UA and SUA.
 
M3UA is r! eal adaptation/coordination function which does not contain any MTP functionality but like all the other adaptation/coordination functions just provides access to functions provided in a substitute component.
 
Thus for example in case of ITU-T SAAL one can find MTP-alike functions in ATM layer, SSCOP (retransmission etc...) so he/she just needs a coordination function in SSCF (Q.2140) which does not contain real functionality but only coordinates (maps) services expected from user to corresponding services in the new component which replaces the old ones.
 
So like in this ITU-T example M3UA also does not essentially contain any MTP functions (that's is why it is called adaptation layer) but provides access to MTP-alike functions in new components which replace MTP. Thus one can find functionality similar to MTP L3 relay in IP layer or data error detection and correction functions of MTP L2 in SCTP. So M3UA just pr! ovides access for MTP-users to MTP-alike functions in new component (SCTP+IP+Physical layer) which replaces MTP layer. M3UA essentially behaves as SSCF of SAAL by coordinating access to MTP alike functions in the substitute component.
 
 
 
However this SUA thing is really not adaptation layer of this kind. Does SIGTRAN provide us with substitute for GT, CL, CO... functions of SCCP? NO!
Can one find GT alike function in IP or SCTP? NO!
 
So what does SUA adapt?
 
It is therefore clear that SUA "adaptation" layer must contain SCCP functions.
 
However the question is should it contain MTP functions? E.g. MTP3 relay?
 
Looking into SUA RFC it looks like that SUA layer cannot support MTP3 relay. (e.g. sec. 3.4.1. DUNA is sent only as N-STATE or N-PC-STATE indications, and many other similar references...).
 
I have also recently heard from people here at the SIGTRAN forum that MTP3 relay does not make sense since we have corresponding function in IP relay... (when we spoke about SGP-SGP protocol which is being developed for M3UA to enable it to contain and use MTP3 relay functions).
 
If MTP3 functions do not make sense within M3UA how can they make sense for SUA?
 
thanks for the comments!
 
kind regards/ Stanislav Ivanovich
 
Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo! Mail.

Bring words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail. --0-1682464887-1138299086=:72503-- --===============1195222471== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1195222471==-- From sigtran-bounces@ietf.org Thu Jan 26 13:25:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Bob-000454-OA; Thu, 26 Jan 2006 13:25:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BoY-00043L-1P for sigtran@megatron.ietf.org; Thu, 26 Jan 2006 13:25:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12288 for ; Thu, 26 Jan 2006 13:24:14 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[ZVbRfdyFp1JLlBbh/LPTk6J4sIt7EVtw]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2ByY-0000P6-6b for sigtran@ietf.org; Thu, 26 Jan 2006 13:36:06 -0500 Received: from ns.pigworks.openss7.net (IDENT:oUtpoz9GFxRgqwDxJrRVpQp4+iYWNv0z@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0QIPWj20161; Thu, 26 Jan 2006 11:25:32 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0QIPWV01591; Thu, 26 Jan 2006 11:25:32 -0700 Date: Thu, 26 Jan 2006 11:25:32 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Re: Can SUA Layer encapsulate MTP L3 layer/functionality? Message-ID: <20060126112532.A1476@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060126181126.72794.qmail@web35410.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060126181126.72794.qmail@web35410.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Thu, Jan 26, 2006 at 10:11:26AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Adaptation modules are defined as in RFC 2719 Section 3.1, and *NOT* ATM SAAL specifications. --brian Stanislav Ivanovich wrote: (Thu, 26 Jan 2006 10:11:26) > > In addition to the last mail I want to add that it seems that SUA RFC > provides SCCP alike relay (GT) since this relay is not managed by > management messages thus no need for DUNA, DAVA messages what makes > SUA RFC complkiant with the idea of having only SCCP relay in SUA. > > > > / Stanislav Ivanovich > > Stanislav Ivanovich wrote: > > Hello SIGTRAN community, > > > > The reason why I am writing this is because I have recently found very > contradictory statements in this forum which seem to collide with > relevant specifications. So I would like to hear some comments. > > > > > > There is no doubt that there is a very sharp distinction between M3UA > and SUA. > > > > M3UA is r! eal adaptation/coordination function which does not contain > any MTP functionality but like all the other adaptation/coordination > functions just provides access to functions provided in a substitute > component. > > > > Thus for example in case of ITU-T SAAL one can find MTP-alike > functions in ATM layer, SSCOP (retransmission etc...) so he/she just > needs a coordination function in SSCF (Q.2140) which does not contain > real functionality but only coordinates (maps) services expected from > user to corresponding services in the new component which replaces the > old ones. > > > > So like in this ITU-T example M3UA also does not essentially contain > any MTP functions (that's is why it is called adaptation layer) but > provides access to MTP-alike functions in new components which replace > MTP. Thus one can find functionality similar to MTP L3 relay in IP > layer or data error detection and correction functions of MTP L2 in > SCTP. So M3UA just pr! ovides access for MTP-users to MTP-alike > functions in new component (SCTP+IP+Physical layer) which replaces MTP > layer. M3UA essentially behaves as SSCF of SAAL by coordinating access > to MTP alike functions in the substitute component. > > > > > > > > However this SUA thing is really not adaptation layer of this kind. > Does SIGTRAN provide us with substitute for GT, CL, CO... functions of > SCCP? NO! > > Can one find GT alike function in IP or SCTP? NO! > > > > So what does SUA adapt? > > > > It is therefore clear that SUA "adaptation" layer must contain SCCP > functions. > > > > However the question is should it contain MTP functions? E.g. MTP3 > relay? > > > > Looking into SUA RFC it looks like that SUA layer cannot support MTP3 > relay. (e.g. sec. 3.4.1. DUNA is sent only as N-STATE or N-PC-STATE > indications, and many other similar references...). > > > > I have also recently heard from people here at the SIGTRAN forum that > MTP3 relay does not make sense since we have corresponding function in > IP relay... (when we spoke about SGP-SGP protocol which is being > developed for M3UA to enable it to contain and use MTP3 relay > functions). > > > > If MTP3 functions do not make sense within M3UA how can they make > sense for SUA? > > > > thanks for the comments! > > > > kind regards/ Stanislav Ivanovich > > > _________________________________________________________________ > > Do you Yahoo!? > With a free 1 GB, there's more in store with [1]Yahoo! Mail. > _________________________________________________________________ > > Bring words and photos together (easily) with > [2]PhotoMail - it's free and works with Yahoo! Mail. > > References > > 1. http://us.rd.yahoo.com/mail_us/taglines/mailstorage/*http://mail.yahoo.com/ > 2. http://us.rd.yahoo.com/mail_us/taglines/PMHM3/*http://photomail.mail.yahoo.com > _______________________________________________ > 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 From sigtran-bounces@ietf.org Thu Jan 26 13:48:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CAZ-00066x-76; Thu, 26 Jan 2006 13:48:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CAW-00066G-Um for sigtran@megatron.ietf.org; Thu, 26 Jan 2006 13:48:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14875 for ; Thu, 26 Jan 2006 13:46:57 -0500 (EST) Received: from web35411.mail.mud.yahoo.com ([66.163.179.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2CKV-0001Nb-5W for sigtran@ietf.org; Thu, 26 Jan 2006 13:58:49 -0500 Received: (qmail 91527 invoked by uid 60001); 26 Jan 2006 18:48:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PzDCNaPk15sdrUsQMCRALqWT22LupnTl024r79z1kD4+QxMOsF9VRf/FeUWDdXBtmLFOigGQSIn1XfbEQ5oQzpXQZX6tAIrDyJlOnYwa6h/5bnxKmOYF9h9Tb/ipnjFYlWrlucqxLvS1gNWmH5kl2YBV7RfbQdHzzESRoCv4p50= ; Message-ID: <20060126184817.91525.qmail@web35411.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35411.mail.mud.yahoo.com via HTTP; Thu, 26 Jan 2006 10:48:17 PST Date: Thu, 26 Jan 2006 10:48:17 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Re: Can SUA Layer encapsulate MTP L3 layer/functionality? To: SIGTRAN In-Reply-To: <20060126112532.A1476@openss7.org> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1077652910==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1077652910== Content-Type: multipart/alternative; boundary="0-1867445193-1138301297=:91118" Content-Transfer-Encoding: 8bit --0-1867445193-1138301297=:91118 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Brian, and other SIGTRAN community memebers, I have read that RFC many years ago and do understand it quite well. I think you haven't understand my point with SAAL specifications which I used just as a refference to show what I mean. Could you please answer this very simple question in very simple way (with YES or NO), which I copy/paste from my previous mail. "It is clear that SUA adaptation layer must contain SCCP functions. However the question is can SUA layer contain MTP functions? E.g. MTP3 relay?" If YES how is the MTP3 functionality supported by SUA protocol if I read: SUA RFC: sec. 3.4.1. DUNA is meant to replace N-STATE and N-PCSTATE indications... / Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Adaptation modules are defined as in RFC 2719 Section 3.1, and *NOT* ATM SAAL specifications. --brian Stanislav Ivanovich wrote: (Thu, 26 Jan 2006 10:11:26) > > In addition to the last mail I want to add that it seems that SUA RFC > provides SCCP alike relay (GT) since this relay is not managed by > management messages thus no need for DUNA, DAVA messages what makes > SUA RFC complkiant with the idea of having only SCCP relay in SUA. > > > > / Stanislav Ivanovich > > Stanislav Ivanovich wrote: > > Hello SIGTRAN community, > > > > The reason why I am writing this is because I have recently found very > contradictory statements in this forum which seem to collide with > relevant specifications. So I would like to hear some comments. > > > > > > There is no doubt that there is a very sharp distinction between M3UA > and SUA. > > > > M3UA is r! eal adaptation/coordination function which does not contain > any MTP functionality but like all the other adaptation/coordination > functions just provides access to functions provided in a substitute > component. > > > > Thus for example in case of ITU-T SAAL one can find MTP-alike > functions in ATM layer, SSCOP (retransmission etc...) so he/she just > needs a coordination function in SSCF (Q.2140) which does not contain > real functionality but only coordinates (maps) services expected from > user to corresponding services in the new component which replaces the > old ones. > > > > So like in this ITU-T example M3UA also does not essentially contain > any MTP functions (that's is why it is called adaptation layer) but > provides access to MTP-alike functions in new components which replace > MTP. Thus one can find functionality similar to MTP L3 relay in IP > layer or data error detection and correction functions of MTP L2 in > SCTP. So M3UA just pr! ovides access for MTP-users to MTP-alike > functions in new component (SCTP+IP+Physical layer) which replaces MTP > layer. M3UA essentially behaves as SSCF of SAAL by coordinating access > to MTP alike functions in the substitute component. > > > > > > > > However this SUA thing is really not adaptation layer of this kind. > Does SIGTRAN provide us with substitute for GT, CL, CO... functions of > SCCP? NO! > > Can one find GT alike function in IP or SCTP? NO! > > > > So what does SUA adapt? > > > > It is therefore clear that SUA "adaptation" layer must contain SCCP > functions. > > > > However the question is should it contain MTP functions? E.g. MTP3 > relay? > > > > Looking into SUA RFC it looks like that SUA layer cannot support MTP3 > relay. (e.g. sec. 3.4.1. DUNA is sent only as N-STATE or N-PC-STATE > indications, and many other similar references...). > > > > I have also recently heard from people here at the SIGTRAN forum that > MTP3 relay does not make sense since we have corresponding function in > IP relay... (when we spoke about SGP-SGP protocol which is being > developed for M3UA to enable it to contain and use MTP3 relay > functions). > > > > If MTP3 functions do not make sense within M3UA how can they make > sense for SUA? > > > > thanks for the comments! > > > > kind regards/ Stanislav Ivanovich > > > _________________________________________________________________ > > Do you Yahoo!? > With a free 1 GB, there's more in store with [1]Yahoo! Mail. > _________________________________________________________________ > > Bring words and photos together (easily) with > [2]PhotoMail - it's free and works with Yahoo! Mail. > > References > > 1. http://us.rd.yahoo.com/mail_us/taglines/mailstorage/*http://mail.yahoo.com/ > 2. http://us.rd.yahoo.com/mail_us/taglines/PMHM3/*http://photomail.mail.yahoo.com > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --------------------------------- Do you Yahoo!? With a free 1 GB, there's more in store with Yahoo! Mail. --0-1867445193-1138301297=:91118 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Brian, and other SIGTRAN community memebers,
 
I have read that RFC many years ago and do understand it quite well. I think you haven't understand my point with SAAL specifications which I used just as a refference to show what I mean.
 
Could you please answer this very simple question in very simple way (with YES or NO), which I copy/paste from my previous mail.
 
"It is clear that SUA adaptation layer must contain SCCP functions. However the question is can SUA layer contain MTP functions? E.g. MTP3 relay?"
If YES how is the MTP3 functionality supported by SUA protocol if I read:
 
SUA RFC: sec. 3.4.1. DUNA is meant to replace N-STATE and N-PCSTATE indications...
 
/ Stanislav Ivanovich
 


"Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
Stanislav,

Adaptation modules are defined as in RFC 2719 Section 3.1, and
*NOT* ATM SAAL specifications.

--brian

Stanislav Ivanovich wrote: (Thu, 26 Jan 2006 10:11:26)
>
> In addition to the last mail I want to add that it seems that SUA RFC
> provides SCCP alike relay (GT) since this relay is not managed by
> management messages thus no need for DUNA, DAVA messages what makes
> SUA RFC complkiant with the idea of having only SCCP relay in SUA.
>
>
>
> / Stanislav Ivanovich
>
> Stanislav Ivanovich wrote:
>
> Hello SIGTRAN community,
>
>
>
> The reason why I am writing this is because I have recently found very
> contradictory statements in this forum which! seem to collide with
> relevant specifications. So I would like to hear some comments.
>
>
>
>
>
> There is no doubt that there is a very sharp distinction between M3UA
> and SUA.
>
>
>
> M3UA is r! eal adaptation/coordination function which does not contain
> any MTP functionality but like all the other adaptation/coordination
> functions just provides access to functions provided in a substitute
> component.
>
>
>
> Thus for example in case of ITU-T SAAL one can find MTP-alike
> functions in ATM layer, SSCOP (retransmission etc...) so he/she just
> needs a coordination function in SSCF (Q.2140) which does not contain
> real functionality but only coordinates (maps) services expected from
> user to corresponding services in the new component which replaces the
> old ones.
>
>
>
> So like in this ITU-T ! example M3UA also does not essentially contain
> any MTP functions (that's is why it is called adaptation layer) but
> provides access to MTP-alike functions in new components which replace
> MTP. Thus one can find functionality similar to MTP L3 relay in IP
> layer or data error detection and correction functions of MTP L2 in
> SCTP. So M3UA just pr! ovides access for MTP-users to MTP-alike
> functions in new component (SCTP+IP+Physical layer) which replaces MTP
> layer. M3UA essentially behaves as SSCF of SAAL by coordinating access
> to MTP alike functions in the substitute component.
>
>
>
>
>
>
>
> However this SUA thing is really not adaptation layer of this kind.
> Does SIGTRAN provide us with substitute for GT, CL, CO... functions of
> SCCP? NO!
>
> Can one find GT alike function in IP or SCTP? NO!
>
>
>
> So what does SUA adapt?
>
>
>
> It is therefore clear that SUA "adaptation" layer must contain SCCP
> functions.
>
>
>
> However the question is should it contain MTP functions? E.g. MTP3
> relay?
>
>
>
> Looking into SUA RFC it looks like that SUA layer cannot support MTP3
> relay. (e.g. sec. 3.4.1. DUNA is sent only as N-STATE or N-PC-STATE
> indications, and many other similar references...).
>
>
>
> I have also recently heard from people here at the SIGTRAN forum that
> MTP3 relay does not make sense since we have corresponding function in
> IP relay... (when we spoke about SGP-SGP protocol which is being
> developed for M3UA to enable it to contain and use MTP3 relay
> functions).
>
>
>
> If MTP3 functions do not make sense within M3UA how can they make
> sense for SUA?
>
>
>
! > thanks for the comments!
>
>
>
> kind regards/ Stanislav Ivanovich
>
>
> _________________________________________________________________
>
> Do you Yahoo!?
> With a free 1 GB, there's more in store with [1]Yahoo! Mail.
> _________________________________________________________________
>
> Bring words and photos together (easily) with
> [2]PhotoMail - it's free and works with Yahoo! Mail.
>
> References
>
> 1. http://us.rd.yahoo.com/mail_us/taglines/mailstorage/*http://mail.yahoo.com/
> 2. http://us.rd.yahoo.com/mail_us/taglines/PMHM3/*http://photomail.mail.yahoo.com

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


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

Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo! Mail. --0-1867445193-1138301297=:91118-- --===============1077652910== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1077652910==-- From sigtran-bounces@ietf.org Thu Jan 26 14:38:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Cwc-0001X7-6f; Thu, 26 Jan 2006 14:38:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Cwa-0001SN-5z for sigtran@megatron.ietf.org; Thu, 26 Jan 2006 14:38:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19133 for ; Thu, 26 Jan 2006 14:36:36 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[D/gtENbnt25DphM9Oik9kfMlYt7jz4Nr]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2D6Z-0003Gp-Uy for sigtran@ietf.org; Thu, 26 Jan 2006 14:48:29 -0500 Received: from ns.pigworks.openss7.net (IDENT:h5cYbZ4J58swDLbUMYvq0a30E4F969qb@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0QJc4j21329; Thu, 26 Jan 2006 12:38:04 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0QJc4w02155; Thu, 26 Jan 2006 12:38:04 -0700 Date: Thu, 26 Jan 2006 12:38:04 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Re: Can SUA Layer encapsulate MTP L3 layer/functionality? Message-ID: <20060126123804.A2140@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060126112532.A1476@openss7.org> <20060126184817.91525.qmail@web35411.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060126184817.91525.qmail@web35411.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Thu, Jan 26, 2006 at 10:48:17AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, Stanislav Ivanovich wrote: (Thu, 26 Jan 2006 10:48:17) > > Brian, and other SIGTRAN community memebers, > > > > I have read that RFC many years ago and do understand it quite well. I > think you haven't understand my point with SAAL specifications which I > used just as a refference to show what I mean. > > > > Could you please answer this very simple question in very simple way > (with YES or NO), which I copy/paste from my previous mail. Well, no, I cannot: because your question proceeds from a false premise. SUA does not have to contain SCCP functions. Also, M3UA may contain MTP3 functions. --brian > > > > "It is clear that SUA adaptation layer must contain SCCP functions. > However the question is can SUA layer contain MTP functions? E.g. MTP3 > relay?" > > If YES how is the MTP3 functionality supported by SUA protocol if I > read: > > > > SUA RFC: sec. 3.4.1. DUNA is meant to replace N-STATE and > N-PCSTATE indications... > > > > / Stanislav Ivanovich > > > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Jan 26 14:53:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DBC-0006z5-TR; Thu, 26 Jan 2006 14:53:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DBA-0006xR-7G for sigtran@megatron.ietf.org; Thu, 26 Jan 2006 14:53:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20040 for ; Thu, 26 Jan 2006 14:51:39 -0500 (EST) Received: from web35401.mail.mud.yahoo.com ([66.163.179.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2DL9-0003h0-64 for sigtran@ietf.org; Thu, 26 Jan 2006 15:03:33 -0500 Received: (qmail 75358 invoked by uid 60001); 26 Jan 2006 19:53:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y16fHhBNr+iQ8yGopnjbnO3QHNkBu4M8h1i8Sl7aHu0cq+JISqcHfsiAH7Z4wOKMlhrKUgkBIN1AxiFWdG0gvFEDiXHG5jznottsLaB4Cghg4JsZajMX/Q14TY97UhaItu+0a8cztwzxx4s6Vpdp7fLj2XGAqadn4EYGHqte8RY= ; Message-ID: <20060126195300.75356.qmail@web35401.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35401.mail.mud.yahoo.com via HTTP; Thu, 26 Jan 2006 11:53:00 PST Date: Thu, 26 Jan 2006 11:53:00 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Re: Can SUA Layer encapsulate MTP L3 layer/functionality? To: SIGTRAN In-Reply-To: <20060126184817.91525.qmail@web35411.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1978154098==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1978154098== Content-Type: multipart/alternative; boundary="0-1607362589-1138305180=:73575" Content-Transfer-Encoding: 8bit --0-1607362589-1138305180=:73575 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In addition to the last mail I want to draw attention to very significant difference between "primitives" as used in RFC 2719 and messages of an peer-to-peer protocol. For example primitives of SCCP API are certainly not part of any peer-to-peer protocol but are exchanged between different type of entities (in this case SCCP and SCCP user). For this reason we have ASP-SGP protocol which models this kind of communication. However in xxUA specifications there are also peer-to-peer protocols (IPSP-IPSP in two flavors) and these protocols do not fit into the reference Brian pointed to! If one wants to talk about IPSP-IPSP or Relay or anything peer-to-peer then he must privude the functions needed! My very particular SUA question is related to these! SUA RFC talks about "relay" thing and there is no such thing in between SCCP and SCCP-user (i.e. ASP-SGP) but only between peer entities (SCCP-SCCP, MTPL3-MTPL3...) / Stanislav P.S: I do not have any problems with SGP-ASP in SUA! It is perfectly clear! Stanislav Ivanovich wrote: Brian, and other SIGTRAN community memebers, I have read that RFC many years ago and do understand it quite well. I think you haven't understand my point with SAAL specifications which I used just as a refference to show what I mean. Could you please answer this very simple question in very simple way (with YES or NO), which I copy/paste from my previous mail. "It is clear that SUA adaptation layer must contain SCCP functions. However the question is can SUA layer contain MTP functions? E.g. MTP3 relay?" If YES how is the MTP3 functionality supported by SUA protocol if I read: SUA RFC: sec. 3.4.1. DUNA is meant to replace N-STATE and N-PCSTATE indications... / Stanislav Ivanovich "Brian F. G. Bidulock" wrote: Stanislav, Adaptation modules are defined as in RFC 2719 Section 3.1, and *NOT* ATM SAAL specifications. --brian Stanislav Ivanovich wrote: (Thu, 26 Jan 2006 10:11:26) > > In addition to the last mail I want to add that it seems that SUA RFC > provides SCCP alike relay (GT) since this relay is not managed by > management messages thus no need for DUNA, DAVA messages what makes > SUA RFC complkiant with the idea of having only SCCP relay in SUA. > > > > / Stanislav Ivanovich > > Stanislav Ivanovich wrote: > > Hello SIGTRAN community, > > > > The reason why I am writing this is because I have recently found very > contradictory statements in this forum which! seem to collide with > relevant specifications. So I would like to hear some comments. > > > > > > There is no doubt that there is a very sharp distinction between M3UA > and SUA. > > > > M3UA is r! eal adaptation/coordination function which does not contain > any MTP functionality but like all the other adaptation/coordination > functions just provides access to functions provided in a substitute > component. > > > > Thus for example in case of ITU-T SAAL one can find MTP-alike > functions in ATM layer, SSCOP (retransmission etc...) so he/she just > needs a coordination function in SSCF (Q.2140) which does not contain > real functionality but only coordinates (maps) services expected from > user to corresponding services in the new component which replaces the > old ones. > > > > So like in this ITU-T ! example M3UA also does not essentially contain > any MTP functions (that's is why it is called adaptation layer) but > provides access to MTP-alike functions in new components which replace > MTP. Thus one can find functionality similar to MTP L3 relay in IP > layer or data error detection and correction functions of MTP L2 in > SCTP. So M3UA just pr! ovides access for MTP-users to MTP-alike > functions in new component (SCTP+IP+Physical layer) which replaces MTP > layer. M3UA essentially behaves as SSCF of SAAL by coordinating access > to MTP alike functions in the substitute component. > > > > > > > > However this SUA thing is really not adaptation layer of this kind. > Does SIGTRAN provide us with substitute for GT, CL, CO... functions of > SCCP? NO! > > Can one find GT alike function in IP or SCTP? NO! > > > > So what does SUA adapt? > > > > It is therefore clear that SUA "adaptation" layer must contain SCCP > functions. > > > > However the question is should it contain MTP functions? E.g. MTP3 > relay? > > > > Looking into SUA RFC it looks like that SUA layer cannot support MTP3 > relay. (e.g. sec. 3.4.1. DUNA is sent only as N-STATE or N-PC-STATE > indications, and many other similar references...). > > > > I have also recently heard from people here at the SIGTRAN forum that > MTP3 relay does not make sense since we have corresponding function in > IP relay... (when we spoke about SGP-SGP protocol which is being > developed for M3UA to enable it to contain and use MTP3 relay > functions). > > > > If MTP3 functions do not make sense within M3UA how can they make > sense for SUA? > > > ! > thanks for the comments! > > > > kind regards/ Stanislav Ivanovich > > > _________________________________________________________________ > > Do you Yahoo!? > With a free 1 GB, there's more in store with [1]Yahoo! Mail. > _________________________________________________________________ > > Bring words and photos together (easily) with > [2]PhotoMail - it's free and works with Yahoo! Mail. > > References > > 1. http://us.rd.yahoo.com/mail_us/taglines/mailstorage/*http://mail.yahoo.com/ > 2. http://us.rd.yahoo.com/mail_us/taglines/PMHM3/*http://photomail.mail.yahoo.com > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --------------------------------- Do you Yahoo!? With a free 1 GB, there's more in store with Yahoo! Mail._______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Bring words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail. --0-1607362589-1138305180=:73575 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
In addition to the last mail I want to draw attention to very significant difference between "primitives" as used in RFC 2719 and messages of an peer-to-peer protocol.
 
For example primitives of SCCP API are certainly not part of any peer-to-peer protocol but are exchanged between different type of entities (in this case SCCP and SCCP user). For this reason we have ASP-SGP protocol which models this kind of communication.
 
However in xxUA specifications there are also peer-to-peer protocols (IPSP-IPSP in two flavors) and these protocols do not fit into the reference Brian pointed to! If one wants to talk about IPSP-IPSP or Relay or anything peer-to-peer then he must privude the functions needed!
 
My very particular SUA question is related to these!
SUA RFC talks about "relay" thing and there is no such thing in between SCCP and SCCP-user (i.e. ASP-SGP) bu! t only between peer entities (SCCP-SCCP, MTPL3-MTPL3...)
 
/ Stanislav
 
P.S: I do not have any problems with SGP-ASP in SUA! It is perfectly clear!
 


Stanislav Ivanovich <stanislav_ivanovich@yahoo.com> wrote:
Brian, and other SIGTRAN community memebers,
 
I have read that RFC many years ago and do understand it quite well. I think you haven't understand my point with SAAL specifications which I used just as a refference to show what I mean.
 
Could you please answer this very simple question in very simple way (with YES or NO), which I copy/paste from my previous mail.
 
"It is clear that SUA adaptation layer must contain SCCP functions. However the question is&nb! sp;can SUA layer contain MTP functions? E.g. MTP3 relay?"
If YES how is the MTP3 functionality supported by SUA protocol if I read:
 
SUA RFC: sec. 3.4.1. DUNA is meant to replace N-STATE and N-PCSTATE indications...
 
/ Stanislav Ivanovich
 


"Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
Stanislav,

Adaptation modules are defined as in RFC 2719 Section 3.1, and
*NOT* ATM SAAL specifications.

--brian

Stanislav Ivanovich wrote: (Thu, 26 Jan 2006 10:11:26)
>
> In addition to the last mail I want to add that it seems that SUA RFC
> provides SCCP alike relay (GT) since this relay is not managed by
> management messages thus no need for DUNA, DAVA messages what makes
>! ; SUA RFC complkiant with the idea of having only SCCP relay in SUA.
>
>
>
> / Stanislav Ivanovich
>
> Stanislav Ivanovich wrote:
>
> Hello SIGTRAN community,
>
>
>
> The reason why I am writing this is because I have recently found very
> contradictory statements in this forum which! seem to collide with
> relevant specifications. So I would like to hear some comments.
>
>
>
>
>
> There is no doubt that there is a very sharp distinction between M3UA
> and SUA.
>
>
>
> M3UA is r! eal adaptation/coordination function which does not contain
> any MTP functionality but like all the other adaptation/coordination
> functions just provides access to functions provided in a substitute
> component.
>
>
>
> Thus for example in case of ITU-T SAAL one can f! ind MTP-alike
> functions in ATM layer, SSCOP (retransmission etc...) so he/she just
> needs a coordination function in SSCF (Q.2140) which does not contain
> real functionality but only coordinates (maps) services expected from
> user to corresponding services in the new component which replaces the
> old ones.
>
>
>
> So like in this ITU-T ! example M3UA also does not essentially contain
> any MTP functions (that's is why it is called adaptation layer) but
> provides access to MTP-alike functions in new components which replace
> MTP. Thus one can find functionality similar to MTP L3 relay in IP
> layer or data error detection and correction functions of MTP L2 in
> SCTP. So M3UA just pr! ovides access for MTP-users to MTP-alike
> functions in new component (SCTP+IP+Physical layer) which replaces MTP
> layer. M3UA essentially behaves as SSCF of SAAL by coordinating access
>! ; to MTP alike functions in the substitute component.
>
>
>
>
>
>
>
> However this SUA thing is really not adaptation layer of this kind.
> Does SIGTRAN provide us with substitute for GT, CL, CO... functions of
> SCCP? NO!
>
> Can one find GT alike function in IP or SCTP? NO!
>
>
>
> So what does SUA adapt?
>
>
>
> It is therefore clear that SUA "adaptation" layer must contain SCCP
> functions.
>
>
>
> However the question is should it contain MTP functions? E.g. MTP3
> relay?
>
>
>
> Looking into SUA RFC it looks like that SUA layer cannot support MTP3
> relay. (e.g. sec. 3.4.1. DUNA is sent only as N-STATE or N-PC-STATE
> indications, and many other similar references...).
>
>
>
> I have also recently heard from people here at the SIGTRAN forum that
> MTP3 relay does not make sense since we have corresponding function in
> IP relay... (when we spoke about SGP-SGP protocol which is being
> developed for M3UA to enable it to contain and use MTP3 relay
> functions).
>
>
>
> If MTP3 functions do not make sense within M3UA how can they make
> sense for SUA?
>
>
>
! > thanks for the comments!
>
>
>
> kind regards/ Stanislav Ivanovich
>
>
> _________________________________________________________________
>
> Do you Yahoo!?
> With a free 1 GB, there's more in store with [1]Yahoo! Mail.
> _________________________________________________________________
>
> Bring words and photos together (easily) with
> [2]PhotoMail - it's free and works with Yahoo! Mail.
>
> References
>
> 1. http://us.rd.yahoo.com/mail_us/taglines/mailstorage/*http://mail.yahoo.com/
> 2. http://us.rd.yahoo.com/mail_us/taglines/PMHM3/*http://photomail.mail.yahoo.com

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


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

Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo! Mail._______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Bring words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail. --0-1607362589-1138305180=:73575-- --===============1978154098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1978154098==-- From sigtran-bounces@ietf.org Thu Jan 26 15:07:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DP0-0003bM-GV; Thu, 26 Jan 2006 15:07:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DOy-0003b9-Re for sigtran@megatron.ietf.org; Thu, 26 Jan 2006 15:07:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21107 for ; Thu, 26 Jan 2006 15:05:56 -0500 (EST) Received: from web35410.mail.mud.yahoo.com ([66.163.179.119]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2DYx-0004Ak-JX for sigtran@ietf.org; Thu, 26 Jan 2006 15:17:50 -0500 Received: (qmail 25977 invoked by uid 60001); 26 Jan 2006 20:07:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f3XP9YIN6Y0gCD+tdh7ueG1ropG9Vh3MVMUQGdx+H3BxXNzAxQqzmU06AXuWNNZ8kcURbj5ewOkTXFg4Q/ov9gtNrD8F4eQJvlo8+r4OKBBZb5VxB2XD4NA/15w17LYlvBnKyqrwLNJ74CoIb+sATjRA9cz42dwQPK2FwFcAiJM= ; Message-ID: <20060126200717.25975.qmail@web35410.mail.mud.yahoo.com> Received: from [194.237.142.13] by web35410.mail.mud.yahoo.com via HTTP; Thu, 26 Jan 2006 12:07:16 PST Date: Thu, 26 Jan 2006 12:07:16 -0800 (PST) From: Stanislav Ivanovich Subject: Re: [Sigtran] Re: Can SUA Layer encapsulate MTP L3 layer/functionality? To: SIGTRAN In-Reply-To: <20060126123804.A2140@openss7.org> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0989930423==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0989930423== Content-Type: multipart/alternative; boundary="0-1958155536-1138306036=:24470" Content-Transfer-Encoding: 8bit --0-1958155536-1138306036=:24470 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Brian, Please read my last mail I have recently sent with clarififcations on my last question. Here I react to this statement: --------------------------------------------------- [Brian] Also, M3UA may contain MTP3 functions. --------------------------------------------------- No! Certainly not! Anyway why would anyone need any SIGTRAN paper (like M3UA) to develop something that already exist??? Is it because we can say"We have developed new xxUA thing which is the same thing ITU-T developed 20 years ago"??? M3UA certainly does specify something what is not specified in ITU-T specifications (messages for MTP3 API primitives + AS redundacy support). However this is not MTP functionality! Neither two M3UA instances can communicate like two MTP3 instances! Why would one use M3UA as replacement for MTP external protocol if these already exisit??? M3UA does contain peer-to-peer protocol but it is certainly not replacement for MTP external protocol! Two MTP3 instances can communicate with TFP, TFA... while DUNA, DAVA are not supported on IPSP-IPSP interfaces with very good reason! / Stanislav "Brian F. G. Bidulock" wrote: Stanislav, Stanislav Ivanovich wrote: (Thu, 26 Jan 2006 10:48:17) > > Brian, and other SIGTRAN community memebers, > > > > I have read that RFC many years ago and do understand it quite well. I > think you haven't understand my point with SAAL specifications which I > used just as a refference to show what I mean. > > > > Could you please answer this very simple question in very simple way > (with YES or NO), which I copy/paste from my previous mail. Well, no, I cannot: because your question proceeds from a false premise. SUA does not have to contain SCCP functions. Also, M3UA may contain MTP3 functions. --brian > > > > "It is clear that SUA adaptation layer must contain SCCP functions. > However the question is can SUA layer contain MTP functions? E.g. MTP3 > relay?" > > If YES how is the MTP3 functionality supported by SUA protocol if I > read: > > > > SUA RFC: sec. 3.4.1. DUNA is meant to replace N-STATE and > N-PCSTATE indications... > > > > / Stanislav Ivanovich > > > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --------------------------------- Do you Yahoo!? With a free 1 GB, there's more in store with Yahoo! Mail. --0-1958155536-1138306036=:24470 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Brian,
 
Please read my last mail I have recently sent with clarififcations on my last question.
 
 
Here I react to this statement:
 
---------------------------------------------------
[Brian]
Also, M3UA may contain MTP3 functions.
---------------------------------------------------
 
No! Certainly not!
Anyway why would anyone need any SIGTRAN paper (like M3UA) to develop something that already exist??? Is it because we can say"We have developed new xxUA thing which is the same thing ITU-T developed 20 years ago"???
 
M3UA certainly does specify something what is not specified in ITU-T specifications (messages for MTP3 API primitives + AS redundacy support). However this is not MTP functionality!
Neither two M3UA instances can communicate like two M! TP3 instances!
 
Why would one use M3UA as replacement for MTP external protocol if these already exisit??? M3UA does contain peer-to-peer protocol but it is certainly not replacement for MTP external protocol!
Two MTP3 instances can communicate with TFP, TFA... while DUNA, DAVA are not supported on IPSP-IPSP interfaces with very good reason!
 
/ Stanislav
 
 


"Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
Stanislav,

Stanislav Ivanovich wrote: (Thu, 26 Jan 2006 10:48:17)
>
> Brian, and other SIGTRAN community memebers,
>
>
>
> I have read that RFC many years ago and do understand it quite well. I
> think you haven't understand my point with SAAL specifications which I
&! gt; used just as a refference to show what I mean.
>
>
>
> Could you please answer this very simple question in very simple way
> (with YES or NO), which I copy/paste from my previous mail.

Well, no, I cannot: because your question proceeds from a false premise. SUA
does not have to contain SCCP functions. Also, M3UA may contain MTP3 functions.

--brian


>
>
>
> "It is clear that SUA adaptation layer must contain SCCP functions.
> However the question is can SUA layer contain MTP functions? E.g. MTP3
> relay?"
>
> If YES how is the MTP3 functionality supported by SUA protocol if I
> read:
>
>
>
> SUA RFC: sec. 3.4.1. DUNA is meant to replace N-STATE and
> N-PCSTATE indications...
>
>
>
> / Stanislav Ivanovich
>
>
>


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

Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo! Mail. --0-1958155536-1138306036=:24470-- --===============0989930423== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0989930423==-- From sigtran-bounces@ietf.org Thu Jan 26 15:24:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DfT-0002W3-75; Thu, 26 Jan 2006 15:24:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DfR-0002VJ-Gl for sigtran@megatron.ietf.org; Thu, 26 Jan 2006 15:24:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22183 for ; Thu, 26 Jan 2006 15:22:57 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[nBRsHa/biCefxjN0EOnGa6R4AWkqHoFg]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2DpR-0004g0-Ri for sigtran@ietf.org; Thu, 26 Jan 2006 15:34:51 -0500 Received: from ns.pigworks.openss7.net (IDENT:bIq8aNKFDO2Li/igqGxyIEkOwc/Ul87G@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0QKOQj22218; Thu, 26 Jan 2006 13:24:26 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0QKOQ702600; Thu, 26 Jan 2006 13:24:26 -0700 Date: Thu, 26 Jan 2006 13:24:25 -0700 From: "Brian F. G. Bidulock" To: Stanislav Ivanovich Subject: Re: [Sigtran] Re: Can SUA Layer encapsulate MTP L3 layer/functionality? Message-ID: <20060126132425.A2572@openss7.org> Mail-Followup-To: Stanislav Ivanovich , SIGTRAN References: <20060126123804.A2140@openss7.org> <20060126200717.25975.qmail@web35410.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060126200717.25975.qmail@web35410.mail.mud.yahoo.com>; from stanislav_ivanovich@yahoo.com on Thu, Jan 26, 2006 at 12:07:16PM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Stanislav, You are still confused. In the multiple SG as STP configuration, the ASP needs to provide some MTP3 functions in the M3UA layer (namely routing and route status). Also, please read RFC 2719 section 4.1. --brian Stanislav Ivanovich wrote: (Thu, 26 Jan 2006 12:07:16) > > Brian, > > > > Please read my last mail I have recently sent with clarififcations on > my last question. > > > > > > Here I react to this statement: > > > > --------------------------------------------------- > > [Brian] > > Also, M3UA may contain MTP3 functions. > --------------------------------------------------- > > > > No! Certainly not! > > Anyway why would anyone need any SIGTRAN paper (like M3UA) to develop > something that already exist??? Is it because we can say"We have > developed new xxUA thing which is the same thing ITU-T developed 20 > years ago"??? > > > > M3UA certainly does specify something what is not specified in ITU-T > specifications (messages for MTP3 API primitives + AS redundacy > support). However this is not MTP functionality! > > Neither two M3UA instances can communicate like two M! TP3 instances! > > > > Why would one use M3UA as replacement for MTP external protocol if > these already exisit??? M3UA does contain peer-to-peer protocol but it > is certainly not replacement for MTP external protocol! > > Two MTP3 instances can communicate with TFP, TFA... while DUNA, DAVA > are not supported on IPSP-IPSP interfaces with very good reason! > > > > / Stanislav > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 30 14:15:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3eUU-0000gr-4v; Mon, 30 Jan 2006 14:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3eUS-0000eA-2Y for sigtran@megatron.ietf.org; Mon, 30 Jan 2006 14:15:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18559 for ; Mon, 30 Jan 2006 14:13:09 -0500 (EST) Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3eew-0006dd-Sm for sigtran@ietf.org; Mon, 30 Jan 2006 14:25:56 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k0UJAhW12637 for ; Mon, 30 Jan 2006 14:10:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jan 2006 14:14:32 -0500 Message-ID: Thread-Topic: Parameter Padding Question Thread-Index: AcYl0IkPA4RmWrmTSYudF5HNbq0kZwAANGWA From: "Kelly Mcdonald" To: "Kelly Mcdonald" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Subject: [Sigtran] RE: Parameter Padding Question X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1323363564==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1323363564== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C625D1.66912BE3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C625D1.66912BE3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SIGTRAN community > I am hoping you can help me out with a matter of interpreting a > section that is generating some confusion within my group >=20 > Specifically a part from Section 3.2 >=20 > Parameter Value: variable length.=20 > The Parameter Value field contains the actual information to be > transferred in the parameter. The total length of a parameter > (including Tag, Parameter Length and Value fields) MUST be a multiple > of 4 bytes. If the length of the parameter is not a multiple of 4 > bytes, the sender pads the Parameter at the end (i.e., after the > Parameter Value field) with all zero bytes. The length of the padding > is NOT included in the parameter length field. A sender SHOULD NOT pad > with more than 3 bytes. The receiver MUST ignore the padding bytes.=20 >=20 > My question is, if non-zero padding values are used within the > parameter value, is this still considered a valid message? Based on > the parameter length value we are able to extract the parameter itself > from the message irregardless of the padding. And while the spec calls > for zero bytes to be used, it also states that the padding bytes MUST > be ignored.=20 >=20 > Is the receiver expected to extract a parameter even if the > padding bytes are not zero (i.e. ignore the padding bytes) , or should > the message be rejected as invalid (as the padding is non-zero) >=20 > I hope you can help >=20 > Thanks >=20 > Kelly McDonald BSc.=20 > USP GNPS Team Lead > ESN: 395-1467=20 > External: 613-765-1467=20 > uspgnps@nortel.com > mackelly@nortel.com=20 >=20 >=20 ------_=_NextPart_001_01C625D1.66912BE3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Parameter Padding Question

      SIGTRAN community

      I am hoping you can help me out with a = matter of interpreting a section that is generating some confusion = within my group

      Specifically a part from Section = 3.2

      Parameter Value: variable length. =
      The Parameter Value field contains = the actual information to be transferred in the parameter. The total = length of a parameter (including Tag, Parameter Length and Value fields) = MUST be a multiple of 4 bytes. If the length of the parameter is not a = multiple of 4 bytes, the sender pads the Parameter at the end (i.e., = after the Parameter Value field) with all zero bytes. The length of the = padding is NOT included in the parameter length field. A sender SHOULD = NOT pad with more than 3 bytes. The receiver MUST ignore the padding = bytes.

      My question is, if non-zero padding = values are used within the parameter value, is this still considered a = valid message? Based on the parameter length value we are able to = extract the parameter itself from the message irregardless of the = padding. And while the spec calls for zero bytes to be used, it also = states that the padding bytes MUST be ignored.

      Is the receiver expected to extract a = parameter even if the padding bytes are not zero (i.e. ignore the = padding bytes) , or should the message be rejected as invalid (as the = padding is non-zero)

      I hope you can help

            Thanks

    Kelly McDonald BSc.
    USP GNPS Team Lead
    ESN: 395-1467
    External: 613-765-1467
    uspgnps@nortel.com
    mackelly@nortel.com


------_=_NextPart_001_01C625D1.66912BE3-- --===============1323363564== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1323363564==-- From sigtran-bounces@ietf.org Mon Jan 30 14:24:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3edw-0002bA-68; Mon, 30 Jan 2006 14:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3edu-0002b5-S8 for sigtran@megatron.ietf.org; Mon, 30 Jan 2006 14:24:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19592 for ; Mon, 30 Jan 2006 14:23:15 -0500 (EST) Received: from phl-28-b-170.phl.dsl.cerfnet.com ([63.242.157.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3eog-00071z-V3 for sigtran@ietf.org; Mon, 30 Jan 2006 14:36:02 -0500 Received: from bn001320 (bn001320 [192.168.1.61]) by phl-28-b-170.phl.dsl.cerfnet.com (8.12.8/8.12.8) with SMTP id k0UJOXoj024201 for ; Mon, 30 Jan 2006 14:24:33 -0500 From: "Barry Nagelberg" To: Subject: RE: [Sigtran] RE: Parameter Padding Question Date: Mon, 30 Jan 2006 14:26:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Kelly, Yes, this is still considered a valid message. Please see the definition of "SHOULD NOT" from RFC 2119: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. In this case, the sender may have a "valid reason" to send non-zero bytes. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Kelly Mcdonald Sent: Monday, January 30, 2006 2:15 PM To: Kelly Mcdonald; sigtran@ietf.org Subject: [Sigtran] RE: Parameter Padding Question SIGTRAN community I am hoping you can help me out with a matter of interpreting a section that is generating some confusion within my group Specifically a part from Section 3.2 Parameter Value: variable length. The Parameter Value field contains the actual information to be transferred in the parameter. The total length of a parameter (including Tag, Parameter Length and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is NOT included in the parameter length field. A sender SHOULD NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes. My question is, if non-zero padding values are used within the parameter value, is this still considered a valid message? Based on the parameter length value we are able to extract the parameter itself from the message irregardless of the padding. And while the spec calls for zero bytes to be used, it also states that the padding bytes MUST be ignored. Is the receiver expected to extract a parameter even if the padding bytes are not zero (i.e. ignore the padding bytes) , or should the message be rejected as invalid (as the padding is non-zero) I hope you can help Thanks Kelly McDonald BSc. USP GNPS Team Lead ESN: 395-1467 External: 613-765-1467 uspgnps@nortel.com mackelly@nortel.com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 30 14:47:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3ezT-0008Bw-2f; Mon, 30 Jan 2006 14:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3ezR-0008BY-Dj for sigtran@megatron.ietf.org; Mon, 30 Jan 2006 14:47:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21760 for ; Mon, 30 Jan 2006 14:45:27 -0500 (EST) Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3fAC-0007wB-Q5 for sigtran@ietf.org; Mon, 30 Jan 2006 14:58:15 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0UJkeT08566; Mon, 30 Jan 2006 14:46:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] RE: Parameter Padding Question Date: Mon, 30 Jan 2006 14:46:39 -0500 Message-ID: Thread-Topic: [Sigtran] RE: Parameter Padding Question Thread-Index: AcYl00cVcX/T4lcfTmqqltqHLq634QAAiQnQ From: "Kelly Mcdonald" To: "Barry Nagelberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Barry,=20 Thanks for your response.=20 My understanding of the "A sender SHOULD NOT pad with more than 3 bytes" referred to, that since parameters MUST be a multiple of 4 bytes, you could theoretically add additional padding as long as the multiple of 4 rule was followed i.e. "0D 00 00 00 00 00 00 00" is technically allowed because it is a multiple of 4 bytes, however we SHOULD NOT pad with more than 3 bytes, leaving us with "0D 00 00 00" Comments? Kelly McDonald BSc=20 USP GNPS Team Leader=20 Nortel Networks=20 ESN: 395-1467=20 Phone: 613-765-1467=20 uspgnps@nortel.com mackelly@nortel.com=20 -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Barry Nagelberg Sent: Monday, January 30, 2006 2:27 PM To: sigtran@ietf.org Subject: RE: [Sigtran] RE: Parameter Padding Question Kelly, Yes, this is still considered a valid message. Please see the definition of "SHOULD NOT" from RFC 2119: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. In this case, the sender may have a "valid reason" to send non-zero bytes. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Kelly Mcdonald Sent: Monday, January 30, 2006 2:15 PM To: Kelly Mcdonald; sigtran@ietf.org Subject: [Sigtran] RE: Parameter Padding Question SIGTRAN community I am hoping you can help me out with a matter of interpreting a section that is generating some confusion within my group Specifically a part from Section 3.2 Parameter Value: variable length. The Parameter Value field contains the actual information to be transferred in the parameter. The total length of a parameter (including Tag, Parameter Length and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is NOT included in the parameter length field. A sender SHOULD NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes. My question is, if non-zero padding values are used within the parameter value, is this still considered a valid message? Based on the parameter length value we are able to extract the parameter itself from the message irregardless of the padding. And while the spec calls for zero bytes to be used, it also states that the padding bytes MUST be ignored. Is the receiver expected to extract a parameter even if the padding bytes are not zero (i.e. ignore the padding bytes) , or should the message be rejected as invalid (as the padding is non-zero) I hope you can help Thanks Kelly McDonald BSc. USP GNPS Team Lead ESN: 395-1467 External: 613-765-1467 uspgnps@nortel.com mackelly@nortel.com _______________________________________________ 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 From sigtran-bounces@ietf.org Mon Jan 30 14:50:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3f2R-0000oy-Ix; Mon, 30 Jan 2006 14:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3f2Q-0000nv-GR for sigtran@megatron.ietf.org; Mon, 30 Jan 2006 14:50:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22115 for ; Mon, 30 Jan 2006 14:48:34 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[kHYCar6PlxMH1N1UHFJG551ulwmYbXhH]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3fDE-00085P-L5 for sigtran@ietf.org; Mon, 30 Jan 2006 15:01:22 -0500 Received: from ns.pigworks.openss7.net (IDENT:rpVJc1REH57ADIuHBkHPXzLOlfG1zPMb@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0UJntj11139; Mon, 30 Jan 2006 12:49:55 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0UJnsF28754; Mon, 30 Jan 2006 12:49:54 -0700 Date: Mon, 30 Jan 2006 12:49:54 -0700 From: "Brian F. G. Bidulock" To: Kelly Mcdonald Subject: Re: [Sigtran] RE: Parameter Padding Question Message-ID: <20060130124954.B28674@openss7.org> Mail-Followup-To: Kelly Mcdonald , Barry Nagelberg , sigtran@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from mackelly@nortel.com on Mon, Jan 30, 2006 at 02:46:39PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Barry Nagelberg , sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Kelly, Your understanding appears correct. --brian Kelly Mcdonald wrote: (Mon, 30 Jan 2006 14:46:39) > Barry, > > Thanks for your response. > > My understanding of the "A sender SHOULD NOT pad with more than 3 bytes" > referred to, that since parameters MUST be a multiple of 4 bytes, you > could theoretically add additional padding as long as the multiple of 4 > rule was followed > > i.e. "0D 00 00 00 00 00 00 00" is technically allowed because it is a > multiple of 4 bytes, however we SHOULD NOT pad with more than 3 bytes, > leaving us with "0D 00 00 00" > > Comments? > > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Jan 30 16:27:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3gZ2-0001Bw-M7; Mon, 30 Jan 2006 16:27:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3gZ1-0001AA-B0 for sigtran@megatron.ietf.org; Mon, 30 Jan 2006 16:27:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05616 for ; Mon, 30 Jan 2006 16:26:00 -0500 (EST) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3gjZ-00056h-3F for sigtran@ietf.org; Mon, 30 Jan 2006 16:38:49 -0500 Received: from [192.168.1.103] (p508F51E8.dip.t-dialin.net [80.143.81.232]) by ilsa.franken.de (Postfix) with ESMTP id 7006A245C9; Mon, 30 Jan 2006 22:27:23 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <73abc43e2e12d9f822eb611e37872b90@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Sigtran] RE: Parameter Padding Question Date: Mon, 30 Jan 2006 22:27:12 +0100 To: "Kelly Mcdonald" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.2 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Cc: Barry Nagelberg , sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi Kelly, the length issue is different from the use 0 for padding issue. If you pad with more than 3 bytes, a receiver would assume that another parameter is following. It will most likely then run into problems. That is why the text says in the bis document says: A sender MUST NOT pad with more than 3 bytes. and not SHOULD NOT as you are stating. Best regards Michael On Jan 30, 2006, at 20:46 Uhr, Kelly Mcdonald wrote: > Barry, > > Thanks for your response. > > My understanding of the "A sender SHOULD NOT pad with more than 3 > bytes" > referred to, that since parameters MUST be a multiple of 4 bytes, you > could theoretically add additional padding as long as the multiple of 4 > rule was followed > > i.e. "0D 00 00 00 00 00 00 00" is technically allowed because it is a > multiple of 4 bytes, however we SHOULD NOT pad with more than 3 bytes, > leaving us with "0D 00 00 00" > > Comments? > > > Kelly McDonald BSc > USP GNPS Team Leader > Nortel Networks > ESN: 395-1467 > Phone: 613-765-1467 > uspgnps@nortel.com > mackelly@nortel.com > > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Barry Nagelberg > Sent: Monday, January 30, 2006 2:27 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] RE: Parameter Padding Question > > > Kelly, > > Yes, this is still considered a valid message. Please see the > definition > of "SHOULD NOT" from RFC 2119: > > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > In this case, the sender may have a "valid reason" to send non-zero > bytes. > > Barry Nagelberg > Adax, Inc. > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Kelly Mcdonald > Sent: Monday, January 30, 2006 2:15 PM > To: Kelly Mcdonald; sigtran@ietf.org > Subject: [Sigtran] RE: Parameter Padding Question > > SIGTRAN community > I am hoping you can help me out with a matter of interpreting a section > that is generating some confusion within my group Specifically a part > from Section 3.2 > > Parameter Value: variable length. > The Parameter Value field contains the actual information to be > transferred in the parameter. The total length of a parameter > (including > Tag, Parameter Length and Value fields) MUST be a multiple of 4 bytes. > If the length of the parameter is not a multiple of 4 bytes, the sender > pads the Parameter at the end (i.e., after the Parameter Value field) > with all zero bytes. The length of the padding is NOT included in the > parameter length field. A sender SHOULD NOT pad with more than 3 bytes. > The receiver MUST ignore the padding bytes. > > My question is, if non-zero padding values are used within the > parameter > value, is this still considered a valid message? Based on the parameter > length value we are able to extract the parameter itself from the > message irregardless of the padding. > > And while the spec calls for zero bytes to be used, it also states that > the padding bytes MUST be ignored. > > Is the receiver expected to extract a parameter even if the padding > bytes are not zero (i.e. ignore the padding bytes) , or should the > message be rejected as invalid (as the padding is non-zero) > > I hope you can help > Thanks > Kelly McDonald BSc. > USP GNPS Team Lead > ESN: 395-1467 > External: 613-765-1467 > uspgnps@nortel.com > mackelly@nortel.com > > > _______________________________________________ > 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 From sigtran-bounces@ietf.org Tue Jan 31 09:04:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3w70-0004on-UN; Tue, 31 Jan 2006 09:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3w6z-0004nS-L3 for sigtran@megatron.ietf.org; Tue, 31 Jan 2006 09:04:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18466 for ; Tue, 31 Jan 2006 09:02:15 -0500 (EST) Received: from smtp02.tekelec.com ([198.89.42.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3wHl-000481-MF for sigtran@ietf.org; Tue, 31 Jan 2006 09:15:13 -0500 Received: from dcex05.tekelec.com (dcex05.tekelec.com [172.28.104.65]) by smtp02.tekelec.com (8.12.10/8.12.10) with ESMTP id k0VDx5IP027283 for ; Tue, 31 Jan 2006 07:59:05 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex05.tekelec.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 08:03:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jan 2006 08:03:32 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E7170289D434@DCEVS2.tekelec.com> Thread-Topic: (M2PA) Question about the requirement "The same standard MUST be followed on both ends" Thread-Index: AcYmbx6jSTlcwYTkTdKhMU6umDmq3Q== From: "Craig, Jeffrey" To: X-OriginalArrivalTime: 31 Jan 2006 14:03:32.0939 (UTC) FILETIME=[1EF759B0:01C6266F] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Subject: [Sigtran] (M2PA) Question about the requirement "The same standard MUST be followed on both ends" X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello All, =20 I am curious about the following RFC4165 M2PA requirement in section 4: =20 "The same standard MUST be followed on both ends of the M2PA link." M2PA does not appear to provide a mechanism for the user to identify the MTP2 standard upon which it is based, nor does it provide a mechanism to communicate that information to its peer. Given these facts, how is the user or the protocol supposed to satisfy the requirement? Shouldn't the statement be changed to something like: Interoperability cannot be guaranteed between two M2PA peers that are based upon different MTP2 standards, and so the M2PA user SHOULD ensure that M2PA peers conform to the same standard. Or, alternatively, perhaps M2PA should provide a mechanism to communicate the MTP2 standard upon which it is based. Perhaps a new parameter in the Link Status Alignment messsage can serve this purpose. Regards, Jeff =20 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Jan 31 11:57:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yop-0005Rr-MY; Tue, 31 Jan 2006 11:57:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yol-0005JH-MH for sigtran@megatron.ietf.org; Tue, 31 Jan 2006 11:57:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06463 for ; Tue, 31 Jan 2006 11:55:39 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[tTTiTxQ518GhNkkD0cE1J9FiRA/OLWxp]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3yzd-000353-I4 for sigtran@ietf.org; Tue, 31 Jan 2006 12:08:38 -0500 Received: from ns.pigworks.openss7.net (IDENT:LyVSYhEhHiqwJnu9Kc9ozHH8UFfxON4s@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k0VGvBj04077; Tue, 31 Jan 2006 09:57:11 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k0VGvAZ05983; Tue, 31 Jan 2006 09:57:10 -0700 Date: Tue, 31 Jan 2006 09:57:10 -0700 From: "Brian F. G. Bidulock" To: "Craig, Jeffrey" Subject: Re: [Sigtran] (M2PA) Question about the requirement "The same standard MUST be followed on both ends" Message-ID: <20060131095710.A5884@openss7.org> Mail-Followup-To: "Craig, Jeffrey" , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E7170289D434@DCEVS2.tekelec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <58292FA6B3EEFD49AEDAF6597E21E7170289D434@DCEVS2.tekelec.com>; from Jeffrey.Craig@tekelec.com on Tue, Jan 31, 2006 at 08:03:32AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Craig,, SS7 itself has no such mechanism, and yet, the same standard must be followed on both ends of an SS7 link or the link will not operate correctly. As is is done in SS7 today, by provisioning, without the need for protocol elements, that should be ok for M2PA as well. --brian Craig, Jeffrey wrote: (Tue, 31 Jan 2006 08:03:32) > Hello All, > > I am curious about the following RFC4165 M2PA requirement in section 4: > > "The same standard MUST be followed on both ends of the M2PA link." > > M2PA does not appear to provide a mechanism for the user to identify > the MTP2 standard upon which it is based, nor does it provide a > mechanism to communicate that information to its peer. Given these > facts, how is the user or the protocol supposed to satisfy the > requirement? > > Shouldn't the statement be changed to something like: > > Interoperability cannot be guaranteed between two M2PA peers that are > based > upon different MTP2 standards, and so the M2PA user SHOULD ensure that > M2PA > peers conform to the same standard. > > Or, alternatively, perhaps M2PA should provide a mechanism to > communicate > the MTP2 standard upon which it is based. Perhaps a new parameter in the > Link Status Alignment messsage can serve this purpose. > > Regards, > > Jeff > > > > _______________________________________________ > 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