From sigtran-bounces@ietf.org Wed Mar 01 02:08:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELRw-0007bA-DG; Wed, 01 Mar 2006 02:08:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELRu-0007ar-Rq for sigtran@ietf.org; Wed, 01 Mar 2006 02:08:38 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FELRt-000077-3l for sigtran@ietf.org; Wed, 01 Mar 2006 02:08:38 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 1D19C205E3 for ; Wed, 1 Mar 2006 12:23:11 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id E965A205D9 for ; Wed, 1 Mar 2006 12:23:10 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.164]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 12:38:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Mar 2006 12:36:59 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: m2ua AS state Thread-Index: AcY8/rvTI1gLYVLLTg+hEE5OAcbvzg== From: To: X-OriginalArrivalTime: 01 Mar 2006 07:08:35.0149 (UTC) FILETIME=[F4B4D7D0:01C63CFE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Subject: [Sigtran] m2ua AS state 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="===============0987912021==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0987912021== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63CFE.F4850D52" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63CFE.F4850D52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Rfc 3331 in section 1.5.1 states that : "Note that only one SGP SHOULD provide Signalling Link Terminal services to an SS7 link. Therefore, within an SG, an Application Server SHOULD be active for only one SGP at any given point in time." =20 Brain, can you throw some light on the significance of the overall AS state at SG, considering the above statement. What does being active at one SGP signify, when the overall state of AS is maintained at SG? Does it mean that SG maintains which AS is active at what SGP? =20 =20 Regards, =20 Prabind =20 =20 ------_=_NextPart_001_01C63CFE.F4850D52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

         =    Rfc 3331 in section 1.5.1 states that :

“Note that only one SGP SHOULD provide = Signalling Link Terminal

   services to an SS7 link.  = Therefore, within an SG, an Application

   Server SHOULD be active for only one SGP = at any given point in time.”

 

Brain, can you throw some light on the significance = of the overall AS state at SG, considering the above statement.  What does being = active at one SGP signify, when the overall  state of AS is maintained at = SG? Does it mean that SG maintains which AS is active at what = SGP?

 

 

Regards,

 

Prabind

 

 

------_=_NextPart_001_01C63CFE.F4850D52-- --===============0987912021== 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 --===============0987912021==-- From sigtran-bounces@ietf.org Wed Mar 01 02:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELwE-0003RV-2Z; Wed, 01 Mar 2006 02:39:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELwD-0003NJ-8x for sigtran@ietf.org; Wed, 01 Mar 2006 02:39:57 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FELwB-0001il-Rb for sigtran@ietf.org; Wed, 01 Mar 2006 02:39:57 -0500 Received: from ns.pigworks.openss7.net (IDENT:YH1171GgeLTfWco2YbiefONTNGIYrnBy@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k217dsq08006; Wed, 1 Mar 2006 00:39:54 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k217dsv10643; Wed, 1 Mar 2006 00:39:54 -0700 Date: Wed, 1 Mar 2006 00:39:54 -0700 From: "Brian F. G. Bidulock" To: prabind.chaubey@wipro.com Subject: Re: [Sigtran] m2ua AS state Message-ID: <20060301003954.A10479@openss7.org> Mail-Followup-To: prabind.chaubey@wipro.com, 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 prabind.chaubey@wipro.com on Wed, Mar 01, 2006 at 12:36:59PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 prabind.chaubey, The authors of the M2UA specification acknowledged that the traditional approach to SS7 signalling link control is to have a single active Signalling Terminal for an SS7 Signalling Data Link. Certainly, however, it is possible to conceive of a system in which multiple SGP could have simultaneous control, and thus the "SHOULD" (instead of "MUST") language in the passages you quote. It does not really impact the shared AS state discussion. Certainly, if only one SGP can have control of a Signalling Link, some AS state coordination across multiple SGP serving the same AS is necessary in either event. If only one SGP can be active for an AS, then it must coordinate with any others serving the AS to provide assurances to that effect. If multiple SGP can be active for the AS, there is most certainly a closely coupled coordination between the active SGP. --brian prabind.chaubey@wipro.com wrote: (Wed, 01 Mar 2006 12:36:59) > > Hi, > > Rfc 3331 in section 1.5.1 states that : > > "Note that only one SGP SHOULD provide Signalling Link Terminal > > services to an SS7 link. Therefore, within an SG, an Application > > Server SHOULD be active for only one SGP at any given point in > time." > > > Brain, can you throw some light on the significance of the overall AS > state at SG, considering the above statement. What does being active > at one SGP signify, when the overall state of AS is maintained at SG? > Does it mean that SG maintains which AS is active at what SGP? > > > > Regards, > > > Prabind > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Mar 01 03:15:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMUQ-0003hT-L7; Wed, 01 Mar 2006 03:15:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMUQ-0003dF-1k for sigtran@ietf.org; Wed, 01 Mar 2006 03:15:18 -0500 Received: from xproxy.gmail.com ([66.249.82.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEMUO-0002bR-Pw for sigtran@ietf.org; Wed, 01 Mar 2006 03:15:18 -0500 Received: by xproxy.gmail.com with SMTP id s15so51537wxc for ; Wed, 01 Mar 2006 00:15:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=neVsfo56O2zcAwZWU4SbtxMJkOp5Vt9kce5n6XR1+blWZykqYPGA+ot9CkcsJ+Xp5FKkd3996JECnhY/ALrMeF3xfq4L+QEjXVN1Qpa5LVtkHqhiGiJI1gKw/4y0Kgf3s9tnRgG9q5d1V5U9lhMmEGzXTuneTW97IB00ZUyG29k= Received: by 10.70.109.20 with SMTP id h20mr1657960wxc; Wed, 01 Mar 2006 00:15:16 -0800 (PST) Received: by 10.70.31.10 with HTTP; Wed, 1 Mar 2006 00:15:16 -0800 (PST) Message-ID: Date: Wed, 1 Mar 2006 13:45:16 +0530 From: "Sandeep Kumar" To: sigtran@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [Sigtran] ASPSM and ASPTM example for SG having multiple SGPs X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Hi, As everyone agrees there is a requirement for a document having test cases or examples addressing how AS is handled by an SG (multiple SGPs) . Here is a proposal for such kind of example, if it is acceptable, then we can prepare similar examples for more scenarios 5.1.5 Single ASP in an Application Server ("1+0" sparing), Two SGPs in an S= G This scenario shows the example M3UA message flows for the establishment of traffic between SGPs and an ASP where only one ASP is configured within an AS (no backup). Both SGPs are part of an SG and they co-ordinate AS state between them. SGP2 SGP1 ASP1 | | | | |<--------ASP Up---------| | |-------ASP Up Ack------>| | | | | |--NOTIFY(AS-INACTIVE)-->| | | | |<--------------------------ASP Up----------------| |--------------------------ASP Up Ack------------>| | | | |------------------------NOTIFY(AS-INACTIVE)----->| 1* | | | | | | | |<-------ASP Active------| | |------ASP Active Ack--->| | | | | |---NOTIFY(AS-ACTIVE)--->| |------------------------NOTIFY(AS-ACTIVE)------->| 2* | | | | | | |<--------------------------ASP Active------------| |--------------------------ASP Active Ack-------->| | | | | | | 3* 1* - Duplicate Notify, may not be issued by SGP 2* - Duplicate Notify, may not be issued by SGP 3* - Here Notify may be issued by SGP 5.3.2 Withdrawal of ASP, Two SGPs in an SG Following on from the example in Section 5.1.5, and ASP1 withdraws from service: SGP2 SGP1 ASP1 | | | | |<-----ASP Inactive------| | |----ASP Inactive Ack--->| | | | | | | 1* | | | |<--------------------------ASP Inactive----------| |--------------------------ASP Inactive Ack------>| | | | | |--NOTIFY(AS-PENDING)--->| | | | |------------------------NOTIFY(AS-PENDING)------>| 2* | | | | |--NOTIFY(AS-INACTIVE)-->| | | | |------------------------NOTIFY(AS-INACTIVE)----->| 3* | | | | | | | |<-------ASP Down--------| | |------ASP Down Ack----->| | | | | | | |<--------------------------ASP Down--------------| |--------------------------ASP Down Ack---------->| | | | | | | 1* - AS state will not change, as it is still ACTIVE with another SGP 2* - Duplicate Notify, may not be issued by SGP 3* - Duplicate Notify, may not be issued by SGP Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., SGP to ASP1) would not occur. It is very important from interoperability point of view, ASP behaviour will also change with decision of doing ASPSM and NOTIFY procedures per SG or per SGP. Thanks, Sandeep _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Mar 01 03:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEN2A-0005Zg-3w; Wed, 01 Mar 2006 03:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEN28-0005VA-Uq for sigtran@ietf.org; Wed, 01 Mar 2006 03:50:08 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEN26-0003lv-MM for sigtran@ietf.org; Wed, 01 Mar 2006 03:50:08 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 72942205E0 for ; Wed, 1 Mar 2006 14:04:39 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 56007205D9 for ; Wed, 1 Mar 2006 14:04:39 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.164]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 14:20:03 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] m2ua AS state Date: Wed, 1 Mar 2006 14:18:28 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] m2ua AS state Thread-Index: AcY9A1x4k36Gzt8XR+OjZ/ejfIF7twACQxMA From: To: X-OriginalArrivalTime: 01 Mar 2006 08:50:03.0666 (UTC) FILETIME=[21BECF20:01C63D0D] X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Thanks Brian =20 Regards, =20 Prabind =20 -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]=20 Sent: Wednesday, March 01, 2006 1:10 PM To: PRABIND CHAUBEY (WT01 - Voice & Next Generation Networks) Cc: sigtran@ietf.org Subject: Re: [Sigtran] m2ua AS state prabind.chaubey, The authors of the M2UA specification acknowledged that the traditional approach to SS7 signalling link control is to have a single active Signalling Terminal for an SS7 Signalling Data Link. Certainly, however, it is possible to conceive of a system in which multiple SGP could have simultaneous control, and thus the "SHOULD" (instead of "MUST") language in the passages you quote. It does not really impact the shared AS state discussion. Certainly, if only one SGP can have control of a Signalling Link, some AS state coordination across multiple SGP serving the same AS is necessary in either event. If only one SGP can be active for an AS, then it must coordinate with any others serving the AS to provide assurances to that effect. If multiple SGP can be active for the AS, there is most certainly a closely coupled coordination between the active SGP. --brian prabind.chaubey@wipro.com wrote: (Wed, 01 Mar 2006 12:36:59) >=20 > Hi, >=20 > Rfc 3331 in section 1.5.1 states that : >=20 > "Note that only one SGP SHOULD provide Signalling Link Terminal >=20 > services to an SS7 link. Therefore, within an SG, an Application >=20 > Server SHOULD be active for only one SGP at any given point in > time." >=20 >=20 > Brain, can you throw some light on the significance of the overall AS > state at SG, considering the above statement. What does being active > at one SGP signify, when the overall state of AS is maintained at SG? > Does it mean that SG maintains which AS is active at what SGP? >=20 >=20 >=20 > Regards, >=20 >=20 > Prabind > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Mar 01 06:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEPjQ-0005gY-LU; Wed, 01 Mar 2006 06:43:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEPjP-0005gF-62 for sigtran@ietf.org; Wed, 01 Mar 2006 06:42:59 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEPjN-0001z3-LN for sigtran@ietf.org; Wed, 01 Mar 2006 06:42:59 -0500 Received: from ns.pigworks.openss7.net (IDENT:0dVckrs++Zyeq0c5QWO99BttcTccmL0q@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k21Bguq13325; Wed, 1 Mar 2006 04:42:56 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k21BguG14560; Wed, 1 Mar 2006 04:42:56 -0700 Date: Wed, 1 Mar 2006 04:42:56 -0700 From: "Brian F. G. Bidulock" To: Sandeep Kumar Subject: Re: [Sigtran] ASPSM and ASPTM example for SG having multiple SGPs Message-ID: <20060301044256.A14457@openss7.org> Mail-Followup-To: Sandeep Kumar , 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 skhira@gmail.com on Wed, Mar 01, 2006 at 01:45:16PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 Sandeep, I think duplicate notifications are a really bad idea: it introduces all manner of races. Consider several NTFY(Alternate ASP Active)'s on different paths. Also, I think any new examples should include multiple ASPs as well as multiple SGPs. (Let's not make the same mistake again.) --brian Sandeep Kumar wrote: (Wed, 01 Mar 2006 13:45:16) > Hi, > > As everyone agrees there is a requirement for a document having test > cases or examples addressing how AS is handled by an SG (multiple > SGPs) . > > Here is a proposal for such kind of example, if it is acceptable, then > we can prepare similar examples for more scenarios > > > 5.1.5 Single ASP in an Application Server ("1+0" sparing), Two SGPs in an SG > > This scenario shows the example M3UA message flows for the > establishment of traffic between SGPs and an ASP where only one ASP > is configured within an AS (no backup). Both SGPs are part of an SG and > they co-ordinate AS state between them. > > SGP2 SGP1 ASP1 > | | | > | |<--------ASP Up---------| > | |-------ASP Up Ack------>| > | | | > | |--NOTIFY(AS-INACTIVE)-->| > | | | > |<--------------------------ASP Up----------------| > |--------------------------ASP Up Ack------------>| > | | | > |------------------------NOTIFY(AS-INACTIVE)----->| 1* > | | | > | | | > | |<-------ASP Active------| > | |------ASP Active Ack--->| > | | | > | |---NOTIFY(AS-ACTIVE)--->| > |------------------------NOTIFY(AS-ACTIVE)------->| 2* > | | | > | | | > |<--------------------------ASP Active------------| > |--------------------------ASP Active Ack-------->| > | | | > | | | 3* > > 1* - Duplicate Notify, may not be issued by SGP > 2* - Duplicate Notify, may not be issued by SGP > 3* - Here Notify may be issued by SGP > > > 5.3.2 Withdrawal of ASP, Two SGPs in an SG > > Following on from the example in Section 5.1.5, and ASP1 withdraws > from service: > > SGP2 SGP1 ASP1 > | | | > | |<-----ASP Inactive------| > | |----ASP Inactive Ack--->| > | | | > | | | 1* > | | | > |<--------------------------ASP Inactive----------| > |--------------------------ASP Inactive Ack------>| > | | | > | |--NOTIFY(AS-PENDING)--->| > | | | > |------------------------NOTIFY(AS-PENDING)------>| 2* > | | | > | |--NOTIFY(AS-INACTIVE)-->| > | | | > |------------------------NOTIFY(AS-INACTIVE)----->| 3* > | | | > | | | > | |<-------ASP Down--------| > | |------ASP Down Ack----->| > | | | > | | | > |<--------------------------ASP Down--------------| > |--------------------------ASP Down Ack---------->| > | | | > | | | > > 1* - AS state will not change, as it is still ACTIVE with another SGP > 2* - Duplicate Notify, may not be issued by SGP > 3* - Duplicate Notify, may not be issued by SGP > > Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., > M3UA heartbeat loss or detection of SCTP failure), the initial ASP > Inactive message exchange (i.e., SGP to ASP1) would not occur. > > It is very important from interoperability point of view, ASP > behaviour will also change with decision of doing ASPSM and NOTIFY > procedures per SG or per SGP. > > Thanks, > Sandeep > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Mar 01 08:39:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERXk-00017e-Mi; Wed, 01 Mar 2006 08:39:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERXj-0000w7-Kq for sigtran@ietf.org; Wed, 01 Mar 2006 08:39:03 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FERXj-0005x7-8U for sigtran@ietf.org; Wed, 01 Mar 2006 08:39:03 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id CAD1095848 for ; Wed, 1 Mar 2006 08:39:02 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k21Dd0M6012389 for ; Wed, 1 Mar 2006 08:39:01 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] ASPSM and ASPTM example for SG having multiple SGPs Date: Wed, 1 Mar 2006 08:18:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 Sandeep, I completely agree that examples are necessary. OTOH, I think first we need to decide what is the "best" semantics. I really think we should discuss with an open-mind what the NTFY/traffic distribution semantics should be for multiple SGP cases. I am in favor of having all ASPSM/ASPTM per SGP. For NTFY, I think we may have a bit more flexibility, considering its advisory nature. BTW, are ASPs relying on NTFY("AS State Change") notifications for any decision, it seems to me they shouldn't but there may be some which do in practice. It could be also good to get some feedback from more people about that. Thanks, Tolga > -----Original Message----- > From: Sandeep Kumar [mailto:skhira@gmail.com] > Sent: Wednesday, March 01, 2006 3:15 AM > To: sigtran@ietf.org > Subject: [Sigtran] ASPSM and ASPTM example for SG having multiple SGPs > > > Hi, > > As everyone agrees there is a requirement for a document having test > cases or examples addressing how AS is handled by an SG (multiple > SGPs) . > > Here is a proposal for such kind of example, if it is acceptable, then > we can prepare similar examples for more scenarios > > > 5.1.5 Single ASP in an Application Server ("1+0" sparing), Two > SGPs in an SG > > This scenario shows the example M3UA message flows for the > establishment of traffic between SGPs and an ASP where only one ASP > is configured within an AS (no backup). Both SGPs are part of an SG and > they co-ordinate AS state between them. > > SGP2 SGP1 ASP1 > | | | > | |<--------ASP Up---------| > | |-------ASP Up Ack------>| > | | | > | |--NOTIFY(AS-INACTIVE)-->| > | | | > |<--------------------------ASP Up----------------| > |--------------------------ASP Up Ack------------>| > | | | > |------------------------NOTIFY(AS-INACTIVE)----->| 1* > | | | > | | | > | |<-------ASP Active------| > | |------ASP Active Ack--->| > | | | > | |---NOTIFY(AS-ACTIVE)--->| > |------------------------NOTIFY(AS-ACTIVE)------->| 2* > | | | > | | | > |<--------------------------ASP Active------------| > |--------------------------ASP Active Ack-------->| > | | | > | | | 3* > > 1* - Duplicate Notify, may not be issued by SGP > 2* - Duplicate Notify, may not be issued by SGP > 3* - Here Notify may be issued by SGP > > > 5.3.2 Withdrawal of ASP, Two SGPs in an SG > > Following on from the example in Section 5.1.5, and ASP1 withdraws > from service: > > SGP2 SGP1 ASP1 > | | | > | |<-----ASP Inactive------| > | |----ASP Inactive Ack--->| > | | | > | | | 1* > | | | > |<--------------------------ASP Inactive----------| > |--------------------------ASP Inactive Ack------>| > | | | > | |--NOTIFY(AS-PENDING)--->| > | | | > |------------------------NOTIFY(AS-PENDING)------>| 2* > | | | > | |--NOTIFY(AS-INACTIVE)-->| > | | | > |------------------------NOTIFY(AS-INACTIVE)----->| 3* > | | | > | | | > | |<-------ASP Down--------| > | |------ASP Down Ack----->| > | | | > | | | > |<--------------------------ASP Down--------------| > |--------------------------ASP Down Ack---------->| > | | | > | | | > > 1* - AS state will not change, as it is still ACTIVE with another SGP > 2* - Duplicate Notify, may not be issued by SGP > 3* - Duplicate Notify, may not be issued by SGP > > Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., > M3UA heartbeat loss or detection of SCTP failure), the initial ASP > Inactive message exchange (i.e., SGP to ASP1) would not occur. > > It is very important from interoperability point of view, ASP > behaviour will also change with decision of doing ASPSM and NOTIFY > procedures per SG or per SGP. > > Thanks, > Sandeep > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Mar 01 10:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETif-0002oA-On; Wed, 01 Mar 2006 10:58:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETid-0002nx-Nu for sigtran@ietf.org; Wed, 01 Mar 2006 10:58:27 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FETic-0003fj-Do for sigtran@ietf.org; Wed, 01 Mar 2006 10:58:27 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 228C9A3EC5 for ; Wed, 1 Mar 2006 10:58:26 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k21FwO6Q026098 for ; Wed, 1 Mar 2006 10:58:24 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] ASPSM and ASPTM example for SG having multiple SGPs Date: Wed, 1 Mar 2006 10:38:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <20060301085148.A17596@openss7.org> X-Scanned-By: MIMEDefang 2.40 Received-SPF: unknown X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Brian, Yes, it is definitly better to play safe and define it nicely in the specification, then it is up to ASP what to do with it. Tolga > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Wednesday, March 01, 2006 10:52 AM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] ASPSM and ASPTM example for SG having multiple > SGPs > > > Tolga, > > ASPs can always rely on NTFY messages of AS state change: the SGP is > required to send them. OTOH, the ASP is not required to rely upon them, > but it surely can. > > --brian > > Tolga Asveren wrote: > (Wed, 01 Mar 2006 08:18:57) > > Sandeep, > > > > I completely agree that examples are necessary. OTOH, I think > first we need > > to decide what is the "best" semantics. > > > > I really think we should discuss with an open-mind what the NTFY/traffic > > distribution semantics should be for multiple SGP cases. I am > in favor of > > having all ASPSM/ASPTM per SGP. For NTFY, I think we may have a bit more > > flexibility, considering its advisory nature. BTW, are ASPs relying on > > NTFY("AS State Change") notifications for any decision, it > seems to me they > > shouldn't but there may be some which do in practice. It could > be also good > > to get some feedback from more people about that. > > > > Thanks, > > Tolga > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Mar 01 13:11:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVnG-0000mx-KD; Wed, 01 Mar 2006 13:11:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVnF-0000hU-Ix for sigtran@ietf.org; Wed, 01 Mar 2006 13:11:21 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEUbO-0006AJ-Tn for sigtran@ietf.org; Wed, 01 Mar 2006 11:55:02 -0500 Received: from gw.openss7.com ([142.179.199.224]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FETcE-0004An-R8 for sigtran@ietf.org; Wed, 01 Mar 2006 10:52:02 -0500 Received: from ns.pigworks.openss7.net (IDENT:2AzRxJ07fA2k2U25x3suRAbSOdk/Dob0@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k21Fpnq25890; Wed, 1 Mar 2006 08:51:49 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k21Fpme17772; Wed, 1 Mar 2006 08:51:48 -0700 Date: Wed, 1 Mar 2006 08:51:48 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] ASPSM and ASPTM example for SG having multiple SGPs Message-ID: <20060301085148.A17596@openss7.org> Mail-Followup-To: Tolga Asveren , 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 asveren@ulticom.com on Wed, Mar 01, 2006 at 08:18:57AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: -2.6 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Tolga, ASPs can always rely on NTFY messages of AS state change: the SGP is required to send them. OTOH, the ASP is not required to rely upon them, but it surely can. --brian Tolga Asveren wrote: (Wed, 01 Mar 2006 08:18:57) > Sandeep, > > I completely agree that examples are necessary. OTOH, I think first we need > to decide what is the "best" semantics. > > I really think we should discuss with an open-mind what the NTFY/traffic > distribution semantics should be for multiple SGP cases. I am in favor of > having all ASPSM/ASPTM per SGP. For NTFY, I think we may have a bit more > flexibility, considering its advisory nature. BTW, are ASPs relying on > NTFY("AS State Change") notifications for any decision, it seems to me they > shouldn't but there may be some which do in practice. It could be also good > to get some feedback from more people about that. > > Thanks, > Tolga > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Mar 01 13:53:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWSG-0002Or-A0; Wed, 01 Mar 2006 13:53:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWSE-0002Oe-SV for sigtran@ietf.org; Wed, 01 Mar 2006 13:53:42 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEWSD-0002p5-El for sigtran@ietf.org; Wed, 01 Mar 2006 13:53:42 -0500 Received: from ns.pigworks.openss7.net (IDENT:M4hydm2xmKAI3uDIS3I6/WAHaEuNAWfI@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k21Ircq30536; Wed, 1 Mar 2006 11:53:38 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k21Irbr19647; Wed, 1 Mar 2006 11:53:37 -0700 Date: Wed, 1 Mar 2006 11:53:37 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] ASPSM and ASPTM example for SG having multiple SGPs Message-ID: <20060301115337.A19583@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20060301085148.A17596@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from asveren@ulticom.com on Wed, Mar 01, 2006 at 10:38:20AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Tolga, Again, we agreed that NTFY is advisory: the SGP is required to send one, the ASP is not compelled to act upon it; but may rely upon it. And, yes, both are clearly stated in the specification in section 4.3.4.5. --brian Tolga Asveren wrote: (Wed, 01 Mar 2006 10:38:20) > Brian, > > Yes, it is definitly better to play safe and define it nicely in the > specification, then it is up to ASP what to do with it. > > Tolga > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Wednesday, March 01, 2006 10:52 AM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] ASPSM and ASPTM example for SG having multiple > > SGPs > > > > > > Tolga, > > > > ASPs can always rely on NTFY messages of AS state change: the SGP is > > required to send them. OTOH, the ASP is not required to rely upon them, > > but it surely can. > > > > --brian > > > > Tolga Asveren wrote: > > (Wed, 01 Mar 2006 08:18:57) > > > Sandeep, > > > > > > I completely agree that examples are necessary. OTOH, I think > > first we need > > > to decide what is the "best" semantics. > > > > > > I really think we should discuss with an open-mind what the NTFY/traffic > > > distribution semantics should be for multiple SGP cases. I am > > in favor of > > > having all ASPSM/ASPTM per SGP. For NTFY, I think we may have a bit more > > > flexibility, considering its advisory nature. BTW, are ASPs relying on > > > NTFY("AS State Change") notifications for any decision, it > > seems to me they > > > shouldn't but there may be some which do in practice. It could > > be also good > > > to get some feedback from more people about that. > > > > > > Thanks, > > > Tolga > > > > > > > -- > > Brian F. G. Bidulock > > bidulock@openss7.org > > http://www.openss7.org/ > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- 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 Mar 03 10:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFC32-0008JV-EH; Fri, 03 Mar 2006 10:18:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFC31-0008Ho-Ts for sigtran@ietf.org; Fri, 03 Mar 2006 10:18:27 -0500 Received: from smtp03.tekelec.com ([198.89.42.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFC30-0000YL-KP for sigtran@ietf.org; Fri, 03 Mar 2006 10:18:27 -0500 Received: from dcex04.tekelec.com (dcex04.tekelec.com [172.28.104.64]) by smtp03.tekelec.com (8.13.5/8.12.10) with ESMTP id k23FFAwE003990 for ; Fri, 3 Mar 2006 09:15:10 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex04.tekelec.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 09:18:25 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 3 Mar 2006 09:18:25 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E71702B88F70@DCEVS2.tekelec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IP aliases and SCTP network paths question Thread-Index: AcY+1bd6lmt8VStLRESAfL2LJd68pQ== From: "Davidson, Mark" To: X-OriginalArrivalTime: 03 Mar 2006 15:18:25.0974 (UTC) FILETIME=[B7D45560:01C63ED5] X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Sigtran] IP aliases and SCTP network paths question X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0246007874==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0246007874== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63ED5.B7D3055E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63ED5.B7D3055E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When using an IP address alias on an interface, depending on the implementation, a heartbeat ack may be sent with an IP "from" address different than the one to which the heartbeat was sent (i.e. if the IP layer is allowed to fill in the "from" address). Should the receiver of the heartbeat ack treat a heartbeat ack with correct payload but unexpected "from" address as valid? =20 -Mark ------_=_NextPart_001_01C63ED5.B7D3055E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
When = using an IP=20 address alias on an interface, depending on the implementation, a = heartbeat ack=20 may be sent with an IP "from" address different than the one to = which the=20 heartbeat was sent (i.e. if the IP layer is allowed to fill in the = "from"=20 address).  Should the receiver of the heartbeat ack treat a = heartbeat ack=20 with correct payload but unexpected "from" address as = valid?
 
-Mark
------_=_NextPart_001_01C63ED5.B7D3055E-- --===============0246007874== 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 --===============0246007874==-- From sigtran-bounces@ietf.org Fri Mar 03 14:25:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFtn-0006yh-4J; Fri, 03 Mar 2006 14:25:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFtm-0006yc-4o for sigtran@ietf.org; Fri, 03 Mar 2006 14:25:10 -0500 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFFtk-0001vf-No for sigtran@ietf.org; Fri, 03 Mar 2006 14:25:10 -0500 Received: from [192.168.1.101] (p508F6AC3.dip.t-dialin.net [80.143.106.195]) by ilsa.franken.de (Postfix) with ESMTP id 2D84B245DA; Fri, 3 Mar 2006 20:25:07 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <58292FA6B3EEFD49AEDAF6597E21E71702B88F70@DCEVS2.tekelec.com> References: <58292FA6B3EEFD49AEDAF6597E21E71702B88F70@DCEVS2.tekelec.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4ddcd49a464ce7a0e8c95a29edaeac9b@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Sigtran] IP aliases and SCTP network paths question Date: Fri, 3 Mar 2006 20:25:04 +0100 To: "Davidson, Mark" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Hi Mark, I would consider the received HEARTBEAT-ACK as one for the path on=20 which the HEARTBEAT was sent to... Best regards Michael On Mar 3, 2006, at 16:18 Uhr, Davidson, Mark wrote: > When using an IP address alias on an interface, depending on the=20 > implementation, a heartbeat ack may be sent with an IP "from" address=20= > different than the one to which=A0the heartbeat was sent (i.e. if the = IP=20 > layer is allowed to fill in the "from" address).=A0 Should the = receiver=20 > of the heartbeat ack treat a heartbeat ack with correct payload but=20 > unexpected "from" address as valid? > =A0 > -Mark_______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Mar 03 15:48:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHCN-0005zU-J5; Fri, 03 Mar 2006 15:48:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHCL-0005qx-CQ for sigtran@ietf.org; Fri, 03 Mar 2006 15:48:25 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFHCJ-0004E8-UN for sigtran@ietf.org; Fri, 03 Mar 2006 15:48:25 -0500 Received: from ns.pigworks.openss7.net (IDENT:cCz8cFHWpLkJVOXtEGdC0TroQV4w4Uk+@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k23KmKq28532; Fri, 3 Mar 2006 13:48:20 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k23KmKW25229; Fri, 3 Mar 2006 13:48:20 -0700 Date: Fri, 3 Mar 2006 13:48:20 -0700 From: "Brian F. G. Bidulock" To: "Davidson, Mark" Subject: Re: [Sigtran] IP aliases and SCTP network paths question Message-ID: <20060303134820.B24924@openss7.org> Mail-Followup-To: "Davidson, Mark" , Michael Tuexen , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E71702B88F70@DCEVS2.tekelec.com> <4ddcd49a464ce7a0e8c95a29edaeac9b@lurchi.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4ddcd49a464ce7a0e8c95a29edaeac9b@lurchi.franken.de>; from Michael.Tuexen@lurchi.franken.de on Fri, Mar 03, 2006 at 08:25:04PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id k23KmKq28532 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Michael Tuexen , 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 Mark, I use the destination address contained in the heartbeat info and ignore the source address for the BEAT ACK for most purposes. However, difficulties might ensue if the source address is not one that corresponds to at least some destination address in the association for the peer receiving the BEAT ACK. --brian Michael Tuexen wrote: (Fri, 03 Mar 2006 20:25:04) > Hi Mark, >=20 > I would consider the received HEARTBEAT-ACK as one for the path on=20 > which the HEARTBEAT was > sent to... >=20 > Best regards > Michael >=20 > On Mar 3, 2006, at 16:18 Uhr, Davidson, Mark wrote: >=20 > > When using an IP address alias on an interface, depending on the=20 > > implementation, a heartbeat ack may be sent with an IP "from" address= =20 > > different than the one to which=A0the heartbeat was sent (i.e. if the= IP=20 > > layer is allowed to fill in the "from" address).=A0 Should the receiv= er=20 > > of the heartbeat ack treat a heartbeat ack with correct payload but=20 > > unexpected "from" address as valid? > > =A0 > > -Mark_______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran >=20 >=20 > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock 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 Mar 03 16:28:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHof-0002r6-Ng; Fri, 03 Mar 2006 16:28:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHlI-0000um-Hb for sigtran@ietf.org; Fri, 03 Mar 2006 16:24:32 -0500 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFHen-0000ob-S7 for sigtran@ietf.org; Fri, 03 Mar 2006 16:17:51 -0500 Received: from [192.168.1.101] (p508F71C9.dip.t-dialin.net [80.143.113.201]) by ilsa.franken.de (Postfix) with ESMTP id 432C0245EC; Fri, 3 Mar 2006 22:17:48 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20060303134820.B24924@openss7.org> References: <58292FA6B3EEFD49AEDAF6597E21E71702B88F70@DCEVS2.tekelec.com> <4ddcd49a464ce7a0e8c95a29edaeac9b@lurchi.franken.de> <20060303134820.B24924@openss7.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Sigtran] IP aliases and SCTP network paths question Date: Fri, 3 Mar 2006 22:17:46 +0100 To: bidulock@openss7.org X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sigtran@ietf.org, "Davidson, Mark" X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Brian, see my comments in-line. Best regards Michael On Mar 3, 2006, at 21:48 Uhr, Brian F. G. Bidulock wrote: > Mark, > > I use the destination address contained in the heartbeat info > and ignore the source address for the BEAT ACK for most purposes. > However, difficulties might ensue if the source address is not > one that corresponds to at least some destination address in the > association for the peer receiving the BEAT ACK. Then it is an out of the blue packet... An ABORT might be sent. > > --brian > > Michael Tuexen wrote: (Fri, 03 Mar 2006 = 20:25:04) >> Hi Mark, >> >> I would consider the received HEARTBEAT-ACK as one for the path on >> which the HEARTBEAT was >> sent to... >> >> Best regards >> Michael >> >> On Mar 3, 2006, at 16:18 Uhr, Davidson, Mark wrote: >> >>> When using an IP address alias on an interface, depending on the >>> implementation, a heartbeat ack may be sent with an IP "from" = address >>> different than the one to which=A0the heartbeat was sent (i.e. if = the=20 >>> IP >>> layer is allowed to fill in the "from" address).=A0 Should the = receiver >>> of the heartbeat ack treat a heartbeat ack with correct payload but >>> unexpected "from" address as valid? >>> =A0 >>> -Mark_______________________________________________ >>> Sigtran mailing list >>> Sigtran@ietf.org >>> https://www1.ietf.org/mailman/listinfo/sigtran >> >> >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www1.ietf.org/mailman/listinfo/sigtran > > --=20 > Brian F. G. Bidulock > 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 Mar 03 16:45:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFI4S-0005xd-N7; Fri, 03 Mar 2006 16:44:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHlA-0000qd-VA for sigtran@ietf.org; Fri, 03 Mar 2006 16:24:24 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFHkh-0001S8-JT for sigtran@ietf.org; Fri, 03 Mar 2006 16:23:56 -0500 Received: from ns.pigworks.openss7.net (IDENT:tsQiI94yywWkCjcHLCA67K7PUrPtW8Hd@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k23LNsq29214; Fri, 3 Mar 2006 14:23:54 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k23LNsF25610; Fri, 3 Mar 2006 14:23:54 -0700 Date: Fri, 3 Mar 2006 14:23:54 -0700 From: "Brian F. G. Bidulock" To: Michael Tuexen Subject: Re: [Sigtran] IP aliases and SCTP network paths question Message-ID: <20060303142354.C24924@openss7.org> Mail-Followup-To: Michael Tuexen , "Davidson, Mark" , sigtran@ietf.org References: <58292FA6B3EEFD49AEDAF6597E21E71702B88F70@DCEVS2.tekelec.com> <4ddcd49a464ce7a0e8c95a29edaeac9b@lurchi.franken.de> <20060303134820.B24924@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 Michael.Tuexen@lurchi.franken.de on Fri, Mar 03, 2006 at 10:17:46PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sigtran@ietf.org, "Davidson, Mark" X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Michael, Michael Tuexen wrote: (Fri, 03 Mar 2006 22:17:46) > > > > I use the destination address contained in the heartbeat info > > and ignore the source address for the BEAT ACK for most purposes. > > However, difficulties might ensue if the source address is not > > one that corresponds to at least some destination address in the > > association for the peer receiving the BEAT ACK. > Then it is an out of the blue packet... An ABORT might be sent. Yes, that was my point. --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 Sat Mar 04 08:47:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFX69-0005X8-Mt; Sat, 04 Mar 2006 08:47:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFX68-0005Wo-PT for sigtran@ietf.org; Sat, 04 Mar 2006 08:47:04 -0500 Received: from mx2.consultant.turkcell.com.tr ([212.252.168.230] helo=NEWVW01.turkcell.com.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFX68-0000C5-6F for sigtran@ietf.org; Sat, 04 Mar 2006 08:47:04 -0500 X-Disclaimer-Added-By: turkcell.com.tr Received: from HUB3401.turkcell.entp.tgc ([10.200.123.127]) by exi3401.turkcell.entp.tgc with Microsoft SMTPSVC(6.0.3790.2499); Sat, 4 Mar 2006 15:46:58 +0200 Received: from exhmbx03.turkcell.entp.tgc ([10.200.125.25]) by HUB3401.turkcell.entp.tgc with Microsoft SMTPSVC(6.0.3790.2499); Sat, 4 Mar 2006 15:46:58 +0200 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Mar 2006 15:46:42 +0200 Message-ID: <864E549A60371F428A540F808FBD4382052DFA@exhmbx03.turkcell.entp.tgc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Chunk bundling indicator ? thread-index: AcY/khHPQfc2GlBUTd+m6LM8tD/qjQ== From: To: X-OriginalArrivalTime: 04 Mar 2006 13:46:58.0669 (UTC) FILETIME=[1B8DC9D0:01C63F92] X-imss-version: 2.038 X-imss-result: Passed X-imss-scores: Clean:68.19634 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sigtran] Chunk bundling indicator ? 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 Dear Experts, Is there any flag in an SCTP packet indicating that there is many chunks = that are bundled together ? I got some captures with Ethereal and I see = that a couple of different application messages behind one-single SCTP = header but I couldn't find if it is stated/indicated in the SCTP header = ? Any feedback will be appreciated. Regards B=FClent YILMAZ Operations/R&D Network Technologies and Architecture ************************************************************************ Bu elektronik posta ve onunla iletilen b=FCt=FCn dosyalar sadece = g=F6ndericisi tarafindan almasi amaclanan yetkili gercek ya da t=FCzel = kisinin kullanimi icindir. Eger s=F6z konusu yetkili alici degilseniz = bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, = y=F6nlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik = postayi derhal silmeniz gerekmektedir. TURKCELL bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu = konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin = ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve = saklanmasindan sorumlu degildir. Bu mesajdaki g=F6r=FCsler yalnizca = g=F6nderen kisiye aittir ve TURKCELLin g=F6r=FCslerini yansitmayabilir Bu e-posta bilinen b=FCt=FCn bilgisayar vir=FCslerine karsi taranmistir. ************************************************************************ This e-mail and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you are not the intended recipient you are hereby notified = that any dissemination, forwarding, copying or use of any of the = information is strictly prohibited, and the e-mail should immediately be = deleted. TURKCELL makes no warranty as to the accuracy or completeness of any = information contained in this message and hereby excludes any liability = of any kind for the information contained therein or for the information = transmission, reception, storage or use of such in any way whatsoever. = The opinions expressed in this message belong to sender alone and may = not necessarily reflect the opinions of TURKCELL. This e-mail has been scanned for all known computer viruses. ************************************************************************ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Sat Mar 04 11:23:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFZWu-0003EW-0Y; Sat, 04 Mar 2006 11:22:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFZWt-0003EB-48 for sigtran@ietf.org; Sat, 04 Mar 2006 11:22:51 -0500 Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFZWr-0005Jp-TJ for sigtran@ietf.org; Sat, 04 Mar 2006 11:22:51 -0500 Received: from verizon.net ([71.96.150.44]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IVM00A8U2TVLDI9@vms046.mailsrvcs.net> for sigtran@ietf.org; Sat, 04 Mar 2006 10:22:44 -0600 (CST) Date: Sat, 04 Mar 2006 10:22:44 -0600 From: Tom George In-reply-to: Cc: sigtran@ietf.org Message-id: <4409BED4.5080500@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Macintosh; N; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sigtran] IETF meeting? 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 Apologies for the non-technical use of the list, but are any SIGTRAN people coming to Dallas for the IETF meeting this month? I saw Lyndon's name on the registration list. tomG. -- Tom George in Plano, TX _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Sat Mar 04 16:42:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFeW6-00086i-G6; Sat, 04 Mar 2006 16:42:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFeW5-0007tt-6U for sigtran@ietf.org; Sat, 04 Mar 2006 16:42:21 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFeId-0006wL-O0 for sigtran@ietf.org; Sat, 04 Mar 2006 16:28:29 -0500 Received: from ns.pigworks.openss7.net (IDENT:narLq0zuhark1ZbVzvxMUM0BcQjUTNE/@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k24LSMq25295; Sat, 4 Mar 2006 14:28:22 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k24LSMO10815; Sat, 4 Mar 2006 14:28:22 -0700 Date: Sat, 4 Mar 2006 14:28:22 -0700 From: "Brian F. G. Bidulock" To: bulent.yilmaz@turkcell.com.tr Subject: Re: [Sigtran] Chunk bundling indicator ? Message-ID: <20060304142822.A7420@openss7.org> Mail-Followup-To: bulent.yilmaz@turkcell.com.tr, sigtran@ietf.org References: <864E549A60371F428A540F808FBD4382052DFA@exhmbx03.turkcell.entp.tgc> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <864E549A60371F428A540F808FBD4382052DFA@exhmbx03.turkcell.entp.tgc>; from bulent.yilmaz@turkcell.com.tr on Sat, Mar 04, 2006 at 03:46:42PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id k24LSMq25295 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 bulent.yilmaz, B and E bits in the DATA Chunk header. --brian bulent.yilmaz@turkcell.com.tr wrote: (Sat, 04 Mar= 2006 15:46:42) > Dear Experts, >=20 > Is there any flag in an SCTP packet indicating that there is many chunk= s that are bundled together ? I got some captures with Ethereal and I see= that a couple of different application messages behind one-single SCTP h= eader but I couldn't find if it is stated/indicated in the SCTP header ? >=20 > Any feedback will be appreciated. >=20 > Regards >=20 > B=FClent YILMAZ > Operations/R&D > Network Technologies and Architecture >=20 >=20 >=20 >=20 > ***********************************************************************= * > Bu elektronik posta ve onunla iletilen b=FCt=FCn dosyalar sadece g=F6nd= ericisi tarafindan almasi amaclanan yetkili gercek ya da t=FCzel kisinin = kullanimi icindir. Eger s=F6z konusu yetkili alici degilseniz bu elektro= nik postanin icerigini aciklamaniz, kopyalamaniz, y=F6nlendirmeniz ve kul= lanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz ger= ekmektedir. > TURKCELL bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu = konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin n= e sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve sakla= nmasindan sorumlu degildir. Bu mesajdaki g=F6r=FCsler yalnizca g=F6nderen= kisiye aittir ve TURKCELLin g=F6r=FCslerini yansitmayabilir > Bu e-posta bilinen b=FCt=FCn bilgisayar vir=FCslerine karsi taranmistir. > ***********************************************************************= * > This e-mail and any files transmitted with it are confidential and inte= nded solely for the use of the individual or entity to whom they are addr= essed. If you are not the intended recipient you are hereby notified that= any dissemination, forwarding, copying or use of any of the information = is strictly prohibited, and the e-mail should immediately be deleted. > TURKCELL makes no warranty as to the accuracy or completeness of any in= formation contained in this message and hereby excludes any liability of = any kind for the information contained therein or for the information tra= nsmission, reception, storage or use of such in any way whatsoever. The = opinions expressed in this message belong to sender alone and may not nec= essarily reflect the opinions of TURKCELL. > This e-mail has been scanned for all known computer viruses. > ***********************************************************************= * >=20 >=20 > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Sun Mar 05 06:16:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFrEC-0002y2-Ql; Sun, 05 Mar 2006 06:16:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFrEA-0002xs-Ax for sigtran@ietf.org; Sun, 05 Mar 2006 06:16:42 -0500 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFrEA-00028m-07 for sigtran@ietf.org; Sun, 05 Mar 2006 06:16:42 -0500 Received: from [192.168.1.101] (p5481F86D.dip.t-dialin.net [84.129.248.109]) by ilsa.franken.de (Postfix) with ESMTP id 282A2245C9; Sun, 5 Mar 2006 12:16:39 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <864E549A60371F428A540F808FBD4382052DFA@exhmbx03.turkcell.entp.tgc> References: <864E549A60371F428A540F808FBD4382052DFA@exhmbx03.turkcell.entp.tgc> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2e084ceeaf96816e0732752603c19566@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Sigtran] Chunk bundling indicator ? Date: Sun, 5 Mar 2006 12:16:36 +0100 To: X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Hi B=FClent, there is no indication in the SCTP common header how many chunks are =20 present in the packet. Any number (even 0) is allowed. Because the chunks have a tag-length-value (TLV) structure the receiver =20= and even ethereal can understand the structure of the packet. It is OK to have multiple chunks (even, multiple DATA chunks) in one =20 packet. Best regards Michael On Mar 4, 2006, at 14:46 Uhr, wrote: > Dear Experts, > > Is there any flag in an SCTP packet indicating that there is many =20 > chunks that are bundled together ? I got some captures with Ethereal =20= > and I see that a couple of different application messages behind =20 > one-single SCTP header but I couldn't find if it is stated/indicated =20= > in the SCTP header ? > > Any feedback will be appreciated. > > Regards > > B=FClent YILMAZ > Operations/R&D > Network Technologies and Architecture > > > > > = ***********************************************************************=20= > * > Bu elektronik posta ve onunla iletilen b=FCt=FCn dosyalar sadece =20 > g=F6ndericisi tarafindan almasi amaclanan yetkili gercek ya da t=FCzel = =20 > kisinin kullanimi icindir. Eger s=F6z konusu yetkili alici degilseniz = =20 > bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, =20 > y=F6nlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik =20= > postayi derhal silmeniz gerekmektedir. > TURKCELL bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu = =20 > konusunda herhangi bir garanti vermemektedir. Bu nedenle bu =20 > bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, =20 > alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki g=F6r=FCsl= er =20 > yalnizca g=F6nderen kisiye aittir ve TURKCELLin g=F6r=FCslerini =20 > yansitmayabilir > Bu e-posta bilinen b=FCt=FCn bilgisayar vir=FCslerine karsi = taranmistir. > = ***********************************************************************=20= > * > This e-mail and any files transmitted with it are confidential and =20 > intended solely for the use of the individual or entity to whom they =20= > are addressed. If you are not the intended recipient you are hereby =20= > notified that any dissemination, forwarding, copying or use of any of =20= > the information is strictly prohibited, and the e-mail should =20 > immediately be deleted. > TURKCELL makes no warranty as to the accuracy or completeness of any =20= > information contained in this message and hereby excludes any =20 > liability of any kind for the information contained therein or for the = =20 > information transmission, reception, storage or use of such in any way = =20 > whatsoever. The opinions expressed in this message belong to sender =20= > alone and may not necessarily reflect the opinions of TURKCELL. > This e-mail has been scanned for all known computer viruses. > = ***********************************************************************=20= > * > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 06 00:10:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG7zY-0005bb-M3; Mon, 06 Mar 2006 00:10:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG7zX-0005bW-JX for sigtran@ietf.org; Mon, 06 Mar 2006 00:10:43 -0500 Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG7zW-0007Gg-CW for sigtran@ietf.org; Mon, 06 Mar 2006 00:10:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Mar 2006 00:06:33 -0500 Message-ID: <0901D1988E815341A0103206A834DA07BC839C@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: survey of UA implementations Thread-Index: AcZA270G2MiuF/LTSsenMqKWLQ989g== From: "Ong, Lyndon" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: [Sigtran] survey of UA implementations 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="===============1536226827==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1536226827== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C640DC.468B68C1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C640DC.468B68C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 To get an idea of the actual usage of the specs, I would like to take a poll for input from those people who have done implementations and products for the following information: =20 -- what UAs have you implemented? -- what UAs have you tested with others? -- what UAs have you productized? -- what UAs have been deployed in active use? -- what kind of applications have they been used for? =20 Responses can be sent privately to me if desired (note I no longer work for a company that has any products in this area). =20 I'll compile any responses and put the results out on the mailing list, leaving out names. =20 Thanks, =20 Lyndon =20 =20 ------_=_NextPart_001_01C640DC.468B68C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Folks,
 
To get = an idea of=20 the actual usage of the specs, I would like to take a = poll
for input from those people who have = done
implementations and=20 products for the following information:
 
-- = what UAs have you=20 implemented?
-- = what UAs have you=20 tested with others?
-- = what UAs have you=20 productized?
-- = what UAs have=20 been deployed in active use?
-- what kind of applications have they been used=20 for?
 
Responses can be sent privately to me if desired = (note I no=20 longer work for
a company that has any products in this=20 area).
 
I'll compile any responses and put the results out = on the=20 mailing list,
leaving out names.
 
Thanks,
 
Lyndon
 
 
------_=_NextPart_001_01C640DC.468B68C1-- --===============1536226827== 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 --===============1536226827==-- From sigtran-bounces@ietf.org Mon Mar 06 05:58:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDPj-0005fP-FN; Mon, 06 Mar 2006 05:58:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDPj-0005fI-4y for sigtran@ietf.org; Mon, 06 Mar 2006 05:58:07 -0500 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGDPh-00045H-Ml for sigtran@ietf.org; Mon, 06 Mar 2006 05:58:07 -0500 Received: from [192.168.1.101] (p5481D180.dip.t-dialin.net [84.129.209.128]) by ilsa.franken.de (Postfix) with ESMTP id A96F0245F8; Mon, 6 Mar 2006 11:58:01 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <0901D1988E815341A0103206A834DA07BC839C@mdmxm02.ciena.com> References: <0901D1988E815341A0103206A834DA07BC839C@mdmxm02.ciena.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <980e5be89d34e39c2a144e25719e7d20@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Sigtran] survey of UA implementations Date: Mon, 6 Mar 2006 11:58:01 +0100 To: "Ong, Lyndon" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Hi Lyndon, see my comments in-line. Best regards Michael On Mar 6, 2006, at 6:06 Uhr, Ong, Lyndon wrote: > Hi Folks, > =A0 > To get an idea of the actual usage of the specs, I would like to take=20= > a poll > for input from those people who have done > > implementations and products for the following information: > =A0 > -- what UAs have you implemented? > -- what UAs have you tested with others? > -- what UAs have you productized? > -- what UAs have been deployed in active use? > -- what kind of applications have they been used for? It is not an implementation and I'm not sure if it counts as a product=20= (since it is free), but Ethereal (http://www.ethereal.com) is a packet analyzer which=20 supports all SIGTRAN protocols. It has been tested at every SIGTRAN Interop and I think it is in active=20= use... > =A0 > Responses can be sent privately to me if desired (note I no longer=20 > work for > a company that has any products in this area). > =A0 > I'll compile any responses and put the results out on the mailing = list, > leaving out names. > =A0 > Thanks, > =A0 > Lyndon > =A0 > =A0_______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 06 15:41:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMWY-0003d9-WD; Mon, 06 Mar 2006 15:41:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMWX-0003a2-5W for sigtran@ietf.org; Mon, 06 Mar 2006 15:41:45 -0500 Received: from smtp02.tekelec.com ([198.89.42.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMWV-0000tC-Sy for sigtran@ietf.org; Mon, 06 Mar 2006 15:41:45 -0500 Received: from dcex05.tekelec.com (dcex05.tekelec.com [172.28.104.65]) by smtp02.tekelec.com (8.13.5/8.12.10) with ESMTP id k26Kavtw012189 for ; Mon, 6 Mar 2006 14:36:57 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex05.tekelec.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 14:41:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Mar 2006 14:41:42 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E71702BCAEA3@DCEVS2.tekelec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RCT Question Thread-Index: AcZBXmA7eOFwcES3Seqvtw1LYAFByA== From: "Erickson, Mark" To: X-OriginalArrivalTime: 06 Mar 2006 20:41:43.0157 (UTC) FILETIME=[60B0D250:01C6415E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Sigtran] RCT Question X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1951734785==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1951734785== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6415E.60ABB2E6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6415E.60ABB2E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: =20 I know there's been a lot of discussion regarding congestion and congestion status from different perspectives. In reviewing the thread histories, I've tried to understand why an RCT isn't translated into a message the SGP then forwards on to the ASP but rather is terminated at the SGP, however some of the threads are pretty involved. Can anyone summarize what the reasoning was for this? =20 Thanks, Mark Erickson ------_=_NextPart_001_01C6415E.60ABB2E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All:

 

I know there’s been a lot of discussion = regarding congestion and congestion status from different perspectives.  In = reviewing the thread histories, I’ve tried to understand why an RCT isn’t translated into a message the SGP then forwards on to the ASP but rather = is terminated at the SGP, however some of the threads are pretty involved.  Can = anyone summarize what the reasoning was for this?

 

Thanks,

Mark Erickson

------_=_NextPart_001_01C6415E.60ABB2E6-- --===============1951734785== 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 --===============1951734785==-- From sigtran-bounces@ietf.org Mon Mar 06 15:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMcZ-0007vl-UV; Mon, 06 Mar 2006 15:47:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMcY-0007vg-1u for sigtran@ietf.org; Mon, 06 Mar 2006 15:47:58 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMcW-00016D-PZ for sigtran@ietf.org; Mon, 06 Mar 2006 15:47:58 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 6F0830F2E1 for ; Mon, 6 Mar 2006 15:47:56 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k26Klqe7014827 for ; Mon, 6 Mar 2006 15:47:55 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] RCT Question Date: Mon, 6 Mar 2006 15:27:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <58292FA6B3EEFD49AEDAF6597E21E71702BCAEA3@DCEVS2.tekelec.com> X-Scanned-By: MIMEDefang 2.40 Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Mark, The main reason is RTC is used/consumed/processed by MTP3 and MTP3 is terminated in a SG -even for cases where AS has a different PC then the PC of SG, which is directly connected to SS7 network-. Thanks, Tolga -----Original Message----- From: Erickson, Mark [mailto:Mark.Erickson@tekelec.com] Sent: Monday, March 06, 2006 3:42 PM To: sigtran@ietf.org Subject: [Sigtran] RCT Question All: I know there's been a lot of discussion regarding congestion and congestion status from different perspectives. In reviewing the thread histories, I've tried to understand why an RCT isn't translated into a message the SGP then forwards on to the ASP but rather is terminated at the SGP, however some of the threads are pretty involved. Can anyone summarize what the reasoning was for this? Thanks, Mark Erickson _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 06 19:35:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGQAX-0005zX-Qn; Mon, 06 Mar 2006 19:35:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGQAW-0005zS-OS for sigtran@ietf.org; Mon, 06 Mar 2006 19:35:16 -0500 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGQAV-0000SJ-A7 for sigtran@ietf.org; Mon, 06 Mar 2006 19:35:16 -0500 Received: from [192.168.1.101] (p5481C110.dip.t-dialin.net [84.129.193.16]) by ilsa.franken.de (Postfix) with ESMTP id 13B8B245DF; Tue, 7 Mar 2006 01:35:10 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <0901D1988E815341A0103206A834DA07BC839C@mdmxm02.ciena.com> References: <0901D1988E815341A0103206A834DA07BC839C@mdmxm02.ciena.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Sigtran] survey of UA implementations Date: Tue, 7 Mar 2006 01:35:09 +0100 To: "Ong, Lyndon" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Hi Lyndon, I'm not sure whether also testtools count... The ETSI M3UA conformance tests have been implemented under a BSD license and are available at http://sctp.fh-muenster.de The ASP tests have been tested at the last SIGTRAN Interop and all mandatory SGP tests have been used for conformance testing at the Siemens Center for Quality Engineering. Best regards Michael On Mar 6, 2006, at 6:06 Uhr, Ong, Lyndon wrote: > Hi Folks, > =A0 > To get an idea of the actual usage of the specs, I would like to take=20= > a poll > for input from those people who have done > > implementations and products for the following information: > =A0 > -- what UAs have you implemented? > -- what UAs have you tested with others? > -- what UAs have you productized? > -- what UAs have been deployed in active use? > -- what kind of applications have they been used for? > =A0 > Responses can be sent privately to me if desired (note I no longer=20 > work for > a company that has any products in this area). > =A0 > I'll compile any responses and put the results out on the mailing = list, > leaving out names. > =A0 > Thanks, > =A0 > Lyndon > =A0 > =A0_______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Mar 07 16:20:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjb6-0005xP-EV; Tue, 07 Mar 2006 16:20:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjb5-0005xF-6a for sigtran@ietf.org; Tue, 07 Mar 2006 16:19:59 -0500 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 1FGjb2-0007Xj-T6 for sigtran@ietf.org; Tue, 07 Mar 2006 16:19:59 -0500 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 k27LJqr2008813; Tue, 7 Mar 2006 16:19:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] survey of UA implementations Date: Tue, 7 Mar 2006 16:19:51 -0500 Message-ID: <849535E338E99741B7F7413F73253EDB034B755E@us-nj-mail1.comverse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] survey of UA implementations Thread-Index: AcZBDQZBAGkTuyDaTZWKd9EmSP2wdwBHc1bw From: "Haresign Lincoln" To: "Michael Tuexen" , "Ong, Lyndon" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org For some reason, I didn't receive Lyndon's original email, but only = Michael's follow-up. We have implemented: M2PA M3UA SUA We done limited testing with all three against various test devices, = switches, and IETF interops and more extensive testing with M3UA. = Currently, M3UA is getting the most productization and is deployed in = several sites for a couple years. SUA is currently being used for our = internal architecture and typically does not interact with 3rd party = equipment. Since we are building eqiupment for the edge of the network, = we haven't had any customer interest in M2PA which we typically see = being used in the CORE of the network. We build Voice Mail systems, = SMSCs, PrePaid systems, Intelligent Peripherals, and many other SCP or = SCP-like boxes for deploying Value Added services in the wireless and = wireline networks. Regards, Lincoln -----Original Message----- From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 Sent: Monday, March 06, 2006 5:58 AM To: Ong, Lyndon Cc: sigtran@ietf.org Subject: Re: [Sigtran] survey of UA implementations Hi Lyndon, see my comments in-line. Best regards Michael On Mar 6, 2006, at 6:06 Uhr, Ong, Lyndon wrote: > Hi Folks, > =A0 > To get an idea of the actual usage of the specs, I would like to take=20 > a poll for input from those people who have done > > implementations and products for the following information: > =A0 > -- what UAs have you implemented? > -- what UAs have you tested with others? > -- what UAs have you productized? > -- what UAs have been deployed in active use? > -- what kind of applications have they been used for? It is not an implementation and I'm not sure if it counts as a product = (since it is free), but Ethereal (http://www.ethereal.com) is a packet = analyzer which supports all SIGTRAN protocols. It has been tested at every SIGTRAN Interop and I think it is in active = use... > =A0 > Responses can be sent privately to me if desired (note I no longer=20 > work for a company that has any products in this area). > =A0 > I'll compile any responses and put the results out on the mailing=20 > list, leaving out names. > =A0 > Thanks, > =A0 > Lyndon > =A0 > =A0_______________________________________________ > 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 -------------------------------------------------------------------- This email message has been scanned by Comverse mail security system _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Mar 08 16:19:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH63e-0002su-Mh; Wed, 08 Mar 2006 16:18:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5kV-0001Oh-8X; Wed, 08 Mar 2006 15:59:11 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5kU-0002aq-OS; Wed, 08 Mar 2006 15:59:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko3BX001327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5bf-0002tQ-Hm; Wed, 08 Mar 2006 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 08 Mar 2006 15:50:03 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sigtran@ietf.org Subject: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-implementor-guide-03.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Signaling Transport Working Group of the IETF. Title : SUA Implementor's guide Author(s) : L. Coene, J. Loughney Filename : draft-ietf-sigtran-sua-implementor-guide-03.txt Pages : 35 Date : 2006-3-8 This document contains a compilation of all defects found up until the publication date for SUA [RFC3868] [1]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of SUA to clarify errors in the original SUA document. This document updates RFC3868 and text within this document supersedes the text found in RFC3868. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sua-implementor-guide-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sigtran-sua-implementor-guide-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sigtran-sua-implementor-guide-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-8145831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sigtran-sua-implementor-guide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sigtran-sua-implementor-guide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-8145831.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --NextPart-- From sigtran-bounces@ietf.org Fri Mar 10 19:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHrgI-0004ts-LQ; Fri, 10 Mar 2006 19:10:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHrgG-0004rq-Jr for sigtran@ietf.org; Fri, 10 Mar 2006 19:10:00 -0500 Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHrgF-0005yj-BH for sigtran@ietf.org; Fri, 10 Mar 2006 19:10:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sigtran] survey of UA implementations Date: Fri, 10 Mar 2006 19:09:55 -0500 Message-ID: <0901D1988E815341A0103206A834DA07BC88EE@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] survey of UA implementations Thread-Index: AcZA270G2MiuF/LTSsenMqKWLQ989gDw3ocA From: "Ong, Lyndon" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: "Peterson, Jon" 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="===============2140957532==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============2140957532== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C644A0.1B2DA3E1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C644A0.1B2DA3E1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 Survey results so far show the following (out of 7 companies responding): =20 iua: 3 implementations=20 m2ua: 3 implementations=20 m3ua: 7 implementations=20 sua: 5 implementations m2pa: 5 implementations v5ua: 1 implementation dua: 2 implementations =20 Generally almost all of the implementations have been tested and deployed as products, although one respondent noted that their m2pa implementation was initially productized but is no longer deployed for lack of interest. =20 Applications used included signaling backhaul (of course), as well as SMS, voicemail systems, intelligent peripherals and link consolidation. =20 Thank you for your help! =20 Cheers, =20 Lyndon ------_=_NextPart_001_01C644A0.1B2DA3E1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Folks,
 
Survey results so far show the following (out = of 7=20 companies responding):
 
iua: 3 implementations
m2ua: 3 implementations=20
m3ua: 7 implementations
sua: 5 implementations
m2pa: 5 implementations
v5ua: 1 implementation
dua: 2 implementations
 
Generally almost all of the implementations = have been=20 tested and deployed as products,
although one respondent noted that their m2pa = implementation was initially productized
but is no longer deployed for lack of=20 interest.
 
Applications used included signaling backhaul = (of=20 course), as well as SMS, voicemail
systems, intelligent peripherals and link=20 consolidation.
 
Thank you for your help!
 
Cheers,
 
Lyndon
------_=_NextPart_001_01C644A0.1B2DA3E1-- --===============2140957532== 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 --===============2140957532==-- From sigtran-bounces@ietf.org Wed Mar 15 16:30:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdZX-0001JS-Kp; Wed, 15 Mar 2006 16:30:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdZW-0001JN-IU for sigtran@ietf.org; Wed, 15 Mar 2006 16:30:22 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJdZU-0008Q4-1m for sigtran@ietf.org; Wed, 15 Mar 2006 16:30:22 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k2FLUDs5018984; Wed, 15 Mar 2006 13:30:16 -0800 Received: from OVE1WNEXCB02.vcorp.ad.vrsn.com ([10.60.13.34]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 13:30:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sigtran] survey of UA implementations Date: Wed, 15 Mar 2006 15:30:12 -0600 Message-ID: <122A5731B827474C99ED552C6BFE23ED274378@OVE1WNEXCB02.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] survey of UA implementations Thread-Index: AcZA270G2MiuF/LTSsenMqKWLQ989gDw3ocAAPYUJsA= From: "McCandless, Kevin" To: "Ong, Lyndon" , X-OriginalArrivalTime: 15 Mar 2006 21:30:13.0532 (UTC) FILETIME=[A5208DC0:01C64877] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: "Peterson, Jon" 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="===============2129267223==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============2129267223== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64877.A4DCA205" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64877.A4DCA205 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We also support the following as access methods to our network: SUA, M3UA, and M2PA. =20 ________________________________ From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Friday, March 10, 2006 6:10 PM To: sigtran@ietf.org Cc: Peterson, Jon Subject: RE: [Sigtran] survey of UA implementations =20 Hi Folks, =20 Survey results so far show the following (out of 7 companies responding): =20 iua: 3 implementations=20 m2ua: 3 implementations=20 m3ua: 7 implementations=20 sua: 5 implementations m2pa: 5 implementations v5ua: 1 implementation dua: 2 implementations =20 Generally almost all of the implementations have been tested and deployed as products, although one respondent noted that their m2pa implementation was initially productized but is no longer deployed for lack of interest. =20 Applications used included signaling backhaul (of course), as well as SMS, voicemail systems, intelligent peripherals and link consolidation. =20 Thank you for your help! =20 Cheers, =20 Lyndon ------_=_NextPart_001_01C64877.A4DCA205 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We also support the following as = access methods to our network:  SUA, M3UA, and = M2PA.

 

From: Ong, = Lyndon [mailto:Lyong@Ciena.com]
Sent: Friday, March 10, = 2006 6:10 PM
To: sigtran@ietf.org
Cc: Peterson, Jon
Subject: RE: [Sigtran] = survey of UA implementations

 

Hi = Folks,

 

Survey results so far show the = following (out of 7 companies responding):

 

iua: 3 implementations =

m2ua: 3 implementations =

m3ua: 7 implementations =

sua: 5 = implementations

m2pa: 5 = implementations

v5ua: 1 = implementation

dua: 2 = implementations

 

Generally almost all of the implementations have been tested and deployed as = products,

although one respondent noted that = their m2pa implementation was initially = productized

but is no longer deployed for lack = of interest.

 

Applications used included = signaling backhaul (of course), as well as SMS, = voicemail

systems, intelligent peripherals = and link consolidation.

 

Thank you for your = help!

 

Cheers,

=

 

Lyndon

------_=_NextPart_001_01C64877.A4DCA205-- --===============2129267223== 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 --===============2129267223==-- From sigtran-bounces@ietf.org Wed Mar 15 20:35:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhP3-0003lX-HY; Wed, 15 Mar 2006 20:35:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhP2-0003lM-M2 for sigtran@ietf.org; Wed, 15 Mar 2006 20:35:48 -0500 Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJhP0-0007WA-AY for sigtran@ietf.org; Wed, 15 Mar 2006 20:35:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Mar 2006 20:34:26 -0500 Message-ID: <0901D1988E815341A0103206A834DA07BC8C11@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: future work Thread-Index: AcZHEUmePfIgYdAFTbadKbGE9CRv2A== From: "Ong, Lyndon" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Subject: [Sigtran] future work 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="===============0054743757==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0054743757== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64899.E9FB6F49" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64899.E9FB6F49 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 I've received further input on sigtran UA implementations which I will take into account and send out an updated survey results email at the end of the week. =20 In the meantime, we need to start a discussion on where this WG is going to go. We have now been moved into the RAI (Real-time Apps and Infrastructure) Area, probably continuing to have Jon Peterson as our lead Area Director since he is moving as well. =20 Our WG has basically completed its original objectives, with some continuing work on interop testing results for SUA and M2PA. In general, the number of active participants has fallen considerably since its original days, although there continues to be a fair amount of email traffic (albeit bursty). =20 One legitimate and probably sensible option is to close the group down soon and merge the work into a broader group, as SCTP was merged into the TSV WG. It's likely that an RAI WG will be formed for such purposes. =20 Another alternative is to identify specific additional work items and try to recharter the WG. This to me depends on whether we have additional work items that have broad support, and if we have sufficient momentum as a group to complete them. =20 I'd like to solicit feedback from the list on whether people feel that our target should be to close down the WG, or whether it should be rechartering, and if the latter, what work items you believe need to be addressed. Taking a look over the various proposals, the following come up: =20 1. M3UA deployment considerations draft=20 -- this seems to me to have the most support and be most useful 2. Test specifications (m2pa and m2ua exist as drafts) -- I have feedback from Jon that test specs are OK work items - however, other bodies seem to already have test specs done 3. M3UA ipsp-to-ipsp draft 4. M3UA sg-to-sg draft 5. Brian asp extensions framework draft 6. Brian correlation ID draft 7. Brian isdn user part UA draft 8. Brian load grouping extension draft 9. Brian load selection draft 10. Brian registration extensions draft 11. Brian sg information draft 12. Brian tcap UA draft =20 =20 Cheers, =20 Lyndon =20 ------_=_NextPart_001_01C64899.E9FB6F49 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Folks,
 
I've = received=20 further input on sigtran UA implementations which I = will
take = into account=20 and send out an updated survey results email at
the = end of the=20 week.
 
In the = meantime, we=20 need to start a discussion on where this WG is
going = to go. =20 We have now been moved into the RAI (Real-time
Apps = and=20 Infrastructure) Area, probably continuing to have = Jon
Peterson as our lead=20 Area Director since he is moving as well.
 
Our WG = has basically=20 completed its original objectives, with some
continuing work on=20 interop testing results for SUA and M2PA.  In
general, the number=20 of active participants has fallen considerably
since = its original=20 days, although there continues to be a fair amount
of = email traffic=20 (albeit bursty).
 
One = legitimate and=20 probably sensible option is to close the group
down = soon and merge=20 the work into a broader group, as SCTP was
merged = into the TSV=20 WG.  It's likely that an RAI WG will be formed
for = such=20 purposes.
 
Another alternative=20 is to identify specific additional work items and
try to = recharter the=20 WG.  This to me depends on whether we
have = additional work=20 items that have broad support, and if we have
sufficient momentum=20 as a group to complete them.
 
I'd = like to solicit=20 feedback from the list on whether people feel that
our = target should be=20 to close down the WG, or whether it should
be = rechartering, and=20 if the latter, what work items you believe need
to be=20 addressed.
Taking = a look over=20 the various proposals, the following come up:
 
1.=20 M3UA=20 deployment considerations draft
-- = this seems to me=20 to have the most support and be most useful
2. = Test=20 specifications (m2pa and m2ua exist as drafts)
-- I = have feedback=20 from Jon that test specs are OK work items - = however,
other = bodies seem to=20 already have test specs done
3. = M3UA ipsp-to-ipsp=20 draft
4. = M3UA sg-to-sg=20 draft
5. = Brian asp=20 extensions framework draft
6. = Brian correlation=20 ID draft
7. = Brian isdn=20 user part UA draft
8. = Brian load=20 grouping extension draft
9. = Brian load=20 selection draft
10.=20 Brian registration extensions draft
11. Brian sg information draft
12. = Brian tcap=20 UA draft
 
 
Cheers,
 
Lyndon
 
------_=_NextPart_001_01C64899.E9FB6F49-- --===============0054743757== 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 --===============0054743757==-- From sigtran-bounces@ietf.org Thu Mar 16 10:32:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuT0-0005hO-Uv; Thu, 16 Mar 2006 10:32:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuSz-0005gn-St for sigtran@ietf.org; Thu, 16 Mar 2006 10:32:45 -0500 Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJuSz-0005k0-Fa for sigtran@ietf.org; Thu, 16 Mar 2006 10:32:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Mar 2006 10:32:28 -0500 Message-ID: <0901D1988E815341A0103206A834DA07BC8C67@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: future work Thread-Index: AcZHEUmePfIgYdAFTbadKbGE9CRv2A== From: "Ong, Lyndon" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Subject: [Sigtran] future work 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="===============0426684725==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0426684725== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6490E.D520CE99" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6490E.D520CE99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 I've received further input on sigtran UA implementations which I will take into account and send out an updated survey results email at the end of the week. =20 In the meantime, we need to start a discussion on where this WG is going to go. We have now been moved into the RAI (Real-time Apps and Infrastructure) Area, probably continuing to have Jon Peterson as our lead Area Director since he is moving as well. =20 Our WG has basically completed its original objectives, with some continuing work on interop testing results for SUA and M2PA. In general, the number of active participants has fallen considerably since its original days, although there continues to be a fair amount of email traffic (albeit bursty). =20 One legitimate and probably sensible option is to close the group down soon and merge the work into a broader group, as SCTP was merged into the TSV WG. It's likely that an RAI WG will be formed for such purposes. =20 Another alternative is to identify specific additional work items and try to recharter the WG. This to me depends on whether we have additional work items that have broad support, and if we have sufficient momentum as a group to complete them. =20 I'd like to solicit feedback from the list on whether people feel that our target should be to close down the WG, or whether it should be rechartering, and if the latter, what work items you believe need to be addressed. Taking a look over the various proposals, the following come up: =20 1. M3UA deployment considerations draft=20 -- this seems to me to have the most support and be most useful 2. Test specifications (m2pa and m2ua exist as drafts) -- I have feedback from Jon that test specs are OK work items - however, other bodies seem to already have test specs done 3. M3UA ipsp-to-ipsp draft 4. M3UA sg-to-sg draft 5. Brian asp extensions framework draft 6. Brian correlation ID draft 7. Brian isdn user part UA draft 8. Brian load grouping extension draft 9. Brian load selection draft 10. Brian registration extensions draft 11. Brian sg information draft 12. Brian tcap UA draft =20 =20 Cheers, =20 Lyndon =20 ------_=_NextPart_001_01C6490E.D520CE99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Folks,
 
I've = received=20 further input on sigtran UA implementations which I = will
take = into account=20 and send out an updated survey results email at
the = end of the=20 week.
 
In the = meantime, we=20 need to start a discussion on where this WG is
going = to go. =20 We have now been moved into the RAI (Real-time
Apps = and=20 Infrastructure) Area, probably continuing to have = Jon
Peterson as our lead=20 Area Director since he is moving as well.
 
Our WG = has basically=20 completed its original objectives, with some
continuing work on=20 interop testing results for SUA and M2PA.  In
general, the number=20 of active participants has fallen considerably
since = its original=20 days, although there continues to be a fair amount
of = email traffic=20 (albeit bursty).
 
One = legitimate and=20 probably sensible option is to close the group
down = soon and merge=20 the work into a broader group, as SCTP was
merged = into the TSV=20 WG.  It's likely that an RAI WG will be formed
for = such=20 purposes.
 
Another alternative=20 is to identify specific additional work items and
try to = recharter the=20 WG.  This to me depends on whether we
have = additional work=20 items that have broad support, and if we have
sufficient momentum=20 as a group to complete them.
 
I'd = like to solicit=20 feedback from the list on whether people feel that
our = target should be=20 to close down the WG, or whether it should
be = rechartering, and=20 if the latter, what work items you believe need
to be=20 addressed.
Taking = a look over=20 the various proposals, the following come up:
 
1.=20 M3UA=20 deployment considerations draft
-- = this seems to me=20 to have the most support and be most useful
2. = Test=20 specifications (m2pa and m2ua exist as drafts)
-- I = have feedback=20 from Jon that test specs are OK work items - = however,
other = bodies seem to=20 already have test specs done
3. = M3UA ipsp-to-ipsp=20 draft
4. = M3UA sg-to-sg=20 draft
5. = Brian asp=20 extensions framework draft
6. = Brian correlation=20 ID draft
7. = Brian isdn=20 user part UA draft
8. = Brian load=20 grouping extension draft
9. = Brian load=20 selection draft
10.=20 Brian registration extensions draft
11. Brian sg information draft
12. = Brian tcap=20 UA draft
 
 
Cheers,
 
Lyndon
 
------_=_NextPart_001_01C6490E.D520CE99-- --===============0426684725== 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 --===============0426684725==-- From sigtran-bounces@ietf.org Thu Mar 16 11:02:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuvk-00087e-7N; Thu, 16 Mar 2006 11:02:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuvj-00087Z-B7 for Sigtran@ietf.org; Thu, 16 Mar 2006 11:02:27 -0500 Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJuvg-0006nN-P3 for Sigtran@ietf.org; Thu, 16 Mar 2006 11:02:27 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id k2GFx3l6040463 for ; Thu, 16 Mar 2006 07:59:04 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <027801c64913$02945680$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Thu, 16 Mar 2006 19:02:15 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.87.1/1335/Wed Mar 15 20:58:43 2006 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Subject: [Sigtran] ASP Identifier issue 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="===============1467168135==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1467168135== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0275_01C6492C.23EEA970" This is a multi-part message in MIME format. ------=_NextPart_000_0275_01C6492C.23EEA970 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, ASP Identifier parameter defined as follows: "The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS." It seems not quite clear: 1. When ASP Identifier may be omitted in ASP Up and when it is required by = an SGP? 2. Whether ASP Id must be unique in scope of an AS, especially when the ASP = (with the only ASP Id) may serve multiple AS? I didn't find any explanation in the archive. Could anybody please make = it clear? There are similar statements in the specifications for M2UA, M3UA, SUA, = IUA regarding ASP Identifier. For example, section 4.3.4.1 of rfc3332bis-06 states: "If the SGP is aware, via current configuration data, which Application Servers the ASP is configured to operate in, the SGP updates the ASP state to ASP-INACTIVE in each AS that it is a member. Alternatively, the SGP may move the ASP into a pool of Inactive ASPs available for future configuration within Application Server(s), determined in a subsequent Registration Request or ASP Active procedure. If the ASP Up message contains an ASP Identifier, the SGP should save the ASP Identifier for that ASP." Section 3.5.1 (ASP Up description) of RFC 3868 states: "ASP Identifier MUST be used where the IPSP/SGP cannot identify the ASP by provisioned address/port number information (e.g., where an ASP is resident on a Host using dynamic address/port number assignment)." RFC 3331 has similar statement in 3.3.2.1. Is it legal for an ASP to omit ASP Identifier in ASP Up message in the = case when multiple AS can be served and the SG may later accept = connection to another ASP? If so, what should SG do if the second ASP = specifies ASP Identifier in ASP Up and then relates itself to the same = AS (by Reg Req or ASP Active), as the first one? Thanks in advance, Sergey Mikhailov. ------=_NextPart_000_0275_01C6492C.23EEA970 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi,
 
ASP Identifier parameter defined as=20 follows:
 
   "The optional ASP = Identifier parameter=20 contains a unique value that
   is locally significant = among the=20 ASPs that support an AS."
 
It seems not quite clear:
 
1.
When ASP Identifier may be omitted in = ASP Up and=20 when it is required by an SGP?
 
2.
Whether ASP Id must be unique in scope = of an AS,=20 especially when the ASP (with the only ASP Id) may serve multiple=20 AS?
 
I didn't find any explanation in the = archive. Could=20 anybody please make it clear?
 
 
 
There are similar statements in the = specifications=20 for M2UA, M3UA, SUA, IUA regarding ASP Identifier.
 
For example,
section 4.3.4.1 of rfc3332bis-06=20 states:
 
   "If the SGP is aware, via = current=20 configuration data,
   which Application Servers the ASP is = configured to operate in, the
   SGP updates the ASP state = to=20 ASP-INACTIVE in each AS that it is a
   = member.

  =20 Alternatively, the SGP may move the ASP into a pool of Inactive=20 ASPs
   available for future configuration within = Application=20 Server(s),
   determined in a subsequent Registration = Request or=20 ASP Active
   procedure.  If the ASP Up message = contains an=20 ASP Identifier, the SGP
   should save the ASP Identifier = for that=20 ASP."
 
 
Section 3.5.1 (ASP Up description) of = RFC 3868=20 states:
 
   "ASP Identifier MUST be = used where the=20 IPSP/SGP cannot
   identify the ASP by provisioned = address/port=20 number
   information (e.g., where an ASP is resident on a=20 Host
   using dynamic address/port number=20 assignment)."
 
RFC 3331 has similar statement in=20 3.3.2.1.
 
 
 
Is it legal for an ASP to omit ASP = Identifier in=20 ASP Up message in the case when multiple AS can be served and the = SG may=20 later accept connection to another ASP? If so, what should SG do if = the=20 second ASP specifies ASP Identifier in ASP Up and then relates = itself to=20 the same AS (by Reg Req or ASP Active), as the first one?
 
 
Thanks in advance,
Sergey = Mikhailov.
------=_NextPart_000_0275_01C6492C.23EEA970-- --===============1467168135== 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 --===============1467168135==-- From sigtran-bounces@ietf.org Sun Mar 19 14:37:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL3iG-0005Pc-7D; Sun, 19 Mar 2006 14:37:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL3iE-0005Ol-SG; Sun, 19 Mar 2006 14:37:14 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL3iD-0006t4-Ks; Sun, 19 Mar 2006 14:37:14 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k2JJbA0e023702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Mar 2006 19:37:11 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FL3iA-0001pt-SK; Sun, 19 Mar 2006 14:37:10 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Sun, 19 Mar 2006 14:37:10 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sigtran chair , Internet Architecture Board , sigtran mailing list , RFC Editor Subject: [Sigtran] Protocol Action: 'Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)' to Proposed Standard 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 The IESG has approved the following document: - 'Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) ' as a Proposed Standard This document is the product of the Signaling Transport Working Group. The IESG contact person is Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sigtran-rfc3332bis-06.txt Technical Summary This document revises RFC3332, the Internet adaptation layer for the MTP3 (layer3 for SS7) protocol. The primary purpose of this protocol is to tunnel SS7control traffic (ISUP, etc) over IP, mostly for the sake of emulating SS7 signaling networks or building distributed SS7-IP gateways. This revision mostlyconsists of corrections and clarifications. Working Group Summary The SIGTRAN working group supported the advancement of this document without contention. Protocol Quality This document was reviewed for the IESG by Jon Peterson and David Black (on behalf of GEN-ART). Note to RFC Editor Please add a note to the title page indicating that this document obsoletes RFC3332. Furthermore, append to the Abstract: NEW: This document obsoletes RFC3332. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 20 09:46:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLdu-0001UR-V9; Mon, 20 Mar 2006 09:45:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLdt-0001Sn-8a for sigtran@ietf.org; Mon, 20 Mar 2006 09:45:57 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLdr-0004Xl-KL for sigtran@ietf.org; Mon, 20 Mar 2006 09:45:57 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Mar 2006 06:45:54 -0800 X-IronPort-AV: i="4.03,111,1141632000"; d="scan'208,217"; a="262855790:sNHT2907789134" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2KEjX2J021472; Mon, 20 Mar 2006 06:45:53 -0800 (PST) Received: from xmb-rtp-209.amer.cisco.com ([64.102.31.11]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 09:45:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sigtran] future work Date: Mon, 20 Mar 2006 09:45:43 -0500 Message-ID: <542F2F9C2CDE6B40A775125727674ECA015061A4@xmb-rtp-209.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] future work Thread-Index: AcZHEUmePfIgYdAFTbadKbGE9CRv2AFGiLzQ From: "Ken A Morneault \(kmorneau\)" To: "Ong, Lyndon" , X-OriginalArrivalTime: 20 Mar 2006 14:45:44.0919 (UTC) FILETIME=[F7F8D670:01C64C2C] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f 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="===============0686518600==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0686518600== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64C2D.08F12DF3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64C2D.08F12DF3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Lyndon, =20 I think in time there will be a need to address some of the topics below. Currently, I imagine most are still=20 solidifying SCTP and the current UAs. =20 =20 Given the limited participation, it may be best to move the work into a different WG for now as long as these work items can be addressed in that group when the need=20 arises. =20 Regards, =20 Ken ________________________________ From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Thursday, March 16, 2006 10:32 AM To: sigtran@ietf.org Subject: [Sigtran] future work Hi Folks, =20 I've received further input on sigtran UA implementations which I will take into account and send out an updated survey results email at the end of the week. =20 In the meantime, we need to start a discussion on where this WG is going to go. We have now been moved into the RAI (Real-time Apps and Infrastructure) Area, probably continuing to have Jon Peterson as our lead Area Director since he is moving as well. =20 Our WG has basically completed its original objectives, with some continuing work on interop testing results for SUA and M2PA. In general, the number of active participants has fallen considerably since its original days, although there continues to be a fair amount of email traffic (albeit bursty). =20 One legitimate and probably sensible option is to close the group down soon and merge the work into a broader group, as SCTP was merged into the TSV WG. It's likely that an RAI WG will be formed for such purposes. =20 Another alternative is to identify specific additional work items and try to recharter the WG. This to me depends on whether we have additional work items that have broad support, and if we have sufficient momentum as a group to complete them. =20 I'd like to solicit feedback from the list on whether people feel that our target should be to close down the WG, or whether it should be rechartering, and if the latter, what work items you believe need to be addressed. Taking a look over the various proposals, the following come up: =20 1. M3UA deployment considerations draft=20 -- this seems to me to have the most support and be most useful 2. Test specifications (m2pa and m2ua exist as drafts) -- I have feedback from Jon that test specs are OK work items - however, other bodies seem to already have test specs done 3. M3UA ipsp-to-ipsp draft 4. M3UA sg-to-sg draft 5. Brian asp extensions framework draft 6. Brian correlation ID draft 7. Brian isdn user part UA draft 8. Brian load grouping extension draft 9. Brian load selection draft 10. Brian registration extensions draft 11. Brian sg information draft 12. Brian tcap UA draft =20 =20 Cheers, =20 Lyndon =20 ------_=_NextPart_001_01C64C2D.08F12DF3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 
Lyndon,
 
I think in time there will be a need to address = some=20 of
the topics below.  Currently, I imagine = most are still=20
solidifying SCTP and the current UAs. =20
 
Given=20 the limited participation, it may be best to move
the=20 work into a different WG for now as long as these
work=20 items can be addressed in that group when the need
arises.
 
Regards,
 
Ken

From: Ong, Lyndon = [mailto:Lyong@Ciena.com]=20
Sent: Thursday, March 16, 2006 10:32 AM
To:=20 sigtran@ietf.org
Subject: [Sigtran] future = work

Hi=20 Folks,
 
I've = received=20 further input on sigtran UA implementations which I = will
take = into account=20 and send out an updated survey results email at
the = end of the=20 week.
 
In the = meantime, we=20 need to start a discussion on where this WG is
going = to go. =20 We have now been moved into the RAI (Real-time
Apps = and=20 Infrastructure) Area, probably continuing to have = Jon
Peterson as our lead=20 Area Director since he is moving as well.
 
Our WG = has basically=20 completed its original objectives, with some
continuing work on=20 interop testing results for SUA and M2PA.  In
general, the number=20 of active participants has fallen considerably
since = its original=20 days, although there continues to be a fair amount
of = email traffic=20 (albeit bursty).
 
One = legitimate and=20 probably sensible option is to close the group
down = soon and merge=20 the work into a broader group, as SCTP was
merged = into the TSV=20 WG.  It's likely that an RAI WG will be formed
for = such=20 purposes.
 
Another alternative=20 is to identify specific additional work items and
try to = recharter the=20 WG.  This to me depends on whether we
have = additional work=20 items that have broad support, and if we have
sufficient momentum=20 as a group to complete them.
 
I'd = like to solicit=20 feedback from the list on whether people feel that
our = target should be=20 to close down the WG, or whether it should
be = rechartering, and=20 if the latter, what work items you believe need
to be=20 addressed.
Taking = a look over=20 the various proposals, the following come up:
 
1.=20 M3UA=20 deployment considerations draft
-- = this seems to me=20 to have the most support and be most useful
2. = Test=20 specifications (m2pa and m2ua exist as drafts)
-- I = have feedback=20 from Jon that test specs are OK work items - = however,
other = bodies seem to=20 already have test specs done
3. = M3UA ipsp-to-ipsp=20 draft
4. = M3UA sg-to-sg=20 draft
5. = Brian asp=20 extensions framework draft
6. = Brian correlation=20 ID draft
7. = Brian isdn=20 user part UA draft
8. = Brian load=20 grouping extension draft
9. = Brian load=20 selection draft
10.=20 Brian registration extensions draft
11. Brian sg information draft
12. = Brian tcap=20 UA draft
 
 
Cheers,
 
Lyndon
 
------_=_NextPart_001_01C64C2D.08F12DF3-- --===============0686518600== 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 --===============0686518600==-- From sigtran-bounces@ietf.org Mon Mar 20 10:26:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMHD-0000Nc-HI; Mon, 20 Mar 2006 10:26:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMHC-0000NU-DZ for sigtran@ietf.org; Mon, 20 Mar 2006 10:26:34 -0500 Received: from lin1-118-39-27.ciena.com ([63.118.39.27] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMHB-0006Vk-Vq for sigtran@ietf.org; Mon, 20 Mar 2006 10:26:34 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sigtran] future work Date: Mon, 20 Mar 2006 10:26:15 -0500 Message-ID: <0901D1988E815341A0103206A834DA07C463E9@mdmxm02.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] future work Thread-Index: AcZHEUmePfIgYdAFTbadKbGE9CRv2AFGiLzQAAHDfHA= From: "Ong, Lyndon" To: "Ken A Morneault \(kmorneau\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a 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="===============1749163001==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1749163001== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64C32.A14F5051" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64C32.A14F5051 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK Folks, =20 Accordingly, I will talk with our A-D about the future disposition of remaining Sigtran work. =20 Cheers, =20 L. Ong ________________________________ From: Ken A Morneault (kmorneau) [mailto:kmorneau@cisco.com]=20 Sent: Monday, March 20, 2006 6:46 AM To: Ong, Lyndon; sigtran@ietf.org Subject: RE: [Sigtran] future work =20 Lyndon, =20 I think in time there will be a need to address some of the topics below. Currently, I imagine most are still=20 solidifying SCTP and the current UAs. =20 =20 Given the limited participation, it may be best to move the work into a different WG for now as long as these work items can be addressed in that group when the need=20 arises. =20 Regards, =20 Ken ________________________________ From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Thursday, March 16, 2006 10:32 AM To: sigtran@ietf.org Subject: [Sigtran] future work Hi Folks, =20 I've received further input on sigtran UA implementations which I will take into account and send out an updated survey results email at the end of the week. =20 In the meantime, we need to start a discussion on where this WG is going to go. We have now been moved into the RAI (Real-time Apps and Infrastructure) Area, probably continuing to have Jon Peterson as our lead Area Director since he is moving as well. =20 Our WG has basically completed its original objectives, with some continuing work on interop testing results for SUA and M2PA. In general, the number of active participants has fallen considerably since its original days, although there continues to be a fair amount of email traffic (albeit bursty). =20 One legitimate and probably sensible option is to close the group down soon and merge the work into a broader group, as SCTP was merged into the TSV WG. It's likely that an RAI WG will be formed for such purposes. =20 Another alternative is to identify specific additional work items and try to recharter the WG. This to me depends on whether we have additional work items that have broad support, and if we have sufficient momentum as a group to complete them. =20 I'd like to solicit feedback from the list on whether people feel that our target should be to close down the WG, or whether it should be rechartering, and if the latter, what work items you believe need to be addressed. Taking a look over the various proposals, the following come up: =20 1. M3UA deployment considerations draft=20 -- this seems to me to have the most support and be most useful 2. Test specifications (m2pa and m2ua exist as drafts) -- I have feedback from Jon that test specs are OK work items - however, other bodies seem to already have test specs done 3. M3UA ipsp-to-ipsp draft 4. M3UA sg-to-sg draft 5. Brian asp extensions framework draft 6. Brian correlation ID draft 7. Brian isdn user part UA draft 8. Brian load grouping extension draft 9. Brian load selection draft 10. Brian registration extensions draft 11. Brian sg information draft 12. Brian tcap UA draft =20 =20 Cheers, =20 Lyndon =20 ------_=_NextPart_001_01C64C32.A14F5051 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
OK Folks,
 
Accordingly, I will talk with our A-D about the = future=20 disposition of remaining
Sigtran work.
 
Cheers,
 
L. Ong

From: Ken A Morneault (kmorneau)=20 [mailto:kmorneau@cisco.com]
Sent: Monday, March 20, 2006 6:46 = AM
To: Ong, Lyndon; sigtran@ietf.org
Subject: RE: = [Sigtran]=20 future work

 
Lyndon,
 
I think in time there will be a need to address = some=20 of
the topics below.  Currently, I imagine = most are still=20
solidifying SCTP and the current UAs. =20
 
Given=20 the limited participation, it may be best to move
the=20 work into a different WG for now as long as these
work=20 items can be addressed in that group when the need
arises.
 
Regards,
 
Ken

From: Ong, Lyndon = [mailto:Lyong@Ciena.com]=20
Sent: Thursday, March 16, 2006 10:32 AM
To:=20 sigtran@ietf.org
Subject: [Sigtran] future = work

Hi=20 Folks,
 
I've = received=20 further input on sigtran UA implementations which I = will
take = into account=20 and send out an updated survey results email at
the = end of the=20 week.
 
In the = meantime, we=20 need to start a discussion on where this WG is
going = to go. =20 We have now been moved into the RAI (Real-time
Apps = and=20 Infrastructure) Area, probably continuing to have = Jon
Peterson as our lead=20 Area Director since he is moving as well.
 
Our WG = has basically=20 completed its original objectives, with some
continuing work on=20 interop testing results for SUA and M2PA.  In
general, the number=20 of active participants has fallen considerably
since = its original=20 days, although there continues to be a fair amount
of = email traffic=20 (albeit bursty).
 
One = legitimate and=20 probably sensible option is to close the group
down = soon and merge=20 the work into a broader group, as SCTP was
merged = into the TSV=20 WG.  It's likely that an RAI WG will be formed
for = such=20 purposes.
 
Another alternative=20 is to identify specific additional work items and
try to = recharter the=20 WG.  This to me depends on whether we
have = additional work=20 items that have broad support, and if we have
sufficient momentum=20 as a group to complete them.
 
I'd = like to solicit=20 feedback from the list on whether people feel that
our = target should be=20 to close down the WG, or whether it should
be = rechartering, and=20 if the latter, what work items you believe need
to be=20 addressed.
Taking = a look over=20 the various proposals, the following come up:
 
1.=20 M3UA=20 deployment considerations draft
-- = this seems to me=20 to have the most support and be most useful
2. = Test=20 specifications (m2pa and m2ua exist as drafts)
-- I = have feedback=20 from Jon that test specs are OK work items - = however,
other = bodies seem to=20 already have test specs done
3. = M3UA ipsp-to-ipsp=20 draft
4. = M3UA sg-to-sg=20 draft
5. = Brian asp=20 extensions framework draft
6. = Brian correlation=20 ID draft
7. = Brian isdn=20 user part UA draft
8. = Brian load=20 grouping extension draft
9. = Brian load=20 selection draft
10.=20 Brian registration extensions draft
11. Brian sg information draft
12. = Brian tcap=20 UA draft
 
 
Cheers,
 
Lyndon
 
------_=_NextPart_001_01C64C32.A14F5051-- --===============1749163001== 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 --===============1749163001==-- From sigtran-bounces@ietf.org Fri Mar 24 08:01:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMlvF-0000kI-TX; Fri, 24 Mar 2006 08:01:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMlvD-0000hB-T5 for Sigtran@ietf.org; Fri, 24 Mar 2006 08:01:44 -0500 Received: from [151.17.59.94] (helo=wexit4imc.wind.root.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMlvC-0005f1-6r for Sigtran@ietf.org; Fri, 24 Mar 2006 08:01:43 -0500 Received: from WEXIT12DB.wind.root.it ([10.55.249.87]) by wexit4imc.wind.root.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Mar 2006 14:01:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C64F43.17E2C56F" Date: Fri, 24 Mar 2006 14:01:04 +0100 Message-ID: <620B2E4B1D22E54A970B16BA95E4D86703C84574@WEXIT12DB.wind.root.it> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SUA Test List thread-index: AcZPQFstgluw9EdpT4G1As/xFuUZ+AAApWmg From: "Troiano Marco" To: X-OriginalArrivalTime: 24 Mar 2006 13:01:41.0044 (UTC) FILETIME=[17FC1F40:01C64F43] X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: Subject: [Sigtran] R: SUA Test List 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C64F43.17E2C56F Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C64F43.17E2C56F" ------_=_NextPart_002_01C64F43.17E2C56F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, my name is Marco Troiano. I am a TLC engineer and I am going to test SUA in our labs. I found the attached document and I would like to know if there is a later document to use for interoperability test between two machines. Can anybody help me? =20 Thanks in advance. =20 Marco Troiano ------_=_NextPart_002_01C64F43.17E2C56F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

my name is Marco Troiano. I am a TLC engineer = and I am going to test SUA in our labs. I found the attached document and I = would like to know if there is a later document to use for interoperability = test between two machines.

Can anybody help = me?

 

Thanks in = advance.

 

Marco Troiano

------_=_NextPart_002_01C64F43.17E2C56F-- ------_=_NextPart_001_01C64F43.17E2C56F Content-Type: application/x-zip-compressed; name="draft-vibansal-interop-test-spec-sua-00.zip" Content-Transfer-Encoding: base64 Content-Description: draft-vibansal-interop-test-spec-sua-00.zip Content-Disposition: attachment; filename="draft-vibansal-interop-test-spec-sua-00.zip" UEsDBBQAAAAIAGNseDSOGgOYLygAAA/rAAArAAAAZHJhZnQtdmliYW5zYWwtaW50ZXJvcC10ZXN0 LXNwZWMtc3VhLTAwLnR4dO09224juXLPZ4H9B2IeEhtrySP5MruD7CKy5PE4O77E7dmcQRActCXa 6kyrW+lu2etg/iIH+ZX8XqqKbN76Lllz9iyWwGisFlksFot1I1n97TfffsPWL78Ej/wzO/Gj1A8J 0HmU8STiGZsk/n1GjybxdLXgUfaWzfBZ7zG4o/q9AOvGy17G06yXLvm0pwG/Xz3Mecq8+D578hNO gNKV33v9up/9mlVgU1e85zTji5QAnf66DBKevmXv+F2y8pNnNnz9+qgJApV/WYVU+5AAFWh3LobE E/8uCIPsmd3C2JgHY2P3ccK8jyO2452f3d6MLneLhG+kj6aA7v7bb7zMz1Ypi+9ZNg9SdsEXsf75 Fh/N5BQw+NuP1CT1aJLgyQx/CCJ2vwpDNo0jwHXhR1NB9qcgmzMfflgm8WOQBnFEfXl8msHfbPAa v928Gw9fD4/7umO7E+g34ewpTj4H0YPCRyLNNducRg9BxHkCtQT6fvqZvYuTKWc756e373b3WCCA +emewBy+5nAfkni1TPvsMs44wPUFmWLoIZG/sYX/DINJYzYL0iwJ7lZZGVp+qvEXTEyD6JeOiqbN aPzoh8GM5tuH7n4NFqsFjFOwcPArW8RRNk8Jd0TmjrPVcuZnfLbHEr4M/Sn+BY3juzQOOTxnd89i DATCQBKn7pllwYIDYpmYQ38J07RMAh8pELNVqonbk6MgMDDChN/zhMM0Ax5QI/BD7BYaTQMiH19I 0gElI2zwCgkFfRAA6OYBFlHaf2UyG2ch0BWndbpKEmQ5l2JTgAVj9qdTaAyDk5NEZZ5ly7f7+09P T/2AZ/f9OHnYxz/2B8Gs59/BhPlTmIWc/83uHJ725v4sfmITWOfTLE4C3r3jlED059kiNNj6229G Eg9r2EBmXKYMl2lwH0x9WhvIHUBP+gXZPHDFwx3PnjgXBJ0F9zQfGYmJYLEMOc4zQUpxcu98RBvA euPxNfuYwsyMZv5S1GAf/GfJITAzWTyNQxA1H0ewYGDmZjydArNDc1jluI4k0/6TEDk45l4aPMC4 IhIyBGdwjJT+yRz7rX8XciT3GJgYmbBU+vS7l4Gma1PV+gKABn1ghiSerUhANTWoKAd62O89j21W AClDMF7ent5cnt72Jjejd7f4cwutAWW0eljBY0P5DPtUEeZiFhCXNA2qrMBAD/oA4hGmkzhtlQo2 yUzN0QSF4BxKfIBP2c4H/shDNthtaucWJPxhf9D3QCIDr4286553ds12LmMQWLNVNAPF9NwCqoAz 7F9FBITUAa4iWDaPKOyzpxieN0Hp948IzoHGh/0Du1iFWbAU2LEdeHQLywhWPXsPUj1E6IsYlpyF pYADJIJ+YUD/SAo3BuS8M4AYSyx3cKwFaBcGtDcE56h/4qdQxfMuL2DNpan/wAXbgJT/eDnaY5PR L6Oy8cgyeE1wjvsnq/Azm/iZj5IKUKhpU1YGA4LzxobjnTW1c8tg+O03R0X+GbaYaasgHHYE/HN+ DZyDH2TQBA+rxO8iDiScIS6NSJo6VwkK8JmaHym9cQZRm5cSb3BMcA76Z2F8Bxr2NsiAbwBClIZC cHtTHvlJ0CA1B28IzmEzHOShaqoNvic4R33Fw4C9x7PVku1MeOYHIQzQ5KqU2KoAcPADwTnue/xB qSkiww3v+aBgF3dgKaOm+DC5ZQsJq4jPEPjnuDjvB13nHeGwY5j3yXPkL2BybvgDWnidJr2v4Az7 NzwE6+zdKqK591EuN7U1yxDkz5v++eUvow/nE3Z76t2y8cg7bSFw7DJEufEG+TkSdmWpcGCnSRIn LeAMFZxLYF4050bLJfcTtPbR+st/vYlXGQInPQ8OF8gqOYfDYwJ00KcuQdzc8HtSGT124UdQgRyN kzCeok1dgxDA+d6YeG+1WIArVt2gogxhYfwAXAj2JqpOQDgNZlzMexeFiHAGr8GQHl2O1oci4Qz6 SBZhXXdrrgrBGfbZaPo5ip9gVdIy6w5sCAt+cABwVtk8TkDtjGYztNu74oVwchNGuP2blOF2LCL6 GJCbpgxA8ycmnIZ0CrCVyUqwr0NwD+ALKK9H8IXun0sNdoKQi31tsLvGOrrHgOK/D/6DhWiWW/4D zKljtpVg6I1vrxkYO+R9cYJGkNjFR5Ak4Magw/3D8Wshcd+NDw5e/wCKDvAIfLDWbGD4HPzcJGXz OKVljTDR3MDWBB+sDnRWHmL6NcYeUr4EuYB+KQESYQDwHq4fD1kkhUdOCnQW7U4BGAKM4swCCn57 SKNB9wU8eHDEsX8wPmcx4JfO41U4IxiKpuBFE71AUIW5Y4WmU0LEidkDj3ChkscKvk+wAKI+cnKw CRA6YOBXyN95kgc38tiDpm0eTlDayiZjjuRTgMEQAQidq2kYEJrQGo1LAETWMzcYBD1AgjP1Uxeu dB0x6JCCrS0M1UxTkAfkhAvKoecXYWQhMmMCnvdGTQlfrKRBIMBIHx7FmRrxGQKZ8b5eDAQmXxDk rzauheI6sOdNrwWLyg5RaWqJKsrnoO6XuB4puhI8AurokeBEzhPOnQ5DNBgM7/geYwQsDD7TQPeR zeMIbJFzC7E9hrahoN5quYwTCsCMP+yPr8AcAhcBBPeeUoM/c6DB8xIjknllxrOpDLsQFP4rSCd8 TvN3CoR7lrTwc+tIcDdLBQjmhxn3Yaih8JQEsypyWDID5Heji1YiRT4D2sAUs5S9Qrnxak/8zy6v 6O+b03/9eH5zOsG/vfejDx/UH6IGwYEHVx8/yDr4l249vrq4OL2cEACAPPr0SoTkXl1d355fXY4+ vMqDRRaieVjkTvLUMqEolxumAKnWGw4GP7B///4/LGIc5gLU8jPtGqAD6h3IEmotfOjVDxZqHaS5 RV1YC3fkfN1zP1uBLpU8rqFtrh8PtqYf08yffpahU4QynfsYc32gRlPl7IQgA9mM3DnH2wExQ4BQ gliiTCo17Wu9ZSOHzLp4Z9aD73pm+Y5VFbte7zsLyBf6xMnW38rKF/Ti2eR6zH5kf4avJUDKvzm/ SCTE1zogvaoCvyAy1wPRYguYbERY/WEKwlsShG9FkLCHdNR/se/QebTX1X0chvETtpYC8E5oPD57 KxuO0jSeBkJIwg/+XRikcxQVe8iuiYyB50bLDgh4hAYCwycAQgHv9iU0w2O3gCkOBs2SGz8+eu/X e8KaUN0QIHTnNSn/j4aCzVIwA9IcmY/XubVAdoZQroVmyJKyWayGkZFlBssFzBFCFlcuyR0JcU+D CfqgrHWX4BPU9OGzy9t3nzAu1Tu/HI1vz3853XWxVIMD4gOpHgUGKMfc1Q6VMVRmrPY6eozGO1cg JxNQ2YU+66gDUnQZIxwyMxUwHCnTEPf0nFMpIZ8xtCbiNJFGtvegXW4zj0Mw0piwugcGo5G0zAMm Oxjy2GX3SbzQcO7ADCMjLGU7KTGjZmjDCt+1ut6JlyL4sFuCxZDaHRhY9HCjAyNUGoYK4iA2FhI0 dWgUBhEYzGA/p4b0V2tpwv0XYQ+x5M5HbVdLKT9A8xHpLpxGd+41lE5McC3ouptHP1s10stKtGL+ fYbOSLCAz1sDFS52mg0t2aP6syDVxG6i2uRyfapN40Q+ROYhYD1cUxKgEplhDLaUr8UwutBMWeO4 6coWaEuA6J7O+fRzbudKWgsxDOhOCdDOAzpcuJv8DDJ/lc3ip2hXYI5+rdmPpgx9bG45HW7NcvpW bCgwVr+l4IyoaBaxtydOnU6l1gRqVdDkGJC2RvPHMRhaFccYcSB4Z6yxfLHHsYbR8gWxGHlDGsin dWynL7bptIYJ94VgkAGHDUog5NboS+DASksLk7j8W9UPa+DgYPFd3Ww6vO9alh0MS9onj5QaRR2k pBRtVIO4REEq5SiYExQ5EaqEoOSRHiEwF3FC4RexL+eEwAsynOwmrkRzWwhUXEGvLaeeZTrtpLsk lm7GA/YP8Dk0YDB0aTP+lkBgN3gMZ0wnBZTZ4PZoaDNJEtQGJR0XdfkmJpTb3twT0m0GbEfpLRjw 7hoghhaIoQlCBLvUhEtXJAH7Zk4LuDC/55H/EjO8V2EB4dTu0Nw6Wy0w0xoMDCGfZm/9aT4fFZV+ BV2/kmHkmEYSrjFEOt6iZguM5cvzd4b/mMhNJ/iBjNqRZ1sSuGPP2Dp79o54KlPfY6fO5kbL0TaN lsJHy9JgaNRqeR1iKTExGtT7JpGVLz1DHXdUyF36ZU7ZrC3hPKzGWX8rjnf92E/HkE9bxUxG8LVh FQvhnPoLblnHtyrWj/FuuQeSL8pJfjrT9Oyp3tNcxCCpEwKE4WTVme4JTYMPsT/z5lBhj6GOu0F/ F73mkwR+IHCyQwJ04UQ01wklUUMl/Ae6Ge4dOM6P0Ci2M2e2Hm7UemCpgKZAFavSHR+vTd1haPhB Q+uGKFQVBBr3djEfWnNMxg9xBioAbVCWKXMbM9tkaxX/azC7ikiWQ+lsgaFmFTYTBYI8jHmCT09b maROpxyUGB6KLe+7wE9gTNfg354IdVAcFqmkQkhIA7SsmZDdCFHsvkCI89GaTCCMshcYvl5g+47R NmDyXJpNg/NIiNKirffkpwg928Mj9LjZZULXILQdltJ+nmXk5ZZdE9XNULdl2f0n7aNaaxTleC9F Qd5ikRYZVamBakalj80NueOtGXJU6ldS9TDbs1K1PJF+iCl48ZdHP1zRyYJILaKUZ9gOHaQ4kmS2 vbkXWIWuKG41y5sSsUqWKEfFZG/+bLC1vm5iROdzK6J6qVaInC4DE3KmiSEqZkQPAE/y5AteSpfG WXkZRFtqwt+9EMyN1mwtGahab7Q6qqG8hIhpw5GbyYivQIUqGaGOplWtMHNEGNTQYKq4mO65vQUv JUm4PPR1PmF4bG/BkRvl/bIlMCIdU4wsaVXKNoSvWrouUTRBRm5Uid358MUVC+sMn05rmbez9Kjl Shi5W2jlSyCnGHmIfqYjenhnqRgGKyyb9htvdqsWDlMFi75wjzbVCpt8ab9gWhANnN07PLn1JIWN u3PnDqZDU+sDb8aI2IG31t0YB2JZ1G5S7PXFzL43WzP7Kj/alLW3Cmv39+rCSrUN62JZ+BvM7wAv r5Q0JL4sB2N96xB5a9g3w9DWn9dpaJbiGM0fX4aqdSWPeA4FWTs2NL62bri9oKKQesWYojxJKOpt GFOEPmpiiiCNXiCmmJ+3Qsglp2kqT9K0jCVWhCxatW3he5RG40oNP7dda61otm13lK1FmKYU71LP wo0+dsF7uBbekjGcQCReIgF2RJYzD8tWm/id5kOasi3HVTIfjaOSEBwzHn+vtOOr2bdyqC2msNtQ S6aw+1DteABVFEcW7F+N6y6yGB62TyYzZidBybdDR0CRQGYkRToA7+MnspBmYPXj5QcQVLloEa5i 6lzL0BBmfAlY8yirh5osgggQNjFqD5Q+Njeyvt+akUWlMdhiTQfNROMqc1yk7qusGNSwYWkonbjR dL0wtctDLL29FhrACuoMG1dfNxLUCNBtkAAdZHm/yoi6MPM0ab4cZTVPbvFJma2MgT9kdvuh/uZk 9lQe666X3Y7YBkJoQCHwAe1PAE2mSZymYgbQLnRXidHjYHs96vtwKf+vFWX5iVaLu/z+HZWLHLw6 M0VmrtPADXS6q06axuY+CpXt6KZGobS2lG7ilN+/kG5Jgb83Ge3Ezf+Q0W2G+juU0TmX0IHBLYpn +tjc3P1hu+ZuG2psR4RLqJhlo8u2hQYg6d7M0X9ohT+0guZw52jfi+6GNIXfugEx922+Fem+GGuT 8MtqVr4NUn0lWxbnZjZrPEfauM0ggsmePHhbvEJi3cfeKwabm66gSPjeJbT/VBKsbtFeoi6+NrTv uaX2FnexPXNLU/9r0V9/rBtzL4ulj1YzWHzXSTzls1UiAt8r4kUwqy57tLFKDy9FH9fTlB7pvCy6 AxcWcj+gShOJxhlwurmWZNyc06pxI+fIXHK7F6+HLvEohkL9sG/vSXtv2DIOQDhMUXv9GfVXniNO nScgwcHF/RAf7xI9Bn6JvegZBxxwGSoJt2OMZteUnfZdVRMPTZmNjQfM7qfBvbzxIAcP1fQd0FzV XPbySd+ZXP3b5W4Asl+m7XHFvkpk2gT5YvRJZAKgPpCZJ6OPE1OdeOX75ANKgrp/ef5uHzvb1fd+ 6FIstrQg4axpMDijFuc0aaXiCR6Lg+mIUBpjkh9KSYuDIbmtzkQMkPMFcimtKcROw6iyfFx6GXPw EQZdmAKivAbSZgrSLF6WUn9NAuXaGQddLxO+vkAgSxg6/VQjGjSAzWSE6KiLiDBBV6xAIYfLp73V bP+9LDjE8zew2mit1Sy1VjT/OivspS1f11Q9RlPVySlrVSnPFMSMec/L39gSXc+Ss76u0V6iLr42 tO+55e/UEmWmMUofm1tAW8q5LaCXGsysYDNTxjAUPag1MD3GHE+tcTbn/uOzFqZCdfUtSHoJ5cdX lFI01+qL6cCzPIuiFWfLIeYCE9Y24SSFzNx/NLDBfDwrJCtKVeoDOwaC+PIuPp/OY3FMFBOL6YZ9 dn4Pai5NA8ouT7EHyk2zZzRR8cwcJ0odaR4TFQubspCI3DCizTJjO3fPLIxjesmDn5loIiK7rgh7 00dgTkJrh5VZhRgbS62eiqvHgJF7NrFT2YYIBBGnJVyh/RclHsXXNUSI9bWkvUJuzfbqii8JPKe0 aL9R/2vR35r9VlKQdRcyMG/73llLOfNbFjQAplbQuGLGO9v3ztaTNLJpC2GjgVDan1yibyJqjkoS WQ531Y+Yx7g8ib3DU2iwdUheSfDyJKQyhyXBkalaZYZIOzukz0BLYsr5uyDL8xtXZYakDprTQ7K3 p85ANtf628wrbfTTJASKddbIy1MriehHIvSoWNWoQ1VOxNc6DHplpRmDim8VT9ufeC6v09qg7MG4 2c4vh/u/HO8WHpSkEkq5Wi8pypwn4HeR45X/6uPWFrGHXIiLxSrKfTx5jJjgiOTEy7mPyYzlWtJX VNiOOoIrMltSclX+K60wmevRutMiZcVJrK2JvDYJ21m8ujOf3XGQkgFmOErQ9Z+Gq5l0iBHJIAxX 4nUIj4DjKgEh6OQYZipfSg5S3PX8sVjKVgWJqhGrLlThxOSAcp4xisUvNoui/P24NJ/8ZNf+J7cu 5g40qn/ZAJMcNmkBkQdq52Z8t6tgA2eO37qZfYqD0c1FoksN4yeJ0U5Jjp/O6FbXkxXswalpBh08 uh0JtBQb/LQRbDVsdRfLJVw70lkgbNr9pHB6EeIZfES9TuKnyHjk8FGhqs11axFPf7jJWm9dBTyv uj8gV+fC/1x5/t9dn1ZDc1u4eJS+uumJ07LsxIjoorRju7k+oCKaVI3SblPZ5UlD+8aDKiYU/bG5 EbO95N9WRpsPMBpl+UfpPW2l1zGSjj2SmS6oVXnoqITGZQBO6gGMrE37K7mg2VvmYWA39BOYjjT4 by7UKVrk6kJ2NNPgVqm8yUOAUvOdRfrcibxRbUVX++zqDi8CiUBpnnSfoJDvIXvEdioTAhnRZhfg nuFpjUik+b0PIvm21JyfZBRYYIuIAp1Evjqqq+oZ3pA7FuDXJEGlTbnzKe3rNNMvyRDvqgBAfgTw 71cKpn0mwnrXFaeXXXVhEGv9jK9uTlusO2udj69GP5eLh7p+9HS176eiTUk/eZub0w8VA6pBDhqN rxrlhsXYk5hyLdBuBb7mgxib1gt+o5TNZHUGwP+3O4Gf7iJnEZwM77HFxK9cuKnjq3M9UDQM77i8 eEbziZtaBFrdN6fs0BZqm6WALhHj+hRSezFefougoxhvfx6pDrA9GNzi7j4cbNVyQFUbPgLq/kmL fWcBwliOHUDkkqHFnpEcZ9ddo4ntx3RyOvI+q4ugqNGitdmlvpkWYJnj4VQv1K0zATsjY3Zc6gRV mb0tPKLqpqyhVFBsff9oQwepM8alCPsK4Z/aYKydGxvlHMyLYEwfm5uY28uSnpdSP9LXfuSPzgzo hd7C7WxLLfWthePZOL8FCAW/c7OpVd96pcgqbmzPjGXYSjAvhmwn/7ijg9wZGbPjEmRc6Ar3cmRc 3FlD+cNdp/M4OV895zZsDRblcNwBgANe7haUj78QNaBF2tlI+1qhgyYsxKpt0dAdd/XsNbRvh77t mn/twALNaSOUpugCkXbr7s56/Pcb8nlcxKQub4GSS4sX4MmOQ2pF64Ib12o4tW5c5YAqZSQhUQZK A2ojLwVWbSTm79633NxQ3nJm/vwtS/5ymcT+dL4nst9hyjN3zw9kkXTb8nkVsUeCM5UvrOb0Hk0e xasH2jWcitCkOuMq3zom3gm75PBRCcTHMFQwlYGkgN50FBCD9UCZpzqFHn28k/mU6DZ4wv0UX7Gq xqLsqxx1gBVxju91FUjG8EFwqDM/ognP5TWdn/sLtfeNxSZRylIe3hu4ExjAX0S69PtherS8UnVD BYNsPr6ZkNOpZNkX1vTEMfOcoY1Ryo8jfA2UHSylWKlr4HlnTB6LcUDUnIDVH1bZxkEwLH+chS37 Jp/U9r8W/a3Z3dZBMGR4U2yUhPUViEqOFV6GcX4hf0+gjBjLVZUDwsUnFZ4mlHCAKk0pMqEssm5w zsyCk585M1HZbHNDIKfvWJTtbthXIqiFvvtRtrUxsq+9Fvso7lI09FFsUNaHblG6qdGAVumehldM ALLhroYGJDfO1tva0GD02y9NRqWPze2ErSZ+X98rwamb8N46q0oDsY9xaqRKDDfdSNhto/XukRzh 65vOwvgOeOc2wGOHtEhlsgBvKo5qmS1Yu9vOFlfLstarqFuc7qtWrXmtjV9DXaujmhSkKLVq8gWw 2ICc+qP6nN/ZrfrD0JDyq3mjpPQ6M/KgzgBqMZxxLCBFsYV5KAiQfPfcFGxHNJRnswTDHbq6kdSf yZQaVoBhnZjgOuvXXrY5Wcwh5leUr+mG4RhvGMqbj2bf+YoSVjy9ZBFkvj+d8mUmSCEsBZseeBYx etBwyBWASdF02olimCB8JSNekTZ7dAI5OD7q4ub8R+IEOrltjQTRPjMyhKheUnh8DuvrEJP59ybB A7gL8PVozxIoxFI/DqDONf6n4VyO2I8He6LZj4PhweGRNSte/oI7fXKD0NZ3HuMQ1BUMGxFc4nn3 mbhQosHY1wOrpsmYIxODG77k8vCIfxc/cmPiqdVYTMrImhSkuh+aJ9q3MhQq4tWFBoPpUAB2GcbA NvLnaT62ahqMy/hzfRpERiTDsq03Nwe2lxCcym9mwgh4fg/DXIFhcJdgwp1ZDA4JWn4Jz1ZJRNYe 0HqPrj2reGz+ZoKSrE15HU0BNA8OW5gHmOin5PJVme/9x60t52tJe4Xcmu1/z7e2NOc7hoh+Ytoi 7AXMkRwQXvvZyCLReP4NLRO2sXECRA4iPOYoB6DfxiirOlaFCnGAVfG3MCpYlVVBznkuxEVMEmmr LS2JUw3dtm0ttEVRDJc0irDiqAnpIiOrhTltFIglzYVT/UZDAb6D5UeVmke/RTuBuWDb0oI+Njcs tpwEu3Gy8tQo9qRpAObslU9a/nFEWc3Ua5m9M1ih2WrJdiY884OQQFyqXGcpjaTNe17eFbtqq8Ob tHB5qdU9lYqntlWl644/wOTga1IGu7Ke6sINQgh9W4Do9pzDFd/q8NB/upQSP+Ocn14XYKDd8qkt DPnalQ70cH+pGEvrmaDKubnRgQc88Z6VYfsXrTRZLeVl7VhJ93RvKMnkvcJVQglybrxbsN3HV2DB Tz5ef9SbZCB6CA5tZ1q3lbskXCMQbkKlPDXpsK+2GeUNRkQp5SGG9WHE3tme2pKYzmO84YhiRWXC xpTZDHNmY2XDrFlY8Zkbjq+JoWySJL/5f61AvSzBoUhQoFL6YPu9fhpBcTXDbtHeXDLss0HN/oZz ob4tyGF7kFXnAkbFJEO177X0zLSy/UIPyEwqgq9zMmWUM6gQSl4rRVX7rKIip6/5yk4K+lHcyvKZ y4dSnfsvH9hQDozSe5GYe5khmtgwlV33snc99m5Ht6cyCx/tuIsNmAwZAfqHJ9ZKs8CIEwLe2ab0 s6aBPja3gbacGbkkdZhMDSa2r6wUYkMnhZgGgw02pV4N91VIq1VkSZ9AX0UvkVpzYIR58EBnQXL5 ls39iGTtOjLmtyu2igS23jdpUdjkVhP030ZeLTBk1k4YV/JM5YiaxdagILZefKDsxaXW+lzRatnJ tYeRU3aNA/0Y+Y/gsyBO6/D4b3fZvKS2N8zF7qsnpaMHeWbLdTLLShY7zwRLTUPuJywQmWzkCAXX ihykfloGRDjF0H7zdZoZmRmpoG7K07JLDgPX9gF9aDOlfnse+O2yVXHdbcJZ6I60lGKt+Uzlz9VT kJ/grsidSx8bGzfD19s2br7KvNzm7zVPH3j+PgfMbuMneOZTeWSmV2WtX4maLXOPKLmoZ96sx85v eM9PU764CwmONTSrfctzl2Ufdul2YmSToyKbnBHReybia13bnlM2ORVS2+86tNIfbmwjfdHgBso5 OokWRyzP5yYtepllAbjWXjQe5sTMD3HXRz0ITodU80WTra2Qrt5rkYCqRICHL2UnNwJ7KM+SoeGk PFPpjmFOSNskHBPR4VfVoM/eBQkggonjxGlsE0RpIg5TU5KibOfGb4T+6y2i/9pAX9wxfqBj7TSG YsboFdqVahzTeHEXRMAtdipD4Fc60IhVVBDOXC7HJdkFD3btGiDwJ8+RvwA+uuEPgUgQVhasfwnN tr2MvKjImxIg0mIwB7k/4Yk7ZiEEXEu/bJeh9rB+Vw2xkYrYSEdspCSUlmBraImN1MS29ETPeh0P txP2kXeA1stzbi6yHV9EnvG6DAGYhniy3L6XeCsrC9NSNi19H3XROj0rNKt455o5hrIljaxtUMUO BdGhbMxfFIA1dXrWuzn9V9tTk1oK0fEwO6jtvOeuFWnZm5/Zhf+8D//IzQIh6Ieg2mbPjuKzBCkW d/zSMs9JAAiea0n5CtD8y/nl5BWi9cF/5sm+95xm3DjufeFHgL+VdV+T08dx/uXGs2ZB6X9xLmAs bFtD5loERf9glZKf+HE8PvU8Ky5nn6WoPa5dMhUjuvfrkh7FIGDVLx8SJa4diXu/45/leAqwTbWp j1fS7Q0hRuVPNSexDH/J4ro1j6i7C0TdMS2uDz0xOzc/D4qrDKvIF00YLzUV0EaY05autU1Fyl6B qPWqDVnbmsh8MU34Wstpctp1QTVxPkHcjPcFiK7c71Cggf8BmpXOVP+4uSWxvSy/VMo5clK4m1sl sYssSPnY6CEyDAEz5bhFucKtijLEul6pALBzDh0+zXmGIVLB6QP2wLEtDzkqtuAew1Rzf2Zf3Hya B1ORHGwmLSa6Irpzbr3zUb/q0bxPT/iap20oW94MQQfykqc6ronUokZ1WX3VH67qho9jvJYJQjoE 3fNuFRHb+cgAVq1O5iKCGvvLnJGgsg/abuYEJspNRGbYgBX2zHf1z0xDsMKcMh6XPTPNKnpMJLdS Rn+RD08cCPRwXISgDc0cSxMH85mo+akAQdcuedw0io0oqT+qeUzZh5Z5aNw0aZdausfeX3m3l6OL 0xJO7WZpysvvwJVmaoLOEE4UhLEtGfTFSAuK0tzyOjaggBpBwDLOM5YkIqg0ctvkVhANUTzm+FZm GqnHd9yI73g7+Nr07WAK1ncksQTL0MFSM4nR8eZqdnt5aKlYfFNqtsFIkawFq03DYHkGdmumvj7h x+UAxlsYF314GV+mVKc0705+CVZJtdbFpJ8nt28RDfIb9Fs8zSQfheOzOKYM9KuwikEL9D5Z5CEU 81t1JiBHwhWrz4zqBXHWFuFxC4T/3Abh8boIj3KEr9SFZiN98DxeqveGqKAi+AP8kSfPxK7CVaMG BKiqUe7Fzfg04UJECrMOofnSqKP3fCz4DO/2C+hteK3iCn1nfsNSyXN4x15NoaYkG1lXDtuwHIFq z3JG9VqWK0V69HMp0mOnB6jWnqWM6rUs5SAkj/5QXoASnIzxu9hhYLoDuVT1WnLp6qNOY1fVX3Ls Y7d9/dhrsKsfewF62dhrKFs/9mpGFKkdSjmxAjfRov3QzfrNM0Mfmxslh1szSgrkG19VSJ9ythYt 2s+tWb/N5G4WYJOg09oYWwlTNNlolaE1DYSKQ4OvPKZu9tlmYyoPfdWjXQwudZ2KLiGmvwMMDdfW m68yDG+t5RfXNy5fas5pARm0ApmCV57yg7YIQxw3tLb9U7osJ4A58SDDztE0s2IUjJU8tja/zOca iBUqafrTfm4DKdlkpD+RYcqAkDx0gBTjQ+URovy5jBJVBInWHs6mhJUfb/qgZH4ZfTifsNtT75aN R96ph4/x7XyRiPHnN2Xf+9EsRN6+wAMfp0kSJyYoVn7+yNhJxuWjYpLcYEERk5xSCFek47tntkMq 30mi9miIRymwZb7fZBovltDtXX5TknqR2M8l9gRngSOYrmDBRln4jCcSZiL5n9yY2CsJdJ/e3Fzd 5AgRFGmUI0mmPsBgr2pJ9spYg1R6xv3eciLLbRJU7Yhbyq7ASUqCmbW3eKGcmvZQkeM11A94c8ib +0kFXPrY3LbZXrLJdlGzkTxDRDcAYI7p9TFKZBKgkXWGss9Oc1jFNNXGySR1SrCgLUb60KVUvp13 xnXSMqlm7O09luVnEf38PXtUgj740brPkbMJJ5EbvhRyw5dDrmdTzpEEeuWL1w7dB+Qlq90VWZCl 8S4cF2vduPCfCwKrR09fc6Y+rcWOw0Tecde72d//1C79v1qOwhvcyMnrXwIbxclnNlouOYgyyhaa qF+dJPgopEwJZMjWetEr6rgy1repGshOI4mSr1DazxEhOAoZnMXLf2Oj6+ub/ZsxHYiY8Xs6zSUl V5Aqmb2HE67TFtQI1xrBKqkl1qpC79X+X6soZlJ+a1LihU4u9sXeOr0ewpqY4oSwE7FvKW+QaBg2 /S0sN+Tx/6nm2L/2C4NASpQMJI7MczKVr3ig2N9WkK9hD7U6D/rCumF4/+yejIOePHNAzHISxtPP +WLovATlq4ptaUsZUZR1Q87yHfbCSfztaZFLUDhhp1aLWCIK1/8tw/WVg8jm2nx7KSG3tk6/vjbf nHFrZ7WEfb83z8V6q8XCT4wDAjiK+xjTQmNfQIqMLZP4EbOG4juBE+5/Fmct0EbPpRQJLWpu+YKu OauK7RiO3tpSrroc9o/aVTtuU+2oP2xXrVWnx25+UKPY4z3B8RrXnOrqjrHuQZv+D/tv2lQ7ktAa e55gz4cth3T6FgC7KYcr6p69xYMquq796zuElC/1H1BXgBeG0mEsE5yLKINufolpzJfLMJji3QGL 3Qev+9T/+ehy1LH9YCCawuICmQEazGpBBuyjWIQDxrzgIfLDUGqNXC6hAkniUF6QxCPto5m/lIeF 6Nga2wEhtyus3hkYBVkv4Nl9Lw0ecP+yl6783uC4n0m9Rx+bS+XtZeYDqg0F1cBcj+InsLrFqzlV lT+Rg7/K5gBJ3CQMg89SMPrR55x1/nTtP4LQvoaJV49uQDj/9zxIlnjRVD39GQTyRZxE3F+FQKU/ yU3jAH19IOM8wzd94hvLOb0hFKRrunqQ19nUbYHBgcSaEPvHNE+BZM65oPuJH6Xy1aXvVw9zTK8R 32dP6ESIE4jpHvuQzQTgs1Xy4ONbAN6DgAXJvEenGP0+GwyHrwdHotL1PI74W7bzw2C3Bz8c9o4P Do+h9E9/7R28/v41VTpd+EH4lj0Gd9T/P8/TtD8H/Kcyu/MLccb3337z/1BLAQIUCxQAAAAIAGNs eDSOGgOYLygAAA/rAAArAAAAAAAAAAEAIAAAAAAAAABkcmFmdC12aWJhbnNhbC1pbnRlcm9wLXRl c3Qtc3BlYy1zdWEtMDAudHh0UEsFBgAAAAABAAEAWQAAAHgoAAAAAA== ------_=_NextPart_001_01C64F43.17E2C56F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran ------_=_NextPart_001_01C64F43.17E2C56F-- From sigtran-bounces@ietf.org Fri Mar 24 08:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmh2-0004Ex-2H; Fri, 24 Mar 2006 08:51:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmh1-0004Es-IF for Sigtran@ietf.org; Fri, 24 Mar 2006 08:51:07 -0500 Received: from [194.100.156.5] (helo=levi.nethawkgroup.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMmh0-0008Vm-25 for Sigtran@ietf.org; Fri, 24 Mar 2006 08:51:07 -0500 Received: from (194.100.156.10) by levi.nethawkgroup.com via smtp id 5395_547f345a_bb3d_11da_85c3_00304811d5fb; Fri, 24 Mar 2006 15:51:47 +0200 (EET) Received: from bhaws056 (10.17.17.56) by jopo.nethawk.fi (7.0.008) (authenticated as toshbi@nethawk.fi) id 427713DD0011E76C for Sigtran@ietf.org; Fri, 24 Mar 2006 15:47:28 +0200 Message-ID: <00f501c64f49$fe75ae90$3811110a@nethawk.fi> From: "Bibhuti Bhusan Tosh" To: Date: Fri, 24 Mar 2006 19:21:01 +0530 Organization: Nethawk Networks India P Ltd MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Subject: [Sigtran] Please help me regarding Automatis TEI management procedures in IUA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bibhuti Bhusan Tosh List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1174227823==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1174227823== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01C64F78.167E65D0" This is a multi-part message in MIME format. ------=_NextPart_000_00F2_01C64F78.167E65D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All=20 I am working on IUA rfc4233 and rfc3057 version. Please provide me the Auto TEI generation techniques details.=20 1. Are the number of TEIs are assigned to the BChannels present in the = DChannel will have multiple TEIs as per its BChannel count? The number of BChannels present are 2 for BRI type and 23 for USA = PRI type and 30 for EUROPE PRI type. These TEIs are assigned to the ASP = from SG using TEI Status Indication.=20 2. Do we have to send as many unique TEIs in separate Indication = messages? 3. If the Dchannel has additional IID value then do we need to used = another set of Indication messages of additional IIDs? 4. When the SG should start the TEI assignment procedures? 5. When the ASP will initiate the TEI rquest procedures? Warm Regards, Bibhuti Bhusan Tosh ------=_NextPart_000_00F2_01C64F78.167E65D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi All
 
    I am working on IUA = rfc4233 and=20 rfc3057 version.
 
    Please provide me = the Auto TEI=20 generation techniques details.
1. Are the number of TEIs are assigned = to the=20 BChannels present in the DChannel will have multiple TEIs as per its = BChannel=20 count?
 
    The number of = BChannels present=20 are 2 for BRI type and 23 for USA PRI type and 30 for EUROPE PRI type. = These=20 TEIs are assigned to the ASP from SG using TEI Status Indication. =
2. Do we have to send as many unique = TEIs in=20 separate Indication messages?
3. If the Dchannel has additional IID = value then do=20 we need to used another set of Indication messages of additional=20 IIDs?
4. When the SG should start the TEI = assignment=20 procedures?
5. When the ASP will initiate the TEI = rquest=20 procedures?
 
Warm Regards,
Bibhuti Bhusan = Tosh
------=_NextPart_000_00F2_01C64F78.167E65D0-- --===============1174227823== 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 --===============1174227823==-- From sigtran-bounces@ietf.org Fri Mar 24 09:53:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMnfk-00026E-RG; Fri, 24 Mar 2006 09:53:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMnfj-000251-Pc for Sigtran@ietf.org; Fri, 24 Mar 2006 09:53:51 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMnfi-0002oX-A4 for Sigtran@ietf.org; Fri, 24 Mar 2006 09:53:51 -0500 Received: from ns.pigworks.openss7.net (IDENT:d2SGnLcyifl49CD2tsFaUGznVJZxVZ9b@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k2OErnq11268; Fri, 24 Mar 2006 07:53:49 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k2OErmA14656; Fri, 24 Mar 2006 07:53:48 -0700 Date: Fri, 24 Mar 2006 07:53:48 -0700 From: "Brian F. G. Bidulock" To: Troiano Marco Subject: Re: [Sigtran] R: SUA Test List Message-ID: <20060324075348.A12169@openss7.org> Mail-Followup-To: Troiano Marco , Sigtran@ietf.org References: <620B2E4B1D22E54A970B16BA95E4D86703C84574@WEXIT12DB.wind.root.it> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <620B2E4B1D22E54A970B16BA95E4D86703C84574@WEXIT12DB.wind.root.it>; from Marco.Troiano@mail.wind.it on Fri, Mar 24, 2006 at 02:01:04PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id k2OErnq11268 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Troiano, ETSI has a test spec for M3UA (ETSI TS 102 381) and M2UA (ETSI TS 102.380= ). Much of the M3UA document is applicable to SUA. I don't know of an SUA test document from ETSI. Perhaps someone on this = list could identify one. Otherwise, the document you mention is the last that I have too. --brian On Fri, 24 Mar 2006, Troiano Marco wrote: >=20 > Hi all, >=20 > my name is Marco Troiano. I am a TLC engineer and I am going to te= st > SUA in our labs. I found the attached document and I would like = to > know if there is a later document to use for interoperability te= st > between two machines. >=20 > Can anybody help me? >=20 >=20 > Thanks in advance. >=20 >=20 > Marco Troiano --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 27 00:24:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNkCs-0005MJ-UT; Mon, 27 Mar 2006 00:23:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNkCs-0005ME-Gv for sigtran@ietf.org; Mon, 27 Mar 2006 00:23:58 -0500 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNkCr-0002xC-3y for sigtran@ietf.org; Mon, 27 Mar 2006 00:23:58 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP for sigtran@ietf.org; Mon, 27 Mar 2006 06:23:55 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Mar 2006 07:23:55 +0200 Message-Id: From: "Poetzl, Joachim" To: sigtran@ietf.org Date: Mon, 27 Mar 2006 07:23:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Sigtran] multihoming 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="===============2038081717==" Errors-To: sigtran-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2038081717== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6515E.A15C0DCD" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6515E.A15C0DCD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, has anyone experience with RTO values in SCTP multihoming scenario. Actually I would like to know when SCTP in failure scenarios on primary = path chooses to switch over to the secondary path. Which maximum delay can one anticipate when transmitting SS7 over IP = when the primary path is lost and SCTP choses to retransmit on the = secondary path. Regards > Joachim P=F6tzl Deutsche Telekom AG T-Com Zentrale TE332-4; Dienste- und Netzkonvergenz, Protokolle von NGN 64307 DARMSTADT, GERMANY=20 Phone: +49 6151 83-2134 Fax: +49 6151 83-4577 PCFax: +49 521 52244 983 > mailto:joachim.poetzl@t-com.net =20 >=20 ------_=_NextPart_001_01C6515E.A15C0DCD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable multihoming

Hi folks,

has anyone experience with RTO values = in SCTP multihoming scenario.

Actually I would like to know when = SCTP in failure scenarios on primary path chooses to switch over to the = secondary path.

Which maximum delay can one anticipate = when transmitting SS7 over IP when the primary path is lost and SCTP = choses to retransmit on the secondary path.

Regards

Joachim P=F6tzl
Deutsche Telekom AG
T-Com Zentrale
TE332-4; Dienste- und = Netzkonvergenz, Protokolle von NGN
64307 DARMSTADT, GERMANY
Phone:  +49 6151 83-2134
Fax:      = +49 6151 83-4577
PCFax:  +49 521 52244 = 983
mailto:joachim.poetzl@t-com.net

------_=_NextPart_001_01C6515E.A15C0DCD-- --===============2038081717== 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 --===============2038081717==-- From sigtran-bounces@ietf.org Tue Mar 28 09:02:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOEmV-0005PG-2Q; Tue, 28 Mar 2006 09:02:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOEmT-0005PB-3l for Sigtran@ietf.org; Tue, 28 Mar 2006 09:02:45 -0500 Received: from web54106.mail.yahoo.com ([206.190.37.241]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOEmR-0003kc-TQ for Sigtran@ietf.org; Tue, 28 Mar 2006 09:02:45 -0500 Received: (qmail 9621 invoked by uid 60001); 28 Mar 2006 14:02:43 -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=PKlDrWe7Soswhp4659Dr89YZyP5tOnnryF29J4v1e4CT99FqjgPKu24MEds6E8pUqv96L22XEMZA3zipIcuk4CEhsqhBF1vfasJKqBU7QFoRgCjXHVDgdnHImPL6V0ZG76oN0FaG3vTyadU9/3+EnylG33ArtijdQ1XlxnmR56o= ; Message-ID: <20060328140243.9619.qmail@web54106.mail.yahoo.com> Received: from [47.165.147.156] by web54106.mail.yahoo.com via HTTP; Tue, 28 Mar 2006 06:02:43 PST Date: Tue, 28 Mar 2006 06:02:43 -0800 (PST) From: Bahri Okuroglu Subject: RE: [Sigtran] Please help me regarding Automatis TEI managementprocedures in IUA 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: 4b800b1eab964a31702fa68f1ff0e955 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 Dynamic TEIs are assigned by SG upon ID_REQUEST messages from subscriber. ASP is only informed about this assignment by the TEIStatus.Ind messages. There is no relation with the b-channels and TEIs assigned. You can have much more TEIs then the number of b-channels. TEIStatus messages are for only a single TEI. A message cannot carry information for multiple TEIs. AFAIK, ASP does not initiate the TEI Request procedure, but the subsciber does for p2mp configuration. ASP is only notified about the assignment/removal, and can request the state of the TEIs. All is managed by the SG. --- Bahri OKUROGLU wrote: > > > -----Original Message----- > From: Bibhuti Bhusan Tosh [mailto:toshbi@nethawk.fi] > > Sent: 24 Mart 2006 Cuma 15:51 > To: Sigtran@ietf.org > Subject: [Sigtran] Please help me regarding > Automatis TEI > managementprocedures in IUA > > > > Hi All > > I am working on IUA rfc4233 and rfc3057 version. > > Please provide me the Auto TEI generation > techniques details. > 1. Are the number of TEIs are assigned to the > BChannels present in the > DChannel will have multiple TEIs as per its BChannel > count? > > The number of BChannels present are 2 for BRI > type and 23 for USA > PRI type and 30 for EUROPE PRI type. These TEIs are > assigned to the ASP > from SG using TEI Status Indication. > 2. Do we have to send as many unique TEIs in > separate Indication > messages? > 3. If the Dchannel has additional IID value then do > we need to used > another set of Indication messages of additional > IIDs? > 4. When the SG should start the TEI assignment > procedures? > 5. When the ASP will initiate the TEI rquest > procedures? > > Warm Regards, > Bibhuti Bhusan Tosh > > __________________________________________________ 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