Which ASP shall answer in Traffic Mode =3D Multicast?

From sigtran-bounces@ietf.org Fri Sep 01 11:33:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJB0k-0003oN-0c; Fri, 01 Sep 2006 11:32:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJB0i-0003oI-Pb for sigtran@ietf.org; Fri, 01 Sep 2006 11:32:48 -0400 Received: from hicks.ciena.com ([63.118.34.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJB0g-0004bS-HB for sigtran@ietf.org; Fri, 01 Sep 2006 11:32:48 -0400 Received: from lin1-118-39-27.ciena.com (HELO mdmxm02.ciena.com) ([63.118.39.27]) by hicks.ciena.com with ESMTP; 01 Sep 2006 11:43:25 -0400 X-IronPort-AV: i="4.08,201,1154923200"; d="scan'208,217"; a="62617797:sNHT40288828" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Sep 2006 11:23:20 -0400 Message-ID: <0901D1988E815341A0103206A834DA07F9BAAB@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call on IUA update Thread-Index: AcbN2o6T7fsBsWV3RsWb48GjtOLRnw== From: "Ong, Lyndon" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [Sigtran] WG Last Call on IUA update 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="===============1606150267==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1606150267== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CDDA.8F98393D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CDDA.8F98393D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 I've been neglecting this, but some time ago we agreed to go forward with the IUA TLV update in http://ietf.org/internet-drafts/draft-ietf-sigtran-rfc4233update-00.txt =20 Let's do a WG Last Call on this. Given the shortness of the draft, I think just a week would be sufficient for Last Call, however if people want we could make it the usual two weeks. =20 If there are no objections, let's have Last Call starting today (Sept. 1st) and going to next Friday (Sept. 8th). =20 Cheers, =20 L. Ong ------_=_NextPart_001_01C6CDDA.8F98393D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi=20 Folks,

I've = been neglecting=20 this, but some time ago we agreed to go forward with the IUA
TLV = update in http://ietf.org/internet-drafts/draft-ietf-sigtran-rfc4233update-= 00.txt

Let's = do a WG Last=20 Call on this. Given the shortness of the draft, I think=20 just

a week = would be=20 sufficient for Last Call, however if people want we could make=20 it

the = usual two=20 weeks.

If = there are no=20 objections, let's have Last Call starting today (Sept. 1st) and=20 going

to = next Friday=20 (Sept. 8th).

Cheers,

L.=20 Ong

------_=_NextPart_001_01C6CDDA.8F98393D-- --===============1606150267== 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 --===============1606150267==-- From sigtran-bounces@ietf.org Wed Sep 06 01:23:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKpsU-0002Vb-9g; Wed, 06 Sep 2006 01:23:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKpsT-0002VW-9V for sigtran@ietf.org; Wed, 06 Sep 2006 01:23:09 -0400 Received: from web54009.mail.yahoo.com ([206.190.36.233]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GKpsR-0000Ub-PI for sigtran@ietf.org; Wed, 06 Sep 2006 01:23:09 -0400 Received: (qmail 10000 invoked by uid 60001); 6 Sep 2006 05:23:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uPswh+aF//3RzxxVk1QZGdAWJwrfsizTGUDGatDat2Q8qOKKy6CxnciFw1blLs3lfOgqYbpo+O9rti8cqqruK2NVZekjqjp0d60rSZ4FP5FGYI6CC/Uk8U1pLdASMzXUjXP9Fcw5Rsap8BRe7drfknWdqQtmV8t6YZiOlP7IvqU= ; Message-ID: <20060906052307.9998.qmail@web54009.mail.yahoo.com> Received: from [220.227.132.114] by web54009.mail.yahoo.com via HTTP; Tue, 05 Sep 2006 22:23:07 PDT Date: Tue, 5 Sep 2006 22:23:07 -0700 (PDT) From: Saraswati Bose To: Brian Bidulock , sigtran MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Sigtran] SCTP: Multihoming Configuration 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="===============0138388918==" Errors-To: sigtran-bounces@ietf.org --===============0138388918== Content-Type: multipart/alternative; boundary="0-1129588597-1157520187=:99682" Content-Transfer-Encoding: 8bit --0-1129588597-1157520187=:99682 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian, please suggest in the below. Endpoint A (ASP) Endpoint B (SG) ASSO-1 IPs== IP1,IP2 IP== IP1' Port==P1 Port== P1' ASSO-2 IPs== IP1 IP== IP2 Port==P1 Port== P2 In ASP side Is the above a valid configuration? If yes then wht about the fact tht the same transport address of one multi homed endpoint (IP1+P1) must be used by any other SCTP endpoint? If no then how to support 1 ASP 2 SG scenario since we need 2 unique ASSOCIATION establishment for the scenarion? Regards, Saraswati --------------------------------- Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business. --0-1129588597-1157520187=:99682 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi Brian,

please suggest in the below.

Endpoint A (ASP) Endpoint B (SG)

ASSO-1

IPs== IP1,IP2 IP== IP1'

Port==P1 Port== P1'

ASSO-2

IPs== IP1 IP== IP2

Port==P1 Port== P2

In ASP side Is the above a valid configuration?

If yes then wht about the fact tht the same transport address of one multi homed endpoint (IP1+P1) must be used by any other SCTP endpoint?

If no then how to support 1 ASP 2 SG scenario since we need 2 unique ASSOCIATION establishment for the scenarion?

Regards,

Saraswati

Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business. --0-1129588597-1157520187=:99682-- --===============0138388918== 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 --===============0138388918==-- From sigtran-bounces@ietf.org Wed Sep 06 05:55:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKu7y-0003Ev-Jn; Wed, 06 Sep 2006 05:55:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKu7x-0003Eq-T8 for sigtran@ietf.org; Wed, 06 Sep 2006 05:55:25 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKu7w-000569-GM for sigtran@ietf.org; Wed, 06 Sep 2006 05:55:25 -0400 Received: from ns.pigworks.openss7.net (IDENT:2VotlbN7k5Is6hfGSD3mWxq/rFSomWMX@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k869tMD04014; Wed, 6 Sep 2006 03:55:22 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k869tKQ06335; Wed, 6 Sep 2006 03:55:20 -0600 Date: Wed, 6 Sep 2006 03:55:20 -0600 From: "Brian F. G. Bidulock" To: Saraswati Bose Message-ID: <20060906035520.A6186@openss7.org> Mail-Followup-To: Saraswati Bose , sigtran References: <20060906052307.9998.qmail@web54009.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060906052307.9998.qmail@web54009.mail.yahoo.com>; from saraswatibose@yahoo.com on Tue, Sep 05, 2006 at 10:23:07PM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sigtran Subject: [Sigtran] Re: SCTP: Multihoming Configuration 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: , Errors-To: sigtran-bounces@ietf.org Saraswati, Saraswati Bose wrote: (Tue, 05 Sep 2006 22:23:07) > > In ASP side Is the above a valid configuration? Yes, it is valid but not common. > If yes then wht about the fact tht the same transport address of one > multi homed endpoint (IP1+P1) must be used by any other SCTP endpoint? The only rule is that there can only be one associated between a pair of transport addresses (address list and port number). The rule is not violoated here because in the second instance IP1,P1 connects to IP2,P2. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 07 03:11:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLE2X-0006yF-4g; Thu, 07 Sep 2006 03:11:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLE2W-0006y6-2d for sigtran@ietf.org; Thu, 07 Sep 2006 03:11:08 -0400 Received: from levi.nethawkgroup.com ([194.100.156.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLE2T-00089C-Fj for sigtran@ietf.org; Thu, 07 Sep 2006 03:11:08 -0400 Received: from (194.100.156.10) by levi.nethawkgroup.com via smtp id 0dfc_f19c40f8_3e40_11db_8c04_003048245d96; Thu, 07 Sep 2006 10:17:39 +0300 Received: from [10.21.21.54] by jopo.nethawk.fi with HTTP; Thu, 7 Sep 2006 09:58:11 +0300 Date: Thu, 7 Sep 2006 12:28:11 +0530 Message-ID: <44351CC8000041BD@jopo.nethawk.fi> In-Reply-To: From: "Ambika Pr. Tripathy" To: sigtran@ietf.org, sigtran@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-4" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: bidulock@openss7.org Subject: [Sigtran] RE: Sigtran Digest, Vol 29, Issue 2 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: , Errors-To: sigtran-bounces@ietf.org Hi All, My impression on below setting is, ASP and one SG reside in the same device since one ASP end association contains IP2 as an alternative path which is used for the second association as the destination address. If i am not wrong, the association configuration at ASP end must matc= h, since the same association will communicate to SG 2. Br Ambika P. Tripathy >-- Original Message -- >From: sigtran-request@ietf.org >Subject: Sigtran Digest, Vol 29, Issue 2 >To: sigtran@ietf.org >Reply-To: sigtran@ietf.org >Date: Wed, 06 Sep 2006 12:00:22 -0400 > > >Send Sigtran mailing list submissions to > sigtran@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/sigtran >or, via email, send a message with subject or body 'help' to > sigtran-request@ietf.org > >You can reach the person managing the list at > sigtran-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Sigtran digest..." > > >Today's Topics: > > 1. SCTP: Multihoming Configuration (Saraswati Bose) > 2. Re: SCTP: Multihoming Configuration (Brian F. G. Bidulock) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Tue, 5 Sep 2006 22:23:07 -0700 (PDT) >From: Saraswati Bose >Subject: [Sigtran] SCTP: Multihoming Configuration >To: Brian Bidulock , sigtran >Message-ID: <20060906052307.9998.qmail@web54009.mail.yahoo.com> >Content-Type: text/plain; charset=3D"iso-8859-1" > >Hi Brian, > please suggest in the below. > > Endpoint A (ASP) Endpoint B (SG) > ASSO-1 > IPs=3D=3D IP1,IP2 IP=3D=3D I= P1' > Port=3D=3DP1 Port=3D=3D= P1' > > ASSO-2 > IPs=3D=3D IP1 IP=3D=3D= IP2 > Port=3D=3DP1 Port=3D=3D= P2 > > In ASP side Is the above a valid configuration? > If yes then wht about the fact tht the same transport address of one multi >homed endpoint (IP1+P1) must be used by any other SCTP endpoint? > > If no then how to support 1 ASP 2 SG scenario since we need 2 unique ASSOCIATION >establishment for the scenarion? > > Regards, > Saraswati > > > > >--------------------------------- >Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small= >Business. >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: http://www1.ietf.org/pipermail/sigtran/attachments/20060905/478167e= e/attachment.html > >------------------------------ > >Message: 2 >Date: Wed, 6 Sep 2006 03:55:20 -0600 >From: "Brian F. G. Bidulock" >Subject: [Sigtran] Re: SCTP: Multihoming Configuration >To: Saraswati Bose >Cc: sigtran >Message-ID: <20060906035520.A6186@openss7.org> >Content-Type: text/plain; charset=3Dus-ascii > >Saraswati, > >Saraswati Bose wrote: (Tue, 05 Sep 2006 22= :23:07) >> >> In ASP side Is the above a valid configuration? > >Yes, it is valid but not common. > >> If yes then wht about the fact tht the same transport address of one >> multi homed endpoint (IP1+P1) must be used by any other SCTP endpoi= nt? > >The only rule is that there can only be one associated between a pair of= >transport addresses (address list and port number). The rule is not vio= loated >here because in the second instance IP1,P1 connects to IP2,P2. > >--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 > > >End of Sigtran Digest, Vol 29, Issue 2 >************************************** Ambika Prasad Tripathy NetHawk Networks India Pvt. Ltd. Charampa, Bhadrak, Orissa India-756101 mob: +91-94373 07049 mail: ambika.tripathy@nethawkgroup.com tripaam@nethawk.fi web: www.nethawk.fi _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 07 10:03:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKT0-0001AV-Ko; Thu, 07 Sep 2006 10:02:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKSz-00015g-57 for sigtran@ietf.org; Thu, 07 Sep 2006 10:02:53 -0400 Received: from mx01.kapsch.net ([148.198.2.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLKSx-0008Kw-IK for sigtran@ietf.org; Thu, 07 Sep 2006 10:02:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Sep 2006 16:02:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Which ASP shall answer in Traffic Mode = Multicast? Thread-Index: AcbShkpK+UeqPfBnSEa1QKTFBAejyw== From: "Sedlak Michael" To: X-OriginalArrivalTime: 07 Sep 2006 14:02:46.0678 (UTC) FILETIME=[4BDBBB60:01C6D286] X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? 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="===============0126700745==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0126700745== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D286.4A057949" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D286.4A057949 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, After studying the rfc, I could not find an answer on how to proceed after a multicast-message was sent to several ASP. consider a case where 3 ASP are active in an AS, traffic mode type =3D multicast. When an SGP sends a message to all 3 ASP, how do the ASP know which one shall transport the message to the upper layer? And further on, which upper layer shall answer the message? What could be a real-life scenario where multicast is needed? thanks, Michael Sedlak Solution Architect | All-IP Data Core KapschCarrierCom The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof. ------_=_NextPart_001_01C6D286.4A057949 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Which ASP shall answer in Traffic Mode =3D Multicast?

Hello,

After studying the = rfc, I could not find an answer on how to proceed after a = multicast-message was sent to several ASP.

consider a case = where 3 ASP are active in an AS, traffic mode type =3D = multicast.
When an SGP sends = a message to all 3 ASP, how do the ASP know which one shall transport = the message to the upper layer? And further on, which upper layer shall = answer the message?

What could be a = real-life scenario where multicast is needed?

thanks,
Michael = Sedlak

Solution Architect = | All-IP Data Core
KapschCarrierCom

The information contained in this e-mail message is privileged and
confidential and is for the exclusive use of the addressee. The person
who receives this message and who is not the addressee, one of his
employees or an agent entitled to hand it over to the addressee, is
informed that he may not use, disclose or reproduce the contents thereof.

------_=_NextPart_001_01C6D286.4A057949-- --===============0126700745== 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 --===============0126700745==-- From sigtran-bounces@ietf.org Thu Sep 07 10:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKZM-0002pV-1U; Thu, 07 Sep 2006 10:09:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKZK-0002pQ-CW for sigtran@ietf.org; Thu, 07 Sep 2006 10:09:26 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLKZJ-0001M2-6N for sigtran@ietf.org; Thu, 07 Sep 2006 10:09:26 -0400 Received: by wr-out-0506.google.com with SMTP id i32so42513wra for ; Thu, 07 Sep 2006 07:09:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IzVsBXLm0zL0I/M3QBaEGIyHZNDsG8NvU20LTI3EC9DE00tFzPOO923ZydVaJBkaCERFzs6hojVT+o71heduA1xbQAjl5vDo/WMJsNj5J8yRhTR+AOpIYeEQFpMkrtpqKR4FlvPAjtzW7U2lq3Ip26gbDoXNJQwbnZ9jpsaFXtA= Received: by 10.90.100.6 with SMTP id x6mr198438agb; Thu, 07 Sep 2006 07:09:24 -0700 (PDT) Received: by 10.90.105.10 with HTTP; Thu, 7 Sep 2006 07:09:23 -0700 (PDT) Message-ID: Date: Thu, 7 Sep 2006 15:09:23 +0100 From: "Lee Dryburgh" To: "Sedlak Michael" Subject: Re: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org I was told from a very good source, assume that multicast (broadcast) did not exist in the specs! I was told that it is never used! So I'd be interested if other SigTran folks had something else to say on the topic. Regards Lee On 07/09/06, Sedlak Michael wrote: > > > > Hello, > > After studying the rfc, I could not find an answer on how to proceed after a > multicast-message was sent to several ASP. > > consider a case where 3 ASP are active in an AS, traffic mode type = > multicast. > When an SGP sends a message to all 3 ASP, how do the ASP know which one > shall transport the message to the upper layer? And further on, which upper > layer shall answer the message? > > What could be a real-life scenario where multicast is needed? > > > thanks, > Michael Sedlak > > Solution Architect | All-IP Data Core > KapschCarrierCom _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 07 10:16:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKg7-0005xu-Sn; Thu, 07 Sep 2006 10:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKg7-0005xp-5q for sigtran@ietf.org; Thu, 07 Sep 2006 10:16:27 -0400 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 1GLKg4-0002oj-Kq for sigtran@ietf.org; Thu, 07 Sep 2006 10:16:27 -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 k87EGGjd020983 for ; Thu, 7 Sep 2006 10:16:17 -0400 From: "Barry Nagelberg" To: Subject: RE: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? Date: Thu, 7 Sep 2006 10:18:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Score: 1.5 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: , Errors-To: sigtran-bounces@ietf.org Lee, If your source is correct, then this is a sad comment on the RFC. Nevertheless, if it's in the RFC, then I would say ignore it at your peril. Someone may use it, and then anyone who doesn't will be non-compliant and non-interoperable. Barry Nagelberg Adax, Inc. -----Original Message----- From: Lee Dryburgh [mailto:dryburghl@gmail.com] Sent: Thursday, September 07, 2006 10:09 AM To: Sedlak Michael Cc: sigtran@ietf.org Subject: Re: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? I was told from a very good source, assume that multicast (broadcast) did not exist in the specs! I was told that it is never used! So I'd be interested if other SigTran folks had something else to say on the topic. Regards Lee On 07/09/06, Sedlak Michael wrote: > > > > Hello, > > After studying the rfc, I could not find an answer on how to proceed after a > multicast-message was sent to several ASP. > > consider a case where 3 ASP are active in an AS, traffic mode type = > multicast. > When an SGP sends a message to all 3 ASP, how do the ASP know which one > shall transport the message to the upper layer? And further on, which upper > layer shall answer the message? > > What could be a real-life scenario where multicast is needed? > > > thanks, > Michael Sedlak > > Solution Architect | All-IP Data Core > KapschCarrierCom _______________________________________________ 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 Thu Sep 07 10:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKiO-0006uN-LC; Thu, 07 Sep 2006 10:18:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKiN-0006ss-Ft for sigtran@ietf.org; Thu, 07 Sep 2006 10:18:47 -0400 Received: from us-wkf-fwmain.comverse.com ([63.64.185.250] helo=us-wkf-interscan1.comverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLKiL-0003NU-4r for sigtran@ietf.org; Thu, 07 Sep 2006 10:18:47 -0400 Received: from us-nj-mail1.comverse.com (localhost.localdomain [127.0.0.1]) by us-wkf-interscan1.comverse.com (8.13.1/8.13.1) with ESMTP id k87EIZjC022916; Thu, 7 Sep 2006 10:18:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? Date: Thu, 7 Sep 2006 10:18:35 -0400 Message-ID: <849535E338E99741B7F7413F73253EDB04A8E2BF@us-nj-mail1.comverse.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? thread-index: AcbShkpK+UeqPfBnSEa1QKTFBAejywAAb7/g From: "Haresign Lincoln" To: "Sedlak Michael" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1323161376==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1323161376== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D288.81A181A7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D288.81A181A7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One possible use for multicast would be if you are trying to build some redundancy mechanism in. For example: =20 A message gets sent to all ASPs within an AS. By some agreed mechanism within the AS, the ASPs would know who is responsible for responding to that message. However, if a particular ASP died in the middle of a call, all the state was being maintained by the other ASPs, so another ASP could take over the call. =20 This is probably over engineered, and we are not doing it, but it would be one scenario that you might use this capability. =20 Regards, Lincoln ________________________________ From: Sedlak Michael [mailto:michael.sedlak@kapsch.net]=20 Sent: Thursday, September 07, 2006 10:03 AM To: sigtran@ietf.org Subject: [Sigtran] Which ASP shall answer in Traffic Mode =3D Multicast? Hello,=20 After studying the rfc, I could not find an answer on how to proceed after a multicast-message was sent to several ASP.=20 consider a case where 3 ASP are active in an AS, traffic mode type =3D multicast.=20 When an SGP sends a message to all 3 ASP, how do the ASP know which one shall transport the message to the upper layer? And further on, which upper layer shall answer the message? What could be a real-life scenario where multicast is needed?=20 thanks,=20 Michael Sedlak=20 Solution Architect | All-IP Data Core=20 KapschCarrierCom=20 The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof. ------_=_NextPart_001_01C6D288.81A181A7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Which ASP shall answer in Traffic Mode =3D = Multicast?

One=20 possible use for multicast would be if you are trying to build some = redundancy=20 mechanism in. For example:

A=20 message gets sent to all ASPs within an AS. By some agreed = mechanism=20 within the AS, the ASPs would know who is responsible for responding to = that=20 message. However, if a particular ASP died in the middle of a = call, all=20 the state was being maintained by the other ASPs, so another ASP could = take over=20 the call.

This=20 is probably over engineered, and we are not doing it, but it would be = one=20 scenario that you might use this capability.

Regards,

Lincoln

From: Sedlak Michael=20 [mailto:michael.sedlak@kapsch.net]
Sent: Thursday, September = 07, 2006=20 10:03 AM
To: sigtran@ietf.org
Subject: [Sigtran] = Which ASP=20 shall answer in Traffic Mode =3D Multicast?

Hello, =

After studying the = rfc, I could not=20 find an answer on how to proceed after a multicast-message was sent to = several=20 ASP.

consider a case where = 3 ASP are=20 active in an AS, traffic mode type =3D multicast. =
When an SGP sends a message to = all 3 ASP, how=20 do the ASP know which one shall transport the message to the upper = layer? And=20 further on, which upper layer shall answer the = message?

What could be a = real-life scenario=20 where multicast is needed?

thanks, =
Michael Sedlak =

Solution Architect | = All-IP Data=20 Core
KapschCarrierCom

The information contained in this e-mail message is privileged=20 and
confidential and is for the exclusive use of the addressee. The=20 person
who receives this message and who is not the addressee, one of = his
employees or an agent entitled to hand it over to the addressee,=20 is
informed that he may not use, disclose or reproduce the contents=20 thereof.

------_=_NextPart_001_01C6D288.81A181A7-- --===============1323161376== 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 --===============1323161376==-- From sigtran-bounces@ietf.org Thu Sep 07 10:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKoC-0000BR-Si; Thu, 07 Sep 2006 10:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKoB-0000BI-Tt for sigtran@ietf.org; Thu, 07 Sep 2006 10:24:47 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLKoA-0004Rt-Nj for sigtran@ietf.org; Thu, 07 Sep 2006 10:24:47 -0400 Received: by wr-out-0506.google.com with SMTP id i32so47260wra for ; Thu, 07 Sep 2006 07:24:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Qx+gnAwbzc1wI60hYRP4oLF6hzRFl37eA/La13+R/p0faBhERguHdKgpAdV9DYXTfrxfiBTpdpKxNulbHE8A3A5lm88Ggq5O7sWeZ0OQLrBixdynjQoC8oB3G8Ij1rj79ZewDrAJzBd+zh+GFwJhJqbVZYwSSY6k8oIWTSOAATE= Received: by 10.90.79.6 with SMTP id c6mr209695agb; Thu, 07 Sep 2006 07:24:46 -0700 (PDT) Received: by 10.90.105.10 with HTTP; Thu, 7 Sep 2006 07:24:43 -0700 (PDT) Message-ID: Date: Thu, 7 Sep 2006 15:24:43 +0100 From: "Lee Dryburgh" To: "Haresign Lincoln" Subject: Re: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? In-Reply-To: <849535E338E99741B7F7413F73253EDB04A8E2BF@us-nj-mail1.comverse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <849535E338E99741B7F7413F73253EDB04A8E2BF@us-nj-mail1.comverse.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org On 07/09/06, Haresign Lincoln wrote: > > > One possible use for multicast would be if you are trying to build some > redundancy mechanism in. For example: > > A message gets sent to all ASPs within an AS. By some agreed mechanism > within the AS, the ASPs would know who is responsible for responding to that Added complexity comes to mind. But I am sure this has all been thrashed out many times in the past. > message. However, if a particular ASP died in the middle of a call, all the > state was being maintained by the other ASPs, so another ASP could take over > the call. Ditto. > > This is probably over engineered, and we are not doing it, but it would be > one scenario that you might use this capability. > Does any vendor actually provide the ASP broadcast option? Regards Lee _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 07 10:29:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKsE-00013T-UU; Thu, 07 Sep 2006 10:28:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKsD-00013O-QR for sigtran@ietf.org; Thu, 07 Sep 2006 10:28:57 -0400 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 1GLKsC-00059I-9s for sigtran@ietf.org; Thu, 07 Sep 2006 10:28:57 -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 k87ESqjd021048 for ; Thu, 7 Sep 2006 10:28:52 -0400 From: "Barry Nagelberg" To: Subject: RE: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? Date: Thu, 7 Sep 2006 10:31:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Score: 1.5 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Lee, Adax supports it on the SGP. Barry Nagelberg Adax, Inc. -----Original Message----- From: Lee Dryburgh [mailto:dryburghl@gmail.com] Sent: Thursday, September 07, 2006 10:25 AM To: Haresign Lincoln Cc: sigtran@ietf.org Subject: Re: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? On 07/09/06, Haresign Lincoln wrote: > > > One possible use for multicast would be if you are trying to build some > redundancy mechanism in. For example: > > A message gets sent to all ASPs within an AS. By some agreed mechanism > within the AS, the ASPs would know who is responsible for responding to that Added complexity comes to mind. But I am sure this has all been thrashed out many times in the past. > message. However, if a particular ASP died in the middle of a call, all the > state was being maintained by the other ASPs, so another ASP could take over > the call. Ditto. > > This is probably over engineered, and we are not doing it, but it would be > one scenario that you might use this capability. > Does any vendor actually provide the ASP broadcast option? Regards Lee _______________________________________________ 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 Thu Sep 07 10:48:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLLAh-0000FL-JE; Thu, 07 Sep 2006 10:48:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLLAg-0000CW-PI for sigtran@ietf.org; Thu, 07 Sep 2006 10:48:02 -0400 Received: from wr-out-0506.google.com ([64.233.184.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLL0V-0006MU-29 for sigtran@ietf.org; Thu, 07 Sep 2006 10:37:32 -0400 Received: by wr-out-0506.google.com with SMTP id i32so50695wra for ; Thu, 07 Sep 2006 07:37:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hMsBOD3RazaNuxoSapDsTtiua3iXcHC0EA44E0QDeO+ePa37+EDqoR4y/xT2FcwGra4F3Plp9JvQT7ZDhCHW7syMtV8tOrd+52Jc+Ap6u4PR48uu7cWw4WoIayY1xLSUxzfXGXV8vCYc1w04wMCezwezXrKDvalY1jW1Jv5Q7FY= Received: by 10.90.78.1 with SMTP id a1mr216816agb; Thu, 07 Sep 2006 07:37:30 -0700 (PDT) Received: by 10.90.105.10 with HTTP; Thu, 7 Sep 2006 07:37:30 -0700 (PDT) Message-ID: Date: Thu, 7 Sep 2006 15:37:30 +0100 From: "Lee Dryburgh" To: "Barry Nagelberg" Subject: Re: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org That is were the little effort is. Anybody support it at the real end (AS/MGC)? Regards Lee On 07/09/06, Barry Nagelberg wrote: > Lee, > > Adax supports it on the SGP. > > Barry Nagelberg > Adax, Inc. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 07 12:53:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLN7Q-0001O7-A8; Thu, 07 Sep 2006 12:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLN7O-0001Ny-O5 for sigtran@ietf.org; Thu, 07 Sep 2006 12:52:46 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLN7N-0002Wt-A3 for sigtran@ietf.org; Thu, 07 Sep 2006 12:52:46 -0400 Received: from ns.pigworks.openss7.net (IDENT:3/dc6H6hz3r1zElWYjcCMnhjP790XG8K@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k87GqiD16832; Thu, 7 Sep 2006 10:52:44 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k87GqhE28140; Thu, 7 Sep 2006 10:52:43 -0600 Date: Thu, 7 Sep 2006 10:52:43 -0600 From: "Brian F. G. Bidulock" To: Sedlak Michael Subject: Re: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? Message-ID: <20060907105243.A27971@openss7.org> Mail-Followup-To: Sedlak Michael , sigtran@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from michael.sedlak@kapsch.net on Thu, Sep 07, 2006 at 04:02:43PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Errors-To: sigtran-bounces@ietf.org Sedlak, I presume that you are speaking of broadcast traffic mode under, say, M3UA, rather that IP "broadcast" or "multicast". Broadcast is a mechanism that permits all other traffic modes independent of the SG. The ASPs serving an AS decide between themselves which one will handle a given message. In a typical arrangement, each ASP serving the AS would be responsible for active processing of 1 range of SLS (M3UA) and responsible for checkpointing on the remaining ranges of SLS. ASPs heartbeat and checkpoint between each other or rely upon ASP Failure indications from the SGP to detect a failed ASP. When an ASP fails, the active ASP in the AS responsible for acting as backup to the failed ASP takes starts actively processing messages rather than just check pointing for the range of SLS for the failed ASP. Of course, other arrangments are possible. Active-Standby and Loadshare can also be preformed by ASPs in broadcast mode. The reason that you do not see much mention of this in the RFCs is because the RFCs do not dictate how ASPs in a broadcast AS behave because ASP-ASP communication and coordination is out of scope. From the ASP-SG protocol perspective, the SG simply sends the message to each ASP serving the AS and does not dictate who processes it. Hope that helps. --brian Sedlak Michael wrote: (Thu, 07 Sep 2006 16:02:43) > > Hello, > > After studying the rfc, I could not find an answer on how to proceed > after a multicast-message was sent to several ASP. > > consider a case where 3 ASP are active in an AS, traffic mode type = > multicast. > When an SGP sends a message to all 3 ASP, how do the ASP know which > one shall transport the message to the upper layer? And further on, > which upper layer shall answer the message? > > What could be a real-life scenario where multicast is needed? > > thanks, > Michael Sedlak > > Solution Architect | All-IP Data Core > KapschCarrierCom > > The information contained in this e-mail message is privileged and > confidential and is for the exclusive use of the addressee. The person > who receives this message and who is not the addressee, one of his > employees or an agent entitled to hand it over to the addressee, is > informed that he may not use, disclose or reproduce the contents > thereof. > _______________________________________________ > 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 Sep 07 14:02:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLOC8-00047z-5z; Thu, 07 Sep 2006 14:01:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLOC6-00046l-KR for sigtran@ietf.org; Thu, 07 Sep 2006 14:01:42 -0400 Received: from mail1.adax.com ([208.201.231.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLOC5-0005Vv-5s for sigtran@ietf.org; Thu, 07 Sep 2006 14:01:42 -0400 Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 45ED83E2F; Thu, 7 Sep 2006 11:20:01 -0700 (PDT) Received: by adax (Postfix, from userid 243) id E20FB38002; Thu, 7 Sep 2006 10:59:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id E1807C072; Thu, 7 Sep 2006 10:59:29 -0700 (PDT) Date: Thu, 7 Sep 2006 10:59:29 -0700 (PDT) From: Chris Benson X-X-Sender: cbenson@adax To: sigtran@ietf.org Subject: Re: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Barry Nagelberg 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: , Errors-To: sigtran-bounces@ietf.org Lee, I am in another department of Barry's company, and we support broadcast mode at an AS implementation of M3UA. The individual M3UA users (MTP3-users) of each ASP are expected to co-ordinate ownership etc. This AS broadcast mechanism is just a vehicle to all instances of the higher layer at each ASP. You asked whether any vendor supported AS broadcast. Adax does. You are probably more interested in an example usage, and I know of no actual usage of broadcast by our customers, except when they are testing for protocol specification conformance ;-) With thanks, from Chris Benson, Adax, Inc. On Thu, 7 Sep 2006, Lee Dryburgh wrote: > That is were the little effort is. Anybody support it at the real end (AS/MGC)? > > Regards > > Lee > > On 07/09/06, Barry Nagelberg wrote: > > Lee, > > > > Adax supports it on the SGP. > > > > Barry Nagelberg > > Adax, Inc. > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > -- Christopher Benson, Software Engineer, Adax Inc., Berkeley, California, USA. cbenson@adax.com +1 510 548-7047 ext. 189 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 07 14:11:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLOLq-0008Hs-VR; Thu, 07 Sep 2006 14:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLOLp-0008Hn-LW for sigtran@ietf.org; Thu, 07 Sep 2006 14:11:45 -0400 Received: from qb-out-0506.google.com ([72.14.204.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLOLo-0007Oy-FB for sigtran@ietf.org; Thu, 07 Sep 2006 14:11:45 -0400 Received: by qb-out-0506.google.com with SMTP id p36so64qba for ; Thu, 07 Sep 2006 11:11:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ULmCoIOxKZBQgIv4HEgVcH1WwreocOet3M4Bh5oWVsuwhJvsN7vlSOg78BfT8ioVgmEPzFb1ifMHinki/1xkBPEtNfPJBCUbuxt/Q3iY07iSVSN75tqKshmZuEFbt4CdQWnKGTiC0VYBlX0849OJzDQryQYa2bxXTDiU1+AUOmI= Received: by 10.90.100.6 with SMTP id x6mr404548agb; Thu, 07 Sep 2006 11:11:43 -0700 (PDT) Received: by 10.90.105.10 with HTTP; Thu, 7 Sep 2006 11:11:43 -0700 (PDT) Message-ID: Date: Thu, 7 Sep 2006 19:11:43 +0100 From: "Lee Dryburgh" To: "Chris Benson" Subject: Re: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References:

X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Chris, Thanks for the interesting info. As you've pre-guessed I'd be interested to know if anyone knows of a customer using it? Regards Lee On 07/09/06, Chris Benson wrote: > Lee, > > I am in another department of Barry's company, and we support > broadcast mode at an AS implementation of M3UA. The individual > M3UA users (MTP3-users) of each ASP are expected to co-ordinate > ownership etc. This AS broadcast mechanism is just a vehicle to > all instances of the higher layer at each ASP. > > You asked whether any vendor supported AS broadcast. Adax does. > You are probably more interested in an example usage, and I > know of no actual usage of broadcast by our customers, except > when they are testing for protocol specification conformance ;-) > > With thanks, from Chris Benson, > Adax, Inc. > > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Sep 08 01:24:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLYqD-0003Lb-0G; Fri, 08 Sep 2006 01:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLYqC-0003LT-32 for sigtran@ietf.org; Fri, 08 Sep 2006 01:23:48 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLYq9-0007qU-IQ for sigtran@ietf.org; Fri, 08 Sep 2006 01:23:48 -0400 Received: by py-out-1112.google.com with SMTP id e30so493865pya for ; Thu, 07 Sep 2006 22:23:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ZI6H2e88bShN8PEz+a2tGBsiADeDTNqPnZHZoEh2VUgBJAyocuZKKUVRo6qCr0wSSTOxVzEX9CX7PEBKodyxjcMn859QaSHqfmjq/4CR9VhKzbu0nxkUGqGv7OpY7qY5kciMaC9NA3XxL99C38yjxBbbVEq3GcExdCPz14oqBT8= Received: by 10.35.76.10 with SMTP id d10mr2110010pyl; Thu, 07 Sep 2006 22:23:45 -0700 (PDT) Received: by 10.35.75.10 with HTTP; Thu, 7 Sep 2006 22:23:44 -0700 (PDT) Message-ID: Date: Fri, 8 Sep 2006 10:53:44 +0530 From: "Saurabh Jain" To: bidulock@openss7.org, "Sedlak Michael" , sigtran@ietf.org Subject: Re: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? In-Reply-To: <20060907105243.A27971@openss7.org> MIME-Version: 1.0 References: <20060907105243.A27971@openss7.org> X-Spam-Score: 0.2 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0063719597==" Errors-To: sigtran-bounces@ietf.org --===============0063719597== Content-Type: multipart/alternative; boundary="----=_Part_41253_8757059.1157693024959" ------=_Part_41253_8757059.1157693024959 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have query for Broadcast mode in SUA. For M3UA, Broadcast mode : the role of SG would be to Broadcast messages to all ASPs. the role at ASPs would be to accept the message. Now thru inter-ASP communication, one of the ASPs may process it and rest would drop it, or all ASPs may process it. However, will Broadcast mode also be applicable for SUA Class 2 Messages? Potential issues: - This would mean that for a single SCCP Connect request from User, SUA would have to maintain multiple connections, one with each Peer ASP. - What happens if 1 out of multiple Peer ASPs does not send a COAK, (we will not be able to send further messages to this ASP for this connection) - What happens if a new ASP becomes active, (and some Class 2 connections had already been established with earlier ASPs), we will not be able to send data for earlier connections towards this new ASP. RFC 3868, only explains Broadcast Mode in general (in section 4.3.4.3. ASP Active Procedures) *"The algorithm at the SGP for broadcasting traffic within an AS to all the active ASPs is a simple broadcast algorithm, where every message is sent to each of the active ASPs."* If we allow Broadcast Mode for Class 2 Messages then there would be a slight conflict with the above section. rgds Saurabh On 9/7/06, Brian F. G. Bidulock wrote: > > Sedlak, > > I presume that you are speaking of broadcast traffic mode under, say, > M3UA, rather that IP "broadcast" or "multicast". Broadcast is a > mechanism that permits all other traffic modes independent of the SG. > The ASPs serving an AS decide between themselves which one will handle > a given message. In a typical arrangement, each ASP serving the AS > would be responsible for active processing of 1 range of SLS (M3UA) > and responsible for checkpointing on the remaining ranges of SLS. ASPs > heartbeat and checkpoint between each other or rely upon ASP Failure > indications from the SGP to detect a failed ASP. When an ASP fails, > the active ASP in the AS responsible for acting as backup to the failed > ASP takes starts actively processing messages rather than just check > pointing for the range of SLS for the failed ASP. > > Of course, other arrangments are possible. Active-Standby and Loadshare > can also be preformed by ASPs in broadcast mode. > > The reason that you do not see much mention of this in the RFCs is because > the RFCs do not dictate how ASPs in a broadcast AS behave because ASP-ASP > communication and coordination is out of scope. From the ASP-SG protocol > perspective, the SG simply sends the message to each ASP serving the AS > and > does not dictate who processes it. > > Hope that helps. > > --brian > > Sedlak Michael wrote: (Thu, 07 Sep 2006 16:02:43) > > > > Hello, > > > > After studying the rfc, I could not find an answer on how to > proceed > > after a multicast-message was sent to several ASP. > > > > consider a case where 3 ASP are active in an AS, traffic mode type > = > > multicast. > > When an SGP sends a message to all 3 ASP, how do the ASP know > which > > one shall transport the message to the upper layer? And further > on, > > which upper layer shall answer the message? > > > > What could be a real-life scenario where multicast is needed? > > > > thanks, > > Michael Sedlak > > > > Solution Architect | All-IP Data Core > > KapschCarrierCom > > > > The information contained in this e-mail message is privileged and > > confidential and is for the exclusive use of the addressee. The > person > > who receives this message and who is not the addressee, one of his > > employees or an agent entitled to hand it over to the addressee, is > > informed that he may not use, disclose or reproduce the > contents > > thereof. > > > _______________________________________________ > > 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 > ------=_Part_41253_8757059.1157693024959 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi,

I have query for Broadcast mode in SUA.

For M3UA, Broadcast mode : the role of SG would be to Broadcast messages to all ASPs.

the role at ASPs would be to accept the message.

Now thru inter-ASP communication, one of the ASPs may process it and rest would drop it,

or all ASPs may process it.

However, will Broadcast mode also be applicable for SUA Class 2 Messages?

Potential issues:

This would mean that for a single SCCP Connect request from User, SUA would have to maintain multiple connections, one with each Peer ASP.
What happens if 1 out of multiple Peer ASPs does not send a COAK, (we will not be able to send further messages to this ASP for this connection)
What happens if a new ASP becomes active, (and some Class 2 connections had already been established with earlier ASPs), we will not be able to send data for earlier connections towards this new ASP.

RFC 3868, only explains Broadcast Mode in general (in section 4.3.4.3. ASP Active Procedures)

"The algorithm at the SGP for broadcasting traffic within an AS to all the active ASPs is a simple broadcast algorithm, where every message is sent to each of the active ASPs."

If we allow Broadcast Mode for Class 2 Messages then there would be a slight conflict with the above section.

rgds

Saurabh

On 9/7/06, Brian F. G. Bidulock <bidulock@openss7.org> wrote:

Sedlak,

I presume that you are speaking of broadcast traffic mode under, say,
M3UA, rather that IP "broadcast" or "multicast".  Broadcast is a
mechanism that permits all other traffic modes independent of the SG.
The ASPs serving an AS decide between themselves which one will handle
a given message.  In a typical arrangement, each ASP serving the AS
would be responsible for active processing of 1 range of SLS (M3UA)
and responsible for checkpointing on the remaining ranges of SLS.  ASPs
heartbeat and checkpoint between each other or rely upon ASP Failure
indications from the SGP to detect a failed ASP.  When an ASP fails,
the active ASP in the AS responsible for acting as backup to the failed
ASP takes starts actively processing messages rather than just check
pointing for the range of SLS for the failed ASP.

Of course, other arrangments are possible.  Active-Standby and Loadshare
can also be preformed by ASPs in broadcast mode.

The reason that you do not see much mention of this in the RFCs is because
the RFCs do not dictate how ASPs in a broadcast AS behave because ASP-ASP
communication and coordination is out of scope.  From the ASP-SG protocol
perspective, the SG simply sends the message to each ASP serving the AS and
does not dictate who processes it.

Hope that helps.

--brian

Sedlak Michael wrote:                      (Thu, 07 Sep 2006 16:02:43)
>
>    Hello,
>
>    After  studying  the rfc, I could not find an answer on how to proceed
>    after a multicast-message was sent to several ASP.
>
>    consider  a  case where 3 ASP are active in an AS, traffic mode type =
>    multicast.
>    When  an  SGP  sends a message to all 3 ASP, how do the ASP know which
>    one  shall  transport  the message to the upper layer? And further on,
>    which upper layer shall answer the message?
>
>    What could be a real-life scenario where multicast is needed?
>
>    thanks,
>    Michael Sedlak
>
>    Solution Architect | All-IP Data Core
>    KapschCarrierCom
>
>    The information contained in this e-mail message is privileged and
>    confidential and is for the exclusive use of the addressee. The person
>    who receives this message and who is not the addressee, one of his
>    employees or an agent entitled to hand it over to the addressee, is
>    informed  that  he  may  not  use,  disclose or reproduce the contents
>    thereof.

> _______________________________________________
> 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

------=_Part_41253_8757059.1157693024959-- --===============0063719597== 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 --===============0063719597==-- From sigtran-bounces@ietf.org Fri Sep 08 03:07:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLaRB-0003Ub-TE; Fri, 08 Sep 2006 03:06:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLaRA-0003UW-GN for sigtran@ietf.org; Fri, 08 Sep 2006 03:06:04 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLaR9-0006Nv-3P for sigtran@ietf.org; Fri, 08 Sep 2006 03:06:04 -0400 Received: from ns.pigworks.openss7.net (IDENT:9cjxZOUwIUhUWqLSJSK3U46qPtbql0eq@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k88761D06131; Fri, 8 Sep 2006 01:06:01 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k88761e08088; Fri, 8 Sep 2006 01:06:01 -0600 Date: Fri, 8 Sep 2006 01:06:01 -0600 From: "Brian F. G. Bidulock" To: Saurabh Jain Subject: Re: [Sigtran] Which ASP shall answer in Traffic Mode = Multicast? Message-ID: <20060908010601.A7531@openss7.org> Mail-Followup-To: Saurabh Jain , Sedlak Michael , sigtran@ietf.org References: <20060907105243.A27971@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from saur99jain@gmail.com on Fri, Sep 08, 2006 at 10:53:44AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: sigtran-bounces@ietf.org Saurabh, Saurabh Jain wrote: (Fri, 08 Sep 2006 10:53:44) > > Potential issues: > > * This would mean that for a single SCCP Connect request from User, > SUA would have to maintain multiple connections, one with each > Peer ASP. No, just one connection with the AS. > * What happens if 1 out of multiple Peer ASPs does not send a COAK, > (we will not be able to send further messages to this ASP for this > connection) Why not? All messages can still be sent to all active ASPs in the AS. > * What happens if a new ASP becomes active, (and some Class 2 > connections had already been established with earlier ASPs), we > will not be able to send data for earlier connections towards this > new ASP. Again, why not? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Sep 08 15:43:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLmFL-0004oY-Sq; Fri, 08 Sep 2006 15:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLmFK-0004jn-B3 for sigtran@ietf.org; Fri, 08 Sep 2006 15:42:38 -0400 Received: from web50607.mail.yahoo.com ([206.190.38.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLm8I-0004Gi-Sa for sigtran@ietf.org; Fri, 08 Sep 2006 15:35:28 -0400 Received: (qmail 52418 invoked by uid 60001); 8 Sep 2006 19:35:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=l2GwM3/p3FzPUNujWFefTW7GPVi6orgFFlJwp8ycwpQ/UAgnqJvUsdM38MgPMEn7f7qHm/3eTqfiWLGddsa0ynGkROl3OK03UpCWbfipUBlxLtNJYhzerGfDd6iouDzycJ25YWwFeff1Jd7RqiANABWwKCV25+tvFFDe16IgsZE= ; Message-ID: <20060908193502.52416.qmail@web50607.mail.yahoo.com> Received: from [62.217.232.72] by web50607.mail.yahoo.com via HTTP; Fri, 08 Sep 2006 12:35:00 PDT Date: Fri, 8 Sep 2006 12:35:00 -0700 (PDT) From: IULIAN LASCU To: sigtran@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sigtran] M2UA terminology 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: , Errors-To: sigtran-bounces@ietf.org Hi all, I'm working to define a network having some M2UA SG implementations and one who resides on the MGC side and I need some help to clarify the structure of the network - so here's my question, maybe already answered. Which will be the correct interpretation for the Application Server term (rfc3331) at MCG, considering the following situations [MGC]---[SG]------------[SEP] \ / \--[STP]-/ AS <=> signaling links set (direct signaling route to SEP) or AS <=> all the signaling routes towards SEP or [MGC]------[SG1]----[STP1]---SS7 network behind STP1 \-----[SG2]----[STP2]---SS7 network behind STP2 AS = MGC and in this case a SG could be used only for a specific part of the network described at MGC and following this logic the SEP and STP from the first case should be reached by separate SGs. Thanks Iulian __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Sep 08 22:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLstg-0001Z2-9e; Fri, 08 Sep 2006 22:48:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLste-0001Y4-NJ for sigtran@ietf.org; Fri, 08 Sep 2006 22:48:42 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLsgf-0003hm-Pn for sigtran@ietf.org; Fri, 08 Sep 2006 22:35:19 -0400 Received: from ns.pigworks.openss7.net (IDENT:BWg416efF2E+92HHHKizJWrmqGT5FQxa@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k892ZGD02551; Fri, 8 Sep 2006 20:35:16 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k892ZGc21380; Fri, 8 Sep 2006 20:35:16 -0600 Date: Fri, 8 Sep 2006 20:35:16 -0600 From: "Brian F. G. Bidulock" To: IULIAN LASCU Subject: Re: [Sigtran] M2UA terminology Message-ID: <20060908203516.A21270@openss7.org> Mail-Followup-To: IULIAN LASCU , sigtran@ietf.org References: <20060908193502.52416.qmail@web50607.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060908193502.52416.qmail@web50607.mail.yahoo.com>; from iulian_lascu@yahoo.com on Fri, Sep 08, 2006 at 12:35:00PM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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: , Errors-To: sigtran-bounces@ietf.org IULIAN, The SS7 network side of an M2UA SG is simply SS7 signalling links. How the signalling links are interpreted at the MGC depepends on how there are configured for use by the MTP stack there. M2UA simply provides, if you will, "remote" access to the SS7 signalling link termination at the SG. So, from the SS7 network perpective, your first diagram is no different than, say: [SEP]------------[SEP] \ / \--[STP]-/ The SEP just happens to be functionally decomposed into MGC and SG. Hope that helps. --brian IULIAN LASCU wrote: (Fri, 08 Sep 2006 12:35:00) > Hi all, > > I'm working to define a network having some M2UA SG > implementations and one who resides on the MGC side > and I need some help to clarify the structure of the > network - so here's my question, maybe already > answered. > > Which will be the correct interpretation for the > Application Server term (rfc3331) at MCG, considering > the following situations > > [MGC]---[SG]------------[SEP] > \ / > \--[STP]-/ > > AS <=> signaling links set (direct signaling route to > SEP) > or > AS <=> all the signaling routes towards SEP > or > [MGC]------[SG1]----[STP1]---SS7 network behind STP1 > \-----[SG2]----[STP2]---SS7 network behind STP2 > AS = MGC and in this case a SG could be used only for > a specific part of the network described at MGC and > following this logic the SEP and STP from the first > case should be reached by separate SGs. > > Thanks > Iulian > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Sat Sep 09 15:17:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM8Jp-0006ph-Gk; Sat, 09 Sep 2006 15:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM8Jo-0006pZ-AF for sigtran@ietf.org; Sat, 09 Sep 2006 15:16:44 -0400 Received: from web50615.mail.yahoo.com ([206.190.39.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GM8Ji-0008Gh-Iw for sigtran@ietf.org; Sat, 09 Sep 2006 15:16:44 -0400 Received: (qmail 46150 invoked by uid 60001); 9 Sep 2006 19:16:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=icuwf191kcCcvEnnPy3CnFP+GRqgc+z4FMM/zpDfX2BMr4w6O21O23+8Av6uSunOJeKqsVEYV/3ZH2s/D+vRfToIbPCKu6N2Zi9ghOjR3kwZWuDvO3OI1AsdjkXeWK17mReX5mJv9X30n0QmlI577s68Z69SMG/NRV/u3/c/5RM= ; Message-ID: <20060909191638.46148.qmail@web50615.mail.yahoo.com> Received: from [62.217.232.76] by web50615.mail.yahoo.com via HTTP; Sat, 09 Sep 2006 12:16:38 PDT Date: Sat, 9 Sep 2006 12:16:38 -0700 (PDT) From: IULIAN LASCU Subject: Re: [Sigtran] M2UA terminology To: bidulock@openss7.org In-Reply-To: <20060908203516.A21270@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Brian, I see from your answer that the AS isn't related with any MTP3 entity as a signaling link, signaling link set or with the signaling routes towars a certain PS. It could be, but it's only a particular case. In "real terms" the AS would be the part of MGC MTP3 which a SG could see by the means of its configuration. A limit at the SG for the number of InterfaceIds per AS at a value of 16 (in my case, value which missconduct me to make the analogy AS-signaling link set) signifies only that a SG of this type could treat only that amount of signalings links(16) for the MGC. thanks Iulian --- "Brian F. G. Bidulock" wrote: > IULIAN, > > The SS7 network side of an M2UA SG is simply SS7 > signalling links. How the signalling links are > interpreted at the MGC depepends on how there are > configured for use by the MTP stack there. > > M2UA simply provides, if you will, "remote" access > to > the SS7 signalling link termination at the SG. > > So, from the SS7 network perpective, your first > diagram > is no different than, say: > > [SEP]------------[SEP] > \ / > \--[STP]-/ > > The SEP just happens to be functionally decomposed > into > MGC and SG. > > Hope that helps. > > --brian > > > IULIAN LASCU wrote: (Fri, 08 Sep 2006 > 12:35:00) > > Hi all, > > > > I'm working to define a network having some M2UA > SG > > implementations and one who resides on the MGC > side > > and I need some help to clarify the structure of > the > > network - so here's my question, maybe already > > answered. > > > > Which will be the correct interpretation for the > > Application Server term (rfc3331) at MCG, > considering > > the following situations > > > > [MGC]---[SG]------------[SEP] > > \ / > > \--[STP]-/ > > > > AS <=> signaling links set (direct signaling route > to > > SEP) > > or > > AS <=> all the signaling routes towards SEP > > or > > [MGC]------[SG1]----[STP1]---SS7 network behind > STP1 > > \-----[SG2]----[STP2]---SS7 network behind > STP2 > > AS = MGC and in this case a SG could be used only > for > > a specific part of the network described at MGC > and > > following this logic the SEP and STP from the > first > > case should be reached by separate SGs. > > > > Thanks > > Iulian > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Sep 11 19:10:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMuuL-00005a-FY; Mon, 11 Sep 2006 19:09:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMuuI-0008VU-W1 for sigtran@ietf.org; Mon, 11 Sep 2006 19:09:38 -0400 Received: from hicks.ciena.com ([63.118.34.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMuhs-0000GY-7W for sigtran@ietf.org; Mon, 11 Sep 2006 18:56:49 -0400 Received: from mdmail4.ciena.com (HELO mdmxm02.ciena.com) ([63.118.39.27]) by hicks.ciena.com with ESMTP; 11 Sep 2006 19:10:17 -0400 X-IronPort-AV: i="4.09,147,1157342400"; d="scan'208,217"; a="63286048:sNHT43246168" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sigtran] WG Last Call on IUA update concludes Date: Mon, 11 Sep 2006 18:56:28 -0400 Message-ID: <0901D1988E815341A0103206A834DA070101A1AB@mdmxm02.ciena.com> In-Reply-To: <0901D1988E815341A0103206A834DA07F9BAAB@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] WG Last Call on IUA update concludes Thread-Index: AcbN2o6T7fsBsWV3RsWb48GjtOLRnwIGtNEw From: "Ong, Lyndon" To: "Ong, Lyndon" , X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1084685613==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1084685613== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D5F5.84D7C5B3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D5F5.84D7C5B3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 As there were no comments on the IUA update, it is approved by the WG and will be forwarded to our A-Ds for review. =20 Best regards, =20 L. Ong ________________________________ From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Friday, September 01, 2006 8:23 AM To: sigtran@ietf.org Subject: [Sigtran] WG Last Call on IUA update Hi Folks, =20 I've been neglecting this, but some time ago we agreed to go forward with the IUA TLV update in http://ietf.org/internet-drafts/draft-ietf-sigtran-rfc4233update-00.txt =20 Let's do a WG Last Call on this. Given the shortness of the draft, I think just a week would be sufficient for Last Call, however if people want we could make it the usual two weeks. =20 If there are no objections, let's have Last Call starting today (Sept. 1st) and going to next Friday (Sept. 8th). =20 Cheers, =20 L. Ong ------_=_NextPart_001_01C6D5F5.84D7C5B3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

As there were no comments on the IUA update, = it is=20 approved

by the WG and will be forwarded to our A-Ds = for=20 review.

Best regards,

L. Ong

From: Ong, Lyndon = [mailto:Lyong@Ciena.com]=20
Sent: Friday, September 01, 2006 8:23 AM
To:=20 sigtran@ietf.org
Subject: [Sigtran] WG Last Call on IUA=20 update

Hi=20 Folks,

I've = been neglecting=20 this, but some time ago we agreed to go forward with the IUA
TLV = update in http://ietf.org/internet-drafts/draft-ietf-sigtran-rfc4233update-= 00.txt

Let's = do a WG Last=20 Call on this. Given the shortness of the draft, I think=20 just

a week = would be=20 sufficient for Last Call, however if people want we could make=20 it

the = usual two=20 weeks.

If = there are no=20 objections, let's have Last Call starting today (Sept. 1st) and=20 going

to = next Friday=20 (Sept. 8th).

Cheers,

L.=20 Ong

------_=_NextPart_001_01C6D5F5.84D7C5B3-- --===============1084685613== 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 --===============1084685613==-- From sigtran-bounces@ietf.org Thu Sep 14 07:23:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpIq-0005cW-Lv; Thu, 14 Sep 2006 07:22:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpIp-0005cO-BG for sigtran@ietf.org; Thu, 14 Sep 2006 07:22:43 -0400 Received: from web54004.mail.yahoo.com ([206.190.36.228]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNpIn-0005xP-RL for sigtran@ietf.org; Thu, 14 Sep 2006 07:22:43 -0400 Received: (qmail 26709 invoked by uid 60001); 14 Sep 2006 11:22:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kllSJOb9xH5o1mm5r9P/1S88n3ZYUU8VLmM5uPV7cLgUjfA/DF3/B/mtGwJzSmQLby9IPKf2MdVKmOrMUFIzvsTQcT5cKiayisDM5tLbWCoO84CiAHwxHcmLv9q5MkkOvvf4/c9WnecrPs8SxyKM/r9FHKI1nyWCt3tU3w+FOZY= ; Message-ID: <20060914112241.26707.qmail@web54004.mail.yahoo.com> Received: from [220.227.132.114] by web54004.mail.yahoo.com via HTTP; Thu, 14 Sep 2006 04:22:41 PDT Date: Thu, 14 Sep 2006 04:22:41 -0700 (PDT) From: Saraswati Bose To: Brian Bidulock , sigtran MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Sigtran] SCTP data message handling 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="===============0134783054==" Errors-To: sigtran-bounces@ietf.org --===============0134783054== Content-Type: multipart/alternative; boundary="0-111982530-1158232961=:23221" Content-Transfer-Encoding: 8bit --0-111982530-1158232961=:23221 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian, please suggest in the below SCTP-A SCTP-B ARWND==4000 No fragmentation/bundling to be done ASSOCIATION ESTABLISHED.. <-----------User Data of size 5000 bytes ?? Should endpoint B simply reject the data or send it to peer and peer shound reject the data? Regards, Saraswati --------------------------------- Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail. --0-111982530-1158232961=:23221 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi Brian,

please suggest in the below

SCTP-A SCTP-B

ARWND==4000 No fragmentation/bundling to be done

ASSOCIATION ESTABLISHED..

<-----------User Data of size 5000 bytes

?? Should endpoint B simply reject the data or send it to peer and peer shound reject the data?

Regards,

Saraswati

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail. --0-111982530-1158232961=:23221-- --===============0134783054== 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 --===============0134783054==-- From sigtran-bounces@ietf.org Thu Sep 14 07:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpc2-0003GW-Mi; Thu, 14 Sep 2006 07:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpc0-0003Dl-JZ for sigtran@ietf.org; Thu, 14 Sep 2006 07:42:33 -0400 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNpQU-0000qp-6q for sigtran@ietf.org; Thu, 14 Sep 2006 07:30:39 -0400 Received: by wx-out-0506.google.com with SMTP id t4so3089415wxc for ; Thu, 14 Sep 2006 04:30:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=thxXN/kFtnQu9bjwAJetpEG9B1ahRKZrSm+JvONnkM8QkCL24cApsnhybewpeBGMQ41xulKHROcYqUDTDHYkCkx14UheJ0MnAMJRCbo0Zy9ZUyOkRc0lUJSAGgYwfmc0hVc6hxNOZ4ajy1uT3/TH/JzW1c+NeHv6Lmw3xEseN5A= Received: by 10.70.108.18 with SMTP id g18mr12394679wxc; Thu, 14 Sep 2006 04:30:37 -0700 (PDT) Received: by 10.70.130.2 with HTTP; Thu, 14 Sep 2006 04:30:37 -0700 (PDT) Message-ID: <64b4f63d0609140430q7b0ff733va7bbaef265fbdfc0@mail.gmail.com> Date: Thu, 14 Sep 2006 17:00:37 +0530 From: "Ashish Soregaonkar" To: "Saraswati Bose" Subject: Re: [Sigtran] SCTP data message handling In-Reply-To: <20060914112241.26707.qmail@web54004.mail.yahoo.com> MIME-Version: 1.0 References: <20060914112241.26707.qmail@web54004.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sigtran X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0321883289==" Errors-To: sigtran-bounces@ietf.org --===============0321883289== Content-Type: multipart/alternative; boundary="----=_Part_260602_22670695.1158233437677" ------=_Part_260602_22670695.1158233437677 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline >From RFC2960 Section 6.1 A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e. rwnd is 0, see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data receiver to the data sender. HTH, Ashish On 9/14/06, Saraswati Bose wrote: > > Hi Brian, > please suggest in the below > SCTP-A SCTP-B > ARWND==4000 No fragmentation/bundling > to be done > > ASSOCIATION ESTABLISHED.. > > > <-----------User Data of size 5000 bytes > ?? Should endpoint B simply reject the data or send it to peer and peer > shound reject the data? > > Regards, > Saraswati > > ------------------------------ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail. > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > > ------=_Part_260602_22670695.1158233437677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline >From RFC2960 Section 6.1

A) At any given time, the data sender MUST NOT transmit new data to
      any destination transport address if its peer's rwnd indicates
      that the peer has no buffer space (i.e . rwnd is 0, see Section
      6.2.1). However, regardless of the value of rwnd (including if it
      is 0), the data sender can always have one DATA chunk in flight to
      the receiver if allowed by cwnd (see rule B below). This rule
      allows the sender to probe for a change in rwnd that the sender
      missed due to the SACK having been lost in transit from the data
      receiver to the data sender.

HTH,
Ashish

On 9/14/06, Saraswati Bose <saraswatibose@yahoo.com> wrote:

Hi Brian,

please suggest in the below

SCTP-A                                         SCTP-B

ARWND==4000                                      No fragmentation/bundling to be done

            ASSOCIATION ESTABLISHED..

                                                             <-----------User Data of size  5000 bytes

?? Should endpoint B simply reject the data or send it to peer and peer shound reject the data?

Regards,

Saraswati

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail.

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

------=_Part_260602_22670695.1158233437677-- --===============0321883289== 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 --===============0321883289==-- From sigtran-bounces@ietf.org Thu Sep 14 08:07:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNq01-0003YI-7D; Thu, 14 Sep 2006 08:07:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNpzz-0003YD-S0 for sigtran@ietf.org; Thu, 14 Sep 2006 08:07:19 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNpzy-00057x-FZ for sigtran@ietf.org; Thu, 14 Sep 2006 08:07:19 -0400 Received: from ns.pigworks.openss7.net (IDENT:3bTQbctPImpC1MEnkcg4w64RM9vXkxcH@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k8EC7HD00429; Thu, 14 Sep 2006 06:07:17 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k8EC7HM26985; Thu, 14 Sep 2006 06:07:17 -0600 Date: Thu, 14 Sep 2006 06:07:17 -0600 From: "Brian F. G. Bidulock" To: Saraswati Bose Message-ID: <20060914060716.B26595@openss7.org> Mail-Followup-To: Saraswati Bose , sigtran References: <20060914112241.26707.qmail@web54004.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060914112241.26707.qmail@web54004.mail.yahoo.com>; from saraswatibose@yahoo.com on Thu, Sep 14, 2006 at 04:22:41AM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sigtran Subject: [Sigtran] Re: SCTP data message handling 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: , Errors-To: sigtran-bounces@ietf.org Saraswati, Saraswati Bose wrote: (Thu, 14 Sep 2006 04:22:41) > > SCTP-A SCTP-B > > ARWND==4000 If the MTU greater than 5000, SWS Avoidance dictates that SCTP-A either advertize 1 MTU or zero. SCTP-B after SWS Avoidance should either treat this as 1 MTU or zero also. Nevertheless, the other reponse is correct: you can always have one MTU in flight. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 14 08:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNqdq-0001Zq-KJ; Thu, 14 Sep 2006 08:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNqdp-0001Wu-41 for sigtran@ietf.org; Thu, 14 Sep 2006 08:48:29 -0400 Received: from web54002.mail.yahoo.com ([206.190.36.226]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GNqdm-0003g4-OW for sigtran@ietf.org; Thu, 14 Sep 2006 08:48:29 -0400 Received: (qmail 94767 invoked by uid 60001); 14 Sep 2006 12:48:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TOppkYZxj2k+nObY7caBPxwHGsc3XdjNYS22C8ROxy9AFHdd26pRGkP4y6rJslx9DiL7prWpu4tGbctgVh0BPKGSyCyQkmfIoDgISUnfuMsHK/0QIhwGmgYhqXdTWqiqu2iK5TzVeab0l0uKDXe9h5H7MtVS4PIAwTSRHZVDuXc= ; Message-ID: <20060914124826.94764.qmail@web54002.mail.yahoo.com> Received: from [220.227.132.114] by web54002.mail.yahoo.com via HTTP; Thu, 14 Sep 2006 05:48:26 PDT Date: Thu, 14 Sep 2006 05:48:26 -0700 (PDT) From: Saraswati Bose To: sigtran MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1185629059-1158238106=:90506" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [Sigtran] Fwd: Re: SCTP data message handling 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: , Errors-To: sigtran-bounces@ietf.org --0-1185629059-1158238106=:90506 Content-Type: multipart/alternative; boundary="0-714129697-1158238106=:90506" --0-714129697-1158238106=:90506 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Note: forwarded message attached. --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1�/min. --0-714129697-1158238106=:90506 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Note: forwarded message attached.

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1�/min. --0-714129697-1158238106=:90506-- --0-1185629059-1158238106=:90506 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Received: from [220.227.132.114] by web54004.mail.yahoo.com via HTTP; Thu, 14 Sep 2006 05:45:46 PDT Date: Thu, 14 Sep 2006 05:45:46 -0700 (PDT) From: Saraswati Bose Subject: Re: SCTP data message handling To: bidulock@openss7.org In-Reply-To: <20060914060716.B26595@openss7.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1026827149-1158237946=:50320" Content-Transfer-Encoding: 8bit Content-Length: 971 --0-1026827149-1158237946=:50320 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian, It seems I am not understood properly. I wanted to know in case SCTP endpoint A receives ulp data of size greater than the ARWND value of its peer (say Endpoint B) and and suppose that fragmentation/bundling is not supported by endpoint A, should A reject the data or not? If not then should endpoint B reject the data? Regards, Saraswati "Brian F. G. Bidulock" wrote: Saraswati, Saraswati Bose wrote: (Thu, 14 Sep 2006 04:22:41) > > SCTP-A SCTP-B > > ARWND==4000 If the MTU greater than 5000, SWS Avoidance dictates that SCTP-A either advertize 1 MTU or zero. SCTP-B after SWS Avoidance should either treat this as 1 MTU or zero also. Nevertheless, the other reponse is correct: you can always have one MTU in flight. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --------------------------------- Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail. --0-1026827149-1158237946=:50320 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi Brian,

It seems I am not understood properly.

I wanted to know in case SCTP endpoint A receives ulp data of size greater than the ARWND value of its peer (say Endpoint B) and and suppose that fragmentation/bundling is not supported by endpoint A, should A reject the data or not?

If not then should endpoint B reject the data?

Regards,

Saraswati

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

Saraswati,

Saraswati Bose wrote: (Thu, 14 Sep 2006 04:22:41)
>
> SCTP-A SCTP-B
>
> ARWND==4000

If the MTU greater than 5000, SWS Avoidance dictates that SCTP-A either
advertize 1 MTU or zero. SCTP-B after SWS Avoidance should either treat
this as 1 MTU or zero also.

Nevertheless, the other reponse is correct: you can always have one MTU
in flight.

--brian

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

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail. --0-1026827149-1158237946=:50320-- --0-1185629059-1158238106=:90506 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 --0-1185629059-1158238106=:90506-- From sigtran-bounces@ietf.org Fri Sep 15 01:21:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO68N-0002ET-Bh; Fri, 15 Sep 2006 01:21:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO68L-0002EO-PD for sigtran@ietf.org; Fri, 15 Sep 2006 01:21:01 -0400 Received: from web56701.mail.re3.yahoo.com ([66.196.97.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GO68K-0002YY-Al for sigtran@ietf.org; Fri, 15 Sep 2006 01:21:01 -0400 Received: (qmail 15053 invoked by uid 60001); 15 Sep 2006 05:20:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TlJfCe8cq3cPaaAC2F8hgpm7RX8ltqpRJ20U5kPU5PqgCEW6fNgPcf3IXX6kefJiAh2qrG+7b8GhbhyGTDyhKoQRQ3SY9In79xITcMVEr8qCeceXQl7Qly6Rj2+nhtni3Bd+t+jgFF7CK4WfeCiNwqSUvsChzePytmX8x8TypGA= ; Message-ID: <20060915052052.15051.qmail@web56701.mail.re3.yahoo.com> Received: from [220.227.132.114] by web56701.mail.re3.yahoo.com via HTTP; Thu, 14 Sep 2006 22:20:52 PDT Date: Thu, 14 Sep 2006 22:20:52 -0700 (PDT) From: Padmalochan Moharana To: sigtran@ietf.org, bidulock@openss7.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Sigtran] ASP Active for pending RC 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: , Errors-To: sigtran-bounces@ietf.org Hi Brian, please suggest for the following doubts. 1 - In SUA should ASP encode ASP Active for pending RCs if no responce is being received for them. 2 - Should the state of the ASP change to ACTIVE if it not received ASP ACTIVE ACK for all the RC encoded in the ASP ACTIVE message. Regards, Padman, __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Sep 15 02:12:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6vh-0006CL-7R; Fri, 15 Sep 2006 02:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO6vf-0006Bj-Qu for sigtran@ietf.org; Fri, 15 Sep 2006 02:11:59 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO6ve-00023A-Dq for sigtran@ietf.org; Fri, 15 Sep 2006 02:11:59 -0400 Received: from ns.pigworks.openss7.net (IDENT:pPBB/X1Ys0BiXUz9twfWi9JWFOyWGAz7@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k8F6BtD25564; Fri, 15 Sep 2006 00:11:55 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k8F6Bsa11304; Fri, 15 Sep 2006 00:11:54 -0600 Date: Fri, 15 Sep 2006 00:11:54 -0600 From: "Brian F. G. Bidulock" To: Padmalochan Moharana Message-ID: <20060915001154.A11188@openss7.org> Mail-Followup-To: Padmalochan Moharana , sigtran@ietf.org References: <20060915052052.15051.qmail@web56701.mail.re3.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060915052052.15051.qmail@web56701.mail.re3.yahoo.com>; from moharana_p@yahoo.com on Thu, Sep 14, 2006 at 10:20:52PM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sigtran@ietf.org Subject: [Sigtran] Re: ASP Active for pending RC 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: , Errors-To: sigtran-bounces@ietf.org Padmalochan, Padmalochan Moharana wrote: (Thu, 14 Sep 2006 22:20:52) > Hi Brian, > > please suggest for the following doubts. > > 1 - In SUA should ASP encode ASP Active for pending > RCs if no responce is being received for them. I am not sure what you mean by "pending RCs". > > 2 - Should the state of the ASP change to ACTIVE if it > not received ASP ACTIVE ACK for all the RC encoded in > the ASP ACTIVE message. The state can change to AS-ACTIVE for the AS for which ASP ACTIVE ACK was received for the associated RCs. The state of AS for which no ASP ACTIVE ACK has been received for the corresponding RCs, can remanin in a state awaiting receipt of an ASP ACTIVE ACK. If a timeout occurs, the ASP can resend ASP ACTIVE with the RC for which no responding ASP ACITVE ACK has yet been received. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Sep 15 02:17:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO718-0008Pb-KU; Fri, 15 Sep 2006 02:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO717-0008PW-M6 for sigtran@ietf.org; Fri, 15 Sep 2006 02:17:37 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO715-0003Te-Nc for sigtran@ietf.org; Fri, 15 Sep 2006 02:17:37 -0400 Received: from ns.pigworks.openss7.net (IDENT:Eb91Ur69vnfQJGSTVLmSbWuz2qOZTHwG@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k8F6HZD25667; Fri, 15 Sep 2006 00:17:35 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k8F6HYL11382; Fri, 15 Sep 2006 00:17:34 -0600 Date: Fri, 15 Sep 2006 00:17:34 -0600 From: "Brian F. G. Bidulock" To: Padmalochan Moharana , sigtran@ietf.org Subject: Re: [Sigtran] Re: ASP Active for pending RC Message-ID: <20060915001734.A11322@openss7.org> Mail-Followup-To: Padmalochan Moharana , sigtran@ietf.org References: <20060915052052.15051.qmail@web56701.mail.re3.yahoo.com> <20060915001154.A11188@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060915001154.A11188@openss7.org>; from bidulock@openss7.org on Fri, Sep 15, 2006 at 12:11:54AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 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: , Errors-To: sigtran-bounces@ietf.org Padmalochan, Brian F. G. Bidulock wrote: (Fri, 15 Sep 2006 00:11:54) > Padmalochan, > > Padmalochan Moharana wrote: (Thu, 14 Sep 2006 22:20:52) > > Hi Brian, > > > > please suggest for the following doubts. > > > > 1 - In SUA should ASP encode ASP Active for pending > > RCs if no responce is being received for them. > > I am not sure what you mean by "pending RCs". > > > > > 2 - Should the state of the ASP change to ACTIVE if it > > not received ASP ACTIVE ACK for all the RC encoded in > > the ASP ACTIVE message. > > The state can change to AS-ACTIVE for the AS for which > ASP ACTIVE ACK was received for the associated RCs. The > state of AS for which no ASP ACTIVE ACK has been received > for the corresponding RCs, can remanin in a state awaiting > receipt of an ASP ACTIVE ACK. If a timeout occurs, the > ASP can resend ASP ACTIVE with the RC for which no responding > ASP ACITVE ACK has yet been received. > Let me put that another way: Sending multiple RCs in an ASP ACTIVE (Ack) or ASP INACTIVE (Ack) is really just a convenience for compacting multiple messages into one. No relationship between the RCs contained in the message is formed by placing them together. From a state machine view, one message containing five different RC values is treated the same as though 5 messages of the same type were received each with only one RC value in it. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Sep 15 02:26:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO799-0002uN-2m; Fri, 15 Sep 2006 02:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO797-0002rm-2y for sigtran@ietf.org; Fri, 15 Sep 2006 02:25:53 -0400 Received: from web56707.mail.re3.yahoo.com ([66.196.97.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GO795-0005RT-RI for sigtran@ietf.org; Fri, 15 Sep 2006 02:25:53 -0400 Received: (qmail 32361 invoked by uid 60001); 15 Sep 2006 06:25:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=r2YXWnwfbypWKXZ7GJySlcs2Ielm/W70k/iqhEBCfuvHRfQ4oiNp2V3nviYm3rN7trfWnMHbWkhnQaJFUECFClVymWQfPsD5+VQI5dxfjYy6mpquFe3ebtjlmVJUcxpGGnBYrvpABpU7B5HQa6ZB34K3Ch5KCwfdlfpHdUuUn88= ; Message-ID: <20060915062551.32359.qmail@web56707.mail.re3.yahoo.com> Received: from [220.227.132.114] by web56707.mail.re3.yahoo.com via HTTP; Thu, 14 Sep 2006 23:25:51 PDT Date: Thu, 14 Sep 2006 23:25:51 -0700 (PDT) From: Padmalochan Moharana Subject: Re: [Sigtran] Re: ASP Active for pending RC To: bidulock@openss7.org, sigtran In-Reply-To: <20060915001734.A11322@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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: , Errors-To: sigtran-bounces@ietf.org Hi brian, suppose the ASP active contains 5 RCs. But SG responce Active ack with 3 RC .Also not receive error for the rest of the 2 RC then should ASP encode ASP Active for the rest of the 2 RC. --- "Brian F. G. Bidulock" wrote: > Padmalochan, > > Brian F. G. Bidulock wrote: (Fri, 15 Sep > 2006 00:11:54) > > Padmalochan, > > > > Padmalochan Moharana wrote: (Thu, 14 Sep > 2006 22:20:52) > > > Hi Brian, > > > > > > please suggest for the following doubts. > > > > > > 1 - In SUA should ASP encode ASP Active for > pending > > > RCs if no responce is being received for them. > > > > I am not sure what you mean by "pending RCs". > > > > > > > > 2 - Should the state of the ASP change to ACTIVE > if it > > > not received ASP ACTIVE ACK for all the RC > encoded in > > > the ASP ACTIVE message. > > > > The state can change to AS-ACTIVE for the AS for > which > > ASP ACTIVE ACK was received for the associated > RCs. The > > state of AS for which no ASP ACTIVE ACK has been > received > > for the corresponding RCs, can remanin in a state > awaiting > > receipt of an ASP ACTIVE ACK. If a timeout > occurs, the > > ASP can resend ASP ACTIVE with the RC for which no > responding > > ASP ACITVE ACK has yet been received. > > > > Let me put that another way: Sending multiple RCs > in an ASP ACTIVE > (Ack) or ASP INACTIVE (Ack) is really just a > convenience for compacting > multiple messages into one. No relationship between > the RCs contained > in the message is formed by placing them together. > From a state machine > view, one message containing five different RC > values is treated the > same as though 5 messages of the same type were > received each with only > one RC value in it. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Sep 15 02:38:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7LW-00085j-PL; Fri, 15 Sep 2006 02:38:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7LV-000858-B5 for sigtran@ietf.org; Fri, 15 Sep 2006 02:38:41 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO7LT-0001Kn-U2 for sigtran@ietf.org; Fri, 15 Sep 2006 02:38:41 -0400 Received: from ns.pigworks.openss7.net (IDENT:x0UWaJINEvMQ1xhC9/sbNc1T+y7k/OnJ@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k8F6cdD26184; Fri, 15 Sep 2006 00:38:39 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k8F6cdt11604; Fri, 15 Sep 2006 00:38:39 -0600 Date: Fri, 15 Sep 2006 00:38:38 -0600 From: "Brian F. G. Bidulock" To: Padmalochan Moharana Subject: Re: [Sigtran] Re: ASP Active for pending RC Message-ID: <20060915003838.B11322@openss7.org> Mail-Followup-To: Padmalochan Moharana , sigtran References: <20060915001734.A11322@openss7.org> <20060915062551.32359.qmail@web56707.mail.re3.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060915062551.32359.qmail@web56707.mail.re3.yahoo.com>; from moharana_p@yahoo.com on Thu, Sep 14, 2006 at 11:25:51PM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sigtran X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Padmalochan, Padmalochan Moharana wrote: (Thu, 14 Sep 2006 23:25:51) > Hi brian, > > suppose the ASP active contains 5 RCs. But SG responce > Active ack with 3 RC .Also not receive error for the > rest of the 2 RC then should ASP encode ASP Active for > the rest of the 2 RC. > Well, think about it. I said they were independent. When the ASP sends ASP Active containing 5 RCs it is no different than sending 5 ASP Active messages each containing one of the RCs. So, if the ASP sends 5 ASP Active messages to the SG and only receives 3 ASP Active Ack messages, for three of the 5 sent message, what does the ASP do with the other two? Well, it can wait for a time and then resend the messages (in which case it could send both RC in the same retry message), or, it could wait indefinitely. Whether multiple RCs are in a message or not has nothing to do with it. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Sep 15 02:41:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7O4-0001Dl-NH; Fri, 15 Sep 2006 02:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7O3-0001Cg-Q4 for sigtran@ietf.org; Fri, 15 Sep 2006 02:41:19 -0400 Received: from hostreea1.alcatel.com ([143.209.238.161] helo=audl951.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO7O3-00022w-AK for sigtran@ietf.org; Fri, 15 Sep 2006 02:41:19 -0400 Received: from ssd.usa.alcatel.com (spdmail-qfe1.ssd.usa.alcatel.com [172.22.222.60]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id k8F6fH4v002325; Fri, 15 Sep 2006 01:41:18 -0500 Received: from axes-mach01.usa.alcatel.com (axes-mach01.usa.alcatel.com [10.255.0.20]) by ssd.usa.alcatel.com (8.12.8/8.12.8) with ESMTP id k8F6eMgq013027; Fri, 15 Sep 2006 01:40:23 -0500 (CDT) Received: from [10.255.1.164] (ax-sp-pc112.usa.alcatel.com [10.255.1.164]) by axes-mach01.usa.alcatel.com (8.12.10+Sun/8.12.2) with ESMTP id k8F6jij0005627; Fri, 15 Sep 2006 12:15:45 +0530 (IST) Message-ID: <450A4967.7060409@axes-mach01.usa.alcatel.com> Date: Fri, 15 Sep 2006 12:04:15 +0530 From: Bhanu Prakash User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Padmalochan Moharana Subject: Re: [Sigtran] Re: ASP Active for pending RC References: <20060915062551.32359.qmail@web56707.mail.re3.yahoo.com> In-Reply-To: <20060915062551.32359.qmail@web56707.mail.re3.yahoo.com> X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: bidulock@openss7.org, sigtran X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0785637586==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0785637586== Content-Type: multipart/alternative; boundary="------------030509010306080507010507" This is a multi-part message in MIME format. --------------030509010306080507010507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit <>Padmalochan, The ASP state will not change to ACTIVE untill the ASP ACTIVE ACK has been received for the corresponding RCs. Regards, Bhanu. Padmalochan Moharana wrote: >Hi brian, > >suppose the ASP active contains 5 RCs. But SG responce >Active ack with 3 RC .Also not receive error for the >rest of the 2 RC then should ASP encode ASP Active for >the rest of the 2 RC. > > > >--- "Brian F. G. Bidulock" >wrote: > > > >>Padmalochan, >> >>Brian F. G. Bidulock wrote: (Fri, 15 Sep >>2006 00:11:54) >> >> >>>Padmalochan, >>> >>>Padmalochan Moharana wrote: (Thu, 14 Sep >>> >>> >>2006 22:20:52) >> >> >>>>Hi Brian, >>>> >>>>please suggest for the following doubts. >>>> >>>>1 - In SUA should ASP encode ASP Active for >>>> >>>> >>pending >> >> >>>>RCs if no responce is being received for them. >>>> >>>> >>>I am not sure what you mean by "pending RCs". >>> >>> >>> >>>>2 - Should the state of the ASP change to ACTIVE >>>> >>>> >>if it >> >> >>>>not received ASP ACTIVE ACK for all the RC >>>> >>>> >>encoded in >> >> >>>>the ASP ACTIVE message. >>>> >>>> >>>The state can change to AS-ACTIVE for the AS for >>> >>> >>which >> >> >>>ASP ACTIVE ACK was received for the associated >>> >>> >>RCs. The >> >> >>>state of AS for which no ASP ACTIVE ACK has been >>> >>> >>received >> >> >>>for the corresponding RCs, can remanin in a state >>> >>> >>awaiting >> >> >>>receipt of an ASP ACTIVE ACK. If a timeout >>> >>> >>occurs, the >> >> >>>ASP can resend ASP ACTIVE with the RC for which no >>> >>> >>responding >> >> >>>ASP ACITVE ACK has yet been received. >>> >>> >>> >>Let me put that another way: Sending multiple RCs >>in an ASP ACTIVE >>(Ack) or ASP INACTIVE (Ack) is really just a >>convenience for compacting >>multiple messages into one. No relationship between >>the RCs contained >>in the message is formed by placing them together. >>From a state machine >>view, one message containing five different RC >>values is treated the >>same as though 5 messages of the same type were >>received each with only >>one RC value in it. >> >>--brian >> >>-- >>Brian F. G. Bidulock >>bidulock@openss7.org >>http://www.openss7.org/ >> >> >> > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > >_______________________________________________ >Sigtran mailing list >Sigtran@ietf.org >https://www1.ietf.org/mailman/listinfo/sigtran > > > > --------------030509010306080507010507 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <>Padmalochan, The ASP state will not change to ACTIVE untill the ASP ACTIVE ACK has been received for the corresponding RCs. Regards, Bhanu. Padmalochan Moharana wrote:

Hi brian,

suppose the ASP active contains 5 RCs. But SG responce
Active ack with 3 RC .Also not receive error for the
rest of the 2 RC then should ASP encode ASP Active for
the rest of the 2 RC.



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

Padmalochan,

Brian F. G. Bidulock wrote:            (Fri, 15 Sep
2006 00:11:54)

Padmalochan,

Padmalochan Moharana wrote:          (Thu, 14 Sep

2006 22:20:52)

Hi Brian,

please suggest for the following doubts.

1 - In SUA should ASP encode ASP Active for

pending

RCs if no responce is being received for them.

I am not sure what you mean by "pending RCs".

2 - Should the state of the ASP change to ACTIVE

if it

not received ASP ACTIVE ACK  for all the RC

encoded in

the ASP ACTIVE message.

The state can change to AS-ACTIVE for the AS for

which

ASP ACTIVE ACK was received for the associated

RCs.  The

state of AS for which no ASP ACTIVE ACK has been

received

for the corresponding RCs, can remanin in a state

awaiting

receipt of an ASP ACTIVE ACK.  If a timeout

occurs, the

ASP can resend ASP ACTIVE with the RC for which no

responding

ASP ACITVE ACK has yet been received.

Let me put that another way:  Sending multiple RCs
in an ASP ACTIVE
(Ack) or ASP INACTIVE (Ack) is really just a
convenience for compacting
multiple messages into one.  No relationship between
the RCs contained
in the message is formed by placing them together. 
>From a state machine
view, one message containing five different RC
values is treated the
same as though 5 messages of the same type were
received each with only
one RC value in it.

--brian

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



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

--------------030509010306080507010507-- --===============0785637586== 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 --===============0785637586==-- From sigtran-bounces@ietf.org Fri Sep 15 02:55:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7bd-0005bc-4v; Fri, 15 Sep 2006 02:55:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO7bc-0005bX-11 for sigtran@ietf.org; Fri, 15 Sep 2006 02:55:20 -0400 Received: from web37407.mail.mud.yahoo.com ([209.191.91.139]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GO7ba-0004QE-7C for sigtran@ietf.org; Fri, 15 Sep 2006 02:55:19 -0400 Received: (qmail 14794 invoked by uid 60001); 15 Sep 2006 06:55:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=t40KoEHPekQ1yL6gfLUy5CpiGLNQAEsgdb4gSPuj38NaUFIkthksd5GCYP6j2LPI2O4wZSqsVUa5xJRCSzY3IL/T+Ln27473jxYuBc+DIGuopxy68ZpWlPKpFjdMWmGjjFTbtA3N/Fk9IyFJdzYvkKGhVJc2kvFkB6Gpohv2aCo= ; Message-ID: <20060915065517.14792.qmail@web37407.mail.mud.yahoo.com> Received: from [203.145.132.252] by web37407.mail.mud.yahoo.com via HTTP; Thu, 14 Sep 2006 23:55:17 PDT Date: Thu, 14 Sep 2006 23:55:17 -0700 (PDT) From: ash kat Subject: Re: [Sigtran] Fwd: Re: SCTP data message handling To: Saraswati Bose , sigtran In-Reply-To: <20060914124826.94764.qmail@web54002.mail.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0341263884==" Errors-To: sigtran-bounces@ietf.org --===============0341263884== Content-Type: multipart/alternative; boundary="0-2005595641-1158303317=:11944" Content-Transfer-Encoding: 8bit --0-2005595641-1158303317=:11944 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Saraswati IMO If Side B has to send User data greater then a_rwnd of peer then 1. The SCTP should discard the data only in one case when it is not able to fragment the data to less than PMTU size configured. [ i.e fragmentation is not allowed ] 2. Otherwise it should send the data to peer, but peer will drop the DATA as no buffers are available to receive that DATA, However the peer SCTP will send the SACK containing TSN of the last data chunk successfully received and also the updated receiver window. SCTP will keep on retransmitting that DATA chunk until it receives SACK for "that" DATA chunk. If PMTU size is configured to 1500 [ for ethernet] then your case lies in the first scenario, hence the SCTP should discard the data and give proper error to the user. --Ashwani kathuria FSS India Saraswati Bose wrote: Note: forwarded message attached. --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1�/min.Date: Thu, 14 Sep 2006 05:45:46 -0700 (PDT) From: Saraswati Bose Subject: Re: SCTP data message handling To: bidulock@openss7.org Hi Brian, It seems I am not understood properly. I wanted to know in case SCTP endpoint A receives ulp data of size greater than the ARWND value of its peer (say Endpoint B) and and suppose that fragmentation/bundling is not supported by endpoint A, should A reject the data or not? If not then should endpoint B reject the data? Regards, Saraswati "Brian F. G. Bidulock" wrote: Saraswati, Saraswati Bose wrote: (Thu, 14 Sep 2006 04:22:41) > > SCTP-A SCTP-B > > ARWND==4000 If the MTU greater than 5000, SWS Avoidance dictates that SCTP-A either advertize 1 MTU or zero. SCTP-B after SWS Avoidance should either treat this as 1 MTU or zero also. Nevertheless, the other reponse is correct: you can always have one MTU in flight. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ --------------------------------- Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail._______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --------------------------------- Want to be your own boss? Learn how on Yahoo! Small Business. --0-2005595641-1158303317=:11944 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi Saraswati

IMO If Side B has to send User data greater then a_rwnd of peer then

1. The SCTP should discard the data only in one case when it is not able to fragment the data to less than PMTU size configured. [ i.e fragmentation is not allowed ]

2. Otherwise it should send the data to peer, but peer will drop the DATA as no buffers are available to receive that DATA, However the peer SCTP will send the SACK containing TSN of the last data chunk successfully received and also the updated receiver window.

SCTP will keep on retransmitting that DATA chunk until it receives SACK for "that" DATA chunk.

If PMTU size is configured to 1500 [ for ethernet] then your case lies in the first scenario, hence the SCTP should discard the data and give proper error to the user.

--Ashwani kathuria

FSS India

Saraswati Bose <saraswatibose@yahoo.com> wrote:

Note: forwarded message attached.

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1�/min.Date: Thu, 14 Sep 2006 05:45:46 -0700 (PDT)
From: Saraswati Bose <saraswatibose@yahoo.com>
Subject: Re: SCTP data message handling
To: bidulock@openss7.org

Hi Brian,

It seems I am not understood properly.

I wanted to know in case SCTP endpoint A receives ulp data of size greater than the ARWND value of its peer (say Endpoint B) and and suppose that fragmentation/bundling is not supported by endpoint A, should A reject the data or not?

If not then should endpoint B reject the data?

Regards,

Saraswati

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

Saraswati,

Saraswati Bose wrote: (Thu, 14 Sep 2006 04:22:41)
>
> SCTP-A SCTP-B
>
> ARWND==4000

If the MTU greater than 5000, SWS Avoidance dictates that SCTP-A either
advertize 1 MTU or zero. SCTP-B after SWS Avoidance should either treat
this as 1 MTU or zero also.

Nevertheless, the other reponse is correct: you can always have one MTU
in flight.

--brian

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

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail._______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

Want to be your own boss? Learn how on Yahoo! Small Business. --0-2005595641-1158303317=:11944-- --===============0341263884== 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 --===============0341263884==-- From sigtran-bounces@ietf.org Fri Sep 15 09:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOEBb-0003GV-JR; Fri, 15 Sep 2006 09:56:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOEBa-0003G9-OL for sigtran@ietf.org; Fri, 15 Sep 2006 09:56:54 -0400 Received: from web56712.mail.re3.yahoo.com ([66.196.97.71]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GOEBY-0003qt-7F for sigtran@ietf.org; Fri, 15 Sep 2006 09:56:54 -0400 Received: (qmail 64486 invoked by uid 60001); 15 Sep 2006 13:56:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ho2wlOCL+jOmyiW2zZ+avP6MSUrRYHZjR3G1UVG/L2BOi4ANKQgxKmqKulPoXMcNToAp8hdTyawXuP+72Wk9Zvh8Xfmnv0UYXWCBdpXhr/JLWvrPO0UsMFdGGJg2Vn/6l2HynSK4u5v+GNgbqvLR/R1+1un25XPBZYwNnH/HO78= ; Message-ID: <20060915135647.64484.qmail@web56712.mail.re3.yahoo.com> Received: from [220.227.132.114] by web56712.mail.re3.yahoo.com via HTTP; Fri, 15 Sep 2006 06:56:46 PDT Date: Fri, 15 Sep 2006 06:56:46 -0700 (PDT) From: Padmalochan Moharana To: bidulock , sigtran In-Reply-To: <20060915001154.A11188@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Sigtran] ASP message with Traffic mode type in M3UA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Hi Brian, please suggest for the following doubts. 1 - As per the RFC3332 (m3ua) the traffic mode is optional parameter.Should server response error on receiving ASP ACTIVE or REG REQ message without traffic mode? 2- What should be the defult traffic mode if server not receive traffic mode in the ASP active or REG REQ message. Regards, Padmalochan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Sep 15 10:18:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOEWl-0003I2-N4; Fri, 15 Sep 2006 10:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOEWk-0003Hx-Or for sigtran@ietf.org; Fri, 15 Sep 2006 10:18:46 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOEWj-0008A9-C9 for sigtran@ietf.org; Fri, 15 Sep 2006 10:18:46 -0400 Received: from ns.pigworks.openss7.net (IDENT:PlmW/o/a4CNlOTeptBFiG6HaFIPslBl/@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k8FEIiD04953; Fri, 15 Sep 2006 08:18:44 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k8FEIik20133; Fri, 15 Sep 2006 08:18:44 -0600 Date: Fri, 15 Sep 2006 08:18:44 -0600 From: "Brian F. G. Bidulock" To: Padmalochan Moharana Message-ID: <20060915081844.A20073@openss7.org> Mail-Followup-To: Padmalochan Moharana , sigtran References: <20060915001154.A11188@openss7.org> <20060915135647.64484.qmail@web56712.mail.re3.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060915135647.64484.qmail@web56712.mail.re3.yahoo.com>; from moharana_p@yahoo.com on Fri, Sep 15, 2006 at 06:56:46AM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sigtran Subject: [Sigtran] Re: ASP message with Traffic mode type in M3UA 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: , Errors-To: sigtran-bounces@ietf.org Padmalochan, Padmalochan Moharana wrote: (Fri, 15 Sep 2006 06:56:46) > Hi Brian, > please suggest for the following doubts. > > 1 - As per the RFC3332 (m3ua) the traffic mode is > optional parameter.Should server response error on > receiving ASP ACTIVE or REG REQ message without > traffic mode? Did you think it was an error to not do something that is optional? > > 2- What should be the defult traffic mode if server > not receive traffic mode in the ASP active or REG REQ > message. What do you thinK? I think you really need to read the traffic management section of the RFC again. --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 Sep 20 19:44:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQBif-00023y-3s; Wed, 20 Sep 2006 19:43:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQBic-000236-1r; Wed, 20 Sep 2006 19:43:06 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQBia-00059l-MO; Wed, 20 Sep 2006 19:43:06 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k8KNh4xK029253; Wed, 20 Sep 2006 16:43:04 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k8KNh46K029252; Wed, 20 Sep 2006 16:43:04 -0700 Date: Wed, 20 Sep 2006 16:43:04 -0700 Message-Id: <200609202343.k8KNh46K029252@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sigtran@ietf.org, rfc-editor@rfc-editor.org Subject: [Sigtran] RFC 4666 on Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4666 Title: Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) Author: K. Morneault, Ed., J. Pastor-Balbas, Ed. Status: Standards Track Date: September 2006 Mailbox: kmorneau@cisco.com, j.javier.pastor@ericsson.com Pages: 124 Characters: 292991 Obsoletes: RFC3332 See-Also: I-D Tag: draft-ietf-sigtran-rfc3332bis-06.txt URL: http://www.rfc-editor.org/rfc/rfc4666.txt This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. This document obsoletes RFC 3332. [STANDARDS TRACK] This document is a product of the Signaling Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Sep 21 03:31:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQJ0W-00013u-Q2; Thu, 21 Sep 2006 03:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQJ0V-00013i-2Z for sigtran@ietf.org; Thu, 21 Sep 2006 03:30:03 -0400 Received: from web54002.mail.yahoo.com ([206.190.36.226]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQJ0P-0001Mu-IU for sigtran@ietf.org; Thu, 21 Sep 2006 03:30:03 -0400 Received: (qmail 71920 invoked by uid 60001); 21 Sep 2006 07:29:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EOUuE/K/qAhK99oOjtAudve90FwVjpkx69H5mtlfXSmcjg7ulPevtylio5PcJBYFdbd0REJJ3P1dNI/CzpqyrU7VOt9zayiVWWKqfIj+Jv6fApX9RMZXBGru8iHQ1/AZ5UGdMQreqAzLMP1HiIGmR7r8iALWtkpi4t4jAVxqixM= ; Message-ID: <20060921072957.71918.qmail@web54002.mail.yahoo.com> Received: from [220.227.132.114] by web54002.mail.yahoo.com via HTTP; Thu, 21 Sep 2006 00:29:57 PDT Date: Thu, 21 Sep 2006 00:29:57 -0700 (PDT) From: Saraswati Bose To: Brian Bidulock , sigtran MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Sigtran] Default Traffic Mode X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: