Node=20 A------------------------------NodeB

in NOTIFY procedures Node A has already send = its=20 RC.

When NodeB sends its RC in ASP Active,Node A = throws=20 error as invalid RC.

Is it expected by Node A ,to have RC absent = in ASP=20 active ?

Query :I f RC is already exchanged during = Notify=20 procedures,RC is optional in followed ASP Active=20 procedures?

-Vikramjeet = Singh

------_=_NextPart_001_01CAEC13.C36233BC-- From barryn@adax.com Wed May 5 06:15:18 2010 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7211C28C0E3 for ; Wed, 5 May 2010 06:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8nrlrRxLqw1 for ; Wed, 5 May 2010 06:15:14 -0700 (PDT) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id E57803A68D0 for ; Wed, 5 May 2010 06:15:13 -0700 (PDT) Received: from static-151-204-189-187.pskn.east.verizon.net (static-151-204-189-187.pskn.east.verizon.net [151.204.189.187]) by mail1.adax.com (Postfix) with ESMTP id 68028120A19 for ; Wed, 5 May 2010 06:15:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by static-151-204-189-187.pskn.east.verizon.net (Postfix) with ESMTP id A4CD6201AF for ; Wed, 5 May 2010 09:14:59 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at static-151-204-189-187.pskn.east.verizon.net Received: from static-151-204-189-187.pskn.east.verizon.net ([127.0.0.1]) by localhost (static-151-204-189-187.pskn.east.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cN8Cv4UJWS8 for ; Wed, 5 May 2010 09:14:57 -0400 (EDT) Received: from bn001320 (bn001320.mtl-nj.adax [192.168.1.61]) by static-151-204-189-187.pskn.east.verizon.net (Postfix) with SMTP id A5F5C2011E for ; Wed, 5 May 2010 09:14:57 -0400 (EDT) From: "Barry Nagelberg" To: Date: Wed, 5 May 2010 09:15:17 -0400 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 V6.00.2800.1933 Importance: Normal In-Reply-To: <0E951286B87C324185643FC98E35D0F7561E10@FRMRSSMBS35.ad2.ad.alcatel.com> Subject: Re: [Sigtran] is it compulsary to have RC in ASP Active? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 13:15:18 -0000 Vikramjeet, It is recommended to have RC in ASP Active message, especially when more than one AS is using the association, but it is not mandatory. From 4.3.4.3. "ASP Active Procedures": In the case where an ASP wishes to process the traffic for more than one Application Server across a common SCTP association, the ASP Active message(s) SHOULD contain a list of one or more Routing Contexts to indicate for which Application Servers the ASP Active message applies. In the case where an ASP Active message does not contain a Routing Context parameter, the receiver must know, via configuration data, which Application Server(s) the ASP is a member. Barry -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of SINGH VIKRAMJEET Sent: Wednesday, May 05, 2010 1:28 AM To: sigtran@ietf.org Subject: [Sigtran] is it compulsary to have RC in ASP Active? Hi All, I have following configuration: 2 nodes on IPSP-SE mode. Node A------------------------------NodeB in NOTIFY procedures Node A has already send its RC. When NodeB sends its RC in ASP Active,Node A throws error as invalid RC. Is it expected by Node A ,to have RC absent in ASP active ? Query :I f RC is already exchanged during Notify procedures,RC is optional in followed ASP Active procedures? -Vikramjeet Singh From moloud@blueslice.com Thu May 13 10:51:07 2010 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FBD43A69A2 for ; Thu, 13 May 2010 10:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_50=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlD1ZRGYgvCF for ; Thu, 13 May 2010 10:51:06 -0700 (PDT) Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by core3.amsl.com (Postfix) with ESMTP id 013013A6816 for ; Thu, 13 May 2010 10:51:05 -0700 (PDT) Received: from EX13-N05.exchserver.com ([10.7.5.66]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id o4DHog0d014062 for ; Thu, 13 May 2010 13:50:42 -0400 Received: from EX41.exchserver.com ([169.254.4.21]) by EX13-N05.exchserver.com ([10.7.40.160]) with mapi; Thu, 13 May 2010 13:50:42 -0400 From: Moloud Mousavi To: "sigtran@ietf.org" Date: Thu, 13 May 2010 13:50:39 -0400 Thread-Topic: Message initiator Thread-Index: AcrsVRg9trLvyXyOTACMkiNuZ7SWbAGbtm8Q Message-ID: <345A3596DB43194797927F6ADFBFFFEF0260E7118B@EX41.exchserver.com> References: <0E951286B87C324185643FC98E35D0F7561E10@FRMRSSMBS35.ad2.ad.alcatel.com> In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-crx-noroute: SMTP reroute not required Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: moloud@blueslice.com Subject: [Sigtran] Message initiator X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 17:51:07 -0000 Hi all, I was looking for the initiator of M3UA message sequencing in RFC, and coul= dn't find any. Usually an association type (client or server) identifies who should starts= connection establishment! So my questions are: 1) Who sends ASP UP or ASPAC "according to RFC"? 2) Does it have anything to do with SCTP; the one who sends INIT is the one= who sends the ASPUP and ASPAC? Thanks, Moloud NOTICE: This e-mail contains information that may be confidential and propr= ietary. If you are not the intended recipient, any disclosure or other use = of this e-mail or the information contained herein or attached hereto may b= e unlawful and is strictly prohibited. If you have received this e-mail in = error, please notify the sender immediately and delete this e-mail without = reading, printing, copying or forwarding it to anyone. Thank you for your k= ind cooperation. AVIS : Ce courriel contient des renseignements qui peuvent etre confidentie= ls ou de propriete industrielle. Si vous n'etes pas le veritable destinatai= re, la diffusion ou l'usage de ce courriel, des renseignements qu'il contie= nt ou des documents qui lui sont joints pourrait etre illegal. Il est donc = strictement interdit de les diffuser ou de les utiliser. Si vous avez recu = ce courriel par erreur, veuillez en aviser l'expediteur immediatement et ve= uillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser= . Merci de votre aimable collaboration. From bidulock@openss7.org Thu May 13 16:46:05 2010 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A5A3A6858 for ; Thu, 13 May 2010 16:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_50=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyu4YV3wnThl for ; Thu, 13 May 2010 16:46:04 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 39C183A67D6 for ; Thu, 13 May 2010 16:46:04 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:3W/knNXbN5ae2Q+dJQgkbmRWfcniXX5n@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3+etch1) with ESMTP id o4DNjqUD005842; Thu, 13 May 2010 17:45:52 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:KOQO8Ph2mTYSorqskoyvcmXolEol0R7h@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id o4DNjqXp003244; Thu, 13 May 2010 17:45:52 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id o4DNjpXL003243; Thu, 13 May 2010 17:45:51 -0600 Date: Thu, 13 May 2010 17:45:51 -0600 From: "Brian F. G. Bidulock" To: Moloud Mousavi Message-ID: <20100513234551.GA3047@openss7.org> Mail-Followup-To: Moloud Mousavi , "sigtran@ietf.org" References: <0E951286B87C324185643FC98E35D0F7561E10@FRMRSSMBS35.ad2.ad.alcatel.com> <345A3596DB43194797927F6ADFBFFFEF0260E7118B@EX41.exchserver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <345A3596DB43194797927F6ADFBFFFEF0260E7118B@EX41.exchserver.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Message initiator X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 23:46:05 -0000 Moloud, See RFC 4666 section: "1.4.8. SCTP Client/Server Model", pp 19-20. --brian Moloud Mousavi wrote: (Thu, 13 May 2010 13:50:39) > Hi all, > > I was looking for the initiator of M3UA message sequencing in RFC, and couldn't find any. > Usually an association type (client or server) identifies who should starts connection establishment! > > So my questions are: > > 1) Who sends ASP UP or ASPAC "according to RFC"? > 2) Does it have anything to do with SCTP; the one who sends INIT is the one who sends the ASPUP and ASPAC? > > > Thanks, > Moloud -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From cbenson@adax.com Thu May 13 18:10:07 2010 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339253A68D5 for ; Thu, 13 May 2010 18:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_05=-1.11, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2zuTRLaL9G7 for ; Thu, 13 May 2010 18:10:06 -0700 (PDT) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id BF49F3A6856 for ; Thu, 13 May 2010 18:10:05 -0700 (PDT) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id A8A47120BB5; Thu, 13 May 2010 18:09:55 -0700 (PDT) Received: by adax (Postfix, from userid 243) id 09A578ED2C; Thu, 13 May 2010 18:11:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 03D998ED2B; Thu, 13 May 2010 18:11:27 -0700 (PDT) Date: Thu, 13 May 2010 18:11:26 -0700 (PDT) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Moloud Mousavi In-Reply-To: <345A3596DB43194797927F6ADFBFFFEF0260E7118B@EX41.exchserver.com> Message-ID: References: <0E951286B87C324185643FC98E35D0F7561E10@FRMRSSMBS35.ad2.ad.alcatel.com> <345A3596DB43194797927F6ADFBFFFEF0260E7118B@EX41.exchserver.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Message initiator X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 01:10:07 -0000 Moloud, I think you already received a pointer as reply to your question 2). That is to say the direction of certain management M3UA messages is NOT related to client/server or sender of SCTP INIT. For question 1), you may note the first sentence of the ASP Active description in RFC 4666 (page 59) ... "The ASP Active message is sent by an ASP ...". The same direction is true for ASP UP. With thanks, from Chris. On Thu, 13 May 2010, Moloud Mousavi wrote: >> Date: Thu, 13 May 2010 13:50:39 -0400 >> From: Moloud Mousavi >> To: "sigtran@ietf.org" >> Subject: [Sigtran] Message initiator >> >> Hi all, >> >> I was looking for the initiator of M3UA message sequencing in RFC, and couldn't find any. >> Usually an association type (client or server) identifies who should starts connection establishment! >> >> So my questions are: >> >> 1) Who sends ASP UP or ASPAC "according to RFC"? >> 2) Does it have anything to do with SCTP; the one who sends INIT is the one who sends the ASPUP and ASPAC? >> >> >> Thanks, >> Moloud >> >> NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation. >> AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration. >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran >> From javi@trajano.us.es Sat May 22 14:03:23 2010 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C41D3A63C9 for ; Sat, 22 May 2010 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur3OBNyqytoA for ; Sat, 22 May 2010 14:03:21 -0700 (PDT) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 4A2B23A67A1 for ; Sat, 22 May 2010 14:03:20 -0700 (PDT) Received: (qmail 19512 invoked from network); 22 May 2010 23:03:09 +0200 Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 22 May 2010 23:03:09 +0200 Received: (qmail 28054 invoked by uid 507); 22 May 2010 21:03:09 -0000 Received: from 192.168.1.13 by antivirus1 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.1/11070. Clear:RC:1(192.168.1.13):. Processed in 0.034597 secs); 22 May 2010 21:03:09 -0000 Received: from unknown (HELO us.es) (192.168.1.13) by us.es with SMTP; 22 May 2010 21:03:08 -0000 Received: (qmail 10878 invoked from network); 22 May 2010 23:03:04 +0200 Received: from unknown (HELO trajano.us.es) (193.147.162.130) by us.es with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 May 2010 23:03:04 +0200 Received: from [127.0.0.1] (98.Red-81-33-242.dynamicIP.rima-tde.net [81.33.242.98]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id o4ML37si014796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 22 May 2010 23:03:08 +0200 Message-ID: <4BF84682.9040803@trajano.us.es> Date: Sat, 22 May 2010 23:02:58 +0200 From: Javi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: sigtran@ietf.org References: <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> <341a09720910150200k26967f86y8dd16330261752f8@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com> <76AD3443-4DFE-421F-B1F2-874C28D20F37@lurchi.franken.de> In-Reply-To: <76AD3443-4DFE-421F-B1F2-874C28D20F37@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Sigtran] RFC 4233: IUA and LAPB/LAPF X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 21:03:23 -0000 Hi, May IUA be used with LAPB (ITU-T X.25) or LAPF (ITU-T Q.922), instead of Q.921 (LAPD)? All of them are HDLC, but small differences. May any of these differences make IUA does not apply? Thanks, Javi From moloud@blueslice.com Tue May 25 09:04:08 2010 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C64B3A6AD9 for ; Tue, 25 May 2010 09:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.921 X-Spam-Level: X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_50=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yllOlnvJ1DuG for ; Tue, 25 May 2010 09:04:07 -0700 (PDT) Received: from cx295.800onemail.com (cx295.800onemail.com [209.171.54.144]) by core3.amsl.com (Postfix) with ESMTP id 1E7B43A6C2F for ; Tue, 25 May 2010 09:04:06 -0700 (PDT) Received: from EX13-N02.exchserver.com ([10.7.5.66]) by cx295.800onemail.com (8.13.8/8.13.8) with ESMTP id o4PG3tJm003299 for ; Tue, 25 May 2010 12:03:55 -0400 Received: from EX41.exchserver.com ([169.254.4.21]) by EX13-N02.exchserver.com ([10.7.40.170]) with mapi; Tue, 25 May 2010 12:03:55 -0400 From: Moloud Mousavi To: "sigtran@ietf.org" Date: Tue, 25 May 2010 12:03:53 -0400 Thread-Topic: Alternative to M3UA HeartBeat Thread-Index: Acr6V0NeVDfBolIZRmSKjZTKw7ICXwBytOrg Message-ID: <345A3596DB43194797927F6ADFBFFFEF0260FC45F8@EX41.exchserver.com> References: <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> <341a09720910150200k26967f86y8dd16330261752f8@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com><76AD3443-4DFE-421F-B1F2-874C28D20F37@lurchi.franken.de> <4BF84682.9040803@trajano.us.es> In-Reply-To: <4BF84682.9040803@trajano.us.es> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-crx-noroute: SMTP reroute not required Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: moloud@blueslice.com Subject: [Sigtran] Alternative to M3UA HeartBeat X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 16:04:08 -0000 Hi, RFC considers M3UA beat optional; it's needed over transport layers without= their own heartbeat mechanism. My question is: If M3UA beat is off while running over a transport layer wi= thout such a mechanism, what would be the system behavior? Does it stay in = a wrong status forever or is there an alternative to prevent such a case? Thanks, Moloud NOTICE: This e-mail contains information that may be confidential and propr= ietary. If you are not the intended recipient, any disclosure or other use = of this e-mail or the information contained herein or attached hereto may b= e unlawful and is strictly prohibited. If you have received this e-mail in = error, please notify the sender immediately and delete this e-mail without = reading, printing, copying or forwarding it to anyone. Thank you for your k= ind cooperation. AVIS : Ce courriel contient des renseignements qui peuvent etre confidentie= ls ou de propriete industrielle. Si vous n'etes pas le veritable destinatai= re, la diffusion ou l'usage de ce courriel, des renseignements qu'il contie= nt ou des documents qui lui sont joints pourrait etre illegal. Il est donc = strictement interdit de les diffuser ou de les utiliser. Si vous avez recu = ce courriel par erreur, veuillez en aviser l'expediteur immediatement et ve= uillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser= . Merci de votre aimable collaboration. From cbenson@adax.com Tue May 25 11:09:04 2010 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2CD3A6998 for ; Tue, 25 May 2010 11:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_50=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNYClc5zC0PO for ; Tue, 25 May 2010 11:09:00 -0700 (PDT) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id 83E513A68D7 for ; Tue, 25 May 2010 11:08:58 -0700 (PDT) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 04569120B97; Tue, 25 May 2010 11:08:50 -0700 (PDT) Received: by adax (Postfix, from userid 243) id DC1068ED95; Tue, 25 May 2010 11:10:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id D74728ED94; Tue, 25 May 2010 11:10:49 -0700 (PDT) Date: Tue, 25 May 2010 11:10:49 -0700 (PDT) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Moloud Mousavi In-Reply-To: <345A3596DB43194797927F6ADFBFFFEF0260FC45F8@EX41.exchserver.com> Message-ID: References: <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> <341a09720910150200k26967f86y8dd16330261752f8@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com><76AD3443-4DFE-421F-B1F2-874C28D20F37@lurchi.franken.de> <4BF84682.9040803@trajano.us.es> <345A3596DB43194797927F6ADFBFFFEF0260FC45F8@EX41.exchserver.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Alternative to M3UA HeartBeat X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 18:09:04 -0000 Moloud, Although other transports are technically allowed, in practice, M3UA is (always?) implemented over SCTP, which *does* have its own heartbeat mechanism. I thus consider your question moot. As you have probably noted, RFC 4666 only "recommends" that M3UA BEAT be used over transport layers without heartbeats. It is thus true that one could use a different transport layer (without its own hearbeat mechanism) and not be able to determine quickly that an M3UA peer has "disappeared". In certain circumstances, the determination can be made (e.g. waiting for ASPUP Ack), but in other circumstances (normal active, idle), the determination cannot be made by M3UA alone. So it isn't a good idea to implement the combination of "M3UA-no-BEATs" with "transport-no-heartbeats". With thanks, from Chris Benson. On Tue, 25 May 2010, Moloud Mousavi wrote: >> Date: Tue, 25 May 2010 12:03:53 -0400 >> From: Moloud Mousavi >> To: "sigtran@ietf.org" >> Subject: [Sigtran] Alternative to M3UA HeartBeat >> >> Hi, >> >> RFC considers M3UA beat optional; it's needed over transport layers without their own heartbeat mechanism. >> My question is: If M3UA beat is off while running over a transport layer without such a mechanism, what would be the system behavior? Does it stay in a wrong status forever or is there an alternative to prevent such a case? >> >> >> Thanks, >> Moloud >> >> >> NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation. >> AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration. >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran >> From deepak.gunjal@aricent.com Tue May 25 11:22:25 2010 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BFC3A68D6 for ; Tue, 25 May 2010 11:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSJJtMc-snri for ; Tue, 25 May 2010 11:22:23 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by core3.amsl.com (Postfix) with ESMTP id DFC753A6918 for ; Tue, 25 May 2010 11:22:13 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 90EAB36B65; Tue, 25 May 2010 23:47:39 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 7AF6C36B64; Tue, 25 May 2010 23:47:38 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Tue, 25 May 2010 23:52:02 +0530 From: Deepak Gunjal To: Chris Benson , Moloud Mousavi Date: Tue, 25 May 2010 23:52:02 +0530 Thread-Topic: [Sigtran] Alternative to M3UA HeartBeat Thread-Index: Acr8NV6Q6mIkpw5nTvmRTCwMe52T1AAANLpS Message-ID: References: <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> <341a09720910150200k26967f86y8dd16330261752f8@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com><76AD3443-4DFE-421F-B1F2-874C28D20F37@lurchi.franken.de> <4BF84682.9040803@trajano.us.es> <345A3596DB43194797927F6ADFBFFFEF0260FC45F8@EX41.exchserver.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Alternative to M3UA HeartBeat X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 18:22:25 -0000 What are the cases where I may require to use BEAT over reliable transport = viz. SCTP? I can think of a case where remote M3UA is stuck in a loop and u= nable to process protocol messages but its SCTP layer can still send and ac= knowledge heartbeats at SCTP level though M3UA as such is not available. Wi= ll this case qualify for using BEAT where peer can detect such problem as B= EAT ACK will not be received? Are there also other use cases which may suggest for use of BEAT over relia= ble transport? Regards Deepak ________________________________________ From: sigtran-bounces@ietf.org [sigtran-bounces@ietf.org] On Behalf Of Chri= s Benson [cbenson@adax.com] Sent: Tuesday, May 25, 2010 11:40 PM To: Moloud Mousavi Cc: sigtran@ietf.org Subject: Re: [Sigtran] Alternative to M3UA HeartBeat Moloud, Although other transports are technically allowed, in practice, M3UA is (always?) implemented over SCTP, which *does* have its own heartbeat mechanism. I thus consider your question moot. As you have probably noted, RFC 4666 only "recommends" that M3UA BEAT be used over transport layers without heartbeats. It is thus true that one could use a different transport layer (without its own hearbeat mechanism) and not be able to determine quickly that an M3UA peer has "disappeared". In certain circumstances, the determination can be made (e.g. waiting for ASPUP Ack), but in other circumstances (normal active, idle), the determination cannot be made by M3UA alone. So it isn't a good idea to implement the combination of "M3UA-no-BEATs" with "transport-no-heartbeats". With thanks, from Chris Benson. On Tue, 25 May 2010, Moloud Mousavi wrote: >> Date: Tue, 25 May 2010 12:03:53 -0400 >> From: Moloud Mousavi >> To: "sigtran@ietf.org" >> Subject: [Sigtran] Alternative to M3UA HeartBeat >> >> Hi, >> >> RFC considers M3UA beat optional; it's needed over transport layers wit= hout their own heartbeat mechanism. >> My question is: If M3UA beat is off while running over a transport laye= r without such a mechanism, what would be the system behavior? Does it stay= in a wrong status forever or is there an alternative to prevent such a cas= e? >> >> >> Thanks, >> Moloud >> >> >> NOTICE: This e-mail contains information that may be confidential and p= roprietary. If you are not the intended recipient, any disclosure or other = use of this e-mail or the information contained herein or attached hereto m= ay be unlawful and is strictly prohibited. If you have received this e-mail= in error, please notify the sender immediately and delete this e-mail with= out reading, printing, copying or forwarding it to anyone. Thank you for yo= ur kind cooperation. >> AVIS : Ce courriel contient des renseignements qui peuvent etre confide= ntiels ou de propriete industrielle. Si vous n'etes pas le veritable destin= ataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il co= ntient ou des documents qui lui sont joints pourrait etre illegal. Il est d= onc strictement interdit de les diffuser ou de les utiliser. Si vous avez r= ecu ce courriel par erreur, veuillez en aviser l'expediteur immediatement e= t veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diff= user. Merci de votre aimable collaboration. >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran >> _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From cbenson@adax.com Tue May 25 11:42:43 2010 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170613A6980 for ; Tue, 25 May 2010 11:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHu2D5cJEI1T for ; Tue, 25 May 2010 11:42:42 -0700 (PDT) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id E25C63A6948 for ; Tue, 25 May 2010 11:42:41 -0700 (PDT) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 9EBD9120A2A; Tue, 25 May 2010 11:42:33 -0700 (PDT) Received: by adax (Postfix, from userid 243) id 9C9A88ED95; Tue, 25 May 2010 11:44:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 965558ED94; Tue, 25 May 2010 11:44:33 -0700 (PDT) Date: Tue, 25 May 2010 11:44:33 -0700 (PDT) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Deepak Gunjal In-Reply-To: Message-ID: References: <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> <341a09720910150200k26967f86y8dd16330261752f8@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com><76AD3443-4DFE-421F-B1F2-874C28D20F37@lurchi.franken.de> <4BF84682.9040803@trajano.us.es> <345A3596DB43194797927F6ADFBFFFEF0260FC45F8@EX41.exchserver.com>, MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] Alternative to M3UA HeartBeat X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 18:42:43 -0000 Deepak, Your point is generally valid when M3UA is in any "out-to-lunch" state. An additional use case may be considered where the M3UA administrator wishes to have "quick" determination of misisng M3UA peers, and can tune the frequency of M3UA BEAT messages, but does not have the ability to increase the frequency of SCTP heartbeats. SCTP heartbeats might within recommendation be only every 60 seconds. Certain M3UA applications may not consider this satisfactory, and want more frequent BEAT messages. This is *not* complicated by the fact that the M3UA BEAT message (as SCTP-user DATA) can somewhat take the place of SCTP HEARTBEAT messages. For example, near the beginning of an SCTP 60 second heartbeat period, an M3UA peer can disappear, and the local [idle] M3UA may not know for a long time, unless it sends BEAT messages more frequently. Of course Moloud was originally addressing the converse problem of no M3UA BEATS with no transport heartbeats. With thanks, from Chris Benson On Tue, 25 May 2010, Deepak Gunjal wrote: >> Date: Tue, 25 May 2010 23:52:02 +0530 >> From: Deepak Gunjal >> To: Chris Benson , Moloud Mousavi >> Cc: "sigtran@ietf.org" >> Subject: RE: [Sigtran] Alternative to M3UA HeartBeat >> >> What are the cases where I may require to use BEAT over reliable transport viz. SCTP? I can think of a case where remote M3UA is stuck in a loop and unable to process protocol messages but its SCTP layer can still send and acknowledge heartbeats at SCTP level though M3UA as such is not available. Will this case qualify for using BEAT where peer can detect such problem as BEAT ACK will not be received? >> Are there also other use cases which may suggest for use of BEAT over reliable transport? >> >> Regards >> Deepak >> >> ________________________________________ >> From: sigtran-bounces@ietf.org [sigtran-bounces@ietf.org] On Behalf Of Chris Benson [cbenson@adax.com] >> Sent: Tuesday, May 25, 2010 11:40 PM >> To: Moloud Mousavi >> Cc: sigtran@ietf.org >> Subject: Re: [Sigtran] Alternative to M3UA HeartBeat >> >> Moloud, >> >> Although other transports are technically allowed, in practice, >> M3UA is (always?) implemented over SCTP, which *does* have its >> own heartbeat mechanism. >> >> I thus consider your question moot. As you have probably >> noted, RFC 4666 only "recommends" that M3UA BEAT be used >> over transport layers without heartbeats. It is thus true >> that one could use a different transport layer (without its >> own hearbeat mechanism) and not be able to determine quickly >> that an M3UA peer has "disappeared". In certain circumstances, >> the determination can be made (e.g. waiting for ASPUP Ack), >> but in other circumstances (normal active, idle), the >> determination cannot be made by M3UA alone. So it isn't >> a good idea to implement the combination of "M3UA-no-BEATs" >> with "transport-no-heartbeats". >> >> With thanks, from Chris Benson. >> >> On Tue, 25 May 2010, Moloud Mousavi wrote: >> >> >> Date: Tue, 25 May 2010 12:03:53 -0400 >> >> From: Moloud Mousavi >> >> To: "sigtran@ietf.org" >> >> Subject: [Sigtran] Alternative to M3UA HeartBeat >> >> >> >> Hi, >> >> >> >> RFC considers M3UA beat optional; it's needed over transport layers without their own heartbeat mechanism. >> >> My question is: If M3UA beat is off while running over a transport layer without such a mechanism, what would be the system behavior? Does it stay in a wrong status forever or is there an alternative to prevent such a case? >> >> >> >> >> >> Thanks, >> >> Moloud >> >> >> >> >> >> NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation. >> >> AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration. >> >> _______________________________________________ >> >> Sigtran mailing list >> >> Sigtran@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sigtran >> >> >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran >> >> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." >> From deddihp@yahoo.com Sun May 30 23:20:54 2010 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AEE3A69E8 for ; Sun, 30 May 2010 23:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgtdmYeKr9OR for ; Sun, 30 May 2010 23:20:52 -0700 (PDT) Received: from web76505.mail.sg1.yahoo.com (web76505.mail.sg1.yahoo.com [124.108.123.37]) by core3.amsl.com (Postfix) with SMTP id 838333A69E9 for ; Sun, 30 May 2010 23:20:52 -0700 (PDT) Received: (qmail 81492 invoked by uid 60001); 31 May 2010 06:20:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1275286836; bh=YQ1eqCsPUoJOE5+QhmUCnY3KCYw2NZ7dPMNHIHKYKO0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=Jof/b/p0NENUKQG4SYiZcwePh780Lf38CXGE23B0ICrfdwRhBypLjevWXCmXcCVrcLYWco7zSecJoFoA/Ch/uQOY3Ua+2nqxe6EObxaehbQBEwyExNP+QgUWXSJnyxb/FALEMpzVzQqgx9T3sWFqE3cQ/anqXE4be50uFsrkJVU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=05IkHSFylluSZIguiYd5djOEMV30+Cxtw+nT+W62I3mCtYnIc1RvmLVVffI054ULN4UZgWf76B5ryUFpPUVKbBuFveoUZ3XRn2vCVZmpahWNA5pNDeE6JJkklCJDpAsXJkpWFePbR5yMDnb37PJRNuHt8V041gXFMfLH3uMcrko=; Message-ID: <158090.80415.qm@web76505.mail.sg1.yahoo.com> X-YMail-OSG: Xt70X7EVM1l5ty5ht.AuqfzMnAsxt4.i7vb_hragUhDA1VV NuPNQWZRqJTza3MdDYDNPQ5d9NhpFPzLpSSBVLIIpbpqwRnQsXPpYrhm4GJ3 oJNX6TEdo5vzsuJeQmssTxmJvqVz7tbzdRdGtsNNCVCWClMrVB3ivVNypZKA 3ZhqW.Rpt8v0ZdtYqL990Ecsxux7lOKV7jVa5im5rq1I17kHFmhO.BAegEOu QCdVgWZKZtwXjL1vn10dM64g4ZbmzSwqR6JtNWdFBKSJsbB8Ahkb7Co.YW_. .wXRBE_DvQ.gtLjtyp9iPBatMQuEC1p11FW2g56G3KOiWfXTwx5xhSrY- Received: from [220.157.104.199] by web76505.mail.sg1.yahoo.com via HTTP; Mon, 31 May 2010 14:20:36 SGT X-Mailer: YahooMailClassic/11.0.8 YahooMailWebService/0.8.103.269680 Date: Mon, 31 May 2010 14:20:36 +0800 (SGT) From: deddi hp To: sigtran@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1251346709-1275286836=:80415" Subject: [Sigtran] Implement BSSAP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 06:20:54 -0000 --0-1251346709-1275286836=:80415 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello everyone, I try to implement BSSAP over SIGTRAN, so based on the manual I need to bui= ld mtp->sccp->bssap, is that right ?. In the MTP there is sctp as protocol, and then m2pa as MTP Layer 2, and the= n MTP. is it right I need to implement all of that stuff ?. Actually I have a problem using I_LINK between m2pa-sl and mtpi. is there a= nyone who knows the answer ?. Thanks =0A=0A --0-1251346709-1275286836=:80415 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello everyone,

I try to implement BSS= AP over SIGTRAN, so based on the manual I need to build mtp->sccp->bs= sap, is that right ?.

In the MTP there is sctp as protocol, and then= m2pa as MTP Layer 2, and then MTP.

is it right I need to implement = all of that stuff ?.
Actually I have a problem using I_LINK between m2pa= -sl and mtpi. is there anyone who knows the answer ?.

Thanks

--0-1251346709-1275286836=:80415--