From sigtran-bounces@ietf.org Wed Aug 03 08:04:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HzG-00082L-NY; Wed, 03 Aug 2005 08:04:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HzE-000817-Pt for sigtran@megatron.ietf.org; Wed, 03 Aug 2005 08:04:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08777 for ; Wed, 3 Aug 2005 08:04:39 -0400 (EDT) Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0IVt-0004t5-0b for sigtran@ietf.org; Wed, 03 Aug 2005 08:38:27 -0400 Received: (qmail 18117 invoked by uid 510); 3 Aug 2005 07:15:35 -0500 Received: from vikramb@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. spamassassin: 2.63. Clear:RC:0(59.95.0.169):SA:0(-104.7/3.0):. Processed in 1.064282 secs); 03 Aug 2005 12:15:35 -0000 X-Spam-Status: No, hits=-104.7 required=3.0 X-Antivirus-MYDOMAIN-Mail-From: vikramb@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(59.95.0.169):SA:0(-104.7/3.0):. Processed in 1.064282 secs Process 18101) Received: from unknown (HELO vikramb) (vikramb@aftek.com@59.95.0.169) by mail.aftek.com with SMTP; 3 Aug 2005 07:15:34 -0500 Message-ID: <011f01c59823$87eb76c0$9100000a@vikramb> From: "VikramB" To: Date: Wed, 3 Aug 2005 17:34:37 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Sigtran] sigtran/mgcp/??? 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="===============0314937634==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0314937634== Content-Type: multipart/alternative; boundary="----=_NextPart_000_011C_01C59851.9F140730" This is a multi-part message in MIME format. ------=_NextPart_000_011C_01C59851.9F140730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hell All, I am new to SIGTRAN world. I am bit confused with so = many technologis liike MGCP/SCTP/TRIP /SIGTRAN / SIP-PSTN internetwork......... and IMS from 3G PP ????=20 Can somebody tell me how these fit into one big picture ..... any link/doc also will do thanks in advance=20 =20 vikram ------=_NextPart_000_011C_01C59851.9F140730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hell All,

&nbs= p; =20 I am new to SIGTRAN world. I am bit confused with so many=20 technologis

liike MGCP/SCTP/TRIP /SIGTRAN = / SIP-PSTN=20 internetwork.........

and IMS from 3G PP ????

Can somebody tell me how these fit = into one=20 big picture .....

any link/doc also will do

thanks in advance

vikram

------=_NextPart_000_011C_01C59851.9F140730-- --===============0314937634== 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 --===============0314937634==-- From sigtran-bounces@ietf.org Wed Aug 03 12:28:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0M6B-0002k9-M1; Wed, 03 Aug 2005 12:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0M69-0002jz-MQ for sigtran@megatron.ietf.org; Wed, 03 Aug 2005 12:28:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28876 for ; Wed, 3 Aug 2005 12:28:03 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[txt7RLhN0rfLJLtOY7tumxM94+gqxDNA]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Mcr-0000dR-8t for sigtran@ietf.org; Wed, 03 Aug 2005 13:01:54 -0400 Received: from ns.pigworks.openss7.net (IDENT:CNggq67R+XEcJciCyKZ8I4j7J5OXfK+F@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j73GRqQ26770; Wed, 3 Aug 2005 10:27:52 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j73GRqt13558; Wed, 3 Aug 2005 10:27:52 -0600 Date: Wed, 3 Aug 2005 10:27:52 -0600 From: "Brian F. G. Bidulock" To: VikramB Subject: Re: [Sigtran] sigtran/mgcp/??? Message-ID: <20050803102752.A13528@openss7.org> Mail-Followup-To: VikramB , sigtran@ietf.org References: <011f01c59823$87eb76c0$9100000a@vikramb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <011f01c59823$87eb76c0$9100000a@vikramb>; from vikramb@aftek.com on Wed, Aug 03, 2005 at 05:34:37PM +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 VikramB, Start with RFC 2719. --brian VikramB wrote: (Wed, 03 Aug 2005 17:34:37) > > Hell All, > > I am new to SIGTRAN world. I am bit confused with so > many technologis > > liike MGCP/SCTP/TRIP /SIGTRAN / SIP-PSTN internetwork......... > > and IMS from 3G PP ???? > > > > Can somebody tell me how these fit into one big picture ..... > > any link/doc also will do > > > > thanks in advance > > > > > > vikram > _______________________________________________ > 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 Aug 04 06:00:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cWy-0005Xj-KG; Thu, 04 Aug 2005 06:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cWw-0005UB-KJ for sigtran@megatron.ietf.org; Thu, 04 Aug 2005 06:00:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18528 for ; Thu, 4 Aug 2005 06:00:48 -0400 (EDT) Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0d3n-0001Mb-71 for sigtran@ietf.org; Thu, 04 Aug 2005 06:34:48 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j74A7Som018783; Thu, 4 Aug 2005 12:07:28 +0200 Received: from bruc300e.sbs.be (bruc300e.sbs.be [193.210.175.142]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j74A09so022493; Thu, 4 Aug 2005 12:00:10 +0200 Received: by bruc300e.sbs.be with Internet Mail Service (5.5.2655.55) id ; Thu, 4 Aug 2005 12:00:09 +0200 Message-ID: <8CA2D55E9EBDEE479C2B99F4544F9CB363455B@hrtades7.atea.be> From: "Coene, Lode" To: "'pankajnath@huawei.com'" , sigtran@ietf.org Subject: RE: [Sigtran] query for bit 1 in Segmentation parameter (RFC 3868 - SUA) Date: Thu, 4 Aug 2005 11:59:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: john.Loughney@nokia.com, 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 > >-----Original Message----- >From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of pankaj >Sent: woensdag 13 juli 2005 14:53 >To: sigtran@ietf.org >Cc: john.Loughney@nokia.com; bidulock@openss7.org >Subject: [Sigtran] query for bit 1 in Segmentation parameter (RFC 3868 - SUA) > > >Hi All, > Please find below the text for segmentation parameter in section 3.10.23. (Segmentation) of RFC 3868. >"The segmentation paramter consists of the following: > > o bit 0: first/remaing segment bit: first = 1, remaining = 0 > o bit 1: sequence delivery option as original demanded(= before the > segementing) by the SCCP application. class 0 = 0, class 1 = 1. > o bit 2-3: spare > o bit 4-7: number of remaining segments(4 bits, values 0 -15) > o bit 8-31:segmentation reference(3 byte integer)" I think you copied this out of the SCCP Q713/714 or out of the SUA implementors guide... It is surely not in the RFC..(especially not in that particular paragraph...) > >Why we need the bit 1 value to find the protocol class. I think protocol class parameter is mandatory parameter >for both SCCP Connectionless message and SUA Connectionless message. I am not finding the usability of this >bit 1 in segmentation parameter. Please correct me if I am wrong. Also for protocol class 0, Is it required to do >the fragmentation and reassembly. When the message is segmented, the segments are send in sequence, meaning the CLDT's carrying the segmented CLDT will always have class 1. So the original CLDT sequence delivery option is lost to the reassembler of the CLDT. That is why we have this extra bit. It is required for class 0 or 1 to do segmenting/reassembly if a certain messages length is exceeded. What that message length is , is dependant on the underlying technology and/or administration and configuration. > >Also in section 3.10.23. "The field would thus be coded 1000 0000 (first, no remaining segments) for a un-segmented >CLDT" > >How will be 1000 0000 for protocol class 1? I think, this should be either 1000 0000 (for protocol class 0) and 1100 >0000 >(for protocol class 1). That is correct. Depending on the original protocol class, the bit should be turned on or off. However, if the messages remains the same, is still one message, then including the segmentation parameter is not really needed.... > >Thanks in Advance, >==Pankaj Nath== Yours sincerely, Lode Coene Siemens COM atealaan 34 2200 Herentals, Belgium E-mail: lode.coene@siemens.com Tel: +32-14-252081 Fax: +32-14-253212 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Aug 08 09:00:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27Eg-0004BY-DV; Mon, 08 Aug 2005 09:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27Eb-00049d-NA for sigtran@megatron.ietf.org; Mon, 08 Aug 2005 09:00:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18833 for ; Mon, 8 Aug 2005 09:00:03 -0400 (EDT) Received: from petasus.isw.intel.com ([192.55.37.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E27mH-0007AR-W7 for sigtran@ietf.org; Mon, 08 Aug 2005 09:34:55 -0400 Received: from swsmsxvs01.isw.intel.com (swsmsxvs01.isw.intel.com [172.28.130.22]) by petasus.isw.intel.com (8.12.9-20030918-01/8.12.10/d: small-solo.mc,v 1.2 2004/09/17 18:05:04 root Exp $) with SMTP id j78D41pi000685; Mon, 8 Aug 2005 13:04:16 GMT Received: from swsmsx331.ger.corp.intel.com ([172.28.130.50]) by swsmsxvs01.isw.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005080813593421842 ; Mon, 08 Aug 2005 13:59:34 +0100 Received: from swsmsx404.ger.corp.intel.com ([172.28.130.40]) by swsmsx331.ger.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 13:59:34 +0100 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 LS Ready at the end of Processor Outage Date: Mon, 8 Aug 2005 13:59:29 +0100 Message-ID: <39CC97884CA19A4D8D6296FE94357BCB02CB6E70@swsmsx404> Thread-Topic: [Sigtran] M2PA LS Ready at the end of Processor Outage Thread-Index: AcWUU2Dl2bYTTj7yQQaLeBRaNjObVwHm+cvw From: "May, Howard" To: "Daniel B. Simonraj" , "Brian F. G. Bidulock" X-OriginalArrivalTime: 08 Aug 2005 12:59:34.0371 (UTC) FILETIME=[064C5B30:01C59C19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable Cc: Subhashini , 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 During the SN realignment both LPO an RPO may need to discard incoming acknowledgements. I would like clarification of what 'discard incoming acknowledgements' means. =20 Does it simply mean that the receiving side must ignore any indication that a message has been successfully received by MTP3. Cheers Howard May >-----Original Message----- >From: sigtran-bounces@ietf.org=20 >[mailto:sigtran-bounces@ietf.org] On Behalf Of Daniel B. Simonraj >Sent: Friday, July 29, 2005 4:28 PM >To: Brian F. G. Bidulock >Cc: Subhashini; sigtran@ietf.org >Subject: Re: [Sigtran] M2PA LS Ready at the end of Processor Outage > >Brian, > > It looks ok to me. > >with regards, >P. Daniel Brein > > > >On Fri, 29 Jul 2005, Brian F. G. Bidulock wrote: > >> Daniel, >>=20 >> Well,... After looking at Figure 16 again, I think that the=20 >statement >> should say: >>=20 >> "M2PA SHALL NOT resume transmitting User Data Messages until it has >> _sent_ the Link Status Ready message." >>=20 >> Then it all works correctly, an the T1 timer will be set if there is >> messages to send. This is why the Remote Process Outage Recovered >> was indicated on receipt of LS PR. >>=20 >> Comments? >>=20 >> --brian >>=20 >> Brian F. G. Bidulock wrote: =20 > (Fri, 29 Jul 2005 07:56:48) >> > Daniel, >> >=20 >> > Yes, the triple handshake is required to restart the link, as >> > detailed in Figure 16 (which I drew), but there is no need to >> > start a timer at MTP2. >> >=20 >> > The RPO side need not report RPR to MTP3 until it receives the >> > last message in the resyncrhonization sequence, thus the MTP3 >> > RPO timer (T1) will still be running and put the link out of >> > service (MTP3 Stop command) if the sequence does not complete. >> >=20 >> > Also a time-controlled changeover procedure should have been >> > started at both sides and MTP3 CO timer (T2) will still be >> > running. Messages are not sent to MTP2 during RPO or while the >> > link is blocked, so there should be no User Data messages to >> > send from the RPO side, and if M2PA continues blocking, there >> > are also no messages sent at the LPO side either. >> >=20 >> > So, the example in Figure 16 should show Remote Processor Outage >> > Ceases going to MTP3 at B after receipt of the final LS Ready. >> > That way at least one side will put the link out of service if >> > messages suddenly get delayed for long periods of time. >> >=20 >> > M2PA at A can also keep MTP3 at A from unblocking the link, if >> > it is capable, until the last message in the sequence. >> >=20 >> > --brian >> >=20 >> > Daniel B. Simonraj wrote: =20 > (Fri, 29 Jul 2005 07:23:00) >> > > Brian, >> > >=20 >> > > In version 13 section 4.1.4 says "M2PA (at both the LPO=20 >and RPO ends) >> > > uses the BSN value in the received Link Status Ready message to >> > > resynchronize its sequence numbers, if this is required=20 >by MTP2. M2PA >> > > SHALL NOT resume transmitting User Data messages until=20 >it has received the >> > > Link Status Ready message". >> > >=20 >> > > If M2PA (RPO ends) receives Link Status Processor=20 >recovered message, then >> > > sends Link Status Ready message to resynchronize the=20 >sequence number and >> > > wait for the Ready message from other side. If it=20 >receives Ready message >> > > from other side, then the transmitting User Data message resumes. >> > >=20 >> > > This is my interpretation. Please clarify it. >> > >=20 >> > > with regards, >> > > P. Daniel Brein >> > >=20 >> > >=20 >> > >=20 >> > > On Fri, 29 Jul 2005, Brian F. G. Bidulock wrote: >> > >=20 >> > > > Subhashini, >> > > >=20 >> > > > Subhashini wrote: =20 > (Fri, 29 Jul 2005 16:55:40) >> > > > > In version 13 of M2PA, the text discussing the=20 >initial value of FSN is=20 >> > > > > removed. In version 7, the initial value of FSN was=20 >set to 1 and when it=20 >> > > > > reaches the maximum value, it was set to 0. Do we=20 >still go with this? Or=20 >> > > > > Is there any change in this? Can anybody clarify? >> > > >=20 >> > > > For MTP2 it is different for different variants. (Some set it >> > > > to all one's (i.e. -1) and some set it to zero.) Follow the >> > > > procedures for inittial FSN value of the MTP2 variant you are >> > > > following. If you want a receiver that can handle both, start >> > > > with whatever arrives first. >> > > >=20 >> > > > >=20 >> > > > > In version 13, LS Ready on stream 1 is introduced at=20 >the end of=20 >> > > > > Processor Outage. After sending LS Ready, while=20 >waiting for LS Ready=20 >> > > > > from peer to resynchronize the sequence numbers, do=20 >we need to start the=20 >> > > > > same T1 timer? If we do not get LS ready from peer=20 >within T1, do we need=20 >> > > > > to remove the link from inservice? >> > > >=20 >> > > > No, do not start a timer. The peer will send READY if it needs >> > > > to, otherwise it might not (doesn't need to resynchronize >> > > > sequence numbers because there are no unacknowledged FSNs). >> > > >=20 >> > > > --brian >> > > >=20 >> > > > >=20 >> > > > > thanks, >> > > > > Subhashini ... >> > > > >=20 >> > > > > _______________________________________________ >> > > > > Sigtran mailing list >> > > > > Sigtran@ietf.org >> > > > > https://www1.ietf.org/mailman/listinfo/sigtran >> > > >=20 >> > > > --=20 >> > > > Brian F. G. Bidulock >> > > > bidulock@openss7.org >> > > > http://www.openss7.org/ >> > > >=20 >> > > > _______________________________________________ >> > > > Sigtran mailing list >> > > > Sigtran@ietf.org >> > > > https://www1.ietf.org/mailman/listinfo/sigtran >> > > >=20 >> >=20 >> > --=20 >> > Brian F. G. Bidulock >> > bidulock@openss7.org >> > http://www.openss7.org/ >> >=20 >> > _______________________________________________ >> > Sigtran mailing list >> > Sigtran@ietf.org >> > https://www1.ietf.org/mailman/listinfo/sigtran >>=20 >> --=20 >> Brian F. G. Bidulock >> bidulock@openss7.org >> http://www.openss7.org/ >>=20 >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www1.ietf.org/mailman/listinfo/sigtran >>=20 > > >_______________________________________________ >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 Aug 08 11:56:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29ys-00047J-S9; Mon, 08 Aug 2005 11:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29yq-000475-QF for sigtran@megatron.ietf.org; Mon, 08 Aug 2005 11:56:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29171 for ; Mon, 8 Aug 2005 11:55:58 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[RQZml6YqCafWV6QMwDlo2MTQWFNi4+y1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2AWZ-0003h0-2E for sigtran@ietf.org; Mon, 08 Aug 2005 12:30:52 -0400 Received: from ns.pigworks.openss7.net (IDENT:cfFZZns9HGM2pDVgU3w751IkfYvpJL1j@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j78FtmQ08330; Mon, 8 Aug 2005 09:55:49 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j78FtmE07582; Mon, 8 Aug 2005 09:55:48 -0600 Date: Mon, 8 Aug 2005 09:55:48 -0600 From: "Brian F. G. Bidulock" To: "May, Howard" Subject: Re: [Sigtran] M2PA LS Ready at the end of Processor Outage Message-ID: <20050808095548.A7466@openss7.org> Mail-Followup-To: "May, Howard" , "Daniel B. Simonraj" , Subhashini , sigtran@ietf.org References: <39CC97884CA19A4D8D6296FE94357BCB02CB6E70@swsmsx404> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <39CC97884CA19A4D8D6296FE94357BCB02CB6E70@swsmsx404>; from howard.may@intel.com on Mon, Aug 08, 2005 at 01:59:29PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Daniel B. Simonraj" , Subhashini , 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 Howard, Although it is mentioned in the example in Figure 16 that acknowledgements are discarded, the example was written before we finally decided to send LS PR and LS Ready on the data stream. Before these messages were synchronized with the data it was possible to have several race conditions that not longer apply. One of them was late arriving acknowledgements that were sent before the Link Status messages used for SN synchronization. This can no longer occur, as the pertinent Link Status messages are sent sequenced on Stream 1 with the data an SCTP will ensure proper ordering. So, there should be no need to discard acknowledgements. --brian May, Howard wrote: (Mon, 08 Aug 2005 13:59:29) > During the SN realignment both LPO an RPO may need to discard incoming > acknowledgements. I would like clarification of what 'discard incoming > acknowledgements' means. > > Does it simply mean that the receiving side must ignore any indication > that a message has been successfully received by MTP3. > > Cheers > > Howard May -- 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 Aug 10 09:52:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2r0Z-0004T8-8u; Wed, 10 Aug 2005 09:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2r0X-0004Sl-0x for sigtran@megatron.ietf.org; Wed, 10 Aug 2005 09:52:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28760 for ; Wed, 10 Aug 2005 09:52:35 -0400 (EDT) Received: from smtp02.tekelec.com ([198.89.42.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2rYd-0007Ic-JC for sigtran@ietf.org; Wed, 10 Aug 2005 10:27:52 -0400 Received: from dcex04.tekelec.com (dcex04.tekelec.com [172.28.104.64]) by smtp02.tekelec.com (8.12.10/8.12.10) with ESMTP id j7ADnUQY023490 for ; Wed, 10 Aug 2005 08:49:30 -0500 (CDT) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex04.tekelec.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 08:52:18 -0500 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: Wed, 10 Aug 2005 08:52:17 -0500 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E7170182E1B3@DCEVS2.tekelec.com> Thread-Topic: other processor outage race conditions (was "M2PA LS Ready at the end of Processor Outage") Thread-Index: AcWcMffdCuDAJ5mNTAK1BTW5SSKAmABflBxg From: "Davidson, Mark" To: X-OriginalArrivalTime: 10 Aug 2005 13:52:18.0660 (UTC) FILETIME=[B9300A40:01C59DB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: "Kanode, Mark" Subject: [Sigtran] other processor outage race conditions (was "M2PA LS Ready at the end of Processor Outage") 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, What are the other "race conditions that no longer apply" ? I'm curious in particular about the following text: While there is a remote processor outage (RPO) condition: ... (b) If any User Data messages received from the peer after the Link Status Processor Outage cannot be delivered to MTP3, then these messages MUST NOT be acknowledged and MUST be buffered. How can User Data be sent after processor outage indication? Except for requiring an LS Ready for PO recovery, is there any reason not to=20 simply follow the MTP2 spec on this? Are there other problems being solved by the processor outage procedures beyond those that were self inflicted by sending processor outage indication on stream 0? Mark Davidson davidson@tekelec.com >Howard, > >Although it is mentioned in the example in Figure 16 that acknowledgements=20 >are discarded, the example was written before we finally decided to send LS=20 >PR and LS Ready on the data stream. Before these messages were synchronized=20 >with the data it was possible to have several race conditions that not=20 >longer apply. One of them was late arriving acknowledgements that were >sent before the Link Status messages used for SN synchronization. This >can no longer occur, as the pertinent Link Status messages are sent=20 >sequenced on Stream 1 with the data an SCTP will ensure proper ordering. > >So, there should be no need to discard acknowledgements. > >--brian > > >May, Howard wrote: (Mon, 08 Aug 2005 13:59:29) > >> During the SN realignment both LPO an RPO may need to discard incoming=20 >> acknowledgements. I would like clarification of what 'discard=20 >> incoming acknowledgements' means. >>=20 >> Does it simply mean that the receiving side must ignore any indication=20 >> that a message has been successfully received by MTP3. >>=20 >> Cheers >>=20 >> Howard May _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Aug 10 09:56:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2r4X-0005iH-M0; Wed, 10 Aug 2005 09:56:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2r4W-0005iC-8L for sigtran@megatron.ietf.org; Wed, 10 Aug 2005 09:56:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29065 for ; Wed, 10 Aug 2005 09:56:42 -0400 (EDT) Received: from postfix4-2.free.fr ([213.228.0.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2rcc-0007VA-TK for sigtran@ietf.org; Wed, 10 Aug 2005 10:32:00 -0400 Received: from [81.57.111.149] (mon75-2-81-57-111-149.fbx.proxad.net [81.57.111.149]) by postfix4-2.free.fr (Postfix) with ESMTP id B4F1893A2E for ; Wed, 10 Aug 2005 15:56:41 +0200 (CEST) Message-ID: <42FA03C1.1050503@free.fr> Date: Wed, 10 Aug 2005 15:40:17 +0200 From: Philippe Langlois User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sigtran@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Sigtran] Packet capture files with SCTP and other SIGTRAN protocols 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, I'm setting up a collection of capture files recording simple exchanges of SIGTRAN protocols (mostly that are using SCTP as transport). You can have a look there on a few of them: http://wiki.ethereal.com/SampleCaptures (section 'Sigtran Protocol Family' and 'Stream Control Transmission Protocol (SCTP)'), It would be great to have a few some of you to send me their own capture files or update the wiki directly themselves. Precising which equipment & software you used would be a plus. Thanks, Philippe Langlois. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Aug 10 15:02:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vqi-0006xQ-4a; Wed, 10 Aug 2005 15:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vqg-0006xL-30 for sigtran@megatron.ietf.org; Wed, 10 Aug 2005 15:02:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19546 for ; Wed, 10 Aug 2005 15:02:44 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[AUREiqnGApF8F1wK9mAKPYFySH8xVDJX]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2wOp-0000Bl-4L for sigtran@ietf.org; Wed, 10 Aug 2005 15:38:04 -0400 Received: from ns.pigworks.openss7.net (IDENT:xt1TVBAOmisFTXtNedNLEW4LGVSkTeji@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j7AJ2VQ25511; Wed, 10 Aug 2005 13:02:31 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j7AJ2VK03671; Wed, 10 Aug 2005 13:02:31 -0600 Date: Wed, 10 Aug 2005 13:02:30 -0600 From: "Brian F. G. Bidulock" To: "Davidson, Mark" Subject: Re: [Sigtran] other processor outage race conditions (was "M2PA LS Ready at the end of Processor Outage") Message-ID: <20050810130230.A3365@openss7.org> Mail-Followup-To: "Davidson, Mark" , sigtran@ietf.org, "Kanode, Mark" References: <58292FA6B3EEFD49AEDAF6597E21E7170182E1B3@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: <58292FA6B3EEFD49AEDAF6597E21E7170182E1B3@DCEVS2.tekelec.com>; from Mark.Davidson@tekelec.com on Wed, Aug 10, 2005 at 08:52:17AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "Kanode, Mark" , 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, Davidson, Mark wrote: (Wed, 10 Aug 2005 08:52:17) > > What are the other "race conditions that no longer apply" ? Some of the discussion about what arrives before what in the example in Figure 16. > I'm curious in particular about the following text: > > While there is a remote processor outage (RPO) condition: > ... > (b) If any User Data messages received from the peer after the Link > Status Processor Outage cannot be delivered to MTP3, then these > messages MUST NOT be acknowledged and MUST be buffered. > > How can User Data be sent after processor outage indication? While in local processor outage (LPO) condition: ... (c) M2PA SHOULD continue to transmit messages that have been sent by its upper layer MTP3. That's how. > > Except for requiring an LS Ready for PO recovery, is there any reason not to > simply follow the MTP2 spec on this? Are there other problems being solved > by the processor outage procedures beyond those that were self inflicted > by sending processor outage indication on stream 0? Yes, the other problem being solved is the subtle difference between MTP2 and M2PA: M2PA cannot discard messages because they will never be retransmitted. The above is an embellishment that we thought worth while: because M2PA can send a single LSPO where MTP2 sends continuous SIPO, it is possible for M2PA to clear any backlog of messages to the peer where MTP2 cannot. This reduces the number of messages to be changed over or flushed from the LPO end and is a good thing. --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 Aug 10 16:16:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2wxi-0007HF-5G; Wed, 10 Aug 2005 16:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2wxg-0007GA-E4 for sigtran@megatron.ietf.org; Wed, 10 Aug 2005 16:14:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00886 for ; Wed, 10 Aug 2005 16:14:02 -0400 (EDT) Received: from smtp01.tekelec.com ([198.89.42.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2xVq-0004ZN-9F for sigtran@ietf.org; Wed, 10 Aug 2005 16:49:23 -0400 Received: from dcex05.tekelec.com (dcex05.tekelec.com [172.28.104.65]) by smtp01.tekelec.com (8.12.10/8.12.10) with ESMTP id j7AKCuPj009767 for ; Wed, 10 Aug 2005 15:12:56 -0500 (CDT) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex05.tekelec.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 15:13:53 -0500 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] other processor outage race conditions (was "M2PA LS Ready at the end of Processor Outage") Date: Wed, 10 Aug 2005 15:13:52 -0500 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E7170186100A@DCEVS2.tekelec.com> Thread-Topic: [Sigtran] other processor outage race conditions (was "M2PA LS Ready at the end of Processor Outage") Thread-Index: AcWd3hJo7Pktm5FaS+i9FCJKu9uAmwABciwQ From: "Davidson, Mark" To: X-OriginalArrivalTime: 10 Aug 2005 20:13:53.0426 (UTC) FILETIME=[07881720:01C59DE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Brian, Thanks for your response. A few more questions/comments. >Davidson, Mark wrote: (Wed, 10 Aug 2005 08:52:17) >>=20 >> How can User Data be sent after processor outage indication? > > While in local processor outage (LPO) condition: > ... > (c) M2PA SHOULD continue to transmit messages that have been sent > by its upper layer MTP3. > >That's how. > I sure hope MTP3 doesn't continue to send data after a PO. I guess that moving status messages in front of data messages could create this condition (again, seems like self-inflicted pain). But per 4.1.8, that's only true for status messages on stream 0, right? ("M2PA SHOULD give higher priority to messages sent=20 on the Link Status stream...") So status messages on stream 1 (i.e. PO related status msgs) stay in order? So data is already sent. Really seems like a "should not occur". >>=20 >> Except for requiring an LS Ready for PO recovery, is there any reason >> not to simply follow the MTP2 spec on this? Are there other problems >> being solved by the processor outage procedures beyond those that were=20 >> self inflicted by sending processor outage indication on stream 0? > >Yes, the other problem being solved is the subtle difference between >MTP2 and M2PA: M2PA cannot discard messages because they will never be retransmitted. > >The above is an embellishment that we thought worth while: because M2PA >can send a single LSPO where MTP2 sends continuous SIPO, it is possible for=20 >M2PA to clear any backlog of messages to the peer where MTP2 cannot. > >This reduces the number of messages to be changed over or flushed from the=20 >LPO end and is a good thing. OK, I see how this could ease the pain in certain situations, but it still has to work with the backhoe type outage. Link failure is much more common than MTP3 failure. -Mark _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Aug 10 16:44:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2xQs-0007gd-0P; Wed, 10 Aug 2005 16:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2xQm-0007fK-LI for sigtran@megatron.ietf.org; Wed, 10 Aug 2005 16:44:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02676 for ; Wed, 10 Aug 2005 16:44:06 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[GxW24vusvCXcAy5G2gHzTDP+QfWm3D8J]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2xyw-0005R4-MZ for sigtran@ietf.org; Wed, 10 Aug 2005 17:19:28 -0400 Received: from ns.pigworks.openss7.net (IDENT:MBbPaIOfxytikssaeYolXLvAIu2hihgJ@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j7AKi5Q26764; Wed, 10 Aug 2005 14:44:05 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j7AKi5A04816; Wed, 10 Aug 2005 14:44:05 -0600 Date: Wed, 10 Aug 2005 14:44:05 -0600 From: "Brian F. G. Bidulock" To: "Davidson, Mark" Subject: Re: [Sigtran] other processor outage race conditions (was "M2PA LS Ready at the end of Processor Outage") Message-ID: <20050810144405.A4751@openss7.org> Mail-Followup-To: "Davidson, Mark" , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E7170186100A@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: <58292FA6B3EEFD49AEDAF6597E21E7170186100A@DCEVS2.tekelec.com>; from Mark.Davidson@tekelec.com on Wed, Aug 10, 2005 at 03:13:52PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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, Davidson, Mark wrote: (Wed, 10 Aug 2005 15:13:52) > Brian, > > Thanks for your response. A few more questions/comments. > > >Davidson, Mark wrote: (Wed, 10 Aug 2005 > 08:52:17) > >> > >> How can User Data be sent after processor outage indication? > > > > While in local processor outage (LPO) condition: > > ... > > (c) M2PA SHOULD continue to transmit messages that have been sent > > by its upper layer MTP3. > > > >That's how. > > > > I sure hope MTP3 doesn't continue to send data after a PO. I guess that moving > status messages in front of data messages could create this condition (again, > seems like self-inflicted pain). But per 4.1.8, that's only true for status > messages on stream 0, right? ("M2PA SHOULD give higher priority to messages sent > on the Link Status stream...") So status messages on stream 1 (i.e. PO related > status msgs) stay in order? So data is already sent. Really seems like a > "should not occur". There are several cases where there are messages to send after LPO. 1) MTP3 cannot receive messages (LPO) but it can send them. 2) Messages are queued between MTP3 and M2PA and, although LPO has been signalled, M2PA continues to receive messages for transmission. 3) Messages are priority queued between MTP3 and M2PA. Local processor outage is signalled with higher priority than messages for transmission. 4) There are messages in the M2PA TB waiting to be transmitted. These are all very valid situations. --brian > > >> > >> Except for requiring an LS Ready for PO recovery, is there any reason > >> not to simply follow the MTP2 spec on this? Are there other problems > >> being solved by the processor outage procedures beyond those that were > >> self inflicted by sending processor outage indication on stream 0? > > > >Yes, the other problem being solved is the subtle difference between > >MTP2 and M2PA: M2PA cannot discard messages because they will never be > >retransmitted. > > > >The above is an embellishment that we thought worth while: because M2PA > >can send a single LSPO where MTP2 sends continuous SIPO, it is possible for > >M2PA to clear any backlog of messages to the peer where MTP2 cannot. > > > >This reduces the number of messages to be changed over or flushed from the > >LPO end and is a good thing. > > OK, I see how this could ease the pain in certain situations, but it still > has to work with the backhoe type outage. Link failure is much more common > than MTP3 failure. > > -Mark > > > > _______________________________________________ > 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 Aug 23 23:34:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7m2I-0004bK-12; Tue, 23 Aug 2005 23:34:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7m2G-0004bA-0g for sigtran@megatron.ietf.org; Tue, 23 Aug 2005 23:34:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27616 for ; Tue, 23 Aug 2005 23:34:41 -0400 (EDT) From: varadaraj.yatirajula@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7m2T-0007ZJ-DJ for sigtran@ietf.org; Tue, 23 Aug 2005 23:34:59 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 408CD20670 for ; Wed, 24 Aug 2005 08:53:33 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 221C020664 for ; Wed, 24 Aug 2005 08:53:33 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 09:04:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Aug 2005 09:03:38 +0530 Message-ID: <897DA809E857CD40A8419CF517948E210131D004@blr-k1-msg.wipro.com> Thread-Topic: SUA traces Thread-Index: AcWoXJ2SBHmgeS2IS6qUwMngr86jaw== X-Priority: 5 Priority: Non-Urgent Importance: low To: X-OriginalArrivalTime: 24 Aug 2005 03:34:26.0688 (UTC) FILETIME=[BA5A8800:01C5A85C] X-Spam-Score: 1.1 (+) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [Sigtran] SUA traces 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="===============0602293283==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0602293283== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A85C.9E0C3D22" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A85C.9E0C3D22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I am new to the SUA protocol. I need an SUA ethereal dump/trace for reference to understand the flow of messages - for connectionless and connection oriented scenarios. If you have one can you please forward it on? =20 Regards Varadaraj =20 =20 ------_=_NextPart_001_01C5A85C.9E0C3D22 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

I am new to the SUA protocol. I need an SUA ethereal dump/trace

for reference to = understand the flow of messages - for connectionless

and connection = oriented scenarios. If you have one can you please forward it = on?

Regards

Varadaraj

------_=_NextPart_001_01C5A85C.9E0C3D22-- --===============0602293283== 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 --===============0602293283==-- From sigtran-bounces@ietf.org Tue Aug 30 04:59:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA1xS-0005ut-T0; Tue, 30 Aug 2005 04:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA1xR-0005uo-4E for sigtran@megatron.ietf.org; Tue, 30 Aug 2005 04:59:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29818 for ; Tue, 30 Aug 2005 04:59:02 -0400 (EDT) From: arijit.dilip@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA1ys-00026D-RJ for sigtran@ietf.org; Tue, 30 Aug 2005 05:00:39 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 718C62060E for ; Tue, 30 Aug 2005 14:17:42 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 55DAB2060C for ; Tue, 30 Aug 2005 14:17:42 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 14:28:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Aug 2005 14:28:43 +0530 Message-ID: Thread-Topic: Doubt regarding non-Transfer & non-SSNM message Thread-Index: AcWtQQWr3ujITYd1RNqFSsauhrI/lg== To: X-OriginalArrivalTime: 30 Aug 2005 08:58:44.0796 (UTC) FILETIME=[06C4AFC0:01C5AD41] X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sigtran] Doubt regarding non-Transfer & non-SSNM message 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="===============0685030656==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0685030656== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AD41.05B3BBCD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AD41.05B3BBCD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 in the sigtran rfc 3868 in section 4.2.1 (Receipt of SUA Peer Management Messages) it tacks abt non-Transfer and non-SSNM messages.=20 I am not very clear about this two types, any clarification on it will be really help full to me. =20 Thanks in advance, Arijit ------_=_NextPart_001_01C5AD41.05B3BBCD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all,

in the sigtran = rfc 3868 in=20 section 4.2.1 (Receipt of SUA Peer Management Messages) it tacks abt=20 non-Transfer and non-SSNM messages.

I am not very = clear about=20 this two types, any clarification on it will be really help full to=20 me.

Thanks in=20 advance,

Arijit

------_=_NextPart_001_01C5AD41.05B3BBCD-- --===============0685030656== 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 --===============0685030656==-- From sigtran-bounces@ietf.org Wed Aug 31 00:53:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAKay-0003h0-Fo; Wed, 31 Aug 2005 00:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAKax-0003gv-1y for sigtran@megatron.ietf.org; Wed, 31 Aug 2005 00:53:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01660 for ; Wed, 31 Aug 2005 00:53:03 -0400 (EDT) From: varadaraj.yatirajula@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAKca-0000hQ-Rv for sigtran@ietf.org; Wed, 31 Aug 2005 00:54:51 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id D8448205ED for ; Wed, 31 Aug 2005 10:11:49 +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 A7B55205EC for ; Wed, 31 Aug 2005 10:11:49 +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.211); Wed, 31 Aug 2005 10:22:53 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Aug 2005 10:22:52 +0530 Message-ID: <897DA809E857CD40A8419CF517948E2101367B0D@blr-k1-msg.wipro.com> Thread-Topic: SUA: Query regarding DEREG REQ message Thread-Index: AcWt59ggfEnme4v9S1Gv8Qf7fp+3VA== To: X-OriginalArrivalTime: 31 Aug 2005 04:52:53.0456 (UTC) FILETIME=[D8B29500:01C5ADE7] X-Spam-Score: 0.4 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: [Sigtran] SUA: Query regarding DEREG REQ message 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="===============0350133200==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0350133200== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5ADE7.D86F15D1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5ADE7.D86F15D1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the RFC3868, Sec 3.8.3 it states: =20 "The DEREG REQ message is sent by an ASP to indicate to a remote SUA peer that it wishes to deregister a given Routing Key. ... " =20 However in the figure the Routing Context is shown in the DEREG REQ message - is this a typo? =20 Regards, Varadaraj =20 ------_=_NextPart_001_01C5ADE7.D86F15D1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the RFC3868, Sec 3.8.3 it = states:

“The DEREG REQ = message is sent by an ASP to indicate to a remote SUA

peer that it wishes to = deregister a given Routing Key.

...

“<= /font>

However in the figure the = Routing Context is shown in the DEREG REQ message - is this a = typo?

Regards,=

Varadaraj

------_=_NextPart_001_01C5ADE7.D86F15D1-- --===============0350133200== 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 --===============0350133200==-- From sigtran-bounces@ietf.org Wed Aug 31 09:03:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EASFF-0004Sh-OQ; Wed, 31 Aug 2005 09:03:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EASF8-0004S7-U2 for sigtran@megatron.ietf.org; Wed, 31 Aug 2005 09:03:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19257 for ; Wed, 31 Aug 2005 09:03:04 -0400 (EDT) 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 1EASGp-0005Ef-Ak for sigtran@ietf.org; Wed, 31 Aug 2005 09:04:55 -0400 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 j7VD2eJg010219; Wed, 31 Aug 2005 09:02:42 -0400 From: "Barry Nagelberg" To: , Subject: RE: [Sigtran] SUA: Query regarding DEREG REQ message Date: Wed, 31 Aug 2005 09:04:20 -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) In-Reply-To: <897DA809E857CD40A8419CF517948E2101367B0D@blr-k1-msg.wipro.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit 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 Varadaraj, The Routing Context is a integer which, for a given ASP/SGP pair, has a 1:1 correspondence with a Routing Key. So the two concepts, Routing Context and Routing Key, can be used interchangeably in the RFC. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of varadaraj.yatirajula@wipro.com Sent: Wednesday, August 31, 2005 12:53 AM To: sigtran@ietf.org Subject: [Sigtran] SUA: Query regarding DEREG REQ message In the RFC3868, Sec 3.8.3 it states: "The DEREG REQ message is sent by an ASP to indicate to a remote SUA peer that it wishes to deregister a given Routing Key. ... " However in the figure the Routing Context is shown in the DEREG REQ message - is this a typo? Regards, Varadaraj _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran