From sigtran-bounces@ietf.org Wed Nov 02 03:35:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXE5w-00024e-Th; Wed, 02 Nov 2005 03:35:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXE5u-00020X-FK for sigtran@megatron.ietf.org; Wed, 02 Nov 2005 03:35:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20602 for ; Wed, 2 Nov 2005 03:35:22 -0500 (EST) Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXEKR-0005Ye-R2 for sigtran@ietf.org; Wed, 02 Nov 2005 03:50:45 -0500 Received: from bemail02.netfr.alcatel.fr (bemail02.netfr.alcatel.fr [155.132.251.36]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id jA28ZP5j003046 for ; Wed, 2 Nov 2005 09:35:25 +0100 Received: from [202.65.8.113] ([202.65.8.113]) by bemail02.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2005110209352337:725 ; Wed, 2 Nov 2005 09:35:23 +0100 Date: Wed, 02 Nov 2005 14:07:09 +0530 From: Kalyanaraman.Madhavan@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sigtran@ietf.org Subject: Re: [Sigtran] RFC3332: RC in DAVA Message References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL02/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/02/2005 09:35:24, Serialize by Router on BEMAIL02/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/02/2005 09:35:25, Serialize complete at 11/02/2005 09:35:25 Message-ID: X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 1.8 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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="===============1103383374==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1103383374== Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Samuel,

Thanks for reply.Currently an error is generated for this parameter & links are set to unavailable.

But the definition for parameter in RFC states,

Parameter Length: 16 bits (unsigned integer)

      The Parameter Length field contains the size of the parameter in
      bytes, including the Parameter Tag, Parameter Length, and
      Parameter Value fields.  Thus, a parameter with a zero-length
      Parameter Value field would have a Length field of 4.  The
      Parameter Length does not include any padding bytes."

In this case, RC parameter is received complying to above. For this an ERROR is reported from AS as you have stated below. The links are unavailable due to this communication in loop.

Kind Regards,Madhavan

Samuel Dur D. Jeyaseelan wrote:
Madhavan,

pls see my comments inline.

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Mon, 31 Oct 2005 Kalyanaraman.Madhavan@alcatel.com wrote:

  
Hi !!

I am currently involved in configuration of SGW to AS(doing this type of 
configuration for first time) & need following clarification as I cannot 
pick this out in clear way from RFC.

Scenario:

- AS sends DAUD to SGW without Routing Context
- AS receives DAVA with routing context parameter.The contents are tag 
id & length of the parameter without any value.In this case the length 
is 4 bytes (2 bytes for tag id & 2 bytes for length field itself)

Question:

Since AS has not sent a RC in DAUD, i assume the field should not be 
received in DAVA.Is my assumption inline with RFC ?
    
RC is a 'conditional' parameter that means it is very much needed when an
ASP serves more than one AS. In your case if the received RC does not find
any match in the static or dynamic databases then it is appropriate to
send an ERROR msg to SGW.

  
Thank you in advance,

Kind Regards,Madhavan



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

--===============1103383374== 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 --===============1103383374==-- From sigtran-bounces@ietf.org Wed Nov 02 03:55:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXEOs-0003XC-8p; Wed, 02 Nov 2005 03:55:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXEOp-0003X4-Tr for sigtran@megatron.ietf.org; Wed, 02 Nov 2005 03:55:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21539 for ; Wed, 2 Nov 2005 03:54:55 -0500 (EST) Received: from hostree9f.alcatel.com ([143.209.238.159] helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXEdN-0006df-I6 for sigtran@ietf.org; Wed, 02 Nov 2005 04:10:18 -0500 Received: from ssd.usa.alcatel.com (spdmail-qfe5.ssd.usa.alcatel.com [143.209.150.90]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id jA28sxYO009542; Wed, 2 Nov 2005 02:55:05 -0600 Received: from ssdtcom01.ssd.usa.alcatel.com (ssdtcom01.ssd.usa.alcatel.com [143.209.150.29]) by ssd.usa.alcatel.com (8.12.8/8.12.8) with ESMTP id jA28sdZB020433; Wed, 2 Nov 2005 02:54:39 -0600 (CST) Date: Wed, 2 Nov 2005 02:54:39 -0600 (CST) From: "Samuel Dur D. Jeyaseelan" To: Kalyanaraman.Madhavan@alcatel.com Subject: Re: [Sigtran] RFC3332: RC in DAVA Message In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Madhavan, Hope SGW might have received the ERROR msg with "Invalid Routing Context" but links should not go down. --Samuel Alcatel USA, Inc. Internet: @ssd.usa.alcatel.com 1000 Coit Road, Plano, Texas 75075 ******* The opinions expressed are not those of Alcatel USA, Inc. ******* On Wed, 2 Nov 2005 Kalyanaraman.Madhavan@alcatel.com wrote: > Hi Samuel, > > Thanks for reply.Currently an error is generated for this parameter & > links are set to unavailable. > > But the definition for parameter in RFC states, > > Parameter Length: 16 bits (unsigned integer) > > The Parameter Length field contains the size of the parameter in > bytes, including the Parameter Tag, Parameter Length, and > Parameter Value fields. Thus, a parameter with a zero-length > Parameter Value field would have a Length field of 4. The > Parameter Length does not include any padding bytes." > > In this case, RC parameter is received complying to above. For this an > ERROR is reported from AS as you have stated below. The links are > unavailable due to this communication in loop. > > Kind Regards,Madhavan > > Samuel Dur D. Jeyaseelan wrote: > > Madhavan, > > pls see my comments inline. > > --Samuel > > Alcatel USA, Inc. Internet: @ssd.usa.alcatel.com > 1000 Coit Road, Plano, Texas 75075 > ******* The opinions expressed are not those of Alcatel USA, Inc. ******* > > On Mon, 31 Oct 2005 Kalyanaraman.Madhavan@alcatel.com wrote: > > > > Hi !! > > I am currently involved in configuration of SGW to AS(doing this type of > configuration for first time) & need following clarification as I cannot > pick this out in clear way from RFC. > > Scenario: > > - AS sends DAUD to SGW without Routing Context > - AS receives DAVA with routing context parameter.The contents are tag > id & length of the parameter without any value.In this case the length > is 4 bytes (2 bytes for tag id & 2 bytes for length field itself) > > Question: > > Since AS has not sent a RC in DAUD, i assume the field should not be > received in DAVA.Is my assumption inline with RFC ? > > > RC is a 'conditional' parameter that means it is very much needed when an > ASP serves more than one AS. In your case if the received RC does not find > any match in the static or dynamic databases then it is appropriate to > send an ERROR msg to SGW. > > > > Thank you in advance, > > Kind Regards,Madhavan > > > > _______________________________________________ > 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 Nov 02 09:21:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJUl-00060O-8s; Wed, 02 Nov 2005 09:21:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJUj-0005zW-5K for sigtran@megatron.ietf.org; Wed, 02 Nov 2005 09:21:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08639 for ; Wed, 2 Nov 2005 09:21:18 -0500 (EST) Received: from smtp01.tekelec.com ([198.89.42.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXJjI-0003X7-F1 for sigtran@ietf.org; Wed, 02 Nov 2005 09:36:47 -0500 Received: from dcex05.tekelec.com (dcex05.tekelec.com [172.28.104.65]) by smtp01.tekelec.com (8.12.10/8.12.10) with ESMTP id jA2EKEPh016576 for ; Wed, 2 Nov 2005 08:20:14 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex05.tekelec.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 08:21:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Nov 2005 08:21:20 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E717020F7F7B@DCEVS2.tekelec.com> Thread-Topic: M2PA busy/lpo questions Thread-Index: AcXfuLIoLOtfvQsSSv2VGq6v8nMPPw== From: "Davidson, Mark" To: X-OriginalArrivalTime: 02 Nov 2005 14:21:21.0320 (UTC) FILETIME=[B297DA80:01C5DFB8] X-Spam-Score: 0.5 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: "Kanode, Mark" Subject: [Sigtran] M2PA busy/lpo questions 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="===============1455951621==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1455951621== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DFB8.B28540B1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DFB8.B28540B1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Flow control RFC text included at bottom for convenience... =20 Trying to sort out Busy/Busy End and LPO/ LPO End interactions. =20 The Level 2 flow control text doesn't say anything about buffering=20 during local busy (just says don't ack), but I'm assuming that's=20 the intent, i.e. to avoid retransmissions since M2PA doesn't=20 retransmit. (I'm a little confused as to why LPOR needs those=20 LSRs afterwards but LSBE doesn't, but that's not my real question.) =20 Anyway, it gets really interesting when you have a (local)=20 busy condition, then LPO condition. MTP2 spec is clear - Stop=20 T5, move to PO state. When PO ends, MSUs may again trigger=20 Busy condition, but if there's no traffic, then no Busy condition. =20 The reverse, LPO followed by Busy does not occur in MTP2 because=20 MSUs are discarded in LPO, so busy is not triggered. =20 Question 1. In M2PA , should an LSBE be expected in the case where=20 there is a local busy followed by LPO? It seems unnecessary to=20 me - the LSPO message should imply an end to the Busy condition. =20 Buffered Busy messages can become buffered LPO messages that are=20 acked during LPO recovery. =20 Question 2. Assuming traffic is buffered in M2PA during local busy, it is possible that the busy condition may not subside during a=20 transient LPO condition. I.e. LPO ends but queues are still backed=20 up. Should the Busy resume? What should be acked? Should we wait=20 for the LSRs to be exchanged before sending LSB? =20 -Mark Davidson =20 >From the RFC: =20 4.1.5. Level 2 Flow Control =20 The Link Status Busy message replaces the SIB message of MTP2. The message SHOULD NOT be transmitted continuously. M2PA SHALL send a Link Status Busy message to its peer at the beginning of a receive congestion condition where MTP2 would send SIB. M2PA MAY send additional Link Status Busy messages as long as that condition persists. When the condition ends, M2PA SHALL send a Link Status Busy Ended message to its peer. =20 M2PA SHALL continue transmitting messages while it is in receive congestion, but MUST NOT acknowledge the message that triggered the sending of the Link Status Busy message, nor any messages received before the sending of Link Status Busy Ended. =20 When the peer M2PA receives the first Link Status Busy message, it SHALL start the Remote Congestion timer T6 if there are messages in the retransmission buffer awaiting acknowledgement (i.e., T7 is running). M2PA SHALL stop the T7 timer if it is running. Additional Link Status Busy messages received while T6 is running do not cause T6 to be reset and do not cause T7 to be started. While T6 is running, T7 SHALL NOT be started. =20 When the peer M2PA receives the Link Status Busy Ended message and T6 has not expired, it SHALL stop T6 (if T6 is running) and start T7 (if there are messages awaiting acknowledgement in the retransmission buffer). =20 The peer M2PA SHOULD continue receiving and acknowledging messages while the other end is busy, but MUST NOT send User Data messages after receiving Link Status Busy and before receiving Link Status Busy Ended. ------_=_NextPart_001_01C5DFB8.B28540B1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Flow control=20 RFC text included at bottom for = convenience...
 
Trying to=20 sort out Busy/Busy End and LPO/ LPO End = interactions.
 
The Level 2=20 flow control text doesn't say anything about buffering =
during local=20 busy (just says don't ack), = but I'm assuming that's=20
the intent, i.e. to avoid retransmissions = since M2PA=20 doesn't
retransmit. (I'm a little confused as to why LPOR needs = those=20
LSRs=20 afterwards but LSBE doesn't, but that's=20 not my real question.)
 
Anyway, it=20 gets really interesting when you have a (local)
busy=20 condition, then LPO condition.  MTP2 spec is clear - Stop=20
T5,=20 move to PO state. When PO ends,=20 MSUs may again trigger =
Busy=20 condition, but if there's no traffic, then=20 no Busy condition.
 
The reverse,=20 LPO followed by Busy does not occur in MTP2 because
MSUs are=20 discarded in LPO, so busy is not triggered.
 
Question 1. In M2PA , should an LSBE be = expected=20 in the case where
there=20 is a local busy=20 followed by LPO? It seems unnecessary to =
me - the=20 LSPO message should imply an end to the Busy condition. =20
Buffered=20 Busy messages can become buffered LPO messages that are=20
acked during=20 LPO=20 recovery.
 
Question 2.=20 Assuming traffic is buffered in M2PA during local = busy,
it is=20 possible that the busy condition may not = subside during=20 a
transient=20 LPO condition.  I.e. LPO ends but queues are still = backed=20
up. =20 Should the Busy resume? What should be acked? Should we wait=20
for the LSRs=20 to be exchanged before sending LSB?
 
-Mark=20 Davidson
 
From the=20 RFC:
 
=
4.1.5. =20 Level 2 Flow Control
 
  =20 The Link Status Busy message replaces the SIB message of MTP2. =20 The
   message SHOULD NOT be transmitted = continuously.  M2PA=20 SHALL send a
   Link Status Busy message to its peer at the = beginning of a receive
   congestion condition where MTP2 = would=20 send SIB.  M2PA MAY send
   additional Link Status = Busy=20 messages as long as that condition
   persists.  When = the=20 condition ends, M2PA SHALL send a Link Status
   Busy Ended = message=20 to its peer.
 
  =20 M2PA SHALL continue transmitting messages while it is in = receive
  =20 congestion, but MUST NOT acknowledge the message that triggered=20 the
   sending of the Link Status Busy message, nor any = messages=20 received
   before the sending of Link Status Busy=20 Ended.
 
  =20 When the peer M2PA receives the first Link Status Busy message,=20 it
   SHALL start the Remote Congestion timer T6 if there = are=20 messages in
   the retransmission buffer awaiting = acknowledgement=20 (i.e., T7 is
   running).  M2PA SHALL stop the T7 = timer if it=20 is running.  Additional
   Link Status Busy messages = received=20 while T6 is running do not cause
   T6 to be reset and do = not cause=20 T7 to be started.  While T6 is
   running, T7 SHALL = NOT be=20 started.
 
  =20 When the peer M2PA receives the Link Status Busy Ended message and=20 T6
   has not expired, it SHALL stop T6 (if T6 is running) = and=20 start T7 (if
   there are messages awaiting acknowledgement = in the=20 retransmission
   buffer).
 
  =20 The peer M2PA SHOULD continue receiving and acknowledging=20 messages
   while the other end is busy, but MUST NOT send = User=20 Data messages
   after receiving Link Status Busy and = before=20 receiving Link Status
   Busy=20 Ended.
------_=_NextPart_001_01C5DFB8.B28540B1-- --===============1455951621== 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 --===============1455951621==-- From sigtran-bounces@ietf.org Wed Nov 02 12:27:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMOg-0000qw-BR; Wed, 02 Nov 2005 12:27:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMOe-0000pI-EF for sigtran@megatron.ietf.org; Wed, 02 Nov 2005 12:27:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23386 for ; Wed, 2 Nov 2005 12:27:14 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[iaCC5eGDJnaG4oNKH6rzZIrhmhq0nV5r]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMdE-0005BR-Or for sigtran@ietf.org; Wed, 02 Nov 2005 12:42:43 -0500 Received: from ns.pigworks.openss7.net (IDENT:sNAUcaR13zTJGe+xsCwfIRcIUSNbgxri@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA2HRDc11849; Wed, 2 Nov 2005 10:27:13 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA2HRB325580; Wed, 2 Nov 2005 10:27:11 -0700 Date: Wed, 2 Nov 2005 10:27:11 -0700 From: "Brian F. G. Bidulock" To: "Davidson, Mark" Subject: Re: [Sigtran] M2PA busy/lpo questions Message-ID: <20051102102711.A25467@openss7.org> Mail-Followup-To: "Davidson, Mark" , sigtran@ietf.org, "Kanode, Mark" References: <58292FA6B3EEFD49AEDAF6597E21E717020F7F7B@DCEVS2.tekelec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <58292FA6B3EEFD49AEDAF6597E21E717020F7F7B@DCEVS2.tekelec.com>; from Mark.Davidson@tekelec.com on Wed, Nov 02, 2005 at 08:21:20AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: "Kanode, Mark" , sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Mark, A couple comments: Q1) I think it is clear that LSPO does not clear LSB, only LSBE does. Under M2PA both PO and Busy conditions can exist at the same time. Q2) I think buffered messages are buffered messages, regardless of what condition prevailed when they were buffered. When M2PA exits PO state and Busy still prevails, I think the text is clear with regard to how data messages are treated before LSBE is sent or received, in the passages you quoted. --brian Davidson, Mark wrote: (Wed, 02 Nov 2005 08:21:20) > > Flow control RFC text included at bottom for convenience... > > > > Trying to sort out Busy/Busy End and LPO/ LPO End interactions. > > > > The Level 2 flow control text doesn't say anything about buffering > > during local busy (just says don't ack), but I'm assuming that's > > the intent, i.e. to avoid retransmissions since M2PA doesn't > > retransmit. (I'm a little confused as to why LPOR needs those > > LSRs afterwards but LSBE doesn't, but that's not my real question.) > > > > Anyway, it gets really interesting when you have a (local) > > busy condition, then LPO condition. MTP2 spec is clear - Stop > > T5, move to PO state. When PO ends, MSUs may again trigger > > Busy condition, but if there's no traffic, then no Busy condition. > > > > The reverse, LPO followed by Busy does not occur in MTP2 because > > MSUs are discarded in LPO, so busy is not triggered. > > > > Question 1. In M2PA , should an LSBE be expected in the case where > > there is a local busy followed by LPO? It seems unnecessary to > > me - the LSPO message should imply an end to the Busy condition. > > Buffered Busy messages can become buffered LPO messages that are > > acked during LPO recovery. > > > > Question 2. Assuming traffic is buffered in M2PA during local busy, > > it is possible that the busy condition may not subside during a > > transient LPO condition. I.e. LPO ends but queues are still backed > > up. Should the Busy resume? What should be acked? Should we wait > > for the LSRs to be exchanged before sending LSB? > > > > -Mark Davidson > > > > From the RFC: > > > > 4.1.5. Level 2 Flow Control > > > > The Link Status Busy message replaces the SIB message of MTP2. The > message SHOULD NOT be transmitted continuously. M2PA SHALL send a > Link Status Busy message to its peer at the beginning of a receive > congestion condition where MTP2 would send SIB. M2PA MAY send > additional Link Status Busy messages as long as that condition > persists. When the condition ends, M2PA SHALL send a Link Status > Busy Ended message to its peer. > > > > M2PA SHALL continue transmitting messages while it is in receive > congestion, but MUST NOT acknowledge the message that triggered the > sending of the Link Status Busy message, nor any messages received > before the sending of Link Status Busy Ended. > > > > When the peer M2PA receives the first Link Status Busy message, it > SHALL start the Remote Congestion timer T6 if there are messages in > the retransmission buffer awaiting acknowledgement (i.e., T7 is > running). M2PA SHALL stop the T7 timer if it is running. > Additional > Link Status Busy messages received while T6 is running do not cause > T6 to be reset and do not cause T7 to be started. While T6 is > running, T7 SHALL NOT be started. > > > > When the peer M2PA receives the Link Status Busy Ended message and > T6 > has not expired, it SHALL stop T6 (if T6 is running) and start T7 > (if > there are messages awaiting acknowledgement in the retransmission > buffer). > > > > The peer M2PA SHOULD continue receiving and acknowledging messages > while the other end is busy, but MUST NOT send User Data messages > after receiving Link Status Busy and before receiving Link Status > Busy Ended. > _______________________________________________ > 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 Nov 02 13:42:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXNYi-0002Ry-PR; Wed, 02 Nov 2005 13:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXNYc-0002O9-ER for sigtran@megatron.ietf.org; Wed, 02 Nov 2005 13:42:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29870 for ; Wed, 2 Nov 2005 13:41:36 -0500 (EST) Received: from smtp01.tekelec.com ([198.89.42.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXNnD-0000ry-UQ for sigtran@ietf.org; Wed, 02 Nov 2005 13:57:06 -0500 Received: from dcex04.tekelec.com (dcex04.tekelec.com [172.28.104.64]) by smtp01.tekelec.com (8.12.10/8.12.10) with ESMTP id jA2IedPh004831 for ; Wed, 2 Nov 2005 12:40:39 -0600 (CST) Received: from DCEVS2.tekelec.com ([172.28.104.62]) by dcex04.tekelec.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 12:41:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] M2PA busy/lpo questions Date: Wed, 2 Nov 2005 12:41:45 -0600 Message-ID: <58292FA6B3EEFD49AEDAF6597E21E71702133DC1@DCEVS2.tekelec.com> Thread-Topic: [Sigtran] M2PA busy/lpo questions Thread-Index: AcXf0q9nPN5CsG/PSA60yUQjC7rk7AAB21mw From: "Davidson, Mark" To: X-OriginalArrivalTime: 02 Nov 2005 18:41:46.0255 (UTC) FILETIME=[13C7B9F0:01C5DFDD] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: quoted-printable X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, >Q1) I think it is clear that LSPO does not clear LSB, only LSBE does. It is clear how a busy clear condition is signaled, but not when it ends. There is a difference.=20 > Under M2PA both PO and Busy conditions can exist at the same time. Works for me, but where does it say that? >Q2) I think buffered messages are buffered messages, regardless of > what condition prevailed when they were buffered. When M2PA exits v PO state and Busy still prevails, I think the text is clear with > regard to how data messages are treated before LSBE is sent or > received, in the passages you quoted. The text I quoted says NOTHING about buffering received msgs, so I=20 don't see how it can be clear on the subject. Anyway, I think this is your interpretation: During local busy OR LPO (or both) buffer and do not acknowledge received MSUs. When BOTH conditions are cleared, process and acknowledged buffered messages. This is handled explicitly by PO procedures, for local busy=20 an ack must be sent if there was at least one data message buffered=20 (per other text requiring immediate ack). Local busy can continue during LPO and still be in effect after LPO ends. -Mark > >--brian > >Davidson, Mark wrote: (Wed, 02 Nov 2005 08:21:20) >>=20 >> Flow control RFC text included at bottom for convenience... >>=20 >>=20 >>=20 >> Trying to sort out Busy/Busy End and LPO/ LPO End interactions. >>=20 >>=20 >>=20 >> The Level 2 flow control text doesn't say anything about buffering >>=20 >> during local busy (just says don't ack), but I'm assuming that's >>=20 >> the intent, i.e. to avoid retransmissions since M2PA doesn't >>=20 >> retransmit. (I'm a little confused as to why LPOR needs those >>=20 >> LSRs afterwards but LSBE doesn't, but that's not my real question.) >>=20 >>=20 >>=20 >> Anyway, it gets really interesting when you have a (local) >>=20 >> busy condition, then LPO condition. MTP2 spec is clear - Stop >>=20 >> T5, move to PO state. When PO ends, MSUs may again trigger >>=20 >> Busy condition, but if there's no traffic, then no Busy condition. >>=20 >>=20 >>=20 >> The reverse, LPO followed by Busy does not occur in MTP2 because >>=20 >> MSUs are discarded in LPO, so busy is not triggered. >>=20 >>=20 >>=20 >> Question 1. In M2PA , should an LSBE be expected in the case where >>=20 >> there is a local busy followed by LPO? It seems unnecessary to >>=20 >> me - the LSPO message should imply an end to the Busy condition. >>=20 >> Buffered Busy messages can become buffered LPO messages that are >>=20 >> acked during LPO recovery. >>=20 >>=20 >>=20 >> Question 2. Assuming traffic is buffered in M2PA during local busy, >>=20 >> it is possible that the busy condition may not subside during a >>=20 >> transient LPO condition. I.e. LPO ends but queues are still backed >>=20 >> up. Should the Busy resume? What should be acked? Should we wait >>=20 >> for the LSRs to be exchanged before sending LSB? >>=20 >>=20 >>=20 >> -Mark Davidson >>=20 >>=20 >>=20 > From the RFC: >=20 >=20 >=20 > 4.1.5. Level 2 Flow Control >=20 >=20 >=20 > The Link Status Busy message replaces the SIB message of MTP2. The > message SHOULD NOT be transmitted continuously. M2PA SHALL send a > Link Status Busy message to its peer at the beginning of a receive > congestion condition where MTP2 would send SIB. M2PA MAY send > additional Link Status Busy messages as long as that condition > persists. When the condition ends, M2PA SHALL send a Link Status > Busy Ended message to its peer. >=20 >=20 >=20 > M2PA SHALL continue transmitting messages while it is in receive > congestion, but MUST NOT acknowledge the message that triggered the > sending of the Link Status Busy message, nor any messages received > before the sending of Link Status Busy Ended. >=20 >=20 >=20 > When the peer M2PA receives the first Link Status Busy message, it > SHALL start the Remote Congestion timer T6 if there are messages in > the retransmission buffer awaiting acknowledgement (i.e., T7 is > running). M2PA SHALL stop the T7 timer if it is running. > Additional > Link Status Busy messages received while T6 is running do not cause > T6 to be reset and do not cause T7 to be started. While T6 is > running, T7 SHALL NOT be started. >=20 >=20 >=20 > When the peer M2PA receives the Link Status Busy Ended message and > T6 > has not expired, it SHALL stop T6 (if T6 is running) and start T7 > (if > there are messages awaiting acknowledgement in the retransmission > buffer). >=20 >=20 >=20 > The peer M2PA SHOULD continue receiving and acknowledging messages > while the other end is busy, but MUST NOT send User Data messages > after receiving Link Status Busy and before receiving Link Status > Busy Ended. > _______________________________________________ > 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 Nov 04 05:12:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXyYb-00078R-Ga; Fri, 04 Nov 2005 05:12:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXyYa-00078M-7q for sigtran@megatron.ietf.org; Fri, 04 Nov 2005 05:12:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07990 for ; Fri, 4 Nov 2005 05:12:00 -0500 (EST) From: arijit.dilip@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXynX-0000o9-7i for sigtran@ietf.org; Fri, 04 Nov 2005 05:27:53 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 4612E205DE for ; Fri, 4 Nov 2005 15:29:30 +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 2B75C205DA for ; Fri, 4 Nov 2005 15:29:30 +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); Fri, 4 Nov 2005 15:42:06 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Nov 2005 15:42:06 +0530 Message-ID: Thread-Topic: Doubt regarding Error codes thread-index: AcXhKDWwm4kQB8cKTEqHc+SVzAsTMw== To: X-OriginalArrivalTime: 04 Nov 2005 10:12:06.0996 (UTC) FILETIME=[35F29940:01C5E128] X-Spam-Score: 0.5 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [Sigtran] Doubt regarding Error codes 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="===============0000185591==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0000185591== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E128.35C6EF6D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E128.35C6EF6D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 In SUA(RFC 3868) ERR(Error message, Section 3.7.1) message it is written that=20 Routing Context Mandatory *1 Network Appearance Mandatory *1 Affected Point Code Mandatory *1 Note 1: Only mandatory for specific error codes. Can I please know for which error codes this parameters are mandatory. =20 Thanks and Regards, Arijit =20 ------_=_NextPart_001_01C5E128.35C6EF6D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = All,
 
In SUA(RFC = 3868) ERR(Error=20 message, Section 3.7.1) message it is written that =

Routing = Context        &nbs= p; =20 Mandatory *1

Network=20 Appearance        Mandatory=20 *1

Affected = Point=20 Code      =20 Mandatory *1

Note 1: Only mandatory for specific error=20 codes.

Can I please = know for which=20 error codes this parameters are mandatory.
 
Thanks and=20 Regards,
Arijit
 
------_=_NextPart_001_01C5E128.35C6EF6D-- --===============0000185591== 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 --===============0000185591==-- From sigtran-bounces@ietf.org Fri Nov 04 09:48:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY2rX-0002Dj-C1; Fri, 04 Nov 2005 09:48:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY2rW-0002Dc-6U for sigtran@megatron.ietf.org; Fri, 04 Nov 2005 09:48:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23795 for ; Fri, 4 Nov 2005 09:47:50 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY36W-0000VI-56 for sigtran@ietf.org; Fri, 04 Nov 2005 10:03:45 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA4Em8XG005577 for ; Fri, 4 Nov 2005 08:48:10 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Nov 2005 20:18:08 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB685A@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: "'sigtran@ietf.org'" Date: Fri, 4 Nov 2005 20:18:07 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi, I had a specific question related to a specific scenario explained below (Single Exchange scenario) NodeA supports 1 PS with 1 IPSP NodeB supports 1 PS with 2 IPSPs in Loadshared mode. There are two associations between NodeA and NodeB. The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). The IPSP2 and IPSP3, which are serving loadshared for the PS2 on NodeB, send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means that IPSP2 and IPSP3, serving a loadshared PS2, are essentially telling NodeA to loadshare all the traffic for PS2, between IPSP2 and IPSP3. The above concepts are also illustrated below....(I have purposefully avoided AS-ACTIVE notification) NodeA <------------NodeB------------> PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 | | | |<-----ASP Up------------| | |-------ASP Up Ack------>| (Assoc #1) | | | | | | | |<--------------------ASP Up------------------------| (Assoc #2) |----------------------------ASP Up Ack------------>| | | | | | | | | | |<--ASP Active(Ldshr)----| | |------ASP Active Ack--->| | | | | | | | | | | |<--------------------ASP Active(Ldshr)-------------| |----------------------------ASP Up Ack------------>| | | | | | | |---NOTIFY(AS-ACTIVE)--->| | |--------------------------NOTIFY(AS-ACTIVE)------->| | | | Questions: Assuming a single exchange scenario, would the traffic towards PS1 on NodeA, be also loadshared across 2 associations ? I thought it would and hence another follow-up question: It looks like a loadshared peer (NodeB in our case) with multiple IPSPs, is putting a constraint on the NodeA, to ALSO be ready to receive data on multiple associations and possibly loadshared. Is this a fair understanding ? shashank _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Nov 04 10:01:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY33z-0004Yp-C1; Fri, 04 Nov 2005 10:01:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY33y-0004Yj-C6 for sigtran@megatron.ietf.org; Fri, 04 Nov 2005 10:01:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24327 for ; Fri, 4 Nov 2005 10:00:42 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY3Iz-0000oQ-6v for sigtran@ietf.org; Fri, 04 Nov 2005 10:16:37 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA4F0fvV014620 for ; Fri, 4 Nov 2005 10:00:43 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Fri, 4 Nov 2005 09:43:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB685A@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, As far as I understand your question: You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC for this RK to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing mode. You are wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3. Yes, it can, but I wouldn't call it traffic being loadshared to IPSP1. IPSP2 and IPSP3 are not the same entities. OTOH it makes sense to speak of loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a single source is distrubuted to multiple peers. Tolga > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Prasad, Shashank S (Shashank) > Sent: Friday, November 04, 2005 9:48 AM > To: 'sigtran@ietf.org' > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Hi, > I had a specific question related to a specific scenario explained below > (Single Exchange scenario) > > NodeA supports 1 PS with 1 IPSP > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > There are two associations between NodeA and NodeB. > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 on NodeB, > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > that IPSP2 and > IPSP3, > serving a loadshared PS2, are essentially telling NodeA to > loadshare all the > traffic > for PS2, between IPSP2 and IPSP3. > > The above concepts are also illustrated below....(I have purposefully > avoided AS-ACTIVE notification) > > > > NodeA <------------NodeB------------> > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > | | | > |<-----ASP Up------------| | > |-------ASP Up Ack------>| (Assoc #1) | > | | | > | | | > |<--------------------ASP Up------------------------| (Assoc #2) > |----------------------------ASP Up Ack------------>| > | | | > | | | > | | | > |<--ASP Active(Ldshr)----| | > |------ASP Active Ack--->| | > | | | > | | | > | | | > |<--------------------ASP Active(Ldshr)-------------| > |----------------------------ASP Up Ack------------>| > | | | > | | | > |---NOTIFY(AS-ACTIVE)--->| | > |--------------------------NOTIFY(AS-ACTIVE)------->| > | | | > > > > Questions: > Assuming a single exchange scenario, would the traffic towards > PS1 on NodeA, > > be also loadshared across 2 associations ? > > I thought it would and hence another follow-up question: > It looks like a loadshared peer (NodeB in our case) with multiple IPSPs, > is putting a constraint on the NodeA, to ALSO be ready to receive data on > multiple associations and possibly loadshared. Is this a fair > understanding > ? > > > shashank > > _______________________________________________ > 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 Nov 04 10:28:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3UU-0000j3-SY; Fri, 04 Nov 2005 10:28:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3UR-0000iO-Kn for sigtran@megatron.ietf.org; Fri, 04 Nov 2005 10:28:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25769 for ; Fri, 4 Nov 2005 10:28:03 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY3jQ-0001aE-Qj for sigtran@ietf.org; Fri, 04 Nov 2005 10:43:59 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA4FSGOR002793; Fri, 4 Nov 2005 09:28:22 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Nov 2005 20:58:15 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB685B@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: "'Tolga Asveren'" , sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Fri, 4 Nov 2005 20:58:14 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Thanx Tolga. U are right in understanding my question. Followup Question: Since IPSP2 and IPSP3 are serving the same AS, what would determine at NodeB, if the traffic to IPSP1 is to be sent via IPSP2 or IPSP3 ? shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Friday, November 04, 2005 8:13 PM To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Shashank, As far as I understand your question: You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC for this RK to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing mode. You are wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3. Yes, it can, but I wouldn't call it traffic being loadshared to IPSP1. IPSP2 and IPSP3 are not the same entities. OTOH it makes sense to speak of loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a single source is distrubuted to multiple peers. Tolga > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Prasad, Shashank S (Shashank) > Sent: Friday, November 04, 2005 9:48 AM > To: 'sigtran@ietf.org' > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Hi, > I had a specific question related to a specific scenario explained below > (Single Exchange scenario) > > NodeA supports 1 PS with 1 IPSP > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > There are two associations between NodeA and NodeB. > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 on NodeB, > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > that IPSP2 and > IPSP3, > serving a loadshared PS2, are essentially telling NodeA to > loadshare all the > traffic > for PS2, between IPSP2 and IPSP3. > > The above concepts are also illustrated below....(I have purposefully > avoided AS-ACTIVE notification) > > > > NodeA <------------NodeB------------> > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > | | | > |<-----ASP Up------------| | > |-------ASP Up Ack------>| (Assoc #1) | > | | | > | | | > |<--------------------ASP Up------------------------| (Assoc #2) > |----------------------------ASP Up Ack------------>| > | | | > | | | > | | | > |<--ASP Active(Ldshr)----| | > |------ASP Active Ack--->| | > | | | > | | | > | | | > |<--------------------ASP Active(Ldshr)-------------| > |----------------------------ASP Up Ack------------>| > | | | > | | | > |---NOTIFY(AS-ACTIVE)--->| | > |--------------------------NOTIFY(AS-ACTIVE)------->| > | | | > > > > Questions: > Assuming a single exchange scenario, would the traffic towards > PS1 on NodeA, > > be also loadshared across 2 associations ? > > I thought it would and hence another follow-up question: > It looks like a loadshared peer (NodeB in our case) with multiple IPSPs, > is putting a constraint on the NodeA, to ALSO be ready to receive data on > multiple associations and possibly loadshared. Is this a fair > understanding > ? > > > shashank > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Nov 04 10:38:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3eQ-0003kq-CR; Fri, 04 Nov 2005 10:38:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3eP-0003ke-BK for sigtran@megatron.ietf.org; Fri, 04 Nov 2005 10:38:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26306 for ; Fri, 4 Nov 2005 10:38:21 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY3tP-0001tS-6G for sigtran@ietf.org; Fri, 04 Nov 2005 10:54:16 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA4FcNmN018792 for ; Fri, 4 Nov 2005 10:38:25 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Fri, 4 Nov 2005 10:20:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB685B@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is implementation/traffic type dependent and is not something standardized by M3UA. > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Friday, November 04, 2005 10:28 AM > To: 'Tolga Asveren'; sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Thanx Tolga. U are right in understanding my question. > > Followup Question: > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > NodeB, if the traffic to IPSP1 is > to be sent via IPSP2 or IPSP3 ? > > > shashank > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Friday, November 04, 2005 8:13 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > As far as I understand your question: > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > for this RK > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > mode. You are > wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3. > > Yes, it can, but I wouldn't call it traffic being loadshared to > IPSP1. IPSP2 > and IPSP3 are not the same entities. OTOH it makes sense to speak of > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a > single source is distrubuted to multiple peers. > > Tolga > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Prasad, Shashank S (Shashank) > > Sent: Friday, November 04, 2005 9:48 AM > > To: 'sigtran@ietf.org' > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Hi, > > I had a specific question related to a specific scenario explained below > > (Single Exchange scenario) > > > > NodeA supports 1 PS with 1 IPSP > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > There are two associations between NodeA and NodeB. > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 on NodeB, > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > that IPSP2 and > > IPSP3, > > serving a loadshared PS2, are essentially telling NodeA to > > loadshare all the > > traffic > > for PS2, between IPSP2 and IPSP3. > > > > The above concepts are also illustrated below....(I have purposefully > > avoided AS-ACTIVE notification) > > > > > > > > NodeA <------------NodeB------------> > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > | | | > > |<-----ASP Up------------| | > > |-------ASP Up Ack------>| (Assoc #1) | > > | | | > > | | | > > |<--------------------ASP Up------------------------| > (Assoc #2) > > |----------------------------ASP Up Ack------------>| > > | | | > > | | | > > | | | > > |<--ASP Active(Ldshr)----| | > > |------ASP Active Ack--->| | > > | | | > > | | | > > | | | > > |<--------------------ASP Active(Ldshr)-------------| > > |----------------------------ASP Up Ack------------>| > > | | | > > | | | > > |---NOTIFY(AS-ACTIVE)--->| | > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > | | | > > > > > > > > Questions: > > Assuming a single exchange scenario, would the traffic towards > > PS1 on NodeA, > > > > be also loadshared across 2 associations ? > > > > I thought it would and hence another follow-up question: > > It looks like a loadshared peer (NodeB in our case) with > multiple IPSPs, > > is putting a constraint on the NodeA, to ALSO be ready to > receive data on > > multiple associations and possibly loadshared. Is this a fair > > understanding > > ? > > > > > > shashank > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Nov 04 11:06:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY45X-0000rt-OH; Fri, 04 Nov 2005 11:06:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY45V-0000ro-GU for sigtran@megatron.ietf.org; Fri, 04 Nov 2005 11:06:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27435 for ; Fri, 4 Nov 2005 11:06:20 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY4KW-0002ai-8O for sigtran@ietf.org; Fri, 04 Nov 2005 11:22:16 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA4G6ZP2028141; Fri, 4 Nov 2005 10:06:36 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Nov 2005 21:36:34 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB685C@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: "'Tolga Asveren'" , sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Fri, 4 Nov 2005 21:36:34 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Oh OK ! Looks like, it could potentially happen that NodeB can limit itself to sending traffic for PS1 on only one of associations also, rather than both. However, IPSP1 has really to "listen" at both the associations. Is that correct ? A couple of more questions that now comes up: 1. In a single ended scenario, how could have IPSP1 (at NodeA) determined the Traffic Mode of AS2 at NodeB, if the ASP Active was sent from IPSP1 to IPSP2 and IPSP3 ? (Instead of what is shown my illustration) 2. In a single exchange scenario, isn't it needed to have the peer ASs having the same Traffic Mode ? shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Friday, November 04, 2005 8:51 PM To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow This is implementation/traffic type dependent and is not something standardized by M3UA. > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Friday, November 04, 2005 10:28 AM > To: 'Tolga Asveren'; sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Thanx Tolga. U are right in understanding my question. > > Followup Question: > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > NodeB, if the traffic to IPSP1 is > to be sent via IPSP2 or IPSP3 ? > > > shashank > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Friday, November 04, 2005 8:13 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > As far as I understand your question: > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > for this RK > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > mode. You are > wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3. > > Yes, it can, but I wouldn't call it traffic being loadshared to > IPSP1. IPSP2 > and IPSP3 are not the same entities. OTOH it makes sense to speak of > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a > single source is distrubuted to multiple peers. > > Tolga > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Prasad, Shashank S (Shashank) > > Sent: Friday, November 04, 2005 9:48 AM > > To: 'sigtran@ietf.org' > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Hi, > > I had a specific question related to a specific scenario explained below > > (Single Exchange scenario) > > > > NodeA supports 1 PS with 1 IPSP > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > There are two associations between NodeA and NodeB. > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 on NodeB, > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > that IPSP2 and > > IPSP3, > > serving a loadshared PS2, are essentially telling NodeA to > > loadshare all the > > traffic > > for PS2, between IPSP2 and IPSP3. > > > > The above concepts are also illustrated below....(I have purposefully > > avoided AS-ACTIVE notification) > > > > > > > > NodeA <------------NodeB------------> > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > | | | > > |<-----ASP Up------------| | > > |-------ASP Up Ack------>| (Assoc #1) | > > | | | > > | | | > > |<--------------------ASP Up------------------------| > (Assoc #2) > > |----------------------------ASP Up Ack------------>| > > | | | > > | | | > > | | | > > |<--ASP Active(Ldshr)----| | > > |------ASP Active Ack--->| | > > | | | > > | | | > > | | | > > |<--------------------ASP Active(Ldshr)-------------| > > |----------------------------ASP Up Ack------------>| > > | | | > > | | | > > |---NOTIFY(AS-ACTIVE)--->| | > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > | | | > > > > > > > > Questions: > > Assuming a single exchange scenario, would the traffic towards > > PS1 on NodeA, > > > > be also loadshared across 2 associations ? > > > > I thought it would and hence another follow-up question: > > It looks like a loadshared peer (NodeB in our case) with > multiple IPSPs, > > is putting a constraint on the NodeA, to ALSO be ready to > receive data on > > multiple associations and possibly loadshared. Is this a fair > > understanding > > ? > > > > > > shashank > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Nov 04 11:56:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY4rq-0001ox-Cb; Fri, 04 Nov 2005 11:56:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY4ro-0001oM-6s for sigtran@megatron.ietf.org; Fri, 04 Nov 2005 11:56:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01040 for ; Fri, 4 Nov 2005 11:56:15 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY56n-0004Dg-Rt for sigtran@ietf.org; Fri, 04 Nov 2005 12:12:12 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA4GuFi0026828 for ; Fri, 4 Nov 2005 11:56:17 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Fri, 4 Nov 2005 11:38:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB685C@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Prasad, Shashank S (Shashank) > Sent: Friday, November 04, 2005 11:07 AM > To: 'Tolga Asveren'; sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Oh OK ! > Looks like, it could potentially happen that NodeB can limit itself to > sending traffic for PS1 on only one of associations also, rather > than both. > However, IPSP1 has really to "listen" at both the associations. > Is that correct ? [TOLGA]Yes. Please also note that it is the M3UA-User which controls this behavior on Node-B, i.e. this is not loadhsaring on M3UA level but one layer above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When they receive a message from their user, they will send it to IPSP1. > > A couple of more questions that now comes up: > 1. In a single ended scenario, how could have IPSP1 (at NodeA) determined > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent from IPSP1 to > IPSP2 and IPSP3 ? (Instead of what is shown my illustration) [TOLGA]Through local configuration, please note Traffic Mode parameter is optional. OTOH, I think that it could be an idea to modify the protocol a bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending side about traffic mode on the peer side in case it is necessary. > > 2. In a single exchange scenario, isn't it needed to have the peer ASs > having the same Traffic Mode ? [TOLGA]I believe what you mean as "AS traffic mode" is traffic mode of peer IPSPs in the context of an AS. As far as I can see different traffic modes shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE simultaneously at both sides. > > shashank > > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Friday, November 04, 2005 8:51 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > This is implementation/traffic type dependent and is not something > standardized by M3UA. > > > -----Original Message----- > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > Sent: Friday, November 04, 2005 10:28 AM > > To: 'Tolga Asveren'; sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Thanx Tolga. U are right in understanding my question. > > > > Followup Question: > > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > > NodeB, if the traffic to IPSP1 is > > to be sent via IPSP2 or IPSP3 ? > > > > > > shashank > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Friday, November 04, 2005 8:13 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > As far as I understand your question: > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > for this RK > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > mode. You are > > wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3. > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > IPSP1. IPSP2 > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a > > single source is distrubuted to multiple peers. > > > > Tolga > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Friday, November 04, 2005 9:48 AM > > > To: 'sigtran@ietf.org' > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Hi, > > > I had a specific question related to a specific scenario > explained below > > > (Single Exchange scenario) > > > > > > NodeA supports 1 PS with 1 IPSP > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > There are two associations between NodeA and NodeB. > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > on NodeB, > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > that IPSP2 and > > > IPSP3, > > > serving a loadshared PS2, are essentially telling NodeA to > > > loadshare all the > > > traffic > > > for PS2, between IPSP2 and IPSP3. > > > > > > The above concepts are also illustrated below....(I have purposefully > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > > | | | > > > |<-----ASP Up------------| | > > > |-------ASP Up Ack------>| (Assoc #1) | > > > | | | > > > | | | > > > |<--------------------ASP Up------------------------| > > (Assoc #2) > > > |----------------------------ASP Up Ack------------>| > > > | | | > > > | | | > > > | | | > > > |<--ASP Active(Ldshr)----| | > > > |------ASP Active Ack--->| | > > > | | | > > > | | | > > > | | | > > > |<--------------------ASP Active(Ldshr)-------------| > > > |----------------------------ASP Up Ack------------>| > > > | | | > > > | | | > > > |---NOTIFY(AS-ACTIVE)--->| | > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > | | | > > > > > > > > > > > > Questions: > > > Assuming a single exchange scenario, would the traffic towards > > > PS1 on NodeA, > > > > > > be also loadshared across 2 associations ? > > > > > > I thought it would and hence another follow-up question: > > > It looks like a loadshared peer (NodeB in our case) with > > multiple IPSPs, > > > is putting a constraint on the NodeA, to ALSO be ready to > > receive data on > > > multiple associations and possibly loadshared. Is this a fair > > > understanding > > > ? > > > > > > > > > shashank > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ > 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 Nov 04 14:07:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY6um-0001A3-Po; Fri, 04 Nov 2005 14:07:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY6uk-00019y-KZ for sigtran@megatron.ietf.org; Fri, 04 Nov 2005 14:07:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07795 for ; Fri, 4 Nov 2005 14:07:27 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY79n-0007kQ-4T for sigtran@ietf.org; Fri, 04 Nov 2005 14:23:23 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA4J7ePG028715 for ; Fri, 4 Nov 2005 13:07:41 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 5 Nov 2005 00:37:39 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB685E@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Sat, 5 Nov 2005 00:37:39 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Reply embedded. shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Friday, November 04, 2005 10:09 PM To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Shashank, > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Prasad, Shashank S (Shashank) > Sent: Friday, November 04, 2005 11:07 AM > To: 'Tolga Asveren'; sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Oh OK ! > Looks like, it could potentially happen that NodeB can limit itself to > sending traffic for PS1 on only one of associations also, rather > than both. > However, IPSP1 has really to "listen" at both the associations. > Is that correct ? [TOLGA]Yes. Please also note that it is the M3UA-User which controls this behavior on Node-B, i.e. this is not loadhsaring on M3UA level but one layer above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When they receive a message from their user, they will send it to IPSP1. [SHASHANK] OK, I get ur point related to the role of M3UA User. > > A couple of more questions that now comes up: > 1. In a single ended scenario, how could have IPSP1 (at NodeA) determined > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent from IPSP1 to > IPSP2 and IPSP3 ? (Instead of what is shown my illustration) [TOLGA]Through local configuration, please note Traffic Mode parameter is optional. OTOH, I think that it could be an idea to modify the protocol a bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending side about traffic mode on the peer side in case it is necessary. > [SHASHANK] Yeah, I believe that ASPAC-ACK can be tailored to to inform ASPAC sending side about traffic mode on the peer side in case it is necessary. That will help a great deal in the single exchange scenarios to exchange the Traffic Modes. At present, the M3UA protocol does NOT say anything explicitly on this. Alternatively, the protocol could also define a default Traffic Mode explicitly (possibly Override). And in case the peers do NOT exchange the Traffic mode, the default Traffic Mode (as specified in the specs) can be used. Now that we understand the need, do u think that this could be taken up further ? > 2. In a single exchange scenario, isn't it needed to have the peer ASs > having the same Traffic Mode ? [TOLGA]I believe what you mean as "AS traffic mode" is traffic mode of peer IPSPs in the context of an AS. As far as I can see different traffic modes shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE simultaneously at both sides. > [SHASHANK] I agree with the answer to my second question. > shashank > > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Friday, November 04, 2005 8:51 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > This is implementation/traffic type dependent and is not something > standardized by M3UA. > > > -----Original Message----- > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > Sent: Friday, November 04, 2005 10:28 AM > > To: 'Tolga Asveren'; sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Thanx Tolga. U are right in understanding my question. > > > > Followup Question: > > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > > NodeB, if the traffic to IPSP1 is > > to be sent via IPSP2 or IPSP3 ? > > > > > > shashank > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Friday, November 04, 2005 8:13 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > As far as I understand your question: > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > for this RK > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > mode. You are > > wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3. > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > IPSP1. IPSP2 > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a > > single source is distrubuted to multiple peers. > > > > Tolga > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Friday, November 04, 2005 9:48 AM > > > To: 'sigtran@ietf.org' > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Hi, > > > I had a specific question related to a specific scenario > explained below > > > (Single Exchange scenario) > > > > > > NodeA supports 1 PS with 1 IPSP > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > There are two associations between NodeA and NodeB. > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > on NodeB, > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > that IPSP2 and > > > IPSP3, > > > serving a loadshared PS2, are essentially telling NodeA to > > > loadshare all the > > > traffic > > > for PS2, between IPSP2 and IPSP3. > > > > > > The above concepts are also illustrated below....(I have purposefully > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > > | | | > > > |<-----ASP Up------------| | > > > |-------ASP Up Ack------>| (Assoc #1) | > > > | | | > > > | | | > > > |<--------------------ASP Up------------------------| > > (Assoc #2) > > > |----------------------------ASP Up Ack------------>| > > > | | | > > > | | | > > > | | | > > > |<--ASP Active(Ldshr)----| | > > > |------ASP Active Ack--->| | > > > | | | > > > | | | > > > | | | > > > |<--------------------ASP Active(Ldshr)-------------| > > > |----------------------------ASP Up Ack------------>| > > > | | | > > > | | | > > > |---NOTIFY(AS-ACTIVE)--->| | > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > | | | > > > > > > > > > > > > Questions: > > > Assuming a single exchange scenario, would the traffic towards > > > PS1 on NodeA, > > > > > > be also loadshared across 2 associations ? > > > > > > I thought it would and hence another follow-up question: > > > It looks like a loadshared peer (NodeB in our case) with > > multiple IPSPs, > > > is putting a constraint on the NodeA, to ALSO be ready to > > receive data on > > > multiple associations and possibly loadshared. Is this a fair > > > understanding > > > ? > > > > > > > > > shashank > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Nov 04 15:29:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY8Bv-0005BJ-0T; Fri, 04 Nov 2005 15:29:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY8Bt-00059u-4j for sigtran@megatron.ietf.org; Fri, 04 Nov 2005 15:29:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11360 for ; Fri, 4 Nov 2005 15:29:13 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY8Qw-0001GI-OI for sigtran@ietf.org; Fri, 04 Nov 2005 15:45:11 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA4KTFB7019529 for ; Fri, 4 Nov 2005 15:29:17 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Fri, 4 Nov 2005 15:11:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB685E@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Prasad, Shashank S (Shashank) > Sent: Friday, November 04, 2005 2:08 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Reply embedded. > > shashank > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Friday, November 04, 2005 10:09 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Prasad, Shashank S (Shashank) > > Sent: Friday, November 04, 2005 11:07 AM > > To: 'Tolga Asveren'; sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Oh OK ! > > Looks like, it could potentially happen that NodeB can limit itself to > > sending traffic for PS1 on only one of associations also, rather > > than both. > > However, IPSP1 has really to "listen" at both the associations. > > Is that correct ? > [TOLGA]Yes. Please also note that it is the M3UA-User which controls this > behavior on Node-B, i.e. this is not loadhsaring on M3UA level > but one layer > above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When > they receive a > message from their user, they will send it to IPSP1. > > [SHASHANK] OK, I get ur point related to the role of M3UA User. > > > > > > > > A couple of more questions that now comes up: > > 1. In a single ended scenario, how could have IPSP1 (at NodeA) > determined > > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent > from IPSP1 to > > IPSP2 and IPSP3 ? (Instead of what is shown my illustration) > [TOLGA]Through local configuration, please note Traffic Mode parameter is > optional. OTOH, I think that it could be an idea to modify the protocol a > bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending side > about traffic mode on the peer side in case it is necessary. > > > > [SHASHANK] Yeah, I believe that ASPAC-ACK can be tailored to to > inform ASPAC > sending side > about traffic mode on the peer side in case it is necessary. That > will help > a > great deal in the single exchange scenarios to exchange the Traffic Modes. > At present, the M3UA protocol does NOT say anything explicitly on this. > > Alternatively, the protocol could also define a default Traffic Mode > explicitly (possibly Override). And in case the peers do NOT exchange > the Traffic mode, the default Traffic Mode (as specified in the specs) can > be used. > > Now that we understand the need, do u think that this could be taken up > further ? [TOLGA]I am not sure whether it is a good idea to declare a default traffic mode but allowing both sides to use Traffic Mode parameter makes sense to me. Similar concept could be applied for SGPs as well, i.e. they declare their traffic mode with Traffic Mode in ASPAC-ACK -actually this in practicall life is probably less useful-. Any other opinions about this issue? It looks like a useful feature to me to use Traffic Mode in both directions. > > > > 2. In a single exchange scenario, isn't it needed to have the peer ASs > > having the same Traffic Mode ? > [TOLGA]I believe what you mean as "AS traffic mode" is traffic > mode of peer > IPSPs in the context of an AS. As far as I can see different traffic modes > shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE > simultaneously at both sides. > > > [SHASHANK] I agree with the answer to my second question. > > > shashank > > > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Friday, November 04, 2005 8:51 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > This is implementation/traffic type dependent and is not something > > standardized by M3UA. > > > > > -----Original Message----- > > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > > Sent: Friday, November 04, 2005 10:28 AM > > > To: 'Tolga Asveren'; sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Thanx Tolga. U are right in understanding my question. > > > > > > Followup Question: > > > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > > > NodeB, if the traffic to IPSP1 is > > > to be sent via IPSP2 or IPSP3 ? > > > > > > > > > shashank > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Tolga Asveren > > > Sent: Friday, November 04, 2005 8:13 PM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Shashank, > > > > > > As far as I understand your question: > > > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > > for this RK > > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > > mode. You are > > > wondering whether IPSP1 will receive traffic from both IPSP2 > and IPSP3. > > > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > > IPSP1. IPSP2 > > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because > traffic from a > > > single source is distrubuted to multiple peers. > > > > > > Tolga > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Prasad, Shashank S (Shashank) > > > > Sent: Friday, November 04, 2005 9:48 AM > > > > To: 'sigtran@ietf.org' > > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Hi, > > > > I had a specific question related to a specific scenario > > explained below > > > > (Single Exchange scenario) > > > > > > > > NodeA supports 1 PS with 1 IPSP > > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > > > > There are two associations between NodeA and NodeB. > > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > > on NodeB, > > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > > that IPSP2 and > > > > IPSP3, > > > > serving a loadshared PS2, are essentially telling NodeA to > > > > loadshare all the > > > > traffic > > > > for PS2, between IPSP2 and IPSP3. > > > > > > > > The above concepts are also illustrated below....(I have > purposefully > > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > > > | | | > > > > |<-----ASP Up------------| | > > > > |-------ASP Up Ack------>| (Assoc #1) | > > > > | | | > > > > | | | > > > > |<--------------------ASP Up------------------------| > > > (Assoc #2) > > > > |----------------------------ASP Up Ack------------>| > > > > | | | > > > > | | | > > > > | | | > > > > |<--ASP Active(Ldshr)----| | > > > > |------ASP Active Ack--->| | > > > > | | | > > > > | | | > > > > | | | > > > > |<--------------------ASP Active(Ldshr)-------------| > > > > |----------------------------ASP Up Ack------------>| > > > > | | | > > > > | | | > > > > |---NOTIFY(AS-ACTIVE)--->| | > > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > > | | | > > > > > > > > > > > > > > > > Questions: > > > > Assuming a single exchange scenario, would the traffic towards > > > > PS1 on NodeA, > > > > > > > > be also loadshared across 2 associations ? > > > > > > > > I thought it would and hence another follow-up question: > > > > It looks like a loadshared peer (NodeB in our case) with > > > multiple IPSPs, > > > > is putting a constraint on the NodeA, to ALSO be ready to > > > receive data on > > > > multiple associations and possibly loadshared. Is this a fair > > > > understanding > > > > ? > > > > > > > > > > > > shashank > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Sat Nov 05 01:54:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYHwS-0000yr-CD; Sat, 05 Nov 2005 01:54:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYHwQ-0000ym-Ci for sigtran@megatron.ietf.org; Sat, 05 Nov 2005 01:54:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14133 for ; Sat, 5 Nov 2005 01:53:55 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYIBX-0000o9-He for sigtran@ietf.org; Sat, 05 Nov 2005 02:09:58 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA56s7Bs023147 for ; Sat, 5 Nov 2005 00:54:08 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 5 Nov 2005 12:24:06 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB6860@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Sat, 5 Nov 2005 12:24:04 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, I agree with ur point. In a Single Ended exchange, the Traffic Mode in the ASPAC-Ack could be interpreted as the Traffic Mode of the Node sending ASPAC-Ack. This would help the peers to "know" the Traffic Mode of each other. Some more important points: The ASPAC message can have multiple (n) Routing Contexts. And therefore the Traffic Mode sent in the ASP-Ack must also have the Traffic Mode per Routing Context. Hence the ASPAC-Ack should have Traffic Mode per Routing Context. Would u agree ? However, there is still a catch. The Traffic Mode is an Optional parameter in ASPAC and ASPAC-Ack messages. At present, M3UA has left to the implementators on how to interpret Traffic Modes of each other, in case, the peers do NOT exchange Traffic Modes. I was therefore suggesting that we could have M3UA suggest a default implementation of Traffic Mode, and rather NOT leave to the implementation. And I suggested Override, because, I would always believe that whenever a node gets the last ASPAC or ASPAC-Ack (intrododuced in the course of our discussion), without any Traffic Mode (since it is Optional), it shall interpret that the peer intends to use this ASP for its communication. At the same time, we ALSO have ur suggestion about IPSPs sending their respective Traffic modes in ASPAC-Ack messages. shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Saturday, November 05, 2005 1:42 AM To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Shashank, > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Prasad, Shashank S (Shashank) > Sent: Friday, November 04, 2005 2:08 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Reply embedded. > > shashank > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Friday, November 04, 2005 10:09 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Prasad, Shashank S (Shashank) > > Sent: Friday, November 04, 2005 11:07 AM > > To: 'Tolga Asveren'; sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Oh OK ! > > Looks like, it could potentially happen that NodeB can limit itself to > > sending traffic for PS1 on only one of associations also, rather > > than both. > > However, IPSP1 has really to "listen" at both the associations. > > Is that correct ? > [TOLGA]Yes. Please also note that it is the M3UA-User which controls this > behavior on Node-B, i.e. this is not loadhsaring on M3UA level > but one layer > above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When > they receive a > message from their user, they will send it to IPSP1. > > [SHASHANK] OK, I get ur point related to the role of M3UA User. > > > > > > > > A couple of more questions that now comes up: > > 1. In a single ended scenario, how could have IPSP1 (at NodeA) > determined > > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent > from IPSP1 to > > IPSP2 and IPSP3 ? (Instead of what is shown my illustration) > [TOLGA]Through local configuration, please note Traffic Mode parameter is > optional. OTOH, I think that it could be an idea to modify the protocol a > bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending side > about traffic mode on the peer side in case it is necessary. > > > > [SHASHANK] Yeah, I believe that ASPAC-ACK can be tailored to to > inform ASPAC > sending side > about traffic mode on the peer side in case it is necessary. That > will help > a > great deal in the single exchange scenarios to exchange the Traffic Modes. > At present, the M3UA protocol does NOT say anything explicitly on this. > > Alternatively, the protocol could also define a default Traffic Mode > explicitly (possibly Override). And in case the peers do NOT exchange > the Traffic mode, the default Traffic Mode (as specified in the specs) can > be used. > > Now that we understand the need, do u think that this could be taken up > further ? [TOLGA]I am not sure whether it is a good idea to declare a default traffic mode but allowing both sides to use Traffic Mode parameter makes sense to me. Similar concept could be applied for SGPs as well, i.e. they declare their traffic mode with Traffic Mode in ASPAC-ACK -actually this in practicall life is probably less useful-. Any other opinions about this issue? It looks like a useful feature to me to use Traffic Mode in both directions. > > > > 2. In a single exchange scenario, isn't it needed to have the peer ASs > > having the same Traffic Mode ? > [TOLGA]I believe what you mean as "AS traffic mode" is traffic > mode of peer > IPSPs in the context of an AS. As far as I can see different traffic modes > shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE > simultaneously at both sides. > > > [SHASHANK] I agree with the answer to my second question. > > > shashank > > > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Friday, November 04, 2005 8:51 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > This is implementation/traffic type dependent and is not something > > standardized by M3UA. > > > > > -----Original Message----- > > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > > Sent: Friday, November 04, 2005 10:28 AM > > > To: 'Tolga Asveren'; sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Thanx Tolga. U are right in understanding my question. > > > > > > Followup Question: > > > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > > > NodeB, if the traffic to IPSP1 is > > > to be sent via IPSP2 or IPSP3 ? > > > > > > > > > shashank > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Tolga Asveren > > > Sent: Friday, November 04, 2005 8:13 PM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Shashank, > > > > > > As far as I understand your question: > > > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > > for this RK > > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > > mode. You are > > > wondering whether IPSP1 will receive traffic from both IPSP2 > and IPSP3. > > > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > > IPSP1. IPSP2 > > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because > traffic from a > > > single source is distrubuted to multiple peers. > > > > > > Tolga > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Prasad, Shashank S (Shashank) > > > > Sent: Friday, November 04, 2005 9:48 AM > > > > To: 'sigtran@ietf.org' > > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Hi, > > > > I had a specific question related to a specific scenario > > explained below > > > > (Single Exchange scenario) > > > > > > > > NodeA supports 1 PS with 1 IPSP > > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > > > > There are two associations between NodeA and NodeB. > > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > > on NodeB, > > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > > that IPSP2 and > > > > IPSP3, > > > > serving a loadshared PS2, are essentially telling NodeA to > > > > loadshare all the > > > > traffic > > > > for PS2, between IPSP2 and IPSP3. > > > > > > > > The above concepts are also illustrated below....(I have > purposefully > > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > > > | | | > > > > |<-----ASP Up------------| | > > > > |-------ASP Up Ack------>| (Assoc #1) | > > > > | | | > > > > | | | > > > > |<--------------------ASP Up------------------------| > > > (Assoc #2) > > > > |----------------------------ASP Up Ack------------>| > > > > | | | > > > > | | | > > > > | | | > > > > |<--ASP Active(Ldshr)----| | > > > > |------ASP Active Ack--->| | > > > > | | | > > > > | | | > > > > | | | > > > > |<--------------------ASP Active(Ldshr)-------------| > > > > |----------------------------ASP Up Ack------------>| > > > > | | | > > > > | | | > > > > |---NOTIFY(AS-ACTIVE)--->| | > > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > > | | | > > > > > > > > > > > > > > > > Questions: > > > > Assuming a single exchange scenario, would the traffic towards > > > > PS1 on NodeA, > > > > > > > > be also loadshared across 2 associations ? > > > > > > > > I thought it would and hence another follow-up question: > > > > It looks like a loadshared peer (NodeB in our case) with > > > multiple IPSPs, > > > > is putting a constraint on the NodeA, to ALSO be ready to > > > receive data on > > > > multiple associations and possibly loadshared. Is this a fair > > > > understanding > > > > ? > > > > > > > > > > > > shashank > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ 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 Sat Nov 05 03:41:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYJc5-0001Rc-LY; Sat, 05 Nov 2005 03:41:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYJc4-0001RX-4S for sigtran@megatron.ietf.org; Sat, 05 Nov 2005 03:41:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18097 for ; Sat, 5 Nov 2005 03:41:00 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[mzMosYWeARtXbL3TW+qEgfB1agBlynaF]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYJrD-0003B6-FY for sigtran@ietf.org; Sat, 05 Nov 2005 03:57:04 -0500 Received: from ns.pigworks.openss7.net (IDENT:5ws3EnFCDu/O8TPbyKpq7KgkWt0yDuo+@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA58fAc11230; Sat, 5 Nov 2005 01:41:10 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA58f9G22772; Sat, 5 Nov 2005 01:41:09 -0700 Date: Sat, 5 Nov 2005 01:41:09 -0700 From: "Brian F. G. Bidulock" To: "Prasad, Shashank S (Shashank)" Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Message-ID: <20051105014109.A22541@openss7.org> Mail-Followup-To: "Prasad, Shashank S (Shashank)" , sigtran@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D210FB6860@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB6860@ii0015exch002u.iprc.lucent.com>; from ssprasad@lucent.com on Sat, Nov 05, 2005 at 12:24:04PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, RFC 3332 says: (Section 4.3.4.3 second paragraph) For the Application Servers that the ASP can be successfully activated, the SGP or IPSP responds with one or more ASP Active Ack messages, including the associated Routing Context(s) and reflecting any Traffic Mode Type value present in the related ASP Active message. The Routing Context parameter MUST be included in the ASP Active Ack message(s) if the received ASP Active message contained any Routing Contexts. Depending on any Traffic Mode Type request in the ASP Active message, or local configuration data if there is no request, the SGP moves the ASP to the correct ASP traffic state within the associated Application Server(s). Layer Management is informed with an M-ASP_Active indication. If the SGP or IPSP receives any Data messages before an ASP Active message is received, the SGP or IPSP MAY discard them. By sending an ASP Active Ack message, the SGP or IPSP is now ready to receive and send traffic for the related Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages for the related Routing Context(s) before receiving an ASP Active Ack message, or it will risk message loss. I think that this is quite clear with regard to two things: The IPSP receiving the ASP Active message responds with regard to Traffic Mode in the same fashion as an SGP would. Traffic Mode included in the ASP Active Ack is simply the value from the ASP Active message reflected back at the activating ASP. SGPs do not have traffic modes. Also, they do not have activation or up/down states either. See RFC 3332 Section 1.4.2.5: 1.4.2.5 Message Distribution at the ASP The ASP must choose an SGP to direct a message to the SS7 network. This is accomplished by observing the Destination Point Code (and possibly other elements of the outgoing message such as the SLS value). The ASP must also take into account whether the related Routing Context is active or not (See Section 4.3.4.3). Implementation Note: Where more than one route (or SGP) is possible for routing to the SS7 network, the ASP could, for example, maintain a dynamic table of available SGP routes for the SS7 destinations, taking into account the SS7 destination availability/restricted/congestion status received from the SGP(s), the availability status of the individual SGPs and configuration changes and failover mechanisms. There is, however, no M3UA messaging to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging). Whenever an SCTP association to an SGP exists, the SGP is assumed to be ready for the purposes of responding to M3UA ASPSM messages (Refer to Section 3). See also RFC 3332 Appendix A.2.2: A.2.2 Signalling Gateway Redundancy Signalling Gateways may also be distributed over multiple hosts. Much like the AS model, SGs may comprise one or more SG Processes (SGPs), distributed over one or more hosts, using an active/backup or a loadsharing model. Should an SGP lose all or partial SS7 connectivity and other SGPs exist, the SGP may terminate the SCTP associations to the concerned ASPs. It is therefore possible for an ASP to route signalling messages destined to the SS7 network using more than one SGP. In this model, a Signalling Gateway is deployed as a cluster of hosts acting as a single SG. A primary/backup redundancy model is possible, where the unavailability of the SCTP association to a primary SGP could be used to reroute affected traffic to an alternate SGP. A loadsharing model is possible, where the signalling messages are loadshared between multiple SGPs. A broadcast model is also possible, where signalling messages are sent to each active SGP in the SG. The distribution of the MTP3-user messages over the SGPs should be done in such a way to minimize message missequencing, as required by the SS7 User Parts. It may also be possible for an ASP to use more than one SG to access a specific SS7 end point, in a model that resembles an SS7 STP mated pair. Typically, SS7 STPs are deployed in mated pairs, with traffic loadshared between them. Other models are also possible, subject to the limitations of the local SS7 network provisioning guidelines. From the perspective of the M3UA layer at an ASP, a particular SG is capable of transferring traffic to a provisioned SS7 destination X if an SCTP association with at least one SGP of the SG is established, the SGP has returned an acknowledgement to the ASP to indicate that the ASP is actively handling traffic for that destination X, the SGP has not indicated that the destination X is inaccessible and the SGP has not indicated MTP Restart. When an ASP is configured to use multiple SGPs for transferring traffic to the SS7 network, the ASP must maintain knowledge of the current capability of the SGPs to handle traffic to destinations of interest. This information is crucial to the overall reliability of the service, for active/backup, loadsharing and broadcast models, in the event of failures, recovery and maintenance activities. The ASP M3UA may also use this information for congestion avoidance purposes. The distribution of the MTP3-user messages over the SGPs should be done in such a way to minimize message missequencing, as required by the SS7 User Parts. I think these passages are quite clear. --brian Prasad, Shashank S (Shashank) wrote: (Sat, 05 Nov 2005 12:24:04) > Tolga, > I agree with ur point. In a Single Ended exchange, the Traffic Mode in the > ASPAC-Ack could be interpreted as the Traffic Mode of the Node sending > ASPAC-Ack. This would help the peers to "know" the Traffic Mode of each > other. > > Some more important points: > The ASPAC message can have multiple (n) Routing Contexts. > And therefore the Traffic Mode sent in the ASP-Ack must also have the > Traffic Mode per Routing Context. > > Hence the ASPAC-Ack should have Traffic Mode per Routing Context. Would u > agree ? > > > > However, there is still a catch. > The Traffic Mode is an Optional parameter in ASPAC and ASPAC-Ack messages. > At present, M3UA has left to the implementators on how to interpret Traffic > Modes of each other, in case, the peers do NOT exchange Traffic Modes. > > I was therefore suggesting that we could have M3UA suggest a default > implementation of Traffic Mode, and rather NOT leave to the implementation. > And I suggested Override, because, I would always believe that whenever a > node gets the last ASPAC or ASPAC-Ack (intrododuced in the course of our > discussion), without any Traffic Mode (since it is Optional), it shall > interpret that the peer intends to use this ASP for its communication. > > > At the same time, we ALSO have ur suggestion about IPSPs sending their > respective Traffic modes in ASPAC-Ack messages. > > > shashank > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Saturday, November 05, 2005 1:42 AM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Prasad, Shashank S (Shashank) > > Sent: Friday, November 04, 2005 2:08 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Reply embedded. > > > > shashank > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Friday, November 04, 2005 10:09 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Friday, November 04, 2005 11:07 AM > > > To: 'Tolga Asveren'; sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Oh OK ! > > > Looks like, it could potentially happen that NodeB can limit itself to > > > sending traffic for PS1 on only one of associations also, rather > > > than both. > > > However, IPSP1 has really to "listen" at both the associations. > > > Is that correct ? > > [TOLGA]Yes. Please also note that it is the M3UA-User which controls this > > behavior on Node-B, i.e. this is not loadhsaring on M3UA level > > but one layer > > above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When > > they receive a > > message from their user, they will send it to IPSP1. > > > > [SHASHANK] OK, I get ur point related to the role of M3UA User. > > > > > > > > > > > > > > A couple of more questions that now comes up: > > > 1. In a single ended scenario, how could have IPSP1 (at NodeA) > > determined > > > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent > > from IPSP1 to > > > IPSP2 and IPSP3 ? (Instead of what is shown my illustration) > > [TOLGA]Through local configuration, please note Traffic Mode parameter is > > optional. OTOH, I think that it could be an idea to modify the protocol a > > bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending side > > about traffic mode on the peer side in case it is necessary. > > > > > > > [SHASHANK] Yeah, I believe that ASPAC-ACK can be tailored to to > > inform ASPAC > > sending side > > about traffic mode on the peer side in case it is necessary. That > > will help > > a > > great deal in the single exchange scenarios to exchange the Traffic Modes. > > At present, the M3UA protocol does NOT say anything explicitly on this. > > > > Alternatively, the protocol could also define a default Traffic Mode > > explicitly (possibly Override). And in case the peers do NOT exchange > > the Traffic mode, the default Traffic Mode (as specified in the specs) can > > be used. > > > > Now that we understand the need, do u think that this could be taken up > > further ? > [TOLGA]I am not sure whether it is a good idea to declare a default traffic > mode but allowing both sides to use Traffic Mode parameter makes sense to > me. Similar concept could be applied for SGPs as well, i.e. they declare > their traffic mode with Traffic Mode in ASPAC-ACK -actually this in > practicall life is probably less useful-. Any other opinions about this > issue? It looks like a useful feature to me to use Traffic Mode in both > directions. > > > > > > > 2. In a single exchange scenario, isn't it needed to have the peer ASs > > > having the same Traffic Mode ? > > [TOLGA]I believe what you mean as "AS traffic mode" is traffic > > mode of peer > > IPSPs in the context of an AS. As far as I can see different traffic modes > > shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE > > simultaneously at both sides. > > > > > [SHASHANK] I agree with the answer to my second question. > > > > > shashank > > > > > > > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Tolga Asveren > > > Sent: Friday, November 04, 2005 8:51 PM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > This is implementation/traffic type dependent and is not something > > > standardized by M3UA. > > > > > > > -----Original Message----- > > > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > > > Sent: Friday, November 04, 2005 10:28 AM > > > > To: 'Tolga Asveren'; sigtran@ietf.org > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Thanx Tolga. U are right in understanding my question. > > > > > > > > Followup Question: > > > > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > > > > NodeB, if the traffic to IPSP1 is > > > > to be sent via IPSP2 or IPSP3 ? > > > > > > > > > > > > shashank > > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Tolga Asveren > > > > Sent: Friday, November 04, 2005 8:13 PM > > > > To: sigtran@ietf.org > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Shashank, > > > > > > > > As far as I understand your question: > > > > > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > > > for this RK > > > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > > > mode. You are > > > > wondering whether IPSP1 will receive traffic from both IPSP2 > > and IPSP3. > > > > > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > > > IPSP1. IPSP2 > > > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because > > traffic from a > > > > single source is distrubuted to multiple peers. > > > > > > > > Tolga > > > > > > > > > -----Original Message----- > > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > > Behalf Of Prasad, Shashank S (Shashank) > > > > > Sent: Friday, November 04, 2005 9:48 AM > > > > > To: 'sigtran@ietf.org' > > > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Hi, > > > > > I had a specific question related to a specific scenario > > > explained below > > > > > (Single Exchange scenario) > > > > > > > > > > NodeA supports 1 PS with 1 IPSP > > > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > > > > > > > There are two associations between NodeA and NodeB. > > > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > > > on NodeB, > > > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > > > that IPSP2 and > > > > > IPSP3, > > > > > serving a loadshared PS2, are essentially telling NodeA to > > > > > loadshare all the > > > > > traffic > > > > > for PS2, between IPSP2 and IPSP3. > > > > > > > > > > The above concepts are also illustrated below....(I have > > purposefully > > > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > > > > | | | > > > > > |<-----ASP Up------------| | > > > > > |-------ASP Up Ack------>| (Assoc #1) | > > > > > | | | > > > > > | | | > > > > > |<--------------------ASP Up------------------------| > > > > (Assoc #2) > > > > > |----------------------------ASP Up Ack------------>| > > > > > | | | > > > > > | | | > > > > > | | | > > > > > |<--ASP Active(Ldshr)----| | > > > > > |------ASP Active Ack--->| | > > > > > | | | > > > > > | | | > > > > > | | | > > > > > |<--------------------ASP Active(Ldshr)-------------| > > > > > |----------------------------ASP Up Ack------------>| > > > > > | | | > > > > > | | | > > > > > |---NOTIFY(AS-ACTIVE)--->| | > > > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > > > | | | > > > > > > > > > > > > > > > > > > > > Questions: > > > > > Assuming a single exchange scenario, would the traffic towards > > > > > PS1 on NodeA, > > > > > > > > > > be also loadshared across 2 associations ? > > > > > > > > > > I thought it would and hence another follow-up question: > > > > > It looks like a loadshared peer (NodeB in our case) with > > > > multiple IPSPs, > > > > > is putting a constraint on the NodeA, to ALSO be ready to > > > > receive data on > > > > > multiple associations and possibly loadshared. Is this a fair > > > > > understanding > > > > > ? > > > > > > > > > > > > > > > shashank > > > > > > > > > > _______________________________________________ > > > > > Sigtran mailing list > > > > > Sigtran@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > 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 -- 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 Nov 06 11:56:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYnoV-0004Ax-IS; Sun, 06 Nov 2005 11:56:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYnoO-0004Ab-Hm for sigtran@megatron.ietf.org; Sun, 06 Nov 2005 11:56:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07585 for ; Sun, 6 Nov 2005 11:55:43 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYo3p-0007BN-99 for sigtran@ietf.org; Sun, 06 Nov 2005 12:12:05 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA6GtwMX018648; Sun, 6 Nov 2005 10:55:59 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 6 Nov 2005 22:25:57 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D21BBCD968@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Sun, 6 Nov 2005 22:25:56 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f Cc: bidulock@openss7.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Thanx Brian for ur inputs. However, I re-read the sections that u mentioned but I still did NOT get the answer that I was seeking. I will try to give an example to better explain. Possibly, ur answers to the questions (below) could be of good help. -----------------------|----------------------------------------------- AS1 | AS2(Loadshared), AS3(Override) -----------------------|----------------------------------------------- IPSP1 | IPSP2 IPSP3 (AS1) | (AS2,AS3) (AS2) -----------------------|----------------------------------------------- | IPSP1 serves AS1. IPSP2 serves AS2 and AS3. IPSP3 serves AS2. 1. In a Single Ended scenario, if the IPSP1 sends ASPAC message to the IPSP2 and IPSP3, how would IPSP1 know that IPSP2 and IPSP3 are loadshared for AS2 ? I did NOT see how this would happen, and therefore, we (Tolga and I) were discussing that IPSP2 and IPSP3 send their respective Traffic Modes for the various AS they are serving. Which means that ASPAC-Ack from IPSP2 must send Routing Key of AS2 and AS3 with the Traffic Mode of AS2 and AS3. 2. If the IPSP2 sends ASPAC message to IPSP1, with multiple Routing Keys in the same ASPAC, it should also send Traffic mode for different Routing Keys too (AS2 and AS2). Thanx. shashank -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Saturday, November 05, 2005 2:11 PM To: Prasad, Shashank S (Shashank) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Shashank, RFC 3332 says: (Section 4.3.4.3 second paragraph) For the Application Servers that the ASP can be successfully activated, the SGP or IPSP responds with one or more ASP Active Ack messages, including the associated Routing Context(s) and reflecting any Traffic Mode Type value present in the related ASP Active message. The Routing Context parameter MUST be included in the ASP Active Ack message(s) if the received ASP Active message contained any Routing Contexts. Depending on any Traffic Mode Type request in the ASP Active message, or local configuration data if there is no request, the SGP moves the ASP to the correct ASP traffic state within the associated Application Server(s). Layer Management is informed with an M-ASP_Active indication. If the SGP or IPSP receives any Data messages before an ASP Active message is received, the SGP or IPSP MAY discard them. By sending an ASP Active Ack message, the SGP or IPSP is now ready to receive and send traffic for the related Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages for the related Routing Context(s) before receiving an ASP Active Ack message, or it will risk message loss. I think that this is quite clear with regard to two things: The IPSP receiving the ASP Active message responds with regard to Traffic Mode in the same fashion as an SGP would. Traffic Mode included in the ASP Active Ack is simply the value from the ASP Active message reflected back at the activating ASP. SGPs do not have traffic modes. Also, they do not have activation or up/down states either. See RFC 3332 Section 1.4.2.5: 1.4.2.5 Message Distribution at the ASP The ASP must choose an SGP to direct a message to the SS7 network. This is accomplished by observing the Destination Point Code (and possibly other elements of the outgoing message such as the SLS value). The ASP must also take into account whether the related Routing Context is active or not (See Section 4.3.4.3). Implementation Note: Where more than one route (or SGP) is possible for routing to the SS7 network, the ASP could, for example, maintain a dynamic table of available SGP routes for the SS7 destinations, taking into account the SS7 destination availability/restricted/congestion status received from the SGP(s), the availability status of the individual SGPs and configuration changes and failover mechanisms. There is, however, no M3UA messaging to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging). Whenever an SCTP association to an SGP exists, the SGP is assumed to be ready for the purposes of responding to M3UA ASPSM messages (Refer to Section 3). See also RFC 3332 Appendix A.2.2: A.2.2 Signalling Gateway Redundancy Signalling Gateways may also be distributed over multiple hosts. Much like the AS model, SGs may comprise one or more SG Processes (SGPs), distributed over one or more hosts, using an active/backup or a loadsharing model. Should an SGP lose all or partial SS7 connectivity and other SGPs exist, the SGP may terminate the SCTP associations to the concerned ASPs. It is therefore possible for an ASP to route signalling messages destined to the SS7 network using more than one SGP. In this model, a Signalling Gateway is deployed as a cluster of hosts acting as a single SG. A primary/backup redundancy model is possible, where the unavailability of the SCTP association to a primary SGP could be used to reroute affected traffic to an alternate SGP. A loadsharing model is possible, where the signalling messages are loadshared between multiple SGPs. A broadcast model is also possible, where signalling messages are sent to each active SGP in the SG. The distribution of the MTP3-user messages over the SGPs should be done in such a way to minimize message missequencing, as required by the SS7 User Parts. It may also be possible for an ASP to use more than one SG to access a specific SS7 end point, in a model that resembles an SS7 STP mated pair. Typically, SS7 STPs are deployed in mated pairs, with traffic loadshared between them. Other models are also possible, subject to the limitations of the local SS7 network provisioning guidelines. From the perspective of the M3UA layer at an ASP, a particular SG is capable of transferring traffic to a provisioned SS7 destination X if an SCTP association with at least one SGP of the SG is established, the SGP has returned an acknowledgement to the ASP to indicate that the ASP is actively handling traffic for that destination X, the SGP has not indicated that the destination X is inaccessible and the SGP has not indicated MTP Restart. When an ASP is configured to use multiple SGPs for transferring traffic to the SS7 network, the ASP must maintain knowledge of the current capability of the SGPs to handle traffic to destinations of interest. This information is crucial to the overall reliability of the service, for active/backup, loadsharing and broadcast models, in the event of failures, recovery and maintenance activities. The ASP M3UA may also use this information for congestion avoidance purposes. The distribution of the MTP3-user messages over the SGPs should be done in such a way to minimize message missequencing, as required by the SS7 User Parts. I think these passages are quite clear. --brian Prasad, Shashank S (Shashank) wrote: (Sat, 05 Nov 2005 12:24:04) > Tolga, > I agree with ur point. In a Single Ended exchange, the Traffic Mode in the > ASPAC-Ack could be interpreted as the Traffic Mode of the Node sending > ASPAC-Ack. This would help the peers to "know" the Traffic Mode of each > other. > > Some more important points: > The ASPAC message can have multiple (n) Routing Contexts. > And therefore the Traffic Mode sent in the ASP-Ack must also have the > Traffic Mode per Routing Context. > > Hence the ASPAC-Ack should have Traffic Mode per Routing Context. Would u > agree ? > > > > However, there is still a catch. > The Traffic Mode is an Optional parameter in ASPAC and ASPAC-Ack messages. > At present, M3UA has left to the implementators on how to interpret Traffic > Modes of each other, in case, the peers do NOT exchange Traffic Modes. > > I was therefore suggesting that we could have M3UA suggest a default > implementation of Traffic Mode, and rather NOT leave to the implementation. > And I suggested Override, because, I would always believe that whenever a > node gets the last ASPAC or ASPAC-Ack (intrododuced in the course of our > discussion), without any Traffic Mode (since it is Optional), it shall > interpret that the peer intends to use this ASP for its communication. > > > At the same time, we ALSO have ur suggestion about IPSPs sending their > respective Traffic modes in ASPAC-Ack messages. > > > shashank > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Saturday, November 05, 2005 1:42 AM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Prasad, Shashank S (Shashank) > > Sent: Friday, November 04, 2005 2:08 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Reply embedded. > > > > shashank > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Friday, November 04, 2005 10:09 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Friday, November 04, 2005 11:07 AM > > > To: 'Tolga Asveren'; sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Oh OK ! > > > Looks like, it could potentially happen that NodeB can limit itself to > > > sending traffic for PS1 on only one of associations also, rather > > > than both. > > > However, IPSP1 has really to "listen" at both the associations. > > > Is that correct ? > > [TOLGA]Yes. Please also note that it is the M3UA-User which controls this > > behavior on Node-B, i.e. this is not loadhsaring on M3UA level > > but one layer > > above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When > > they receive a > > message from their user, they will send it to IPSP1. > > > > [SHASHANK] OK, I get ur point related to the role of M3UA User. > > > > > > > > > > > > > > A couple of more questions that now comes up: > > > 1. In a single ended scenario, how could have IPSP1 (at NodeA) > > determined > > > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent > > from IPSP1 to > > > IPSP2 and IPSP3 ? (Instead of what is shown my illustration) > > [TOLGA]Through local configuration, please note Traffic Mode parameter is > > optional. OTOH, I think that it could be an idea to modify the protocol a > > bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending side > > about traffic mode on the peer side in case it is necessary. > > > > > > > [SHASHANK] Yeah, I believe that ASPAC-ACK can be tailored to to > > inform ASPAC > > sending side > > about traffic mode on the peer side in case it is necessary. That > > will help > > a > > great deal in the single exchange scenarios to exchange the Traffic Modes. > > At present, the M3UA protocol does NOT say anything explicitly on this. > > > > Alternatively, the protocol could also define a default Traffic Mode > > explicitly (possibly Override). And in case the peers do NOT exchange > > the Traffic mode, the default Traffic Mode (as specified in the specs) can > > be used. > > > > Now that we understand the need, do u think that this could be taken up > > further ? > [TOLGA]I am not sure whether it is a good idea to declare a default traffic > mode but allowing both sides to use Traffic Mode parameter makes sense to > me. Similar concept could be applied for SGPs as well, i.e. they declare > their traffic mode with Traffic Mode in ASPAC-ACK -actually this in > practicall life is probably less useful-. Any other opinions about this > issue? It looks like a useful feature to me to use Traffic Mode in both > directions. > > > > > > > 2. In a single exchange scenario, isn't it needed to have the peer ASs > > > having the same Traffic Mode ? > > [TOLGA]I believe what you mean as "AS traffic mode" is traffic > > mode of peer > > IPSPs in the context of an AS. As far as I can see different traffic modes > > shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE > > simultaneously at both sides. > > > > > [SHASHANK] I agree with the answer to my second question. > > > > > shashank > > > > > > > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Tolga Asveren > > > Sent: Friday, November 04, 2005 8:51 PM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > This is implementation/traffic type dependent and is not something > > > standardized by M3UA. > > > > > > > -----Original Message----- > > > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > > > Sent: Friday, November 04, 2005 10:28 AM > > > > To: 'Tolga Asveren'; sigtran@ietf.org > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Thanx Tolga. U are right in understanding my question. > > > > > > > > Followup Question: > > > > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > > > > NodeB, if the traffic to IPSP1 is > > > > to be sent via IPSP2 or IPSP3 ? > > > > > > > > > > > > shashank > > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Tolga Asveren > > > > Sent: Friday, November 04, 2005 8:13 PM > > > > To: sigtran@ietf.org > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Shashank, > > > > > > > > As far as I understand your question: > > > > > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > > > for this RK > > > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > > > mode. You are > > > > wondering whether IPSP1 will receive traffic from both IPSP2 > > and IPSP3. > > > > > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > > > IPSP1. IPSP2 > > > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because > > traffic from a > > > > single source is distrubuted to multiple peers. > > > > > > > > Tolga > > > > > > > > > -----Original Message----- > > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > > Behalf Of Prasad, Shashank S (Shashank) > > > > > Sent: Friday, November 04, 2005 9:48 AM > > > > > To: 'sigtran@ietf.org' > > > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Hi, > > > > > I had a specific question related to a specific scenario > > > explained below > > > > > (Single Exchange scenario) > > > > > > > > > > NodeA supports 1 PS with 1 IPSP > > > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > > > > > > > There are two associations between NodeA and NodeB. > > > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > > > on NodeB, > > > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > > > that IPSP2 and > > > > > IPSP3, > > > > > serving a loadshared PS2, are essentially telling NodeA to > > > > > loadshare all the > > > > > traffic > > > > > for PS2, between IPSP2 and IPSP3. > > > > > > > > > > The above concepts are also illustrated below....(I have > > purposefully > > > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > > > > | | | > > > > > |<-----ASP Up------------| | > > > > > |-------ASP Up Ack------>| (Assoc #1) | > > > > > | | | > > > > > | | | > > > > > |<--------------------ASP Up------------------------| > > > > (Assoc #2) > > > > > |----------------------------ASP Up Ack------------>| > > > > > | | | > > > > > | | | > > > > > | | | > > > > > |<--ASP Active(Ldshr)----| | > > > > > |------ASP Active Ack--->| | > > > > > | | | > > > > > | | | > > > > > | | | > > > > > |<--------------------ASP Active(Ldshr)-------------| > > > > > |----------------------------ASP Up Ack------------>| > > > > > | | | > > > > > | | | > > > > > |---NOTIFY(AS-ACTIVE)--->| | > > > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > > > | | | > > > > > > > > > > > > > > > > > > > > Questions: > > > > > Assuming a single exchange scenario, would the traffic towards > > > > > PS1 on NodeA, > > > > > > > > > > be also loadshared across 2 associations ? > > > > > > > > > > I thought it would and hence another follow-up question: > > > > > It looks like a loadshared peer (NodeB in our case) with > > > > multiple IPSPs, > > > > > is putting a constraint on the NodeA, to ALSO be ready to > > > > receive data on > > > > > multiple associations and possibly loadshared. Is this a fair > > > > > understanding > > > > > ? > > > > > > > > > > > > > > > shashank > > > > > > > > > > _______________________________________________ > > > > > Sigtran mailing list > > > > > Sigtran@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > 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 -- 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 Nov 06 14:41:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYqOL-0001gi-Hj; Sun, 06 Nov 2005 14:41:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYqOK-0001gd-FC for sigtran@megatron.ietf.org; Sun, 06 Nov 2005 14:41:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16613 for ; Sun, 6 Nov 2005 14:40:58 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[7tkj1M5c48z3ROROxsYuRN3V0JqxrLYL]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYqay-0002st-9Q for sigtran@ietf.org; Sun, 06 Nov 2005 14:57:23 -0500 Received: from ns.pigworks.openss7.net (IDENT:WDLKNnivbQPc65uJX4o63cjwv9eGBjCV@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA6Jc1c13252; Sun, 6 Nov 2005 12:38:01 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA6JbwR05797; Sun, 6 Nov 2005 12:37:58 -0700 Date: Sun, 6 Nov 2005 12:37:58 -0700 From: "Brian F. G. Bidulock" To: "Prasad, Shashank S (Shashank)" Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Message-ID: <20051106123758.A5718@openss7.org> Mail-Followup-To: "Prasad, Shashank S (Shashank)" , sigtran@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D21BBCD968@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D21BBCD968@ii0015exch002u.iprc.lucent.com>; from ssprasad@lucent.com on Sun, Nov 06, 2005 at 10:25:56PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b157e6e8a3799aef911c0bc37fc93a6 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Prasad,, Prasad, Shashank S (Shashank) wrote: (Sun, 06 Nov 2005 22:25:56) > Thanx Brian for ur inputs. > However, I re-read the sections that u mentioned but I still did NOT get the > answer that I was seeking. > > I will try to give an example to better explain. > Possibly, ur answers to the questions (below) could be of good help. > > > -----------------------|----------------------------------------------- > AS1 | AS2(Loadshared), AS3(Override) > -----------------------|----------------------------------------------- > IPSP1 | IPSP2 IPSP3 > (AS1) | (AS2,AS3) (AS2) > -----------------------|----------------------------------------------- > | > > IPSP1 serves AS1. > IPSP2 serves AS2 and AS3. > IPSP3 serves AS2. > > > > 1. In a Single Ended scenario, if the IPSP1 sends ASPAC message to the IPSP2 > and IPSP3, how would IPSP1 know that IPSP2 and IPSP3 are loadshared for AS2 > ? In SE, one IPSP acts as ASP, the other as SGP. If you want a loadshared AS at IPSP2 it will have to send the ASPAC. IPSPs receiving ASPAC act as an SGP (as stated in the passages). For distribution of messages over SGP, see 1.4.2.5 and A.2.2. --brian > > I did NOT see how this would happen, and therefore, we (Tolga and I) were > discussing that IPSP2 and IPSP3 send their respective Traffic Modes for the > various AS they are serving. Which means that ASPAC-Ack from IPSP2 must send > Routing Key of AS2 and AS3 with the Traffic Mode of AS2 and AS3. > > > 2. If the IPSP2 sends ASPAC message to IPSP1, with multiple Routing Keys in > the same ASPAC, it should also send Traffic mode for different Routing Keys > too (AS2 and AS2). > > > Thanx. > shashank > > > > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Saturday, November 05, 2005 2:11 PM > To: Prasad, Shashank S (Shashank) > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > RFC 3332 says: (Section 4.3.4.3 second paragraph) > > For the Application Servers that the ASP can be successfully > activated, the SGP or IPSP responds with one or more ASP Active Ack > messages, including the associated Routing Context(s) and reflecting > any Traffic Mode Type value present in the related ASP Active > message. The Routing Context parameter MUST be included in the ASP > Active Ack message(s) if the received ASP Active message contained > any Routing Contexts. Depending on any Traffic Mode Type request in > the ASP Active message, or local configuration data if there is no > request, the SGP moves the ASP to the correct ASP traffic state > within the associated Application Server(s). Layer Management is > informed with an M-ASP_Active indication. If the SGP or IPSP receives > any Data messages before an ASP Active message is received, the SGP > or IPSP MAY discard them. By sending an ASP Active Ack message, the > SGP or IPSP is now ready to receive and send traffic for the related > Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages > for the related Routing Context(s) before receiving an ASP Active Ack > message, or it will risk message loss. > > I think that this is quite clear with regard to two things: > > The IPSP receiving the ASP Active message responds with regard to Traffic > Mode in the same fashion as an SGP would. > > Traffic Mode included in the ASP Active Ack is simply the value from the > ASP Active message reflected back at the activating ASP. > > SGPs do not have traffic modes. Also, they do not have activation or > up/down states either. See RFC 3332 Section 1.4.2.5: > > 1.4.2.5 Message Distribution at the ASP > > The ASP must choose an SGP to direct a message to the SS7 network. > This is accomplished by observing the Destination Point Code (and > possibly other elements of the outgoing message such as the SLS > value). The ASP must also take into account whether the related > Routing Context is active or not (See Section 4.3.4.3). > > Implementation Note: Where more than one route (or SGP) is possible > for routing to the SS7 network, the ASP could, for example, maintain > a dynamic table of available SGP routes for the SS7 destinations, > taking into account the SS7 destination > availability/restricted/congestion status received from the SGP(s), > the availability status of the individual SGPs and configuration > changes and failover mechanisms. There is, however, no M3UA messaging > to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive > messaging). > > Whenever an SCTP association to an SGP exists, the SGP is assumed to > be ready for the purposes of responding to M3UA ASPSM messages (Refer > to Section 3). > > See also RFC 3332 Appendix A.2.2: > > A.2.2 Signalling Gateway Redundancy > > Signalling Gateways may also be distributed over multiple hosts. > Much like the AS model, SGs may comprise one or more SG Processes > (SGPs), distributed over one or more hosts, using an active/backup or > a loadsharing model. Should an SGP lose all or partial SS7 > connectivity and other SGPs exist, the SGP may terminate the SCTP > associations to the concerned ASPs. > > It is therefore possible for an ASP to route signalling messages > destined to the SS7 network using more than one SGP. In this model, > a Signalling Gateway is deployed as a cluster of hosts acting as a > single SG. A primary/backup redundancy model is possible, where the > unavailability of the SCTP association to a primary SGP could be used > to reroute affected traffic to an alternate SGP. A loadsharing model > is possible, where the signalling messages are loadshared between > multiple SGPs. A broadcast model is also possible, where signalling > messages are sent to each active SGP in the SG. The distribution of > the MTP3-user messages over the SGPs should be done in such a way to > minimize message missequencing, as required by the SS7 User Parts. > > It may also be possible for an ASP to use more than one SG to access > a specific SS7 end point, in a model that resembles an SS7 STP mated > pair. Typically, SS7 STPs are deployed in mated pairs, with traffic > loadshared between them. Other models are also possible, subject to > the limitations of the local SS7 network provisioning guidelines. > > From the perspective of the M3UA layer at an ASP, a particular SG is > capable of transferring traffic to a provisioned SS7 destination X if > an SCTP association with at least one SGP of the SG is established, > the SGP has returned an acknowledgement to the ASP to indicate that > the ASP is actively handling traffic for that destination X, the SGP > has not indicated that the destination X is inaccessible and the SGP > has not indicated MTP Restart. When an ASP is configured to use > multiple SGPs for transferring traffic to the SS7 network, the ASP > must maintain knowledge of the current capability of the SGPs to > handle traffic to destinations of interest. This information is > crucial to the overall reliability of the service, for active/backup, > loadsharing and broadcast models, in the event of failures, recovery > and maintenance activities. The ASP M3UA may also use this > information for congestion avoidance purposes. The distribution of > the MTP3-user messages over the SGPs should be done in such a way to > minimize message missequencing, as required by the SS7 User Parts. > > I think these passages are quite clear. > > --brian > > > Prasad, Shashank S (Shashank) wrote: (Sat, 05 Nov 2005 12:24:04) > > Tolga, > > I agree with ur point. In a Single Ended exchange, the Traffic Mode in the > > ASPAC-Ack could be interpreted as the Traffic Mode of the Node sending > > ASPAC-Ack. This would help the peers to "know" the Traffic Mode of each > > other. > > > > Some more important points: > > The ASPAC message can have multiple (n) Routing Contexts. > > And therefore the Traffic Mode sent in the ASP-Ack must also have the > > Traffic Mode per Routing Context. > > > > Hence the ASPAC-Ack should have Traffic Mode per Routing Context. Would u > > agree ? > > > > > > > > However, there is still a catch. > > The Traffic Mode is an Optional parameter in ASPAC and ASPAC-Ack messages. > > At present, M3UA has left to the implementators on how to interpret > Traffic > > Modes of each other, in case, the peers do NOT exchange Traffic Modes. > > > > I was therefore suggesting that we could have M3UA suggest a default > > implementation of Traffic Mode, and rather NOT leave to the > implementation. > > And I suggested Override, because, I would always believe that whenever a > > node gets the last ASPAC or ASPAC-Ack (intrododuced in the course of our > > discussion), without any Traffic Mode (since it is Optional), it shall > > interpret that the peer intends to use this ASP for its communication. > > > > > > At the same time, we ALSO have ur suggestion about IPSPs sending their > > respective Traffic modes in ASPAC-Ack messages. > > > > > > shashank > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Saturday, November 05, 2005 1:42 AM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Friday, November 04, 2005 2:08 PM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Reply embedded. > > > > > > shashank > > > > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Tolga Asveren > > > Sent: Friday, November 04, 2005 10:09 PM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Shashank, > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Prasad, Shashank S (Shashank) > > > > Sent: Friday, November 04, 2005 11:07 AM > > > > To: 'Tolga Asveren'; sigtran@ietf.org > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Oh OK ! > > > > Looks like, it could potentially happen that NodeB can limit itself to > > > > sending traffic for PS1 on only one of associations also, rather > > > > than both. > > > > However, IPSP1 has really to "listen" at both the associations. > > > > Is that correct ? > > > [TOLGA]Yes. Please also note that it is the M3UA-User which controls > this > > > behavior on Node-B, i.e. this is not loadhsaring on M3UA level > > > but one layer > > > above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When > > > they receive a > > > message from their user, they will send it to IPSP1. > > > > > > [SHASHANK] OK, I get ur point related to the role of M3UA User. > > > > > > > > > > > > > > > > > > > > A couple of more questions that now comes up: > > > > 1. In a single ended scenario, how could have IPSP1 (at NodeA) > > > determined > > > > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent > > > from IPSP1 to > > > > IPSP2 and IPSP3 ? (Instead of what is shown my illustration) > > > [TOLGA]Through local configuration, please note Traffic Mode parameter > is > > > optional. OTOH, I think that it could be an idea to modify the protocol > a > > > bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending > side > > > about traffic mode on the peer side in case it is necessary. > > > > > > > > > > [SHASHANK] Yeah, I believe that ASPAC-ACK can be tailored to to > > > inform ASPAC > > > sending side > > > about traffic mode on the peer side in case it is necessary. That > > > will help > > > a > > > great deal in the single exchange scenarios to exchange the Traffic > Modes. > > > At present, the M3UA protocol does NOT say anything explicitly on this. > > > > > > Alternatively, the protocol could also define a default Traffic Mode > > > explicitly (possibly Override). And in case the peers do NOT exchange > > > the Traffic mode, the default Traffic Mode (as specified in the specs) > can > > > be used. > > > > > > Now that we understand the need, do u think that this could be taken up > > > further ? > > [TOLGA]I am not sure whether it is a good idea to declare a default > traffic > > mode but allowing both sides to use Traffic Mode parameter makes sense to > > me. Similar concept could be applied for SGPs as well, i.e. they declare > > their traffic mode with Traffic Mode in ASPAC-ACK -actually this in > > practicall life is probably less useful-. Any other opinions about this > > issue? It looks like a useful feature to me to use Traffic Mode in both > > directions. > > > > > > > > > > 2. In a single exchange scenario, isn't it needed to have the peer ASs > > > > having the same Traffic Mode ? > > > [TOLGA]I believe what you mean as "AS traffic mode" is traffic > > > mode of peer > > > IPSPs in the context of an AS. As far as I can see different traffic > modes > > > shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE > > > simultaneously at both sides. > > > > > > > [SHASHANK] I agree with the answer to my second question. > > > > > > > shashank > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Tolga Asveren > > > > Sent: Friday, November 04, 2005 8:51 PM > > > > To: sigtran@ietf.org > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > This is implementation/traffic type dependent and is not something > > > > standardized by M3UA. > > > > > > > > > -----Original Message----- > > > > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > > > > Sent: Friday, November 04, 2005 10:28 AM > > > > > To: 'Tolga Asveren'; sigtran@ietf.org > > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Thanx Tolga. U are right in understanding my question. > > > > > > > > > > Followup Question: > > > > > Since IPSP2 and IPSP3 are serving the same AS, what would determine > at > > > > > NodeB, if the traffic to IPSP1 is > > > > > to be sent via IPSP2 or IPSP3 ? > > > > > > > > > > > > > > > shashank > > > > > > > > > > -----Original Message----- > > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > > Behalf Of Tolga Asveren > > > > > Sent: Friday, November 04, 2005 8:13 PM > > > > > To: sigtran@ietf.org > > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Shashank, > > > > > > > > > > As far as I understand your question: > > > > > > > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > > > > for this RK > > > > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > > > > mode. You are > > > > > wondering whether IPSP1 will receive traffic from both IPSP2 > > > and IPSP3. > > > > > > > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > > > > IPSP1. IPSP2 > > > > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > > > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because > > > traffic from a > > > > > single source is distrubuted to multiple peers. > > > > > > > > > > Tolga > > > > > > > > > > > -----Original Message----- > > > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > > > Behalf Of Prasad, Shashank S (Shashank) > > > > > > Sent: Friday, November 04, 2005 9:48 AM > > > > > > To: 'sigtran@ietf.org' > > > > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > > > > Hi, > > > > > > I had a specific question related to a specific scenario > > > > explained below > > > > > > (Single Exchange scenario) > > > > > > > > > > > > NodeA supports 1 PS with 1 IPSP > > > > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > > > > > > > > > > There are two associations between NodeA and NodeB. > > > > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > > > > on NodeB, > > > > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > > > > that IPSP2 and > > > > > > IPSP3, > > > > > > serving a loadshared PS2, are essentially telling NodeA to > > > > > > loadshare all the > > > > > > traffic > > > > > > for PS2, between IPSP2 and IPSP3. > > > > > > > > > > > > The above concepts are also illustrated below....(I have > > > purposefully > > > > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > > > > > > > PS1-IPSP1 PS2-IPSP2 > PS2-IPSP3 > > > > > > | | | > > > > > > |<-----ASP Up------------| | > > > > > > |-------ASP Up Ack------>| (Assoc #1) | > > > > > > | | | > > > > > > | | | > > > > > > |<--------------------ASP Up------------------------| > > > > > (Assoc #2) > > > > > > |----------------------------ASP Up Ack------------>| > > > > > > | | | > > > > > > | | | > > > > > > | | | > > > > > > |<--ASP Active(Ldshr)----| | > > > > > > |------ASP Active Ack--->| | > > > > > > | | | > > > > > > | | | > > > > > > | | | > > > > > > |<--------------------ASP Active(Ldshr)-------------| > > > > > > |----------------------------ASP Up Ack------------>| > > > > > > | | | > > > > > > | | | > > > > > > |---NOTIFY(AS-ACTIVE)--->| | > > > > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > > > > | | | > > > > > > > > > > > > > > > > > > > > > > > > Questions: > > > > > > Assuming a single exchange scenario, would the traffic towards > > > > > > PS1 on NodeA, > > > > > > > > > > > > be also loadshared across 2 associations ? > > > > > > > > > > > > I thought it would and hence another follow-up question: > > > > > > It looks like a loadshared peer (NodeB in our case) with > > > > > multiple IPSPs, > > > > > > is putting a constraint on the NodeA, to ALSO be ready to > > > > > receive data on > > > > > > multiple associations and possibly loadshared. Is this a fair > > > > > > understanding > > > > > > ? > > > > > > > > > > > > > > > > > > shashank > > > > > > > > > > > > _______________________________________________ > > > > > > Sigtran mailing list > > > > > > Sigtran@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sigtran mailing list > > > > > Sigtran@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > 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 > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Sun Nov 06 18:48:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYuFC-0000AH-UD; Sun, 06 Nov 2005 18:48:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYuFB-0000AC-QM for sigtran@megatron.ietf.org; Sun, 06 Nov 2005 18:48:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27664 for ; Sun, 6 Nov 2005 18:47:47 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYuUd-000088-8N for sigtran@ietf.org; Sun, 06 Nov 2005 19:04:14 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA6Nm0ft013173 for ; Sun, 6 Nov 2005 17:48:02 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Nov 2005 05:18:00 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB6861@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Mon, 7 Nov 2005 05:17:59 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ed37b243475b9c4ffb6a3f90050819d X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, I have only IPSPs in peer to peer communication. There are no SGs. And therefore I would NOT consider SGPs or their equivalent functionality. Ur answer tends me to believe that the Single Exchange is ONLY between an ASP and SGP. Which is NOT correct. Please refer to Sec 5.5.1 and Sec 5.5.2 in the RFC 3332. I can always have SE between 2 IPSPs. It is upto the IPSPs to exchange the right parameters in the messages to indicate to each other about loadsharing. shashank -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Monday, November 07, 2005 1:08 AM To: Prasad, Shashank S (Shashank) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Prasad,, Prasad, Shashank S (Shashank) wrote: (Sun, 06 Nov 2005 22:25:56) > Thanx Brian for ur inputs. > However, I re-read the sections that u mentioned but I still did NOT get the > answer that I was seeking. > > I will try to give an example to better explain. > Possibly, ur answers to the questions (below) could be of good help. > > > -----------------------|----------------------------------------------- > AS1 | AS2(Loadshared), AS3(Override) > -----------------------|----------------------------------------------- > IPSP1 | IPSP2 IPSP3 > (AS1) | (AS2,AS3) (AS2) > -----------------------|----------------------------------------------- > | > > IPSP1 serves AS1. > IPSP2 serves AS2 and AS3. > IPSP3 serves AS2. > > > > 1. In a Single Ended scenario, if the IPSP1 sends ASPAC message to the IPSP2 > and IPSP3, how would IPSP1 know that IPSP2 and IPSP3 are loadshared for AS2 > ? In SE, one IPSP acts as ASP, the other as SGP. If you want a loadshared AS at IPSP2 it will have to send the ASPAC. IPSPs receiving ASPAC act as an SGP (as stated in the passages). For distribution of messages over SGP, see 1.4.2.5 and A.2.2. --brian > > I did NOT see how this would happen, and therefore, we (Tolga and I) were > discussing that IPSP2 and IPSP3 send their respective Traffic Modes for the > various AS they are serving. Which means that ASPAC-Ack from IPSP2 must send > Routing Key of AS2 and AS3 with the Traffic Mode of AS2 and AS3. > > > 2. If the IPSP2 sends ASPAC message to IPSP1, with multiple Routing Keys in > the same ASPAC, it should also send Traffic mode for different Routing Keys > too (AS2 and AS2). > > > Thanx. > shashank > > > > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Saturday, November 05, 2005 2:11 PM > To: Prasad, Shashank S (Shashank) > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > RFC 3332 says: (Section 4.3.4.3 second paragraph) > > For the Application Servers that the ASP can be successfully > activated, the SGP or IPSP responds with one or more ASP Active Ack > messages, including the associated Routing Context(s) and reflecting > any Traffic Mode Type value present in the related ASP Active > message. The Routing Context parameter MUST be included in the ASP > Active Ack message(s) if the received ASP Active message contained > any Routing Contexts. Depending on any Traffic Mode Type request in > the ASP Active message, or local configuration data if there is no > request, the SGP moves the ASP to the correct ASP traffic state > within the associated Application Server(s). Layer Management is > informed with an M-ASP_Active indication. If the SGP or IPSP receives > any Data messages before an ASP Active message is received, the SGP > or IPSP MAY discard them. By sending an ASP Active Ack message, the > SGP or IPSP is now ready to receive and send traffic for the related > Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages > for the related Routing Context(s) before receiving an ASP Active Ack > message, or it will risk message loss. > > I think that this is quite clear with regard to two things: > > The IPSP receiving the ASP Active message responds with regard to Traffic > Mode in the same fashion as an SGP would. > > Traffic Mode included in the ASP Active Ack is simply the value from the > ASP Active message reflected back at the activating ASP. > > SGPs do not have traffic modes. Also, they do not have activation or > up/down states either. See RFC 3332 Section 1.4.2.5: > > 1.4.2.5 Message Distribution at the ASP > > The ASP must choose an SGP to direct a message to the SS7 network. > This is accomplished by observing the Destination Point Code (and > possibly other elements of the outgoing message such as the SLS > value). The ASP must also take into account whether the related > Routing Context is active or not (See Section 4.3.4.3). > > Implementation Note: Where more than one route (or SGP) is possible > for routing to the SS7 network, the ASP could, for example, maintain > a dynamic table of available SGP routes for the SS7 destinations, > taking into account the SS7 destination > availability/restricted/congestion status received from the SGP(s), > the availability status of the individual SGPs and configuration > changes and failover mechanisms. There is, however, no M3UA messaging > to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive > messaging). > > Whenever an SCTP association to an SGP exists, the SGP is assumed to > be ready for the purposes of responding to M3UA ASPSM messages (Refer > to Section 3). > > See also RFC 3332 Appendix A.2.2: > > A.2.2 Signalling Gateway Redundancy > > Signalling Gateways may also be distributed over multiple hosts. > Much like the AS model, SGs may comprise one or more SG Processes > (SGPs), distributed over one or more hosts, using an active/backup or > a loadsharing model. Should an SGP lose all or partial SS7 > connectivity and other SGPs exist, the SGP may terminate the SCTP > associations to the concerned ASPs. > > It is therefore possible for an ASP to route signalling messages > destined to the SS7 network using more than one SGP. In this model, > a Signalling Gateway is deployed as a cluster of hosts acting as a > single SG. A primary/backup redundancy model is possible, where the > unavailability of the SCTP association to a primary SGP could be used > to reroute affected traffic to an alternate SGP. A loadsharing model > is possible, where the signalling messages are loadshared between > multiple SGPs. A broadcast model is also possible, where signalling > messages are sent to each active SGP in the SG. The distribution of > the MTP3-user messages over the SGPs should be done in such a way to > minimize message missequencing, as required by the SS7 User Parts. > > It may also be possible for an ASP to use more than one SG to access > a specific SS7 end point, in a model that resembles an SS7 STP mated > pair. Typically, SS7 STPs are deployed in mated pairs, with traffic > loadshared between them. Other models are also possible, subject to > the limitations of the local SS7 network provisioning guidelines. > > From the perspective of the M3UA layer at an ASP, a particular SG is > capable of transferring traffic to a provisioned SS7 destination X if > an SCTP association with at least one SGP of the SG is established, > the SGP has returned an acknowledgement to the ASP to indicate that > the ASP is actively handling traffic for that destination X, the SGP > has not indicated that the destination X is inaccessible and the SGP > has not indicated MTP Restart. When an ASP is configured to use > multiple SGPs for transferring traffic to the SS7 network, the ASP > must maintain knowledge of the current capability of the SGPs to > handle traffic to destinations of interest. This information is > crucial to the overall reliability of the service, for active/backup, > loadsharing and broadcast models, in the event of failures, recovery > and maintenance activities. The ASP M3UA may also use this > information for congestion avoidance purposes. The distribution of > the MTP3-user messages over the SGPs should be done in such a way to > minimize message missequencing, as required by the SS7 User Parts. > > I think these passages are quite clear. > > --brian > > > Prasad, Shashank S (Shashank) wrote: (Sat, 05 Nov 2005 12:24:04) > > Tolga, > > I agree with ur point. In a Single Ended exchange, the Traffic Mode in the > > ASPAC-Ack could be interpreted as the Traffic Mode of the Node sending > > ASPAC-Ack. This would help the peers to "know" the Traffic Mode of each > > other. > > > > Some more important points: > > The ASPAC message can have multiple (n) Routing Contexts. > > And therefore the Traffic Mode sent in the ASP-Ack must also have the > > Traffic Mode per Routing Context. > > > > Hence the ASPAC-Ack should have Traffic Mode per Routing Context. Would u > > agree ? > > > > > > > > However, there is still a catch. > > The Traffic Mode is an Optional parameter in ASPAC and ASPAC-Ack messages. > > At present, M3UA has left to the implementators on how to interpret > Traffic > > Modes of each other, in case, the peers do NOT exchange Traffic Modes. > > > > I was therefore suggesting that we could have M3UA suggest a default > > implementation of Traffic Mode, and rather NOT leave to the > implementation. > > And I suggested Override, because, I would always believe that whenever a > > node gets the last ASPAC or ASPAC-Ack (intrododuced in the course of our > > discussion), without any Traffic Mode (since it is Optional), it shall > > interpret that the peer intends to use this ASP for its communication. > > > > > > At the same time, we ALSO have ur suggestion about IPSPs sending their > > respective Traffic modes in ASPAC-Ack messages. > > > > > > shashank > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Saturday, November 05, 2005 1:42 AM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Friday, November 04, 2005 2:08 PM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Reply embedded. > > > > > > shashank > > > > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Tolga Asveren > > > Sent: Friday, November 04, 2005 10:09 PM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Shashank, > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Prasad, Shashank S (Shashank) > > > > Sent: Friday, November 04, 2005 11:07 AM > > > > To: 'Tolga Asveren'; sigtran@ietf.org > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Oh OK ! > > > > Looks like, it could potentially happen that NodeB can limit itself to > > > > sending traffic for PS1 on only one of associations also, rather > > > > than both. > > > > However, IPSP1 has really to "listen" at both the associations. > > > > Is that correct ? > > > [TOLGA]Yes. Please also note that it is the M3UA-User which controls > this > > > behavior on Node-B, i.e. this is not loadhsaring on M3UA level > > > but one layer > > > above. IPSP2 and IPSP3 have only one peer anyway, IPSP1. When > > > they receive a > > > message from their user, they will send it to IPSP1. > > > > > > [SHASHANK] OK, I get ur point related to the role of M3UA User. > > > > > > > > > > > > > > > > > > > > A couple of more questions that now comes up: > > > > 1. In a single ended scenario, how could have IPSP1 (at NodeA) > > > determined > > > > the Traffic Mode of AS2 at NodeB, if the ASP Active was sent > > > from IPSP1 to > > > > IPSP2 and IPSP3 ? (Instead of what is shown my illustration) > > > [TOLGA]Through local configuration, please note Traffic Mode parameter > is > > > optional. OTOH, I think that it could be an idea to modify the protocol > a > > > bit to use TrafficMode parameter in ASPAC-ACK to inform ASPAC sending > side > > > about traffic mode on the peer side in case it is necessary. > > > > > > > > > > [SHASHANK] Yeah, I believe that ASPAC-ACK can be tailored to to > > > inform ASPAC > > > sending side > > > about traffic mode on the peer side in case it is necessary. That > > > will help > > > a > > > great deal in the single exchange scenarios to exchange the Traffic > Modes. > > > At present, the M3UA protocol does NOT say anything explicitly on this. > > > > > > Alternatively, the protocol could also define a default Traffic Mode > > > explicitly (possibly Override). And in case the peers do NOT exchange > > > the Traffic mode, the default Traffic Mode (as specified in the specs) > can > > > be used. > > > > > > Now that we understand the need, do u think that this could be taken up > > > further ? > > [TOLGA]I am not sure whether it is a good idea to declare a default > traffic > > mode but allowing both sides to use Traffic Mode parameter makes sense to > > me. Similar concept could be applied for SGPs as well, i.e. they declare > > their traffic mode with Traffic Mode in ASPAC-ACK -actually this in > > practicall life is probably less useful-. Any other opinions about this > > issue? It looks like a useful feature to me to use Traffic Mode in both > > directions. > > > > > > > > > > 2. In a single exchange scenario, isn't it needed to have the peer ASs > > > > having the same Traffic Mode ? > > > [TOLGA]I believe what you mean as "AS traffic mode" is traffic > > > mode of peer > > > IPSPs in the context of an AS. As far as I can see different traffic > modes > > > shouldn't be a problem. Important is that AS becomes ACTIVE/INACTIVE > > > simultaneously at both sides. > > > > > > > [SHASHANK] I agree with the answer to my second question. > > > > > > > shashank > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Tolga Asveren > > > > Sent: Friday, November 04, 2005 8:51 PM > > > > To: sigtran@ietf.org > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > This is implementation/traffic type dependent and is not something > > > > standardized by M3UA. > > > > > > > > > -----Original Message----- > > > > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > > > > Sent: Friday, November 04, 2005 10:28 AM > > > > > To: 'Tolga Asveren'; sigtran@ietf.org > > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Thanx Tolga. U are right in understanding my question. > > > > > > > > > > Followup Question: > > > > > Since IPSP2 and IPSP3 are serving the same AS, what would determine > at > > > > > NodeB, if the traffic to IPSP1 is > > > > > to be sent via IPSP2 or IPSP3 ? > > > > > > > > > > > > > > > shashank > > > > > > > > > > -----Original Message----- > > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > > Behalf Of Tolga Asveren > > > > > Sent: Friday, November 04, 2005 8:13 PM > > > > > To: sigtran@ietf.org > > > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Shashank, > > > > > > > > > > As far as I understand your question: > > > > > > > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > > > > for this RK > > > > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > > > > mode. You are > > > > > wondering whether IPSP1 will receive traffic from both IPSP2 > > > and IPSP3. > > > > > > > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > > > > IPSP1. IPSP2 > > > > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > > > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because > > > traffic from a > > > > > single source is distrubuted to multiple peers. > > > > > > > > > > Tolga > > > > > > > > > > > -----Original Message----- > > > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > > > Behalf Of Prasad, Shashank S (Shashank) > > > > > > Sent: Friday, November 04, 2005 9:48 AM > > > > > > To: 'sigtran@ietf.org' > > > > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > > > > Hi, > > > > > > I had a specific question related to a specific scenario > > > > explained below > > > > > > (Single Exchange scenario) > > > > > > > > > > > > NodeA supports 1 PS with 1 IPSP > > > > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > > > > > > > > > > There are two associations between NodeA and NodeB. > > > > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > > > > on NodeB, > > > > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > > > > that IPSP2 and > > > > > > IPSP3, > > > > > > serving a loadshared PS2, are essentially telling NodeA to > > > > > > loadshare all the > > > > > > traffic > > > > > > for PS2, between IPSP2 and IPSP3. > > > > > > > > > > > > The above concepts are also illustrated below....(I have > > > purposefully > > > > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > > > > > > > PS1-IPSP1 PS2-IPSP2 > PS2-IPSP3 > > > > > > | | | > > > > > > |<-----ASP Up------------| | > > > > > > |-------ASP Up Ack------>| (Assoc #1) | > > > > > > | | | > > > > > > | | | > > > > > > |<--------------------ASP Up------------------------| > > > > > (Assoc #2) > > > > > > |----------------------------ASP Up Ack------------>| > > > > > > | | | > > > > > > | | | > > > > > > | | | > > > > > > |<--ASP Active(Ldshr)----| | > > > > > > |------ASP Active Ack--->| | > > > > > > | | | > > > > > > | | | > > > > > > | | | > > > > > > |<--------------------ASP Active(Ldshr)-------------| > > > > > > |----------------------------ASP Up Ack------------>| > > > > > > | | | > > > > > > | | | > > > > > > |---NOTIFY(AS-ACTIVE)--->| | > > > > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > > > > | | | > > > > > > > > > > > > > > > > > > > > > > > > Questions: > > > > > > Assuming a single exchange scenario, would the traffic towards > > > > > > PS1 on NodeA, > > > > > > > > > > > > be also loadshared across 2 associations ? > > > > > > > > > > > > I thought it would and hence another follow-up question: > > > > > > It looks like a loadshared peer (NodeB in our case) with > > > > > multiple IPSPs, > > > > > > is putting a constraint on the NodeA, to ALSO be ready to > > > > > receive data on > > > > > > multiple associations and possibly loadshared. Is this a fair > > > > > > understanding > > > > > > ? > > > > > > > > > > > > > > > > > > shashank > > > > > > > > > > > > _______________________________________________ > > > > > > Sigtran mailing list > > > > > > Sigtran@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sigtran mailing list > > > > > Sigtran@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > 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 > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Sun Nov 06 21:57:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxCm-0006Ul-Tb; Sun, 06 Nov 2005 21:57:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxCl-0006Ub-Dy for sigtran@megatron.ietf.org; Sun, 06 Nov 2005 21:57:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07212 for ; Sun, 6 Nov 2005 21:57:30 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[ez9pmzoJvDHCqYLKmlPOpC+XX1P9OFKq]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYxSG-0004Y3-R9 for sigtran@ietf.org; Sun, 06 Nov 2005 22:13:58 -0500 Received: from ns.pigworks.openss7.net (IDENT:zEGMzgL0DIh+5F+4yLkygi3cGwTzKsD3@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA72vmc19398; Sun, 6 Nov 2005 19:57:48 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA72vmC08557; Sun, 6 Nov 2005 19:57:48 -0700 Date: Sun, 6 Nov 2005 19:57:47 -0700 From: "Brian F. G. Bidulock" To: "Prasad, Shashank S (Shashank)" Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Message-ID: <20051106195747.A8535@openss7.org> Mail-Followup-To: "Prasad, Shashank S (Shashank)" , sigtran@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D210FB6861@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB6861@ii0015exch002u.iprc.lucent.com>; from ssprasad@lucent.com on Mon, Nov 07, 2005 at 05:17:59AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, > > RFC 3332 says: (Section 4.3.4.3 second paragraph) > > > > For the Application Servers that the ASP can be successfully > > activated, the SGP or IPSP responds with one or more ASP Active Ack > > messages, including the associated Routing Context(s) and reflecting > > any Traffic Mode Type value present in the related ASP Active > > message. The Routing Context parameter MUST be included in the ASP > > Active Ack message(s) if the received ASP Active message contained > > any Routing Contexts. Depending on any Traffic Mode Type request in > > the ASP Active message, or local configuration data if there is no > > request, the SGP moves the ASP to the correct ASP traffic state > > within the associated Application Server(s). Layer Management is > > informed with an M-ASP_Active indication. If the SGP or IPSP receives > > any Data messages before an ASP Active message is received, the SGP > > or IPSP MAY discard them. By sending an ASP Active Ack message, the > > SGP or IPSP is now ready to receive and send traffic for the related > > Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages > > for the related Routing Context(s) before receiving an ASP Active Ack > > message, or it will risk message loss. > > > > I think that this is quite clear with regard to two things: > > > > The IPSP receiving the ASP Active message responds with regard to Traffic > > Mode in the same fashion as an SGP would. Prasad, Shashank S (Shashank) wrote: (Mon, 07 Nov 2005 05:17:59) > Brian, > I have only IPSPs in peer to peer communication. > There are no SGs. And therefore I would NOT consider SGPs or their > equivalent functionality. > > Ur answer tends me to believe that the Single Exchange is ONLY between an > ASP and SGP. > Which is NOT correct. Please refer to Sec 5.5.1 and Sec 5.5.2 in the RFC > 3332. > > I can always have SE between 2 IPSPs. It is upto the IPSPs to exchange the > right parameters in the messages to indicate to each other about > loadsharing. > > > shashank > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 00:31:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYzbc-0002UM-Ib; Mon, 07 Nov 2005 00:31:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYzba-0002UH-Tx for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 00:31:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14963 for ; Mon, 7 Nov 2005 00:31:17 -0500 (EST) Received: from web53810.mail.yahoo.com ([206.190.36.205]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYzr7-0008KV-Es for sigtran@ietf.org; Mon, 07 Nov 2005 00:47:47 -0500 Received: (qmail 89143 invoked by uid 60001); 7 Nov 2005 05:31:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uY9DVTI3WrRbB+sHNLHZO5A/in0VVHtqOcHcLWR0N/X0ts+grk/9qWrAr48kfcvy0Dp2EFWzD2tg4DOGZBDwROuv41RqlKZKD5NBAGm3oORKC7N2fwuATwh5WkmyWE7hbfC0bcqR0OMwBAiY+8p6zJl61uOALBg4Ot6xACzDPg4= ; Message-ID: <20051107053131.89141.qmail@web53810.mail.yahoo.com> Received: from [220.227.128.163] by web53810.mail.yahoo.com via HTTP; Sun, 06 Nov 2005 21:31:31 PST Date: Sun, 6 Nov 2005 21:31:31 -0800 (PST) From: Saraswati Bose Subject: RE:[SIGTRAN] ASPs Load sharing traffic To: bidulock@openss7.org, sigtran@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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="===============1478367661==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1478367661== Content-Type: multipart/alternative; boundary="0-189384306-1131341491=:88219" Content-Transfer-Encoding: 8bit --0-189384306-1131341491=:88219 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Brian, Please answer the below queries related to ASPs load sharing traffic within a AS. 1. Which parameter can be used for IUA for load sharing traffic on a round robin basis between multiple active ASPs within the AS like SLS in M3UA and SSN in SUA? 2. What exact parameters can be kept common for the multiple ASPs sharing traffic? Should it be the routing tables, RCs etc? Suggest. 3. Will the multiple ASPs sharing traffic be uniquely identified by SCTP association or is there ant other parameters also? 4. Can we opt for 1+0 model with load share traffic mode or should it be treated as a invalid configuration? 5. I think only redundant ASPs can load share traffic. As per the RFCs the option may lie with SG whether it will or won't distribute traffic to redundant ASPs (traffic mode = 2) depending on availability of the ASP the SG is currently communicating with. Tell me what condition apply for the above type communciation? --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click. --0-189384306-1131341491=:88219 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Brian,
   Please answer the below queries related to ASPs load sharing traffic within a AS.
 
1. Which parameter can be used for IUA for load sharing traffic on a round robin basis between multiple active ASPs within the AS like SLS in M3UA and SSN in SUA?
 
2. What exact parameters can be kept common for the multiple ASPs sharing traffic? Should it be the routing tables, RCs etc? Suggest.
 
3. Will the multiple ASPs sharing traffic be uniquely identified by SCTP association or is there ant other parameters also?
 
4. Can we opt for 1+0 model with load share traffic mode or should it be treated as a invalid configuration?
 
5. I think only redundant ASPs can load share traffic.
 
As per the RFCs the option may  lie with SG whether it will or won't distribute traffic to redundant ASPs (traffic mode = 2) depending on availability of the ASP the SG is currently communicating with.
Tell me what condition apply for the above type communciation?
 

Yahoo! FareChase - Search multiple travel sites in one click. --0-189384306-1131341491=:88219-- --===============1478367661== 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 --===============1478367661==-- From sigtran-bounces@ietf.org Mon Nov 07 00:52:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYzwA-0006HF-RH; Mon, 07 Nov 2005 00:52:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYzw8-0006H7-M7 for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 00:52:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15853 for ; Mon, 7 Nov 2005 00:52:31 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[R3H61fJ7IRtrVsyGN/N3yx4J/xwuGTkE]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ0Bd-0000MG-Ja for sigtran@ietf.org; Mon, 07 Nov 2005 01:09:01 -0500 Received: from ns.pigworks.openss7.net (IDENT:Oj4IUd66N0u9oxEXmiNwUr3d0GYxrlEe@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA75qic22280; Sun, 6 Nov 2005 22:52:45 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA75qis10445; Sun, 6 Nov 2005 22:52:44 -0700 Date: Sun, 6 Nov 2005 22:52:44 -0700 From: "Brian F. G. Bidulock" To: Saraswati Bose Subject: Re: [SIGTRAN] ASPs Load sharing traffic Message-ID: <20051106225244.A10365@openss7.org> Mail-Followup-To: Saraswati Bose , sigtran@ietf.org References: <20051107053131.89141.qmail@web53810.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20051107053131.89141.qmail@web53810.mail.yahoo.com>; from saraswatibose@yahoo.com on Sun, Nov 06, 2005 at 09:31:31PM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Saraswati, Please see comments below... Saraswati Bose wrote: (Sun, 06 Nov 2005 21:31:31) > > Brian, > > Please answer the below queries related to ASPs load sharing > traffic within a AS. > > > > 1. Which parameter can be used for IUA for load sharing traffic on a > round robin basis between multiple active ASPs within the AS like SLS > in M3UA and SSN in SUA? DLCI? > > > > 2. What exact parameters can be kept common for the multiple ASPs > sharing traffic? Should it be the routing tables, RCs etc? Suggest. > Any parameter con be kept common, but none are required to be kept common. Good sense would be to keep NA and RC/IID common across SGP-ASP relations. The RFCs indicate this. > > > 3. Will the multiple ASPs sharing traffic be uniquely identified by > SCTP association or is there ant other parameters also? > ASP Identifier. > > > 4. Can we opt for 1+0 model with load share traffic mode or should it > be treated as a invalid configuration? Sure, it is a valid configuration. It is not precluded by the RFCs. > > > > 5. I think only redundant ASPs can load share traffic. > If there is only one ASP, loadsharing is simply a matter of routing all messages to the same ASP. There is little difference between one ASP active for a loadsharing AS and a 1+0 configuration. > > > As per the RFCs the option may lie with SG whether it will or won't > distribute traffic to redundant ASPs (traffic mode = 2) depending on > availability of the ASP the SG is currently communicating with. > > Tell me what condition apply for the above type communciation? How about ASP availability to the distributing SGP? ;) --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 04:36:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ3Qs-0004oT-6e; Mon, 07 Nov 2005 04:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ3Qq-0004oL-Ia for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 04:36:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28699 for ; Mon, 7 Nov 2005 04:36:27 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ3gQ-0006Tk-JI for sigtran@ietf.org; Mon, 07 Nov 2005 04:52:58 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA79aZvC013387; Mon, 7 Nov 2005 03:36:36 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Nov 2005 15:06:35 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB6882@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Mon, 7 Nov 2005 15:06:34 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: "'bidulock@openss7.org'" X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, ASPAC (and ASPAC-Ack) message has one Traffic mode and mutiple(n) Routing Contexts. My point is that the ASP Active message must have as many modes as Routing Contexts ....OR.... ...The implementation should club all the Routing Contexts with the same Traffic Mode in a ASP Active message and then send the others in a different ASP Active.... This is possible but it is quite and indirect mechanism to send ASP Active messages.... Verbatim from the specs: For the Application Servers that the ASP can be successfully activated, the SGP or IPSP responds with one or more ASP Active Ack messages, including the associated Routing Context(s) and reflecting any Traffic Mode Type value present in the related ASP Active message. Does this mean that the Traffic mode in the ASPAC-Ack is the traffic mode of the sender of ASP-Ack ? >From the RFC text "...reflecting any Traffic Mode Type value present in the related ASP Active message ", I interpret that the Traffic Mode received in the ASPAC messages shall be sent back in ASPAC-Ack. And it is NOT really the Traffic mode of the sender of ASPAC-Ack. And that's the issue which I see in the Single Ended mode wherein the sender of ASPAC will never come to know the Traffic Mode of the peer. shashank -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Monday, November 07, 2005 8:28 AM To: Prasad, Shashank S (Shashank) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Shashank, > > RFC 3332 says: (Section 4.3.4.3 second paragraph) > > > > For the Application Servers that the ASP can be successfully > > activated, the SGP or IPSP responds with one or more ASP Active Ack > > messages, including the associated Routing Context(s) and reflecting > > any Traffic Mode Type value present in the related ASP Active > > message. The Routing Context parameter MUST be included in the ASP > > Active Ack message(s) if the received ASP Active message contained > > any Routing Contexts. Depending on any Traffic Mode Type request in > > the ASP Active message, or local configuration data if there is no > > request, the SGP moves the ASP to the correct ASP traffic state > > within the associated Application Server(s). Layer Management is > > informed with an M-ASP_Active indication. If the SGP or IPSP receives > > any Data messages before an ASP Active message is received, the SGP > > or IPSP MAY discard them. By sending an ASP Active Ack message, the > > SGP or IPSP is now ready to receive and send traffic for the related > > Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages > > for the related Routing Context(s) before receiving an ASP Active Ack > > message, or it will risk message loss. > > > > I think that this is quite clear with regard to two things: > > > > The IPSP receiving the ASP Active message responds with regard to Traffic > > Mode in the same fashion as an SGP would. Prasad, Shashank S (Shashank) wrote: (Mon, 07 Nov 2005 05:17:59) > Brian, > I have only IPSPs in peer to peer communication. > There are no SGs. And therefore I would NOT consider SGPs or their > equivalent functionality. > > Ur answer tends me to believe that the Single Exchange is ONLY between an > ASP and SGP. > Which is NOT correct. Please refer to Sec 5.5.1 and Sec 5.5.2 in the RFC > 3332. > > I can always have SE between 2 IPSPs. It is upto the IPSPs to exchange the > right parameters in the messages to indicate to each other about > loadsharing. > > > shashank > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 04:56:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ3jr-0008MY-RU; Mon, 07 Nov 2005 04:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ3jp-0008MM-Ru for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 04:56:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29492 for ; Mon, 7 Nov 2005 04:56:04 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ3zO-0006uY-Rb for sigtran@ietf.org; Mon, 07 Nov 2005 05:12:36 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA79uJtB027187; Mon, 7 Nov 2005 03:56:20 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Nov 2005 15:26:16 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB6883@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Mon, 7 Nov 2005 15:26:07 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, I picked up an old discussion thread that I had with u. What specifically did u mean, when u said - implementation dependent ? Did u mean local configuration ? And what did u mean by Traffic Type ? Did u mean that IPSP1 can send ASPAC to the 2 IPSPs with Traffic Type as Loadshared ? If YES, then this would really not help because IPSP2 and IPSP3 (illustrated below) are different entities by themselves. shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Friday, November 04, 2005 8:51 PM To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow This is implementation/traffic type dependent and is not something standardized by M3UA. > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Friday, November 04, 2005 10:28 AM > To: 'Tolga Asveren'; sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Thanx Tolga. U are right in understanding my question. > > Followup Question: > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > NodeB, if the traffic to IPSP1 is > to be sent via IPSP2 or IPSP3 ? > > > shashank > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Friday, November 04, 2005 8:13 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > As far as I understand your question: > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > for this RK > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > mode. You are > wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3. > > Yes, it can, but I wouldn't call it traffic being loadshared to > IPSP1. IPSP2 > and IPSP3 are not the same entities. OTOH it makes sense to speak of > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a > single source is distrubuted to multiple peers. > > Tolga > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Prasad, Shashank S (Shashank) > > Sent: Friday, November 04, 2005 9:48 AM > > To: 'sigtran@ietf.org' > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Hi, > > I had a specific question related to a specific scenario explained below > > (Single Exchange scenario) > > > > NodeA supports 1 PS with 1 IPSP > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > There are two associations between NodeA and NodeB. > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 on NodeB, > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > that IPSP2 and > > IPSP3, > > serving a loadshared PS2, are essentially telling NodeA to > > loadshare all the > > traffic > > for PS2, between IPSP2 and IPSP3. > > > > The above concepts are also illustrated below....(I have purposefully > > avoided AS-ACTIVE notification) > > > > > > > > NodeA <------------NodeB------------> > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > | | | > > |<-----ASP Up------------| | > > |-------ASP Up Ack------>| (Assoc #1) | > > | | | > > | | | > > |<--------------------ASP Up------------------------| > (Assoc #2) > > |----------------------------ASP Up Ack------------>| > > | | | > > | | | > > | | | > > |<--ASP Active(Ldshr)----| | > > |------ASP Active Ack--->| | > > | | | > > | | | > > | | | > > |<--------------------ASP Active(Ldshr)-------------| > > |----------------------------ASP Up Ack------------>| > > | | | > > | | | > > |---NOTIFY(AS-ACTIVE)--->| | > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > | | | > > > > > > > > Questions: > > Assuming a single exchange scenario, would the traffic towards > > PS1 on NodeA, > > > > be also loadshared across 2 associations ? > > > > I thought it would and hence another follow-up question: > > It looks like a loadshared peer (NodeB in our case) with > multiple IPSPs, > > is putting a constraint on the NodeA, to ALSO be ready to > receive data on > > multiple associations and possibly loadshared. Is this a fair > > understanding > > ? > > > > > > shashank > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 05:53:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ4dM-0000xX-TH; Mon, 07 Nov 2005 05:53:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ4dK-0000xM-10 for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 05:53:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02136 for ; Mon, 7 Nov 2005 05:53:24 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[kTspdDkYtM4CO8Rum7i5DDAGvLi0XN3j]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ4sq-0008H9-Ib for sigtran@ietf.org; Mon, 07 Nov 2005 06:09:57 -0500 Received: from ns.pigworks.openss7.net (IDENT:XZQxmaLCYEvCmBxg0bD8SZXKNtzTJU74@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA7Argc27520; Mon, 7 Nov 2005 03:53:42 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA7ArfR14719; Mon, 7 Nov 2005 03:53:41 -0700 Date: Mon, 7 Nov 2005 03:53:41 -0700 From: "Brian F. G. Bidulock" To: "Prasad, Shashank S (Shashank)" Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Message-ID: <20051107035341.A14656@openss7.org> Mail-Followup-To: "Prasad, Shashank S (Shashank)" , sigtran@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D210FB6882@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB6882@ii0015exch002u.iprc.lucent.com>; from ssprasad@lucent.com on Mon, Nov 07, 2005 at 03:06:34PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, The RFC is clear: the TM in the ASP Active Ack is the value that was sent in the ASP Active. In SE mode, the peer does not have a traffic mode. It is acting like an SGP. Again, see A.2.2. If you want both IPSPs to each have an AS an traffic mode, use DE instead of SE. --brian Prasad, Shashank S (Shashank) wrote: (Mon, 07 Nov 2005 15:06:34) > Brian, > > ASPAC (and ASPAC-Ack) message has one Traffic mode and mutiple(n) Routing > Contexts. > My point is that the ASP Active message must have as many modes as Routing > Contexts ....OR.... > > ...The implementation should club all the Routing Contexts with the same > Traffic Mode in a ASP Active message and then send the others in a different > ASP Active.... This is possible but it is quite and indirect mechanism to > send ASP Active messages.... > > > Verbatim from the specs: > > For the Application Servers that the ASP can be successfully > activated, the SGP or IPSP responds with one or more ASP Active Ack > messages, including the associated Routing Context(s) and reflecting > any Traffic Mode Type value present in the related ASP Active > message. > > > Does this mean that the Traffic mode in the ASPAC-Ack is the traffic mode of > the sender of ASP-Ack ? > >From the RFC text "...reflecting any Traffic Mode Type value present in the > related ASP Active message ", I interpret that the Traffic Mode received in > the ASPAC messages shall be sent back in ASPAC-Ack. > And it is NOT really the Traffic mode of the sender of ASPAC-Ack. > > And that's the issue which I see in the Single Ended mode wherein the sender > of ASPAC will never come to know the Traffic Mode of the peer. > > shashank > > > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, November 07, 2005 8:28 AM > To: Prasad, Shashank S (Shashank) > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > > > RFC 3332 says: (Section 4.3.4.3 second paragraph) > > > > > > For the Application Servers that the ASP can be successfully > > > activated, the SGP or IPSP responds with one or more ASP Active Ack > > > messages, including the associated Routing Context(s) and reflecting > > > any Traffic Mode Type value present in the related ASP Active > > > message. The Routing Context parameter MUST be included in the ASP > > > Active Ack message(s) if the received ASP Active message contained > > > any Routing Contexts. Depending on any Traffic Mode Type request in > > > the ASP Active message, or local configuration data if there is no > > > request, the SGP moves the ASP to the correct ASP traffic state > > > within the associated Application Server(s). Layer Management is > > > informed with an M-ASP_Active indication. If the SGP or IPSP receives > > > any Data messages before an ASP Active message is received, the SGP > > > or IPSP MAY discard them. By sending an ASP Active Ack message, the > > > SGP or IPSP is now ready to receive and send traffic for the related > > > Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages > > > for the related Routing Context(s) before receiving an ASP Active Ack > > > message, or it will risk message loss. > > > > > > I think that this is quite clear with regard to two things: > > > > > > The IPSP receiving the ASP Active message responds with regard to > Traffic > > > Mode in the same fashion as an SGP would. > > Prasad, Shashank S (Shashank) wrote: > (Mon, 07 Nov 2005 05:17:59) > > Brian, > > I have only IPSPs in peer to peer communication. > > There are no SGs. And therefore I would NOT consider SGPs or their > > equivalent functionality. > > > > Ur answer tends me to believe that the Single Exchange is ONLY between an > > ASP and SGP. > > Which is NOT correct. Please refer to Sec 5.5.1 and Sec 5.5.2 in the RFC > > 3332. > > > > I can always have SE between 2 IPSPs. It is upto the IPSPs to exchange the > > right parameters in the messages to indicate to each other about > > loadsharing. > > > > > > shashank > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 07:09:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ5on-00058v-46; Mon, 07 Nov 2005 07:09:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ5ol-00057n-6L for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 07:09:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05640 for ; Mon, 7 Nov 2005 07:09:17 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ64M-0001ck-B4 for sigtran@ietf.org; Mon, 07 Nov 2005 07:25:50 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA7C9TYR026657; Mon, 7 Nov 2005 06:09:30 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Nov 2005 17:39:28 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB6887@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Mon, 7 Nov 2005 17:39:22 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: "'bidulock@openss7.org'" X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, Replies embedded. -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Monday, November 07, 2005 4:24 PM To: Prasad, Shashank S (Shashank) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Shashank, The RFC is clear: the TM in the ASP Active Ack is the value that was sent in the ASP Active. In SE mode, the peer does not have a traffic mode. It is acting like an SGP. Again, see A.2.2. [SHASHANK] U are putting a lot of constraints by this statement. Ur statement means that IPSP-IPSP cannot have a SE mode. This is NOT really correct. Here I am trying to make some minor improvements in the M3UA specs so that IPSPs can also use the SE effectively. If you want both IPSPs to each have an AS an traffic mode, use DE instead of SE. [SHASHANK] This is a big contraint and not acceptable :) IPSPs can surely use SE mode too between themselves (IPSPs). Moreover DE is optional. --brian Prasad, Shashank S (Shashank) wrote: (Mon, 07 Nov 2005 15:06:34) > Brian, > > ASPAC (and ASPAC-Ack) message has one Traffic mode and mutiple(n) Routing > Contexts. > My point is that the ASP Active message must have as many modes as Routing > Contexts ....OR.... > > ...The implementation should club all the Routing Contexts with the same > Traffic Mode in a ASP Active message and then send the others in a different > ASP Active.... This is possible but it is quite and indirect mechanism to > send ASP Active messages.... > > > Verbatim from the specs: > > For the Application Servers that the ASP can be successfully > activated, the SGP or IPSP responds with one or more ASP Active Ack > messages, including the associated Routing Context(s) and reflecting > any Traffic Mode Type value present in the related ASP Active > message. > > > Does this mean that the Traffic mode in the ASPAC-Ack is the traffic mode of > the sender of ASP-Ack ? > >From the RFC text "...reflecting any Traffic Mode Type value present in the > related ASP Active message ", I interpret that the Traffic Mode received in > the ASPAC messages shall be sent back in ASPAC-Ack. > And it is NOT really the Traffic mode of the sender of ASPAC-Ack. > > And that's the issue which I see in the Single Ended mode wherein the sender > of ASPAC will never come to know the Traffic Mode of the peer. > > shashank > > > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, November 07, 2005 8:28 AM > To: Prasad, Shashank S (Shashank) > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > > > RFC 3332 says: (Section 4.3.4.3 second paragraph) > > > > > > For the Application Servers that the ASP can be successfully > > > activated, the SGP or IPSP responds with one or more ASP Active Ack > > > messages, including the associated Routing Context(s) and reflecting > > > any Traffic Mode Type value present in the related ASP Active > > > message. The Routing Context parameter MUST be included in the ASP > > > Active Ack message(s) if the received ASP Active message contained > > > any Routing Contexts. Depending on any Traffic Mode Type request in > > > the ASP Active message, or local configuration data if there is no > > > request, the SGP moves the ASP to the correct ASP traffic state > > > within the associated Application Server(s). Layer Management is > > > informed with an M-ASP_Active indication. If the SGP or IPSP receives > > > any Data messages before an ASP Active message is received, the SGP > > > or IPSP MAY discard them. By sending an ASP Active Ack message, the > > > SGP or IPSP is now ready to receive and send traffic for the related > > > Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages > > > for the related Routing Context(s) before receiving an ASP Active Ack > > > message, or it will risk message loss. > > > > > > I think that this is quite clear with regard to two things: > > > > > > The IPSP receiving the ASP Active message responds with regard to > Traffic > > > Mode in the same fashion as an SGP would. > > Prasad, Shashank S (Shashank) wrote: > (Mon, 07 Nov 2005 05:17:59) > > Brian, > > I have only IPSPs in peer to peer communication. > > There are no SGs. And therefore I would NOT consider SGPs or their > > equivalent functionality. > > > > Ur answer tends me to believe that the Single Exchange is ONLY between an > > ASP and SGP. > > Which is NOT correct. Please refer to Sec 5.5.1 and Sec 5.5.2 in the RFC > > 3332. > > > > I can always have SE between 2 IPSPs. It is upto the IPSPs to exchange the > > right parameters in the messages to indicate to each other about > > loadsharing. > > > > > > shashank > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 07:47:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6Oy-0002kM-G8; Mon, 07 Nov 2005 07:47:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6Ow-0002kH-LN for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 07:47:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07122 for ; Mon, 7 Nov 2005 07:46:40 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[9owprIO1aRFc2BnqUvqEfyrqRMQ8XSIt]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ6eV-0002Vn-0E for sigtran@ietf.org; Mon, 07 Nov 2005 08:03:14 -0500 Received: from ns.pigworks.openss7.net (IDENT:f/0zZVtCPbv86jtF/oNfFGK8w7KdRKjt@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA7Ckwc29892; Mon, 7 Nov 2005 05:46:58 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA7Ckt016867; Mon, 7 Nov 2005 05:46:55 -0700 Date: Mon, 7 Nov 2005 05:46:55 -0700 From: "Brian F. G. Bidulock" To: "Prasad, Shashank S (Shashank)" Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Message-ID: <20051107054655.A16653@openss7.org> Mail-Followup-To: "Prasad, Shashank S (Shashank)" , sigtran@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D210FB6887@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB6887@ii0015exch002u.iprc.lucent.com>; from ssprasad@lucent.com on Mon, Nov 07, 2005 at 05:39:22PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, I don't think that you understand SE mode. Take a look back in the mail archives for long discussions of the differences between SE and DE modes. SE mode uses the same semantics as an ASP/SGP connection, where one IPSP acts like an ASP in the exchange and the other acts like an SGP. I find it strange that you refuse to use DE mode, yet seem to want to mogrify SE into DE. --brian Prasad, Shashank S (Shashank) wrote: (Mon, 07 Nov 2005 17:39:22) > Brian, > > Replies embedded. > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, November 07, 2005 4:24 PM > To: Prasad, Shashank S (Shashank) > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > The RFC is clear: the TM in the ASP Active Ack is the value that was sent > in the ASP Active. > > In SE mode, the peer does not have a traffic mode. It is acting like an > SGP. > Again, see A.2.2. > > [SHASHANK] U are putting a lot of constraints by this statement. Ur > statement means that IPSP-IPSP cannot have a SE mode. This is NOT really > correct. Here I am trying to make some minor improvements in the M3UA specs > so that IPSPs can also use the SE effectively. > > > If you want both IPSPs to each have an AS an traffic mode, use DE instead > of SE. > > [SHASHANK] This is a big contraint and not acceptable :) > IPSPs can surely use SE mode too between themselves (IPSPs). Moreover DE is > optional. > > > --brian > > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 08:13:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6oJ-0007kT-HD; Mon, 07 Nov 2005 08:13:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6oI-0007kO-EO for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 08:13:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08750 for ; Mon, 7 Nov 2005 08:12:52 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ73u-0003Ch-9j for sigtran@ietf.org; Mon, 07 Nov 2005 08:29:26 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA7DCuDT002669 for ; Mon, 7 Nov 2005 08:12:59 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Mon, 7 Nov 2005 07:54:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB6887@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Prasad, Shashank S (Shashank) > Sent: Monday, November 07, 2005 7:09 AM > To: sigtran@ietf.org > Cc: 'bidulock@openss7.org' > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Brian, > > Replies embedded. > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, November 07, 2005 4:24 PM > To: Prasad, Shashank S (Shashank) > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > The RFC is clear: the TM in the ASP Active Ack is the value that was sent > in the ASP Active. > > In SE mode, the peer does not have a traffic mode. It is acting like an > SGP. > Again, see A.2.2. > > [SHASHANK] U are putting a lot of constraints by this statement. Ur > statement means that IPSP-IPSP cannot have a SE mode. This is NOT really > correct. Here I am trying to make some minor improvements in the > M3UA specs > so that IPSPs can also use the SE effectively. [TOLGA]I agree with Shashanks point here. IMO, we have an unnecessary costraint in -SE-IPSP mode. I don't see any problem why using Traffic Mode in both directions should create a problem. Forcing people to use DE-IPSP mode -which is both optional and IMO more importantt han that not a really peer-to-peer model- to set traffic modes in both directions is anot a solution. > > > If you want both IPSPs to each have an AS an traffic mode, use DE instead > of SE. > > [SHASHANK] This is a big contraint and not acceptable :) > IPSPs can surely use SE mode too between themselves (IPSPs). > Moreover DE is > optional. > > > --brian > > > Prasad, Shashank S (Shashank) wrote: (Mon, 07 Nov 2005 > 15:06:34) > > Brian, > > > > ASPAC (and ASPAC-Ack) message has one Traffic mode and > mutiple(n) Routing > > Contexts. > > My point is that the ASP Active message must have as many modes > as Routing > > Contexts ....OR.... > > > > ...The implementation should club all the Routing Contexts with the same > > Traffic Mode in a ASP Active message and then send the others in a > different > > ASP Active.... This is possible but it is quite and indirect > mechanism to > > send ASP Active messages.... > > > > > > Verbatim from the specs: > > > > For the Application Servers that the ASP can be successfully > > activated, the SGP or IPSP responds with one or more ASP Active Ack > > messages, including the associated Routing Context(s) and reflecting > > any Traffic Mode Type value present in the related ASP Active > > message. > > > > > > Does this mean that the Traffic mode in the ASPAC-Ack is the > traffic mode > of > > the sender of ASP-Ack ? > > >From the RFC text "...reflecting any Traffic Mode Type value present in > the > > related ASP Active message ", I interpret that the Traffic Mode received > in > > the ASPAC messages shall be sent back in ASPAC-Ack. > > And it is NOT really the Traffic mode of the sender of ASPAC-Ack. > > > > And that's the issue which I see in the Single Ended mode wherein the > sender > > of ASPAC will never come to know the Traffic Mode of the peer. > > > > shashank > > > > > > > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Monday, November 07, 2005 8:28 AM > > To: Prasad, Shashank S (Shashank) > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > > > RFC 3332 says: (Section 4.3.4.3 second paragraph) > > > > > > > > For the Application Servers that the ASP can be successfully > > > > activated, the SGP or IPSP responds with one or more ASP > Active Ack > > > > messages, including the associated Routing Context(s) and > reflecting > > > > any Traffic Mode Type value present in the related ASP Active > > > > message. The Routing Context parameter MUST be included > in the ASP > > > > Active Ack message(s) if the received ASP Active message > contained > > > > any Routing Contexts. Depending on any Traffic Mode Type request > in > > > > the ASP Active message, or local configuration data if > there is no > > > > request, the SGP moves the ASP to the correct ASP traffic state > > > > within the associated Application Server(s). Layer Management is > > > > informed with an M-ASP_Active indication. If the SGP or IPSP > receives > > > > any Data messages before an ASP Active message is > received, the SGP > > > > or IPSP MAY discard them. By sending an ASP Active Ack message, > the > > > > SGP or IPSP is now ready to receive and send traffic for the > related > > > > Routing Context(s). The ASP SHOULD NOT send Data or > SSNM messages > > > > for the related Routing Context(s) before receiving an ASP Active > Ack > > > > message, or it will risk message loss. > > > > > > > > I think that this is quite clear with regard to two things: > > > > > > > > The IPSP receiving the ASP Active message responds with regard to > > Traffic > > > > Mode in the same fashion as an SGP would. > > > > Prasad, Shashank S (Shashank) wrote: > > (Mon, 07 Nov 2005 05:17:59) > > > Brian, > > > I have only IPSPs in peer to peer communication. > > > There are no SGs. And therefore I would NOT consider SGPs or their > > > equivalent functionality. > > > > > > Ur answer tends me to believe that the Single Exchange is ONLY between > an > > > ASP and SGP. > > > Which is NOT correct. Please refer to Sec 5.5.1 and Sec 5.5.2 > in the RFC > > > 3332. > > > > > > I can always have SE between 2 IPSPs. It is upto the IPSPs to exchange > the > > > right parameters in the messages to indicate to each other about > > > loadsharing. > > > > > > > > > shashank > > > > > > > -- > > Brian F. G. Bidulock > > bidulock@openss7.org > > http://www.openss7.org/ > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 08:21:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6we-0000dg-ER; Mon, 07 Nov 2005 08:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6wc-0000db-Td for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 08:21:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09105 for ; Mon, 7 Nov 2005 08:21:28 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[3D8Pj5hdj9NrTMz6+VOFNmfadn7JPHzo]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ7CD-0003P2-Jf for sigtran@ietf.org; Mon, 07 Nov 2005 08:38:03 -0500 Received: from ns.pigworks.openss7.net (IDENT:b+edNfwMcZCIjmldno40ZYktGTcJG275@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA7DLlc30823; Mon, 7 Nov 2005 06:21:47 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA7DLlm17314; Mon, 7 Nov 2005 06:21:47 -0700 Date: Mon, 7 Nov 2005 06:21:47 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Message-ID: <20051107062147.A17231@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D210FB6887@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from asveren@ulticom.com on Mon, Nov 07, 2005 at 07:54:58AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: 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 Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, The problem is that an SGP (intentionally) neither has an AS, nor does it have a traffic mode. This is the same for the SGPF in the SE model. If you want to change the model, call it something different: how about SG-SG? ;) --brian Tolga Asveren wrote: (Mon, 07 Nov 2005 07:54:58) --X--snip--X-- > [TOLGA]I agree with Shashanks point here. IMO, we have an unnecessary > costraint in -SE-IPSP mode. I don't see any problem why using Traffic Mode > in both directions should create a problem. Forcing people to use DE-IPSP > mode -which is both optional and IMO more importantt han that not a really > peer-to-peer model- to set traffic modes in both directions is anot a > solution. --X--snip--X-- -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 09:20:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ7qt-00038w-BP; Mon, 07 Nov 2005 09:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ7qr-00038J-Nt for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 09:20:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12193 for ; Mon, 7 Nov 2005 09:19:34 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ86O-0004vI-VK for sigtran@ietf.org; Mon, 07 Nov 2005 09:36:10 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA7EJdhb008922 for ; Mon, 7 Nov 2005 09:19:40 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Mon, 7 Nov 2005 09:01:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051107062147.A17231@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, November 07, 2005 8:22 AM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Tolga, > > The problem is that an SGP (intentionally) neither has an AS, nor does > it have a traffic mode. This is the same for the SGPF in the SE model. > If you want to change the model, call it something different: how about > SG-SG? ;) [TOLGA]I belive the main reason why we have different opinions about this issue is because you think the logic in SE-IPSP as a SGPF whereas I would call it IPSPF -OTOH I totally would agree with you that it makes sense to speak of SGPF and ASPF in IPSP for DE-model-. It is true that the messages exchanged to bring the entities up and ready for message exchange are the same for SE-IPSP and SGP/ASP cases -mainly for the sake of reusing existing message codes- but there is a fundamental difference between two models: with SE-IPSP model, we have two different application logic processing entities on each end, which may have different traffic mode attributes. It sounds reasonable to me to have a mechanism to set both of those values with Traffic Mode parameter. For SG-SG, yes it could be nice indeed ;-) > > --brian > > Tolga Asveren wrote: (Mon, 07 Nov 2005 07:54:58) > > --X--snip--X-- > > > [TOLGA]I agree with Shashanks point here. IMO, we have an unnecessary > > costraint in -SE-IPSP mode. I don't see any problem why using > Traffic Mode > > in both directions should create a problem. Forcing people to > use DE-IPSP > > mode -which is both optional and IMO more importantt han that > not a really > > peer-to-peer model- to set traffic modes in both directions is anot a > > solution. > > --X--snip--X-- > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 09:25:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ7wH-00040V-9b; Mon, 07 Nov 2005 09:25:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ7wF-00040P-7M for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 09:25:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12428 for ; Mon, 7 Nov 2005 09:25:08 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ8Br-00052r-PS for sigtran@ietf.org; Mon, 07 Nov 2005 09:41:44 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA7EPNA5009511 for ; Mon, 7 Nov 2005 09:25:25 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Mon, 7 Nov 2005 09:07:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB6883@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Monday, November 07, 2005 4:56 AM > To: sigtran@ietf.org > Cc: 'Tolga Asveren' > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Tolga, > I picked up an old discussion thread that I had with u. > > What specifically did u mean, when u said - implementation dependent ? > Did u mean local configuration ? [TOLGA]Not really. In your example, it was the M3UA-user which was performing loadsharing, i.e. deciding to use IPSP2 or IPSP3. So, loadsharing will be done based on an implementation dependent mechanism in M3UA-User, it has nothhing to do with M3UA itself. > > And what did u mean by Traffic Type ? > Did u mean that IPSP1 can send ASPAC to the 2 IPSPs with Traffic Type as > Loadshared ? > If YES, then this would really not help because IPSP2 and IPSP3 > (illustrated > below) are different entities by themselves. [TOLGA]I was referring to type of traffic, e.g. SCCP class1, 800-number lookup query etc.. The characteristics of traffic type would determine the implementation dependent message routing mechanims in M3UA-User. > > > > shashank > > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Friday, November 04, 2005 8:51 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > This is implementation/traffic type dependent and is not something > standardized by M3UA. > > > -----Original Message----- > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > Sent: Friday, November 04, 2005 10:28 AM > > To: 'Tolga Asveren'; sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Thanx Tolga. U are right in understanding my question. > > > > Followup Question: > > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > > NodeB, if the traffic to IPSP1 is > > to be sent via IPSP2 or IPSP3 ? > > > > > > shashank > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Friday, November 04, 2005 8:13 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > As far as I understand your question: > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > for this RK > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > mode. You are > > wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3. > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > IPSP1. IPSP2 > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a > > single source is distrubuted to multiple peers. > > > > Tolga > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Friday, November 04, 2005 9:48 AM > > > To: 'sigtran@ietf.org' > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Hi, > > > I had a specific question related to a specific scenario > explained below > > > (Single Exchange scenario) > > > > > > NodeA supports 1 PS with 1 IPSP > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > There are two associations between NodeA and NodeB. > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > on NodeB, > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > that IPSP2 and > > > IPSP3, > > > serving a loadshared PS2, are essentially telling NodeA to > > > loadshare all the > > > traffic > > > for PS2, between IPSP2 and IPSP3. > > > > > > The above concepts are also illustrated below....(I have purposefully > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > > | | | > > > |<-----ASP Up------------| | > > > |-------ASP Up Ack------>| (Assoc #1) | > > > | | | > > > | | | > > > |<--------------------ASP Up------------------------| > > (Assoc #2) > > > |----------------------------ASP Up Ack------------>| > > > | | | > > > | | | > > > | | | > > > |<--ASP Active(Ldshr)----| | > > > |------ASP Active Ack--->| | > > > | | | > > > | | | > > > | | | > > > |<--------------------ASP Active(Ldshr)-------------| > > > |----------------------------ASP Up Ack------------>| > > > | | | > > > | | | > > > |---NOTIFY(AS-ACTIVE)--->| | > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > | | | > > > > > > > > > > > > Questions: > > > Assuming a single exchange scenario, would the traffic towards > > > PS1 on NodeA, > > > > > > be also loadshared across 2 associations ? > > > > > > I thought it would and hence another follow-up question: > > > It looks like a loadshared peer (NodeB in our case) with > > multiple IPSPs, > > > is putting a constraint on the NodeA, to ALSO be ready to > > receive data on > > > multiple associations and possibly loadshared. Is this a fair > > > understanding > > > ? > > > > > > > > > shashank > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 09:37:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ87r-00064m-Jq; Mon, 07 Nov 2005 09:37:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ87p-00064L-G5 for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 09:37:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13165 for ; Mon, 7 Nov 2005 09:37:06 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ8NR-0005QK-UO for sigtran@ietf.org; Mon, 07 Nov 2005 09:53:42 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA7EbNOB026817; Mon, 7 Nov 2005 08:37:25 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Nov 2005 20:07:23 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB688B@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Mon, 7 Nov 2005 20:07:22 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: "'bidulock@openss7.org'" X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi Brian, Not really trying to "mogrify" Brian. I am ONLY trying to discuss some changes which shall greatly help to take advantage of the SE mode in the IPSP-IPSP (Point to Point) scenario. Except for the Traffic Mode, there is nothing that stops IPSPs to talk to each other using SE mode in a point to point fashion. One can use the local configuration of Traffic Modes and start to work in the SE mode. However, we should take the advantage of ASPAC and ASPAC-Ack messages exchanges to set the Traffic Modes (overriding the local configuration). A change in concepts will set the IPSPs talking to each other in the SE mode. That's what Tolga and I were discussing with :) I cannot expect the peer IPSPs to always support an optional DE mode.. Also, I did NOT quite understand why one would like an IPSP behave like an SGP. shashank -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Monday, November 07, 2005 6:17 PM To: Prasad, Shashank S (Shashank) Cc: sigtran@ietf.org Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Shashank, I don't think that you understand SE mode. Take a look back in the mail archives for long discussions of the differences between SE and DE modes. SE mode uses the same semantics as an ASP/SGP connection, where one IPSP acts like an ASP in the exchange and the other acts like an SGP. I find it strange that you refuse to use DE mode, yet seem to want to mogrify SE into DE. --brian Prasad, Shashank S (Shashank) wrote: (Mon, 07 Nov 2005 17:39:22) > Brian, > > Replies embedded. > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, November 07, 2005 4:24 PM > To: Prasad, Shashank S (Shashank) > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > The RFC is clear: the TM in the ASP Active Ack is the value that was sent > in the ASP Active. > > In SE mode, the peer does not have a traffic mode. It is acting like an > SGP. > Again, see A.2.2. > > [SHASHANK] U are putting a lot of constraints by this statement. Ur > statement means that IPSP-IPSP cannot have a SE mode. This is NOT really > correct. Here I am trying to make some minor improvements in the M3UA specs > so that IPSPs can also use the SE effectively. > > > If you want both IPSPs to each have an AS an traffic mode, use DE instead > of SE. > > [SHASHANK] This is a big contraint and not acceptable :) > IPSPs can surely use SE mode too between themselves (IPSPs). Moreover DE is > optional. > > > --brian > > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 09:47:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8H7-00088K-7o; Mon, 07 Nov 2005 09:47:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8H5-00088F-Ci for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 09:47:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13687 for ; Mon, 7 Nov 2005 09:46:40 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ8Wh-0005gq-SP for sigtran@ietf.org; Mon, 07 Nov 2005 10:03:16 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA7El2qN005389; Mon, 7 Nov 2005 08:47:03 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Nov 2005 20:17:01 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB688D@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Mon, 7 Nov 2005 20:17:00 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Thanx. Got it. shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Monday, November 07, 2005 7:37 PM To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Shashank, > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Monday, November 07, 2005 4:56 AM > To: sigtran@ietf.org > Cc: 'Tolga Asveren' > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Tolga, > I picked up an old discussion thread that I had with u. > > What specifically did u mean, when u said - implementation dependent ? > Did u mean local configuration ? [TOLGA]Not really. In your example, it was the M3UA-user which was performing loadsharing, i.e. deciding to use IPSP2 or IPSP3. So, loadsharing will be done based on an implementation dependent mechanism in M3UA-User, it has nothhing to do with M3UA itself. > > And what did u mean by Traffic Type ? > Did u mean that IPSP1 can send ASPAC to the 2 IPSPs with Traffic Type as > Loadshared ? > If YES, then this would really not help because IPSP2 and IPSP3 > (illustrated > below) are different entities by themselves. [TOLGA]I was referring to type of traffic, e.g. SCCP class1, 800-number lookup query etc.. The characteristics of traffic type would determine the implementation dependent message routing mechanims in M3UA-User. > > > > shashank > > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Friday, November 04, 2005 8:51 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > This is implementation/traffic type dependent and is not something > standardized by M3UA. > > > -----Original Message----- > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > Sent: Friday, November 04, 2005 10:28 AM > > To: 'Tolga Asveren'; sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Thanx Tolga. U are right in understanding my question. > > > > Followup Question: > > Since IPSP2 and IPSP3 are serving the same AS, what would determine at > > NodeB, if the traffic to IPSP1 is > > to be sent via IPSP2 or IPSP3 ? > > > > > > shashank > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Friday, November 04, 2005 8:13 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > As far as I understand your question: > > > > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC > > for this RK > > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing > > mode. You are > > wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3. > > > > Yes, it can, but I wouldn't call it traffic being loadshared to > > IPSP1. IPSP2 > > and IPSP3 are not the same entities. OTOH it makes sense to speak of > > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a > > single source is distrubuted to multiple peers. > > > > Tolga > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Friday, November 04, 2005 9:48 AM > > > To: 'sigtran@ietf.org' > > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Hi, > > > I had a specific question related to a specific scenario > explained below > > > (Single Exchange scenario) > > > > > > NodeA supports 1 PS with 1 IPSP > > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode. > > > > > > > > > There are two associations between NodeA and NodeB. > > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB). > > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB). > > > > > > The IPSP2 and IPSP3, which are serving loadshared for the PS2 > on NodeB, > > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means > > > that IPSP2 and > > > IPSP3, > > > serving a loadshared PS2, are essentially telling NodeA to > > > loadshare all the > > > traffic > > > for PS2, between IPSP2 and IPSP3. > > > > > > The above concepts are also illustrated below....(I have purposefully > > > avoided AS-ACTIVE notification) > > > > > > > > > > > > NodeA <------------NodeB------------> > > > > > > PS1-IPSP1 PS2-IPSP2 PS2-IPSP3 > > > | | | > > > |<-----ASP Up------------| | > > > |-------ASP Up Ack------>| (Assoc #1) | > > > | | | > > > | | | > > > |<--------------------ASP Up------------------------| > > (Assoc #2) > > > |----------------------------ASP Up Ack------------>| > > > | | | > > > | | | > > > | | | > > > |<--ASP Active(Ldshr)----| | > > > |------ASP Active Ack--->| | > > > | | | > > > | | | > > > | | | > > > |<--------------------ASP Active(Ldshr)-------------| > > > |----------------------------ASP Up Ack------------>| > > > | | | > > > | | | > > > |---NOTIFY(AS-ACTIVE)--->| | > > > |--------------------------NOTIFY(AS-ACTIVE)------->| > > > | | | > > > > > > > > > > > > Questions: > > > Assuming a single exchange scenario, would the traffic towards > > > PS1 on NodeA, > > > > > > be also loadshared across 2 associations ? > > > > > > I thought it would and hence another follow-up question: > > > It looks like a loadshared peer (NodeB in our case) with > > multiple IPSPs, > > > is putting a constraint on the NodeA, to ALSO be ready to > > receive data on > > > multiple associations and possibly loadshared. Is this a fair > > > understanding > > > ? > > > > > > > > > shashank > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ 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 Nov 07 10:06:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8a9-0004uu-8R; Mon, 07 Nov 2005 10:06:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8a8-0004uP-6U for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 10:06:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15049 for ; Mon, 7 Nov 2005 10:06:23 -0500 (EST) Received: from web25906.mail.ukl.yahoo.com ([217.12.10.204]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZ8pU-0006KW-VO for sigtran@ietf.org; Mon, 07 Nov 2005 10:22:57 -0500 Received: (qmail 53703 invoked by uid 60001); 7 Nov 2005 15:06:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.es; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DB4APPcteExYPLxbRtPEDwXrBndBb09dpu514DhyMhQ9jm78Z7thkCZkZcWyvk7vX9A2FFz3HQExI/Q/mwDXsUz0iopSQ9K7fx/TyjQ+C1ixNV24OxGS9S/IqZExotr7+IGH02R2tzZ+8VPCRAgk+sKfcp1tfXin3HuETvaSvIc= ; Message-ID: <20051107150622.53701.qmail@web25906.mail.ukl.yahoo.com> Received: from [195.235.92.108] by web25906.mail.ukl.yahoo.com via HTTP; Mon, 07 Nov 2005 16:06:21 CET Date: Mon, 7 Nov 2005 16:06:21 +0100 (CET) From: David Santos To: sigtran@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA15049 Subject: [Sigtran] M3UA - AS-PENDING with IPSP-IPSP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi, we have the following configuration depicted below. It=92s an IPSP-IPSP communication. We have AS1 served by ASP1. ASP2 and ASP3 are in the same Application Server (AS2). Every ASP is operating in Override traffic mode, where ASP1 and ASP2 are configured to be in the ASP-ACTIVE state and ASP3 is acting as backup. ________ ________ ________=20 | | | | | | | AS1 | | AS2 | | AS2 | | PC =3D X | | PC =3D Y | | PC =3D Y | |________| |________| |________| | | | =20 ___|____ ___|____ ___|____=20 | | | | | | | ASP1 | | ASP2 | | ASP3 | | IP@1 | | IP@2 | | IP@3 | |Override| |Override| |Override| |(Active)| |(Active)| |(Backup)| |________| |________| |________| | | | =20 |__________________|____________| =20 When ASP2 turns Inactive, is the following scenario correct? Or shouldn=92t ASP2 send AS-PENDING? Which would be the correct sequence? Could be correct that just the ASP receiving ASP-Inactive sends AS-PENDING messages as a SGP would do? ASP1 ASP2 ASP3 | | | |-------------------ASP Active----------------->| |<----------------ASP Active Ack----------------| | | | |-------ASP Active------>| | |<------ASP Active Ack---| | | | | |----------------NTFY(Alt ASP-Act)------------> | | | |=20 |<-----ASP Inactive------| | |----ASP Inactive Ack--->| | | | | |----NTFY(AS-PENDING)--->| | |----------------NTFY(AS-PENDING)-------------->| | | | |<----NTFY(AS-PENDING)---| <=3D=3D Is this correct? | =20 | | | ... ... ... ... ... ... ... ... ... Thank you all. =09 =09 =09 ______________________________________________=20 Renovamos el Correo Yahoo!=20 Nuevos servicios, m=E1s seguridad=20 http://correo.yahoo.es _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 10:27:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8uD-0000gq-RL; Mon, 07 Nov 2005 10:27:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8uD-0000gl-6A for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 10:27:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16445 for ; Mon, 7 Nov 2005 10:27:08 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ99p-0006y9-4N for sigtran@ietf.org; Mon, 07 Nov 2005 10:43:42 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA7FRB8n016972 for ; Mon, 7 Nov 2005 10:27:13 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA - AS-PENDING with IPSP-IPSP Date: Mon, 7 Nov 2005 10:09:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051107150622.53701.qmail@web25906.mail.ukl.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by colby.ulticom.com id jA7FRB8n016972 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org David, > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of David Santos > Sent: Monday, November 07, 2005 10:06 AM > To: sigtran@ietf.org > Subject: [Sigtran] M3UA - AS-PENDING with IPSP-IPSP > > > Hi, we have the following configuration depicted > below. It=92s an IPSP-IPSP communication. We have AS1 > served by ASP1. ASP2 and ASP3 are in the same > Application Server (AS2). Every ASP is operating in > Override traffic mode, where ASP1 and ASP2 are > configured to be in the ASP-ACTIVE state and ASP3 is > acting as backup. > > ________ ________ ________ > | | | | | | > | AS1 | | AS2 | | AS2 | > | PC =3D X | | PC =3D Y | | PC =3D Y | > |________| |________| |________| > | | | > ___|____ ___|____ ___|____ > | | | | | | > | ASP1 | | ASP2 | | ASP3 | > | IP@1 | | IP@2 | | IP@3 | > |Override| |Override| |Override| > |(Active)| |(Active)| |(Backup)| > |________| |________| |________| > | | | > |__________________|____________| > > When ASP2 turns Inactive, is the following scenario > correct? Or shouldn=92t ASP2 send AS-PENDING? Which > would be the correct sequence? Could be correct that > just the ASP receiving ASP-Inactive sends AS-PENDING > messages as a SGP would do? > > > ASP1 ASP2 ASP3 > | | | > |-------------------ASP Active----------------->| > |<----------------ASP Active Ack----------------| > | | | > |-------ASP Active------>| | > |<------ASP Active Ack---| | > | | | > |----------------NTFY(Alt ASP-Act)------------> | > | | | > |<-----ASP Inactive------| | > |----ASP Inactive Ack--->| | > | | | > |----NTFY(AS-PENDING)--->| | > |----------------NTFY(AS-PENDING)-------------->| > | | | > |<----NTFY(AS-PENDING)---| <=3D=3D Is this correct? | > | | | [TOLGA]I wouldn't use a very strong language like "correct/incorrect" considering the advisory nature of NTFYs but for the scenario you describ= ed, it does not make sense to me IPSP2 to send NTFY(AS-PENDING), because it w= as IPSP2 which has issued the ASPIAC -probably due to an operator activity-. OTOH, sending it wouldn't be wrong either, it probably would trigger ASPA= C to be sent from IPSP1 to IPSP2 and IPSP2 wouldn't reply back ASPAC-ACK -i= t probably would send ERR(ManagementBlocking)- > ... ... ... > ... ... ... > ... ... ... > > > Thank you all. > > > > > > ______________________________________________ > Renovamos el Correo Yahoo! > Nuevos servicios, m=E1s seguridad > http://correo.yahoo.es > > _______________________________________________ > 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 Nov 07 13:42:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBx7-00046p-VY; Mon, 07 Nov 2005 13:42:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBx5-00046S-Lu for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 13:42:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28426 for ; Mon, 7 Nov 2005 13:42:17 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[vNFo7D/6bHF97GydnqbIKPAIiOrW4ZR0]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCCj-0004GY-7a for sigtran@ietf.org; Mon, 07 Nov 2005 13:58:54 -0500 Received: from ns.pigworks.openss7.net (IDENT:Kl77P7X28erjdqVhtzTywrkbLddT+WZH@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA7Igdc03754; Mon, 7 Nov 2005 11:42:39 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA7Igcu20267; Mon, 7 Nov 2005 11:42:38 -0700 Date: Mon, 7 Nov 2005 11:42:38 -0700 From: "Brian F. G. Bidulock" To: "Prasad, Shashank S (Shashank)" Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Message-ID: <20051107114238.B20016@openss7.org> Mail-Followup-To: "Prasad, Shashank S (Shashank)" , sigtran@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D210FB688B@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB688B@ii0015exch002u.iprc.lucent.com>; from ssprasad@lucent.com on Mon, Nov 07, 2005 at 08:07:22PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Prasad,, Prasad, Shashank S (Shashank) wrote: (Mon, 07 Nov 2005 20:07:22) > Hi Brian, > Not really trying to "mogrify" Brian. I am ONLY trying to discuss some > changes which shall greatly help to take advantage of the SE mode in the > IPSP-IPSP (Point to Point) scenario. What would greatly help IPSP would be an SG-SG IPSP instead of SE or DE. There were long ladders of discussion at LC on RFC 3332 and Tolga even wrote a draft. I would far rather discuss the SG-SG model for IPSP rather than trying to make "enhancements" to SE or DE models, which are inferior. --brian > > Except for the Traffic Mode, there is nothing that stops IPSPs to talk to > each other using SE mode in a point to point fashion. One can use the local > configuration of Traffic Modes and start to work in the SE mode. > > However, we should take the advantage of ASPAC and ASPAC-Ack messages > exchanges to set the Traffic Modes (overriding the local configuration). A > change in concepts will set the IPSPs talking to each other in the SE mode. > > That's what Tolga and I were discussing with :) > I cannot expect the peer IPSPs to always support an optional DE mode.. > > Also, I did NOT quite understand why one would like an IPSP behave like an > SGP. > > shashank > > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, November 07, 2005 6:17 PM > To: Prasad, Shashank S (Shashank) > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > I don't think that you understand SE mode. Take a look back in the mail > archives for long discussions of the differences between SE and DE modes. > SE mode uses the same semantics as an ASP/SGP connection, where one IPSP > acts like an ASP in the exchange and the other acts like an SGP. > > I find it strange that you refuse to use DE mode, yet seem to want to > mogrify SE into DE. > > --brian > > Prasad, Shashank S (Shashank) wrote: (Mon, 07 Nov 2005 17:39:22) > > Brian, > > > > Replies embedded. > > > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Monday, November 07, 2005 4:24 PM > > To: Prasad, Shashank S (Shashank) > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > The RFC is clear: the TM in the ASP Active Ack is the value that was sent > > in the ASP Active. > > > > In SE mode, the peer does not have a traffic mode. It is acting like an > > SGP. > > Again, see A.2.2. > > > > [SHASHANK] U are putting a lot of constraints by this statement. Ur > > statement means that IPSP-IPSP cannot have a SE mode. This is NOT really > > correct. Here I am trying to make some minor improvements in the M3UA > specs > > so that IPSPs can also use the SE effectively. > > > > > > If you want both IPSPs to each have an AS an traffic mode, use DE instead > > of SE. > > > > [SHASHANK] This is a big contraint and not acceptable :) > > IPSPs can surely use SE mode too between themselves (IPSPs). Moreover DE > is > > optional. > > > > > > --brian > > > > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 13:56:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCA6-0007F0-0K; Mon, 07 Nov 2005 13:56:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZC9z-0007ET-Kh for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 13:56:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29309 for ; Mon, 7 Nov 2005 13:55:37 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[sGGizItNzzqYLjZenCHWTqm0Lt/hAc9Z]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCPT-0004fh-3c for sigtran@ietf.org; Mon, 07 Nov 2005 14:12:14 -0500 Received: from ns.pigworks.openss7.net (IDENT:jPArMPmTsMOJp0lvdStBO+C1TNkwUPL0@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA7Itoc04013; Mon, 7 Nov 2005 11:55:50 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA7Itn320351; Mon, 7 Nov 2005 11:55:49 -0700 Date: Mon, 7 Nov 2005 11:55:49 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Message-ID: <20051107115549.A20305@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051107062147.A17231@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 Mon, Nov 07, 2005 at 09:01:40AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, The SE model of RFC 3332 is SGPF/ASPF. Look back at "M3UA-v02 Last Call Comment: ASP States and SE or DE IPSP". You did not receive any support for your IPSPF model, even for rfc3332bis. --brian Tolga Asveren wrote: (Mon, 07 Nov 2005 09:01:40) > Brian, > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Monday, November 07, 2005 8:22 AM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Tolga, > > > > The problem is that an SGP (intentionally) neither has an AS, nor does > > it have a traffic mode. This is the same for the SGPF in the SE model. > > If you want to change the model, call it something different: how about > > SG-SG? ;) > [TOLGA]I belive the main reason why we have different opinions about this > issue is because you think the logic in SE-IPSP as a SGPF whereas I would > call it IPSPF -OTOH I totally would agree with you that it makes sense to > speak of SGPF and ASPF in IPSP for DE-model-. It is true that the messages > exchanged to bring the entities up and ready for message exchange are the > same for SE-IPSP and SGP/ASP cases -mainly for the sake of reusing existing > message codes- but there is a fundamental difference between two models: > with SE-IPSP model, we have two different application logic processing > entities on each end, which may have different traffic mode attributes. It > sounds reasonable to me to have a mechanism to set both of those values with > Traffic Mode parameter. > > For SG-SG, yes it could be nice indeed ;-) > > > > --brian > > > > Tolga Asveren wrote: (Mon, 07 Nov 2005 07:54:58) > > > > --X--snip--X-- > > > > > [TOLGA]I agree with Shashanks point here. IMO, we have an unnecessary > > > costraint in -SE-IPSP mode. I don't see any problem why using > > Traffic Mode > > > in both directions should create a problem. Forcing people to > > use DE-IPSP > > > mode -which is both optional and IMO more importantt han that > > not a really > > > peer-to-peer model- to set traffic modes in both directions is anot a > > > solution. > > > > --X--snip--X-- > > > > -- > > 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 Mon Nov 07 14:54:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZD4W-0006XD-37; Mon, 07 Nov 2005 14:54:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZD4U-0006Wu-Ma for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 14:54:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03861 for ; Mon, 7 Nov 2005 14:53:59 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZDK9-0006eg-KA for sigtran@ietf.org; Mon, 07 Nov 2005 15:10:38 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA7Js8vw013860 for ; Mon, 7 Nov 2005 14:54:10 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Mon, 7 Nov 2005 14:36:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051107115549.A20305@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Brian F. G. Bidulock > Sent: Monday, November 07, 2005 1:56 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Tolga, > > The SE model of RFC 3332 is SGPF/ASPF. > > Look back at "M3UA-v02 Last Call Comment: ASP States and SE or DE IPSP". > You did not receive any support for your IPSPF model, even for rfc3332bis. [TOLGA]If you look to " M3UAbis - consensus on comment resolution - Part 1&2" thread -which has happened later than the thread you mentioned ;-) -, you will see that everybody involved in the discussion "Valerie, you, myself and Javier" agreed to return to the original SE-IPSP model. The conclusion was to use the text proposed by Valerie. It seems the bis document is not updated accordingly. Ken, was there a technical objection for that change -actually I would call it reverting back to the original model- or is this just an oversight? Considering the way it is supposed to work, i.e. according to the text we had concensus on, we can't speak of exact SGPF semantics for SE-IPSP even from basic message exchange point of view, e.g. SGPF does not send ASPAC, can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both sides can send ASPAC/ASPAC-ACK and they don't send SSNM and they have a peer-to-peer relationship, not a client/server relationship. Regarding the issue we are discussing in this thread -being able to support traffic mode in both directions-I think it is a nice thing to have, because we have application logic at both sides, which may want to use different traffic . > > --brian > > > Tolga Asveren wrote: (Mon, 07 Nov 2005 09:01:40) > > Brian, > > > > > -----Original Message----- > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: Monday, November 07, 2005 8:22 AM > > > To: Tolga Asveren > > > Cc: sigtran@ietf.org > > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Tolga, > > > > > > The problem is that an SGP (intentionally) neither has an AS, nor does > > > it have a traffic mode. This is the same for the SGPF in the > SE model. > > > If you want to change the model, call it something different: > how about > > > SG-SG? ;) > > [TOLGA]I belive the main reason why we have different opinions > about this > > issue is because you think the logic in SE-IPSP as a SGPF > whereas I would > > call it IPSPF -OTOH I totally would agree with you that it > makes sense to > > speak of SGPF and ASPF in IPSP for DE-model-. It is true that > the messages > > exchanged to bring the entities up and ready for message > exchange are the > > same for SE-IPSP and SGP/ASP cases -mainly for the sake of > reusing existing > > message codes- but there is a fundamental difference between two models: > > with SE-IPSP model, we have two different application logic processing > > entities on each end, which may have different traffic mode > attributes. It > > sounds reasonable to me to have a mechanism to set both of > those values with > > Traffic Mode parameter. > > > > For SG-SG, yes it could be nice indeed ;-) > > > > > > --brian > > > > > > Tolga Asveren wrote: (Mon, 07 Nov 2005 07:54:58) > > > > > > --X--snip--X-- > > > > > > > [TOLGA]I agree with Shashanks point here. IMO, we have an > unnecessary > > > > costraint in -SE-IPSP mode. I don't see any problem why using > > > Traffic Mode > > > > in both directions should create a problem. Forcing people to > > > use DE-IPSP > > > > mode -which is both optional and IMO more importantt han that > > > not a really > > > > peer-to-peer model- to set traffic modes in both directions > is anot a > > > > solution. > > > > > > --X--snip--X-- > > > > > > -- > > > 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 > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 07 19:51:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHiQ-0002sQ-F0; Mon, 07 Nov 2005 19:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHiL-0002pY-6b for sigtran@megatron.ietf.org; Mon, 07 Nov 2005 19:51:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27347 for ; Mon, 7 Nov 2005 19:51:26 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[/Oxl38oph0OhLAv1ctgCb8FUOyEwv1nT]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZHy2-0000Oa-Kj for sigtran@ietf.org; Mon, 07 Nov 2005 20:08:07 -0500 Received: from ns.pigworks.openss7.net (IDENT:woSKnngHWIBSYanQqVIgn++R2SMz+k5g@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA80phc09888; Mon, 7 Nov 2005 17:51:43 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA80pha23293; Mon, 7 Nov 2005 17:51:43 -0700 Date: Mon, 7 Nov 2005 17:51:43 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Message-ID: <20051107175143.B23024@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051107115549.A20305@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 Mon, Nov 07, 2005 at 02:36:07PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Mon, 07 Nov 2005 14:36:07) --X--snip--X-- > [TOLGA]If you look to " M3UAbis - consensus on comment resolution - Part > 1&2" thread -which has happened later than the thread you mentioned ;-) -, > you will see that everybody involved in the discussion "Valerie, you, myself > and Javier" agreed to return to the original SE-IPSP model. The conclusion > was to use the text proposed by Valerie. It seems the bis document is not > updated accordingly. Ken, was there a technical objection for that > change -actually I would call it reverting back to the original model- or is > this just an oversight? Really? Did you mean in "M3UAbis - consensus on comment resolution" 23 Aug 2004 where Valerie says: IPSP-SE behaviour: The IPSP acting as the SGP must sends ASPAC-ack only when its side of the RK is ready. The IPSP acting as the ASP is responsible to retry the ASPAC until the remote peer is ready. When the IPSP acting as the SGP wants to stop application traffic from its side, it must send ASPIA-ack. Or did you mean where we agreed to back out of the v03 changes (which is what I think you are referring to with the IPSPF) and go back to the v02 description (which is the same as RFC 3332 and the SGPF/ASPF approach). --brian > > Considering the way it is supposed to work, i.e. according to the text we > had concensus on, we can't speak of exact SGPF semantics for SE-IPSP even > from basic message exchange point of view, e.g. SGPF does not send ASPAC, > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both sides can send > ASPAC/ASPAC-ACK and they don't send SSNM and they have a peer-to-peer > relationship, not a client/server relationship. See Valerie's description above. As I have mantained, it is clear that one IPSP acts in an SGP role and the other in an ASP role. > > Regarding the issue we are discussing in this thread -being able to support > traffic mode in both directions-I think it is a nice thing to have, because > we have application logic at both sides, which may want to use different > traffic . Again, the IPSP acting as an SGP in SE mode is not required to have a traffic mode. In the normal ASP/SGP exchange, the SGP does not have a traffic mode to place in the ASPAC Ack. Any traffic distribution towards the SGP is an SG-wide attribute and does not differ from AS to AS, nor ASP to ASP. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 08 02:35:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZO0w-0005XZ-Jr; Tue, 08 Nov 2005 02:35:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZO0u-0005XU-QS for sigtran@megatron.ietf.org; Tue, 08 Nov 2005 02:35:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17409 for ; Tue, 8 Nov 2005 02:35:02 -0500 (EST) Received: from web53807.mail.yahoo.com ([206.190.36.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZOGX-0002Kn-Ou for sigtran@ietf.org; Tue, 08 Nov 2005 02:51:46 -0500 Received: (qmail 92158 invoked by uid 60001); 8 Nov 2005 07:35:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=I2c2LG7L7pLRuEry5pMjC5S/biL3fW3nJSbRsSzq0gLCI4GNRc0ip2k5rd639nSL4h8HslasH0K+bgMFC42Zfl1NhaxRXr35HI+FoLVHgeY0BHhvFEDKwLkOheV+EiLP3jAJcAWFtujjP7A+gqXswAgGTcrfuI+Pbfo6VSVv5fU= ; Message-ID: <20051108073510.92156.qmail@web53807.mail.yahoo.com> Received: from [220.227.128.163] by web53807.mail.yahoo.com via HTTP; Mon, 07 Nov 2005 23:35:10 PST Date: Mon, 7 Nov 2005 23:35:10 -0800 (PST) From: Saraswati Bose To: bidulock@openss7.org, sigtran@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [Sigtran] RE: ASP configuration in AS X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0892662593==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0892662593== Content-Type: multipart/alternative; boundary="0-221723592-1131435310=:90701" Content-Transfer-Encoding: 8bit --0-221723592-1131435310=:90701 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian, The AS is uniquely identified by RK value. The multiple ASPs within the AS will have unique ASPID values. Suggest what conditions apply for the below. 1. Should NA when present in RK uniquely identify the AS and be same across the three ASPs? Or is the parameter specific to the ASPs? 2. The dynamic registration feature (registering ASPs within a AS) support apply to the AS or individual ASP? Means can we configure such that 1 ASP supports dynamic registration while other two don't. 3. The dynamic configuration (registering of ASP to a new AS) support apply to AS or individual ASP? 4. For traffic mode override can only ASP strictly stay in ACTIVE state? If true what error can be encoded in response to active request received from the other ASP when one ASP is already in active state? "unexpected message"/ "protocol error"? 5. How can we indicate to the peer SG the ASPs that belong to the particular AS? Is it the statically configured RK for the AS? But RK is exchanged during registration procedure only which is a optional procedure? 6. You said we may keep the NA +RC/IID combination same for multiple ASPs load sharing traffic. Do the same apply for override also? 7. Can we opt for multiple ASPs configured within AS with completely different set of routing parameters for both override/load share modes and yet successfully route traffic as per routing information set. --Saraswati __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-221723592-1131435310=:90701 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Brian,
 
The AS is uniquely identified by RK value.
The multiple ASPs within the AS will have unique ASPID values.
 
Suggest what conditions apply for the below.
 
1. Should NA  when present in RK uniquely identify the AS and be same across the three ASPs? Or is the parameter specific to the ASPs?
 
2. The dynamic registration feature (registering ASPs within a AS) support apply to the AS or individual ASP? Means can we configure such that 1 ASP supports dynamic registration while other two don't.
 
3. The dynamic configuration (registering of ASP to a new AS) support apply to AS or individual ASP?
 
4. For traffic mode override can only ASP strictly stay in ACTIVE state? If true what error can be encoded in response to active request received from the other ASP when one ASP is already in active state? "unexpected message"/ "protocol error"?
 
5. How can we indicate to the peer SG the ASPs that belong to the particular AS? Is it the statically configured RK for the AS? But RK is exchanged during registration procedure only which is a optional procedure?
 
6. You said we may keep the NA +RC/IID combination same for multiple ASPs load sharing traffic. Do the same apply for override also?
 
7. Can we opt for multiple ASPs configured within AS with completely different set of routing parameters for both override/load share modes and yet successfully route traffic as per routing information set.
 
--Saraswati

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-221723592-1131435310=:90701-- --===============0892662593== 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 --===============0892662593==-- From sigtran-bounces@ietf.org Tue Nov 08 04:00:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZPLY-0002HA-Ph; Tue, 08 Nov 2005 04:00:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZPLX-0002GO-5v for sigtran@megatron.ietf.org; Tue, 08 Nov 2005 04:00:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22517 for ; Tue, 8 Nov 2005 04:00:24 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[c2dwnF06y4M5/sz1nRNQQ+qsftk5xL0z]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZPbI-00050S-0n for sigtran@ietf.org; Tue, 08 Nov 2005 04:17:09 -0500 Received: from ns.pigworks.openss7.net (IDENT:GMaj64dvrHc+zfHQfkVSwg6PO43t9p7b@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA890jc18628; Tue, 8 Nov 2005 02:00:45 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA890j428979; Tue, 8 Nov 2005 02:00:45 -0700 Date: Tue, 8 Nov 2005 02:00:44 -0700 From: "Brian F. G. Bidulock" To: Saraswati Bose Message-ID: <20051108020044.A28556@openss7.org> Mail-Followup-To: Saraswati Bose , sigtran@ietf.org References: <20051108073510.92156.qmail@web53807.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20051108073510.92156.qmail@web53807.mail.yahoo.com>; from saraswatibose@yahoo.com on Mon, Nov 07, 2005 at 11:35:10PM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sigtran@ietf.org Subject: [Sigtran] Re: ASP configuration in AS X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Saraswati, Saraswati Bose wrote: (Mon, 07 Nov 2005 23:35:10) > 1. Should NA when present in RK uniquely identify the AS and be same > across the three ASPs? Or is the parameter specific to the ASPs? NA is agreed upon between SGP and ASP. Only necessary when the SGP supports more than one. Typically the same assignment for each SGP in an SG. Could be managed to be the same across more than one SG or across an entire administrative domain. > 2. The dynamic registration feature (registering ASPs within a AS) > support apply to the AS or individual ASP? Means can we configure such > that 1 ASP supports dynamic registration while other two don't. Dynamic regsitration by an ASP is optional. You can provision the ASP with an RC value (agreed upon between ASP and SGP) instead. > 3. The dynamic configuration (registering of ASP to a new AS) support > apply to AS or individual ASP? I would say it applies to an SGP. The ASP can regsiter or not as it choses regardless of whether the ASP supports it or not. > 4. For traffic mode override can only ASP strictly stay in ACTIVE > state? If true what error can be encoded in response to active request > received from the other ASP when one ASP is already in active state? > "unexpected message"/ "protocol error"? The activating ASP takes over from the other. SGP sends NTFY(alternate ASP active for AS). > 5. How can we indicate to the peer SG the ASPs that belong to the > particular AS? Is it the statically configured RK for the AS? But RK > is exchanged during registration procedure only which is a optional > procedure? An RK is provisioned at the SGP if the ASP does not register. > 6. You said we may keep the NA +RC/IID combination same for multiple > ASPs load sharing traffic. Do the same apply for override also? Yes. > 7. Can we opt for multiple ASPs configured within AS with completely > different set of routing parameters for both override/load share modes > and yet successfully route traffic as per routing information set. I don't know what you mean by that, but I think the answer is no. Much of this information is in the RFC: have you read it? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 08 06:24:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZRah-0003Hm-AY; Tue, 08 Nov 2005 06:24:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZRaf-0003H5-Oi for sigtran@megatron.ietf.org; Tue, 08 Nov 2005 06:24:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29495 for ; Tue, 8 Nov 2005 06:24:11 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[UYSZNqYxVQtoXC+rQfwfsayVbNtp8Ons]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZRqM-00009x-7E for sigtran@ietf.org; Tue, 08 Nov 2005 06:40:57 -0500 Received: from ns.pigworks.openss7.net (IDENT:pWysdA1ZNQ1ZjrWmfeOjfmxJscIyG2kG@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA8BOSc21874; Tue, 8 Nov 2005 04:24:28 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA8BORl30871; Tue, 8 Nov 2005 04:24:27 -0700 Date: Tue, 8 Nov 2005 04:24:27 -0700 From: "Brian F. G. Bidulock" To: Saraswati Bose Message-ID: <20051108042427.A30853@openss7.org> Mail-Followup-To: Saraswati Bose , sigtran@ietf.org References: <20051108020044.A28556@openss7.org> <20051108093524.5929.qmail@web53802.mail.yahoo.com> 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: <20051108093524.5929.qmail@web53802.mail.yahoo.com>; from saraswatibose@yahoo.com on Tue, Nov 08, 2005 at 01:35:24AM -0800 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 jA8BOSc21874 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org Subject: [Sigtran] Re: ASP configuration in AS X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Saraswati, I'm sorry, I still don't understand the question. --brian On Tue, 08 Nov 2005, Saraswati Bose wrote: >=20 > Hi brian, >=20 >=20 >=20 > U mean to say irrespective of the AS that multiple ASPs serve t= he > registration procedure is specific to ASP-SG just like the UP/ACTI= VE > procedures and not AS_SG, right... >=20 >=20 >=20 > Suppose I have one AS with 3 ASPs serving it. These three ASPs a= re > communicating with the peer end SG. >=20 >=20 >=20 > When multiple ASPs serve a particular AS then is there any paramete= rs > that is manadtory to be kept common to allow traffic flow from the = SG > in case of override or load share traffic? >=20 >=20 > --Saraswati >=20 --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 08 08:52:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZTuB-0004Ad-Jo; Tue, 08 Nov 2005 08:52:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZTuA-0004AW-Hb for sigtran@megatron.ietf.org; Tue, 08 Nov 2005 08:52:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07128 for ; Tue, 8 Nov 2005 08:52:27 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZU9z-0004W7-7B for sigtran@ietf.org; Tue, 08 Nov 2005 09:09:15 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA8DqaEU013549 for ; Tue, 8 Nov 2005 08:52:38 -0500 (EST) From: "Tolga Asveren" To: Date: Tue, 8 Nov 2005 08:34:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051107175143.B23024@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Subject: [Sigtran] SE-IPSP definition X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, -changed the subject of the thread- Ken, I re-checked and current bis document seems to be updated partially (4.3 has the definition I copy/pasted below -which is fine-, OTOH still there is text mentioning about C-IPSP, D-IPSP for SE-model. The idea probably was to assign roles to IPSPS per "transaction", i.e. a message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I believe the concept of "client" and "server" can be misleading because it can be considered as one IPSP always playing client or server role while communicating with a certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than clarify. Brian, more comments below. Tolga > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Brian F. G. Bidulock > Sent: Monday, November 07, 2005 7:52 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Tolga, > > Tolga Asveren wrote: > (Mon, 07 Nov 2005 14:36:07) > > --X--snip--X-- > > > [TOLGA]If you look to " M3UAbis - consensus on comment resolution - Part > > 1&2" thread -which has happened later than the thread you > mentioned ;-) -, > > you will see that everybody involved in the discussion > "Valerie, you, myself > > and Javier" agreed to return to the original SE-IPSP model. The > conclusion > > was to use the text proposed by Valerie. It seems the bis > document is not > > updated accordingly. Ken, was there a technical objection for that > > change -actually I would call it reverting back to the original > model- or is > > this just an oversight? > > Really? Did you mean in "M3UAbis - consensus on comment > resolution" 23 Aug 2004 > where Valerie says: > > IPSP-SE behaviour: > The IPSP acting as the SGP must sends ASPAC-ack only when its > side of the RK is > ready. The IPSP acting as the ASP is responsible to retry the > ASPAC until the > remote peer is ready. > When the IPSP acting as the SGP wants to stop application > traffic from its side, > it must send ASPIA-ack. [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - consensus on comment resoluti on-Part 1&2" 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM or ASPSM messages is needed to change the IPSP state. This means that a set of request from one end and acknowledge from the other will be enough. The RK must define both sides of the traffic flow. Each exchange of ASPTM or ASPSM messages can be initiated by either IPSP. For this exchange, the initiating IPSP follows the procedures described in section 4.3.1. The above is the original concept we defined for SE-IPSP mode. There are no predefined client/server relationship, a pure peer-to-peer relationship. > > Or did you mean where we agreed to back out of the v03 changes > (which is what > I think you are referring to with the IPSPF) and go back to the > v02 description > (which is the same as RFC 3332 and the SGPF/ASPF approach). [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As long as the problem is how you and I name it, there is no problem from specification point of view but I would call it IPSPF because it has a different machine than SGPF and ASPF and does not send/receive messages. I believe you use the term SGPF in the context of a "transaction" not inthe context of the overall realtionship between two peer IPSPs. > > --brian > > > > > Considering the way it is supposed to work, i.e. according to > the text we > > had concensus on, we can't speak of exact SGPF semantics for > SE-IPSP even > > from basic message exchange point of view, e.g. SGPF does not > send ASPAC, > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > sides can send > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a peer-to-peer > > relationship, not a client/server relationship. > > See Valerie's description above. As I have mantained, it is > clear that one IPSP > acts in an SGP role and the other in an ASP role. > > > > > Regarding the issue we are discussing in this thread -being > able to support > > traffic mode in both directions-I think it is a nice thing to > have, because > > we have application logic at both sides, which may want to use different > > traffic . > > Again, the IPSP acting as an SGP in SE mode is not required to > have a traffic > mode. > > In the normal ASP/SGP exchange, the SGP does not have a traffic > mode to place in > the ASPAC Ack. Any traffic distribution towards the SGP is an > SG-wide attribute > and does not differ from AS to AS, nor ASP to ASP. > > --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 > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 08 09:07:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZU8Y-0007jI-5R; Tue, 08 Nov 2005 09:07:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZU8X-0007j7-7E for sigtran@megatron.ietf.org; Tue, 08 Nov 2005 09:07:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07822 for ; Tue, 8 Nov 2005 09:07:18 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZUOM-0004r6-2H for sigtran@ietf.org; Tue, 08 Nov 2005 09:24:06 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA8E7Qb9015313 for ; Tue, 8 Nov 2005 09:07:27 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Tue, 8 Nov 2005 08:49:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051107175143.B23024@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, [..snip..] > > Regarding the issue we are discussing in this thread -being > able to support > > traffic mode in both directions-I think it is a nice thing to > have, because > > we have application logic at both sides, which may want to use different > > traffic . > > Again, the IPSP acting as an SGP in SE mode is not required to > have a traffic > mode. > > In the normal ASP/SGP exchange, the SGP does not have a traffic > mode to place in > the ASPAC Ack. Any traffic distribution towards the SGP is an > SG-wide attribute > and does not differ from AS to AS, nor ASP to ASP. [TOLGA]I believe we have another one of those "rare" situations where neither you nor I can convince the other one ;-) I think the options and supporting arguments are as follows: a)We don't need traffic mode bothways for SE-IPSP, because one of SE-IPSPs is mimicing a SGP and SGPs do not have traffic mode. b)We need traffic mode bothways, because both sides have application logic, which can have different trafic mode characteristics. (Shashank's position) I subscribe to b) and as far as I understand you support a). I think we need to hear more from other people about this issue so that we can reach a conclusion. Thanks, Tolga _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 08 09:31:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZUVn-0004kf-5B; Tue, 08 Nov 2005 09:31:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZUVl-0004k7-IM for sigtran@megatron.ietf.org; Tue, 08 Nov 2005 09:31:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08843 for ; Tue, 8 Nov 2005 09:31:17 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZUlY-0005Om-Io for sigtran@ietf.org; Tue, 08 Nov 2005 09:48:06 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA8EVKlQ017969 for ; Tue, 8 Nov 2005 09:31:24 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Tue, 8 Nov 2005 09:13:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org A few typo scorrected below. > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Tuesday, November 08, 2005 8:35 AM > To: sigtran@ietf.org > Subject: [Sigtran] SE-IPSP definition > > > Brian, > > -changed the subject of the thread- > > Ken, I re-checked and current bis document seems to be updated partially > (4.3 has the definition I copy/pasted below -which is fine-, OTOH still > there is text mentioning about C-IPSP, D-IPSP for SE-model. The idea > probably was to assign roles to IPSPS per "transaction", i.e. a > message pair > like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I believe the concept > of "client" > and "server" can be misleading because it can be considered as one IPSP > always playing client or server role while communicating with a > certain peer > IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than clarify. > > Brian, more comments below. > > Tolga > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Brian F. G. Bidulock > > Sent: Monday, November 07, 2005 7:52 PM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Tolga, > > > > Tolga Asveren wrote: > > (Mon, 07 Nov 2005 14:36:07) > > > > --X--snip--X-- > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > resolution - Part > > > 1&2" thread -which has happened later than the thread you > > mentioned ;-) -, > > > you will see that everybody involved in the discussion > > "Valerie, you, myself > > > and Javier" agreed to return to the original SE-IPSP model. The > > conclusion > > > was to use the text proposed by Valerie. It seems the bis > > document is not > > > updated accordingly. Ken, was there a technical objection for that > > > change -actually I would call it reverting back to the original > > model- or is > > > this just an oversight? > > > > Really? Did you mean in "M3UAbis - consensus on comment > > resolution" 23 Aug 2004 > > where Valerie says: > > > > IPSP-SE behaviour: > > The IPSP acting as the SGP must sends ASPAC-ack only when its > > side of the RK is > > ready. The IPSP acting as the ASP is responsible to retry the > > ASPAC until the > > remote peer is ready. > > When the IPSP acting as the SGP wants to stop application > > traffic from its side, > > it must send ASPIA-ack. > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - consensus > on comment resoluti on-Part 1&2" > > 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM > or ASPSM messages is needed to change the IPSP state. This means > that a set of request from one end and acknowledge from the other > will be enough. The RK must define both sides of the traffic flow. > Each exchange of ASPTM or ASPSM messages can be initiated by either > IPSP. For this exchange, the initiating IPSP follows the procedures > described in section 4.3.1. > > The above is the original concept we defined for SE-IPSP mode. > There are no > predefined client/server relationship, a pure peer-to-peer relationship. > > > > Or did you mean where we agreed to back out of the v03 changes > > (which is what > > I think you are referring to with the IPSPF) and go back to the > > v02 description > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As > long as the > problem is how you and I name it, there is no problem from specification > point of view but I would call it IPSPF because it has a different machine ^^^^^^^^^ state machine > than SGPF and ASPF and does not send/receive messages. I believe ^^^^^^^^^ certain messages, e.g. SSNM > you use the > term SGPF in the context of a "transaction" not inthe context of > the overall > realtionship between two peer IPSPs. > > > > --brian > > > > > > > > Considering the way it is supposed to work, i.e. according to > > the text we > > > had concensus on, we can't speak of exact SGPF semantics for > > SE-IPSP even > > > from basic message exchange point of view, e.g. SGPF does not > > send ASPAC, > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > sides can send > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a peer-to-peer > > > relationship, not a client/server relationship. > > > > See Valerie's description above. As I have mantained, it is > > clear that one IPSP > > acts in an SGP role and the other in an ASP role. > > > > > > > > Regarding the issue we are discussing in this thread -being > > able to support > > > traffic mode in both directions-I think it is a nice thing to > > have, because > > > we have application logic at both sides, which may want to > use different > > > traffic . > > > > Again, the IPSP acting as an SGP in SE mode is not required to > > have a traffic > > mode. > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic > > mode to place in > > the ASPAC Ack. Any traffic distribution towards the SGP is an > > SG-wide attribute > > and does not differ from AS to AS, nor ASP to ASP. > > > > --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 > > > > > > _______________________________________________ > 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 Nov 08 14:48:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZRw-0007UR-D8; Tue, 08 Nov 2005 14:48:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZRv-0007UK-2q for sigtran@megatron.ietf.org; Tue, 08 Nov 2005 14:48:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29245 for ; Tue, 8 Nov 2005 14:47:40 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZhl-0006Mv-Rv for sigtran@ietf.org; Tue, 08 Nov 2005 15:04:31 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA8JlxRk001578 for ; Tue, 8 Nov 2005 13:48:00 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Nov 2005 01:17:59 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D21BE55843@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Wed, 9 Nov 2005 01:17:57 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Brian, I was going thru ur last mails and ur old discussions. ( This mail is slightly long..excuse me for that ). I see new terms ASPF and SGPF. I haven't seen these terms in the RFC 3332. I guess, they mean ASP and SGP Function only and there is NOT really something more than our understanding of ASP and SGPs. Am I right ? I also read all along (in this discussion and the thread mails) that IPSP can act as an SGP or an ASP. This really confuses me. And may be I need additional clarification. As stated in RFC 3332 the definition of IPSP is as follows: IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not use the services of a Signalling Gateway node. Which clearly states that that IPSP is equivalent of ASP. I am NOT sure why I would use IPSP for SGs. SGP functionality should always be in SGs. Can I have SGPs even on nodes that are NOT Signaling Gateways ? Let's take the following simple example. I have picked this example because the Rel 5 3GPP standards use M3UA over SCTP at its Core Network Signaling transport side (SCCP is the ONLY M3UA User). And as per the specs (29.202), it speaks about IPSP considerations for all the nodes (eg. RNC, SGSN...). It terms each M3UA node (eg. RNC, SGSN...) as "IP Node using M3UA User". There is a seperate Requirement for SGs in the 3GPP standards. They follow the SGP Requirements. Essentially, both the peers will work in the pure IPSP-IPSP mode (peer to peer mode). I have never seen a mention of SE and DE as I feel that this has been left to implementation and various configurations that one might want to choose (Loadshared or Override) ******** IP ******** * IPSP * * IPSP * ******** ******** +------+ +------+ |SCCP- | |SCCP- | | User | | User | +------+ +------+ | SCCP | | SCCP | +------+ +------+ | M3UA | | M3UA | +------+ +------+ | SCTP | | SCTP | +------+ +------+ | IP | | IP | +------+ +------+ |________________| shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Tuesday, November 08, 2005 7:19 PM To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Brian, [..snip..] > > Regarding the issue we are discussing in this thread -being > able to support > > traffic mode in both directions-I think it is a nice thing to > have, because > > we have application logic at both sides, which may want to use different > > traffic . > > Again, the IPSP acting as an SGP in SE mode is not required to > have a traffic > mode. > > In the normal ASP/SGP exchange, the SGP does not have a traffic > mode to place in > the ASPAC Ack. Any traffic distribution towards the SGP is an > SG-wide attribute > and does not differ from AS to AS, nor ASP to ASP. [TOLGA]I believe we have another one of those "rare" situations where neither you nor I can convince the other one ;-) I think the options and supporting arguments are as follows: a)We don't need traffic mode bothways for SE-IPSP, because one of SE-IPSPs is mimicing a SGP and SGPs do not have traffic mode. b)We need traffic mode bothways, because both sides have application logic, which can have different trafic mode characteristics. (Shashank's position) I subscribe to b) and as far as I understand you support a). I think we need to hear more from other people about this issue so that we can reach a conclusion. Thanks, Tolga _______________________________________________ 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 Nov 08 14:48:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZRx-0007Uw-UG; Tue, 08 Nov 2005 14:48:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZRu-0007UI-OM for sigtran@megatron.ietf.org; Tue, 08 Nov 2005 14:48:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29238 for ; Tue, 8 Nov 2005 14:47:39 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZhl-0006Mj-Rz for sigtran@ietf.org; Tue, 08 Nov 2005 15:04:30 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA8Jlurm001516; Tue, 8 Nov 2005 13:47:57 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Nov 2005 01:17:56 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D21BE55842@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Wed, 9 Nov 2005 01:17:55 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Tolga Asveren X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, Tolga, The key thing is that SE and DE modes should be delinked from IPSP and SGP considerations. I feel that we should give the flexibility of SE and DE to the IPSPs-IPSPs. We should leave the IPSPs to decide which mode they need to take. If both the IPSPs have more than one AS, and they would like to control the traffic flow from either end for their respective ASs, they would naturally go for Double Ended. However, if they have only one AS per IPSPs, it is likely that they go in the Single Ended. Would u agree ? shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Tuesday, November 08, 2005 7:19 PM To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Brian, [..snip..] > > Regarding the issue we are discussing in this thread -being > able to support > > traffic mode in both directions-I think it is a nice thing to > have, because > > we have application logic at both sides, which may want to use different > > traffic . > > Again, the IPSP acting as an SGP in SE mode is not required to > have a traffic > mode. > > In the normal ASP/SGP exchange, the SGP does not have a traffic > mode to place in > the ASPAC Ack. Any traffic distribution towards the SGP is an > SG-wide attribute > and does not differ from AS to AS, nor ASP to ASP. [TOLGA]I believe we have another one of those "rare" situations where neither you nor I can convince the other one ;-) I think the options and supporting arguments are as follows: a)We don't need traffic mode bothways for SE-IPSP, because one of SE-IPSPs is mimicing a SGP and SGPs do not have traffic mode. b)We need traffic mode bothways, because both sides have application logic, which can have different trafic mode characteristics. (Shashank's position) I subscribe to b) and as far as I understand you support a). I think we need to hear more from other people about this issue so that we can reach a conclusion. Thanks, Tolga _______________________________________________ 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 Nov 08 14:56:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZZr-00011i-H2; Tue, 08 Nov 2005 14:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZZq-00010X-0M for sigtran@megatron.ietf.org; Tue, 08 Nov 2005 14:56:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29815 for ; Tue, 8 Nov 2005 14:55:50 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZpg-0006bm-Oh for sigtran@ietf.org; Tue, 08 Nov 2005 15:12:42 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA8JtwVc021307 for ; Tue, 8 Nov 2005 14:56:00 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Tue, 8 Nov 2005 14:37:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D21BE55842@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Tuesday, November 08, 2005 2:48 PM > To: sigtran@ietf.org > Cc: Tolga Asveren > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Brian, Tolga, > The key thing is that SE and DE modes should be delinked from IPSP and SGP > considerations. > I feel that we should give the flexibility of SE and DE to the > IPSPs-IPSPs. > We should leave the IPSPs to decide which mode they need to take. > > If both the IPSPs have more than one AS, and they would like to > control the > traffic flow from either end for their respective ASs, they would > naturally > go for Double Ended. [TOLGA]I don't agree with this statement. As far as I can see, using SE or DE modes of operation for IPSP is totally independent of number AS. One can very well have multiple AS and can use SE-IPSP mode -and I personally would think they would have made a better choice with it-. The main difference between SE and DE models is whether one wants two client/server relationships coupled to each other -DE mode- or a peer-to-peer relationship -SE mode- > However, if they have only one AS per IPSPs, it is likely that they go in > the Single Ended. > > Would u agree ? [TOLGA]I don't agree. I personally do not think that DE-mode is necessary but it is there in the specification as an optional method. > > > shashank > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Tuesday, November 08, 2005 7:19 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Brian, > > [..snip..] > > > Regarding the issue we are discussing in this thread -being > > able to support > > > traffic mode in both directions-I think it is a nice thing to > > have, because > > > we have application logic at both sides, which may want to > use different > > > traffic . > > > > Again, the IPSP acting as an SGP in SE mode is not required to > > have a traffic > > mode. > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic > > mode to place in > > the ASPAC Ack. Any traffic distribution towards the SGP is an > > SG-wide attribute > > and does not differ from AS to AS, nor ASP to ASP. > [TOLGA]I believe we have another one of those "rare" situations where > neither you nor I can convince the other one ;-) I think the options and > supporting arguments are as follows: > > a)We don't need traffic mode bothways for SE-IPSP, because one of SE-IPSPs > is mimicing a SGP and SGPs do not have traffic mode. > > b)We need traffic mode bothways, because both sides have > application logic, > which can have different trafic mode characteristics. (Shashank's > position) > > I subscribe to b) and as far as I understand you support a). I think we > need to hear more from other people about this issue so that we > can reach a > conclusion. > > > Thanks, > Tolga > > > > _______________________________________________ > 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 Nov 08 15:05:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZij-0003uZ-Aq; Tue, 08 Nov 2005 15:05:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZih-0003sh-DJ for sigtran@megatron.ietf.org; Tue, 08 Nov 2005 15:05:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00302 for ; Tue, 8 Nov 2005 15:05:00 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZyZ-0006qx-3r for sigtran@ietf.org; Tue, 08 Nov 2005 15:21:51 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA8K5GaG022239 for ; Tue, 8 Nov 2005 15:05:17 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Tue, 8 Nov 2005 14:47:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D21BE55843@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Prasad, Shashank S (Shashank) > Sent: Tuesday, November 08, 2005 2:48 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Tolga, Brian, > I was going thru ur last mails and ur old discussions. > ( This mail is slightly long..excuse me for that ). > > I see new terms ASPF and SGPF. I haven't seen these terms in the RFC 3332. > I guess, they mean ASP and SGP Function only and there is NOT really > something more than our understanding of ASP and SGPs. Am I right ? [TOLGA]We use the terms ASPF and SGPF to refer to the correspondign functionality in M3UA stack. > > > I also read all along (in this discussion and the thread mails) that IPSP > can act as an SGP or an ASP. > This really confuses me. And may be I need additional clarification. > > > As stated in RFC 3332 the definition of IPSP is as follows: > > IP Server Process (IPSP) - A process instance of an IP-based > application. An IPSP is essentially the same as an ASP, except that > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > not use the services of a Signalling Gateway node. > > Which clearly states that that IPSP is equivalent of ASP. I am [TOLGA]The similarity between ASP and IPSP is that both of them are hosting application logic. OTOH the state machines and message semantics are not equivalent. So, I wouldn't say that IPSP is equal to ASP -nor would I say that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, just that -all that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be wrong to speak of DE-IPSP = ASPF + SGPF-. > NOT sure why > I would use IPSP for SGs. > SGP functionality should always be in SGs. Can I have SGPs even on nodes > that are NOT Signaling Gateways ? > > > > Let's take the following simple example. > I have picked this example because the Rel 5 3GPP standards use M3UA over > SCTP at its Core Network Signaling transport side (SCCP is the ONLY M3UA > User). And as per the specs (29.202), it speaks about IPSP considerations > for all the nodes (eg. RNC, SGSN...). It terms each M3UA node (eg. RNC, > SGSN...) as "IP Node using M3UA User". > > There is a seperate Requirement for SGs in the 3GPP standards. They follow > the SGP Requirements. > Essentially, both the peers will work in the pure IPSP-IPSP mode (peer to > peer mode). > > I have never seen a mention of SE and DE as I feel that this has been left > to implementation and various configurations that one might want to choose > (Loadshared or Override) [TOLGA]I think the main reason for why you don't see much about SE/DE mode in 3GPP documents is because SE/DE conmcept was not defined at that time. Initially we had only SE-mode of operation. > > > ******** IP ******** > * IPSP * * IPSP * > ******** ******** > > +------+ +------+ > |SCCP- | |SCCP- | > | User | | User | > +------+ +------+ > | SCCP | | SCCP | > +------+ +------+ > | M3UA | | M3UA | > +------+ +------+ > | SCTP | | SCTP | > +------+ +------+ > | IP | | IP | > +------+ +------+ > |________________| > > > shashank > > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Tuesday, November 08, 2005 7:19 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Brian, > > [..snip..] > > > Regarding the issue we are discussing in this thread -being > > able to support > > > traffic mode in both directions-I think it is a nice thing to > > have, because > > > we have application logic at both sides, which may want to > use different > > > traffic . > > > > Again, the IPSP acting as an SGP in SE mode is not required to > > have a traffic > > mode. > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic > > mode to place in > > the ASPAC Ack. Any traffic distribution towards the SGP is an > > SG-wide attribute > > and does not differ from AS to AS, nor ASP to ASP. > [TOLGA]I believe we have another one of those "rare" situations where > neither you nor I can convince the other one ;-) I think the options and > supporting arguments are as follows: > > a)We don't need traffic mode bothways for SE-IPSP, because one of SE-IPSPs > is mimicing a SGP and SGPs do not have traffic mode. > > b)We need traffic mode bothways, because both sides have > application logic, > which can have different trafic mode characteristics. (Shashank's > position) > > I subscribe to b) and as far as I understand you support a). I think we > need to hear more from other people about this issue so that we > can reach a > conclusion. > > > Thanks, > Tolga > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 00:40:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZihY-0007r1-AS; Wed, 09 Nov 2005 00:40:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZihX-0007pE-DV for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 00:40:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14390 for ; Wed, 9 Nov 2005 00:40:24 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[uoYjPecAabf57VrfPyZzjKwvgoIUNzsJ]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZixT-0000du-GY for sigtran@ietf.org; Wed, 09 Nov 2005 00:57:20 -0500 Received: from ns.pigworks.openss7.net (IDENT:gouhQAIIDcGkjzhKTYT7PGa9U07NhmWE@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA95eUc08906; Tue, 8 Nov 2005 22:40:31 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA95eP207400; Tue, 8 Nov 2005 22:40:25 -0700 Date: Tue, 8 Nov 2005 22:40:25 -0700 From: "Brian F. G. Bidulock" To: Saraswati Bose Message-ID: <20051108224025.A7338@openss7.org> Mail-Followup-To: Saraswati Bose , sigtran@ietf.org References: <20051108042427.A30853@openss7.org> <20051109041042.84594.qmail@web53803.mail.yahoo.com> 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: <20051109041042.84594.qmail@web53803.mail.yahoo.com>; from saraswatibose@yahoo.com on Tue, Nov 08, 2005 at 08:10:42PM -0800 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 jA95eUc08906 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org Subject: [Sigtran] Re: [IUA]: ASP configuration in AS X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Saraswati, On Tue, 08 Nov 2005, Saraswati Bose wrote: >=20 > Brian, >=20 >=20 >=20 > I think like an AS is uniquely identified by its RK value in SUA/M3= UA > similarly in IUA AS is identified by Interface Identifier value. >=20 >=20 >=20 > 1.For an ASP serving in more than one AS the Routing Context is us= ed > to identify the ASP for each unique AS that it serves in SUA/ M3U= A. > What parameter can we use for IUA case? IID is closer to RC than RK. >=20 > 2. In rfc 3057--IUA ASPID parameter is not defined. In that case whi= ch > other parameter can be used to identifying the multiple ASPs serving= a > AS? I believe it was defined in rfc3057bis. >=20 >=20 >=20 > --Saraswati >=20 >=20 --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 01:39:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZjcV-0008M9-Ev; Wed, 09 Nov 2005 01:39:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZjcT-0008KL-Sc for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 01:39:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16906 for ; Wed, 9 Nov 2005 01:39:15 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[OdpBPjsuWvzkqN/7n0B66CiRig7s4SJG]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZjr9-0001rj-3B for sigtran@ietf.org; Wed, 09 Nov 2005 01:56:11 -0500 Received: from ns.pigworks.openss7.net (IDENT:zC1j+TgpD9lflBFADiAwB5GTgWaZB8Wo@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA96c1c09952; Tue, 8 Nov 2005 23:38:01 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA96c1k08242; Tue, 8 Nov 2005 23:38:01 -0700 Date: Tue, 8 Nov 2005 23:38:00 -0700 From: "Brian F. G. Bidulock" To: Saraswati Bose Message-ID: <20051108233800.A8199@openss7.org> Mail-Followup-To: Saraswati Bose , sigtran@ietf.org References: <20051108224025.A7338@openss7.org> <20051109060257.98990.qmail@web53804.mail.yahoo.com> 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: <20051109060257.98990.qmail@web53804.mail.yahoo.com>; from saraswatibose@yahoo.com on Tue, Nov 08, 2005 at 10:02:57PM -0800 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 jA96c1c09952 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org Subject: [Sigtran] Re: [IUA]: ASP configuration in AS X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Saraswati, In M3UA and SUA, there is a 1:1:1 relationship between RK:RC:AS. In IUA and M2UA, there is a 1:1 relationship between IID:AS (with the exception that any of several IIDs within the same AS can identify the AS). But this should be obvious from the RFCs. --brian On Tue, 08 Nov 2005, Saraswati Bose wrote: >=20 > Brian, >=20 > This is confusing. If for SUA /M3UA I use RK as also specified = in > RFCs to uniquely identify the AS then for IUA case as says t= he > rfc-3057 I have to use IID. Suggest if there is any other paramet= er > used for the purpose? >=20 >=20 >=20 > Now the question is if I use IID for identifying the AS then wh= at > parameter may I use to identify the same ASP that serves multiple = AS > (with unique IID) like we have one to one correspondance for RC:= RK > combination defined for SUA/M3UA. >=20 >=20 >=20 > --Saraswati --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 04:57:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZmhQ-0003yK-5u; Wed, 09 Nov 2005 04:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZmhO-0003yF-B3 for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 04:56:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26332 for ; Wed, 9 Nov 2005 04:56:30 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZmxN-0006qY-Mi for sigtran@ietf.org; Wed, 09 Nov 2005 05:13:30 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA99udXh001169; Wed, 9 Nov 2005 03:56:40 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Nov 2005 15:26:32 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB68AF@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Wed, 9 Nov 2005 15:24:23 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: "'bidulock@openss7.org'" , 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org OK... On the technical terms defined by the standard, there is no difference between IPSPs and ASPs, except that it is used Point-2-Point and do NOT use SGs in between. Of course, IPSP is NOT an SGP...that's for sure. Here the definition of IPSP verbatim from specs.... IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not use the services of a Signalling Gateway node. ---- Picked from ur last mail ---- [TOLGA]The similarity between ASP and IPSP is that both of them are hosting application logic. OTOH the state machines and message semantics are not equivalent. So, I wouldn't say that IPSP is equal to ASP -nor would I say that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, just that -all that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be wrong to speak of DE-IPSP = ASPF + SGPF-. U said that the state machines and message semantics are NOT equivalent. Looking at the specs, I did NOT find any state machine differences between ASPs and IPSPs too. I think the main contention that I have with u and Brian is that the definitions of IPSPs. U defined the modes based of the functionality of the IPSP. I was delinking the modes from the definition of IPSPs. Ur view of IPSPs in Single Ended (SE) mode (picking up from some old threads) IPSP A IPSP B ___________ ___________ | | | | | _______ | | _______ | | | | | | | | | | | ASPF | | | | ASPF | | | |_______| | | |_______| | | | | Association | | | | | __|____________________|__/ | | | / | | | | ___|_|_ | | _______ | | | | | | | | | | | SGPF | | | | SGPF | | | |_______| | | |_______| | | | | | |___________| |___________| And I think that we can also define IPSPs as follows and still have the SE and DE configuration for both :) IPSP A IPSP B ___________ ___________ | | | | | _______ | | _______ | | | | | | | | | | | ASPF |----------------------|-| ASPF | | | |_______| | | |_______| | | | Association | | | | | | | | | | |___________| |___________| Any inputs on my interpretation of my IPSP definition from the RFC 3332 perspective ? Thanx. shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Wednesday, November 09, 2005 1:17 AM To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Shashank, > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Prasad, Shashank S (Shashank) > Sent: Tuesday, November 08, 2005 2:48 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Tolga, Brian, > I was going thru ur last mails and ur old discussions. > ( This mail is slightly long..excuse me for that ). > > I see new terms ASPF and SGPF. I haven't seen these terms in the RFC 3332. > I guess, they mean ASP and SGP Function only and there is NOT really > something more than our understanding of ASP and SGPs. Am I right ? [TOLGA]We use the terms ASPF and SGPF to refer to the correspondign functionality in M3UA stack. > > > I also read all along (in this discussion and the thread mails) that IPSP > can act as an SGP or an ASP. > This really confuses me. And may be I need additional clarification. > > > As stated in RFC 3332 the definition of IPSP is as follows: > > IP Server Process (IPSP) - A process instance of an IP-based > application. An IPSP is essentially the same as an ASP, except that > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > not use the services of a Signalling Gateway node. > > Which clearly states that that IPSP is equivalent of ASP. I am [TOLGA]The similarity between ASP and IPSP is that both of them are hosting application logic. OTOH the state machines and message semantics are not equivalent. So, I wouldn't say that IPSP is equal to ASP -nor would I say that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, just that -all that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be wrong to speak of DE-IPSP = ASPF + SGPF-. > NOT sure why > I would use IPSP for SGs. > SGP functionality should always be in SGs. Can I have SGPs even on nodes > that are NOT Signaling Gateways ? > > > > Let's take the following simple example. > I have picked this example because the Rel 5 3GPP standards use M3UA over > SCTP at its Core Network Signaling transport side (SCCP is the ONLY M3UA > User). And as per the specs (29.202), it speaks about IPSP considerations > for all the nodes (eg. RNC, SGSN...). It terms each M3UA node (eg. RNC, > SGSN...) as "IP Node using M3UA User". > > There is a seperate Requirement for SGs in the 3GPP standards. They follow > the SGP Requirements. > Essentially, both the peers will work in the pure IPSP-IPSP mode (peer to > peer mode). > > I have never seen a mention of SE and DE as I feel that this has been left > to implementation and various configurations that one might want to choose > (Loadshared or Override) [TOLGA]I think the main reason for why you don't see much about SE/DE mode in 3GPP documents is because SE/DE conmcept was not defined at that time. Initially we had only SE-mode of operation. > > > ******** IP ******** > * IPSP * * IPSP * > ******** ******** > > +------+ +------+ > |SCCP- | |SCCP- | > | User | | User | > +------+ +------+ > | SCCP | | SCCP | > +------+ +------+ > | M3UA | | M3UA | > +------+ +------+ > | SCTP | | SCTP | > +------+ +------+ > | IP | | IP | > +------+ +------+ > |________________| > > > shashank > > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Tuesday, November 08, 2005 7:19 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Brian, > > [..snip..] > > > Regarding the issue we are discussing in this thread -being > > able to support > > > traffic mode in both directions-I think it is a nice thing to > > have, because > > > we have application logic at both sides, which may want to > use different > > > traffic . > > > > Again, the IPSP acting as an SGP in SE mode is not required to > > have a traffic > > mode. > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic > > mode to place in > > the ASPAC Ack. Any traffic distribution towards the SGP is an > > SG-wide attribute > > and does not differ from AS to AS, nor ASP to ASP. > [TOLGA]I believe we have another one of those "rare" situations where > neither you nor I can convince the other one ;-) I think the options and > supporting arguments are as follows: > > a)We don't need traffic mode bothways for SE-IPSP, because one of SE-IPSPs > is mimicing a SGP and SGPs do not have traffic mode. > > b)We need traffic mode bothways, because both sides have > application logic, > which can have different trafic mode characteristics. (Shashank's > position) > > I subscribe to b) and as far as I understand you support a). I think we > need to hear more from other people about this issue so that we > can reach a > conclusion. > > > Thanks, > Tolga > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 05:39:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZnMJ-0007iP-5S; Wed, 09 Nov 2005 05:39:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZnMC-0007al-79 for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 05:39:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28505 for ; Wed, 9 Nov 2005 05:38:39 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZncB-0007v8-JE for sigtran@ietf.org; Wed, 09 Nov 2005 05:55:40 -0500 Received: from gw.openss7.com ([142.179.199.224] ident=[prnuhFmzpxIXyWOhleJiFwLoDsXtMXF5]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EZnI1-00056l-7x for sigtran@ietf.org; Wed, 09 Nov 2005 05:38:58 -0500 Received: from ns.pigworks.openss7.net (IDENT:006Bg+F+7Ee8xuTSxCQTh2Sc8WEtMI8D@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA9AOic14619; Wed, 9 Nov 2005 03:24:44 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA9AOei12150; Wed, 9 Nov 2005 03:24:40 -0700 Date: Wed, 9 Nov 2005 03:24:40 -0700 From: "Brian F. G. Bidulock" To: "Prasad, Shashank S (Shashank)" Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Message-ID: <20051109032440.A11934@openss7.org> Mail-Followup-To: "Prasad, Shashank S (Shashank)" , sigtran@ietf.org, 'Tolga Asveren' References: <6733C768256DEC42A72BAFEFA9CF06D210FB68AF@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB68AF@ii0015exch002u.iprc.lucent.com>; from ssprasad@lucent.com on Wed, Nov 09, 2005 at 03:24:23PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: sigtran@ietf.org, 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, For M3UA, ASPF is essentially an M3UA shim and an MTP-User. Two ASPF can no longer communicate with each other than can two MTP-Users without an underlying MTP provider (the SGPF). Tolga's view (if I'm right) is: IPSP A IPSP B ___________ ___________ | _______ | | _______ | | | | | | | | | | | IPSPF |----------------------|-| IPSPF | | | |_______| | Association | |_______| | |___________| |___________| However, this IPSPF is nowhere defined. We had long discussions about this. When RFC 3332 was advanced we knew that there were rather severe limitations with the IPSP models in RFC 3332. We advanced the RFC anyway. The WG agreed that we would offer IPSP as an extension draft. We largely decided that a new protocol (perhaps using the same message set) was required for true peer-to-peer communication. It looked like this: IPSP A IPSP B ___________ ___________ | _______ | | _______ | | | | | | | | | | | ASPF | | | | ASPF | | | |_______| | | |_______| | | | | | | | | ___|___ | | ___|___ | | | | | Association | | | | | | SGPF |-|--------------------|-| SGPF | | | |_______| | | |_______| | |___________| |___________| Which is rougly equivalent to: IPSP A IPSP B ___________ ___________ | _______ | | _______ | | | | | | | | | | | IPSPF |----------------------|-| IPSPF | | | |_______| | Association | |_______| | |___________| |___________| IIRC we called it an SG-SG IPSP. It is even covered in the framework document. Tolga wrote a draft. At some meeting it was supposed to become a WG item. It died. rfc3332bis was advanced without repairing IPSP (but at least removing some glaring errors from RFC 3332, yet introducing others). If one really wants to repair IPSP, it might be an idea to revive the SG-SG draft and do IPSP properly. I can whip up a draft if anyone is truly interested. --brian Prasad, Shashank S (Shashank) wrote: (Wed, 09 Nov 2005 15:24:23) > OK... > On the technical terms defined by the standard, there is no difference > between IPSPs and ASPs, except that it is used Point-2-Point and do NOT use > SGs in between. > Of course, IPSP is NOT an SGP...that's for sure. > > Here the definition of IPSP verbatim from specs.... > > IP Server Process (IPSP) - A process instance of an IP-based > application. An IPSP is essentially the same as an ASP, except that > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > not use the services of a Signalling Gateway node. > > > > > ---- Picked from ur last mail ---- > [TOLGA]The similarity between ASP and IPSP is that both of them are hosting > application logic. OTOH the state machines and message semantics are not > equivalent. So, I wouldn't say that IPSP is equal to ASP -nor would I say > that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, just that -all > that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be wrong to speak of > DE-IPSP = ASPF + SGPF-. > > > U said that the state machines and message semantics are NOT equivalent. > Looking at the specs, I did NOT find any state machine differences between > ASPs and IPSPs too. > > I think the main contention that I have with u and Brian is that the > definitions of IPSPs. > U defined the modes based of the functionality of the IPSP. I was delinking > the modes from the definition of IPSPs. > > > Ur view of IPSPs in Single Ended (SE) mode (picking up from some old > threads) > > > IPSP A IPSP B > ___________ ___________ > | | | | > | _______ | | _______ | > | | | | | | | | > | | ASPF | | | | ASPF | | > | |_______| | | |_______| | > | | | Association | | | > | | __|____________________|__/ | > | | / | | | > | ___|_|_ | | _______ | > | | | | | | | | > | | SGPF | | | | SGPF | | > | |_______| | | |_______| | > | | | | > |___________| |___________| > > > And I think that we can also define IPSPs as follows and still have the SE > and DE configuration for both :) > > IPSP A IPSP B > ___________ ___________ > | | | | > | _______ | | _______ | > | | | | | | | | > | | ASPF |----------------------|-| ASPF | | > | |_______| | | |_______| | > | | Association | | > | | | | > | | | | > |___________| |___________| > > > Any inputs on my interpretation of my IPSP definition from the RFC 3332 > perspective ? > > > Thanx. > shashank > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Wednesday, November 09, 2005 1:17 AM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Prasad, Shashank S (Shashank) > > Sent: Tuesday, November 08, 2005 2:48 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Tolga, Brian, > > I was going thru ur last mails and ur old discussions. > > ( This mail is slightly long..excuse me for that ). > > > > I see new terms ASPF and SGPF. I haven't seen these terms in the RFC 3332. > > I guess, they mean ASP and SGP Function only and there is NOT really > > something more than our understanding of ASP and SGPs. Am I right ? > [TOLGA]We use the terms ASPF and SGPF to refer to the correspondign > functionality in M3UA stack. > > > > > > I also read all along (in this discussion and the thread mails) that IPSP > > can act as an SGP or an ASP. > > This really confuses me. And may be I need additional clarification. > > > > > > As stated in RFC 3332 the definition of IPSP is as follows: > > > > IP Server Process (IPSP) - A process instance of an IP-based > > application. An IPSP is essentially the same as an ASP, except that > > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > > not use the services of a Signalling Gateway node. > > > > Which clearly states that that IPSP is equivalent of ASP. I am > [TOLGA]The similarity between ASP and IPSP is that both of them are hosting > application logic. OTOH the state machines and message semantics are not > equivalent. So, I wouldn't say that IPSP is equal to ASP -nor would I say > that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, just that -all > that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be wrong to speak of > DE-IPSP = ASPF + SGPF-. > > NOT sure why > > I would use IPSP for SGs. > > SGP functionality should always be in SGs. Can I have SGPs even on nodes > > that are NOT Signaling Gateways ? > > > > > > > > Let's take the following simple example. > > I have picked this example because the Rel 5 3GPP standards use M3UA over > > SCTP at its Core Network Signaling transport side (SCCP is the ONLY M3UA > > User). And as per the specs (29.202), it speaks about IPSP considerations > > for all the nodes (eg. RNC, SGSN...). It terms each M3UA node (eg. RNC, > > SGSN...) as "IP Node using M3UA User". > > > > There is a seperate Requirement for SGs in the 3GPP standards. They follow > > the SGP Requirements. > > Essentially, both the peers will work in the pure IPSP-IPSP mode (peer to > > peer mode). > > > > I have never seen a mention of SE and DE as I feel that this has been left > > to implementation and various configurations that one might want to choose > > (Loadshared or Override) > [TOLGA]I think the main reason for why you don't see much about SE/DE mode > in 3GPP documents is because SE/DE conmcept was not defined at that time. > Initially we had only SE-mode of operation. > > > > > > ******** IP ******** > > * IPSP * * IPSP * > > ******** ******** > > > > +------+ +------+ > > |SCCP- | |SCCP- | > > | User | | User | > > +------+ +------+ > > | SCCP | | SCCP | > > +------+ +------+ > > | M3UA | | M3UA | > > +------+ +------+ > > | SCTP | | SCTP | > > +------+ +------+ > > | IP | | IP | > > +------+ +------+ > > |________________| > > > > > > shashank > > > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Tuesday, November 08, 2005 7:19 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Brian, > > > > [..snip..] > > > > Regarding the issue we are discussing in this thread -being > > > able to support > > > > traffic mode in both directions-I think it is a nice thing to > > > have, because > > > > we have application logic at both sides, which may want to > > use different > > > > traffic . > > > > > > Again, the IPSP acting as an SGP in SE mode is not required to > > > have a traffic > > > mode. > > > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic > > > mode to place in > > > the ASPAC Ack. Any traffic distribution towards the SGP is an > > > SG-wide attribute > > > and does not differ from AS to AS, nor ASP to ASP. > > [TOLGA]I believe we have another one of those "rare" situations where > > neither you nor I can convince the other one ;-) I think the options and > > supporting arguments are as follows: > > > > a)We don't need traffic mode bothways for SE-IPSP, because one of SE-IPSPs > > is mimicing a SGP and SGPs do not have traffic mode. > > > > b)We need traffic mode bothways, because both sides have > > application logic, > > which can have different trafic mode characteristics. (Shashank's > > position) > > > > I subscribe to b) and as far as I understand you support a). I think we > > need to hear more from other people about this issue so that we > > can reach a > > conclusion. > > > > > > Thanks, > > Tolga > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- 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 Nov 09 07:10:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZomT-0006Wf-Aw; Wed, 09 Nov 2005 07:10:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZomQ-0006WV-OE for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 07:10:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02648 for ; Wed, 9 Nov 2005 07:09:51 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZp2O-0001YK-Vk for sigtran@ietf.org; Wed, 09 Nov 2005 07:26:51 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA9CA0Yq014396; Wed, 9 Nov 2005 06:10:01 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Nov 2005 17:39:57 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB68BB@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: sigtran@ietf.org Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Wed, 9 Nov 2005 17:39:47 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 Cc: "'bidulock@openss7.org'" , 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, We indeed have a lot differences in our interpretation of IPSPs and the modes. I am seriously interested in the draft....so that we come to a common underdstanding. Few questions on ur last mail: I had different idea about ASPF and SGPF in the IPSP block. My original idea never had ASPF and SGPF in the same IPSP. However, I took the model at the face value from the old e-mail thread discussions. From the e-mail thread discussions, I interpreted that IPSP comprises 2 functionalities, ASPF and SGPF, independent of each other. There can be a possibility that IPSP has ASPF + SGPF. Also, the IPSP can have ASPF only or SGPF only ( I still have sink in this model :) ) But now I still read something different. From ur mail it seems that ASPF uses the services of SGPF in its own IPSP to communicate to the peer...Did I rightly interpret ur mail ? If YES, then I have confusions and am not very sure if that should be the intended model. I understand that ASPFs in one IPSP should be talking to the SGPFs of the peer and NOT the same IPSP. Hence I feel that ASP does NOT need the services of SGPs, in the same IPSP. How would u model, based on ur functionality... +------+ +------+ |SCCP- | |SCCP- | | User | | User | +------+ +------+ | SCCP | | SCCP | +------+ +------+ | M3UA | | M3UA | +------+ +------+ | SCTP | | SCTP | +------+ +------+ | IP | | IP | +------+ +------+ Thanx. shashank -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Wednesday, November 09, 2005 3:55 PM To: Prasad, Shashank S (Shashank) Cc: sigtran@ietf.org; 'Tolga Asveren' Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Shashank, For M3UA, ASPF is essentially an M3UA shim and an MTP-User. Two ASPF can no longer communicate with each other than can two MTP-Users without an underlying MTP provider (the SGPF). Tolga's view (if I'm right) is: IPSP A IPSP B ___________ ___________ | _______ | | _______ | | | | | | | | | | | IPSPF |----------------------|-| IPSPF | | | |_______| | Association | |_______| | |___________| |___________| However, this IPSPF is nowhere defined. We had long discussions about this. When RFC 3332 was advanced we knew that there were rather severe limitations with the IPSP models in RFC 3332. We advanced the RFC anyway. The WG agreed that we would offer IPSP as an extension draft. We largely decided that a new protocol (perhaps using the same message set) was required for true peer-to-peer communication. It looked like this: IPSP A IPSP B ___________ ___________ | _______ | | _______ | | | | | | | | | | | ASPF | | | | ASPF | | | |_______| | | |_______| | | | | | | | | ___|___ | | ___|___ | | | | | Association | | | | | | SGPF |-|--------------------|-| SGPF | | | |_______| | | |_______| | |___________| |___________| Which is rougly equivalent to: IPSP A IPSP B ___________ ___________ | _______ | | _______ | | | | | | | | | | | IPSPF |----------------------|-| IPSPF | | | |_______| | Association | |_______| | |___________| |___________| IIRC we called it an SG-SG IPSP. It is even covered in the framework document. Tolga wrote a draft. At some meeting it was supposed to become a WG item. It died. rfc3332bis was advanced without repairing IPSP (but at least removing some glaring errors from RFC 3332, yet introducing others). If one really wants to repair IPSP, it might be an idea to revive the SG-SG draft and do IPSP properly. I can whip up a draft if anyone is truly interested. --brian Prasad, Shashank S (Shashank) wrote: (Wed, 09 Nov 2005 15:24:23) > OK... > On the technical terms defined by the standard, there is no difference > between IPSPs and ASPs, except that it is used Point-2-Point and do NOT use > SGs in between. > Of course, IPSP is NOT an SGP...that's for sure. > > Here the definition of IPSP verbatim from specs.... > > IP Server Process (IPSP) - A process instance of an IP-based > application. An IPSP is essentially the same as an ASP, except that > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > not use the services of a Signalling Gateway node. > > > > > ---- Picked from ur last mail ---- > [TOLGA]The similarity between ASP and IPSP is that both of them are hosting > application logic. OTOH the state machines and message semantics are not > equivalent. So, I wouldn't say that IPSP is equal to ASP -nor would I say > that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, just that -all > that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be wrong to speak of > DE-IPSP = ASPF + SGPF-. > > > U said that the state machines and message semantics are NOT equivalent. > Looking at the specs, I did NOT find any state machine differences between > ASPs and IPSPs too. > > I think the main contention that I have with u and Brian is that the > definitions of IPSPs. > U defined the modes based of the functionality of the IPSP. I was delinking > the modes from the definition of IPSPs. > > > Ur view of IPSPs in Single Ended (SE) mode (picking up from some old > threads) > > > IPSP A IPSP B > ___________ ___________ > | | | | > | _______ | | _______ | > | | | | | | | | > | | ASPF | | | | ASPF | | > | |_______| | | |_______| | > | | | Association | | | > | | __|____________________|__/ | > | | / | | | > | ___|_|_ | | _______ | > | | | | | | | | > | | SGPF | | | | SGPF | | > | |_______| | | |_______| | > | | | | > |___________| |___________| > > > And I think that we can also define IPSPs as follows and still have the SE > and DE configuration for both :) > > IPSP A IPSP B > ___________ ___________ > | | | | > | _______ | | _______ | > | | | | | | | | > | | ASPF |----------------------|-| ASPF | | > | |_______| | | |_______| | > | | Association | | > | | | | > | | | | > |___________| |___________| > > > Any inputs on my interpretation of my IPSP definition from the RFC 3332 > perspective ? > > > Thanx. > shashank > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Wednesday, November 09, 2005 1:17 AM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Prasad, Shashank S (Shashank) > > Sent: Tuesday, November 08, 2005 2:48 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Tolga, Brian, > > I was going thru ur last mails and ur old discussions. > > ( This mail is slightly long..excuse me for that ). > > > > I see new terms ASPF and SGPF. I haven't seen these terms in the RFC 3332. > > I guess, they mean ASP and SGP Function only and there is NOT really > > something more than our understanding of ASP and SGPs. Am I right ? > [TOLGA]We use the terms ASPF and SGPF to refer to the correspondign > functionality in M3UA stack. > > > > > > I also read all along (in this discussion and the thread mails) that IPSP > > can act as an SGP or an ASP. > > This really confuses me. And may be I need additional clarification. > > > > > > As stated in RFC 3332 the definition of IPSP is as follows: > > > > IP Server Process (IPSP) - A process instance of an IP-based > > application. An IPSP is essentially the same as an ASP, except that > > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > > not use the services of a Signalling Gateway node. > > > > Which clearly states that that IPSP is equivalent of ASP. I am > [TOLGA]The similarity between ASP and IPSP is that both of them are hosting > application logic. OTOH the state machines and message semantics are not > equivalent. So, I wouldn't say that IPSP is equal to ASP -nor would I say > that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, just that -all > that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be wrong to speak of > DE-IPSP = ASPF + SGPF-. > > NOT sure why > > I would use IPSP for SGs. > > SGP functionality should always be in SGs. Can I have SGPs even on nodes > > that are NOT Signaling Gateways ? > > > > > > > > Let's take the following simple example. > > I have picked this example because the Rel 5 3GPP standards use M3UA over > > SCTP at its Core Network Signaling transport side (SCCP is the ONLY M3UA > > User). And as per the specs (29.202), it speaks about IPSP considerations > > for all the nodes (eg. RNC, SGSN...). It terms each M3UA node (eg. RNC, > > SGSN...) as "IP Node using M3UA User". > > > > There is a seperate Requirement for SGs in the 3GPP standards. They follow > > the SGP Requirements. > > Essentially, both the peers will work in the pure IPSP-IPSP mode (peer to > > peer mode). > > > > I have never seen a mention of SE and DE as I feel that this has been left > > to implementation and various configurations that one might want to choose > > (Loadshared or Override) > [TOLGA]I think the main reason for why you don't see much about SE/DE mode > in 3GPP documents is because SE/DE conmcept was not defined at that time. > Initially we had only SE-mode of operation. > > > > > > ******** IP ******** > > * IPSP * * IPSP * > > ******** ******** > > > > +------+ +------+ > > |SCCP- | |SCCP- | > > | User | | User | > > +------+ +------+ > > | SCCP | | SCCP | > > +------+ +------+ > > | M3UA | | M3UA | > > +------+ +------+ > > | SCTP | | SCTP | > > +------+ +------+ > > | IP | | IP | > > +------+ +------+ > > |________________| > > > > > > shashank > > > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Tuesday, November 08, 2005 7:19 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Brian, > > > > [..snip..] > > > > Regarding the issue we are discussing in this thread -being > > > able to support > > > > traffic mode in both directions-I think it is a nice thing to > > > have, because > > > > we have application logic at both sides, which may want to > > use different > > > > traffic . > > > > > > Again, the IPSP acting as an SGP in SE mode is not required to > > > have a traffic > > > mode. > > > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic > > > mode to place in > > > the ASPAC Ack. Any traffic distribution towards the SGP is an > > > SG-wide attribute > > > and does not differ from AS to AS, nor ASP to ASP. > > [TOLGA]I believe we have another one of those "rare" situations where > > neither you nor I can convince the other one ;-) I think the options and > > supporting arguments are as follows: > > > > a)We don't need traffic mode bothways for SE-IPSP, because one of SE-IPSPs > > is mimicing a SGP and SGPs do not have traffic mode. > > > > b)We need traffic mode bothways, because both sides have > > application logic, > > which can have different trafic mode characteristics. (Shashank's > > position) > > > > I subscribe to b) and as far as I understand you support a). I think we > > need to hear more from other people about this issue so that we > > can reach a > > conclusion. > > > > > > Thanks, > > Tolga > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- 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 Nov 09 08:19:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZpqx-0002cd-8U; Wed, 09 Nov 2005 08:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZpqv-0002cY-Rt for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 08:19:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08472 for ; Wed, 9 Nov 2005 08:18:34 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZq6u-000456-R9 for sigtran@ietf.org; Wed, 09 Nov 2005 08:35:35 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9DIcqO028895 for ; Wed, 9 Nov 2005 08:18:41 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Wed, 9 Nov 2005 08:00:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB68AF@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Wednesday, November 09, 2005 4:54 AM > To: sigtran@ietf.org > Cc: 'Tolga Asveren'; 'bidulock@openss7.org' > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > OK... > On the technical terms defined by the standard, there is no difference > between IPSPs and ASPs, except that it is used Point-2-Point and > do NOT use > SGs in between. > Of course, IPSP is NOT an SGP...that's for sure. > > Here the definition of IPSP verbatim from specs.... > > IP Server Process (IPSP) - A process instance of an IP-based > application. An IPSP is essentially the same as an ASP, except that > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > not use the services of a Signalling Gateway node. > > > > > ---- Picked from ur last mail ---- > [TOLGA]The similarity between ASP and IPSP is that both of them > are hosting > application logic. OTOH the state machines and message semantics are not > equivalent. So, I wouldn't say that IPSP is equal to ASP -nor would I say > that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, just > that -all > that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be wrong > to speak of > DE-IPSP = ASPF + SGPF-. > > > U said that the state machines and message semantics are NOT equivalent. > Looking at the specs, I did NOT find any state machine differences between > ASPs and IPSPs too. [TOLGA]Did you consider the state transitions inside brackets, which are only valid for IPSP case for AS state machine per ASP (Figure3 in the specification)? An ASP can't receive ASPAC an IPSP can etc... Furthermore ASP can receive and generate SSNM, an IPSP doesn't. ASP and IPSP are different things from M3UA message processing point of view. OTOH they are similar because both of them host application logic. > > I think the main contention that I have with u and Brian is that the > definitions of IPSPs. > U defined the modes based of the functionality of the IPSP. I was > delinking > the modes from the definition of IPSPs. > > > Ur view of IPSPs in Single Ended (SE) mode (picking up from some old > threads) > > > IPSP A IPSP B > ___________ ___________ > | | | | > | _______ | | _______ | > | | | | | | | | > | | ASPF | | | | ASPF | | > | |_______| | | |_______| | > | | | Association | | | > | | __|____________________|__/ | > | | / | | | > | ___|_|_ | | _______ | > | | | | | | | | > | | SGPF | | | | SGPF | | > | |_______| | | |_______| | > | | | | > |___________| |___________| > [TOLGA]the above is not my view on SE-IPSP. > > And I think that we can also define IPSPs as follows and still have the SE > and DE configuration for both :) [TOLGA]The point is whether something is really necessary or not., hence my objection to DE-IPSP. > > IPSP A IPSP B > ___________ ___________ > | | | | > | _______ | | _______ | > | | | | | | | | > | | ASPF |----------------------|-| ASPF | | > | |_______| | | |_______| | > | | Association | | > | | | | > | | | | > |___________| |___________| > > > Any inputs on my interpretation of my IPSP definition from the RFC 3332 > perspective ? The way SE-IPSP currently defined is: +-------------+ +-------------+ | IPSP A | | IPSP B | | | | | | | | | | +-------+ | | +-------+ | | | | | | | | | | | IPSPF +---+-----------+--+IPSPF | | | | | | | | | | | +-------+ | | +-------+ | | | | | | | | | +-------------+ +-------------+ We don't need to change something architecturally about it, just the document needs a bit of cleanup. > > > Thanx. > shashank > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Wednesday, November 09, 2005 1:17 AM > To: sigtran@ietf.org > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Prasad, Shashank S (Shashank) > > Sent: Tuesday, November 08, 2005 2:48 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Tolga, Brian, > > I was going thru ur last mails and ur old discussions. > > ( This mail is slightly long..excuse me for that ). > > > > I see new terms ASPF and SGPF. I haven't seen these terms in > the RFC 3332. > > I guess, they mean ASP and SGP Function only and there is NOT really > > something more than our understanding of ASP and SGPs. Am I right ? > [TOLGA]We use the terms ASPF and SGPF to refer to the correspondign > functionality in M3UA stack. > > > > > > I also read all along (in this discussion and the thread mails) > that IPSP > > can act as an SGP or an ASP. > > This really confuses me. And may be I need additional clarification. > > > > > > As stated in RFC 3332 the definition of IPSP is as follows: > > > > IP Server Process (IPSP) - A process instance of an IP-based > > application. An IPSP is essentially the same as an ASP, except that > > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > > not use the services of a Signalling Gateway node. > > > > Which clearly states that that IPSP is equivalent of ASP. I am > [TOLGA]The similarity between ASP and IPSP is that both of them > are hosting > application logic. OTOH the state machines and message semantics are not > equivalent. So, I wouldn't say that IPSP is equal to ASP -nor would I say > that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, just > that -all > that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be wrong > to speak of > DE-IPSP = ASPF + SGPF-. > > NOT sure why > > I would use IPSP for SGs. > > SGP functionality should always be in SGs. Can I have SGPs even on nodes > > that are NOT Signaling Gateways ? > > > > > > > > Let's take the following simple example. > > I have picked this example because the Rel 5 3GPP standards use > M3UA over > > SCTP at its Core Network Signaling transport side (SCCP is the ONLY M3UA > > User). And as per the specs (29.202), it speaks about IPSP > considerations > > for all the nodes (eg. RNC, SGSN...). It terms each M3UA node (eg. RNC, > > SGSN...) as "IP Node using M3UA User". > > > > There is a seperate Requirement for SGs in the 3GPP standards. > They follow > > the SGP Requirements. > > Essentially, both the peers will work in the pure IPSP-IPSP > mode (peer to > > peer mode). > > > > I have never seen a mention of SE and DE as I feel that this > has been left > > to implementation and various configurations that one might > want to choose > > (Loadshared or Override) > [TOLGA]I think the main reason for why you don't see much about SE/DE mode > in 3GPP documents is because SE/DE conmcept was not defined at that time. > Initially we had only SE-mode of operation. > > > > > > ******** IP ******** > > * IPSP * * IPSP * > > ******** ******** > > > > +------+ +------+ > > |SCCP- | |SCCP- | > > | User | | User | > > +------+ +------+ > > | SCCP | | SCCP | > > +------+ +------+ > > | M3UA | | M3UA | > > +------+ +------+ > > | SCTP | | SCTP | > > +------+ +------+ > > | IP | | IP | > > +------+ +------+ > > |________________| > > > > > > shashank > > > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Tuesday, November 08, 2005 7:19 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Brian, > > > > [..snip..] > > > > Regarding the issue we are discussing in this thread -being > > > able to support > > > > traffic mode in both directions-I think it is a nice thing to > > > have, because > > > > we have application logic at both sides, which may want to > > use different > > > > traffic . > > > > > > Again, the IPSP acting as an SGP in SE mode is not required to > > > have a traffic > > > mode. > > > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic > > > mode to place in > > > the ASPAC Ack. Any traffic distribution towards the SGP is an > > > SG-wide attribute > > > and does not differ from AS to AS, nor ASP to ASP. > > [TOLGA]I believe we have another one of those "rare" situations where > > neither you nor I can convince the other one ;-) I think the options and > > supporting arguments are as follows: > > > > a)We don't need traffic mode bothways for SE-IPSP, because one > of SE-IPSPs > > is mimicing a SGP and SGPs do not have traffic mode. > > > > b)We need traffic mode bothways, because both sides have > > application logic, > > which can have different trafic mode characteristics. (Shashank's > > position) > > > > I subscribe to b) and as far as I understand you support a). I think we > > need to hear more from other people about this issue so that we > > can reach a > > conclusion. > > > > > > Thanks, > > Tolga > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 08:28:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZpzr-0004gs-VH; Wed, 09 Nov 2005 08:28:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZpzo-0004gi-Iz for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 08:28:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09114 for ; Wed, 9 Nov 2005 08:27:45 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZqFp-0004M7-Lr for sigtran@ietf.org; Wed, 09 Nov 2005 08:44:46 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9DS1lk029757 for ; Wed, 9 Nov 2005 08:28:03 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow Date: Wed, 9 Nov 2005 08:09:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051109032440.A11934@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Wednesday, November 09, 2005 5:25 AM > To: Prasad, Shashank S (Shashank) > Cc: sigtran@ietf.org; 'Tolga Asveren' > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > For M3UA, ASPF is essentially an M3UA shim and an MTP-User. Two ASPF > can no longer communicate with each other than can two MTP-Users without > an underlying MTP provider (the SGPF). > > Tolga's view (if I'm right) is: > > IPSP A IPSP B > ___________ ___________ > | _______ | | _______ | > | | | | | | | | > | | IPSPF |----------------------|-| IPSPF | | > | |_______| | Association | |_______| | > |___________| |___________| > > However, this IPSPF is nowhere defined. [TOLGA]You are right that this is my view of IPSP, SE-IPSP to be more precise. OTOH I would disagree with you that this IPSP is nowhere defined. My interpretation of SE-IPSP as defined in the specification right now is the above architecture. It has a state machine and messaging rules defined for it. OTOH, neither the state machine nor the messaging rules are equivalent neither to ASP nor to SGP, e.g. IPSP can both send and receive ASPAC, does not use SSNM. As long as we agree *how* it works, naming it this way or that way is not really that important, as long as that naming issues don't slip into the specification. > > We had long discussions about this. When RFC 3332 was advanced we knew > that there were rather severe limitations with the IPSP models in RFC > 3332. We advanced the RFC anyway. The WG agreed that we would offer > IPSP as an extension draft. We largely decided that a new protocol > (perhaps using the same message set) was required for true peer-to-peer > communication. It looked like this: > > IPSP A IPSP B > ___________ ___________ > | _______ | | _______ | > | | | | | | | | > | | ASPF | | | | ASPF | | > | |_______| | | |_______| | > | | | | | | > | ___|___ | | ___|___ | > | | | | Association | | | | > | | SGPF |-|--------------------|-| SGPF | | > | |_______| | | |_______| | > |___________| |___________| > > Which is rougly equivalent to: > > IPSP A IPSP B > ___________ ___________ > | _______ | | _______ | > | | | | | | | | > | | IPSPF |----------------------|-| IPSPF | | > | |_______| | Association | |_______| | > |___________| |___________| > > IIRC we called it an SG-SG IPSP. It is even covered in the framework > document. Tolga wrote a draft. At some meeting it was supposed to > become a WG item. It died. > > rfc3332bis was advanced without repairing IPSP (but at least removing > some glaring errors from RFC 3332, yet introducing others). > > If one really wants to repair IPSP, it might be an idea to revive the > SG-SG draft and do IPSP properly. > > I can whip up a draft if anyone is truly interested. > > --brian > > Prasad, Shashank S (Shashank) wrote: (Wed, 09 Nov 2005 > 15:24:23) > > OK... > > On the technical terms defined by the standard, there is no difference > > between IPSPs and ASPs, except that it is used Point-2-Point > and do NOT use > > SGs in between. > > Of course, IPSP is NOT an SGP...that's for sure. > > > > Here the definition of IPSP verbatim from specs.... > > > > IP Server Process (IPSP) - A process instance of an IP-based > > application. An IPSP is essentially the same as an ASP, except that > > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > > not use the services of a Signalling Gateway node. > > > > > > > > > > ---- Picked from ur last mail ---- > > [TOLGA]The similarity between ASP and IPSP is that both of them > are hosting > > application logic. OTOH the state machines and message semantics are not > > equivalent. So, I wouldn't say that IPSP is equal to ASP -nor > would I say > > that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, > just that -all > > that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be > wrong to speak of > > DE-IPSP = ASPF + SGPF-. > > > > > > U said that the state machines and message semantics are NOT equivalent. > > Looking at the specs, I did NOT find any state machine > differences between > > ASPs and IPSPs too. > > > > I think the main contention that I have with u and Brian is that the > > definitions of IPSPs. > > U defined the modes based of the functionality of the IPSP. I > was delinking > > the modes from the definition of IPSPs. > > > > > > Ur view of IPSPs in Single Ended (SE) mode (picking up from some old > > threads) > > > > > > IPSP A IPSP B > > ___________ ___________ > > | | | | > > | _______ | | _______ | > > | | | | | | | | > > | | ASPF | | | | ASPF | | > > | |_______| | | |_______| | > > | | | Association | | | > > | | __|____________________|__/ | > > | | / | | | > > | ___|_|_ | | _______ | > > | | | | | | | | > > | | SGPF | | | | SGPF | | > > | |_______| | | |_______| | > > | | | | > > |___________| |___________| > > > > > > And I think that we can also define IPSPs as follows and still > have the SE > > and DE configuration for both :) > > > > IPSP A IPSP B > > ___________ ___________ > > | | | | > > | _______ | | _______ | > > | | | | | | | | > > | | ASPF |----------------------|-| ASPF | | > > | |_______| | | |_______| | > > | | Association | | > > | | | | > > | | | | > > |___________| |___________| > > > > > > Any inputs on my interpretation of my IPSP definition from the RFC 3332 > > perspective ? > > > > > > Thanx. > > shashank > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Wednesday, November 09, 2005 1:17 AM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Tuesday, November 08, 2005 2:48 PM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Tolga, Brian, > > > I was going thru ur last mails and ur old discussions. > > > ( This mail is slightly long..excuse me for that ). > > > > > > I see new terms ASPF and SGPF. I haven't seen these terms in > the RFC 3332. > > > I guess, they mean ASP and SGP Function only and there is NOT really > > > something more than our understanding of ASP and SGPs. Am I right ? > > [TOLGA]We use the terms ASPF and SGPF to refer to the correspondign > > functionality in M3UA stack. > > > > > > > > > I also read all along (in this discussion and the thread > mails) that IPSP > > > can act as an SGP or an ASP. > > > This really confuses me. And may be I need additional clarification. > > > > > > > > > As stated in RFC 3332 the definition of IPSP is as follows: > > > > > > IP Server Process (IPSP) - A process instance of an IP-based > > > application. An IPSP is essentially the same as an ASP, > except that > > > it uses M3UA in a point-to-point fashion. Conceptually, > an IPSP does > > > not use the services of a Signalling Gateway node. > > > > > > Which clearly states that that IPSP is equivalent of ASP. I am > > [TOLGA]The similarity between ASP and IPSP is that both of them > are hosting > > application logic. OTOH the state machines and message semantics are not > > equivalent. So, I wouldn't say that IPSP is equal to ASP -nor > would I say > > that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, > just that -all > > that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be > wrong to speak of > > DE-IPSP = ASPF + SGPF-. > > > NOT sure why > > > I would use IPSP for SGs. > > > SGP functionality should always be in SGs. Can I have SGPs > even on nodes > > > that are NOT Signaling Gateways ? > > > > > > > > > > > > Let's take the following simple example. > > > I have picked this example because the Rel 5 3GPP standards > use M3UA over > > > SCTP at its Core Network Signaling transport side (SCCP is > the ONLY M3UA > > > User). And as per the specs (29.202), it speaks about IPSP > considerations > > > for all the nodes (eg. RNC, SGSN...). It terms each M3UA node > (eg. RNC, > > > SGSN...) as "IP Node using M3UA User". > > > > > > There is a seperate Requirement for SGs in the 3GPP > standards. They follow > > > the SGP Requirements. > > > Essentially, both the peers will work in the pure IPSP-IPSP > mode (peer to > > > peer mode). > > > > > > I have never seen a mention of SE and DE as I feel that this > has been left > > > to implementation and various configurations that one might > want to choose > > > (Loadshared or Override) > > [TOLGA]I think the main reason for why you don't see much about > SE/DE mode > > in 3GPP documents is because SE/DE conmcept was not defined at > that time. > > Initially we had only SE-mode of operation. > > > > > > > > > ******** IP ******** > > > * IPSP * * IPSP * > > > ******** ******** > > > > > > +------+ +------+ > > > |SCCP- | |SCCP- | > > > | User | | User | > > > +------+ +------+ > > > | SCCP | | SCCP | > > > +------+ +------+ > > > | M3UA | | M3UA | > > > +------+ +------+ > > > | SCTP | | SCTP | > > > +------+ +------+ > > > | IP | | IP | > > > +------+ +------+ > > > |________________| > > > > > > > > > shashank > > > > > > > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Tolga Asveren > > > Sent: Tuesday, November 08, 2005 7:19 PM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Brian, > > > > > > [..snip..] > > > > > Regarding the issue we are discussing in this thread -being > > > > able to support > > > > > traffic mode in both directions-I think it is a nice thing to > > > > have, because > > > > > we have application logic at both sides, which may want to > > > use different > > > > > traffic . > > > > > > > > Again, the IPSP acting as an SGP in SE mode is not required to > > > > have a traffic > > > > mode. > > > > > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic > > > > mode to place in > > > > the ASPAC Ack. Any traffic distribution towards the SGP is an > > > > SG-wide attribute > > > > and does not differ from AS to AS, nor ASP to ASP. > > > [TOLGA]I believe we have another one of those "rare" situations where > > > neither you nor I can convince the other one ;-) I think the > options and > > > supporting arguments are as follows: > > > > > > a)We don't need traffic mode bothways for SE-IPSP, because > one of SE-IPSPs > > > is mimicing a SGP and SGPs do not have traffic mode. > > > > > > b)We need traffic mode bothways, because both sides have > > > application logic, > > > which can have different trafic mode characteristics. (Shashank's > > > position) > > > > > > I subscribe to b) and as far as I understand you support a). > I think we > > > need to hear more from other people about this issue so that we > > > can reach a > > > conclusion. > > > > > > > > > Thanks, > > > Tolga > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > -- > 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 Nov 09 09:41:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZr95-0000EE-8o; Wed, 09 Nov 2005 09:41:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZr92-00006l-4O for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 09:41:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13269 for ; Wed, 9 Nov 2005 09:41:20 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZrP3-0006Np-P2 for sigtran@ietf.org; Wed, 09 Nov 2005 09:58:22 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 09 Nov 2005 06:41:39 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,307,1125903600"; d="scan'208"; a="14795362:sNHT38805564" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA9EfCn4027766; Wed, 9 Nov 2005 09:41:34 -0500 (EST) Received: from xmb-rtp-209.amer.cisco.com ([64.102.31.11]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 09:41:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 09:41:32 -0500 Message-ID: <542F2F9C2CDE6B40A775125727674ECAD4F851@xmb-rtp-209.amer.cisco.com> Thread-Topic: [Sigtran] SE-IPSP definition Thread-Index: AcXkcWTA/1vOcE8bTy+liK2C9St4eAAyae7w From: "Ken A Morneault \(kmorneau\)" To: "Tolga Asveren" , X-OriginalArrivalTime: 09 Nov 2005 14:41:34.0134 (UTC) FILETIME=[AE60D560:01C5E53B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi Tolga, Sorry for the delayed response. I took some time off. Regarding the IPSP text, that is an area that Javier updated. At this point, I'm not sure if we will be able to change the text. The document is supposed to be heading to the Editor's queue to be published.=20 Regards, Ken -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Tolga Asveren Sent: Tuesday, November 08, 2005 9:13 AM To: sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition A few typo scorrected below. > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Tuesday, November 08, 2005 8:35 AM > To: sigtran@ietf.org > Subject: [Sigtran] SE-IPSP definition > > > Brian, > > -changed the subject of the thread- > > Ken, I re-checked and current bis document seems to be updated=20 > partially > (4.3 has the definition I copy/pasted below -which is fine-, OTOH=20 > still there is text mentioning about C-IPSP, D-IPSP for SE-model. The=20 > idea probably was to assign roles to IPSPS per "transaction", i.e. a=20 > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I believe the=20 > concept of "client" > and "server" can be misleading because it can be considered as one=20 > IPSP always playing client or server role while communicating with a=20 > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than=20 > clarify. > > Brian, more comments below. > > Tolga > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Brian F. G. Bidulock > > Sent: Monday, November 07, 2005 7:52 PM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Tolga, > > > > Tolga Asveren wrote: > > (Mon, 07 Nov 2005 14:36:07) > > > > --X--snip--X-- > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > resolution - Part > > > 1&2" thread -which has happened later than the thread you > > mentioned ;-) -, > > > you will see that everybody involved in the discussion > > "Valerie, you, myself > > > and Javier" agreed to return to the original SE-IPSP model. The > > conclusion > > > was to use the text proposed by Valerie. It seems the bis > > document is not > > > updated accordingly. Ken, was there a technical objection for that > > > change -actually I would call it reverting back to the original > > model- or is > > > this just an oversight? > > > > Really? Did you mean in "M3UAbis - consensus on comment resolution" > > 23 Aug 2004 where Valerie says: > > > > IPSP-SE behaviour: > > The IPSP acting as the SGP must sends ASPAC-ack only when its side=20 > > of the RK is ready. The IPSP acting as the ASP is responsible to=20 > > retry the ASPAC until the remote peer is ready. > > When the IPSP acting as the SGP wants to stop application traffic=20 > > from its side, it must send ASPIA-ack. > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis -=20 > consensus on comment resoluti on-Part 1&2" > > 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM > or ASPSM messages is needed to change the IPSP state. This means > that a set of request from one end and acknowledge from the other > will be enough. The RK must define both sides of the traffic flow. > Each exchange of ASPTM or ASPSM messages can be initiated by either > IPSP. For this exchange, the initiating IPSP follows the procedures > described in section 4.3.1. > > The above is the original concept we defined for SE-IPSP mode. > There are no > predefined client/server relationship, a pure peer-to-peer relationship. > > > > Or did you mean where we agreed to back out of the v03 changes=20 > > (which is what I think you are referring to with the IPSPF) and go=20 > > back to the > > v02 description > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As long=20 > as the problem is how you and I name it, there is no problem from=20 > specification point of view but I would call it IPSPF because it has a > different machine ^^^^^^^^^ state machine > than SGPF and ASPF and does not send/receive messages. I believe ^^^^^^^^^ certain messages, e.g. SSNM > you use the > term SGPF in the context of a "transaction" not inthe context of the=20 > overall realtionship between two peer IPSPs. > > > > --brian > > > > > > > > Considering the way it is supposed to work, i.e. according to > > the text we > > > had concensus on, we can't speak of exact SGPF semantics for > > SE-IPSP even > > > from basic message exchange point of view, e.g. SGPF does not > > send ASPAC, > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > sides can send > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a=20 > > > peer-to-peer relationship, not a client/server relationship. > > > > See Valerie's description above. As I have mantained, it is clear=20 > > that one IPSP acts in an SGP role and the other in an ASP role. > > > > > > > > Regarding the issue we are discussing in this thread -being > > able to support > > > traffic mode in both directions-I think it is a nice thing to > > have, because > > > we have application logic at both sides, which may want to > use different > > > traffic . > > > > Again, the IPSP acting as an SGP in SE mode is not required to have=20 > > a traffic mode. > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic mode > > to place in the ASPAC Ack. Any traffic distribution towards the SGP > > is an SG-wide attribute and does not differ from AS to AS, nor ASP=20 > > to ASP. > > > > --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 > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 10:07:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZrYM-0007wo-HC; Wed, 09 Nov 2005 10:07:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZrYL-0007wJ-Bn for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 10:07:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14617 for ; Wed, 9 Nov 2005 10:07:29 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZroL-00071q-ER for sigtran@ietf.org; Wed, 09 Nov 2005 10:24:31 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA9F7jHX020633; Wed, 9 Nov 2005 09:07:46 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Nov 2005 20:37:44 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB68C5@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: "'Ken A Morneault (kmorneau)'" , Tolga Asveren , sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 20:37:43 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ken, There is a serious issue in understanding the differences in IPSP and what it means. I am sure that u would have gone thru the mails where serious issues of IPSP understanding is evident. I feel that it should be resolved in the next draft before anything else. An extention draft must include IPSP considerations. shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Ken A Morneault (kmorneau) Sent: Wednesday, November 09, 2005 8:12 PM To: Tolga Asveren; sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition Hi Tolga, Sorry for the delayed response. I took some time off. Regarding the IPSP text, that is an area that Javier updated. At this point, I'm not sure if we will be able to change the text. The document is supposed to be heading to the Editor's queue to be published. Regards, Ken -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Tolga Asveren Sent: Tuesday, November 08, 2005 9:13 AM To: sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition A few typo scorrected below. > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Tuesday, November 08, 2005 8:35 AM > To: sigtran@ietf.org > Subject: [Sigtran] SE-IPSP definition > > > Brian, > > -changed the subject of the thread- > > Ken, I re-checked and current bis document seems to be updated > partially > (4.3 has the definition I copy/pasted below -which is fine-, OTOH > still there is text mentioning about C-IPSP, D-IPSP for SE-model. The > idea probably was to assign roles to IPSPS per "transaction", i.e. a > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I believe the > concept of "client" > and "server" can be misleading because it can be considered as one > IPSP always playing client or server role while communicating with a > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than > clarify. > > Brian, more comments below. > > Tolga > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Brian F. G. Bidulock > > Sent: Monday, November 07, 2005 7:52 PM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Tolga, > > > > Tolga Asveren wrote: > > (Mon, 07 Nov 2005 14:36:07) > > > > --X--snip--X-- > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > resolution - Part > > > 1&2" thread -which has happened later than the thread you > > mentioned ;-) -, > > > you will see that everybody involved in the discussion > > "Valerie, you, myself > > > and Javier" agreed to return to the original SE-IPSP model. The > > conclusion > > > was to use the text proposed by Valerie. It seems the bis > > document is not > > > updated accordingly. Ken, was there a technical objection for that > > > change -actually I would call it reverting back to the original > > model- or is > > > this just an oversight? > > > > Really? Did you mean in "M3UAbis - consensus on comment resolution" > > 23 Aug 2004 where Valerie says: > > > > IPSP-SE behaviour: > > The IPSP acting as the SGP must sends ASPAC-ack only when its side > > of the RK is ready. The IPSP acting as the ASP is responsible to > > retry the ASPAC until the remote peer is ready. > > When the IPSP acting as the SGP wants to stop application traffic > > from its side, it must send ASPIA-ack. > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - > consensus on comment resoluti on-Part 1&2" > > 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM > or ASPSM messages is needed to change the IPSP state. This means > that a set of request from one end and acknowledge from the other > will be enough. The RK must define both sides of the traffic flow. > Each exchange of ASPTM or ASPSM messages can be initiated by either > IPSP. For this exchange, the initiating IPSP follows the procedures > described in section 4.3.1. > > The above is the original concept we defined for SE-IPSP mode. > There are no > predefined client/server relationship, a pure peer-to-peer relationship. > > > > Or did you mean where we agreed to back out of the v03 changes > > (which is what I think you are referring to with the IPSPF) and go > > back to the > > v02 description > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As long > as the problem is how you and I name it, there is no problem from > specification point of view but I would call it IPSPF because it has a > different machine ^^^^^^^^^ state machine > than SGPF and ASPF and does not send/receive messages. I believe ^^^^^^^^^ certain messages, e.g. SSNM > you use the > term SGPF in the context of a "transaction" not inthe context of the > overall realtionship between two peer IPSPs. > > > > --brian > > > > > > > > Considering the way it is supposed to work, i.e. according to > > the text we > > > had concensus on, we can't speak of exact SGPF semantics for > > SE-IPSP even > > > from basic message exchange point of view, e.g. SGPF does not > > send ASPAC, > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > sides can send > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a > > > peer-to-peer relationship, not a client/server relationship. > > > > See Valerie's description above. As I have mantained, it is clear > > that one IPSP acts in an SGP role and the other in an ASP role. > > > > > > > > Regarding the issue we are discussing in this thread -being > > able to support > > > traffic mode in both directions-I think it is a nice thing to > > have, because > > > we have application logic at both sides, which may want to > use different > > > traffic . > > > > Again, the IPSP acting as an SGP in SE mode is not required to have > > a traffic mode. > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic mode > > to place in the ASPAC Ack. Any traffic distribution towards the SGP > > is an SG-wide attribute and does not differ from AS to AS, nor ASP > > to ASP. > > > > --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 > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 10:15:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZrfD-0001ZN-Tj; Wed, 09 Nov 2005 10:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZrfA-0001YS-PT for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 10:15:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14986 for ; Wed, 9 Nov 2005 10:14:32 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZrvC-0007CV-NU for sigtran@ietf.org; Wed, 09 Nov 2005 10:31:35 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9FEg26011898 for ; Wed, 9 Nov 2005 10:14:45 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 09:56:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB68C5@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, I don't think there is as significant issue as you mention. As far as I can see, some text cleanup is the only thing we need-to get rid of C/SE-IPSP , S/SE-IPSP distinction-. The original problem you mentioned -having traffic mode bothways- is something useful IMO as well. That can be added to the document but it does not change anything architecturally in terms of IPSP as defined in the document. What other issues do you consider as problems associated with IPSP? Tolga > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Wednesday, November 09, 2005 10:08 AM > To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Ken, > There is a serious issue in understanding the differences in IPSP and what > it means. > I am sure that u would have gone thru the mails where serious > issues of IPSP > understanding is evident. > > I feel that it should be resolved in the next draft before anything else. > An extention draft must include IPSP considerations. > > shashank > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Ken A Morneault (kmorneau) > Sent: Wednesday, November 09, 2005 8:12 PM > To: Tolga Asveren; sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > > > Hi Tolga, > > Sorry for the delayed response. I took some time off. > > Regarding the IPSP text, that is an area that Javier > updated. At this point, I'm not sure if we will be > able to change the text. The document is supposed to > be heading to the Editor's queue to be published. > > Regards, > > Ken > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Tolga Asveren > Sent: Tuesday, November 08, 2005 9:13 AM > To: sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > A few typo scorrected below. > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Tuesday, November 08, 2005 8:35 AM > > To: sigtran@ietf.org > > Subject: [Sigtran] SE-IPSP definition > > > > > > Brian, > > > > -changed the subject of the thread- > > > > Ken, I re-checked and current bis document seems to be updated > > partially > > (4.3 has the definition I copy/pasted below -which is fine-, OTOH > > still there is text mentioning about C-IPSP, D-IPSP for SE-model. The > > idea probably was to assign roles to IPSPS per "transaction", i.e. a > > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I believe the > > concept of "client" > > and "server" can be misleading because it can be considered as one > > IPSP always playing client or server role while communicating with a > > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than > > clarify. > > > > Brian, more comments below. > > > > Tolga > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Brian F. G. Bidulock > > > Sent: Monday, November 07, 2005 7:52 PM > > > To: Tolga Asveren > > > Cc: sigtran@ietf.org > > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Tolga, > > > > > > Tolga Asveren wrote: > > > (Mon, 07 Nov 2005 14:36:07) > > > > > > --X--snip--X-- > > > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > > resolution - Part > > > > 1&2" thread -which has happened later than the thread you > > > mentioned ;-) -, > > > > you will see that everybody involved in the discussion > > > "Valerie, you, myself > > > > and Javier" agreed to return to the original SE-IPSP model. The > > > conclusion > > > > was to use the text proposed by Valerie. It seems the bis > > > document is not > > > > updated accordingly. Ken, was there a technical objection for that > > > > > change -actually I would call it reverting back to the original > > > model- or is > > > > this just an oversight? > > > > > > Really? Did you mean in "M3UAbis - consensus on comment resolution" > > > > 23 Aug 2004 where Valerie says: > > > > > > IPSP-SE behaviour: > > > The IPSP acting as the SGP must sends ASPAC-ack only when its side > > > of the RK is ready. The IPSP acting as the ASP is responsible to > > > retry the ASPAC until the remote peer is ready. > > > When the IPSP acting as the SGP wants to stop application traffic > > > from its side, it must send ASPIA-ack. > > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - > > consensus on comment resoluti on-Part 1&2" > > > > 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM > > or ASPSM messages is needed to change the IPSP state. This means > > that a set of request from one end and acknowledge from the > other > > will be enough. The RK must define both sides of the traffic > flow. > > Each exchange of ASPTM or ASPSM messages can be initiated by > either > > IPSP. For this exchange, the initiating IPSP follows the > procedures > > described in section 4.3.1. > > > > The above is the original concept we defined for SE-IPSP mode. > > There are no > > predefined client/server relationship, a pure peer-to-peer > relationship. > > > > > > Or did you mean where we agreed to back out of the v03 changes > > > (which is what I think you are referring to with the IPSPF) and go > > > back to the > > > v02 description > > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > > [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As long > > as the problem is how you and I name it, there is no problem from > > specification point of view but I would call it IPSPF because it has a > > > different machine > > ^^^^^^^^^ > state > machine > > than SGPF and ASPF and does not send/receive messages. I believe > ^^^^^^^^^ > certain messages, e.g. SSNM > > you use the > > term SGPF in the context of a "transaction" not inthe context of the > > overall realtionship between two peer IPSPs. > > > > > > --brian > > > > > > > > > > > Considering the way it is supposed to work, i.e. according to > > > the text we > > > > had concensus on, we can't speak of exact SGPF semantics for > > > SE-IPSP even > > > > from basic message exchange point of view, e.g. SGPF does not > > > send ASPAC, > > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > > sides can send > > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a > > > > peer-to-peer relationship, not a client/server relationship. > > > > > > See Valerie's description above. As I have mantained, it is clear > > > that one IPSP acts in an SGP role and the other in an ASP role. > > > > > > > > > > > Regarding the issue we are discussing in this thread -being > > > able to support > > > > traffic mode in both directions-I think it is a nice thing to > > > have, because > > > > we have application logic at both sides, which may want to > > use different > > > > traffic . > > > > > > Again, the IPSP acting as an SGP in SE mode is not required to have > > > a traffic mode. > > > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic mode > > > > to place in the ASPAC Ack. Any traffic distribution towards the SGP > > > > is an SG-wide attribute and does not differ from AS to AS, nor ASP > > > to ASP. > > > > > > --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 > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 10:36:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZs08-0007YP-Te; Wed, 09 Nov 2005 10:36:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZs07-0007Y7-FW for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 10:36:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16160 for ; Wed, 9 Nov 2005 10:36:11 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZsG9-0007nb-6g for sigtran@ietf.org; Wed, 09 Nov 2005 10:53:13 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA9FaTFH017318; Wed, 9 Nov 2005 09:36:30 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Nov 2005 21:06:27 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB68C6@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: "'Tolga Asveren'" , sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 21:06:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, My issues: I am NOT able to understand the following IPSP model that Brian had said :) I felt that an IPSP can have ASPF and SGPF but an ASPF using the services of SGPF was NOT very clear. IPSP A IPSP B ___________ ___________ | _______ | | _______ | | | | | | | | | | | ASPF | | | | ASPF | | | |_______| | | |_______| | | | | | | | | ___|___ | | ___|___ | | | | | Association | | | | | | SGPF |-|--------------------|-| SGPF | | | |_______| | | |_______| | |___________| |___________| Next is that u said that IPSP do NOT use SSNM messages. I did NOT read anywhere explicit in the specs. Even the 3GPP standards want IPSPs to receive and send DUPU and SCON :). About the Traffic Mode both ways in SE: We should surely add that enhancement suggested. My proposal was NOT based on a different premise. I never had an ASPF using the services of SGPF. May be the spec should draw these diagrams... I had asked a question before: How would ur model fit in assuming that I have two peers sending SCCP messages to each other over an association ? +------+ +------+ |SCCP- | |SCCP- | | User | | User | +------+ +------+ | SCCP | | SCCP | +------+ +------+ | M3UA | | M3UA | +------+ +------+ | SCTP | | SCTP | +------+ +------+ | IP | | IP | +------+ +------+ BTW, what is C/SE-IPSP and D/SE-IPSP shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Wednesday, November 09, 2005 8:26 PM To: sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition Shashank, I don't think there is as significant issue as you mention. As far as I can see, some text cleanup is the only thing we need-to get rid of C/SE-IPSP , S/SE-IPSP distinction-. The original problem you mentioned -having traffic mode bothways- is something useful IMO as well. That can be added to the document but it does not change anything architecturally in terms of IPSP as defined in the document. What other issues do you consider as problems associated with IPSP? Tolga > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Wednesday, November 09, 2005 10:08 AM > To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Ken, > There is a serious issue in understanding the differences in IPSP and what > it means. > I am sure that u would have gone thru the mails where serious > issues of IPSP > understanding is evident. > > I feel that it should be resolved in the next draft before anything else. > An extention draft must include IPSP considerations. > > shashank > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Ken A Morneault (kmorneau) > Sent: Wednesday, November 09, 2005 8:12 PM > To: Tolga Asveren; sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > > > Hi Tolga, > > Sorry for the delayed response. I took some time off. > > Regarding the IPSP text, that is an area that Javier > updated. At this point, I'm not sure if we will be > able to change the text. The document is supposed to > be heading to the Editor's queue to be published. > > Regards, > > Ken > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Tolga Asveren > Sent: Tuesday, November 08, 2005 9:13 AM > To: sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > A few typo scorrected below. > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Tuesday, November 08, 2005 8:35 AM > > To: sigtran@ietf.org > > Subject: [Sigtran] SE-IPSP definition > > > > > > Brian, > > > > -changed the subject of the thread- > > > > Ken, I re-checked and current bis document seems to be updated > > partially > > (4.3 has the definition I copy/pasted below -which is fine-, OTOH > > still there is text mentioning about C-IPSP, D-IPSP for SE-model. The > > idea probably was to assign roles to IPSPS per "transaction", i.e. a > > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I believe the > > concept of "client" > > and "server" can be misleading because it can be considered as one > > IPSP always playing client or server role while communicating with a > > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than > > clarify. > > > > Brian, more comments below. > > > > Tolga > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Brian F. G. Bidulock > > > Sent: Monday, November 07, 2005 7:52 PM > > > To: Tolga Asveren > > > Cc: sigtran@ietf.org > > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Tolga, > > > > > > Tolga Asveren wrote: > > > (Mon, 07 Nov 2005 14:36:07) > > > > > > --X--snip--X-- > > > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > > resolution - Part > > > > 1&2" thread -which has happened later than the thread you > > > mentioned ;-) -, > > > > you will see that everybody involved in the discussion > > > "Valerie, you, myself > > > > and Javier" agreed to return to the original SE-IPSP model. The > > > conclusion > > > > was to use the text proposed by Valerie. It seems the bis > > > document is not > > > > updated accordingly. Ken, was there a technical objection for that > > > > > change -actually I would call it reverting back to the original > > > model- or is > > > > this just an oversight? > > > > > > Really? Did you mean in "M3UAbis - consensus on comment resolution" > > > > 23 Aug 2004 where Valerie says: > > > > > > IPSP-SE behaviour: > > > The IPSP acting as the SGP must sends ASPAC-ack only when its side > > > of the RK is ready. The IPSP acting as the ASP is responsible to > > > retry the ASPAC until the remote peer is ready. > > > When the IPSP acting as the SGP wants to stop application traffic > > > from its side, it must send ASPIA-ack. > > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - > > consensus on comment resoluti on-Part 1&2" > > > > 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM > > or ASPSM messages is needed to change the IPSP state. This means > > that a set of request from one end and acknowledge from the > other > > will be enough. The RK must define both sides of the traffic > flow. > > Each exchange of ASPTM or ASPSM messages can be initiated by > either > > IPSP. For this exchange, the initiating IPSP follows the > procedures > > described in section 4.3.1. > > > > The above is the original concept we defined for SE-IPSP mode. > > There are no > > predefined client/server relationship, a pure peer-to-peer > relationship. > > > > > > Or did you mean where we agreed to back out of the v03 changes > > > (which is what I think you are referring to with the IPSPF) and go > > > back to the > > > v02 description > > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > > [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As long > > as the problem is how you and I name it, there is no problem from > > specification point of view but I would call it IPSPF because it has a > > > different machine > > ^^^^^^^^^ > state > machine > > than SGPF and ASPF and does not send/receive messages. I believe > ^^^^^^^^^ > certain messages, e.g. SSNM > > you use the > > term SGPF in the context of a "transaction" not inthe context of the > > overall realtionship between two peer IPSPs. > > > > > > --brian > > > > > > > > > > > Considering the way it is supposed to work, i.e. according to > > > the text we > > > > had concensus on, we can't speak of exact SGPF semantics for > > > SE-IPSP even > > > > from basic message exchange point of view, e.g. SGPF does not > > > send ASPAC, > > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > > sides can send > > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a > > > > peer-to-peer relationship, not a client/server relationship. > > > > > > See Valerie's description above. As I have mantained, it is clear > > > that one IPSP acts in an SGP role and the other in an ASP role. > > > > > > > > > > > Regarding the issue we are discussing in this thread -being > > > able to support > > > > traffic mode in both directions-I think it is a nice thing to > > > have, because > > > > we have application logic at both sides, which may want to > > use different > > > > traffic . > > > > > > Again, the IPSP acting as an SGP in SE mode is not required to have > > > a traffic mode. > > > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic mode > > > > to place in the ASPAC Ack. Any traffic distribution towards the SGP > > > > is an SG-wide attribute and does not differ from AS to AS, nor ASP > > > to ASP. > > > > > > --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 > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ 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 Nov 09 10:54:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZsHI-0004Qg-Jg; Wed, 09 Nov 2005 10:54:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZsHH-0004Qb-7x for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 10:54:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17562 for ; Wed, 9 Nov 2005 10:53:55 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZsXJ-0008QZ-EV for sigtran@ietf.org; Wed, 09 Nov 2005 11:10:58 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9Fs58G016479 for ; Wed, 9 Nov 2005 10:54:07 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 10:35:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB68C6@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Wednesday, November 09, 2005 10:36 AM > To: 'Tolga Asveren'; sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Tolga, > > My issues: > > I am NOT able to understand the following IPSP model that Brian > had said :) > I felt that an IPSP can have ASPF and SGPF but an ASPF using the > services of > SGPF was NOT very clear. > > IPSP A IPSP B > ___________ ___________ > | _______ | | _______ | > | | | | | | | | > | | ASPF | | | | ASPF | | > | |_______| | | |_______| | > | | | | | | > | ___|___ | | ___|___ | > | | | | Association | | | | > | | SGPF |-|--------------------|-| SGPF | | > | |_______| | | |_______| | > |___________| |___________| [TOLGA]The above model is not something existing in official specifications, i.e. it is nothing you should be concerned about in terms of understanding how IPSP as defined in exiting M3UA documents works. As Brian said, I wrote a draft -Brian also being another main contributor- but it did not become a WG item. I still think it is a good idea, mainly because it supports relaying. OTOH, I think SE-IPSP model works fine as well, but it does not have relaying capability -intentionally-. > > > Next is that u said that IPSP do NOT use SSNM messages. > I did NOT read anywhere explicit in the specs. Even the 3GPP > standards want > IPSPs to receive and send DUPU and SCON :). [TOLGA]Too bad for 3GPP, it shows that they did not fully understand the concept of IPSP. Availability for IPSP is managed by the state of AS, so no need for DUPU. For congestion, right now one needs to rely on SCTP congestion but Brian is working on a ASPCONG draft to define a new ASPTM message to convey AS congestion information. If it is not clear in the current document that SSNM is not to be used for IPSP, we may clarify this with a sentence. Actually lack of "IPSP Considerations" sections for SSNM related procedures also hints for not using SSNM for IPSP. If one want a model relying on SSNM, SG-SG communication is the way to go -which the draft I authored was about-. > > > About the Traffic Mode both ways in SE: > We should surely add that enhancement suggested. My proposal was NOT based > on a different premise. I never had an ASPF using the services of > SGPF. May > be the spec should draw these diagrams... > > > I had asked a question before: > How would ur model fit in assuming that I have two peers sending SCCP > messages to each other over an association ? > > +------+ +------+ > |SCCP- | |SCCP- | > | User | | User | > +------+ +------+ > | SCCP | | SCCP | > +------+ +------+ > | M3UA | | M3UA | > +------+ +------+ > | SCTP | | SCTP | > +------+ +------+ > | IP | | IP | > +------+ +------+ [TOLGA]I am not sure about what you are asking but both M3UA stacks perform functionality defined for M3UA-IPSP in the specification and that is it. > > > BTW, what is C/SE-IPSP and D/SE-IPSP [TOLGA]Something we need to get rid of :-) It refers to a SE-IPSP acting as client or server in the context of a "transaction", transaction meaning an ASPTM message pair exchange, e.g. ASPAC/ASPAC-ACK. IMO, it is extremely confusing. > > > shashank > > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Wednesday, November 09, 2005 8:26 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Shashank, > > I don't think there is as significant issue as you mention. As > far as I can > see, some text cleanup is the only thing we need-to get rid of C/SE-IPSP , > S/SE-IPSP distinction-. > > The original problem you mentioned -having traffic mode bothways- is > something useful IMO as well. That can be added to the document > but it does > not change anything architecturally in terms of IPSP as defined in the > document. > > What other issues do you consider as problems associated with IPSP? > > Tolga > > > -----Original Message----- > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > Sent: Wednesday, November 09, 2005 10:08 AM > > To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > Ken, > > There is a serious issue in understanding the differences in > IPSP and what > > it means. > > I am sure that u would have gone thru the mails where serious > > issues of IPSP > > understanding is evident. > > > > I feel that it should be resolved in the next draft before > anything else. > > An extention draft must include IPSP considerations. > > > > shashank > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Ken A Morneault (kmorneau) > > Sent: Wednesday, November 09, 2005 8:12 PM > > To: Tolga Asveren; sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > > > > > Hi Tolga, > > > > Sorry for the delayed response. I took some time off. > > > > Regarding the IPSP text, that is an area that Javier > > updated. At this point, I'm not sure if we will be > > able to change the text. The document is supposed to > > be heading to the Editor's queue to be published. > > > > Regards, > > > > Ken > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > > Behalf Of Tolga Asveren > > Sent: Tuesday, November 08, 2005 9:13 AM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > A few typo scorrected below. > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Tolga Asveren > > > Sent: Tuesday, November 08, 2005 8:35 AM > > > To: sigtran@ietf.org > > > Subject: [Sigtran] SE-IPSP definition > > > > > > > > > Brian, > > > > > > -changed the subject of the thread- > > > > > > Ken, I re-checked and current bis document seems to be updated > > > partially > > > (4.3 has the definition I copy/pasted below -which is fine-, OTOH > > > still there is text mentioning about C-IPSP, D-IPSP for SE-model. The > > > idea probably was to assign roles to IPSPS per "transaction", i.e. a > > > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I believe the > > > concept of "client" > > > and "server" can be misleading because it can be considered as one > > > IPSP always playing client or server role while communicating with a > > > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than > > > clarify. > > > > > > Brian, more comments below. > > > > > > Tolga > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Brian F. G. Bidulock > > > > Sent: Monday, November 07, 2005 7:52 PM > > > > To: Tolga Asveren > > > > Cc: sigtran@ietf.org > > > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Tolga, > > > > > > > > Tolga Asveren wrote: > > > > (Mon, 07 Nov 2005 14:36:07) > > > > > > > > --X--snip--X-- > > > > > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > > > resolution - Part > > > > > 1&2" thread -which has happened later than the thread you > > > > mentioned ;-) -, > > > > > you will see that everybody involved in the discussion > > > > "Valerie, you, myself > > > > > and Javier" agreed to return to the original SE-IPSP model. The > > > > conclusion > > > > > was to use the text proposed by Valerie. It seems the bis > > > > document is not > > > > > updated accordingly. Ken, was there a technical objection for that > > > > > > > change -actually I would call it reverting back to the original > > > > model- or is > > > > > this just an oversight? > > > > > > > > Really? Did you mean in "M3UAbis - consensus on comment resolution" > > > > > > 23 Aug 2004 where Valerie says: > > > > > > > > IPSP-SE behaviour: > > > > The IPSP acting as the SGP must sends ASPAC-ack only when its side > > > > of the RK is ready. The IPSP acting as the ASP is responsible to > > > > retry the ASPAC until the remote peer is ready. > > > > When the IPSP acting as the SGP wants to stop application traffic > > > > from its side, it must send ASPIA-ack. > > > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - > > > consensus on comment resoluti on-Part 1&2" > > > > > > 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM > > > or ASPSM messages is needed to change the IPSP state. This means > > > that a set of request from one end and acknowledge from the > > other > > > will be enough. The RK must define both sides of the traffic > > flow. > > > Each exchange of ASPTM or ASPSM messages can be initiated by > > either > > > IPSP. For this exchange, the initiating IPSP follows the > > procedures > > > described in section 4.3.1. > > > > > > The above is the original concept we defined for SE-IPSP mode. > > > There are no > > > predefined client/server relationship, a pure peer-to-peer > > relationship. > > > > > > > > Or did you mean where we agreed to back out of the v03 changes > > > > (which is what I think you are referring to with the IPSPF) and go > > > > back to the > > > > v02 description > > > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > > > [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As long > > > as the problem is how you and I name it, there is no problem from > > > specification point of view but I would call it IPSPF because it has a > > > > > different machine > > > > ^^^^^^^^^ > > state > > machine > > > than SGPF and ASPF and does not send/receive messages. I believe > > ^^^^^^^^^ > > certain messages, e.g. SSNM > > > you use the > > > term SGPF in the context of a "transaction" not inthe context of the > > > overall realtionship between two peer IPSPs. > > > > > > > > --brian > > > > > > > > > > > > > > Considering the way it is supposed to work, i.e. according to > > > > the text we > > > > > had concensus on, we can't speak of exact SGPF semantics for > > > > SE-IPSP even > > > > > from basic message exchange point of view, e.g. SGPF does not > > > > send ASPAC, > > > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > > > sides can send > > > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a > > > > > peer-to-peer relationship, not a client/server relationship. > > > > > > > > See Valerie's description above. As I have mantained, it is clear > > > > that one IPSP acts in an SGP role and the other in an ASP role. > > > > > > > > > > > > > > Regarding the issue we are discussing in this thread -being > > > > able to support > > > > > traffic mode in both directions-I think it is a nice thing to > > > > have, because > > > > > we have application logic at both sides, which may want to > > > use different > > > > > traffic . > > > > > > > > Again, the IPSP acting as an SGP in SE mode is not required to have > > > > a traffic mode. > > > > > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic mode > > > > > > to place in the ASPAC Ack. Any traffic distribution towards the SGP > > > > > > is an SG-wide attribute and does not differ from AS to AS, nor ASP > > > > to ASP. > > > > > > > > --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 > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > 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 Nov 09 11:29:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZspY-0006ON-QA; Wed, 09 Nov 2005 11:29:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZspW-0006O6-Q4 for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 11:29:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19758 for ; Wed, 9 Nov 2005 11:29:18 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZt5Z-00012L-7t for sigtran@ietf.org; Wed, 09 Nov 2005 11:46:21 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jA9GTaAp006431; Wed, 9 Nov 2005 10:29:37 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Nov 2005 16:29:34 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00CE6ED8D@en0033exch001u.uk.lucent.com> From: "Holland, Peter Michael (Peter)" To: "'Tolga Asveren'" , sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 16:29:33 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Concerning text clean up I see a couple of references to C-IPSP/D-IPSP that I assume should be removed. I also noticed several English problems with the numbered items at the start of 4.3. I can send updated text if you would like. Reading this thread the problem I see with SE procedures was identified in a mail where Brian said: >If you want both IPSPs to each have an AS an traffic mode, use DE instead of SE. Thus I understand there are situations where SE mode cannot be used. This is not clear in RFC. Concerning the inapplicability of SSNM message in IPSP mode, I definately think it would help if this was explicitly stated - this has been a subject on significant discussion in some fora. Thanks Pete > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: 09 November 2005 14:56 > To: sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Shashank, > > I don't think there is as significant issue as you mention. > As far as I can > see, some text cleanup is the only thing we need-to get rid > of C/SE-IPSP , > S/SE-IPSP distinction-. > > The original problem you mentioned -having traffic mode bothways- is > something useful IMO as well. That can be added to the > document but it does > not change anything architecturally in terms of IPSP as defined in the > document. > > What other issues do you consider as problems associated with IPSP? > > Tolga > > > -----Original Message----- > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > Sent: Wednesday, November 09, 2005 10:08 AM > > To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > Ken, > > There is a serious issue in understanding the differences > in IPSP and what > > it means. > > I am sure that u would have gone thru the mails where serious > > issues of IPSP > > understanding is evident. > > > > I feel that it should be resolved in the next draft before > anything else. > > An extention draft must include IPSP considerations. > > > > shashank > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Ken A Morneault (kmorneau) > > Sent: Wednesday, November 09, 2005 8:12 PM > > To: Tolga Asveren; sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > > > > > Hi Tolga, > > > > Sorry for the delayed response. I took some time off. > > > > Regarding the IPSP text, that is an area that Javier > > updated. At this point, I'm not sure if we will be > > able to change the text. The document is supposed to > > be heading to the Editor's queue to be published. > > > > Regards, > > > > Ken > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > > Behalf Of Tolga Asveren > > Sent: Tuesday, November 08, 2005 9:13 AM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > A few typo scorrected below. > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Tolga Asveren > > > Sent: Tuesday, November 08, 2005 8:35 AM > > > To: sigtran@ietf.org > > > Subject: [Sigtran] SE-IPSP definition > > > > > > > > > Brian, > > > > > > -changed the subject of the thread- > > > > > > Ken, I re-checked and current bis document seems to be updated > > > partially > > > (4.3 has the definition I copy/pasted below -which is fine-, OTOH > > > still there is text mentioning about C-IPSP, D-IPSP for > SE-model. The > > > idea probably was to assign roles to IPSPS per > "transaction", i.e. a > > > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I > believe the > > > concept of "client" > > > and "server" can be misleading because it can be considered as one > > > IPSP always playing client or server role while > communicating with a > > > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse > rather than > > > clarify. > > > > > > Brian, more comments below. > > > > > > Tolga > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org > [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Brian F. G. Bidulock > > > > Sent: Monday, November 07, 2005 7:52 PM > > > > To: Tolga Asveren > > > > Cc: sigtran@ietf.org > > > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Tolga, > > > > > > > > Tolga Asveren wrote: > > > > (Mon, 07 Nov 2005 14:36:07) > > > > > > > > --X--snip--X-- > > > > > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > > > resolution - Part > > > > > 1&2" thread -which has happened later than the thread you > > > > mentioned ;-) -, > > > > > you will see that everybody involved in the discussion > > > > "Valerie, you, myself > > > > > and Javier" agreed to return to the original SE-IPSP > model. The > > > > conclusion > > > > > was to use the text proposed by Valerie. It seems the bis > > > > document is not > > > > > updated accordingly. Ken, was there a technical > objection for that > > > > > > > change -actually I would call it reverting back to > the original > > > > model- or is > > > > > this just an oversight? > > > > > > > > Really? Did you mean in "M3UAbis - consensus on > comment resolution" > > > > > > 23 Aug 2004 where Valerie says: > > > > > > > > IPSP-SE behaviour: > > > > The IPSP acting as the SGP must sends ASPAC-ack only > when its side > > > > of the RK is ready. The IPSP acting as the ASP is > responsible to > > > > retry the ASPAC until the remote peer is ready. > > > > When the IPSP acting as the SGP wants to stop > application traffic > > > > from its side, it must send ASPIA-ack. > > > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - > > > consensus on comment resoluti on-Part 1&2" > > > > > > 1- IPSP Single Exchange (SE) model. Only a single > exchange of ASPTM > > > or ASPSM messages is needed to change the IPSP > state. This means > > > that a set of request from one end and acknowledge from the > > other > > > will be enough. The RK must define both sides of the traffic > > flow. > > > Each exchange of ASPTM or ASPSM messages can be initiated by > > either > > > IPSP. For this exchange, the initiating IPSP follows the > > procedures > > > described in section 4.3.1. > > > > > > The above is the original concept we defined for SE-IPSP mode. > > > There are no > > > predefined client/server relationship, a pure peer-to-peer > > relationship. > > > > > > > > Or did you mean where we agreed to back out of the v03 changes > > > > (which is what I think you are referring to with the > IPSPF) and go > > > > back to the > > > > v02 description > > > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > > > [TOLGA]No, what I mean as "IPSPF approach is v02 > definition. As long > > > as the problem is how you and I name it, there is no problem from > > > specification point of view but I would call it IPSPF > because it has a > > > > > different machine > > > > ^^^^^^^^^ > > > state > > machine > > > than SGPF and ASPF and does not send/receive messages. I believe > > ^^^^^^^^^ > > certain messages, e.g. SSNM > > > you use the > > > term SGPF in the context of a "transaction" not inthe > context of the > > > overall realtionship between two peer IPSPs. > > > > > > > > --brian > > > > > > > > > > > > > > Considering the way it is supposed to work, i.e. according to > > > > the text we > > > > > had concensus on, we can't speak of exact SGPF semantics for > > > > SE-IPSP even > > > > > from basic message exchange point of view, e.g. SGPF does not > > > > send ASPAC, > > > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > > > sides can send > > > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a > > > > > peer-to-peer relationship, not a client/server relationship. > > > > > > > > See Valerie's description above. As I have mantained, > it is clear > > > > that one IPSP acts in an SGP role and the other in an ASP role. > > > > > > > > > > > > > > Regarding the issue we are discussing in this thread -being > > > > able to support > > > > > traffic mode in both directions-I think it is a nice thing to > > > > have, because > > > > > we have application logic at both sides, which may want to > > > use different > > > > > traffic . > > > > > > > > Again, the IPSP acting as an SGP in SE mode is not > required to have > > > > a traffic mode. > > > > > > > > In the normal ASP/SGP exchange, the SGP does not have a > traffic mode > > > > > > to place in the ASPAC Ack. Any traffic distribution > towards the SGP > > > > > > is an SG-wide attribute and does not differ from AS to > AS, nor ASP > > > > to ASP. > > > > > > > > --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 > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > 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 Nov 09 11:41:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZt1G-0002HS-Te; Wed, 09 Nov 2005 11:41:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZt1F-0002H7-7j for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 11:41:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20679 for ; Wed, 9 Nov 2005 11:41:24 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZtHH-0001QX-PV for sigtran@ietf.org; Wed, 09 Nov 2005 11:58:28 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9GfUXW021989 for ; Wed, 9 Nov 2005 11:41:33 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 11:23:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <475FF955A05DD411980D00508B6D5FB00CE6ED8D@en0033exch001u.uk.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Pete, > -----Original Message----- > From: Holland, Peter Michael (Peter) [mailto:pmholland@lucent.com] > Sent: Wednesday, November 09, 2005 11:30 AM > To: 'Tolga Asveren'; sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Tolga, > Concerning text clean up I see a couple of references to > C-IPSP/D-IPSP that I assume should be removed. > I also noticed several English problems with the numbered > items at the start of 4.3. I can send updated text if you > would like. [TOLGA]Ken/Javier are the authors, i.e. the text is not under my control. OTOH based on Ken's last message, I have the impression that we can't have non-editorial changes anymore(?) Otherwise I would like to see C-IPSP/D-IPSP to be cleaned up as well. > > Reading this thread the problem I see with SE procedures was > identified in a mail where Brian said: > >If you want both IPSPs to each have an AS an traffic mode, use DE instead > of SE. > Thus I understand there are situations where SE mode cannot be > used. This is not clear in RFC. [TOLGA]No, this is not true, one can use SE-IPSP for any scenario. IMO, that traffic mode can't be specified bothways is something we need to add to the specification. > > Concerning the inapplicability of SSNM message in IPSP mode, I definately > think it would help if this was explicitly stated - this has been a > subject on significant discussion in some fora. [TOLGA]Ken, is it possible to have the following modification: In 3.1.2 Message Classes and Types: SS7 Signalling Network Management (SSNM) Messages (See Section 3.4)(Note: SSNM is not used for IPSP communication) I believe the above change could be considered as "editorial". ;-) It could be better to a a few sentectes why they are not used and how availability etc.. is to be handled for IPSP case but I don't know whether we are already too late for that. If not, I can provide text. > > Thanks > Pete > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: 09 November 2005 14:56 > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > Shashank, > > > > I don't think there is as significant issue as you mention. > > As far as I can > > see, some text cleanup is the only thing we need-to get rid > > of C/SE-IPSP , > > S/SE-IPSP distinction-. > > > > The original problem you mentioned -having traffic mode bothways- is > > something useful IMO as well. That can be added to the > > document but it does > > not change anything architecturally in terms of IPSP as defined in the > > document. > > > > What other issues do you consider as problems associated with IPSP? > > > > Tolga > > > > > -----Original Message----- > > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > > Sent: Wednesday, November 09, 2005 10:08 AM > > > To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; sigtran@ietf.org > > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > > > > Ken, > > > There is a serious issue in understanding the differences > > in IPSP and what > > > it means. > > > I am sure that u would have gone thru the mails where serious > > > issues of IPSP > > > understanding is evident. > > > > > > I feel that it should be resolved in the next draft before > > anything else. > > > An extention draft must include IPSP considerations. > > > > > > shashank > > > > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Ken A Morneault (kmorneau) > > > Sent: Wednesday, November 09, 2005 8:12 PM > > > To: Tolga Asveren; sigtran@ietf.org > > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > > > > > > > > > > Hi Tolga, > > > > > > Sorry for the delayed response. I took some time off. > > > > > > Regarding the IPSP text, that is an area that Javier > > > updated. At this point, I'm not sure if we will be > > > able to change the text. The document is supposed to > > > be heading to the Editor's queue to be published. > > > > > > Regards, > > > > > > Ken > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > > > Behalf Of Tolga Asveren > > > Sent: Tuesday, November 08, 2005 9:13 AM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > A few typo scorrected below. > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Tolga Asveren > > > > Sent: Tuesday, November 08, 2005 8:35 AM > > > > To: sigtran@ietf.org > > > > Subject: [Sigtran] SE-IPSP definition > > > > > > > > > > > > Brian, > > > > > > > > -changed the subject of the thread- > > > > > > > > Ken, I re-checked and current bis document seems to be updated > > > > partially > > > > (4.3 has the definition I copy/pasted below -which is fine-, OTOH > > > > still there is text mentioning about C-IPSP, D-IPSP for > > SE-model. The > > > > idea probably was to assign roles to IPSPS per > > "transaction", i.e. a > > > > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I > > believe the > > > > concept of "client" > > > > and "server" can be misleading because it can be considered as one > > > > IPSP always playing client or server role while > > communicating with a > > > > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse > > rather than > > > > clarify. > > > > > > > > Brian, more comments below. > > > > > > > > Tolga > > > > > > > > > -----Original Message----- > > > > > From: sigtran-bounces@ietf.org > > [mailto:sigtran-bounces@ietf.org]On > > > > > Behalf Of Brian F. G. Bidulock > > > > > Sent: Monday, November 07, 2005 7:52 PM > > > > > To: Tolga Asveren > > > > > Cc: sigtran@ietf.org > > > > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Tolga, > > > > > > > > > > Tolga Asveren wrote: > > > > > (Mon, 07 Nov 2005 14:36:07) > > > > > > > > > > --X--snip--X-- > > > > > > > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > > > > resolution - Part > > > > > > 1&2" thread -which has happened later than the thread you > > > > > mentioned ;-) -, > > > > > > you will see that everybody involved in the discussion > > > > > "Valerie, you, myself > > > > > > and Javier" agreed to return to the original SE-IPSP > > model. The > > > > > conclusion > > > > > > was to use the text proposed by Valerie. It seems the bis > > > > > document is not > > > > > > updated accordingly. Ken, was there a technical > > objection for that > > > > > > > > > change -actually I would call it reverting back to > > the original > > > > > model- or is > > > > > > this just an oversight? > > > > > > > > > > Really? Did you mean in "M3UAbis - consensus on > > comment resolution" > > > > > > > > 23 Aug 2004 where Valerie says: > > > > > > > > > > IPSP-SE behaviour: > > > > > The IPSP acting as the SGP must sends ASPAC-ack only > > when its side > > > > > of the RK is ready. The IPSP acting as the ASP is > > responsible to > > > > > retry the ASPAC until the remote peer is ready. > > > > > When the IPSP acting as the SGP wants to stop > > application traffic > > > > > from its side, it must send ASPIA-ack. > > > > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - > > > > consensus on comment resoluti on-Part 1&2" > > > > > > > > 1- IPSP Single Exchange (SE) model. Only a single > > exchange of ASPTM > > > > or ASPSM messages is needed to change the IPSP > > state. This means > > > > that a set of request from one end and acknowledge from the > > > other > > > > will be enough. The RK must define both sides of the traffic > > > flow. > > > > Each exchange of ASPTM or ASPSM messages can be initiated by > > > either > > > > IPSP. For this exchange, the initiating IPSP follows the > > > procedures > > > > described in section 4.3.1. > > > > > > > > The above is the original concept we defined for SE-IPSP mode. > > > > There are no > > > > predefined client/server relationship, a pure peer-to-peer > > > relationship. > > > > > > > > > > Or did you mean where we agreed to back out of the v03 changes > > > > > (which is what I think you are referring to with the > > IPSPF) and go > > > > > back to the > > > > > v02 description > > > > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > > > > [TOLGA]No, what I mean as "IPSPF approach is v02 > > definition. As long > > > > as the problem is how you and I name it, there is no problem from > > > > specification point of view but I would call it IPSPF > > because it has a > > > > > > > different machine > > > > > > ^^^^^^^^^ > > > > > state > > > machine > > > > than SGPF and ASPF and does not send/receive messages. I believe > > > ^^^^^^^^^ > > > certain messages, e.g. SSNM > > > > you use the > > > > term SGPF in the context of a "transaction" not inthe > > context of the > > > > overall realtionship between two peer IPSPs. > > > > > > > > > > --brian > > > > > > > > > > > > > > > > > Considering the way it is supposed to work, i.e. according to > > > > > the text we > > > > > > had concensus on, we can't speak of exact SGPF semantics for > > > > > SE-IPSP even > > > > > > from basic message exchange point of view, e.g. SGPF does not > > > > > send ASPAC, > > > > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > > > > sides can send > > > > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a > > > > > > peer-to-peer relationship, not a client/server relationship. > > > > > > > > > > See Valerie's description above. As I have mantained, > > it is clear > > > > > that one IPSP acts in an SGP role and the other in an ASP role. > > > > > > > > > > > > > > > > > Regarding the issue we are discussing in this thread -being > > > > > able to support > > > > > > traffic mode in both directions-I think it is a nice thing to > > > > > have, because > > > > > > we have application logic at both sides, which may want to > > > > use different > > > > > > traffic . > > > > > > > > > > Again, the IPSP acting as an SGP in SE mode is not > > required to have > > > > > a traffic mode. > > > > > > > > > > In the normal ASP/SGP exchange, the SGP does not have a > > traffic mode > > > > > > > > to place in the ASPAC Ack. Any traffic distribution > > towards the SGP > > > > > > > > is an SG-wide attribute and does not differ from AS to > > AS, nor ASP > > > > > to ASP. > > > > > > > > > > --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 > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > 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 Nov 09 11:51:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtAk-00063A-E7; Wed, 09 Nov 2005 11:51:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtAi-00060g-Nh for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 11:51:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21266 for ; Wed, 9 Nov 2005 11:51:12 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZtQk-0001iM-La for sigtran@ietf.org; Wed, 09 Nov 2005 12:08:16 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jA9GpPqr029085; Wed, 9 Nov 2005 10:51:28 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Nov 2005 16:51:24 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00CE6ED8E@en0033exch001u.uk.lucent.com> From: "Holland, Peter Michael (Peter)" To: "'Tolga Asveren'" , sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 16:51:23 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, See below... Pete > > > > Tolga, > > Concerning text clean up I see a couple of references to > > C-IPSP/D-IPSP that I assume should be removed. > > I also noticed several English problems with the numbered > > items at the start of 4.3. I can send updated text if you > > would like. > [TOLGA]Ken/Javier are the authors, i.e. the text is not under > my control. > OTOH based on Ken's last message, I have the impression that > we can't have > non-editorial changes anymore(?) Otherwise I would like to > see C-IPSP/D-IPSP > to be cleaned up as well. PMH - I would have hoped this was editorial... :-) > > > > Reading this thread the problem I see with SE procedures was > > identified in a mail where Brian said: > > >If you want both IPSPs to each have an AS an traffic mode, > use DE instead > > of SE. > > Thus I understand there are situations where SE mode cannot be > > used. This is not clear in RFC. > [TOLGA]No, this is not true, one can use SE-IPSP for any > scenario. IMO, that > traffic mode can't be specified bothways is something we need > to add to the > specification. PMH - to my view, the fact that traffic mode can't be specified bothways makes SE probably un-usable in some situations. But from what you say its too late to add anything to the RFC to deal with this. > > > > Concerning the inapplicability of SSNM message in IPSP > mode, I definately > > think it would help if this was explicitly stated - this has been a > > subject on significant discussion in some fora. > [TOLGA]Ken, is it possible to have the following modification: > In 3.1.2 Message Classes and Types: > SS7 Signalling Network Management (SSNM) Messages (See Section > 3.4)(Note: SSNM is not used for IPSP communication) > > I believe the above change could be considered as "editorial". ;-) PMH - that would be a good change. > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 11:59:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtIS-0000EE-JG; Wed, 09 Nov 2005 11:59:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtIQ-00009K-9t for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 11:59:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21720 for ; Wed, 9 Nov 2005 11:59:09 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZtYS-0001vM-0n for sigtran@ietf.org; Wed, 09 Nov 2005 12:16:13 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9GxImt024306 for ; Wed, 9 Nov 2005 11:59:21 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 11:41:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <475FF955A05DD411980D00508B6D5FB00CE6ED8E@en0033exch001u.uk.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Pete, [..snip..] > PMH - to my view, the fact that traffic mode can't be specified bothways > makes SE probably un-usable in some situations. But from what you > say its too late to add anything to the RFC to deal with this. [TOLGA]I agree with you that there is a deficiancy in the protocol regarding this issue and needs to be fixed. Lyndon, how do you suggest us to proceed? a) There are people both supporting and are against to use traffic mode bothways for SE-IPSP and I believe for both views the arguments are already clear. How are we going to reach a conclusion? -as of right now, a full consensus does not seem possible- b) If we decide for the change, will it be part of the current bis document, are we going to have a new bis document or will it be a separate WG draft? > > > > > > > Concerning the inapplicability of SSNM message in IPSP > > mode, I definately > > > think it would help if this was explicitly stated - this has been a > > > subject on significant discussion in some fora. > > [TOLGA]Ken, is it possible to have the following modification: > > In 3.1.2 Message Classes and Types: > > SS7 Signalling Network Management (SSNM) Messages (See Section > > 3.4)(Note: SSNM is not used for IPSP communication) > > > > I believe the above change could be considered as "editorial". ;-) > > PMH - that would be a good change. > > > > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 12:41:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtwd-00062k-6b; Wed, 09 Nov 2005 12:41:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtwa-00062c-KJ for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 12:41:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25032 for ; Wed, 9 Nov 2005 12:40:41 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZuCc-0003Vj-GV for sigtran@ietf.org; Wed, 09 Nov 2005 12:57:44 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA9HevcM008240; Wed, 9 Nov 2005 11:40:58 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Nov 2005 23:10:56 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB68C7@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: "'Tolga Asveren'" , sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 23:10:52 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Thanx Tolga, I would appreciate if we could clarify on IPSP considerations in the next release of the spec. This is really essential for clarity. I would also appreciate the RFC explicitly stated about a bit more Modes (SE and DE) and the inapplicability of SSNM messages for IPSPs. It would be great to have the state machines for IPSPs discussed seperately. A few more questions to understand the model that u and Brian drafted. 1. Is the SGPF in the IPSP different from the SGP in a Singnaling Gateway ? 2. What did u really mean when u said relaying (in ur last mail) ? Can u share in slightly greater detail about the IPSP model explaining the ASPF and SGPF ? Is it possible to have a look at the draft that u and Brian prepared ? That would give us more perspective on IPSPs and it relevance as understood by M3UA community. Let me give a fresh perspective to my understanding of IPSPs :) shashank -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Tolga Asveren Sent: Wednesday, November 09, 2005 9:06 PM To: sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition Shashank, > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Wednesday, November 09, 2005 10:36 AM > To: 'Tolga Asveren'; sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Tolga, > > My issues: > > I am NOT able to understand the following IPSP model that Brian > had said :) > I felt that an IPSP can have ASPF and SGPF but an ASPF using the > services of > SGPF was NOT very clear. > > IPSP A IPSP B > ___________ ___________ > | _______ | | _______ | > | | | | | | | | > | | ASPF | | | | ASPF | | > | |_______| | | |_______| | > | | | | | | > | ___|___ | | ___|___ | > | | | | Association | | | | > | | SGPF |-|--------------------|-| SGPF | | > | |_______| | | |_______| | > |___________| |___________| [TOLGA]The above model is not something existing in official specifications, i.e. it is nothing you should be concerned about in terms of understanding how IPSP as defined in exiting M3UA documents works. As Brian said, I wrote a draft -Brian also being another main contributor- but it did not become a WG item. I still think it is a good idea, mainly because it supports relaying. OTOH, I think SE-IPSP model works fine as well, but it does not have relaying capability -intentionally-. > > > Next is that u said that IPSP do NOT use SSNM messages. > I did NOT read anywhere explicit in the specs. Even the 3GPP > standards want > IPSPs to receive and send DUPU and SCON :). [TOLGA]Too bad for 3GPP, it shows that they did not fully understand the concept of IPSP. Availability for IPSP is managed by the state of AS, so no need for DUPU. For congestion, right now one needs to rely on SCTP congestion but Brian is working on a ASPCONG draft to define a new ASPTM message to convey AS congestion information. If it is not clear in the current document that SSNM is not to be used for IPSP, we may clarify this with a sentence. Actually lack of "IPSP Considerations" sections for SSNM related procedures also hints for not using SSNM for IPSP. If one want a model relying on SSNM, SG-SG communication is the way to go -which the draft I authored was about-. > > > About the Traffic Mode both ways in SE: > We should surely add that enhancement suggested. My proposal was NOT based > on a different premise. I never had an ASPF using the services of > SGPF. May > be the spec should draw these diagrams... > > > I had asked a question before: > How would ur model fit in assuming that I have two peers sending SCCP > messages to each other over an association ? > > +------+ +------+ > |SCCP- | |SCCP- | > | User | | User | > +------+ +------+ > | SCCP | | SCCP | > +------+ +------+ > | M3UA | | M3UA | > +------+ +------+ > | SCTP | | SCTP | > +------+ +------+ > | IP | | IP | > +------+ +------+ [TOLGA]I am not sure about what you are asking but both M3UA stacks perform functionality defined for M3UA-IPSP in the specification and that is it. > > > BTW, what is C/SE-IPSP and D/SE-IPSP [TOLGA]Something we need to get rid of :-) It refers to a SE-IPSP acting as client or server in the context of a "transaction", transaction meaning an ASPTM message pair exchange, e.g. ASPAC/ASPAC-ACK. IMO, it is extremely confusing. > > > shashank > > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Wednesday, November 09, 2005 8:26 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Shashank, > > I don't think there is as significant issue as you mention. As > far as I can > see, some text cleanup is the only thing we need-to get rid of C/SE-IPSP , > S/SE-IPSP distinction-. > > The original problem you mentioned -having traffic mode bothways- is > something useful IMO as well. That can be added to the document > but it does > not change anything architecturally in terms of IPSP as defined in the > document. > > What other issues do you consider as problems associated with IPSP? > > Tolga > > > -----Original Message----- > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > Sent: Wednesday, November 09, 2005 10:08 AM > > To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > Ken, > > There is a serious issue in understanding the differences in > IPSP and what > > it means. > > I am sure that u would have gone thru the mails where serious > > issues of IPSP > > understanding is evident. > > > > I feel that it should be resolved in the next draft before > anything else. > > An extention draft must include IPSP considerations. > > > > shashank > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Ken A Morneault (kmorneau) > > Sent: Wednesday, November 09, 2005 8:12 PM > > To: Tolga Asveren; sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > > > > > Hi Tolga, > > > > Sorry for the delayed response. I took some time off. > > > > Regarding the IPSP text, that is an area that Javier > > updated. At this point, I'm not sure if we will be > > able to change the text. The document is supposed to > > be heading to the Editor's queue to be published. > > > > Regards, > > > > Ken > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > > Behalf Of Tolga Asveren > > Sent: Tuesday, November 08, 2005 9:13 AM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > A few typo scorrected below. > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Tolga Asveren > > > Sent: Tuesday, November 08, 2005 8:35 AM > > > To: sigtran@ietf.org > > > Subject: [Sigtran] SE-IPSP definition > > > > > > > > > Brian, > > > > > > -changed the subject of the thread- > > > > > > Ken, I re-checked and current bis document seems to be updated > > > partially > > > (4.3 has the definition I copy/pasted below -which is fine-, OTOH > > > still there is text mentioning about C-IPSP, D-IPSP for SE-model. The > > > idea probably was to assign roles to IPSPS per "transaction", i.e. a > > > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I believe the > > > concept of "client" > > > and "server" can be misleading because it can be considered as one > > > IPSP always playing client or server role while communicating with a > > > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than > > > clarify. > > > > > > Brian, more comments below. > > > > > > Tolga > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Brian F. G. Bidulock > > > > Sent: Monday, November 07, 2005 7:52 PM > > > > To: Tolga Asveren > > > > Cc: sigtran@ietf.org > > > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > Tolga, > > > > > > > > Tolga Asveren wrote: > > > > (Mon, 07 Nov 2005 14:36:07) > > > > > > > > --X--snip--X-- > > > > > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > > > resolution - Part > > > > > 1&2" thread -which has happened later than the thread you > > > > mentioned ;-) -, > > > > > you will see that everybody involved in the discussion > > > > "Valerie, you, myself > > > > > and Javier" agreed to return to the original SE-IPSP model. The > > > > conclusion > > > > > was to use the text proposed by Valerie. It seems the bis > > > > document is not > > > > > updated accordingly. Ken, was there a technical objection for that > > > > > > > change -actually I would call it reverting back to the original > > > > model- or is > > > > > this just an oversight? > > > > > > > > Really? Did you mean in "M3UAbis - consensus on comment resolution" > > > > > > 23 Aug 2004 where Valerie says: > > > > > > > > IPSP-SE behaviour: > > > > The IPSP acting as the SGP must sends ASPAC-ack only when its side > > > > of the RK is ready. The IPSP acting as the ASP is responsible to > > > > retry the ASPAC until the remote peer is ready. > > > > When the IPSP acting as the SGP wants to stop application traffic > > > > from its side, it must send ASPIA-ack. > > > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - > > > consensus on comment resoluti on-Part 1&2" > > > > > > 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM > > > or ASPSM messages is needed to change the IPSP state. This means > > > that a set of request from one end and acknowledge from the > > other > > > will be enough. The RK must define both sides of the traffic > > flow. > > > Each exchange of ASPTM or ASPSM messages can be initiated by > > either > > > IPSP. For this exchange, the initiating IPSP follows the > > procedures > > > described in section 4.3.1. > > > > > > The above is the original concept we defined for SE-IPSP mode. > > > There are no > > > predefined client/server relationship, a pure peer-to-peer > > relationship. > > > > > > > > Or did you mean where we agreed to back out of the v03 changes > > > > (which is what I think you are referring to with the IPSPF) and go > > > > back to the > > > > v02 description > > > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > > > [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As long > > > as the problem is how you and I name it, there is no problem from > > > specification point of view but I would call it IPSPF because it has a > > > > > different machine > > > > ^^^^^^^^^ > > state > > machine > > > than SGPF and ASPF and does not send/receive messages. I believe > > ^^^^^^^^^ > > certain messages, e.g. SSNM > > > you use the > > > term SGPF in the context of a "transaction" not inthe context of the > > > overall realtionship between two peer IPSPs. > > > > > > > > --brian > > > > > > > > > > > > > > Considering the way it is supposed to work, i.e. according to > > > > the text we > > > > > had concensus on, we can't speak of exact SGPF semantics for > > > > SE-IPSP even > > > > > from basic message exchange point of view, e.g. SGPF does not > > > > send ASPAC, > > > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > > > sides can send > > > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a > > > > > peer-to-peer relationship, not a client/server relationship. > > > > > > > > See Valerie's description above. As I have mantained, it is clear > > > > that one IPSP acts in an SGP role and the other in an ASP role. > > > > > > > > > > > > > > Regarding the issue we are discussing in this thread -being > > > > able to support > > > > > traffic mode in both directions-I think it is a nice thing to > > > > have, because > > > > > we have application logic at both sides, which may want to > > > use different > > > > > traffic . > > > > > > > > Again, the IPSP acting as an SGP in SE mode is not required to have > > > > a traffic mode. > > > > > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic mode > > > > > > to place in the ASPAC Ack. Any traffic distribution towards the SGP > > > > > > is an SG-wide attribute and does not differ from AS to AS, nor ASP > > > > to ASP. > > > > > > > > --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 > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 13:15:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuTU-0003nT-Lb; Wed, 09 Nov 2005 13:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuTS-0003nC-0N for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 13:15:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27077 for ; Wed, 9 Nov 2005 13:14:38 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZujT-0004UH-Be for sigtran@ietf.org; Wed, 09 Nov 2005 13:31:42 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9IEi5X001916 for ; Wed, 9 Nov 2005 13:14:48 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 12:56:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210FB68C7@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7b8e6f6ef974ecda19a6b57d59caeb7d Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Shashank, > -----Original Message----- > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > Sent: Wednesday, November 09, 2005 12:41 PM > To: 'Tolga Asveren'; sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Thanx Tolga, > I would appreciate if we could clarify on IPSP considerations in the next > release of the spec. This is really essential for clarity. > > I would also appreciate the RFC explicitly stated about a bit > more Modes (SE > and DE) and the inapplicability of SSNM messages for IPSPs. It would be > great to have the state machines for IPSPs discussed seperately. > > A few more questions to understand the model that u and Brian drafted. > 1. Is the SGPF in the IPSP different from the SGP in a Singnaling > Gateway ? [TOLGA]SGPF/ASPF/IPSPF etc.. are just terms we are using to refer to M3UA functionality to be implemented for the corresponding entity, SGP, ASP and IPSP respectively. I wouldn't call them "official" terms. Just follow what the specification says about IPSP behavior. I personbally call this functionality IPSPF. > 2. What did u really mean when u said relaying (in ur last mail) ? [TOLGA]Being able to send received messages to another entity, similar to what an STP does in MTP3 network. > > Can u share in slightly greater detail about the IPSP model explaining the > ASPF and SGPF ? [TOLGA]As said above, just follow the IPSP behavior as defined in the current specification, there is nothing more to it. > > Is it possible to have a look at the draft that u and Brian > prepared ? That > would give us more perspective on IPSPs and it relevance as understood by > M3UA community. [TOLGA]That draft is about SG-to-SG communication. Let me submit a new version of it -in a few days- and then you can have better idea about it. > > Let me give a fresh perspective to my understanding of IPSPs :) [TOLGA]Just follow the IPSP behavior as specified in the document ;-) > > shashank > > > > > > > > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Tolga Asveren > Sent: Wednesday, November 09, 2005 9:06 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Shashank, > > > -----Original Message----- > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > Sent: Wednesday, November 09, 2005 10:36 AM > > To: 'Tolga Asveren'; sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > Tolga, > > > > My issues: > > > > I am NOT able to understand the following IPSP model that Brian > > had said :) > > I felt that an IPSP can have ASPF and SGPF but an ASPF using the > > services of > > SGPF was NOT very clear. > > > > IPSP A IPSP B > > ___________ ___________ > > | _______ | | _______ | > > | | | | | | | | > > | | ASPF | | | | ASPF | | > > | |_______| | | |_______| | > > | | | | | | > > | ___|___ | | ___|___ | > > | | | | Association | | | | > > | | SGPF |-|--------------------|-| SGPF | | > > | |_______| | | |_______| | > > |___________| |___________| > [TOLGA]The above model is not something existing in official > specifications, > i.e. it is nothing you should be concerned about in terms of understanding > how IPSP as defined in exiting M3UA documents works. As Brian > said, I wrote > a draft -Brian also being another main contributor- but it did > not become a > WG item. I still think it is a good idea, mainly because it supports > relaying. OTOH, I think SE-IPSP model works fine as well, but it does not > have relaying capability -intentionally-. > > > > > > Next is that u said that IPSP do NOT use SSNM messages. > > I did NOT read anywhere explicit in the specs. Even the 3GPP > > standards want > > IPSPs to receive and send DUPU and SCON :). > [TOLGA]Too bad for 3GPP, it shows that they did not fully understand the > concept of IPSP. Availability for IPSP is managed by the state of > AS, so no > need for DUPU. For congestion, right now one needs to rely on SCTP > congestion but Brian is working on a ASPCONG draft to define a new ASPTM > message to convey AS congestion information. > If it is not clear in the current document that SSNM is not to be used for > IPSP, we may clarify this with a sentence. Actually lack of "IPSP > Considerations" sections for SSNM related procedures also hints for not > using SSNM for IPSP. > > If one want a model relying on SSNM, SG-SG communication is the way to > go -which the draft I authored was about-. > > > > > > About the Traffic Mode both ways in SE: > > We should surely add that enhancement suggested. My proposal > was NOT based > > on a different premise. I never had an ASPF using the services of > > SGPF. May > > be the spec should draw these diagrams... > > > > > > I had asked a question before: > > How would ur model fit in assuming that I have two peers sending SCCP > > messages to each other over an association ? > > > > +------+ +------+ > > |SCCP- | |SCCP- | > > | User | | User | > > +------+ +------+ > > | SCCP | | SCCP | > > +------+ +------+ > > | M3UA | | M3UA | > > +------+ +------+ > > | SCTP | | SCTP | > > +------+ +------+ > > | IP | | IP | > > +------+ +------+ > [TOLGA]I am not sure about what you are asking but both M3UA > stacks perform > functionality defined for M3UA-IPSP in the specification and that is it. > > > > > > BTW, what is C/SE-IPSP and D/SE-IPSP > [TOLGA]Something we need to get rid of :-) It refers to a SE-IPSP > acting as > client or server in the context of a "transaction", transaction meaning an > ASPTM message pair exchange, e.g. ASPAC/ASPAC-ACK. IMO, it is extremely > confusing. > > > > > > shashank > > > > > > > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Tolga Asveren > > Sent: Wednesday, November 09, 2005 8:26 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > Shashank, > > > > I don't think there is as significant issue as you mention. As > > far as I can > > see, some text cleanup is the only thing we need-to get rid of > C/SE-IPSP , > > S/SE-IPSP distinction-. > > > > The original problem you mentioned -having traffic mode bothways- is > > something useful IMO as well. That can be added to the document > > but it does > > not change anything architecturally in terms of IPSP as defined in the > > document. > > > > What other issues do you consider as problems associated with IPSP? > > > > Tolga > > > > > -----Original Message----- > > > From: Prasad, Shashank S (Shashank) [mailto:ssprasad@lucent.com] > > > Sent: Wednesday, November 09, 2005 10:08 AM > > > To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; sigtran@ietf.org > > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > > > > Ken, > > > There is a serious issue in understanding the differences in > > IPSP and what > > > it means. > > > I am sure that u would have gone thru the mails where serious > > > issues of IPSP > > > understanding is evident. > > > > > > I feel that it should be resolved in the next draft before > > anything else. > > > An extention draft must include IPSP considerations. > > > > > > shashank > > > > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > Behalf Of Ken A Morneault (kmorneau) > > > Sent: Wednesday, November 09, 2005 8:12 PM > > > To: Tolga Asveren; sigtran@ietf.org > > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > > > > > > > > > > Hi Tolga, > > > > > > Sorry for the delayed response. I took some time off. > > > > > > Regarding the IPSP text, that is an area that Javier > > > updated. At this point, I'm not sure if we will be > > > able to change the text. The document is supposed to > > > be heading to the Editor's queue to be published. > > > > > > Regards, > > > > > > Ken > > > > > > -----Original Message----- > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > > > Behalf Of Tolga Asveren > > > Sent: Tuesday, November 08, 2005 9:13 AM > > > To: sigtran@ietf.org > > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > A few typo scorrected below. > > > > > > > -----Original Message----- > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > Behalf Of Tolga Asveren > > > > Sent: Tuesday, November 08, 2005 8:35 AM > > > > To: sigtran@ietf.org > > > > Subject: [Sigtran] SE-IPSP definition > > > > > > > > > > > > Brian, > > > > > > > > -changed the subject of the thread- > > > > > > > > Ken, I re-checked and current bis document seems to be updated > > > > partially > > > > (4.3 has the definition I copy/pasted below -which is fine-, OTOH > > > > still there is text mentioning about C-IPSP, D-IPSP for > SE-model. The > > > > idea probably was to assign roles to IPSPS per "transaction", i.e. a > > > > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I > believe the > > > > concept of "client" > > > > and "server" can be misleading because it can be considered as one > > > > IPSP always playing client or server role while communicating with a > > > > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than > > > > clarify. > > > > > > > > Brian, more comments below. > > > > > > > > Tolga > > > > > > > > > -----Original Message----- > > > > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > > > > Behalf Of Brian F. G. Bidulock > > > > > Sent: Monday, November 07, 2005 7:52 PM > > > > > To: Tolga Asveren > > > > > Cc: sigtran@ietf.org > > > > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > > > > > > > Tolga, > > > > > > > > > > Tolga Asveren wrote: > > > > > (Mon, 07 Nov 2005 14:36:07) > > > > > > > > > > --X--snip--X-- > > > > > > > > > > > [TOLGA]If you look to " M3UAbis - consensus on comment > > > > resolution - Part > > > > > > 1&2" thread -which has happened later than the thread you > > > > > mentioned ;-) -, > > > > > > you will see that everybody involved in the discussion > > > > > "Valerie, you, myself > > > > > > and Javier" agreed to return to the original SE-IPSP model. The > > > > > conclusion > > > > > > was to use the text proposed by Valerie. It seems the bis > > > > > document is not > > > > > > updated accordingly. Ken, was there a technical > objection for that > > > > > > > > > change -actually I would call it reverting back to the original > > > > > model- or is > > > > > > this just an oversight? > > > > > > > > > > Really? Did you mean in "M3UAbis - consensus on comment > resolution" > > > > > > > > 23 Aug 2004 where Valerie says: > > > > > > > > > > IPSP-SE behaviour: > > > > > The IPSP acting as the SGP must sends ASPAC-ack only > when its side > > > > > of the RK is ready. The IPSP acting as the ASP is responsible to > > > > > retry the ASPAC until the remote peer is ready. > > > > > When the IPSP acting as the SGP wants to stop application traffic > > > > > from its side, it must send ASPIA-ack. > > > > [TOLGA] No, what I mean is the message on 08/30/2004 "M3UAbis - > > > > consensus on comment resoluti on-Part 1&2" > > > > > > > > 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM > > > > or ASPSM messages is needed to change the IPSP state. > This means > > > > that a set of request from one end and acknowledge from the > > > other > > > > will be enough. The RK must define both sides of the traffic > > > flow. > > > > Each exchange of ASPTM or ASPSM messages can be initiated by > > > either > > > > IPSP. For this exchange, the initiating IPSP follows the > > > procedures > > > > described in section 4.3.1. > > > > > > > > The above is the original concept we defined for SE-IPSP mode. > > > > There are no > > > > predefined client/server relationship, a pure peer-to-peer > > > relationship. > > > > > > > > > > Or did you mean where we agreed to back out of the v03 changes > > > > > (which is what I think you are referring to with the IPSPF) and go > > > > > back to the > > > > > v02 description > > > > > (which is the same as RFC 3332 and the SGPF/ASPF approach). > > > > [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As long > > > > as the problem is how you and I name it, there is no problem from > > > > specification point of view but I would call it IPSPF > because it has a > > > > > > > different machine > > > > > > ^^^^^^^^^ > > > > state > > > machine > > > > than SGPF and ASPF and does not send/receive messages. I believe > > > ^^^^^^^^^ > > > certain messages, e.g. SSNM > > > > you use the > > > > term SGPF in the context of a "transaction" not inthe context of the > > > > overall realtionship between two peer IPSPs. > > > > > > > > > > --brian > > > > > > > > > > > > > > > > > Considering the way it is supposed to work, i.e. according to > > > > > the text we > > > > > > had concensus on, we can't speak of exact SGPF semantics for > > > > > SE-IPSP even > > > > > > from basic message exchange point of view, e.g. SGPF does not > > > > > send ASPAC, > > > > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both > > > > > sides can send > > > > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a > > > > > > peer-to-peer relationship, not a client/server relationship. > > > > > > > > > > See Valerie's description above. As I have mantained, it is clear > > > > > that one IPSP acts in an SGP role and the other in an ASP role. > > > > > > > > > > > > > > > > > Regarding the issue we are discussing in this thread -being > > > > > able to support > > > > > > traffic mode in both directions-I think it is a nice thing to > > > > > have, because > > > > > > we have application logic at both sides, which may want to > > > > use different > > > > > > traffic . > > > > > > > > > > Again, the IPSP acting as an SGP in SE mode is not > required to have > > > > > a traffic mode. > > > > > > > > > > In the normal ASP/SGP exchange, the SGP does not have a > traffic mode > > > > > > > > to place in the ASPAC Ack. Any traffic distribution > towards the SGP > > > > > > > > is an SG-wide attribute and does not differ from AS to AS, nor ASP > > > > > to ASP. > > > > > > > > > > --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 > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 13:34:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuma-0002F0-3t; Wed, 09 Nov 2005 13:34:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZumY-0002EK-VQ for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 13:34:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28606 for ; Wed, 9 Nov 2005 13:34:24 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[VGe1EsoZRQX+CbijjFA9AMmGOfOAs1Hi]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZv2Q-0005C3-Rk for sigtran@ietf.org; Wed, 09 Nov 2005 13:51:27 -0500 Received: from ns.pigworks.openss7.net (IDENT:pbi2AuQWE9oAi0WY+DlDooNl49Smp0VG@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA9IYYc25311; Wed, 9 Nov 2005 11:34:34 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA9IYVi17262; Wed, 9 Nov 2005 11:34:31 -0700 Date: Wed, 9 Nov 2005 11:34:31 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051109113431.A17044@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <475FF955A05DD411980D00508B6D5FB00CE6ED8D@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from asveren@ulticom.com on Wed, Nov 09, 2005 at 11:23:16AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Wed, 09 Nov 2005 11:23:16) > [TOLGA]Ken, is it possible to have the following modification: > In 3.1.2 Message Classes and Types: > SS7 Signalling Network Management (SSNM) Messages (See Section > 3.4)(Note: SSNM is not used for IPSP communication) > > I believe the above change could be considered as "editorial". ;-) The change is not editorial and I disagree with the change in semantics. There is no reason why an IPSP cannot send SNMM as the RFC permitted at WGLC. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 13:42:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuu9-0004rX-T7; Wed, 09 Nov 2005 13:42:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuu7-0004qq-SV for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 13:42:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29094 for ; Wed, 9 Nov 2005 13:42:12 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[375zsJzjpb7ljazL1JD9Kt1cgAVd0pwL]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvA0-0005PR-4e for sigtran@ietf.org; Wed, 09 Nov 2005 13:59:15 -0500 Received: from ns.pigworks.openss7.net (IDENT:Xzs2SUVYRGgSq28pX3M4rcX294dBdnKG@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA9IgPc25409; Wed, 9 Nov 2005 11:42:25 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA9IgP617308; Wed, 9 Nov 2005 11:42:25 -0700 Date: Wed, 9 Nov 2005 11:42:24 -0700 From: "Brian F. G. Bidulock" To: "Holland, Peter Michael (Peter)" Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051109114224.B17044@openss7.org> Mail-Followup-To: "Holland, Peter Michael (Peter)" , 'Tolga Asveren' , sigtran@ietf.org References: <475FF955A05DD411980D00508B6D5FB00CE6ED8D@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <475FF955A05DD411980D00508B6D5FB00CE6ED8D@en0033exch001u.uk.lucent.com>; from pmholland@lucent.com on Wed, Nov 09, 2005 at 04:29:33PM -0000 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sigtran@ietf.org, 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Holland,, Holland, Peter Michael (Peter) wrote: (Wed, 09 Nov 2005 16:29:33) > Tolga, > Concerning text clean up I see a couple of references to > C-IPSP/D-IPSP that I assume should be removed. It was agreed at WGLC that the terms C-IPSP and D-IPSP would be removed. If it is still possible to do so, it is an editorial change. > I also noticed several English problems with the numbered > items at the start of 4.3. I can send updated text if you > would like. > > Reading this thread the problem I see with SE procedures was > identified in a mail where Brian said: > >If you want both IPSPs to each have an AS an traffic mode, use DE instead > of SE. > Thus I understand there are situations where SE mode cannot be > used. This is not clear in RFC. No, there are not situations where SE mode cannot be used. What I was saying was that if one pedantically requies that both peers have and exchange a traffic mode (which they don't need in the first place) that one should use the DE mode. SE can work quite fine in all situations with one side not having an ASP traffic mode. No change is required. > > Concerning the inapplicability of SSNM message in IPSP mode, I definately > think it would help if this was explicitly stated - this has been a > subject on significant discussion in some fora. All SSNM messages are applicable to IPSPs. No change is required. --brian > > Thanks > Pete > -- 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 Nov 09 13:47:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuyW-0007Sg-8K; Wed, 09 Nov 2005 13:47:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuyU-0007Rp-D5 for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 13:47:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29418 for ; Wed, 9 Nov 2005 13:46:40 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvEV-0005Ym-2Q for sigtran@ietf.org; Wed, 09 Nov 2005 14:03:44 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9IknC5005076 for ; Wed, 9 Nov 2005 13:46:51 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 13:28:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051109113431.A17044@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Wednesday, November 09, 2005 1:35 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] SE-IPSP definition > > > Tolga, > > Tolga Asveren wrote: > (Wed, 09 Nov 2005 11:23:16) > > [TOLGA]Ken, is it possible to have the following modification: > > In 3.1.2 Message Classes and Types: > > SS7 Signalling Network Management (SSNM) Messages (See Section > > 3.4)(Note: SSNM is not used for IPSP communication) > > > > I believe the above change could be considered as "editorial". ;-) > > The change is not editorial and I disagree with the change in semantics. > There is no reason why an IPSP cannot send SNMM as the RFC permitted at > WGLC. [TOLGA]As far as I can see, the current text explicitly defines that DUNA is sent from SG and SCON from SG and ASP in 3.4.1 and 3.4.4 respectively. OTOH, 1.4.6 mentions about sending SCON for IPSP case as well. So, a)For DUNA, the existing specification does not allow its usage for IPSP. b)For SCON, there is inconsistency in the document. With ASPCONG, I don't think there will be a need for SCON for IPSP case. I believe, for the sake of completiness, it can be kept in the document for now(?). > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 13:51:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv2e-0008LB-Cm; Wed, 09 Nov 2005 13:51:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv2c-0008Kc-LH for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 13:51:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29751 for ; Wed, 9 Nov 2005 13:50:59 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvIg-0005ib-HK for sigtran@ietf.org; Wed, 09 Nov 2005 14:08:02 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA9IpLhB008381; Wed, 9 Nov 2005 12:51:22 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Nov 2005 00:21:20 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210FB68C9@ii0015exch002u.iprc.lucent.com> From: "Prasad, Shashank S (Shashank)" To: "'bidulock@openss7.org'" , sigtran@ietf.org Subject: RE: [Sigtran] SE-IPSP definition Date: Thu, 10 Nov 2005 00:21:19 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Brian F. G. Bidulock Sent: Thursday, November 10, 2005 12:12 AM To: Holland, Peter Michael (Peter) Cc: sigtran@ietf.org; 'Tolga Asveren' Subject: Re: [Sigtran] SE-IPSP definition Holland,, Holland, Peter Michael (Peter) wrote: (Wed, 09 Nov 2005 16:29:33) > Tolga, > Concerning text clean up I see a couple of references to > C-IPSP/D-IPSP that I assume should be removed. It was agreed at WGLC that the terms C-IPSP and D-IPSP would be removed. If it is still possible to do so, it is an editorial change. > I also noticed several English problems with the numbered > items at the start of 4.3. I can send updated text if you > would like. > > Reading this thread the problem I see with SE procedures was > identified in a mail where Brian said: > >If you want both IPSPs to each have an AS an traffic mode, use DE instead > of SE. > Thus I understand there are situations where SE mode cannot be > used. This is not clear in RFC. No, there are not situations where SE mode cannot be used. What I was saying was that if one pedantically requies that both peers have and exchange a traffic mode (which they don't need in the first place) that one should use the DE mode. SE can work quite fine in all situations with one side not having an ASP traffic mode. No change is required. > > Concerning the inapplicability of SSNM message in IPSP mode, I definately > think it would help if this was explicitly stated - this has been a > subject on significant discussion in some fora. All SSNM messages are applicable to IPSPs. No change is required. [SHASHANK] Are DUNA, DAVA, DAUD also applicable to IPSPs ? --brian > > Thanks > Pete > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 13:51:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv2y-0008So-0U; Wed, 09 Nov 2005 13:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv2w-0008Sf-LY for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 13:51:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29783 for ; Wed, 9 Nov 2005 13:51:19 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvJ0-0005j3-P2 for sigtran@ietf.org; Wed, 09 Nov 2005 14:08:23 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9IpanH005647 for ; Wed, 9 Nov 2005 13:51:36 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 13:33:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051109114224.B17044@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, [..snip..] > > All SSNM messages are applicable to IPSPs. No change is required. [TOLGA]I couldn't disagree more. Could you please tell why they are needed? Availability of remote ends is managed by the state of AS. As far as I can see only SCON has a use case, and hopefully with ASPCONG it won't be necessary as well. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 13:56:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv7E-00012e-Iy; Wed, 09 Nov 2005 13:56:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv7C-00012H-NS for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 13:56:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00147 for ; Wed, 9 Nov 2005 13:55:43 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[Kyn+YjNirnZrPrTgpoPfNa0q2nZo/5wl]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvNF-0005sx-S8 for sigtran@ietf.org; Wed, 09 Nov 2005 14:12:47 -0500 Received: from ns.pigworks.openss7.net (IDENT:bNlqluGIVE31zWHjyZ93vFLlAAPpH1wv@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA9Iu7c25748; Wed, 9 Nov 2005 11:56:07 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA9Iu5717433; Wed, 9 Nov 2005 11:56:05 -0700 Date: Wed, 9 Nov 2005 11:56:04 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051109115604.A17378@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051109113431.A17044@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, Nov 09, 2005 at 01:28:35PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Wed, 09 Nov 2005 13:28:35) > Brian, > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Wednesday, November 09, 2005 1:35 PM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] SE-IPSP definition > > > > > > Tolga, > > > > Tolga Asveren wrote: > > (Wed, 09 Nov 2005 11:23:16) > > > [TOLGA]Ken, is it possible to have the following modification: > > > In 3.1.2 Message Classes and Types: > > > SS7 Signalling Network Management (SSNM) Messages (See Section > > > 3.4)(Note: SSNM is not used for IPSP communication) > > > > > > I believe the above change could be considered as "editorial". ;-) > > > > The change is not editorial and I disagree with the change in semantics. > > There is no reason why an IPSP cannot send SNMM as the RFC permitted at > > WGLC. > [TOLGA]As far as I can see, the current text explicitly defines that DUNA is > sent from SG and SCON from SG and ASP in 3.4.1 and 3.4.4 respectively. OTOH, > 1.4.6 mentions about sending SCON for IPSP case as well. So, > > a)For DUNA, the existing specification does not allow its usage for IPSP. Where does it say that DUNA cannot be sent from an IPSP? I interpret sending DUNA from an SGP to mean that it can be sent from the SE-IPSP acting like an SGP. (And, DAVA and DUPU and DRST.) > > b)For SCON, there is inconsistency in the document. With ASPCONG, I don't > think there will be a need for SCON for IPSP case. I believe, for the sake > of completiness, it can be kept in the document for now(?). While you're making all these changes, why not scrap IPSP altogether? It hasn't turned into a very useful part of the specification. --brian > > > > --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 -- 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 Nov 09 13:58:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv9E-0001XZ-Oc; Wed, 09 Nov 2005 13:58:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv9D-0001XK-Js for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 13:58:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00313 for ; Wed, 9 Nov 2005 13:57:48 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvPG-0005wb-Ky for sigtran@ietf.org; Wed, 09 Nov 2005 14:14:51 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9IvvVG006315 for ; Wed, 9 Nov 2005 13:57:58 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 13:39:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org For everybody interested in that topic, I would suggest also to read "1.4.3.2 SS7 and M3UA Interworking at the SG" and "1.4.3.4 IPSP Considerations". "1.4.3.4 IPSP Considerations Since IPSPs use M3UA in a point-to-point fashion, there is no concept of routing of messages beyond the remote end. Therefore, SS7 and M3UA interworking is not necessary for this model." > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: Wednesday, November 09, 2005 1:33 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] SE-IPSP definition > > > Brian, > > [..snip..] > > > > All SSNM messages are applicable to IPSPs. No change is required. > [TOLGA]I couldn't disagree more. Could you please tell why they > are needed? > > Availability of remote ends is managed by the state of AS. > > As far as I can see only SCON has a use case, and hopefully with > ASPCONG it won't be necessary as well. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 14:00:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvBG-0002iA-Dw; Wed, 09 Nov 2005 14:00:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvBE-0002i5-78 for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 14:00:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00504 for ; Wed, 9 Nov 2005 13:59:53 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvRI-00062I-Cg for sigtran@ietf.org; Wed, 09 Nov 2005 14:16:56 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9J09wo006538 for ; Wed, 9 Nov 2005 14:00:10 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 13:41:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051109115604.A17378@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Wednesday, November 09, 2005 1:56 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] SE-IPSP definition > > > Tolga, > > Tolga Asveren wrote: > (Wed, 09 Nov 2005 13:28:35) > > Brian, > > > > > -----Original Message----- > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: Wednesday, November 09, 2005 1:35 PM > > > To: Tolga Asveren > > > Cc: sigtran@ietf.org > > > Subject: Re: [Sigtran] SE-IPSP definition > > > > > > > > > Tolga, > > > > > > Tolga Asveren wrote: > > > (Wed, 09 Nov 2005 11:23:16) > > > > [TOLGA]Ken, is it possible to have the following modification: > > > > In 3.1.2 Message Classes and Types: > > > > SS7 Signalling Network Management (SSNM) Messages (See Section > > > > 3.4)(Note: SSNM is not used for IPSP communication) > > > > > > > > I believe the above change could be considered as "editorial". ;-) > > > > > > The change is not editorial and I disagree with the change in > semantics. > > > There is no reason why an IPSP cannot send SNMM as the RFC > permitted at > > > WGLC. > > [TOLGA]As far as I can see, the current text explicitly defines > that DUNA is > > sent from SG and SCON from SG and ASP in 3.4.1 and 3.4.4 > respectively. OTOH, > > 1.4.6 mentions about sending SCON for IPSP case as well. So, > > > > a)For DUNA, the existing specification does not allow its usage > for IPSP. > > Where does it say that DUNA cannot be sent from an IPSP? > > I interpret sending DUNA from an SGP to mean that it can be sent from the > SE-IPSP acting like an SGP. [TOLGA]That wouldn't be an IPSP, that would be an SGP. An IPSP is supposed to work according to IPSP procedures defined in the specification. > > (And, DAVA and DUPU and DRST.) > > > > > b)For SCON, there is inconsistency in the document. With > ASPCONG, I don't > > think there will be a need for SCON for IPSP case. I believe, > for the sake > > of completiness, it can be kept in the document for now(?). > > While you're making all these changes, why not scrap IPSP altogether? > It hasn't turned into a very useful part of the specification. [TOLGA]I think SE-IPSP works fine, just the text needs to be cleaned up. > > --brian > > > > > > > > --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 > > -- > 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 Nov 09 14:03:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvEC-0003K6-Tm; Wed, 09 Nov 2005 14:03:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvEA-0003K1-UI for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 14:03:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00806 for ; Wed, 9 Nov 2005 14:02:55 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[tIwABfCEnKrLo5m36vZKciow/k5sYrsR]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvUD-00068u-3P for sigtran@ietf.org; Wed, 09 Nov 2005 14:19:59 -0500 Received: from ns.pigworks.openss7.net (IDENT:CIhY8uKjYQGhptB4F+PLa+gsTrqGOzrf@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA9J3Gc25998; Wed, 9 Nov 2005 12:03:16 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA9J3FV17655; Wed, 9 Nov 2005 12:03:15 -0700 Date: Wed, 9 Nov 2005 12:03:15 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051109120315.A17443@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051109114224.B17044@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, Nov 09, 2005 at 01:33:22PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: 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: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Wed, 09 Nov 2005 13:33:22) > Brian, > > [..snip..] > > > > All SSNM messages are applicable to IPSPs. No change is required. > [TOLGA]I couldn't disagree more. Could you please tell why they are needed? Because they correspond to MTP-User primitives that need to be delivered to the AS, regardless of whether the AS is at an ASP or IPSP. To use your words, it is required by the "Application Logic" for the peer to be able to indicate things such as MTP-STATUS. --brian > > Availability of remote ends is managed by the state of AS. No it cannot in all cases. For example, if an entire PC RK is used between IPSP, the IPSP can use DUPU to signal the availabiltiy of individual user parts to the peer that cannot be accomplished with ASP activation state. Another case is where NA is used as a RK and multiple point codes are used at either end. I know that you do not agree with this arrangement, but there is nothing in the current spec forbidding it. > > As far as I can see only SCON has a use case, and hopefully with ASPCONG it > won't be necessary as well. They all have "Use Cases". --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 14:08:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvJM-0005ej-1t; Wed, 09 Nov 2005 14:08:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvJJ-0005Yz-GD for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 14:08:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01245 for ; Wed, 9 Nov 2005 14:08:14 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[ByA7evDP9jySTwQWaFDHCdDG5wCRekJ1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvZH-0006Kz-Lb for sigtran@ietf.org; Wed, 09 Nov 2005 14:25:18 -0500 Received: from ns.pigworks.openss7.net (IDENT:AsrStGtHv7G7NfjmWRbAH+WHTicU6Rbm@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA9J8Kc26065; Wed, 9 Nov 2005 12:08:20 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA9J8HD17702; Wed, 9 Nov 2005 12:08:18 -0700 Date: Wed, 9 Nov 2005 12:08:17 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051109120817.C17443@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, Nov 09, 2005 at 01:39:43PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, I an not talking about SNMM used to indicate the status of remote point codes, etc. I am talking about SNMM used to indciate the status of local point codes, etc. for the sending IPSP. Also, it might not be necessary (in all cases), it might not even be very useful (in some cases), but it is currently not prohibited. --brian Tolga Asveren wrote: (Wed, 09 Nov 2005 13:39:43) > For everybody interested in that topic, I would suggest also to read > "1.4.3.2 SS7 and M3UA Interworking at the SG" and "1.4.3.4 IPSP > Considerations". > > "1.4.3.4 IPSP Considerations > > Since IPSPs use M3UA in a point-to-point fashion, there is no concept > of routing of messages beyond the remote end. Therefore, SS7 and > M3UA interworking is not necessary for this model." > > > -----Original Message----- > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > Sent: Wednesday, November 09, 2005 1:33 PM > > To: sigtran@ietf.org > > Subject: RE: [Sigtran] SE-IPSP definition > > > > > > Brian, > > > > [..snip..] > > > > > > All SSNM messages are applicable to IPSPs. No change is required. > > [TOLGA]I couldn't disagree more. Could you please tell why they > > are needed? > > > > Availability of remote ends is managed by the state of AS. > > > > As far as I can see only SCON has a use case, and hopefully with > > ASPCONG it won't be necessary as well. > > > > _______________________________________________ > 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 Nov 09 14:08:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvJV-0005mr-S3; Wed, 09 Nov 2005 14:08:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvJU-0005kD-Vp for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 14:08:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01259 for ; Wed, 9 Nov 2005 14:08:25 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[EtD8x2VN4jFdqJhSc3ktWRxrWFVhG2n5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvWG-0006D4-Uk for sigtran@ietf.org; Wed, 09 Nov 2005 14:25:29 -0500 Received: from ns.pigworks.openss7.net (IDENT:f7CuQi/w5uLgN2COmhYBlO3g2nmnZuGH@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA9J5Qc26026; Wed, 9 Nov 2005 12:05:26 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA9J5Qa17675; Wed, 9 Nov 2005 12:05:26 -0700 Date: Wed, 9 Nov 2005 12:05:26 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051109120526.B17443@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051109115604.A17378@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, Nov 09, 2005 at 01:41:55PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Wed, 09 Nov 2005 13:41:55) > Brian, > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Wednesday, November 09, 2005 1:56 PM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] SE-IPSP definition > > > > > > Tolga, > > > > Tolga Asveren wrote: > > (Wed, 09 Nov 2005 13:28:35) > > > Brian, > > > > > > > -----Original Message----- > > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > > Sent: Wednesday, November 09, 2005 1:35 PM > > > > To: Tolga Asveren > > > > Cc: sigtran@ietf.org > > > > Subject: Re: [Sigtran] SE-IPSP definition > > > > > > > > > > > > Tolga, > > > > > > > > Tolga Asveren wrote: > > > > (Wed, 09 Nov 2005 11:23:16) > > > > > [TOLGA]Ken, is it possible to have the following modification: > > > > > In 3.1.2 Message Classes and Types: > > > > > SS7 Signalling Network Management (SSNM) Messages (See Section > > > > > 3.4)(Note: SSNM is not used for IPSP communication) > > > > > > > > > > I believe the above change could be considered as "editorial". ;-) > > > > > > > > The change is not editorial and I disagree with the change in > > semantics. > > > > There is no reason why an IPSP cannot send SNMM as the RFC > > permitted at > > > > WGLC. > > > [TOLGA]As far as I can see, the current text explicitly defines > > that DUNA is > > > sent from SG and SCON from SG and ASP in 3.4.1 and 3.4.4 > > respectively. OTOH, > > > 1.4.6 mentions about sending SCON for IPSP case as well. So, > > > > > > a)For DUNA, the existing specification does not allow its usage > > for IPSP. > > > > Where does it say that DUNA cannot be sent from an IPSP? > > > > I interpret sending DUNA from an SGP to mean that it can be sent from the > > SE-IPSP acting like an SGP. > [TOLGA]That wouldn't be an IPSP, that would be an SGP. An IPSP is supposed > to work according to IPSP procedures defined in the specification. And there are places where we said that the IPSP follows the SGP side of the procedures, which would include sending SNMM. --brian > > > > (And, DAVA and DUPU and DRST.) > > > > > > > > b)For SCON, there is inconsistency in the document. With > > ASPCONG, I don't > > > think there will be a need for SCON for IPSP case. I believe, > > for the sake > > > of completiness, it can be kept in the document for now(?). > > > > While you're making all these changes, why not scrap IPSP altogether? > > It hasn't turned into a very useful part of the specification. > [TOLGA]I think SE-IPSP works fine, just the text needs to be cleaned up. > > > > --brian > > > > > > > > > > > > --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 > > > > -- > > 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 Wed Nov 09 14:18:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvSl-0003nz-0K; Wed, 09 Nov 2005 14:18:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvSj-0003nu-R9 for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 14:18:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01856 for ; Wed, 9 Nov 2005 14:17:58 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvim-0006d3-UO for sigtran@ietf.org; Wed, 09 Nov 2005 14:35:02 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9JI3Ps008361 for ; Wed, 9 Nov 2005 14:18:04 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 13:59:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051109120315.A17443@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Wednesday, November 09, 2005 2:03 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] SE-IPSP definition > > > Tolga, > > Tolga Asveren wrote: > (Wed, 09 Nov 2005 13:33:22) > > Brian, > > > > [..snip..] > > > > > > All SSNM messages are applicable to IPSPs. No change is required. > > [TOLGA]I couldn't disagree more. Could you please tell why they > are needed? > > Because they correspond to MTP-User primitives that need to be delivered > to the AS, regardless of whether the AS is at an ASP or IPSP. [TOLGA]To generate those primitives AS status is enough for IPSP case (considering the addition of ASPCONG, otherwise SCON may be necessary if SCTP congestion is not enough). > > To use your words, it is required by the "Application Logic" for > the peer to > be able to indicate things such as MTP-STATUS. > > --brian > > > > > Availability of remote ends is managed by the state of AS. > > No it cannot in all cases. For example, if an entire PC RK is > used between > IPSP, the IPSP can use DUPU to signal the availabiltiy of individual user > parts to the peer that cannot be accomplished with ASP activation state. [TOLGA]An AS is not supposed to be partially active or inactive. It acts as a single entity. So, the configuration you mentioned is impractical to be used for IPSP case. If one has RK defined on PC granularity, that PC becomes avalable/unavailable as a whole, not in bits and pieces. Please check your reply on "M3UA User Part's Management" thread on 10/10/2005, where you explain the situation very clearly -where you are answering a question about managing user parts for IPSP case-: "To provide M3UA with information about the availability of an MTP User Part requires that the AS be no larger than a User part. You are runnign into difficulties because your AS is too large. Define an AS per user and your difficulties should go away." > > Another case is where NA is used as a RK and multiple point codes > are used at > either end. I know that you do not agree with this arrangement, > but there is > nothing in the current spec forbidding it. [TOLGA]RC is mandatory in RKs, and RKs can't span SPMCs. This is specified in the document. > > > > > As far as I can see only SCON has a use case, and hopefully > with ASPCONG it > > won't be necessary as well. > > They all have "Use Cases". [TOLGA]The specification does not allow them and they are not necessary (except maybe for SCON -for now). IPSP communication relies on ASPTM. BTW, I noticed that there is also no text chnage necessary, there is enough text in the existing speicification disallowing SSNM -except SCON- for IPSP case. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 14:18:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvSz-0003qZ-I8; Wed, 09 Nov 2005 14:18:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvSy-0003qU-BK for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 14:18:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01868 for ; Wed, 9 Nov 2005 14:18:13 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[iBXnoJiU48UnQcat9MTUfRK0KMbC5rDr]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZviv-0006df-EG for sigtran@ietf.org; Wed, 09 Nov 2005 14:35:17 -0500 Received: from ns.pigworks.openss7.net (IDENT:1aUs4z5hrwSDM3+X7XIvaSQj8G7d0xx1@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA9JILc26243; Wed, 9 Nov 2005 12:18:21 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA9JIKF17849; Wed, 9 Nov 2005 12:18:20 -0700 Date: Wed, 9 Nov 2005 12:18:20 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051109121820.B17378@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051109114224.B17044@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, Nov 09, 2005 at 01:33:22PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, See Section 4.6 in RFC 3332, bottom of page 92. An IPSP will have a hard time acting as proscribed without sending SNMM. I think that your idea of IPSP is your own personal one derived from SG-SG work rather than what is described in and permitted by the RFC. --brian Tolga Asveren wrote: (Wed, 09 Nov 2005 13:33:22) > Brian, > > [..snip..] > > > > All SSNM messages are applicable to IPSPs. No change is required. > [TOLGA]I couldn't disagree more. Could you please tell why they are needed? > > Availability of remote ends is managed by the state of AS. > > As far as I can see only SCON has a use case, and hopefully with ASPCONG it > won't be necessary as well. > > > > _______________________________________________ > 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 Nov 09 14:24:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvYQ-0005F7-UT; Wed, 09 Nov 2005 14:24:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvYP-0005C7-7N for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 14:24:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02285 for ; Wed, 9 Nov 2005 14:23:49 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[iLtKY9gBZvZy4iNQ3a4mMux7tuHMTC+2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvo4-0006oZ-3T for sigtran@ietf.org; Wed, 09 Nov 2005 14:40:41 -0500 Received: from ns.pigworks.openss7.net (IDENT:pCwoExiBoMnlgVtU94mIeI5pgMw2onkJ@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jA9JNnc26334; Wed, 9 Nov 2005 12:23:49 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jA9JNnf17906; Wed, 9 Nov 2005 12:23:49 -0700 Date: Wed, 9 Nov 2005 12:23:48 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051109122348.C17378@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051109120315.A17443@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, Nov 09, 2005 at 01:59:49PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Wed, 09 Nov 2005 13:59:49) > Brian, > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Wednesday, November 09, 2005 2:03 PM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] SE-IPSP definition > > > > > > Tolga, > > > > Tolga Asveren wrote: > > (Wed, 09 Nov 2005 13:33:22) > > > Brian, > > > > > > [..snip..] > > > > > > > > All SSNM messages are applicable to IPSPs. No change is required. > > > [TOLGA]I couldn't disagree more. Could you please tell why they > > are needed? > > > > Because they correspond to MTP-User primitives that need to be delivered > > to the AS, regardless of whether the AS is at an ASP or IPSP. > [TOLGA]To generate those primitives AS status is enough for IPSP case > (considering the addition of ASPCONG, otherwise SCON may be necessary if > SCTP congestion is not enough). > > > > To use your words, it is required by the "Application Logic" for > > the peer to > > be able to indicate things such as MTP-STATUS. > > > > --brian > > > > > > > > Availability of remote ends is managed by the state of AS. > > > > No it cannot in all cases. For example, if an entire PC RK is > > used between > > IPSP, the IPSP can use DUPU to signal the availabiltiy of individual user > > parts to the peer that cannot be accomplished with ASP activation state. > [TOLGA]An AS is not supposed to be partially active or inactive. It acts as > a single entity. So, the configuration you mentioned is impractical to be > used for IPSP case. If one has RK defined on PC granularity, that PC becomes > avalable/unavailable as a whole, not in bits and pieces. Please check your > reply on "M3UA User Part's Management" thread on 10/10/2005, where you > explain the situation very clearly -where you are answering a question about > managing user parts for IPSP case-: > > "To provide M3UA with information about the availability > of an MTP User Part requires that the AS be no larger > than a User part. You are runnign into difficulties > because your AS is too large. Define an AS per user > and your difficulties should go away." That is for the ASP/SGP scenario where the ASP does not send DUPU. In the IPSP case the IPSP acting as SGP can send DUPU and the arragement is possible. --brian > > > > Another case is where NA is used as a RK and multiple point codes > > are used at > > either end. I know that you do not agree with this arrangement, > > but there is > > nothing in the current spec forbidding it. > [TOLGA]RC is mandatory in RKs, and RKs can't span SPMCs. This is specified > in the document. > > > > > > > > As far as I can see only SCON has a use case, and hopefully > > with ASPCONG it > > > won't be necessary as well. > > > > They all have "Use Cases". > [TOLGA]The specification does not allow them Where?! The specification allows them by not forbidding them. > and they are not necessary > (except maybe for SCON -for now). IPSP communication relies on ASPTM. BTW, I > noticed that there is also no text chnage necessary, there is enough text in > the existing speicification disallowing SSNM -except SCON- for IPSP case. See Section 4.6 where the reverse of your view is stated. It states that an IPSP can follow SGP behavior with regard to SSNM. --brian > > > > --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 -- 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 Nov 09 14:47:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvv3-0006WA-10; Wed, 09 Nov 2005 14:47:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvv0-0006W5-Iz for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 14:47:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03783 for ; Wed, 9 Nov 2005 14:47:10 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZwB3-0007XW-HN for sigtran@ietf.org; Wed, 09 Nov 2005 15:04:15 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jA9JlIcg011384 for ; Wed, 9 Nov 2005 14:47:20 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Wed, 9 Nov 2005 14:29:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051109120817.C17443@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, -I will try to consolidate my replies as much as I can- > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Brian F. G. Bidulock > Sent: Wednesday, November 09, 2005 2:08 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] SE-IPSP definition > > > Tolga, > > I an not talking about SNMM used to indicate the status of remote point > codes, etc. I am talking about SNMM used to indciate the status of local > point codes, etc. for the sending IPSP. [TOLGA]ASPTM should be enough for that purpose. If one wants to be notified about remote user part status for IPSP case, one should have RKs defined in User Part granularity. For availability/unavailability there is ASPAC/ASPIA. We only miss the congestion message in ASPTM, which hopefully should be ready soon. > > Also, it might not be necessary (in all cases), it might not even be very > useful (in some cases), but it is currently not prohibited. a)I am not speaking of SG-SG at all, what I am saying has nothing to do with it. You also know that actually it is SG-SG, which is SSNM based -and which makes sense considering the services it needs to provide-, but this is not hte topic right now. b)Your answer in "M3UA User Part's Management" thread was about IPSP communication, if you want, you can check the original question in that thread. ;-) c)The section you mention in "4.6 MTP3 Restart" is really really wrong and needs an update IMHO. An IPSP does not have MTP3 layer. One obviously can build a box which provides both SGP and IPSP services but IPSP functionality itself has nothing to do with MTP3. IPSP will host only local application logic which communicates directly with another application hosted byt a peer IPSP. Remote endpoint in traditional SS7 domain will be responsibility of SGP and MTP3 restart is applicable only for SGP, not for IPSP. For the sake of making progress here is what I think: a)People are confused about use of SSNM for IPSP (I think we agree about this) b)SSNM is not necessary for IPSP case -except for SCON, which needs further study, i.e. ASPCONG-. If there is a situation where we *really* need it, let's try to figure out whether it can be handled with ASPTM. (This is my position. AFAICS, you also think that it is probably not a good idea to use SSNM either but you think that the document does not disallow this.) _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 09 20:19:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea15q-0006q6-Ae; Wed, 09 Nov 2005 20:19:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea15n-0006pl-Jg for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 20:19:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24094 for ; Wed, 9 Nov 2005 20:18:40 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[BMp6lDBvfDJfl/3qthycmBWoZ3YJS8dz]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea1Lu-0000LU-1y for sigtran@ietf.org; Wed, 09 Nov 2005 20:35:47 -0500 Received: from ns.pigworks.openss7.net (IDENT:JozaQOhyqHzVnqLU2UonTw0SDWHhidFi@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAA1Itc00642; Wed, 9 Nov 2005 18:18:55 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAA1It520494; Wed, 9 Nov 2005 18:18:55 -0700 Date: Wed, 9 Nov 2005 18:18:55 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051109181855.A20305@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051109120817.C17443@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, Nov 09, 2005 at 02:29:04PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, I think that you are talking about something completely different than RFC 3332. Might I suggest a new IPSP draft that has things the way that you want them? --brian Tolga Asveren wrote: (Wed, 09 Nov 2005 14:29:04) > Brian, > > > -I will try to consolidate my replies as much as I can- > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Brian F. G. Bidulock > > Sent: Wednesday, November 09, 2005 2:08 PM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] SE-IPSP definition > > > > > > Tolga, > > > > I an not talking about SNMM used to indicate the status of remote point > > codes, etc. I am talking about SNMM used to indciate the status of local > > point codes, etc. for the sending IPSP. > [TOLGA]ASPTM should be enough for that purpose. If one wants to be notified > about remote user part status for IPSP case, one should have RKs defined in > User Part granularity. For availability/unavailability there is ASPAC/ASPIA. > We only miss the congestion message in ASPTM, which hopefully should be > ready soon. > > > > Also, it might not be necessary (in all cases), it might not even be very > > useful (in some cases), but it is currently not prohibited. > a)I am not speaking of SG-SG at all, what I am saying has nothing to do with > it. You also know that actually it is SG-SG, which is SSNM based -and which > makes sense considering the services it needs to provide-, but this is not > hte topic right now. > > b)Your answer in "M3UA User Part's Management" thread was about IPSP > communication, if you want, you can check the original question in that > thread. ;-) > > c)The section you mention in "4.6 MTP3 Restart" is really really wrong and > needs an update IMHO. An IPSP does not have MTP3 layer. One obviously can > build a box which provides both SGP and IPSP services but IPSP functionality > itself has nothing to do with MTP3. IPSP will host only local application > logic which communicates directly with another application hosted byt a peer > IPSP. Remote endpoint in traditional SS7 domain will be responsibility of > SGP and MTP3 restart is applicable only for SGP, not for IPSP. > > For the sake of making progress here is what I think: > a)People are confused about use of SSNM for IPSP (I think we agree about > this) > b)SSNM is not necessary for IPSP case -except for SCON, which needs further > study, i.e. ASPCONG-. If there is a situation where we *really* need it, > let's try to figure out whether it can be handled with ASPTM. (This is my > position. AFAICS, you also think that it is probably not a good idea to use > SSNM either but you think that the document does not disallow this.) > > > > > > _______________________________________________ > 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 enum-bounces@ietf.org Wed Nov 09 20:19:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea15v-0006rD-Bc; Wed, 09 Nov 2005 20:19:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea15u-0006qg-5d for enum@megatron.ietf.org; Wed, 09 Nov 2005 20:19:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24103 for ; Wed, 9 Nov 2005 20:18:46 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea1M0-0000LX-Mw for enum@ietf.org; Wed, 09 Nov 2005 20:35:54 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id jAA1cZPv022409; Wed, 9 Nov 2005 20:38:35 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 20:18:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] please post issues from yesterdays session Date: Wed, 9 Nov 2005 20:18:53 -0500 Message-ID: Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAH6kHXAAe9YWg= From: "Cartwright, Kenneth" To: "Stastny Richard" , "Alexander Mayrhofer" , X-OriginalArrivalTime: 10 Nov 2005 01:18:54.0424 (UTC) FILETIME=[B75E0580:01C5E594] X-Spam-Score: 0.5 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2114497427==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============2114497427== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E594.B6F88890" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E594.B6F88890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Right, I feel that the Requirements section (section 3) in the haberler = document further clarifies the carrier er. infrastructure ENUM problem, = and is mostly complementary with what's already in the lind document. = ...but it's a small point. =20 Ken ________________________________ From: enum-bounces@ietf.org on behalf of Stastny Richard Sent: Wed 11/9/2005 4:43 PM To: Alexander Mayrhofer; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session This was not brought up by me, but concerns our draft: The definitions and terminolgy used in draft-haberler-carrier-enum-01 should be moved over and aligned with the definitions and terminology in draft-lind-infrastructure-enum-reqs-01 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C5E594.B6F88890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Enum] please post issues from yesterdays session=0A= =0A= =0A=

=0A=
Right, I feel = that the =0A= Requirements section (section 3) in the haberler document further = clarifies the =0A= carrier er. infrastructure ENUM problem, and is mostly = complementary with =0A= what's already in the lind document.  ...but it's a small =0A= point.
=0A=
 
=0A=
Ken
=0A=

=0A=
=0A= From: enum-bounces@ietf.org on = behalf of Stastny =0A= Richard
Sent: Wed 11/9/2005 4:43 PM
To: Alexander = Mayrhofer; =0A= enum@ietf.org
Subject: Re: [Enum] please post issues from = yesterdays =0A= session

=0A=
=0A=

This was not brought up by me, but concerns
our =0A= draft:

The definitions and terminolgy used =0A= in
draft-haberler-carrier-enum-01 should be moved over and = aligned
with =0A= the definitions and terminology =0A= in
draft-lind-infrastructure-enum-reqs-01

Richard

______= __________________________

Von: =0A= enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer
Gesendet: Mi =0A= 09.11.2005 18:37
An: enum@ietf.org
Betreff: [Enum] please post = issues from =0A= yesterdays session



All,

i'd like to ask you to = post any =0A= issue which you brought up during
yesterday's WG session on the =0A= list.

that would make tracking those issues much more =0A= easier.

thanks,

alex


___________________________= ____________________
enum =0A= mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum



______________________________= _________________
enum =0A= mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum

=0A= =0A= =0A= ------_=_NextPart_001_01C5E594.B6F88890-- --===============2114497427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============2114497427==-- From sigtran-bounces@ietf.org Thu Nov 10 04:50:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea94h-0005FY-MT; Thu, 10 Nov 2005 04:50:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea94f-0005FN-Cb for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 04:50:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20571 for ; Thu, 10 Nov 2005 04:50:00 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea9Kq-0004a2-CF for sigtran@ietf.org; Thu, 10 Nov 2005 05:07:13 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jAA9oG7P001660; Thu, 10 Nov 2005 03:50:17 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Nov 2005 09:50:16 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00CE6ED92@en0033exch001u.uk.lucent.com> From: "Holland, Peter Michael (Peter)" To: "'bidulock@openss7.org'" Subject: RE: [Sigtran] SE-IPSP definition Date: Thu, 10 Nov 2005 09:50:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sigtran@ietf.org, 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, .... > > > > Reading this thread the problem I see with SE procedures was > > identified in a mail where Brian said: > > >If you want both IPSPs to each have an AS an traffic mode, > use DE instead > > of SE. > > Thus I understand there are situations where SE mode cannot be > > used. This is not clear in RFC. > > No, there are not situations where SE mode cannot be used. What I was > saying was that if one pedantically requies that both peers have and > exchange a traffic mode (which they don't need in the first > place) that > one should use the DE mode. > > SE can work quite fine in all situations with one side not > having an ASP > traffic mode. No change is required. > So you agree that it does not work so well when both ASs have a redundant architecture - loadshare or override? I don't understand why you refer to this as a pedantic requirement - it is an architectural/implementation robustness requirement in some situations. Pete _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 05:23:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea9aM-0006Vb-BO; Thu, 10 Nov 2005 05:23:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea9aJ-0006TF-Ng for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 05:23:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22142 for ; Thu, 10 Nov 2005 05:22:42 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[FJ1T8XznAyM9BnazI+Q5hfl83sObZXGS]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea9qT-0005Lr-Mb for sigtran@ietf.org; Thu, 10 Nov 2005 05:39:56 -0500 Received: from ns.pigworks.openss7.net (IDENT:1QXLSze1rSDhLogB1vAoTrHykBO9lrmK@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAAAMqc10805; Thu, 10 Nov 2005 03:22:52 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAAAMpQ26172; Thu, 10 Nov 2005 03:22:51 -0700 Date: Thu, 10 Nov 2005 03:22:51 -0700 From: "Brian F. G. Bidulock" To: "Holland, Peter Michael (Peter)" Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051110032251.A25993@openss7.org> Mail-Followup-To: "Holland, Peter Michael (Peter)" , 'Tolga Asveren' , sigtran@ietf.org References: <475FF955A05DD411980D00508B6D5FB00CE6ED92@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <475FF955A05DD411980D00508B6D5FB00CE6ED92@en0033exch001u.uk.lucent.com>; from pmholland@lucent.com on Thu, Nov 10, 2005 at 09:50:12AM -0000 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sigtran@ietf.org, 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Peter, Holland, Peter Michael (Peter) wrote: (Thu, 10 Nov 2005 09:50:12) --X--snip--X-- > > So you agree that it does not work so well when both ASs have a redundant > architecture - loadshare or override? > I don't understand why you refer to this as a pedantic requirement - it is > an architectural/implementation robustness requirement in some situations. > --X--snip--X-- It is pedantic because an IPSP does not need an ASP Traffic Mode to be redundant. When acting like an SGP, the peer IPSP can distribute traffic in accordance with the way that an ASP distributes messages to the SGP that make up an SG. The SE-IPSP acting in SGP mode does not require an "ASP Traffic Mode". Traffic Mode (the parameter) is an ASP concept. Is is only useful to an SE-IPSP in so much as the SE-IPSP is behaving like an ASP. In SE mode, it was never intended that both sides behave like an ASP at the same time. That is DE mode. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 05:39:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea9qH-0002Ym-Ht; Thu, 10 Nov 2005 05:39:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea9qF-0002WZ-V0 for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 05:39:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23053 for ; Thu, 10 Nov 2005 05:39:11 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaA6R-0005oE-8G for sigtran@ietf.org; Thu, 10 Nov 2005 05:56:24 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jAAAdTtM019986; Thu, 10 Nov 2005 04:39:30 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Nov 2005 10:39:29 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00CE6ED95@en0033exch001u.uk.lucent.com> From: "Holland, Peter Michael (Peter)" To: "'bidulock@openss7.org'" Subject: RE: [Sigtran] SE-IPSP definition Date: Thu, 10 Nov 2005 10:39:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sigtran@ietf.org, 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, Can I remind you that the definition of IPSP is: IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not use the services of a Signalling Gateway node. Thus your mention of IPSP acting as an SGP is not according to spec. Considering that definition, your statement: > In SE mode, > it was never intended that both sides behave like an ASP at the same > time. That is DE mode. is not reflected in the spec - thus the confusion. Pete > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: 10 November 2005 10:23 > To: Holland, Peter Michael (Peter) > Cc: 'Tolga Asveren'; sigtran@ietf.org > Subject: Re: [Sigtran] SE-IPSP definition > > > Peter, > > Holland, Peter Michael (Peter) wrote: (Thu, 10 Nov > 2005 09:50:12) > > --X--snip--X-- > > > > So you agree that it does not work so well when both ASs > have a redundant > > architecture - loadshare or override? > > I don't understand why you refer to this as a pedantic > requirement - it is > > an architectural/implementation robustness requirement in > some situations. > > > --X--snip--X-- > > It is pedantic because an IPSP does not need an ASP Traffic Mode to be > redundant. When acting like an SGP, the peer IPSP can distribute > traffic in accordance with the way that an ASP distributes messages to > the SGP that make up an SG. The SE-IPSP acting in SGP mode does not > require an "ASP Traffic Mode". > > Traffic Mode (the parameter) is an ASP concept. Is is only > useful to an > SE-IPSP in so much as the SE-IPSP is behaving like an ASP. > In SE mode, > it was never intended that both sides behave like an ASP at the same > time. That is DE mode. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 07:37:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaBgB-0003HS-Ky; Thu, 10 Nov 2005 07:37:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaBg9-0003HF-7B for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 07:37:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29201 for ; Thu, 10 Nov 2005 07:36:53 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[Mii3Ik6aAInIntpcXZLWOcWk/ax7Kaje]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaBwJ-0000GV-7a for sigtran@ietf.org; Thu, 10 Nov 2005 07:54:07 -0500 Received: from ns.pigworks.openss7.net (IDENT:4oz1Pb9GVyKJ2g76qkAHw23aSAdxKhO+@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAACbFc13758; Thu, 10 Nov 2005 05:37:15 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAACbAD27940; Thu, 10 Nov 2005 05:37:10 -0700 Date: Thu, 10 Nov 2005 05:37:09 -0700 From: "Brian F. G. Bidulock" To: "Holland, Peter Michael (Peter)" Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051110053709.A26397@openss7.org> Mail-Followup-To: "Holland, Peter Michael (Peter)" , 'Tolga Asveren' , sigtran@ietf.org References: <475FF955A05DD411980D00508B6D5FB00CE6ED95@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <475FF955A05DD411980D00508B6D5FB00CE6ED95@en0033exch001u.uk.lucent.com>; from pmholland@lucent.com on Thu, Nov 10, 2005 at 10:39:28AM -0000 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: sigtran@ietf.org, 'Tolga Asveren' X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Peter, A couple of comments: - (See "[SUA issue 17 & M3UA issue #11] IPSP cases" in the archives, as well as "M3UA/SUA IPSP" and "IPSP proposed text (1st approach)" "IPSP-IPSP summary" "Consensus call (was: IPSP-IPSP summary)" "IPSP test (2nd approach)" "IPSP text - poll" "IPSP text (take 3?)" "Summary (hopefully) was: IPSP Text (take 3?)") There were several thousand mails exchanged on the topic. - What you quote is just a definition, not a requirement. (And in fact it is an old one that predates the SE model and the entire IPSP discussion.) As it contains no requirements, there was no need to change it. - The phrase "SGP or IPSP" occurs many times in RFC 3332 and RFC 3868. - I invented SE mode (when the rest of the WG was demanding DE mode). If I had not argued through several hundred emails, you would only have DE mode now. - To have a single exchange of messages it is a necessary that one side behave like an ASP (messages and state machines) and the other behave like an SGP (messages and state machines). - An IPSP is often described as behaving like an SGP. - John Loughney described how an IPSP responds to a received message in an attempt to limit complexity. Because ASPs normally initiate messages, the passages describing IPSP decribe the IPSP as responding to the message in the same manner as an SGP (making the same state transitions and performing the same actions). So even if an IPSP is defined as something like an ASP, its behaviour is most often described in the RFC as something like an SGP. - Contrary to what Tolga says now, exchange of SSNM was always part of SE-IPSP. It was exchange of ASPTM/SM that was questioned as whether it should be included in SE-IPSP communication at all. - To limit changes to the RFC and move forward, we underspecified IPSP to allow for a wide range of combinations. The resulting nightmare for interoperability was supposed to be addressed in extension drafts but never was. - We purposely did not preclude any arrangements or interpretations in the RFC. What functions the IPSP provides locally are closer to an implementation decision than a a protocol requirement. - We intentionally did not introduce any changes to the ASP/SGP exchange for IPSP (we did not want define two protocols in one RFC). Any changes to (or narrowing of) the normal ASP/SGP exchanges were to be addressed by extension drafts (but never were). --brian Holland, Peter Michael (Peter) wrote: (Thu, 10 Nov 2005 10:39:28) > Brian, > Can I remind you that the definition of IPSP is: > IP Server Process (IPSP) - A process instance of an IP-based > application. An IPSP is essentially the same as an ASP, except that > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > not use the services of a Signalling Gateway node. > > Thus your mention of IPSP acting as an SGP is not according to spec. > Considering that definition, your statement: > > In SE mode, > > it was never intended that both sides behave like an ASP at the same > > time. That is DE mode. > is not reflected in the spec - thus the confusion. > > Pete > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 08:14:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaCDQ-00040v-61; Thu, 10 Nov 2005 08:11:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaCDO-0003up-RY for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 08:11:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01534 for ; Thu, 10 Nov 2005 08:11:12 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaCTa-0001LA-9Z for sigtran@ietf.org; Thu, 10 Nov 2005 08:28:26 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jAADBNDF018980 for ; Thu, 10 Nov 2005 08:11:25 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Thu, 10 Nov 2005 07:54:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051110032251.A25993@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Please see below for comments. > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Thursday, November 10, 2005 5:23 AM > To: Holland, Peter Michael (Peter) > Cc: 'Tolga Asveren'; sigtran@ietf.org > Subject: Re: [Sigtran] SE-IPSP definition > > > Peter, > > Holland, Peter Michael (Peter) wrote: (Thu, 10 Nov > 2005 09:50:12) > > --X--snip--X-- > > > > So you agree that it does not work so well when both ASs have a > redundant > > architecture - loadshare or override? > > I don't understand why you refer to this as a pedantic > requirement - it is > > an architectural/implementation robustness requirement in some > situations. > > > --X--snip--X-- > > It is pedantic because an IPSP does not need an ASP Traffic Mode to be > redundant. When acting like an SGP, the peer IPSP can distribute > traffic in accordance with the way that an ASP distributes messages to > the SGP that make up an SG. The SE-IPSP acting in SGP mode does not > require an "ASP Traffic Mode". > > Traffic Mode (the parameter) is an ASP concept. Is is only useful to an > SE-IPSP in so much as the SE-IPSP is behaving like an ASP. In SE mode, > it was never intended that both sides behave like an ASP at the same > time. That is DE mode. [TOLGA]SE-IPSP is an IPSP not an ASP not an SGP. For certain message transactions, it follows the same message sequence but conceptually it is not equal to ASP not to SGP. So, I 100% agree with Peter, traffic mode is necessary bothways for SE-IPSP case. Traffic mode is an attribute associated with application logic and for IPSP case, there is application logic present at both ends. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 08:23:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaCOb-000868-En; Thu, 10 Nov 2005 08:23:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaCOZ-00085r-94 for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 08:23:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02206 for ; Thu, 10 Nov 2005 08:22:47 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[IAkcNCI+PCWriwmfcF7vW8r3O2lc+ZvY]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaCek-0001fr-TY for sigtran@ietf.org; Thu, 10 Nov 2005 08:40:01 -0500 Received: from ns.pigworks.openss7.net (IDENT:5VZnQusIp2AcJ71jTk88k4PirKFjGXpi@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAADMwc14745; Thu, 10 Nov 2005 06:22:58 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAADMwC28875; Thu, 10 Nov 2005 06:22:58 -0700 Date: Thu, 10 Nov 2005 06:22:58 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051110062258.A28833@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051110032251.A25993@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 Thu, Nov 10, 2005 at 07:54:04AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) 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: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Thu, 10 Nov 2005 07:54:04) > > --X--snip--X-- > > > > It is pedantic because an IPSP does not need an ASP Traffic Mode to be > > redundant. When acting like an SGP, the peer IPSP can distribute > > traffic in accordance with the way that an ASP distributes messages to > > the SGP that make up an SG. The SE-IPSP acting in SGP mode does not > > require an "ASP Traffic Mode". > > > > Traffic Mode (the parameter) is an ASP concept. Is is only useful to an > > SE-IPSP in so much as the SE-IPSP is behaving like an ASP. In SE mode, > > it was never intended that both sides behave like an ASP at the same > > time. That is DE mode. > [TOLGA]SE-IPSP is an IPSP not an ASP not an SGP. For certain message > transactions, it follows the same message sequence but conceptually it is > not equal to ASP not to SGP. So, I 100% agree with Peter, traffic mode is > necessary bothways for SE-IPSP case. Traffic mode is an attribute associated > with application logic and for IPSP case, there is application logic present > at both ends. It is not even necessary that there be application logic present at the IPSP. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 08:40:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaCey-0004bT-6s; Thu, 10 Nov 2005 08:40:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaCew-0004b5-6Z for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 08:40:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03400 for ; Thu, 10 Nov 2005 08:39:42 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaCv8-0002BI-Nu for sigtran@ietf.org; Thu, 10 Nov 2005 08:56:56 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jAADdpHu021611 for ; Thu, 10 Nov 2005 08:39:53 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Thu, 10 Nov 2005 08:22:32 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051110053709.A26397@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, [..snip..] > - To have a single exchange of messages it is a necessary that one side > behave like an ASP (messages and state machines) and the other behave > like an SGP (messages and state machines). [TOLGA]Wrong. Take a look to Figure 3. IPSP can send and receive ASPAC/ASPIA messages. As an example -just showing ASPAC messages- SE-IPSP1 SE-IPSP2 | | |-------ASPAC------------->| | | |<-----ASPAC-ACK-----------| | | | AS is active at both | | sides | | | |<-------ASPIA-------------| | | |------ASPIA-ACK---------->| | | | AS is inactive | | at both sides | | | The above is a valid message sequence. Neither ASP nor SGP can support the above message exchange. Thinking that an SE-IPSP behaves as ASP and the other one as SGP for the whole set of message exchanges is wrong. I singled out this issue because this is the key of the confusion. Basically, an IPSP is an IPSPS neither ASP not a SGP. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 08:55:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaCte-0008DN-Ql; Thu, 10 Nov 2005 08:55:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaCtd-0008DI-3a for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 08:55:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04320 for ; Thu, 10 Nov 2005 08:54:53 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[Gp2z2ogUTZc5WXWAezMzjvQpRBOC837g]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaD9p-0002bl-68 for sigtran@ietf.org; Thu, 10 Nov 2005 09:12:07 -0500 Received: from ns.pigworks.openss7.net (IDENT:88c8pshqLIiV4lKbR9VeCz9EB6lIGUgS@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAADtDc15406; Thu, 10 Nov 2005 06:55:13 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAADtCe29176; Thu, 10 Nov 2005 06:55:12 -0700 Date: Thu, 10 Nov 2005 06:55:12 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051110065512.A29145@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051110053709.A26397@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 Thu, Nov 10, 2005 at 08:22:32AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Thu, 10 Nov 2005 08:22:32) > Brian, > > [..snip..] > > - To have a single exchange of messages it is a necessary that one side > > behave like an ASP (messages and state machines) and the other behave > > like an SGP (messages and state machines). > [TOLGA]Wrong. Take a look to Figure 3. IPSP can send and receive ASPAC/ASPIA > messages. As an example -just showing ASPAC messages- > > SE-IPSP1 SE-IPSP2 > | | > |-------ASPAC------------->| > | | > |<-----ASPAC-ACK-----------| > | | > | AS is active at both | > | sides | > | | > |<-------ASPIA-------------| > | | > |------ASPIA-ACK---------->| > | | > | AS is inactive | > | at both sides | > | | > > The above is a valid message sequence. Neither ASP nor SGP can support the > above message exchange. Thinking that an SE-IPSP behaves as ASP and the > other one as SGP for the whole set of message exchanges is wrong. I singled > out this issue because this is the key of the confusion. Basically, an IPSP > is an IPSPS neither ASP not a SGP. This message exchange is not required to be supported. The following two other possibilities are just as valid: SE-IPSP1 SE-IPSP2 | | |-------ASPAC------------->| | | |<-----ASPAC-ACK-----------| | | | AS is active at both | | sides | | | |<-------ASPIA-------------| | | |-ERR[Unexpected Message]->| | | SE-IPSP1 SE-IPSP2 | | |-------ASPAC------------->| | | |<-----ASPAC-ACK-----------| | | | AS is active at both | | sides | | | |<-------ASPIA-ACK---------| | | |-------ASPAC------------->| | | |<---ERR[Mgmt. Blocking]---| | | --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 09:04:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaD2M-0001Ok-ID; Thu, 10 Nov 2005 09:04:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaD2K-0001Od-U4 for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 09:04:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04874 for ; Thu, 10 Nov 2005 09:03:52 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaDIX-0002pQ-CM for sigtran@ietf.org; Thu, 10 Nov 2005 09:21:07 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jAAE3rwp024309 for ; Thu, 10 Nov 2005 09:03:55 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Thu, 10 Nov 2005 08:46:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051110065512.A29145@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, (To prevent mailing list pollution my last message on this subtopic -maybe not on this thread- ) > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Thursday, November 10, 2005 8:55 AM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] SE-IPSP definition > > > Tolga, > > Tolga Asveren wrote: > (Thu, 10 Nov 2005 08:22:32) > > Brian, > > > > [..snip..] > > > - To have a single exchange of messages it is a necessary > that one side > > > behave like an ASP (messages and state machines) and the > other behave > > > like an SGP (messages and state machines). > > [TOLGA]Wrong. Take a look to Figure 3. IPSP can send and > receive ASPAC/ASPIA > > messages. As an example -just showing ASPAC messages- > > > > SE-IPSP1 SE-IPSP2 > > | | > > |-------ASPAC------------->| > > | | > > |<-----ASPAC-ACK-----------| > > | | > > | AS is active at both | > > | sides | > > | | > > |<-------ASPIA-------------| > > | | > > |------ASPIA-ACK---------->| > > | | > > | AS is inactive | > > | at both sides | > > | | > > > > The above is a valid message sequence. Neither ASP nor SGP can > support the > > above message exchange. Thinking that an SE-IPSP behaves as ASP and the > > other one as SGP for the whole set of message exchanges is > wrong. I singled > > out this issue because this is the key of the confusion. > Basically, an IPSP > > is an IPSPS neither ASP not a SGP. > > This message exchange is not required to be supported. [TOLGA]Sorry but you are totally wrong. This is very well supported by SE-IPSP state machine. > > The following two other possibilities are just as valid: > > SE-IPSP1 SE-IPSP2 > | | > |-------ASPAC------------->| > | | > |<-----ASPAC-ACK-----------| > | | > | AS is active at both | > | sides | > | | > |<-------ASPIA-------------| > | | > |-ERR[Unexpected Message]->| > | | [TOLGA] This is supported from M3UA point of view but means that your SE-IPSP1 is either not an SE-IPSP or a broken one, because it does not support IPSP state machine as defined by the specifications. > > > SE-IPSP1 SE-IPSP2 > | | > |-------ASPAC------------->| > | | > |<-----ASPAC-ACK-----------| > | | > | AS is active at both | > | sides | > | | > |<-------ASPIA-ACK---------| > | | > |-------ASPAC------------->| > | | > |<---ERR[Mgmt. Blocking]---| > | | [TOLGA]Hmmm, I am not sure about this. IMO no need to support this -because SE-IPSP2 can send ASPIA instead of ASPIA-ACK- but OTOH this has nothing to do with our discussion. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 09:34:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaDVV-000327-6g; Thu, 10 Nov 2005 09:34:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaDVT-000322-QT for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 09:34:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06584 for ; Thu, 10 Nov 2005 09:33:59 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[/alRfwxgcL8wy2koS2jMoifptxZ4ek8M]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaDlY-0003dR-AL for sigtran@ietf.org; Thu, 10 Nov 2005 09:51:14 -0500 Received: from ns.pigworks.openss7.net (IDENT:7LMS0Wzv2OBwPqHOsTnkXuehY7QD6nRp@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAAEYFc16057; Thu, 10 Nov 2005 07:34:15 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAAEYE129701; Thu, 10 Nov 2005 07:34:14 -0700 Date: Thu, 10 Nov 2005 07:34:14 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051110073414.A29588@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051110065512.A29145@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 Thu, Nov 10, 2005 at 08:46:34AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Thu, 10 Nov 2005 08:46:34) > > > > This message exchange is not required to be supported. > [TOLGA]Sorry but you are totally wrong. This is very well supported by > SE-IPSP state machine. It is not required by it. Although we permitted either SE-IPSP to initiate the exchange, there is no requirement to support switching of roles once an AS has been activated. Permitting switching of roles in the fashion that you originally indicated is problematic as follows: SE-IPSP1 SE-IPSP2 | | |-------ASPAC------------->| | | |<-------ASPIA-------------| | | |-------ASPIA------------->| | | |<-------ASPAC-------------| .... What now? Is it active? Inactive? This is why, although either side may initiate the exchange, it should stick with one role. > > > > The following two other possibilities are just as valid: > > > > SE-IPSP1 SE-IPSP2 > > | | > > |-------ASPAC------------->| > > | | > > |<-----ASPAC-ACK-----------| > > | | > > | AS is active at both | > > | sides | > > | | > > |<-------ASPIA-------------| > > | | > > |-ERR[Unexpected Message]->| > > | | > [TOLGA] This is supported from M3UA point of view but means that your > SE-IPSP1 is either not an SE-IPSP or a broken one, because it does not > support IPSP state machine as defined by the specifications. If the IPSP is by definition just an ASP, then the exchange is perfectly valid. The IPSP actually has to act like an SGP to to respond to such messages. Also, to avoid the "glare" not handled by the RFC state machines, this is a way to tell the other side not to change roles, or that its role is unexpected. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 10:01:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaDvE-0000rA-11; Thu, 10 Nov 2005 10:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaDvC-0000r5-E6 for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 10:01:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07888 for ; Thu, 10 Nov 2005 10:00:34 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaEBP-0004JI-1S for sigtran@ietf.org; Thu, 10 Nov 2005 10:17:49 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jAAF0goP001029 for ; Thu, 10 Nov 2005 10:00:44 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Thu, 10 Nov 2005 09:43:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051110073414.A29588@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Thursday, November 10, 2005 9:34 AM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] SE-IPSP definition > > > Tolga, > > Tolga Asveren wrote: > (Thu, 10 Nov 2005 08:46:34) > > > > > > This message exchange is not required to be supported. > > [TOLGA]Sorry but you are totally wrong. This is very well supported by > > SE-IPSP state machine. > > It is not required by it. [TOLGA]Sorry to break my promise of not replying for this subtopic, but it *is* required by it. You can't strip certain pieces of a state machine and claim that you support it because certain pieces are not required. The state machine allows it, so it is requried if you want to claim that your product is fully complaint with it. > > Although we permitted either SE-IPSP to initiate the exchange, there is > no requirement to support switching of roles once an AS has been > activated. [TOLGA]Take a look to the state machine, you re totally wrong. There are no SGP/ASP roles assigned to IPSPs for the whole message exchange, that is the reason why there an IPSP state machine. > Permitting switching of roles in the fashion that you originally indicated > is problematic as follows: > > SE-IPSP1 SE-IPSP2 > | | > |-------ASPAC------------->| > | | > |<-------ASPIA-------------| > | | > |-------ASPIA------------->| > | | > |<-------ASPAC-------------| > > .... What now? Is it active? Inactive? > > This is why, although either side may initiate the exchange, it > should stick > with one role. [TOLGA]Two points: a)If there are open points -and I would think there may be some- in the IPSP state machine, they can be fixed, this does not mean changing the whole architecture. b)For your example: I assume initially AS in INACTIVE. Because ASPAC from IPSP1 is not acknowledged with ASPAC-ACK AS states INACTIVE. With ASPIA from IPSPS2 AS state is INACTIVE With ASPIA from IPSP1 AS state is INACTIVE With ASPAC from IPSP2 AS is still INACTIVE. If IPSP1 replies with ASPAC-ACK, AS will become ACTIVE. For the above, we may need to clarify things in the IPSP state machine -maybe introducing transitionary states-, but as said above this is nowhere near to be a showstopper and does not require an architectural change. > > > > > > > The following two other possibilities are just as valid: > > > > > > SE-IPSP1 SE-IPSP2 > > > | | > > > |-------ASPAC------------->| > > > | | > > > |<-----ASPAC-ACK-----------| > > > | | > > > | AS is active at both | > > > | sides | > > > | | > > > |<-------ASPIA-------------| > > > | | > > > |-ERR[Unexpected Message]->| > > > | | > > [TOLGA] This is supported from M3UA point of view but means that your > > SE-IPSP1 is either not an SE-IPSP or a broken one, because it does not > > support IPSP state machine as defined by the specifications. > > If the IPSP is by definition just an ASP, then the exchange is perfectly > valid. The IPSP actually has to act like an SGP to to respond to such > messages. [TOLGA]If IPSP were nothing else than ASP in terms of M3UA processing, we wouldn't mention anything about it except the definition. The similarity between IPSP and ASP is that they both host application logic, that is it. >From M3UA state machine processing point of view, they are different entities. > > Also, to avoid the "glare" not handled by the RFC state machines, this is > a way to tell the other side not to change roles, or that its role is > unexpected. [TOLGA]Now, you try to change the SE-IPSP model in the specification? ;-) To support the model you want, you don't need to define anything new, just put ASPF and SGPF together and there you are. If you don't want to use IPSP that is fine. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 13:35:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHGZ-0002ra-9i; Thu, 10 Nov 2005 13:35:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHGW-0002qw-DN for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 13:35:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24241 for ; Thu, 10 Nov 2005 13:34:47 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[uk7SHGpF4EYS3TyTgIZ7FI8gzwFTSVkH]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaHWk-000392-OV for sigtran@ietf.org; Thu, 10 Nov 2005 13:52:04 -0500 Received: from ns.pigworks.openss7.net (IDENT:hiJwoewIBDdVGeMMkYSeRK5WlRLtk5gx@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAAIZ8c20899; Thu, 10 Nov 2005 11:35:08 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAAIZ7X31914; Thu, 10 Nov 2005 11:35:07 -0700 Date: Thu, 10 Nov 2005 11:35:07 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051110113507.B31739@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051110073414.A29588@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 Thu, Nov 10, 2005 at 09:43:23AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Thu, 10 Nov 2005 09:43:23) > Brian, > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Thursday, November 10, 2005 9:34 AM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] SE-IPSP definition > > > > > > Tolga, > > > > Tolga Asveren wrote: > > (Thu, 10 Nov 2005 08:46:34) > > > > > > > > This message exchange is not required to be supported. > > > [TOLGA]Sorry but you are totally wrong. This is very well supported by > > > SE-IPSP state machine. > > > > It is not required by it. > [TOLGA]Sorry to break my promise of not replying for this subtopic, but it > *is* required by it. You can't strip certain pieces of a state machine and > claim that you support it because certain pieces are not required. The state > machine allows it, so it is requried if you want to claim that your product > is fully complaint with it. Huh? Compliance? Where does it say that I must follow the state machine illustrated in the RFC? Also understand that the state machine is only maintained at an SGP (or an IPSP that is acting like an SGP). Also, the transitions in brackets [] are not for SE-IPSP, only for DE-IPSP with optional single-ended exchange, whatever that is. > > > > Although we permitted either SE-IPSP to initiate the exchange, there is > > no requirement to support switching of roles once an AS has been > > activated. > [TOLGA]Take a look to the state machine, you re totally wrong. There are no > SGP/ASP roles assigned to IPSPs for the whole message exchange, that is the > reason why there an IPSP state machine. The state machine is only defined for an SGP to track the state of a remote AS and MAY be used by an IPSP to track the state of an AS at a remote IPSP. I repeat MAY. This is not a requirement. > > Permitting switching of roles in the fashion that you originally indicated > > is problematic as follows: > > > > SE-IPSP1 SE-IPSP2 > > | | > > |-------ASPAC------------->| > > | | > > |<-------ASPIA-------------| > > | | > > |-------ASPIA------------->| > > | | > > |<-------ASPAC-------------| > > > > .... What now? Is it active? Inactive? > > > > This is why, although either side may initiate the exchange, it > > should stick > > with one role. > [TOLGA]Two points: > a)If there are open points -and I would think there may be some- in the IPSP > state machine, they can be fixed, this does not mean changing the whole > architecture. > b)For your example: > I assume initially AS in INACTIVE. > Because ASPAC from IPSP1 is not acknowledged with ASPAC-ACK AS states > INACTIVE. > With ASPIA from IPSPS2 AS state is INACTIVE > With ASPIA from IPSP1 AS state is INACTIVE > With ASPAC from IPSP2 AS is still INACTIVE. If IPSP1 replies with ASPAC-ACK, > AS will become ACTIVE. > > For the above, we may need to clarify things in the IPSP state > machine -maybe introducing transitionary states-, but as said above this is > nowhere near to be a showstopper and does not require an architectural > change. We intentionally did not make changes over ASP/SGP communication. > > > > > > > > > > > The following two other possibilities are just as valid: > > > > > > > > SE-IPSP1 SE-IPSP2 > > > > | | > > > > |-------ASPAC------------->| > > > > | | > > > > |<-----ASPAC-ACK-----------| > > > > | | > > > > | AS is active at both | > > > > | sides | > > > > | | > > > > |<-------ASPIA-------------| > > > > | | > > > > |-ERR[Unexpected Message]->| > > > > | | > > > [TOLGA] This is supported from M3UA point of view but means that your > > > SE-IPSP1 is either not an SE-IPSP or a broken one, because it does not > > > support IPSP state machine as defined by the specifications. > > > > If the IPSP is by definition just an ASP, then the exchange is perfectly > > valid. The IPSP actually has to act like an SGP to to respond to such > > messages. > [TOLGA]If IPSP were nothing else than ASP in terms of M3UA processing, we > wouldn't mention anything about it except the definition. The similarity > between IPSP and ASP is that they both host application logic, that is it. Neither require application logic to be present. > >From M3UA state machine processing point of view, they are different > entities. For SE-IPSP the same state machine as that for the SGP is used. The ASP has no state machine. > > > > Also, to avoid the "glare" not handled by the RFC state machines, this is > > a way to tell the other side not to change roles, or that its role is > > unexpected. > [TOLGA]Now, you try to change the SE-IPSP model in the specification? ;-) To > support the model you want, you don't need to define anything new, just put > ASPF and SGPF together and there you are. If you don't want to use IPSP that > is fine. No. It has always been this way. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 14:00:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHel-0002Kl-F7; Thu, 10 Nov 2005 14:00:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHej-0002Kf-PB for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 14:00:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25969 for ; Thu, 10 Nov 2005 13:59:49 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaHv0-0003wd-3p for sigtran@ietf.org; Thu, 10 Nov 2005 14:17:06 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jAAIxvKX026796 for ; Thu, 10 Nov 2005 14:00:00 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] SE-IPSP definition Date: Thu, 10 Nov 2005 13:42:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051110113507.B31739@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Thursday, November 10, 2005 1:35 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] SE-IPSP definition > > > Tolga, > > Tolga Asveren wrote: > (Thu, 10 Nov 2005 09:43:23) > > Brian, > > > > > -----Original Message----- > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: Thursday, November 10, 2005 9:34 AM > > > To: Tolga Asveren > > > Cc: sigtran@ietf.org > > > Subject: Re: [Sigtran] SE-IPSP definition > > > > > > > > > Tolga, > > > > > > Tolga Asveren wrote: > > > (Thu, 10 Nov 2005 08:46:34) > > > > > > > > > > This message exchange is not required to be supported. > > > > [TOLGA]Sorry but you are totally wrong. This is very well > supported by > > > > SE-IPSP state machine. > > > > > > It is not required by it. > > [TOLGA]Sorry to break my promise of not replying for this > subtopic, but it > > *is* required by it. You can't strip certain pieces of a state > machine and > > claim that you support it because certain pieces are not > required. The state > > machine allows it, so it is requried if you want to claim that > your product > > is fully complaint with it. > > Huh? Compliance? Where does it say that I must follow the state machine > illustrated in the RFC? Also understand that the state machine is only > maintained at an SGP (or an IPSP that is acting like an SGP). Also, the > transitions in brackets [] are not for SE-IPSP, only for DE-IPSP with > optional single-ended exchange, whatever that is. [TOLGA]It is maintained at an IPSP as well: "4.3.1 ASP/IPSP States The state of each remote ASP/IPSP, in each AS that it is configured to operate, is maintained in the peer M3UA layer (i.e. in the SGP or peer IPSP, respectively). " Actually they also need to be maintained by ASP, but this is another topic. The transitions in brackets are not special for DE-IPSP case: "4.3.1 ASP/IPSP States [..snip..] The transitions are depicted as a result of the reception of ASP*M messages or other events. In some of the transitions there are some messages in brackets. They mean that for a given node the state transition will be different depending on its role: whether or not it is generating the ASP*M request message (i.e. ASPUP, ASPAC, ASPIA or ASPDN) or simply receiving it. In a peer-to-peer based architecture (IPSP), this role may change between the peers." > > > > > > > Although we permitted either SE-IPSP to initiate the > exchange, there is > > > no requirement to support switching of roles once an AS has been > > > activated. > > [TOLGA]Take a look to the state machine, you re totally wrong. > There are no > > SGP/ASP roles assigned to IPSPs for the whole message exchange, > that is the > > reason why there an IPSP state machine. > > The state machine is only defined for an SGP to track the state > of a remote AS > and MAY be used by an IPSP to track the state of an AS at a > remote IPSP. I > repeat MAY. This is not a requirement. [TOLGA]Sorry, but it is a requirement, otherwise there is no way to know the state of AS and to decide to allow traffic. > > > > > Permitting switching of roles in the fashion that you > originally indicated > > > is problematic as follows: > > > > > > SE-IPSP1 SE-IPSP2 > > > | | > > > |-------ASPAC------------->| > > > | | > > > |<-------ASPIA-------------| > > > | | > > > |-------ASPIA------------->| > > > | | > > > |<-------ASPAC-------------| > > > > > > .... What now? Is it active? Inactive? > > > > > > This is why, although either side may initiate the exchange, it > > > should stick > > > with one role. > > [TOLGA]Two points: > > a)If there are open points -and I would think there may be > some- in the IPSP > > state machine, they can be fixed, this does not mean changing the whole > > architecture. > > b)For your example: > > I assume initially AS in INACTIVE. > > Because ASPAC from IPSP1 is not acknowledged with ASPAC-ACK AS states > > INACTIVE. > > With ASPIA from IPSPS2 AS state is INACTIVE > > With ASPIA from IPSP1 AS state is INACTIVE > > With ASPAC from IPSP2 AS is still INACTIVE. If IPSP1 replies > with ASPAC-ACK, > > AS will become ACTIVE. > > > > For the above, we may need to clarify things in the IPSP state > > machine -maybe introducing transitionary states-, but as said > above this is > > nowhere near to be a showstopper and does not require an architectural > > change. > > We intentionally did not make changes over ASP/SGP communication. [TOLGA]I know we tried not to change things significantly, but if there are changes necessary they need to be done. It is obvious that we don't want to use SGP/ASP state machines -existing IPSP state machine is not equivalent to either one-, otherwise we wouldn't define anything called IPSP. > > > > > > > > > > > > > > > > The following two other possibilities are just as valid: > > > > > > > > > > SE-IPSP1 SE-IPSP2 > > > > > | | > > > > > |-------ASPAC------------->| > > > > > | | > > > > > |<-----ASPAC-ACK-----------| > > > > > | | > > > > > | AS is active at both | > > > > > | sides | > > > > > | | > > > > > |<-------ASPIA-------------| > > > > > | | > > > > > |-ERR[Unexpected Message]->| > > > > > | | > > > > [TOLGA] This is supported from M3UA point of view but means > that your > > > > SE-IPSP1 is either not an SE-IPSP or a broken one, because > it does not > > > > support IPSP state machine as defined by the specifications. > > > > > > If the IPSP is by definition just an ASP, then the exchange > is perfectly > > > valid. The IPSP actually has to act like an SGP to to respond to such > > > messages. > > [TOLGA]If IPSP were nothing else than ASP in terms of M3UA > processing, we > > wouldn't mention anything about it except the definition. The similarity > > between IPSP and ASP is that they both host application logic, > that is it. > > Neither require application logic to be present. [TOLGA]Form 1.2 Terminology: Application Server Process (ASP) - A process instance of an Application Server. An Application Server Process serves as an active or backup process of an Application Server (e.g., part of a distributed virtual switch or database). Examples of ASPs are processes (or process instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP endpoint and may be configured to process signalling traffic within more than one Application Server. IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not use the services of a Signalling Gateway node. BTW, please also note how the difference between ASP and IPSP explained, so they are not the same because the behavior for M3UA stack is diffeerent for each of them. > > > >From M3UA state machine processing point of view, they are different > > entities. > > For SE-IPSP the same state machine as that for the SGP is used. The ASP > has no state machine. > > > > > > > Also, to avoid the "glare" not handled by the RFC state > machines, this is > > > a way to tell the other side not to change roles, or that its role is > > > unexpected. > > [TOLGA]Now, you try to change the SE-IPSP model in the > specification? ;-) To > > support the model you want, you don't need to define anything > new, just put > > ASPF and SGPF together and there you are. If you don't want to > use IPSP that > > is fine. > > No. It has always been this way. [TOLGA]Architecturally I am fine with the existing model, just needs some cleanup/rewording/state machine polishing + extra text for not explained topics. > > --brian > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 14:17:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHvc-0002AN-M5; Thu, 10 Nov 2005 14:17:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHva-0002AH-QM for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 14:17:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27935 for ; Thu, 10 Nov 2005 14:17:15 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaIBp-0004ku-Oc for Sigtran@ietf.org; Thu, 10 Nov 2005 14:34:32 -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 jAAJH5mP033636 for ; Thu, 10 Nov 2005 11:17:05 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <007201c5e62b$616ddfa0$730f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Thu, 10 Nov 2005 22:17:17 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.86.1/1166/Mon Nov 7 11:01:45 2005 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Sigtran] M2UA 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="===============1798849962==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1798849962== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01C5E644.82CCED80" This is a multi-part message in MIME format. ------=_NextPart_000_006F_01C5E644.82CCED80 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, is M2UA alive? It seems that it is mentioned very rarely here. Are signalling gateway implementations with M2UA not popular in compare = to M2PA? Sergey Mikhailov. ------=_NextPart_000_006F_01C5E644.82CCED80 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi,
 
is M2UA alive? It seems that it is = mentioned very=20 rarely here.
Are signalling gateway implementations = with M2UA=20 not popular in compare to M2PA?
 
Sergey = Mikhailov.
------=_NextPart_000_006F_01C5E644.82CCED80-- --===============1798849962== 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 --===============1798849962==-- From sigtran-bounces@ietf.org Thu Nov 10 14:40:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIHT-0001fB-SU; Thu, 10 Nov 2005 14:40:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIBH-0008N2-7R for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 14:33:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28565 for ; Thu, 10 Nov 2005 14:33:24 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[KY29SrnskcinvspqMAI37jBKlT/IrhzF]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaIBL-0004kM-6P for sigtran@ietf.org; Thu, 10 Nov 2005 14:35:28 -0500 Received: from ns.pigworks.openss7.net (IDENT:OLYqnE/HrR1fSn9XfeePlnNBflU3/hb2@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAAJH8c21927; Thu, 10 Nov 2005 12:17:08 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAAJH5w00461; Thu, 10 Nov 2005 12:17:05 -0700 Date: Thu, 10 Nov 2005 12:17:05 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051110121705.C32001@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051110113507.B31739@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 Thu, Nov 10, 2005 at 01:42:36PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Thu, 10 Nov 2005 13:42:36) > > > > Huh? Compliance? Where does it say that I must follow the state machine > > illustrated in the RFC? Also understand that the state machine is only > > maintained at an SGP (or an IPSP that is acting like an SGP). Also, the > > transitions in brackets [] are not for SE-IPSP, only for DE-IPSP with > > optional single-ended exchange, whatever that is. > [TOLGA]It is maintained at an IPSP as well: > "4.3.1 ASP/IPSP States > > The state of each remote ASP/IPSP, in each AS that it is configured to > operate, is maintained in the peer M3UA layer (i.e. in the SGP or peer > IPSP, respectively). " > Actually they also need to be maintained by ASP, but this is another topic. > > The transitions in brackets are not special for DE-IPSP case: > > "4.3.1 ASP/IPSP States > > [..snip..] > The transitions are depicted as a result of the reception of ASP*M > messages or other events. In some of the transitions there are some > messages in brackets. They mean that for a given node the state > transition will be different depending on its role: whether or not it > is generating the ASP*M request message (i.e. ASPUP, ASPAC, ASPIA or > ASPDN) or simply receiving it. In a peer-to-peer based architecture > (IPSP), this role may change between the peers." That is not RFC 3332 which is what we were discussing. > > > > > > > > Although we permitted either SE-IPSP to initiate the > > exchange, there is > > > > no requirement to support switching of roles once an AS has been > > > > activated. > > > [TOLGA]Take a look to the state machine, you re totally wrong. > > There are no > > > SGP/ASP roles assigned to IPSPs for the whole message exchange, > > that is the > > > reason why there an IPSP state machine. > > > > The state machine is only defined for an SGP to track the state > > of a remote AS > > and MAY be used by an IPSP to track the state of an AS at a > > remote IPSP. I > > repeat MAY. This is not a requirement. > [TOLGA]Sorry, but it is a requirement, otherwise there is no way to know the > state of AS and to decide to allow traffic. > > > > > > > > Permitting switching of roles in the fashion that you > > originally indicated > > > > is problematic as follows: > > > > > > > > SE-IPSP1 SE-IPSP2 > > > > | | > > > > |-------ASPAC------------->| > > > > | | > > > > |<-------ASPIA-------------| > > > > | | > > > > |-------ASPIA------------->| > > > > | | > > > > |<-------ASPAC-------------| > > > > > > > > .... What now? Is it active? Inactive? > > > > > > > > This is why, although either side may initiate the exchange, it > > > > should stick > > > > with one role. > > > [TOLGA]Two points: > > > a)If there are open points -and I would think there may be > > some- in the IPSP > > > state machine, they can be fixed, this does not mean changing the whole > > > architecture. > > > b)For your example: > > > I assume initially AS in INACTIVE. > > > Because ASPAC from IPSP1 is not acknowledged with ASPAC-ACK AS states > > > INACTIVE. > > > With ASPIA from IPSPS2 AS state is INACTIVE > > > With ASPIA from IPSP1 AS state is INACTIVE > > > With ASPAC from IPSP2 AS is still INACTIVE. If IPSP1 replies > > with ASPAC-ACK, > > > AS will become ACTIVE. > > > > > > For the above, we may need to clarify things in the IPSP state > > > machine -maybe introducing transitionary states-, but as said > > above this is > > > nowhere near to be a showstopper and does not require an architectural > > > change. > > > > We intentionally did not make changes over ASP/SGP communication. > [TOLGA]I know we tried not to change things significantly, but if there are > changes necessary they need to be done. It is obvious that we don't want to > use SGP/ASP state machines -existing IPSP state machine is not equivalent to > either one-, otherwise we wouldn't define anything called IPSP. We did not define an ASP state machine. > > > > > > > > > > > > > > > > > > > > > The following two other possibilities are just as valid: > > > > > > > > > > > > SE-IPSP1 SE-IPSP2 > > > > > > | | > > > > > > |-------ASPAC------------->| > > > > > > | | > > > > > > |<-----ASPAC-ACK-----------| > > > > > > | | > > > > > > | AS is active at both | > > > > > > | sides | > > > > > > | | > > > > > > |<-------ASPIA-------------| > > > > > > | | > > > > > > |-ERR[Unexpected Message]->| > > > > > > | | > > > > > [TOLGA] This is supported from M3UA point of view but means > > that your > > > > > SE-IPSP1 is either not an SE-IPSP or a broken one, because > > it does not > > > > > support IPSP state machine as defined by the specifications. > > > > > > > > If the IPSP is by definition just an ASP, then the exchange > > is perfectly > > > > valid. The IPSP actually has to act like an SGP to to respond to such > > > > messages. > > > [TOLGA]If IPSP were nothing else than ASP in terms of M3UA > > processing, we > > > wouldn't mention anything about it except the definition. The similarity > > > between IPSP and ASP is that they both host application logic, > > that is it. > > > > Neither require application logic to be present. > [TOLGA]Form 1.2 Terminology: > Application Server Process (ASP) - A process instance of an > Application Server. An Application Server Process serves as an active > or backup process of an Application Server (e.g., part of a > distributed virtual switch or database). Examples of ASPs are > processes (or process instances) of MGCs, IP SCPs or IP HLRs. An ASP > contains an SCTP endpoint and may be configured to process signalling > traffic within more than one Application Server. > > > IP Server Process (IPSP) - A process instance of an IP-based > application. An IPSP is essentially the same as an ASP, except that > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > not use the services of a Signalling Gateway node. > > > BTW, please also note how the difference between ASP and IPSP explained, so > they are not the same because the behavior for M3UA stack is diffeerent for > each of them. That IPSP definition is old and predates SE-IPSP. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 14:46:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaINJ-0002u9-MC; Thu, 10 Nov 2005 14:46:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaINI-0002u1-1c for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 14:46:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29614 for ; Thu, 10 Nov 2005 14:45:52 -0500 (EST) Received: from phl-28-b-170.phl.dsl.cerfnet.com ([63.242.157.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaIdX-0006Ak-Oa for Sigtran@ietf.org; Thu, 10 Nov 2005 15:03:09 -0500 Received: from bn001320 (bn001320 [192.168.1.61]) by phl-28-b-170.phl.dsl.cerfnet.com (8.12.8/8.12.8) with SMTP id jAAJk6oj007312 for ; Thu, 10 Nov 2005 14:46:06 -0500 From: "Barry Nagelberg" To: "SIGTRAN" Subject: RE: [Sigtran] M2UA Date: Thu, 10 Nov 2005 14:47:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <007201c5e62b$616ddfa0$730f0f0a@smikhailov> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, Yes, it's alive. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Sergey Mikhailov Sent: Thursday, November 10, 2005 2:17 PM To: SIGTRAN Subject: [Sigtran] M2UA Hi, is M2UA alive? It seems that it is mentioned very rarely here. Are signalling gateway implementations with M2UA not popular in compare to M2PA? Sergey Mikhailov. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 10 15:03:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIdZ-0000Dd-VP; Thu, 10 Nov 2005 15:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIdX-0000CD-W9 for sigtran@megatron.ietf.org; Thu, 10 Nov 2005 15:03:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00916 for ; Thu, 10 Nov 2005 15:02:39 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaIto-0006k0-9d for Sigtran@ietf.org; Thu, 10 Nov 2005 15:19:57 -0500 Received: from [172.25.33.103] (pc-song-p.ulticom.com [172.25.33.103]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id jAAK2l1Z002928; Thu, 10 Nov 2005 15:02:47 -0500 (EST) Message-ID: <4373A7E2.2010506@ulticom.com> Date: Thu, 10 Nov 2005 15:04:50 -0500 From: song User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barry Nagelberg Subject: Re: [Sigtran] M2UA References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Yes, indeed. Mike Song Ulticom, Inc. Barry Nagelberg wrote: >Sergey, > >Yes, it's alive. > >Barry Nagelberg >Adax, Inc. > >-----Original Message----- >From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Sergey Mikhailov >Sent: Thursday, November 10, 2005 2:17 PM >To: SIGTRAN >Subject: [Sigtran] M2UA > > >Hi, > >is M2UA alive? It seems that it is mentioned very rarely here. >Are signalling gateway implementations with M2UA not popular in compare to M2PA? > >Sergey Mikhailov. > >_______________________________________________ >Sigtran mailing list >Sigtran@ietf.org >https://www1.ietf.org/mailman/listinfo/sigtran > > > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Nov 11 00:20:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaRKY-00059T-1v; Fri, 11 Nov 2005 00:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaRKV-00058p-HG for sigtran@megatron.ietf.org; Fri, 11 Nov 2005 00:20:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14093 for ; Fri, 11 Nov 2005 00:19:33 -0500 (EST) From: partha.dey@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaRak-0000Z0-Ip for sigtran@ietf.org; Fri, 11 Nov 2005 00:36:56 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id C502C205DF for ; Fri, 11 Nov 2005 10:36:16 +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 81656205DC for ; Fri, 11 Nov 2005 10:36:16 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 10:49:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Nov 2005 10:49:01 +0530 Message-ID: <5A521CAA914BAF47A48A726DE83E7D2401775472@blr-k1-msg.wipro.com> Thread-Topic: Query on Broadcast mode Traffic Handling Mode. Thread-Index: AcXTIfbJs0NXg9fSRcmBUOpGDifMpwAAES8QBNbADfA= To: X-OriginalArrivalTime: 11 Nov 2005 05:19:02.0925 (UTC) FILETIME=[6DEA8BD0:01C5E67F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Subject: [Sigtran] Query on Broadcast mode Traffic Handling Mode. X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi Brian, In Broadcast traffic handling mode (Section 4.1.1), should all messages be broadcast to all active ASPs in an AS? Lets take an exmple where we have Three active ASPs in an AS.=20 We get a connection request message from SCCP user ,we broadcast Connection Request message to all the Active ASPs. One of the ASPs responds to that message , then should the subsequent messages also will be broadcast or they will be sent specifically to that particular ASP? Regards, Partha. =20 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Nov 11 10:52:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EabCb-0005Hd-J1; Fri, 11 Nov 2005 10:52:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EabCZ-0005HY-O7 for sigtran@megatron.ietf.org; Fri, 11 Nov 2005 10:52:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14612 for ; Fri, 11 Nov 2005 10:52:02 -0500 (EST) Received: from web25915.mail.ukl.yahoo.com ([217.146.176.253]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EabSl-00014S-1I for sigtran@ietf.org; Fri, 11 Nov 2005 11:09:31 -0500 Received: (qmail 95030 invoked by uid 60001); 11 Nov 2005 15:52:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.es; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Pn9oIks+EzwFCelQaa4DlPTvAvj+0Sy5JMr1vTAVKJLZUuEzKW/Wb2v/hHbEEmTdXvhMgQBXfGcXO70FlEsSBauYwJAjYEasoHaG7RIcLO+tFK+Ygx194cF51Zyo6182hNiFUQYAuojmW0AHGBHjmMqfc38cc44qm+RPrbj1PBE= ; Message-ID: <20051111155201.95028.qmail@web25915.mail.ukl.yahoo.com> Received: from [195.235.92.108] by web25915.mail.ukl.yahoo.com via HTTP; Fri, 11 Nov 2005 16:52:01 CET Date: Fri, 11 Nov 2005 16:52:01 +0100 (CET) From: David Santos To: sigtran@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA14612 Subject: [Sigtran] M3UA - NIF doubts X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi, I have some doubts about how to implement the NIF: a) Can the NIF be implemented as a level 4 user part? b) Should the MTP stack be modified to make the routing function send messages to the NIF? c) Can all incoming traffic be sent to the NIF, or could a SG act as a STP, just routing messages within the SS7 network? d) When a M3UA node is inaccessible, should the SG send signalling network management messages to the SS7 network (e.g. TFA or TFP) via NIF? Thanks! =09 ______________________________________________=20 Renovamos el Correo Yahoo!=20 Nuevos servicios, m=E1s seguridad=20 http://correo.yahoo.es _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Nov 11 17:41:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eahaa-0007SN-94; Fri, 11 Nov 2005 17:41:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EahaY-0007SI-NJ for sigtran@megatron.ietf.org; Fri, 11 Nov 2005 17:41:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23281 for ; Fri, 11 Nov 2005 17:41:13 -0500 (EST) Received: from lin1-118-38-140.ciena.com ([63.118.38.140] helo=mdmxm02.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eahr3-0006DP-78 for sigtran@ietf.org; Fri, 11 Nov 2005 17:58:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Nov 2005 17:41:27 -0500 Message-ID: <0901D1988E815341A0103206A834DA07902DE0@mdmxm02.ciena.com> Thread-Topic: m3ua status thread-index: AcXnEQ1EJMWL4SQKRB+r9ta4qopEyQ== From: "Ong, Lyndon" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [Sigtran] m3ua status 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="===============1700990887==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1700990887== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E711.0D7EA9B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E711.0D7EA9B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 I have been watching the mounting pile of emails on IPSP procedures with some concern. I think at this point it is quite difficult to make any technical changes to the M3UA bis spec, as this is well past the review period. =20 At the same time, it seems clear that there are major differences in peoples' interpretations of some sections in the text. Continued discussion on the email list does not seem to be leading to a consensus, either. Do we need an actual meeting, or some more organized effort to=20 reach a conclusion? I'm open to suggestions here (can be sent off line if you wish). =20 Thanks, =20 L. Ong ------_=_NextPart_001_01C5E711.0D7EA9B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Folks,
 
I have = been watching=20 the mounting pile of emails on IPSP procedures with some=20 concern.
I = think at this=20 point it is quite difficult to make any technical changes to the M3UA=20 bis
spec, = as this is=20 well past the review period.
 
At the = same time, it=20 seems clear that there are major differences in peoples'=20 interpretations
of = some sections in=20 the text.  Continued discussion on the email list does not seem to = be=20 leading to a
consensus,=20 either.  Do we need an actual meeting, or some more organized = effort to=20
reach = a=20 conclusion?  I'm open to suggestions here (can be sent off line if = you=20 wish).
 
Thanks,
 
L.=20 Ong
------_=_NextPart_001_01C5E711.0D7EA9B8-- --===============1700990887== 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 --===============1700990887==-- From sigtran-bounces@ietf.org Sat Nov 12 03:56:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EarBt-0004rx-GO; Sat, 12 Nov 2005 03:56:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EarBr-0004rl-VJ for sigtran@megatron.ietf.org; Sat, 12 Nov 2005 03:56:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20672 for ; Sat, 12 Nov 2005 03:56:23 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EarSR-0003Ou-Qe for sigtran@ietf.org; Sat, 12 Nov 2005 04:14:01 -0500 Received: from gw.openss7.com ([142.179.199.224] ident=[hE55PiEk7ise8wOVLBWcq1GpB/DJopu3]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ear1l-0004LC-RR for sigtran@ietf.org; Sat, 12 Nov 2005 03:50:10 -0500 Received: from ns.pigworks.openss7.net (IDENT:bl5T3lL5f9v9/YCYsvCoI9Vxymgpq+xX@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAC8VMc27972; Sat, 12 Nov 2005 01:31:22 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAC8VJp23454; Sat, 12 Nov 2005 01:31:19 -0700 Date: Sat, 12 Nov 2005 01:31:19 -0700 From: "Brian F. G. Bidulock" To: partha.dey@wipro.com Subject: Re: [Sigtran] Query on Broadcast mode Traffic Handling Mode. Message-ID: <20051112013119.B6840@openss7.org> Mail-Followup-To: partha.dey@wipro.com, sigtran@ietf.org References: <5A521CAA914BAF47A48A726DE83E7D2401775472@blr-k1-msg.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5A521CAA914BAF47A48A726DE83E7D2401775472@blr-k1-msg.wipro.com>; from partha.dey@wipro.com on Fri, Nov 11, 2005 at 10:49:01AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org partha.dey, partha.dey@wipro.com wrote: (Fri, 11 Nov 2005 10:49:01) > Hi Brian, > In Broadcast traffic handling mode (Section 4.1.1), should all > messages be broadcast to all active ASPs in an AS? Yes. > > Lets take an exmple where we have Three active ASPs in an AS. > We get a connection request message from SCCP user ,we broadcast > Connection Request message to all the Active ASPs. Yes. > One of the ASPs responds to that message , then should the subsequent > messages also will be broadcast or they will be sent specifically to > that particular ASP? Subsequent messages are broadcast as well. --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 Nov 12 04:15:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EarRc-0001Ug-Ep; Sat, 12 Nov 2005 04:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EarRZ-0001PA-SJ for sigtran@megatron.ietf.org; Sat, 12 Nov 2005 04:13:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21667 for ; Sat, 12 Nov 2005 04:12:36 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[txI4dSjJd/dw+myvrU8xTVuPWNYV/zxV]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eardi-0003zH-SR for sigtran@ietf.org; Sat, 12 Nov 2005 04:30:15 -0500 Received: from ns.pigworks.openss7.net (IDENT:Wq66Hyr8zCwpMcPaTY1FLQTwObxRqzM8@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAC98Fc28704; Sat, 12 Nov 2005 02:08:15 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAC98EO23899; Sat, 12 Nov 2005 02:08:14 -0700 Date: Sat, 12 Nov 2005 02:08:14 -0700 From: "Brian F. G. Bidulock" To: David Santos Subject: Re: [Sigtran] M3UA - NIF doubts Message-ID: <20051112020814.C6840@openss7.org> Mail-Followup-To: David Santos , sigtran@ietf.org References: <20051111155201.95028.qmail@web25915.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20051111155201.95028.qmail@web25915.mail.ukl.yahoo.com>; from sigtran7@yahoo.es on Fri, Nov 11, 2005 at 04:52:01PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org David, David Santos wrote: (Fri, 11 Nov 2005 16:52:01) > Hi, > > I have some doubts about how to implement the NIF: > > a) Can the NIF be implemented as a level 4 user part? Although it is implementation specific, it was our intention that it should be possible that the NIF could be implemented as one (or more) rather normal MTP-User(s). > b) Should the MTP stack be modified to make the > routing function send messages to the NIF? If the NIF is implemented as normal MTP-User(s), it should not be necessary to modify the MTP stack. > c) Can all incoming traffic be sent to the NIF, or > could a SG act as a STP, just routing messages within > the SS7 network? Yes an SG can optionally act as an SEP or an STP. The multiple SG as STP scenario is supported by M3UA and looks like the following: | SS7 IP Network | Network _______________ _______ ____ | | _______| ______| | / \ | | |_______| ____| ASP | | | B/D-Links | | | SGP |________ | |_______| | | ___________| STP SG|_______| | | _______ | | /| | | |__ + | | __| | | AS | / | | SGP |__ + | | __| ASP | | | \ / | | |_______| + | | |_______| | | \ / |_______________| | | _______ | | \ / C- | + | | __| | \____/ X Links| | + | | __| ASP | ____ / \ _|_____________ + | | |_______| / \ / \ | | _______| | | _______ | | / \ | | |__ + | | __| | | | \ | | | SGP |__ + | | __| ASP | | | __________\| STP SG|_______| + | | |_______| | AS | | | | |________|_| _______ | | | | SGP |_______ |_____| | | | | | |_______| |______| ASP | | | |_______________| SCTP |_______| \___ / | Associations | Figure 1. Example (A) Sample Multiple-SG Configuration In the multiple SG as STP scenrio it is more difficult to implement the NIF as a normal MTP-User at the SG, particularly considering the use of DRST in the SG->ASP direction. (There is no MTP/MTP-User primitive for DRST.) Also, it might not be possible to define a local MTP-User at an STP that can also be reached over an alternate SS7 route (i.e. C-links). The closest analogy would be an SCCP Alias that exists both locally within the STP as well as existing remotely at the associated STP in the STP pair. As many STPs implement this SCCP Alias concept to support ANSI, providing a similar point code for an ASP might not be possible with a simple local MTP-User, or it might be. With no doubt, the NIF is easier to implement for an SG as SEP than for an SG as STP. > d) When a M3UA node is inaccessible, should the SG > send signalling network management messages to the SS7 > network (e.g. TFA or TFP) via NIF? If you think of the AS as an MTP-User, following the NIF as MTP-User (or even "Alias" MTP-User) approach, when the AS is unavailable, the NIF could signal uavailability of the MTP-User to the MTP in the same fashion as it normally does for MTP-Users. If the MTP stack does not support the same scope of MTP-SAP as is supported to an AS (e.g, it only supports entire PC MTP-SAPs, or say, only supports PC-SI MTP-SAPs) then the NIF has some more work to do correlating the availability of individual AS into a single MTP-SAP, or correlating the availability of a single AS into multiple MTP-SAPs, to present a proper SS7 network view. If the MTP stack supports MTP-SAPs on the same basis or scope as M3UA Routing Keys, then it is a simpler matter of locally attaching or detaching the corresponding MTP-User from its MTP-SAP. Using these approaches it is, IMHO, easier to meet the conformance requirements on the MTP stack because the MTP stack's conformance to the SS7 network remains unmodified. That is, the response of the MTP stack to AS availability is the same as it would be if the MTP-User at the local MTP-SAP detaches or attaches and the MTP stack can be relied upon to do the right thing with regard to the SS7 network. How an MTP-User attaches or detaches is of course a local implementation matter for the SS7 stack, however most stacks provide some local mechanism for doing so. Some stacks might even provide the ability to attach or detach to an "SCCP Alias" type point code or PC-SI combination, that would ease integration of NIF to SG as STP. I hope that helps. I can walk through some more specific examples if you would like. --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 Nov 12 06:29:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EatZM-0004Kn-Gv; Sat, 12 Nov 2005 06:29:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EatZK-0004JT-QK for sigtran@megatron.ietf.org; Sat, 12 Nov 2005 06:29:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26600 for ; Sat, 12 Nov 2005 06:28:45 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[ejcdI20qLhOUs1PxJKzMyM4SDHGv/yCm]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eatpf-0000KG-UZ for sigtran@ietf.org; Sat, 12 Nov 2005 06:46:25 -0500 Received: from ns.pigworks.openss7.net (IDENT:go22sEsnBz8vxTHAzLtc9J1uW0XSqEWW@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jACBStc31377; Sat, 12 Nov 2005 04:28:55 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jACBSr525563; Sat, 12 Nov 2005 04:28:53 -0700 Date: Sat, 12 Nov 2005 04:28:53 -0700 From: "Brian F. G. Bidulock" To: "Ong, Lyndon" Subject: Re: [Sigtran] m3ua status Message-ID: <20051112042853.F6840@openss7.org> Mail-Followup-To: "Ong, Lyndon" , sigtran@ietf.org References: <0901D1988E815341A0103206A834DA07902DE0@mdmxm02.ciena.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0901D1988E815341A0103206A834DA07902DE0@mdmxm02.ciena.com>; from Lyong@Ciena.com on Fri, Nov 11, 2005 at 05:41:27PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Lyndon, We recognized the need for an IPSP Extensions Draft 4 years ago. On a number of occasions of the last 4 years it was requested that an IPSP Extensions Draft be made a SIGTRAN work item. Tolga even endeavoured to create the SG-SG draft with the participation of over 9 individuals from as many organizations. IMO without a formal WG work item, confusion and interoperability nightmares surrounding IPSP will prevail. The band-aid fix afforded by IGs will offer little, or no, remedy. Will the WG, WG Chair and A-D now support addition of the IPSP Extensions work item? Alternatively, it is not too late to call back rfc3332bis. rfc3332bis has not even been reviewed by the IESG yet. IMO if issues at WGLC had been properly addressed (lack of addressing extension drafts being one of them) there would not be a problem now. It is even still possible to appeal it based on lack of technical merit: a lack which has become more and more apparent over the last number of months. I also notice that, while they would have assisted in clarification of (and corrections to) the PSs, the MIBs drafts are dead. The exercise of creating a MIB for a protocol often flushes out its problems, both in design and interpretation. Also, a protocol without a MIB is not a very useful one. I believe that these were WG items: what has been done to complete them? Would the WG like to see IPSP Extensions made a WG item? Comments? --brian Lyndon Ong wrote: (Fri, 11 Nov 2005 17:41:27) > > Hi Folks, > > > > I have been watching the mounting pile of emails on IPSP procedures > with some concern. > > I think at this point it is quite difficult to make any technical > changes to the M3UA bis > > spec, as this is well past the review period. > > > > At the same time, it seems clear that there are major differences in > peoples' interpretations > > of some sections in the text. Continued discussion on the email list > does not seem to be leading to a > > consensus, either. Do we need an actual meeting, or some more > organized effort to > > reach a conclusion? I'm open to suggestions here (can be sent off > line if you wish). > > > > Thanks, > > > > L. Ong > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Sat Nov 12 06:35:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eatf8-0005zm-CR; Sat, 12 Nov 2005 06:35:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eatf6-0005ze-UM for sigtran@megatron.ietf.org; Sat, 12 Nov 2005 06:35:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26785 for ; Sat, 12 Nov 2005 06:34:42 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eatvh-0000WO-RT for sigtran@ietf.org; Sat, 12 Nov 2005 06:52:23 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jACBWCvx030349; Sat, 12 Nov 2005 13:32:15 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Nov 2005 13:35:00 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Nov 2005 13:34:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] m3ua status Date: Sat, 12 Nov 2005 13:34:59 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D015CB780@esebe100.NOE.Nokia.com> Thread-Topic: [Sigtran] m3ua status Thread-Index: AcXnfKoXJtZ8yGnbRy6isQuNJ522UAAAF+mw To: , X-OriginalArrivalTime: 12 Nov 2005 11:34:59.0460 (UTC) FILETIME=[1D126440:01C5E77D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, It might be quicker if an individual draft was written, could be reviewed in SIGTRAN and submitted as an AD sponsored draft. =20 John=20 >-----Original Message----- >From: sigtran-bounces@ietf.org=20 >[mailto:sigtran-bounces@ietf.org] On Behalf Of ext Brian F. G. Bidulock >Sent: 12 November, 2005 13:29 >To: Ong, Lyndon >Cc: sigtran@ietf.org >Subject: Re: [Sigtran] m3ua status > >Lyndon, > >We recognized the need for an IPSP Extensions Draft 4 years=20 >ago. On a number of occasions of the last 4 years it was=20 >requested that an IPSP Extensions Draft be made a SIGTRAN work=20 >item. Tolga even endeavoured to create the SG-SG draft with=20 >the participation of over 9 individuals from as many organizations. > >IMO without a formal WG work item, confusion and=20 >interoperability nightmares surrounding IPSP will prevail. =20 >The band-aid fix afforded by IGs will offer little, or no, remedy. > >Will the WG, WG Chair and A-D now support addition of the IPSP=20 >Extensions work item? > >Alternatively, it is not too late to call back rfc3332bis. =20 >rfc3332bis has not even been reviewed by the IESG yet. IMO if=20 >issues at WGLC had been properly addressed (lack of addressing=20 >extension drafts being one of them) there would not be a=20 >problem now. It is even still possible to appeal it based on=20 >lack of technical merit: a lack which has become more and more=20 >apparent over the last number of months. > >I also notice that, while they would have assisted in=20 >clarification of (and corrections to) the PSs, the MIBs drafts=20 >are dead. The exercise of creating a MIB for a protocol often=20 >flushes out its problems, both in design and interpretation. =20 >Also, a protocol without a MIB is not a very useful one. I=20 >believe that these were WG items: what has been done to complete them? > >Would the WG like to see IPSP Extensions made a WG item? > >Comments? > >--brian > > >Lyndon Ong wrote: (Fri, 11 Nov=20 >2005 17:41:27) >>=20 >> Hi Folks, >>=20 >>=20 >>=20 >> I have been watching the mounting pile of emails on=20 >IPSP procedures >> with some concern. >>=20 >> I think at this point it is quite difficult to make=20 >any technical >> changes to the M3UA bis >>=20 >> spec, as this is well past the review period. >>=20 >>=20 >>=20 >> At the same time, it seems clear that there are major=20 >differences in >> peoples' interpretations >>=20 >> of some sections in the text. Continued discussion on=20 >the email list >> does not seem to be leading to a >>=20 >> consensus, either. Do we need an actual meeting, =20 >or some more >> organized effort to >>=20 >> reach a conclusion? I'm open to suggestions here=20 >(can be sent off >> line if you wish). >>=20 >>=20 >>=20 >> Thanks, >>=20 >>=20 >>=20 >> L. Ong > >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www1.ietf.org/mailman/listinfo/sigtran > > >-- >Brian F. G. Bidulock >bidulock@openss7.org >http://www.openss7.org/ > >_______________________________________________ >Sigtran mailing list >Sigtran@ietf.org >https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Sat Nov 12 06:47:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eatr7-0003Ie-0L; Sat, 12 Nov 2005 06:47:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eatr6-0003IW-4B for sigtran@megatron.ietf.org; Sat, 12 Nov 2005 06:47:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27316 for ; Sat, 12 Nov 2005 06:47:06 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[Q1DafukIpL9rQAxVKKrMVvjyGmCQIlD3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eau6v-0000wR-2i for sigtran@ietf.org; Sat, 12 Nov 2005 07:04:46 -0500 Received: from ns.pigworks.openss7.net (IDENT:03y1IkEf1Iff16eBFujXwjBOH2N7Shyj@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jACBkic31584; Sat, 12 Nov 2005 04:46:44 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jACBkgq25728; Sat, 12 Nov 2005 04:46:42 -0700 Date: Sat, 12 Nov 2005 04:46:41 -0700 From: "Brian F. G. Bidulock" To: john.loughney@nokia.com Subject: Re: [Sigtran] m3ua status Message-ID: <20051112044641.A25571@openss7.org> Mail-Followup-To: john.loughney@nokia.com, Lyong@Ciena.com, sigtran@ietf.org References: <1AA39B75171A7144A73216AED1D7478D015CB780@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1AA39B75171A7144A73216AED1D7478D015CB780@esebe100.NOE.Nokia.com>; from john.loughney@nokia.com on Sat, Nov 12, 2005 at 01:34:59PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Lyong@Ciena.com, sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org John, John Loughney wrote: (Sat, 12 Nov 2005 13:34:59) > Brian, > > It might be quicker if an individual draft was written, could be > reviewed in SIGTRAN and submitted as an AD sponsored draft. > > John > Yes, that's what we were told previously and so we worked for a year on leading up to draft-bidas-sigtran-sgsg-03.txt. It dates back to 2003. You can get a copies of these (now outdated) drafts here: http://www.openss7.org/docs/draft-bidas-sigtran-sgsg-00.txt http://www.openss7.org/docs/draft-bidas-sigtran-sgsg-01.txt http://www.openss7.org/docs/draft-bidas-sigtran-sgsg-02.txt http://www.openss7.org/docs/draft-bidas-sigtran-sgsg-03.txt Tolga might have something even more current. Also the archive is full of discussion on SG-SG. This time I think it would be wise to make it a working group item _before_ working for a year on it, unlike the last round. --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 Nov 12 07:43:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eaujd-000144-Gq; Sat, 12 Nov 2005 07:43:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eaujb-0000xD-UL for sigtran@megatron.ietf.org; Sat, 12 Nov 2005 07:43:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29480 for ; Sat, 12 Nov 2005 07:43:25 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eav0C-0002zE-AD for sigtran@ietf.org; Sat, 12 Nov 2005 08:01:06 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jACCdKYC003737; Sat, 12 Nov 2005 14:39:20 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Nov 2005 14:43:22 +0200 Received: from saemailgw02.europe.nokia.com ([10.40.2.12]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 12 Nov 2005 14:43:23 +0200 Received: from ptspilot22v.pts.nokia.com (saenonep22.europe.nokia.com [10.40.32.79]) by saemailgw02.europe.nokia.com (8.11.7p1+Sun/8.11.7) with ESMTP id jACChJh17684; Sat, 12 Nov 2005 14:43:19 +0200 (EET) Message-ID: <33282188.1131799056733.JavaMail.pts@ptspilot22v.pts.nokia.com> Date: Sat, 12 Nov 2005 14:37:31 +0200 (EET) From: "Loughney John (Nokia-NRC/Helsinki)" To: bidulock@openss7.org Subject: RE: [Sigtran] m3ua status Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-OriginalArrivalTime: 12 Nov 2005 12:43:23.0295 (UTC) FILETIME=[AB25EAF0:01C5E786] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: Lyong@Ciena.com, sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, If the draft is ready, let's ask the AD if it can be submitted as an AD=C2= =A0sponsored RFC. John -- This email was sent from my Nokia E70 -- > -----Original Message----- > From: ext Brian F. G. Bidulock > Received: Sat Nov 12 13:48:42 EET 2005 > To: john.loughney@nokia.com > Cc: Lyong@Ciena.com, sigtran@ietf.org > Subject: Re: [Sigtran] m3ua status >=20 > John, >=20 > John Loughney wrote: (Sat, 12 Nov 2005 13:34:59= ) > > Brian, > >=20 > > It might be quicker if an individual draft was written, could be > > reviewed in SIGTRAN and submitted as an AD sponsored draft. =20 > >=20 > > John=20 > >=20 >=20 > Yes, that's what we were told previously and so we worked for a year > on leading up to draft-bidas-sigtran-sgsg-03.txt. It dates back to > 2003. You can get a copies of these (now outdated) drafts here: >=20 > http://www.openss7.org/docs/draft-bidas-sigtran-sgsg-00.txt > http://www.openss7.org/docs/draft-bidas-sigtran-sgsg-01.txt > http://www.openss7.org/docs/draft-bidas-sigtran-sgsg-02.txt > http://www.openss7.org/docs/draft-bidas-sigtran-sgsg-03.txt >=20 > Tolga might have something even more current. >=20 > Also the archive is full of discussion on SG-SG. >=20 > This time I think it would be wise to make it a working group > item _before_ working for a year on it, unlike the last round. >=20 > --brian >=20 > --=20 > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ >=20 >=20 >=20 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 14 07:06:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebd6h-0001rF-Fz; Mon, 14 Nov 2005 07:06:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebd6f-0001r2-Td for sigtran@megatron.ietf.org; Mon, 14 Nov 2005 07:06:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15783 for ; Mon, 14 Nov 2005 07:06:10 -0500 (EST) From: partha.dey@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbdNa-0001Rw-BP for sigtran@ietf.org; Mon, 14 Nov 2005 07:24:17 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 567F2205DC for ; Mon, 14 Nov 2005 17:23:21 +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 3364B205DB for ; Mon, 14 Nov 2005 17:23:21 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 17:36:12 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Nov 2005 17:36:10 +0530 Message-ID: <5A521CAA914BAF47A48A726DE83E7D24017755F9@blr-k1-msg.wipro.com> Thread-Topic: Clarification on CLDT CORE broadcast. Thread-Index: AcXpATeAfK+GsYX8ScajsYqlBXo98wAEjCZQ To: X-OriginalArrivalTime: 14 Nov 2005 12:06:12.0371 (UTC) FILETIME=[CE3D6E30:01C5E913] X-Spam-Score: 0.5 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Subject: [Sigtran] Clarification on CLDT CORE broadcast. 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="===============0955154618==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0955154618== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E913.CD3661A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E913.CD3661A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian,=20 There seems to be a discrepancy in the RFC relating to Broadcasting a message for a CLDT req and CORE request, =20 Section 4.3.4.3. page 70 says=20 Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP MUST tag the first DATA message broadcast in each traffic flow with a unique Correlation Id parameter. The purpose of this Correlation Id is to permit the newly active ASP to synchronize its processing of traffic in each traffic flow with the other ASPs in the broadcast group. =20 Section 3.9.19 Page 71 The Correlation ID is a 32-bit identifier that is attached to CLDT messages to indicate to a newly entering ASP in a Broadcast AS where in the traffic flow of CLDT messages the ASP is joining. It is attached to the first CLDT message sent to an ASP by an SG after sending an ASP Active Ack or otherwise starting traffic to an ASP. The Correlation ID is only significant within a Routing Context. =20 The query is whether the Broadcasting takes place for both CORE and CLDT or only CLDT? =20 =20 Regards, Partha.=20 ------_=_NextPart_001_01C5E913.CD3661A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Brian, 

There seems to be a = discrepancy in=20 the RFC relating to Broadcasting a message for a CLDT req and CORE=20 request,

 

Section 4.3.4.3. page = 70  says=20 

   Whenever an ASP in =
a Broadcast mode AS becomes ASP-ACTIVE, the =
SGP
   MUST tag the first =
DATA message broadcast in each traffic flow with =
a
   unique Correlation =
Id parameter.  The purpose of this Correlation =
Id
   is to permit the =
newly active ASP to synchronize its processing =
of
   traffic in each =
traffic flow with the other ASPs in the =
broadcast
   =
group.
 
Section 3.9.19 Page =
71
   The Correlation ID =
is a 32-bit identifier that is attached to =
CLDT
   messages to =
indicate to a newly entering ASP in a Broadcast AS =
where
   in the traffic =
flow of CLDT messages the ASP is joining.  It =
is
   attached to the =
first CLDT message sent to an ASP by an SG =
after
   sending an ASP =
Active Ack or otherwise starting traffic to an =
ASP.
   The Correlation ID =
is only significant within a Routing =
Context.
 
The query is whether the =
Broadcasting takes place for both CORE and CLDT or only =
CLDT?

 

 

Regards,

Partha. 

= ------_=_NextPart_001_01C5E913.CD3661A2-- --===============0955154618== 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 --===============0955154618==-- From sigtran-bounces@ietf.org Mon Nov 14 09:25:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbfHD-0004Ad-Mx; Mon, 14 Nov 2005 09:25:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbfHA-00049s-Ch for sigtran@megatron.ietf.org; Mon, 14 Nov 2005 09:25:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24017 for ; Mon, 14 Nov 2005 09:25:08 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbfYB-0005xa-RA for sigtran@ietf.org; Mon, 14 Nov 2005 09:43:17 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jAEEPB8w011863 for ; Mon, 14 Nov 2005 09:25:13 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] m3ua status Date: Mon, 14 Nov 2005 09:07:24 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <0901D1988E815341A0103206A834DA07902DE0@mdmxm02.ciena.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.6 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 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="===============0704971628==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0704971628== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0840_01C5E8FA.D3D66B80" This is a multi-part message in MIME format. ------=_NextPart_000_0840_01C5E8FA.D3D66B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My 2 cents about this and related issues: What I think from technical point of view: 1) IMO, SE-IPSP model is a true peer-to-peer model. I don't see any architectural deficiencies but OTOH I think existing documentation is unsatisfactory. 2) I don't think DE-IPSP model is a good approach. 3) I think SG-SG model is useful, because it provides relaying capability. It can be used for IPSP-like communication between IP-resident peers as well. Now, what can be done: a) A draft clarifying IPSP usage as defined by the current document. This should be a self-sufficient document, should not change something architecturally but should include all details which are discussed in this list throughout the years -the current document unfortunately doesn't-. b) Revisiting SG-SG draft. I will submit a new version soon -in 5-10 days- still as a non-WG draft. There has been some off-list comments about it during the last 2 years or so, but architecturally it won't be any different than the version Brian posted the links to. Where I really am not sure what to do is, do we want to provide multiple choices for IPSP-model? Can we have significant changes and if yes to which extent? We already have SE-IPSP and DE-IPSP, and as indicated above, SG-SG could serve the same purpose as well. More choices may be confusing for people. My personal preference would be -considering both technical and non-technical aspects of the problem-: i- Keep SE-IPSP but not DE-IPSP. ii- Define SG-SG, by emphasizing its use for relaying rather than IPSP-kind of operation. Thanks, Tolga -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Ong, Lyndon Sent: Friday, November 11, 2005 5:41 PM To: sigtran@ietf.org Subject: [Sigtran] m3ua status Hi Folks, I have been watching the mounting pile of emails on IPSP procedures with some concern. I think at this point it is quite difficult to make any technical changes to the M3UA bis spec, as this is well past the review period. At the same time, it seems clear that there are major differences in peoples' interpretations of some sections in the text. Continued discussion on the email list does not seem to be leading to a consensus, either. Do we need an actual meeting, or some more organized effort to reach a conclusion? I'm open to suggestions here (can be sent off line if you wish). Thanks, L. Ong ------=_NextPart_000_0840_01C5E8FA.D3D66B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
My 2 cents about = this and=20 related issues:
 
What I think from = technical=20 point of view:
1) IMO, SE-IPSP = model is a true=20 peer-to-peer model. I don't see any architectural deficiencies but OTOH = I think=20 existing documentation is unsatisfactory.
 
2) I don't think = DE-IPSP model=20 is a good approach.
 
3) I think=20 SG-SG model is useful, because it provides = relaying=20 capability. It can be used for IPSP-like communication between = IP-resident peers=20 as well.
 
 
Now, what can be=20 done:
 
a) A draft = clarifying IPSP=20 usage as defined by the current document. This should be a = self-sufficient=20 document, should not change something architecturally but should include = all=20 details which are discussed in this list throughout the years -the = current=20 document unfortunately doesn't-.
 
b) Revisiting SG-SG = draft. I=20 will submit a new version soon -in 5-10 days- still as a non-WG draft. = There has=20 been some off-list comments about it during the last 2 years or so, but=20 architecturally it won't be any different than the version Brian posted = the=20 links to.
 
Where I really am = not sure what=20 to do is, do we want to provide multiple choices for IPSP-model? Can we = have=20 significant changes and if yes to which extent? We already have SE-IPSP = and=20 DE-IPSP, and as indicated above, SG-SG could serve the same purpose as = well.=20 More choices may be confusing for people. My personal preference would = be=20 -considering both technical and non-technical aspects of the=20 problem-:
 
i-  Keep SE-IPSP but not DE-IPSP.
ii- Define SG-SG, = by=20 emphasizing its use for relaying rather than IPSP-kind of=20 operation.
 
 
   =20 Thanks,
    Tolga
-----Original Message-----
From: = sigtran-bounces@ietf.org=20 [mailto:sigtran-bounces@ietf.org]On Behalf Of Ong,=20 Lyndon
Sent: Friday, November 11, 2005 5:41 PM
To: = sigtran@ietf.org
Subject: [Sigtran] m3ua = status

Hi=20 Folks,
 
I = have been=20 watching the mounting pile of emails on IPSP procedures with some=20 concern.
I = think at this=20 point it is quite difficult to make any technical changes to the M3UA=20 bis
spec, as this is=20 well past the review period.
 
At = the same time,=20 it seems clear that there are major differences in peoples'=20 interpretations
of = some sections=20 in the text.  Continued discussion on the email list does not = seem to be=20 leading to a
consensus,=20 either.  Do we need an actual meeting, or some more organized = effort to=20
reach a=20 conclusion?  I'm open to suggestions here (can be sent off line = if you=20 wish).
 
Thanks,
 
L.=20 Ong
------=_NextPart_000_0840_01C5E8FA.D3D66B80-- --===============0704971628== 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 --===============0704971628==-- From sigtran-bounces@ietf.org Mon Nov 14 16:06:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblXK-0003xl-31; Mon, 14 Nov 2005 16:06:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblXF-0003x9-Qs for sigtran@megatron.ietf.org; Mon, 14 Nov 2005 16:06:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26255 for ; Mon, 14 Nov 2005 16:06:09 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbloL-0005Hs-Co for sigtran@ietf.org; Mon, 14 Nov 2005 16:24:22 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Nov 2005 13:06:37 -0800 X-IronPort-AV: i="3.97,328,1125903600"; d="scan'208,217"; a="365058392:sNHT43498250" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAEL6Mmp015228; Mon, 14 Nov 2005 13:06:31 -0800 (PST) Received: from xmb-rtp-209.amer.cisco.com ([64.102.31.11]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 16:06:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sigtran] m3ua status Date: Mon, 14 Nov 2005 16:06:18 -0500 Message-ID: <542F2F9C2CDE6B40A775125727674ECAD506B3@xmb-rtp-209.amer.cisco.com> Thread-Topic: [Sigtran] m3ua status Thread-Index: AcXpJ4lLohAq4e6tT5aiMoSc27g1QgAN53iw From: "Ken A Morneault \(kmorneau\)" To: "Tolga Asveren" , X-OriginalArrivalTime: 14 Nov 2005 21:06:19.0610 (UTC) FILETIME=[4275ABA0:01C5E95F] X-Spam-Score: 0.6 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 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="===============0856561159==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0856561159== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E95F.424E85D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E95F.424E85D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 I'm in favor of proceeding with the SG-SG draft. Hopefully we can push the soon to be released update forward. =20 Regards, =20 Ken ________________________________ From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Tolga Asveren Sent: Monday, November 14, 2005 9:07 AM To: sigtran@ietf.org Subject: RE: [Sigtran] m3ua status My 2 cents about this and related issues: =20 What I think from technical point of view: 1) IMO, SE-IPSP model is a true peer-to-peer model. I don't see any architectural deficiencies but OTOH I think existing documentation is unsatisfactory. =20 2) I don't think DE-IPSP model is a good approach. =20 3) I think SG-SG model is useful, because it provides relaying capability. It can be used for IPSP-like communication between IP-resident peers as well. =20 =20 Now, what can be done: =20 a) A draft clarifying IPSP usage as defined by the current document. This should be a self-sufficient document, should not change something architecturally but should include all details which are discussed in this list throughout the years -the current document unfortunately doesn't-.=20 =20 b) Revisiting SG-SG draft. I will submit a new version soon -in 5-10 days- still as a non-WG draft. There has been some off-list comments about it during the last 2 years or so, but architecturally it won't be any different than the version Brian posted the links to. =20 Where I really am not sure what to do is, do we want to provide multiple choices for IPSP-model? Can we have significant changes and if yes to which extent? We already have SE-IPSP and DE-IPSP, and as indicated above, SG-SG could serve the same purpose as well. More choices may be confusing for people. My personal preference would be -considering both technical and non-technical aspects of the problem-: =20 i- Keep SE-IPSP but not DE-IPSP. ii- Define SG-SG, by emphasizing its use for relaying rather than IPSP-kind of operation. =20 =20 Thanks, Tolga -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Ong, Lyndon Sent: Friday, November 11, 2005 5:41 PM To: sigtran@ietf.org Subject: [Sigtran] m3ua status =09 =09 Hi Folks, =20 I have been watching the mounting pile of emails on IPSP procedures with some concern. I think at this point it is quite difficult to make any technical changes to the M3UA bis spec, as this is well past the review period. =20 At the same time, it seems clear that there are major differences in peoples' interpretations of some sections in the text. Continued discussion on the email list does not seem to be leading to a consensus, either. Do we need an actual meeting, or some more organized effort to=20 reach a conclusion? I'm open to suggestions here (can be sent off line if you wish). =20 Thanks, =20 L. Ong ------_=_NextPart_001_01C5E95F.424E85D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
I'm in favor of proceeding with the SG-SG = draft. =20 Hopefully we can push the soon to be
released update forward.
 
Regards,
 
Ken

From: sigtran-bounces@ietf.org=20 [mailto:sigtran-bounces@ietf.org] On Behalf Of Tolga=20 Asveren
Sent: Monday, November 14, 2005 9:07 AM
To:=20 sigtran@ietf.org
Subject: RE: [Sigtran] m3ua=20 status

My 2 cents about = this and=20 related issues:
 
What I think from = technical=20 point of view:
1) IMO, SE-IPSP = model is a true=20 peer-to-peer model. I don't see any architectural deficiencies but OTOH = I think=20 existing documentation is unsatisfactory.
 
2) I don't think = DE-IPSP model=20 is a good approach.
 
3) I think=20 SG-SG model is useful, because it provides = relaying=20 capability. It can be used for IPSP-like communication between = IP-resident peers=20 as well.
 
 
Now, what can be=20 done:
 
a) A draft = clarifying IPSP=20 usage as defined by the current document. This should be a = self-sufficient=20 document, should not change something architecturally but should include = all=20 details which are discussed in this list throughout the years -the = current=20 document unfortunately doesn't-.
 
b) Revisiting SG-SG = draft. I=20 will submit a new version soon -in 5-10 days- still as a non-WG draft. = There has=20 been some off-list comments about it during the last 2 years or so, but=20 architecturally it won't be any different than the version Brian posted = the=20 links to.
 
Where I really am = not sure what=20 to do is, do we want to provide multiple choices for IPSP-model? Can we = have=20 significant changes and if yes to which extent? We already have SE-IPSP = and=20 DE-IPSP, and as indicated above, SG-SG could serve the same purpose as = well.=20 More choices may be confusing for people. My personal preference would = be=20 -considering both technical and non-technical aspects of the=20 problem-:
 
i-  Keep SE-IPSP but not DE-IPSP.
ii- Define SG-SG, = by=20 emphasizing its use for relaying rather than IPSP-kind of=20 operation.
 
 
   =20 Thanks,
    Tolga
-----Original Message-----
From: = sigtran-bounces@ietf.org=20 [mailto:sigtran-bounces@ietf.org]On Behalf Of Ong,=20 Lyndon
Sent: Friday, November 11, 2005 5:41 PM
To: = sigtran@ietf.org
Subject: [Sigtran] m3ua = status

Hi=20 Folks,
 
I = have been=20 watching the mounting pile of emails on IPSP procedures with some=20 concern.
I = think at this=20 point it is quite difficult to make any technical changes to the M3UA=20 bis
spec, as this is=20 well past the review period.
 
At = the same time,=20 it seems clear that there are major differences in peoples'=20 interpretations
of = some sections=20 in the text.  Continued discussion on the email list does not = seem to be=20 leading to a
consensus,=20 either.  Do we need an actual meeting, or some more organized = effort to=20
reach a=20 conclusion?  I'm open to suggestions here (can be sent off line = if you=20 wish).
 
Thanks,
 
L.=20 Ong
------_=_NextPart_001_01C5E95F.424E85D0-- --===============0856561159== 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 --===============0856561159==-- From sigtran-bounces@ietf.org Mon Nov 14 23:55:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbsrB-0003rj-8B; Mon, 14 Nov 2005 23:55:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebsr9-0003rU-UX for sigtran@megatron.ietf.org; Mon, 14 Nov 2005 23:55:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29096 for ; Mon, 14 Nov 2005 23:55:11 -0500 (EST) Received: from hostreea1.alcatel.com ([143.209.238.161] helo=audl951.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebt8J-0005sz-Dd for sigtran@ietf.org; Tue, 15 Nov 2005 00:13:28 -0500 Received: from axes-mach01.usa.alcatel.com (axes-mach01.usa.alcatel.com [10.255.0.20]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id jAF4tT1E022256 for ; Mon, 14 Nov 2005 22:55:32 -0600 Received: from [10.255.1.164] (ax-sp-pc112.usa.alcatel.com [10.255.1.164]) by axes-mach01.usa.alcatel.com (8.12.10+Sun/8.12.2) with ESMTP id jAF4Umjr013615 for ; Tue, 15 Nov 2005 10:00:49 +0530 (IST) Message-ID: <43796556.3020205@axes-mach01.usa.alcatel.com> Date: Tue, 15 Nov 2005 10:04:30 +0530 From: Bhanu Prakash User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sigtran@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Sigtran] M3UA- handling of multiple Routing Context's (SGP <-> ASP) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hai all I need clarification on this issue: Consider a case where an SGP is using the AS number as routing context. If an SGP receives an M3UA message with multiple routing context's, If some of the routing context's are invalid (i.e. not configured in SGP), an error message is sent to ASP indicating the same. Q1-What about the other valid routing context's.? Q2-Should the SGP has to process the valid ones.? If yes.. If the ASP is not in expected state for some routing context's(i.e AS) and ASP is in expected state for routing context's(i.e AS), what is the procedure to handle the same. Thanks, Bhanuprakash. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 15 01:02:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbttY-00073L-7f; Tue, 15 Nov 2005 01:02:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbttW-00073F-CE for sigtran@megatron.ietf.org; Tue, 15 Nov 2005 01:02:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02489 for ; Tue, 15 Nov 2005 01:01:43 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[Q3CotNpPYs8ZVLw8rJ72z0Z4rOyQEAxm]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbuAg-0007tH-Be for sigtran@ietf.org; Tue, 15 Nov 2005 01:19:59 -0500 Received: from ns.pigworks.openss7.net (IDENT:oEwmjSlxTYr1CB2u8Oyxjfzy1XnA56UK@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAF622A05044; Mon, 14 Nov 2005 23:02:02 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAF621G11632; Mon, 14 Nov 2005 23:02:01 -0700 Date: Mon, 14 Nov 2005 23:02:00 -0700 From: "Brian F. G. Bidulock" To: partha.dey@wipro.com Subject: Re: [Sigtran] Clarification on CLDT CORE broadcast. Message-ID: <20051114230200.A11198@openss7.org> Mail-Followup-To: partha.dey@wipro.com, sigtran@ietf.org References: <5A521CAA914BAF47A48A726DE83E7D24017755F9@blr-k1-msg.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5A521CAA914BAF47A48A726DE83E7D24017755F9@blr-k1-msg.wipro.com>; from partha.dey@wipro.com on Mon, Nov 14, 2005 at 05:36:10PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org partha.dey, I have no idea why it says CLDT in section 3.9.19. I suppose it is a correction for the SUA IG. Correlation Id in this way is used for all CO and CL messages. For this and additional uses of Correlation Id for SUA and other UAs, see: http://www.openss7.org/docs/draft-bidulock-sigtran-corid-04.txt http://www.openss7.org/docs/draft-bidulock-sigtran-corid-04.ps http://www.openss7.org/docs/draft-bidulock-sigtran-corid-04.pdf --brian partha.dey@wipro.com wrote: (Mon, 14 Nov 2005 17:36:10) > > Hi Brian, > > There seems to be a discrepancy in the RFC relating to Broadcasting a > message for a CLDT req and CORE request, > > > Section 4.3.4.3. page 70 says > Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP > MUST tag the first DATA message broadcast in each traffic flow with a > unique Correlation Id parameter. The purpose of this Correlation Id > is to permit the newly active ASP to synchronize its processing of > traffic in each traffic flow with the other ASPs in the broadcast > group. > > Section 3.9.19 Page 71 > The Correlation ID is a 32-bit identifier that is attached to CLDT > messages to indicate to a newly entering ASP in a Broadcast AS where > in the traffic flow of CLDT messages the ASP is joining. It is > attached to the first CLDT message sent to an ASP by an SG after > sending an ASP Active Ack or otherwise starting traffic to an ASP. > The Correlation ID is only significant within a Routing Context. > > The query is whether the Broadcasting takes place for both CORE and CLDT or onl > y CLDT? > > > > Regards, > > Partha. > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 15 01:04:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbtvF-0007a4-Sh; Tue, 15 Nov 2005 01:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbtvE-0007YC-Eq for sigtran@megatron.ietf.org; Tue, 15 Nov 2005 01:04:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02746 for ; Tue, 15 Nov 2005 01:03:29 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[Wd/KSFkizBbW0QZXbeMgVu3JIMCclsdi]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbuCP-00080f-GJ for sigtran@ietf.org; Tue, 15 Nov 2005 01:21:45 -0500 Received: from ns.pigworks.openss7.net (IDENT:+kv3Q3cH+l7a7QwHGNoJwOJhssyj8YTd@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAF63wA05057; Mon, 14 Nov 2005 23:03:58 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAF63wd11638; Mon, 14 Nov 2005 23:03:58 -0700 Date: Mon, 14 Nov 2005 23:03:57 -0700 From: "Brian F. G. Bidulock" To: Bhanu Prakash Subject: Re: [Sigtran] M3UA- handling of multiple Routing Context's (SGP <-> ASP) Message-ID: <20051114230357.B11198@openss7.org> Mail-Followup-To: Bhanu Prakash , sigtran@ietf.org References: <43796556.3020205@axes-mach01.usa.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <43796556.3020205@axes-mach01.usa.alcatel.com>; from bhanup@axes-mach01.usa.alcatel.com on Tue, Nov 15, 2005 at 10:04:30AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Bhanu, Bhanu Prakash wrote: (Tue, 15 Nov 2005 10:04:30) > Hai all > I need clarification on this issue: > > Consider a case where an SGP is using the AS number as routing context. > If an SGP receives an M3UA message with multiple routing context's, > If some of the routing context's are invalid (i.e. not configured in SGP), > an error message is sent to ASP indicating the same. > > Q1-What about the other valid routing context's.? > Q2-Should the SGP has to process the valid ones.? No, it does not have to: an invalid message is, after all, an invalid message. --brian > If yes.. > If the ASP is not in expected state for some routing context's(i.e > AS) and > ASP is in expected state for routing context's(i.e AS), what is > the procedure > to handle the same. > > Thanks, > Bhanuprakash. > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 15 09:27:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec1mO-0005Fk-DU; Tue, 15 Nov 2005 09:27:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec1mN-0005FD-0E for sigtran@megatron.ietf.org; Tue, 15 Nov 2005 09:27:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27390 for ; Tue, 15 Nov 2005 09:26:50 -0500 (EST) From: amrita.garg@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec23a-00060R-Sp for sigtran@ietf.org; Tue, 15 Nov 2005 09:45:12 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 0DECD205F6 for ; Tue, 15 Nov 2005 19:44:02 +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 E87AC205DE for ; Tue, 15 Nov 2005 19:44:01 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2005 19:56:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Nov 2005 19:56:53 +0530 Message-ID: <527712917C05904F91F46FADBBE0F90D01AB5A57@BLR-EC-MBX02.wipro.com> Thread-Topic: Sigtran] [SUA] : DRST and SCON messages Thread-Index: AcXp8KAsnDerdht+REGCJe/r3D7jEw== To: X-OriginalArrivalTime: 15 Nov 2005 14:26:54.0668 (UTC) FILETIME=[A0A778C0:01C5E9F0] X-Spam-Score: 0.5 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Subject: [Sigtran] Sigtran] [SUA] : DRST and SCON messages X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1042092050==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1042092050== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E9F0.A08D7EF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E9F0.A08D7EF8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brain, =20 Could you please provide some clarifications on DRST and SCON messages. =20 According to specification Q714, a signaling point can have 3 states - "accessible", "inaccessible", or "congested". For each of the above state change SUA will receive a DAVA, DUNA or SCON message respectively. =20 In which case can a SUA receive a DRST message, and to what pointcode state it maps on to. =20 Is it that a DRST message is send for the congested state and a SCON is send whenever there is a change in the congestion level. =20 =20 Regards Amrita Garg =20 =20 =20 =20 ------_=_NextPart_001_01C5E9F0.A08D7EF8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brain,

 

Could you please provide some clarifications on DRST = and SCON messages.

 

According to specification = Q714, a signaling point can have 3 states - “accessible", = “inaccessible", or “congested”.<= o:p>

For each of the = above state change SUA will receive a DAVA, DUNA or SCON message = respectively.

   &n= bsp;           &nb= sp;           &nbs= p;

In which case can a = SUA receive a DRST message, and to what pointcode state it maps on = to.

 

Is it that a DRST = message is send for the congested state and a SCON is send whenever there is a = change in the congestion level.

 

 

Regards

Amrita = Garg

 

 

 

 

------_=_NextPart_001_01C5E9F0.A08D7EF8-- --===============1042092050== 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 --===============1042092050==-- From sigtran-bounces@ietf.org Tue Nov 15 10:40:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec2vY-0002Aw-8r; Tue, 15 Nov 2005 10:40:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec2vW-0002Ag-Ur for sigtran@megatron.ietf.org; Tue, 15 Nov 2005 10:40:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01208 for ; Tue, 15 Nov 2005 10:40:22 -0500 (EST) Received: from hostree9f.alcatel.com ([143.209.238.159] helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec3Cl-0008BP-SJ for sigtran@ietf.org; Tue, 15 Nov 2005 10:58:45 -0500 Received: from axes-mach01.usa.alcatel.com (axes-mach01.usa.alcatel.com [10.255.0.20]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id jAFFeU6I027493; Tue, 15 Nov 2005 09:40:43 -0600 Received: from [10.255.1.164] (ax-sp-pc112.usa.alcatel.com [10.255.1.164]) by axes-mach01.usa.alcatel.com (8.12.10+Sun/8.12.2) with ESMTP id jAFEXOjr024712; Tue, 15 Nov 2005 20:03:24 +0530 (IST) Message-ID: <4379F290.3000801@axes-mach01.usa.alcatel.com> Date: Tue, 15 Nov 2005 20:07:04 +0530 From: Bhanu Prakash User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sigtran@ietf.org X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 1.1 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [Sigtran] [Fwd: M3UA- handling of multiple Routing Context's (SGP <-> ASP)] 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="===============1291707617==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1291707617== Content-Type: multipart/alternative; boundary="------------010208030002050507010904" This is a multi-part message in MIME format. --------------010208030002050507010904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: M3UA- handling of multiple Routing Context's (SGP <-> ASP) Date: Tue, 15 Nov 2005 10:04:30 +0530 From: Bhanu Prakash To: sigtran@ietf.org Hai all I need clarification on this issue: Consider a case where an SGP is using the AS number as routing context. If an SGP receives an M3UA message with multiple routing context's, If some of the routing context's are invalid (i.e. not configured in SGP), an error message is sent to ASP indicating the same. Q1-What about the other valid routing context's.? Q2-Should the SGP has to process the valid ones.? If yes.. If the ASP is not in expected state for some routing context's(i.e AS) and ASP is in expected state for routing context's(i.e AS), what is the procedure to handle the same. Thanks, Bhanuprakash. --------------010208030002050507010904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

-------- Original Message --------
Subject: M3UA- handling of multiple Routing Context's (SGP <-> ASP)
Date: Tue, 15 Nov 2005 10:04:30 +0530
From: Bhanu Prakash <bhanup@axes-mach01.usa.alcatel.com>
To: sigtran@ietf.org 


Hai all
I need clarification on this issue:

Consider a case where an SGP is using the AS number as routing context.
If an SGP receives an M3UA message with multiple routing context's,
If some of the routing context's are invalid (i.e. not configured in SGP),
an error message is sent to ASP indicating the same.

Q1-What about the other valid routing context's.?
Q2-Should the SGP has to process the valid ones.? If yes..
     If the ASP is not in expected state for some routing context's(i.e 
AS) and
     ASP is in expected state for routing context's(i.e AS), what is 
the procedure
     to handle the same.

Thanks,
Bhanuprakash.
--------------010208030002050507010904-- --===============1291707617== 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 --===============1291707617==-- From sigtran-bounces@ietf.org Tue Nov 15 13:00:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec56d-0006U3-QU; Tue, 15 Nov 2005 13:00:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec56c-0006Rr-Hx for sigtran@megatron.ietf.org; Tue, 15 Nov 2005 13:00:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13337 for ; Tue, 15 Nov 2005 12:59:57 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[kB21ddRCyOFlxpeX6OVUaJruWU0GKBbw]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec5Ns-0005Jm-RN for sigtran@ietf.org; Tue, 15 Nov 2005 13:18:22 -0500 Received: from ns.pigworks.openss7.net (IDENT:oPzZvXduEQDfXlhfgcSpqnuFece767Wf@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAFI0NA18896; Tue, 15 Nov 2005 11:00:23 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAFI0NT19221; Tue, 15 Nov 2005 11:00:23 -0700 Date: Tue, 15 Nov 2005 11:00:22 -0700 From: "Brian F. G. Bidulock" To: amrita.garg@wipro.com Subject: Re: [Sigtran] Sigtran] [SUA] : DRST and SCON messages Message-ID: <20051115110022.A19167@openss7.org> Mail-Followup-To: amrita.garg@wipro.com, sigtran@ietf.org References: <527712917C05904F91F46FADBBE0F90D01AB5A57@BLR-EC-MBX02.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <527712917C05904F91F46FADBBE0F90D01AB5A57@BLR-EC-MBX02.wipro.com>; from amrita.garg@wipro.com on Tue, Nov 15, 2005 at 07:56:53PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org amrita.garg, amrita.garg@wipro.com wrote: (Tue, 15 Nov 2005 19:56:53) > > Hi Brain, > > > Could you please provide some clarifications on DRST and SCON > messages. > > > According to specification Q714, a signaling point can have 3 states - > "accessible", "inaccessible", or "congested". For ANSI a signalling point can also be "restricted". Thus DRST. --brian > > For each of the above state change SUA will receive a DAVA, DUNA or > SCON message respectively. > > > In which case can a SUA receive a DRST message, and to what pointcode > state it maps on to. > > > Is it that a DRST message is send for the congested state and a SCON > is send whenever there is a change in the congestion level. > > > > Regards > > Amrita Garg > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 15 13:02:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec58e-0006uj-NQ; Tue, 15 Nov 2005 13:02:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec58c-0006uY-5M for sigtran@megatron.ietf.org; Tue, 15 Nov 2005 13:02:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13447 for ; Tue, 15 Nov 2005 13:02:00 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[/O1P8N1RKm3j43INPgDhAeU+hbNJnOCS]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec5Ps-0005NF-Dw for sigtran@ietf.org; Tue, 15 Nov 2005 13:20:25 -0500 Received: from ns.pigworks.openss7.net (IDENT:aAlnMktLw40DHTcDn7/AK21XzoYgA99e@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAFI2VA18978; Tue, 15 Nov 2005 11:02:31 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAFI2Vu19403; Tue, 15 Nov 2005 11:02:31 -0700 Date: Tue, 15 Nov 2005 11:02:30 -0700 From: "Brian F. G. Bidulock" To: Bhanu Prakash Message-ID: <20051115110230.B19167@openss7.org> Mail-Followup-To: Bhanu Prakash , sigtran@ietf.org References: <4379F290.3000801@axes-mach01.usa.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4379F290.3000801@axes-mach01.usa.alcatel.com>; from bhanup@axes-mach01.usa.alcatel.com on Tue, Nov 15, 2005 at 08:07:04PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sigtran@ietf.org Subject: [Sigtran] Re: [Fwd: M3UA- handling of multiple Routing Context's (SGP <-> ASP)] X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Bhanu, Bhanu Prakash wrote: (Tue, 15 Nov 2005 20:07:04) > > -------- Original Message -------- > > Subject: M3UA- handling of multiple Routing Context's (SGP <-> ASP) > Date: Tue, 15 Nov 2005 10:04:30 +0530 > From: Bhanu Prakash [1] > To: [2]sigtran@ietf.org > > Hai all > I need clarification on this issue: > > Consider a case where an SGP is using the AS number as routing context. > If an SGP receives an M3UA message with multiple routing context's, > If some of the routing context's are invalid (i.e. not configured in SGP), > an error message is sent to ASP indicating the same. > > Q1-What about the other valid routing context's.? > Q2-Should the SGP has to process the valid ones.? It does not have to: the message is invalid. --brian > If yes.. > If the ASP is not in expected state for some routing context's(i.e > AS) and > ASP is in expected state for routing context's(i.e AS), what is > the procedure > to handle the same. > > Thanks, > Bhanuprakash. > > References > > 1. mailto:bhanup@axes-mach01.usa.alcatel.com > 2. mailto:sigtran@ietf.org -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 15 13:58:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec60s-0004I3-AH; Tue, 15 Nov 2005 13:58:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec60q-0004GX-O8 for sigtran@megatron.ietf.org; Tue, 15 Nov 2005 13:58:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18166 for ; Tue, 15 Nov 2005 13:58:04 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec6I7-0007cw-HY for sigtran@ietf.org; Tue, 15 Nov 2005 14:16:28 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2005 10:58:25 -0800 X-IronPort-AV: i="3.97,334,1125903600"; d="scan'208"; a="230702645:sNHT35882568" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAFIvZ4T013416; Tue, 15 Nov 2005 10:58:21 -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); Tue, 15 Nov 2005 13:58:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] Re: [Fwd: M3UA- handling of multiple Routing Context's(SGP <-> ASP)] Date: Tue, 15 Nov 2005 13:58:09 -0500 Message-ID: <542F2F9C2CDE6B40A775125727674ECADA4D87@xmb-rtp-209.amer.cisco.com> Thread-Topic: [Sigtran] Re: [Fwd: M3UA- handling of multiple Routing Context's(SGP <-> ASP)] Thread-Index: AcXqEHcoxaQJf0edRguHQ9KffQ+AWwABWa8w From: "Ken A Morneault \(kmorneau\)" To: , "Bhanu Prakash" X-OriginalArrivalTime: 15 Nov 2005 18:58:10.0946 (UTC) FILETIME=[86126620:01C5EA16] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, Bhanu, I would say it should process the valid RCs and return an Error "Invalid RC" for the invalid RCs. For instance, the SGP receives an ASP Active with multiple RCs. The SGP would send ASP Active Ack for all valid RCs and an Error "Invalid RC" for the invalid RCs. =20 Regards, Ken =20 -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Brian F. G. Bidulock Sent: Tuesday, November 15, 2005 1:03 PM To: Bhanu Prakash Cc: sigtran@ietf.org Subject: [Sigtran] Re: [Fwd: M3UA- handling of multiple Routing Context's(SGP <-> ASP)] Bhanu, Bhanu Prakash wrote: (Tue, 15 Nov 2005 20:07:04) >=20 > -------- Original Message -------- >=20 > Subject: M3UA- handling of multiple Routing Context's (SGP <-> ASP) > Date: Tue, 15 Nov 2005 10:04:30 +0530 > From: Bhanu Prakash [1] > To: [2]sigtran@ietf.org >=20 > Hai all > I need clarification on this issue: >=20 > Consider a case where an SGP is using the AS number as routing context. > If an SGP receives an M3UA message with multiple routing context's, If > some of the routing context's are invalid (i.e. not configured in=20 > SGP), an error message is sent to ASP indicating the same. >=20 > Q1-What about the other valid routing context's.? > Q2-Should the SGP has to process the valid ones.? It does not have to: the message is invalid. --brian > If yes.. > If the ASP is not in expected state for some routing=20 > context's(i.e > AS) and > ASP is in expected state for routing context's(i.e AS), what is=20 > the procedure > to handle the same. >=20 > Thanks, > Bhanuprakash. >=20 > References >=20 > 1. mailto:bhanup@axes-mach01.usa.alcatel.com > 2. mailto:sigtran@ietf.org -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 15 14:03:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec662-0005z2-Mv; Tue, 15 Nov 2005 14:03:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec661-0005yp-Gf for sigtran@megatron.ietf.org; Tue, 15 Nov 2005 14:03:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18404 for ; Tue, 15 Nov 2005 14:03:25 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[3V+K6JuWIHd7oZ06Cj5mh48/CUOA/WwC]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec6NI-0007mB-C2 for sigtran@ietf.org; Tue, 15 Nov 2005 14:21:49 -0500 Received: from ns.pigworks.openss7.net (IDENT:4dYFIGG/kY7KYlcS9DJaQx7SltIzLW48@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAFJ3sA09510; Tue, 15 Nov 2005 12:03:54 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAFJ3sA20340; Tue, 15 Nov 2005 12:03:54 -0700 Date: Tue, 15 Nov 2005 12:03:54 -0700 From: "Brian F. G. Bidulock" To: "Ken A Morneault (kmorneau)" Subject: Re: [Sigtran] Re: [Fwd: M3UA- handling of multiple Routing Context's(SGP <-> ASP)] Message-ID: <20051115120354.A20042@openss7.org> Mail-Followup-To: "Ken A Morneault (kmorneau)" , Bhanu Prakash , sigtran@ietf.org References: <542F2F9C2CDE6B40A775125727674ECADA4D87@xmb-rtp-209.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <542F2F9C2CDE6B40A775125727674ECADA4D87@xmb-rtp-209.amer.cisco.com>; from kmorneau@cisco.com on Tue, Nov 15, 2005 at 01:58:09PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Ken, Yes you could, but my point is that you are not required to. --brian Ken Morneault wrote: (Tue, 15 Nov 2005 13:58:09) > > > Brian, Bhanu, > > I would say it should process the valid RCs and > return an Error "Invalid RC" for the invalid RCs. > > For instance, the SGP receives an ASP Active with > multiple RCs. The SGP would send ASP Active Ack for > all valid RCs and an Error "Invalid RC" for the > invalid RCs. > > Regards, > > Ken > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Brian F. G. Bidulock > Sent: Tuesday, November 15, 2005 1:03 PM > To: Bhanu Prakash > Cc: sigtran@ietf.org > Subject: [Sigtran] Re: [Fwd: M3UA- handling of multiple Routing > Context's(SGP <-> ASP)] > > Bhanu, > > Bhanu Prakash wrote: > (Tue, 15 Nov 2005 20:07:04) > > > > -------- Original Message -------- > > > > Subject: M3UA- handling of multiple Routing Context's (SGP <-> ASP) > > Date: Tue, 15 Nov 2005 10:04:30 +0530 > > From: Bhanu Prakash [1] > > To: [2]sigtran@ietf.org > > > > Hai all > > I need clarification on this issue: > > > > Consider a case where an SGP is using the AS number as routing > context. > > If an SGP receives an M3UA message with multiple routing context's, If > > > some of the routing context's are invalid (i.e. not configured in > > SGP), an error message is sent to ASP indicating the same. > > > > Q1-What about the other valid routing context's.? > > Q2-Should the SGP has to process the valid ones.? > > It does not have to: the message is invalid. > > --brian > > > If yes.. > > If the ASP is not in expected state for some routing > > context's(i.e > > AS) and > > ASP is in expected state for routing context's(i.e AS), what is > > the procedure > > to handle the same. > > > > Thanks, > > Bhanuprakash. > > > > References > > > > 1. mailto:bhanup@axes-mach01.usa.alcatel.com > > 2. mailto:sigtran@ietf.org > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 15 18:44:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAT6-00031O-Ux; Tue, 15 Nov 2005 18:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAT5-00031F-LX for sigtran@megatron.ietf.org; Tue, 15 Nov 2005 18:44:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07230 for ; Tue, 15 Nov 2005 18:43:30 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcAkK-0000Dl-8u for Sigtran@ietf.org; Tue, 15 Nov 2005 19:01:58 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id jAFNqPg3014180 for ; Tue, 15 Nov 2005 16:52:25 -0700 (MST) Received: from motorola.com (mvp-10-180-34-138.am.mot.com [10.180.34.138]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id jAFNvGEG024982; Tue, 15 Nov 2005 17:57:17 -0600 (CST) Message-ID: <437A7319.6090106@motorola.com> Date: Tue, 15 Nov 2005 17:45:29 -0600 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sigtran Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Sigtran] SUA open source stack? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org All, I'd appreciate information on any open source SUA stacks. regards, -Qiaobing _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 16 07:08:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcM5e-0000nj-Ck; Wed, 16 Nov 2005 07:08:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcM5c-0000ne-PK for sigtran@megatron.ietf.org; Wed, 16 Nov 2005 07:08:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19986 for ; Wed, 16 Nov 2005 07:08:02 -0500 (EST) From: varadaraj.yatirajula@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcMMy-0005Tt-Rf for Sigtran@ietf.org; Wed, 16 Nov 2005 07:26:37 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 487D7205DC for ; Wed, 16 Nov 2005 17:25:10 +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 27892205D9 for ; Wed, 16 Nov 2005 17:25:10 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 17:37:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Nov 2005 17:37:55 +0530 Message-ID: <897DA809E857CD40A8419CF517948E21015438D7@blr-k1-msg.wipro.com> Thread-Topic: SUA: Routing Context for CL and CO messages Thread-Index: AcXqpmBV4ujA4JaKSYipEUibQ9Nn+A== To: X-OriginalArrivalTime: 16 Nov 2005 12:07:58.0673 (UTC) FILETIME=[626D5410:01C5EAA6] X-Spam-Score: 0.5 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: Subject: [Sigtran] SUA: Routing Context for CL and CO messages X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1986555643==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1986555643== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EAA6.609A431C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EAA6.609A431C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the SUA RFC, the RC parm in CO and CL messages seems to indicate that multiple routing contexts values can be present. However this does not look to be correct as the message should logically be received from or sent to a unique AS (or routing context) =20 Can someone clarify this? =20 >From RFC: =20 3.2.1. Connectionless Data Transfer (CLDT) =20 This message transfers data between one SUA to another. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag =3D 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Routing Context / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 ------_=_NextPart_001_01C5EAA6.609A431C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the SUA RFC, the RC parm in CO and CL messages = seems to indicate

that multiple routing contexts values can be present. = However this does not look to be

correct as the message should logically be received = from or sent to a unique AS (or routing context)

 

Can someone clarify = this?

 

From RFC:

 

3.2.1.  Connectionless Data Transfer (CLDT)

 

   This message transfers data between one SUA to = another.

 

    0            =        1            =        2            =        3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |          Tag =3D 0x0006         |            Length           &= nbsp; |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   /            =            Routing = Context           =             &= nbsp; /

   \            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  \

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

------_=_NextPart_001_01C5EAA6.609A431C-- --===============1986555643== 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 --===============1986555643==-- From sigtran-bounces@ietf.org Wed Nov 16 07:23:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMKA-0004Mk-0v; Wed, 16 Nov 2005 07:23:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMK8-0004Mf-Fk for sigtran@megatron.ietf.org; Wed, 16 Nov 2005 07:23:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20950 for ; Wed, 16 Nov 2005 07:23:02 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[tAJjnHMr/LQcwE6ntyjhg0H/E8PX8iKY]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcMbV-0005w5-G5 for Sigtran@ietf.org; Wed, 16 Nov 2005 07:41:34 -0500 Received: from ns.pigworks.openss7.net (IDENT:2Sxhq5vhsaNjIvHud1Fjsy04BGnlzEVW@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAGCNEA31975; Wed, 16 Nov 2005 05:23:14 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAGCNDh30083; Wed, 16 Nov 2005 05:23:13 -0700 Date: Wed, 16 Nov 2005 05:23:13 -0700 From: "Brian F. G. Bidulock" To: varadaraj.yatirajula@wipro.com Subject: Re: [Sigtran] SUA: Routing Context for CL and CO messages Message-ID: <20051116052313.A30036@openss7.org> Mail-Followup-To: varadaraj.yatirajula@wipro.com, Sigtran@ietf.org References: <897DA809E857CD40A8419CF517948E21015438D7@blr-k1-msg.wipro.com> 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: <897DA809E857CD40A8419CF517948E21015438D7@blr-k1-msg.wipro.com>; from varadaraj.yatirajula@wipro.com on Wed, Nov 16, 2005 at 05:37:55PM +0530 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 jAGCNEA31975 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: Sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org varadaraj.yatirajula, Yes, although the parameter supports multiple RCs, CO and CL messages should only contain one RC. Another for the IG. --brian On Wed, 16 Nov 2005, varadaraj.yatirajula@wipro.com wrote: >=20 > In the SUA RFC, the RC parm in CO and CL messages seems to indicate >=20 > that multiple routing contexts values can be present. However th= is > does not look to be >=20 > correct as the message should logically be received from or sent to= a > unique AS (or routing context) >=20 >=20 > Can someone clarify this? >=20 >=20 > From RFC: >=20 >=20 > 3.2.1. Connectionless Data Transfer (CLDT) >=20 >=20 > This message transfers data between one SUA to another. >=20 >=20 > 0 1 2 3 >=20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > | Tag =3D 0x0006 | Length = | >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > / Routing Context / >=20 > \ \ >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 16 07:34:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMUK-0006JV-Nk; Wed, 16 Nov 2005 07:34:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMUJ-0006JG-W0 for sigtran@megatron.ietf.org; Wed, 16 Nov 2005 07:34:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21576 for ; Wed, 16 Nov 2005 07:33:33 -0500 (EST) From: amrita.garg@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcMlk-0006GN-3r for sigtran@ietf.org; Wed, 16 Nov 2005 07:52:09 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id DDE2F205DD for ; Wed, 16 Nov 2005 17:51:02 +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 BDF67205D9 for ; Wed, 16 Nov 2005 17:51:02 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 18:03:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Nov 2005 18:03:56 +0530 Message-ID: <527712917C05904F91F46FADBBE0F90D01B0C244@BLR-EC-MBX02.wipro.com> Thread-Topic: Sigtran [SUA] : Modification of Routing Key Thread-Index: AcXp8KAsnDerdht+REGCJe/r3D7jEwAuDD1g To: X-OriginalArrivalTime: 16 Nov 2005 12:33:56.0842 (UTC) FILETIME=[032B0CA0:01C5EAAA] X-Spam-Score: 0.5 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Subject: [Sigtran] Sigtran [SUA] : Modification of Routing Key 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="===============0718083986==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0718083986== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EAAA.030F7071" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EAAA.030F7071 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 Referring to section 4.4.1 of RFC 3868,] =20 An ASP MAY modify an existing Routing Key by including a Routing Context parameter in the REG REQ. If the SGP determines that the Routing Context applies to an existing Routing Key, the SG MAY adjust the existing Routing Key to match the new information provided in the Routing Key parameter.=20 =20 =20 IF two (example ASP1 and ASP2) or more ASPs have registered a Routing Key(RK1) and a request to modify the routing key(RK1) from ASP1 modifies the key then in that case how do the other ASPs know of the change in Routing Key. Should not the other ASP which had registered the same routing key be informed about the change. How do we do that? =20 Regards Amrita Garg =20 =20 =20 =20 ------_=_NextPart_001_01C5EAAA.030F7071 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

Referring to section 4.4.1 of RFC 3868,]

 =

An ASP MAY modify an = existing Routing Key by including a Routing

Context parameter in the = REG REQ. If the SGP determines that the

Routing Context applies = to an existing Routing Key, the SG MAY adjust

the existing Routing Key = to match the new information provided in the

Routing Key parameter. =

 

 

IF two (example ASP1 and = ASP2) or more ASPs have registered a Routing Key(RK1) and a request to modify the = routing key(RK1) from ASP1 modifies the key then in that case how do the other ASPs know = of the change in Routing Key.

Should not the other ASP = which had registered the same routing key be informed about the change. How do we = do that?

 

Regards

Amrita = Garg

 

 

 

 

------_=_NextPart_001_01C5EAAA.030F7071-- --===============0718083986== 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 --===============0718083986==-- From sigtran-bounces@ietf.org Wed Nov 16 10:00:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOlt-00049X-OX; Wed, 16 Nov 2005 10:00:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOlr-00049P-Tm for sigtran@megatron.ietf.org; Wed, 16 Nov 2005 10:00:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02206 for ; Wed, 16 Nov 2005 09:59:50 -0500 (EST) Received: from phl-28-b-170.phl.dsl.cerfnet.com ([63.242.157.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcP3G-0002vh-Lu for sigtran@ietf.org; Wed, 16 Nov 2005 10:18:26 -0500 Received: from bn001320 (bn001320 [192.168.1.61]) by phl-28-b-170.phl.dsl.cerfnet.com (8.12.8/8.12.8) with SMTP id jAGF07oj018532 for ; Wed, 16 Nov 2005 10:00:07 -0500 From: "Barry Nagelberg" To: Date: Wed, 16 Nov 2005 10:01:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <527712917C05904F91F46FADBBE0F90D01B0C244@BLR-EC-MBX02.wipro.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: [Sigtran] RE: Sigtran [SUA] : Modification of Routing Key X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Amrita, This is a good question that we have thought about also. In our SGP implementation, we are assuming that ASP1 and ASP2 are being controlled by a central application. Our customers almost always implement multiple ASPs as multiple ethernet cards in a workstation. So we're assuming that if ASP1 sends a modification request for RK1, then ASP2 knows about the modification as well. So we will modify RK1 for both ASPs. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of amrita.garg@wipro.com Sent: Wednesday, November 16, 2005 7:34 AM To: sigtran@ietf.org Subject: [Sigtran] Sigtran [SUA] : Modification of Routing Key Hi, Referring to section 4.4.1 of RFC 3868,] An ASP MAY modify an existing Routing Key by including a Routing Context parameter in the REG REQ. If the SGP determines that the Routing Context applies to an existing Routing Key, the SG MAY adjust the existing Routing Key to match the new information provided in the Routing Key parameter. IF two (example ASP1 and ASP2) or more ASPs have registered a Routing Key(RK1) and a request to modify the routing key(RK1) from ASP1 modifies the key then in that case how do the other ASPs know of the change in Routing Key. Should not the other ASP which had registered the same routing key be informed about the change. How do we do that? Regards Amrita Garg _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 16 10:50:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPY8-0007El-0Q; Wed, 16 Nov 2005 10:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPY6-0007Di-Jc for sigtran@megatron.ietf.org; Wed, 16 Nov 2005 10:50:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05051 for ; Wed, 16 Nov 2005 10:49:40 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcPaE-0004jm-Fd for sigtran@ietf.org; Wed, 16 Nov 2005 10:52:31 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jAGFY1CV011225 for ; Wed, 16 Nov 2005 10:34:04 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] RE: Sigtran [SUA] : Modification of Routing Key Date: Wed, 16 Nov 2005 10:16:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org inline.... > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Barry Nagelberg > Sent: Wednesday, November 16, 2005 10:02 AM > To: sigtran@ietf.org > Subject: [Sigtran] RE: Sigtran [SUA] : Modification of Routing Key > > > Amrita, > > This is a good question that we have thought about also. > > In our SGP implementation, we are assuming that ASP1 and ASP2 are > being controlled by a central application. Our > customers almost always implement multiple ASPs as multiple > ethernet cards in a workstation. [TOLGA]I also think that it is a realistic assumption to expect ASPs to have some kind of coordination between them regarding the traffic range change for a RK. Although not directly related with this issue, I am really wondering why people would like to have multiple ASP on a single host -unless SCTP multihoming is not supported-. > > So we're assuming that if ASP1 sends a modification request for > RK1, then ASP2 knows about the modification as well. So > we will modify RK1 for both ASPs. > > Barry Nagelberg > Adax, Inc. > > -----Original Message----- > From: sigtran-bounces@ietf.org > [mailto:sigtran-bounces@ietf.org]On Behalf Of amrita.garg@wipro.com > Sent: Wednesday, November 16, 2005 7:34 AM > To: sigtran@ietf.org > Subject: [Sigtran] Sigtran [SUA] : Modification of Routing Key > > Hi, > > Referring to section 4.4.1 of RFC 3868,] > > An ASP MAY modify an existing Routing Key by including a Routing > Context parameter in the REG REQ. If the SGP determines that the > Routing Context applies to an existing Routing Key, the SG MAY adjust > the existing Routing Key to match the new information provided in the > Routing Key parameter. > > > IF two (example ASP1 and ASP2) or more ASPs have registered a > Routing Key(RK1) and a request to modify the routing > key(RK1) from ASP1 modifies the key then in that case how do the > other ASPs know of the change in Routing Key. > Should not the other ASP which had registered the same routing > key be informed about the change. How do we do that? > > Regards > Amrita Garg > > > > > > > _______________________________________________ > 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 Nov 16 13:20:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRtH-0004jU-C4; Wed, 16 Nov 2005 13:20:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRtF-0004jB-Jt for sigtran@megatron.ietf.org; Wed, 16 Nov 2005 13:20:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14958 for ; Wed, 16 Nov 2005 13:19:36 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[ZQyFfmcdUgTOg1LrngUx1jvG5L9prmtx]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcSAd-0003BT-1V for sigtran@ietf.org; Wed, 16 Nov 2005 13:38:15 -0500 Received: from ns.pigworks.openss7.net (IDENT:Wt4P1zBKOz0UWSRql5/G8TfKelD767Qg@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAGIK3A05134; Wed, 16 Nov 2005 11:20:03 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAGIK2S00605; Wed, 16 Nov 2005 11:20:02 -0700 Date: Wed, 16 Nov 2005 11:20:02 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] RE: Sigtran [SUA] : Modification of Routing Key Message-ID: <20051116112002.A447@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, Nov 16, 2005 at 10:16:00AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, Tolga Asveren wrote: (Wed, 16 Nov 2005 10:16:00) --X--snip--X-- > [TOLGA]I also think that it is a realistic assumption to expect ASPs to have > some kind of coordination between them regarding the traffic range change > for a RK. --X--snip--X-- Oh, so now they are coordinated, when for the n+k discussiion they were not... ;) It is reasonable to assume that ASPs serving the same AS must be tightly coupled and highly coordinated. After all, to perform their function correctly, they must share circuit or transaction state. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 16 23:36:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcbVt-0006Nu-V0; Wed, 16 Nov 2005 23:36:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcbVs-0006Np-IX for sigtran@megatron.ietf.org; Wed, 16 Nov 2005 23:36:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26354 for ; Wed, 16 Nov 2005 23:36:10 -0500 (EST) From: partha.dey@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcbnJ-00016S-QC for sigtran@ietf.org; Wed, 16 Nov 2005 23:54:54 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 336FA205E4 for ; Thu, 17 Nov 2005 09:53:26 +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 16F80205DC for ; Thu, 17 Nov 2005 09:53:26 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 10:06:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Nov 2005 10:04:52 +0530 Message-ID: <5A521CAA914BAF47A48A726DE83E7D24017D0305@blr-k1-msg.wipro.com> Thread-Topic: Query on Braodcasting at the relay node Thread-Index: AcXrKiITW3i5xNj6RtenzO0w69JznAABeltA To: X-OriginalArrivalTime: 17 Nov 2005 04:36:21.0242 (UTC) FILETIME=[75833DA0:01C5EB30] X-Spam-Score: 0.5 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [Sigtran] Query on Braodcasting at the relay node 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="===============1252613529==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1252613529== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EB30.74F661F0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EB30.74F661F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, In a particular scenario in which a relay node is receiving a CORE message, is the relay node required to Broadcast the message if the THM is set to broadcast ? =20 =20 Does broadcasting takes place at the originator node only or at the relay nodes also ?? =20 Regards, Partha. =20 =20 ------_=_NextPart_001_01C5EB30.74F661F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Brian,

In a particular scenario = in which a=20 relay node is receiving a CORE message, is the relay node required to = Broadcast=20 the message if the THM is set to broadcast = ?

 

 

Does broadcasting takes = place at the=20 originator node only or at the relay nodes also = ??

 

Regards,

Partha.          &nb= sp;         =20

 

------_=_NextPart_001_01C5EB30.74F661F0-- --===============1252613529== 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 --===============1252613529==-- From sigtran-bounces@ietf.org Thu Nov 17 05:00:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcgZA-0006UB-Bu; Thu, 17 Nov 2005 05:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcgZ7-0006U1-0n for sigtran@megatron.ietf.org; Thu, 17 Nov 2005 05:00:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10623 for ; Thu, 17 Nov 2005 04:59:51 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[JoNM6MvueZYTpZuQNnwY/fxIx6rSCY3l]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecgqg-0002lX-6U for sigtran@ietf.org; Thu, 17 Nov 2005 05:18:37 -0500 Received: from ns.pigworks.openss7.net (IDENT:DartH6utLeUtdf/naCT5dautN2qZ4TZ3@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAHA0JA25872; Thu, 17 Nov 2005 03:00:19 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAHA0IW09151; Thu, 17 Nov 2005 03:00:18 -0700 Date: Thu, 17 Nov 2005 03:00:17 -0700 From: "Brian F. G. Bidulock" To: partha.dey@wipro.com Subject: Re: [Sigtran] Query on Braodcasting at the relay node Message-ID: <20051117030017.B9039@openss7.org> Mail-Followup-To: partha.dey@wipro.com, sigtran@ietf.org References: <5A521CAA914BAF47A48A726DE83E7D24017D0305@blr-k1-msg.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5A521CAA914BAF47A48A726DE83E7D24017D0305@blr-k1-msg.wipro.com>; from partha.dey@wipro.com on Thu, Nov 17, 2005 at 10:04:52AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org partha.dey, Broadcast is a Traffic Mode: it occurs wherever the Traffic Mode occurs, just like any other traffic mode. --brian partha.dey@wipro.com wrote: (Thu, 17 Nov 2005 10:04:52) > > Hi Brian, > > In a particular scenario in which a relay node is receiving a CORE > message, is the relay node required to Broadcast the message if the > THM is set to broadcast ? > > > > Does broadcasting takes place at the originator node only or at the > relay nodes also ?? > > > Regards, > > Partha. > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Nov 17 06:47:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EciEZ-0000SZ-8p; Thu, 17 Nov 2005 06:47:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EciEX-0000SU-4X for sigtran@megatron.ietf.org; Thu, 17 Nov 2005 06:47:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16576 for ; Thu, 17 Nov 2005 06:46:42 -0500 (EST) From: khaja.sheriff@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EciVg-0006RT-MX for Sigtran@ietf.org; Thu, 17 Nov 2005 07:05:30 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id B8DA52061F for ; Thu, 17 Nov 2005 17:03:05 +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 9A6E0205FD for ; Thu, 17 Nov 2005 17:03:05 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 17:16:01 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Nov 2005 17:15:27 +0530 Message-ID: <897DA809E857CD40A8419CF517948E2101543B06@blr-k1-msg.wipro.com> X-MS-Has-Attach: yes Thread-Topic: SUA No. of Affectde Point Codes in SCON Message Thread-Index: AcXrbGcsVWO5BkABRBO4khTi0SkHMg== To: X-OriginalArrivalTime: 17 Nov 2005 11:46:01.0064 (UTC) FILETIME=[7B7BE680:01C5EB6C] X-Spam-Score: 1.1 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Subject: [Sigtran] SUA No. of Affectde Point Codes in SCON Message X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1239076328==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1239076328== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C5EB6C.6772D4CC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EB6C.6772D4CC Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5EB6C.6772D4CC" ------_=_NextPart_002_01C5EB6C.6772D4CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi ,=20 In RFC 3868, the structure of the SCON message indicates that there could be a list of Affected Point Codes , but only one congestion level value. Is it possible for the SCON message to have many PCs having same level of congestion ? If different PCs are having different congestion levels, do we need to send an SCON for each congested Point code . =20 Khaja Sheriff ------_=_NextPart_002_01C5EB6C.6772D4CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Glacier

Hi ,

In RFC 3868, the structure of the = SCON=20 message  indicates that there could be a list of Affected Point = Codes , but=20 only one congestion level value.

Is it possible for the SCON message = to have=20 many PCs having same level of congestion ?

 If different PCs are having = different=20 congestion levels, do we need to send an SCON for each congested Point = code=20 .

 

Khaja = Sheriff

------_=_NextPart_002_01C5EB6C.6772D4CC-- ------_=_NextPart_001_01C5EB6C.6772D4CC Content-Type: image/jpeg; name="Glacier Bkgrd.jpg" Content-Transfer-Encoding: base64 Content-ID: <910213310@17112005-056C> Content-Description: Glacier Bkgrd.jpg Content-Location: Glacier%20Bkgrd.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7QSqUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgAAwAAAEgA SAAAAAAC2gIo/+H/4QL5AkUDRwUoA/wAAgAAAEgASAAAAAAC2AIoAAEAAABkAAAAAQADAwMAAAAB Jw8AAQABAAAAAAAAAAAAAAAAYAgAGQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAA AAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEA L2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklN A/gAAAAAAHAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////// //8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAAC QAAAAAA4QklNBAkAAAAAApkAAAABAAAAgAAAAAEAAAGAAAABgAAAAn0AGAAB/9j/4AAQSkZJRgAB AgEASABIAAD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAAEAgAMBIgACEQEDEQH/3QAEAAj/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APTqPon4/wAAir5X SQGyn6oSXyukip+qEl8rpJKfqhJfK6SSn6oSXyukkp+qEl8rpJKfqhJfK6SSn6oSXyukkp//2QA4 QklNBAYAAAAAAAcABAAAAAEBAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGQAAAAAAf/bAIQABgQEBwUHCwYGCw4KCAoOEQ4ODg4RFhMTExMTFhEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAEHCQkTDBMiExMiFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAAwZAAwERAAIRAQMR Af/dAAQAyP/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPB UtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE 1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEy obHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp 0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo +DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A9N/vv+Lv+SWFhv5/7F37 7/i7/kliu/n/ALFbJ63H/dv0+lTFd/P/AGKj++/y/wDkliu/n/sVa29Tl8fSn7fCn/JPfFIRH/AY GTv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Bi rv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/w GKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3 /AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd /wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFX f8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gM Vd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+ AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8A gMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/ 4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq 7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wAB irv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Bi rv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/w GKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3 /AYq/wD/2Q== ------_=_NextPart_001_01C5EB6C.6772D4CC-- --===============1239076328== 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 --===============1239076328==-- From sigtran-bounces@ietf.org Thu Nov 17 06:54:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EciLG-0002ZQ-7r; Thu, 17 Nov 2005 06:54:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EciLE-0002ZL-ER for sigtran@megatron.ietf.org; Thu, 17 Nov 2005 06:54:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16985 for ; Thu, 17 Nov 2005 06:53:38 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[V25PGcPKea0B+Y6qeMi7ZccEDm5k5BsC]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecicq-0006i5-Oh for Sigtran@ietf.org; Thu, 17 Nov 2005 07:12:26 -0500 Received: from ns.pigworks.openss7.net (IDENT:KGFIXS0Si6j/9Y/dt+/HW1ir/KXx6jeX@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAHBs9A31329; Thu, 17 Nov 2005 04:54:09 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAHBs9r12018; Thu, 17 Nov 2005 04:54:09 -0700 Date: Thu, 17 Nov 2005 04:54:09 -0700 From: "Brian F. G. Bidulock" To: khaja.sheriff@wipro.com Subject: Re: [Sigtran] SUA No. of Affectde Point Codes in SCON Message Message-ID: <20051117045409.A12003@openss7.org> Mail-Followup-To: khaja.sheriff@wipro.com, Sigtran@ietf.org References: <897DA809E857CD40A8419CF517948E2101543B06@blr-k1-msg.wipro.com> 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: <897DA809E857CD40A8419CF517948E2101543B06@blr-k1-msg.wipro.com>; from khaja.sheriff@wipro.com on Thu, Nov 17, 2005 at 05:15:27PM +0530 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 jAHBs9A31329 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: Sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org khaja.sheriff, On Thu, 17 Nov 2005, khaja.sheriff@wipro.com wrote: >=20 > Hi , >=20 > In RFC 3868, the structure of the SCON message indicates that the= re > could be a list of Affected Point Codes , but only one congesti= on > level value. Yes. >=20 > Is it possible for the SCON message to have many PCs having same lev= el > of congestion ? Yes. >=20 > If different PCs are having different congestion levels, do we ne= ed > to send an SCON for each congested Point code . Yes. --=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 Thu Nov 17 23:53:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcyFJ-0000Ib-1w; Thu, 17 Nov 2005 23:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcyFH-0000IW-VR for sigtran@megatron.ietf.org; Thu, 17 Nov 2005 23:53:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20894 for ; Thu, 17 Nov 2005 23:52:33 -0500 (EST) From: srivastava.rishi@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcyWx-0000Qg-44 for sigtran@ietf.org; Fri, 18 Nov 2005 00:11:30 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 60C7520616 for ; Fri, 18 Nov 2005 10:09:48 +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 41ADE2060D for ; Fri, 18 Nov 2005 10:09:48 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Nov 2005 10:22:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Nov 2005 10:21:53 +0530 Message-ID: <897DA809E857CD40A8419CF517948E2101543B8E@blr-k1-msg.wipro.com> Thread-Topic: Segmentation in CODT message Thread-Index: AcXr+8t9hIu8Qp24RIqbYsAYvmAnwQ== To: X-OriginalArrivalTime: 18 Nov 2005 04:52:44.0761 (UTC) FILETIME=[EA261490:01C5EBFB] X-Spam-Score: 0.4 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [Sigtran] Segmentation in CODT message X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2098485757==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============2098485757== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EBFB.CBA88498" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EBFB.CBA88498 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 Is Segmentation is applicable only for CLDT (Connection less ) messages ? Connection Oriented message can not be segmented ? as in RFC 3868 there is no parameter in CO message which includes segmentation parameters.=20 =20 Thanks Rishi Srivastava=20 ------_=_NextPart_001_01C5EBFB.CBA88498 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Is Segmentation is applicable only for CLDT = (Connection less ) messages ?  Connection Oriented message can not be segmented = ?  as in RFC 3868 there is no parameter in CO message which includes segmentation parameters.

 

Thanks

Rishi Srivastava

------_=_NextPart_001_01C5EBFB.CBA88498-- --===============2098485757== 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 --===============2098485757==-- From sigtran-bounces@ietf.org Fri Nov 18 00:58:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EczGt-0006uy-1F; Fri, 18 Nov 2005 00:58:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EczGr-0006sz-Tv for sigtran@megatron.ietf.org; Fri, 18 Nov 2005 00:58:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23716 for ; Fri, 18 Nov 2005 00:58:15 -0500 (EST) From: rafiq.singh@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EczYS-00028T-NJ for sigtran@ietf.org; Fri, 18 Nov 2005 01:17:13 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 940F62061B for ; Fri, 18 Nov 2005 11:15:24 +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 7783E2060D for ; Fri, 18 Nov 2005 11:15:24 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Nov 2005 11:28:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Nov 2005 11:28:20 +0530 Message-ID: <897DA809E857CD40A8419CF517948E2101543BC9@blr-k1-msg.wipro.com> Thread-Topic: Query on ASP capabilties tag in SUA Thread-Index: AcXsBRPYOxVBr/y1Tj6BAS8Hn7I5zQ== To: X-OriginalArrivalTime: 18 Nov 2005 05:58:21.0048 (UTC) FILETIME=[145BCF80:01C5EC05] X-Spam-Score: 0.5 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Subject: [Sigtran] Query on ASP capabilties tag in SUA X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0859006874==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0859006874== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EC05.14192EB0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EC05.14192EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I have a query regarding the ASP capabilities tag in the in Registration Request message. How do we use the interworking field in the tag. Can the interworking field be used to make the SUA behave as a relay node. If that is the case how do we make SUA behave as a relay node, if we do static configuration of routing keys(i.e. no registration request is sent). =20 Regards Rafiq Singh Project Engineer Voice and Next Generation Networks Wipro Technologies Mobile: +91-9342530455 =20 =20 =20 ------_=_NextPart_001_01C5EC05.14192EB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

I have a query regarding the ASP capabilities tag in = the in Registration Request message.

How do we use the interworking field in the = tag.

Can the interworking field be used to make the SUA = behave as a relay node.

If that is the case how do we make SUA behave as a = relay node, if we  do static configuration of routing keys(i.e. no = registration request is sent).

 

Regards

Rafiq Singh

Project = Engineer

Voice and Next Generation = Networks

Wipro = Technologies

Mobile: +91-9342530455

 

   = ;            =     

 

------_=_NextPart_001_01C5EC05.14192EB0-- --===============0859006874== 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 --===============0859006874==-- From sigtran-bounces@ietf.org Fri Nov 18 04:52:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed2uk-00032Y-C3; Fri, 18 Nov 2005 04:52:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed2uj-00032T-3a for sigtran@megatron.ietf.org; Fri, 18 Nov 2005 04:52:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05064 for ; Fri, 18 Nov 2005 04:51:39 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[+5i8MnkCNsxrarQ3wNPJ478a4ZCLRgW2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3CW-0000vs-Ub for sigtran@ietf.org; Fri, 18 Nov 2005 05:10:38 -0500 Received: from ns.pigworks.openss7.net (IDENT:t0Jkac+5R1MJs4w1WZ1nuTZtR3UiQQ/j@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAI9q9A21138; Fri, 18 Nov 2005 02:52:09 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAI9q9928800; Fri, 18 Nov 2005 02:52:09 -0700 Date: Fri, 18 Nov 2005 02:52:09 -0700 From: "Brian F. G. Bidulock" To: srivastava.rishi@wipro.com Subject: Re: [Sigtran] Segmentation in CODT message Message-ID: <20051118025209.A28650@openss7.org> Mail-Followup-To: srivastava.rishi@wipro.com, sigtran@ietf.org References: <897DA809E857CD40A8419CF517948E2101543B8E@blr-k1-msg.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <897DA809E857CD40A8419CF517948E2101543B8E@blr-k1-msg.wipro.com>; from srivastava.rishi@wipro.com on Fri, Nov 18, 2005 at 10:21:53AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org srivastava.rishi, There is a sequence number and "more" indicator in the CODT message. --brian srivastava.rishi@wipro.com wrote: (Fri, 18 Nov 2005 10:21:53) > > Hi, > > > Is Segmentation is applicable only for CLDT (Connection less ) > messages ? Connection Oriented message can not be segmented ? as in > RFC 3868 there is no parameter in CO message which includes > segmentation parameters. > > > Thanks > > Rishi Srivastava > _______________________________________________ > 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 Nov 18 04:58:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed30P-0006VT-9l; Fri, 18 Nov 2005 04:58:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed30N-0006VO-IM for sigtran@megatron.ietf.org; Fri, 18 Nov 2005 04:58:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05324 for ; Fri, 18 Nov 2005 04:57:29 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[cJ18JpKfdZhMvcvq0Zg98pV/RzwcNC3B]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3IC-000177-Ee for sigtran@ietf.org; Fri, 18 Nov 2005 05:16:28 -0500 Received: from ns.pigworks.openss7.net (IDENT:70xBhV/Dmmk93Rty07PZU1q0vu7Al1xl@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAI9w2A21217; Fri, 18 Nov 2005 02:58:02 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAI9w1f28835; Fri, 18 Nov 2005 02:58:01 -0700 Date: Fri, 18 Nov 2005 02:58:01 -0700 From: "Brian F. G. Bidulock" To: rafiq.singh@wipro.com Subject: Re: [Sigtran] Query on ASP capabilties tag in SUA Message-ID: <20051118025801.B28650@openss7.org> Mail-Followup-To: rafiq.singh@wipro.com, sigtran@ietf.org References: <897DA809E857CD40A8419CF517948E2101543BC9@blr-k1-msg.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <897DA809E857CD40A8419CF517948E2101543BC9@blr-k1-msg.wipro.com>; from rafiq.singh@wipro.com on Fri, Nov 18, 2005 at 11:28:20AM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org rafiq.singh, rafiq.singh@wipro.com wrote: (Fri, 18 Nov 2005 11:28:20) > > Hi > > > I have a query regarding the ASP capabilities tag in the in > Registration Request message. > > How do we use the interworking field in the tag. > > Can the interworking field be used to make the SUA behave as a relay > node. No, it is used to report whether the ASP is behaving as a relay node. > > If that is the case how do we make SUA behave as a relay node, if we > do static configuration of routing keys(i.e. no registration request > is sent). If you do static configuration, and the SG requires knowledge of the ASP capabilities, they will have to be provisioned with the Routing Key. --brian > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 21 04:18:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee7oh-0004sV-AG; Mon, 21 Nov 2005 04:18:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee7og-0004rC-Am for sigtran@megatron.ietf.org; Mon, 21 Nov 2005 04:18:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15438 for ; Mon, 21 Nov 2005 04:17:49 -0500 (EST) Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee875-0004XR-LW for sigtran@ietf.org; Mon, 21 Nov 2005 04:37:28 -0500 Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id AD08934715A for ; Mon, 21 Nov 2005 01:18:15 -0800 (PST) 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="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2005 01:18:13 -0800 Message-ID: Thread-Topic: Query: IPSP-SE definition Thread-Index: AcXufH6nxI90IpdPQ6updJRdHlhetw== From: "Soni Goel" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Subject: [Sigtran] Query: IPSP-SE definition X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi, I have been following the IPSP-SE definition thread. As per the last = mail from Ken the sigtran team will be working on draft(s) for SE-IPSP = model and a SG-SG draft. In the meantime, is there any consensus reached regarding the IPSP-SE = definition?=20 If yes, can you please let me know which of the following definitions = are correct for IPSP-SE mode - 1) In IPSP-SE model, the IPSP sending ASPAC acts as an ASP. The IPSP = receiving ASPAC acts as an SGP.=20 When acting like an SGP, the peer IPSP can distribute traffic in = accordance with the way that an ASP distributes messages to the SGP that = make up an SG. The SE-IPSP acting in SGP mode does not require an "ASP = Traffic Mode". OR, 2) SE-IPSP is an IPSP not an ASP and not an SGP. So, the traffic mode is = required to be exchanged both ways. So if IPSP1 sends ASPAC message and = IPSP2 replies with ASPAC-Ack message. IPSP2 can update IPSP1 about the = traffic mode (in ASPAC-Ack message) to be used for message distribution = towards IPSP2. This will enable both IPSP1 and IPSP2 to use same = override/loadshare mode towards eahc other, OR, both IPSP1 and IPSP2 can = use different modes. Thanks, Soni --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 =20 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 21 05:56:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee9LQ-0003zD-PF; Mon, 21 Nov 2005 05:56:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee9LP-0003z8-KC for sigtran@megatron.ietf.org; Mon, 21 Nov 2005 05:56:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20679 for ; Mon, 21 Nov 2005 05:55:41 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[yBwoy5Szev0fkUXIZ+ZqkbAFTXeHOlbd]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee9dp-000745-HC for sigtran@ietf.org; Mon, 21 Nov 2005 06:15:23 -0500 Received: from ns.pigworks.openss7.net (IDENT:Ko8E+QVtYVzaTX/8ZlE7r0KpuRrM+pif@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jALAu5A27945; Mon, 21 Nov 2005 03:56:05 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jALAu5m30218; Mon, 21 Nov 2005 03:56:05 -0700 Date: Mon, 21 Nov 2005 03:56:05 -0700 From: "Brian F. G. Bidulock" To: Soni Goel Subject: Re: [Sigtran] Query: IPSP-SE definition Message-ID: <20051121035604.A30130@openss7.org> Mail-Followup-To: Soni Goel , 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 soni@ccpu.com on Mon, Nov 21, 2005 at 01:18:13AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: 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: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Soni, Soni Goel wrote: (Mon, 21 Nov 2005 01:18:13) > Hi, > > I have been following the IPSP-SE definition thread. As per the last > mail from Ken the sigtran team will be working on draft(s) for SE-IPSP > model and a SG-SG draft. > > In the meantime, is there any consensus reached regarding the IPSP-SE > definition? No, I don't think that there was any concensus. > > If yes, can you please let me know which of the following definitions > are correct for IPSP-SE mode - The matter is rather moot because the TM in the ASP Active Ack is just the same value that was present in the ASP Active. As it stands, whichever view you take towards role modeling of IPSPs, the side sending ASP Active can inform the other about its intended traffic mode, but any traffic distribution method in the other direction will have to be provisioned. It don't think that is such a great limitation: in a real world engineered network I would expect that traffic mode (or distribution method, if you prefer) would be provisioned on both sides. --brian > > 1) In IPSP-SE model, the IPSP sending ASPAC acts as an ASP. The IPSP > receiving ASPAC acts as an SGP. When acting like an SGP, the peer > IPSP can distribute traffic in accordance with the way that an ASP > distributes messages to the SGP that make up an SG. The SE-IPSP > acting in SGP mode does not require an "ASP Traffic Mode". > > OR, > > 2) SE-IPSP is an IPSP not an ASP and not an SGP. So, the traffic mode > is required to be exchanged both ways. So if IPSP1 sends ASPAC message > and IPSP2 replies with ASPAC-Ack message. IPSP2 can update IPSP1 about > the traffic mode (in ASPAC-Ack message) to be used for message > distribution towards IPSP2. This will enable both IPSP1 and IPSP2 to > use same override/loadshare mode towards eahc other, OR, both IPSP1 > and IPSP2 can use different modes. > > Thanks, > Soni > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 22 01:47:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeRwH-0006MI-2l; Tue, 22 Nov 2005 01:47:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeRsa-0005nA-A8 for sigtran@megatron.ietf.org; Tue, 22 Nov 2005 01:43:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06408 for ; Tue, 22 Nov 2005 01:39:30 -0500 (EST) From: khaja.sheriff@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeRGz-0002pD-L8 for Sigtran@ietf.org; Tue, 22 Nov 2005 01:05:05 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id DFD9820623 for ; Tue, 22 Nov 2005 11:02:05 +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 C1EAC2061E for ; Tue, 22 Nov 2005 11:02:05 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Nov 2005 11:15:08 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Nov 2005 11:15:07 +0530 Message-ID: <897DA809E857CD40A8419CF517948E21015AFEF8@blr-k1-msg.wipro.com> X-MS-Has-Attach: yes Thread-Topic: SUA : When to send DUPU messages Thread-Index: AcXvJ+TM/RQkPGtnQq6poAPBCmRn6w== To: X-OriginalArrivalTime: 22 Nov 2005 05:45:08.0149 (UTC) FILETIME=[E5680650:01C5EF27] X-Spam-Score: 0.8 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: [Sigtran] SUA : When to send DUPU messages X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1779832610==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1779832610== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C5EF27.E5205B99" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EF27.E5205B99 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5EF27.E5205B99" ------_=_NextPart_002_01C5EF27.E5205B99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 In RFC 3868, the DUPU messages are being sent when the user part is unavailable. But it seems like that the DUNA messages are being sent to convey that the destination is not reachable . Please clarify under what conditions DUPU message will be sent by the peer. Thanks and Regards Khaja Sheriff=20 =20 ------_=_NextPart_002_01C5EF27.E5205B99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Glacier

Hi,

     In RFC = 3868, the DUPU=20 messages  are being sent when the user part is unavailable. But it = seems=20 like that the DUNA messages are being sent to convey that=20 the destination is not reachable .

Please clarify under what conditions = DUPU=20 message will be sent by the peer.

Thanks and Regards

Khaja Sheriff 

     =20

------_=_NextPart_002_01C5EF27.E5205B99-- ------_=_NextPart_001_01C5EF27.E5205B99 Content-Type: image/jpeg; name="Glacier Bkgrd.jpg" Content-Transfer-Encoding: base64 Content-ID: <928503905@22112005-16DC> Content-Description: Glacier Bkgrd.jpg Content-Location: Glacier%20Bkgrd.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7QSqUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgAAwAAAEgA SAAAAAAC2gIo/+H/4QL5AkUDRwUoA/wAAgAAAEgASAAAAAAC2AIoAAEAAABkAAAAAQADAwMAAAAB Jw8AAQABAAAAAAAAAAAAAAAAYAgAGQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAA AAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEA L2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklN A/gAAAAAAHAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////// //8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAAC QAAAAAA4QklNBAkAAAAAApkAAAABAAAAgAAAAAEAAAGAAAABgAAAAn0AGAAB/9j/4AAQSkZJRgAB AgEASABIAAD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAAEAgAMBIgACEQEDEQH/3QAEAAj/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APTqPon4/wAAir5X SQGyn6oSXyukip+qEl8rpJKfqhJfK6SSn6oSXyukkp+qEl8rpJKfqhJfK6SSn6oSXyukkp//2QA4 QklNBAYAAAAAAAcABAAAAAEBAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGQAAAAAAf/bAIQABgQEBwUHCwYGCw4KCAoOEQ4ODg4RFhMTExMTFhEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAEHCQkTDBMiExMiFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAAwZAAwERAAIRAQMR Af/dAAQAyP/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPB UtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE 1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEy obHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp 0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo +DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A9N/vv+Lv+SWFhv5/7F37 7/i7/kliu/n/ALFbJ63H/dv0+lTFd/P/AGKj++/y/wDkliu/n/sVa29Tl8fSn7fCn/JPfFIRH/AY GTv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Bi rv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/w GKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3 /AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd /wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFX f8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gM Vd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+ AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8A gMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/ 4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq 7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wAB irv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Bi rv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/w GKu/4DFXf8Birv8AgMVd/wABirv+AxV3/AYq7/gMVd/wGKu/4DFXf8Birv8AgMVd/wABirv+AxV3 /AYq/wD/2Q== ------_=_NextPart_001_01C5EF27.E5205B99-- --===============1779832610== 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 --===============1779832610==-- From sigtran-bounces@ietf.org Tue Nov 22 04:25:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeUP9-0001TP-7C; Tue, 22 Nov 2005 04:25:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeUP7-0001TI-Ex for sigtran@megatron.ietf.org; Tue, 22 Nov 2005 04:25:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21801 for ; Tue, 22 Nov 2005 04:24:53 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[jdrHJZvg1FAPvg/9M9VJIrWtHPQ9rPmV]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeUhh-00080h-6J for Sigtran@ietf.org; Tue, 22 Nov 2005 04:44:46 -0500 Received: from ns.pigworks.openss7.net (IDENT:NhQCMpEJUPc1HeS/O7eC2c2huARPptWt@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAM9PNA16630; Tue, 22 Nov 2005 02:25:23 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAM9PMJ10570; Tue, 22 Nov 2005 02:25:22 -0700 Date: Tue, 22 Nov 2005 02:25:22 -0700 From: "Brian F. G. Bidulock" To: khaja.sheriff@wipro.com Subject: Re: [Sigtran] SUA : When to send DUPU messages Message-ID: <20051122022522.A10355@openss7.org> Mail-Followup-To: khaja.sheriff@wipro.com, Sigtran@ietf.org References: <897DA809E857CD40A8419CF517948E21015AFEF8@blr-k1-msg.wipro.com> 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: <897DA809E857CD40A8419CF517948E21015AFEF8@blr-k1-msg.wipro.com>; from khaja.sheriff@wipro.com on Tue, Nov 22, 2005 at 11:15:07AM +0530 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 jAM9PNA16630 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: Sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org khaja.sheriff, On Tue, 22 Nov 2005, khaja.sheriff@wipro.com wrote: >=20 > Hi, >=20 > In RFC 3868, the DUPU messages are being sent when the user pa= rt > is unavailable. But it seems like that the DUNA messages are bei= ng > sent to convey that the destination is not reachable . >=20 > Please clarify under what conditions DUPU message will be sent by t= he > peer. Under these conditions: 0 remote SCCP unavailable, reason unknown; 1 remote SCCP unequipped; 2 remote SCCP inaccessible; --brian >=20 > Thanks and Regards >=20 > Khaja Sheriff > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 22 06:31:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeWNM-0002C6-NA; Tue, 22 Nov 2005 06:31:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeWNK-0002B1-V2 for sigtran@megatron.ietf.org; Tue, 22 Nov 2005 06:31:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05419 for ; Tue, 22 Nov 2005 06:31:08 -0500 (EST) Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeWfs-0005ge-Lz for sigtran@ietf.org; Tue, 22 Nov 2005 06:51:03 -0500 Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id D72D7346988; Tue, 22 Nov 2005 03:31:34 -0800 (PST) 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="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] Query: IPSP-SE definition Date: Tue, 22 Nov 2005 03:31:35 -0800 Message-ID: Thread-Topic: [Sigtran] Query: IPSP-SE definition Thread-Index: AcXuijrUGACe7qtnQFepAVKzkmicbwAy9BgA From: "Soni Goel" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi,=20 In one of the earlier mails , I saw the following configuration being = discussed. I have related query. It is an IPSP-IPSP Single Ended communication. We have AS1 served by = IPSP1. IPSP2 and IPSP3 are in the same Application Server (AS2). Every IPSP is operating in Override traffic = mode, where IPSP1 and IPSP2 are configured to be in the ASP-ACTIVE state and IPSP3 is acting as backup. ________ ________ ________=20 | | | | | | | AS1 | | AS2 | | AS2 | | PC =3D X | | PC =3D Y | | PC =3D Y | |________| |________| |________| | | | =20 ___|____ ___|____ ___|____=20 | | | | | | | IPSP1 | | IPSP2 | | IPSP3 | | IP@1 | | IP@2 | | IP@3 | |Override| |Override| |Override| |(Active)| |(Active)| |(Backup)| |________| |________| |________| | | | =20 |__________________|____________| =20 As per the RFC - "In the case of an Override mode AS, reception of an ASP Active message = at an SGP causes the (re)direction of all traffic for the AS to the ASP = that sent the ASP Active message. Any previously active ASP in the AS = is now considered to be in state ASP-INACTIVE and SHOULD no longer = receive traffic from the SGP within the AS. The SGP or IPSP then MUST = send a Notify message ("Alternate ASP_Active") to the previously active = ASP in the AS, and SHOULD stop traffic to/from that ASP. "" In the following scenario, IPSP1 on receiving ASP Active Ack from IPSP2, = redirects all the traffic to IPSP2 and considers IPSP3 as Inactive. = Isn't this contradicting with the RFC paragraph (stated above)? As per = the RFC, the SGP or IPSP receiving ASP-Active message redirects the = traffic and sends NTFY(Alt ASP-Act), not the IPSP receiving the = ASP-Active Ack.=20 If this is true, then if IPSP1 needs to use Override mode towards AS2 = (consisting of IPSP2 and IPSP3), then ASP-Active messages must be = initiated by IPSP2 and/or IPSP3, not by IPSP1. IPSP1 IPSP2 IPSP3 | | | |-------------------ASP Active----------------->| |<----------------ASP Active Ack----------------| | | | |-------ASP Active------>| | |<------ASP Active Ack---| | | | | |----------------NTFY(Alt ASP-Act)------------> | | | |=20 Thanks, Soni -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]=20 Sent: Monday, November 21, 2005 2:56 AM To: Soni Goel Cc: sigtran@ietf.org Subject: Re: [Sigtran] Query: IPSP-SE definition Soni, Soni Goel wrote: (Mon, 21 Nov 2005 01:18:13) > Hi, >=20 > I have been following the IPSP-SE definition thread. As per the last=20 > mail from Ken the sigtran team will be working on draft(s) for SE-IPSP = > model and a SG-SG draft. >=20 > In the meantime, is there any consensus reached regarding the IPSP-SE=20 > definition? No, I don't think that there was any concensus. >=20 > If yes, can you please let me know which of the following definitions=20 > are correct for IPSP-SE mode - The matter is rather moot because the TM in the ASP Active Ack is just = the same value that was present in the ASP Active. As it stands, = whichever view you take towards role modeling of IPSPs, the side sending = ASP Active can inform the other about its intended traffic mode, but any = traffic distribution method in the other direction will have to be = provisioned. It don't think that is such a great limitation: in a real world = engineered network I would expect that traffic mode (or distribution = method, if you prefer) would be provisioned on both sides. --brian >=20 > 1) In IPSP-SE model, the IPSP sending ASPAC acts as an ASP. The IPSP=20 > receiving ASPAC acts as an SGP. When acting like an SGP, the peer=20 > IPSP can distribute traffic in accordance with the way that an ASP=20 > distributes messages to the SGP that make up an SG. The SE-IPSP=20 > acting in SGP mode does not require an "ASP Traffic Mode". >=20 > OR, >=20 > 2) SE-IPSP is an IPSP not an ASP and not an SGP. So, the traffic mode=20 > is required to be exchanged both ways. So if IPSP1 sends ASPAC message = > and IPSP2 replies with ASPAC-Ack message. IPSP2 can update IPSP1 about = > the traffic mode (in ASPAC-Ack message) to be used for message=20 > distribution towards IPSP2. This will enable both IPSP1 and IPSP2 to=20 > use same override/loadshare mode towards eahc other, OR, both IPSP1=20 > and IPSP2 can use different modes. >=20 > Thanks, > Soni >=20 >=20 > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 > =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/ --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 =20 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 22 06:45:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeWaR-0008IF-0M; Tue, 22 Nov 2005 06:45:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeWaP-0008IA-Rj for sigtran@megatron.ietf.org; Tue, 22 Nov 2005 06:45:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06356 for ; Tue, 22 Nov 2005 06:44:43 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[a7ssEUKQVQfmSUrBJVLj30EHZQW/8geW]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeWt1-0006Fa-MC for sigtran@ietf.org; Tue, 22 Nov 2005 07:04:38 -0500 Received: from ns.pigworks.openss7.net (IDENT:o1TGIkPZuNSQSe7xKBaH2oYTUoIVlr7/@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAMBj5A19454; Tue, 22 Nov 2005 04:45:05 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAMBj4p20326; Tue, 22 Nov 2005 04:45:04 -0700 Date: Tue, 22 Nov 2005 04:45:04 -0700 From: "Brian F. G. Bidulock" To: Soni Goel Subject: Re: [Sigtran] Query: IPSP-SE definition Message-ID: <20051122044504.A20244@openss7.org> Mail-Followup-To: Soni Goel , 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 soni@ccpu.com on Tue, Nov 22, 2005 at 03:31:35AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Soni, Soni Goel wrote: (Tue, 22 Nov 2005 03:31:35) > Hi, > > In one of the earlier mails , I saw the following configuration being > discussed. I have related query. > > It is an IPSP-IPSP Single Ended communication. We have AS1 served by > IPSP1. IPSP2 and IPSP3 are in the same Application Server (AS2). Every > IPSP is operating in Override traffic mode, where IPSP1 and IPSP2 are > configured to be in the ASP-ACTIVE state and IPSP3 is acting as > backup. > > ________ ________ ________ > | | | | | | > | AS1 | | AS2 | | AS2 | > | PC = X | | PC = Y | | PC = Y | > |________| |________| |________| > | | | > ___|____ ___|____ ___|____ > | | | | | | > | IPSP1 | | IPSP2 | | IPSP3 | > | IP@1 | | IP@2 | | IP@3 | > |Override| |Override| |Override| > |(Active)| |(Active)| |(Backup)| > |________| |________| |________| > | | | > |__________________|____________| > > As per the RFC - > "In the case of an Override mode AS, reception of an ASP Active > message at an SGP causes the (re)direction of all traffic for the AS > to the ASP that sent the ASP Active message. Any previously active > ASP in the AS is now considered to be in state ASP-INACTIVE and SHOULD > no longer receive traffic from the SGP within the AS. The SGP or > IPSP then MUST send a Notify message ("Alternate ASP_Active") to the > previously active ASP in the AS, and SHOULD stop traffic to/from that > ASP. "" > > In the following scenario, IPSP1 on receiving ASP Active Ack from > IPSP2, redirects all the traffic to IPSP2 and considers IPSP3 as > Inactive. Isn't this contradicting with the RFC paragraph (stated > above)? As per the RFC, the SGP or IPSP receiving ASP-Active message > redirects the traffic and sends NTFY(Alt ASP-Act), not the IPSP > receiving the ASP-Active Ack. If this is true, then if IPSP1 needs to > use Override mode towards AS2 (consisting of IPSP2 and IPSP3), then > ASP-Active messages must be initiated by IPSP2 and/or IPSP3, not by > IPSP1. No, you should follow the RFC as above. Let me make one change to your diagram: IPSP1 IPSP2 IPSP3 | | | |-------------------ASP Active----------------->| |<----------------ASP Active Ack----------------| | | | |-------ASP Active------>| | |<------ERR[Mgmt Blking]-| | | | | | | | A standby IPSP need not accept an ASP Active from an IPSP. --brian > > IPSP1 IPSP2 IPSP3 > | | | > |-------------------ASP Active----------------->| > |<----------------ASP Active Ack----------------| > | | | > |-------ASP Active------>| | > |<------ASP Active Ack---| | > | | | > |----------------NTFY(Alt ASP-Act)------------> | > | | | > > > Thanks, > Soni > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 22 08:27:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYBV-00074r-Hf; Tue, 22 Nov 2005 08:27:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYBT-00074m-4R for sigtran@megatron.ietf.org; Tue, 22 Nov 2005 08:27:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16712 for ; Tue, 22 Nov 2005 08:27:03 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeYU2-00033X-4s for sigtran@ietf.org; Tue, 22 Nov 2005 08:47:00 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jAMDRDg0020063 for ; Tue, 22 Nov 2005 08:27:15 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] Query: IPSP-SE definition Date: Tue, 22 Nov 2005 08:09:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Soni, It is obvious that certain clarifications are necessary for the existing text in the document regarding IPSP, but still please see below for my 2 cents about how it is supposed to work. Thanks, Tolga > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Soni Goel > Sent: Tuesday, November 22, 2005 6:32 AM > To: bidulock@openss7.org > Cc: sigtran@ietf.org > Subject: RE: [Sigtran] Query: IPSP-SE definition > > > Hi, > > In one of the earlier mails , I saw the following configuration > being discussed. I have related query. > > It is an IPSP-IPSP Single Ended communication. We have AS1 served > by IPSP1. IPSP2 and IPSP3 are in the same > Application Server (AS2). Every IPSP is operating in Override > traffic mode, where IPSP1 and IPSP2 are > configured to be in the ASP-ACTIVE state and IPSP3 is acting as backup. > > ________ ________ ________ > | | | | | | > | AS1 | | AS2 | | AS2 | > | PC = X | | PC = Y | | PC = Y | > |________| |________| |________| > | | | > ___|____ ___|____ ___|____ > | | | | | | > | IPSP1 | | IPSP2 | | IPSP3 | > | IP@1 | | IP@2 | | IP@3 | > |Override| |Override| |Override| > |(Active)| |(Active)| |(Backup)| > |________| |________| |________| > | | | > |__________________|____________| > > As per the RFC - > "In the case of an Override mode AS, reception of an ASP Active > message at an SGP causes the (re)direction of all traffic for the > AS to the ASP that sent the ASP Active message. Any previously > active ASP in the AS is now considered to be in state > ASP-INACTIVE and SHOULD no longer receive traffic from the SGP > within the AS. The SGP or IPSP then MUST send a Notify message > ("Alternate ASP_Active") to the previously active ASP in the AS, > and SHOULD stop traffic to/from that ASP. "" > > In the following scenario, IPSP1 on receiving ASP Active Ack from > IPSP2, redirects all the traffic to IPSP2 and considers IPSP3 as > Inactive. Isn't this contradicting with the RFC paragraph (stated > above)? As per the RFC, the SGP or IPSP receiving ASP-Active > message redirects the traffic and sends NTFY(Alt ASP-Act), not > the IPSP receiving the ASP-Active Ack. > If this is true, then if IPSP1 needs to use Override mode towards > AS2 (consisting of IPSP2 and IPSP3), then ASP-Active messages > must be initiated by IPSP2 and/or IPSP3, not by IPSP1. [TOLGA]If you interprete the current text literally, I agree with you that is not very clear. OTOH, I don't see something conceptually wrong. The key point is that for SE-IPSP mode of operation AS defines traffic at both ends, it is not a cleint-server model like SGP/ASP communication. For that reason, ASPAC and ASPAC-ACK usually have the same semantics from SE-IPSP processing point of view. > > IPSP1 IPSP2 IPSP3 > | | | > |-------------------ASP Active----------------->| > |<----------------ASP Active Ack----------------| > | | | > |-------ASP Active------>| | > |<------ASP Active Ack---| | > | | | > |----------------NTFY(Alt ASP-Act)------------> | > | | | > > > Thanks, > Soni > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, November 21, 2005 2:56 AM > To: Soni Goel > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Query: IPSP-SE definition > > > Soni, > > Soni Goel wrote: (Mon, 21 Nov 2005 01:18:13) > > Hi, > > > > I have been following the IPSP-SE definition thread. As per the last > > mail from Ken the sigtran team will be working on draft(s) for SE-IPSP > > model and a SG-SG draft. > > > > In the meantime, is there any consensus reached regarding the IPSP-SE > > definition? > > No, I don't think that there was any concensus. > > > > > If yes, can you please let me know which of the following definitions > > are correct for IPSP-SE mode - > > The matter is rather moot because the TM in the ASP Active Ack is > just the same value that was present in the ASP Active. As it > stands, whichever view you take towards role modeling of IPSPs, > the side sending ASP Active can inform the other about its > intended traffic mode, but any traffic distribution method in the > other direction will have to be provisioned. > > It don't think that is such a great limitation: in a real world > engineered network I would expect that traffic mode (or > distribution method, if you prefer) would be provisioned on both sides. > > --brian > > > > > 1) In IPSP-SE model, the IPSP sending ASPAC acts as an ASP. The IPSP > > receiving ASPAC acts as an SGP. When acting like an SGP, the peer > > IPSP can distribute traffic in accordance with the way that an ASP > > distributes messages to the SGP that make up an SG. The SE-IPSP > > acting in SGP mode does not require an "ASP Traffic Mode". > > > > OR, > > > > 2) SE-IPSP is an IPSP not an ASP and not an SGP. So, the traffic mode > > is required to be exchanged both ways. So if IPSP1 sends ASPAC message > > and IPSP2 replies with ASPAC-Ack message. IPSP2 can update IPSP1 about > > the traffic mode (in ASPAC-Ack message) to be used for message > > distribution towards IPSP2. This will enable both IPSP1 and IPSP2 to > > use same override/loadshare mode towards eahc other, OR, both IPSP1 > > and IPSP2 can use different modes. > > > > Thanks, > > Soni > > > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005 > > > _______________________________________________ > 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 Nov 22 08:36:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYJy-0001Ji-Mq; Tue, 22 Nov 2005 08:36:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYJx-0001Jb-MZ for sigtran@megatron.ietf.org; Tue, 22 Nov 2005 08:36:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17599 for ; Tue, 22 Nov 2005 08:35:50 -0500 (EST) Received: from web53805.mail.yahoo.com ([206.190.36.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeYcX-0003Un-IM for sigtran@ietf.org; Tue, 22 Nov 2005 08:55:47 -0500 Received: (qmail 28115 invoked by uid 60001); 22 Nov 2005 13:36:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=O0McBxkhTVsbHeZQHMIKZzevEqT+tyoCJz+WQcBhZTvwPgSvl2EqUyFYLjPi/7T48itg6265YQskXRsCtn/CJx0gUJsWSebXrkM6DxzNxIE1SDzg7Nwb4ZBwdQ5EJqKrBlt31IVHpWrnh0vswjjJQryoSBIWln9tdeTUXaRV9Xc= ; Message-ID: <20051122133615.28113.qmail@web53805.mail.yahoo.com> Received: from [220.227.128.163] by web53805.mail.yahoo.com via HTTP; Tue, 22 Nov 2005 05:36:15 PST Date: Tue, 22 Nov 2005 05:36:15 -0800 (PST) From: Saraswati Bose Subject: [SIGTRAN]: Clarification on traffic modes To: sigtran , bidulock@openss7.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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="===============1179840950==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============1179840950== Content-Type: multipart/alternative; boundary="0-260727086-1132666575=:26267" Content-Transfer-Encoding: 8bit --0-260727086-1132666575=:26267 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, 1. Is 1. Is it correct that traffic mode is defined for an AS only? If yes then can we say that same ASP serving in more than one AS will operate as per Traffic mode defined for the AS? 2. For override traffic mode only one ASP can stay in ACTIVE state at one time. If yes then can we say that the redundant model defined for an override AS is always 1+k? 3. Is 4. How does load share traffic and broadcast traffic differ from each other for redundancy model 2+1? Regards, Saraswati --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click. --0-260727086-1132666575=:26267 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
1.     
Is    1. Is it correct that traffic mode is defined for an AS only? If yes then can we say that same ASP serving in more than one AS will operate as per Traffic mode defined for the AS?
 
 2.      For override traffic mode only one ASP can stay in ACTIVE state at one time. If yes then can we say that the redundant model defined for an override AS is always 1+k?
 
3.        
 Is  4.       How does load share traffic and broadcast traffic differ from each other for  redundancy model 2+1?
 
Regards,
Saraswati

Yahoo! FareChase - Search multiple travel sites in one click. --0-260727086-1132666575=:26267-- --===============1179840950== 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 --===============1179840950==-- From sigtran-bounces@ietf.org Tue Nov 22 14:14:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedbN-0007Ay-C5; Tue, 22 Nov 2005 14:14:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedVj-0006Fv-Sm for sigtran@megatron.ietf.org; Tue, 22 Nov 2005 14:08:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26924 for ; Tue, 22 Nov 2005 14:08:17 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[7B9Hg5JtGzipbCjHzAmLfgORzY4Pnypo]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EedZY-0004fR-Mh for sigtran@ietf.org; Tue, 22 Nov 2005 14:12:58 -0500 Received: from ns.pigworks.openss7.net (IDENT:EAXrSRFGHaKLDxci20ULt1NVXGR+x2da@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAMIrYA27115; Tue, 22 Nov 2005 11:53:34 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAMIrYR24907; Tue, 22 Nov 2005 11:53:34 -0700 Date: Tue, 22 Nov 2005 11:53:34 -0700 From: "Brian F. G. Bidulock" To: Saraswati Bose Subject: Re: [SIGTRAN]: Clarification on traffic modes Message-ID: <20051122115334.B24853@openss7.org> Mail-Followup-To: Saraswati Bose , sigtran References: <20051122133615.28113.qmail@web53805.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20051122133615.28113.qmail@web53805.mail.yahoo.com>; from saraswatibose@yahoo.com on Tue, Nov 22, 2005 at 05:36:15AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sigtran X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Saraswati, Saraswati Bose wrote: (Tue, 22 Nov 2005 05:36:15) > > Hi, > > 1. > Is 1. Is it correct that traffic mode is defined for an AS only? If > yes then can we say that same ASP serving in more than one AS will > operate as per Traffic mode defined for the AS? Yes. > > 2. For override traffic mode only one ASP can stay in ACTIVE > state at one time. If yes then can we say that the redundant model > defined for an override AS is always 1+k? Yes. > > 3. > Is 4. How does load share traffic and broadcast traffic differ > from each other for redundancy model 2+1? Loadshare sends message to 1 active ASP. Broadcast sends a copy of the message to each active ASP. --brian > > Regards, > Saraswati > _________________________________________________________________ > > [1]Yahoo! FareChase - Search multiple travel sites in one click. > > References > > 1. http://us.lrd.yahoo.com/_ylc=X3oDMTFqODRtdXQ4BF9TAzMyOTc1MDIEX3MDOTY2ODgxNjkEcG9zAzEEc2VjA21haWwtZm9vdGVyBHNsawNmYw--/SIG=110oav78o/**http%3a//farechase.yahoo.com/ -- 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 Nov 23 00:36:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EenIh-0006oT-Gr; Wed, 23 Nov 2005 00:36:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EenIg-0006o6-Uq for sigtran@megatron.ietf.org; Wed, 23 Nov 2005 00:36:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11869 for ; Wed, 23 Nov 2005 00:35:32 -0500 (EST) From: amrita.garg@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EenbP-0000Zf-2e for Sigtran@ietf.org; Wed, 23 Nov 2005 00:55:36 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 18E512068A for ; Wed, 23 Nov 2005 10:52:21 +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 EF3FA2067C for ; Wed, 23 Nov 2005 10:52:20 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Nov 2005 11:05:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sigtran] SUA : When to send DUPU messages Date: Wed, 23 Nov 2005 11:05:23 +0530 Message-ID: <527712917C05904F91F46FADBBE0F90D01BE864C@BLR-EC-MBX02.wipro.com> Thread-Topic: [Sigtran] SUA : When to send DUPU messages Thread-Index: AcXvRzNWofmNmHG7TAWaB5MfdiCUcgApj72Q To: , X-OriginalArrivalTime: 23 Nov 2005 05:35:24.0767 (UTC) FILETIME=[B418BEF0:01C5EFEF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: Sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hi Brian, Wanted to clarify in which case do we send a DUPU message. After receiving a DAUD message if a pointcode is not configured then should DUPU be send in response? And if a point code is configured but inaccessible then a DUNA will be sent. In this case a DUPU will not be sent. Can you confirm if this understanding is correct? Regards Amrita Garg -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf Of Brian F. G. Bidulock Sent: Tuesday, November 22, 2005 2:55 PM To: Khaja Sheriff (WT01 - Voice & Next Generation Networks) Cc: Sigtran@ietf.org Subject: Re: [Sigtran] SUA : When to send DUPU messages khaja.sheriff, On Tue, 22 Nov 2005, khaja.sheriff@wipro.com wrote: >=20 > Hi, >=20 > In RFC 3868, the DUPU messages are being sent when the user part > is unavailable. But it seems like that the DUNA messages are being > sent to convey that the destination is not reachable . >=20 > Please clarify under what conditions DUPU message will be sent by the > peer. Under these conditions: 0 remote SCCP unavailable, reason unknown; 1 remote SCCP unequipped; 2 remote SCCP inaccessible; --brian >=20 > Thanks and Regards >=20 > Khaja Sheriff > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock | The reasonable man adapts himself to the | bidulock@openss7.org | world; the unreasonable one persists in | http://www.openss7.org/ | trying to adapt the world to himself. | | Therefore all progress depends on the | | unreasonable man. -- George Bernard Shaw | _______________________________________________ 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 Nov 23 02:17:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeotD-0007Se-2i; Wed, 23 Nov 2005 02:17:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeotB-0007RY-Iq for sigtran@megatron.ietf.org; Wed, 23 Nov 2005 02:17:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20747 for ; Wed, 23 Nov 2005 02:17:18 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[comIe5Out3o9E35wykK76UNqoScP/r+J]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EepBz-0005kk-0t for Sigtran@ietf.org; Wed, 23 Nov 2005 02:37:24 -0500 Received: from ns.pigworks.openss7.net (IDENT:Ia8bC7DKUDxQvF1xait2q7kcGOUB2xpz@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAN7HqA07795; Wed, 23 Nov 2005 00:17:52 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAN7HqW18966; Wed, 23 Nov 2005 00:17:52 -0700 Date: Wed, 23 Nov 2005 00:17:51 -0700 From: "Brian F. G. Bidulock" To: amrita.garg@wipro.com Subject: Re: [Sigtran] SUA : When to send DUPU messages Message-ID: <20051123001751.A18935@openss7.org> Mail-Followup-To: amrita.garg@wipro.com, khaja.sheriff@wipro.com, Sigtran@ietf.org References: <527712917C05904F91F46FADBBE0F90D01BE864C@BLR-EC-MBX02.wipro.com> 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: <527712917C05904F91F46FADBBE0F90D01BE864C@BLR-EC-MBX02.wipro.com>; from amrita.garg@wipro.com on Wed, Nov 23, 2005 at 11:05:23AM +0530 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 jAN7HqA07795 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: Sigtran@ietf.org, khaja.sheriff@wipro.com X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org amrita.garg, On Wed, 23 Nov 2005, amrita.garg@wipro.com wrote: > Hi Brian, >=20 > Wanted to clarify in which case do we send a DUPU message. After > receiving a DAUD message if a pointcode is not configured then should > DUPU be send in response? No, don't send DUPU. An unconfigured point code does not match any of the three cases below. > And if a point code is configured but inaccessible then a DUNA will be > sent. In this case a DUPU will not be sent. Yes, don't send DUPU. An inaccessible point code does not match any of the cases below. DUNA is TFP or SSP. DUPU is UPU (or SSP for SSN=3D0). --brian >=20 > Can you confirm if this understanding is correct? >=20 > Regards > Amrita Garg >=20 > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On > Behalf Of Brian F. G. Bidulock > Sent: Tuesday, November 22, 2005 2:55 PM > To: Khaja Sheriff (WT01 - Voice & Next Generation Networks) > Cc: Sigtran@ietf.org > Subject: Re: [Sigtran] SUA : When to send DUPU messages >=20 > khaja.sheriff, >=20 > On Tue, 22 Nov 2005, khaja.sheriff@wipro.com wrote: >=20 > >=20 > > Hi, > >=20 > > In RFC 3868, the DUPU messages are being sent when the user > part > > is unavailable. But it seems like that the DUNA messages are > being > > sent to convey that the destination is not reachable . > >=20 > > Please clarify under what conditions DUPU message will be sent by > the > > peer. >=20 > Under these conditions: >=20 > 0 remote SCCP unavailable, reason unknown; > 1 remote SCCP unequipped; > 2 remote SCCP inaccessible; >=20 > --brian >=20 > >=20 > > Thanks and Regards > >=20 > > Khaja Sheriff >=20 >=20 >=20 > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran >=20 >=20 > --=20 > Brian F. G. Bidulock | The reasonable man adapts himself to the | > bidulock@openss7.org | world; the unreasonable one persists in | > http://www.openss7.org/ | trying to adapt the world to himself. | > | Therefore all progress depends on the | > | unreasonable man. -- George Bernard Shaw | >=20 > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran >=20 > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=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 Nov 28 06:14:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eggy3-0006hC-Hk; Mon, 28 Nov 2005 06:14:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eggy2-0006gP-Hh for sigtran@megatron.ietf.org; Mon, 28 Nov 2005 06:14:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17674 for ; Mon, 28 Nov 2005 06:13:57 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EghHr-0000s1-A5 for Sigtran@ietf.org; Mon, 28 Nov 2005 06:35:14 -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 jASBDZcn029020 for ; Mon, 28 Nov 2005 03:13:38 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <004801c5f40c$db3bc740$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Mon, 28 Nov 2005 14:14:00 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.86.1/1196/Mon Nov 28 01:41:34 2005 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Sigtran] Details of Reg Rsp, Dereg Rsp 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="===============1242870916==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1242870916== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C5F425.FAA3C010" This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C5F425.FAA3C010 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, I have a question regarding Registration Result (Deregistration Result) = parameter of Reg Rsp (Dereg Rsp) message. Is ordering of parameters = inside Registration Result (Deregistration Result) important? Perhaps it is implied. I'm just not sure. Thanks in advance, Sergey Mikhailov. ------=_NextPart_000_0045_01C5F425.FAA3C010 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have a question regarding = Registration Result=20 (Deregistration Result) parameter of Reg Rsp (Dereg Rsp) message. Is = ordering of=20 parameters inside Registration Result (Deregistration Result)=20 important?
 
Perhaps it is implied. I'm just = not=20 sure.
 
Thanks in advance,
Sergey = Mikhailov.
------=_NextPart_000_0045_01C5F425.FAA3C010-- --===============1242870916== 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 --===============1242870916==-- From sigtran-bounces@ietf.org Mon Nov 28 09:29:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egk0X-0000Gi-MC; Mon, 28 Nov 2005 09:29:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egk0W-0000Gd-Db for sigtran@megatron.ietf.org; Mon, 28 Nov 2005 09:29:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11495 for ; Mon, 28 Nov 2005 09:28:44 -0500 (EST) Received: from phl-28-b-170.phl.dsl.cerfnet.com ([63.242.157.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgkKO-0007mY-El for Sigtran@ietf.org; Mon, 28 Nov 2005 09:50:01 -0500 Received: from bn001320 (bn001320 [192.168.1.61]) by phl-28-b-170.phl.dsl.cerfnet.com (8.12.8/8.12.8) with SMTP id jASETEoj007763 for ; Mon, 28 Nov 2005 09:29:14 -0500 From: "Barry Nagelberg" To: "SIGTRAN" Subject: RE: [Sigtran] Details of Reg Rsp, Dereg Rsp Date: Mon, 28 Nov 2005 09:31:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <004801c5f40c$db3bc740$150f0f0a@smikhailov> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, Please refer to section 3.2 (Variable Length Parameter Format) of draft-ietf-sigtran-rfc3332bis-05.doc: Where more than one parameter is included in a message, the parameters may be in any order, except where explicitly mandated. A receiver SHOULD accept the parameters in any order. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Sergey Mikhailov Sent: Monday, November 28, 2005 6:14 AM To: SIGTRAN Subject: [Sigtran] Details of Reg Rsp, Dereg Rsp Hi, I have a question regarding Registration Result (Deregistration Result) parameter of Reg Rsp (Dereg Rsp) message. Is ordering of parameters inside Registration Result (Deregistration Result) important? Perhaps it is implied. I'm just not sure. Thanks in advance, Sergey Mikhailov. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Nov 28 11:08:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglYm-0000Re-MI; Mon, 28 Nov 2005 11:08:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglYk-0000Qy-U5 for sigtran@megatron.ietf.org; Mon, 28 Nov 2005 11:08:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24774 for ; Mon, 28 Nov 2005 11:08:10 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eglsc-0002sx-HX for Sigtran@ietf.org; Mon, 28 Nov 2005 11:29:29 -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 jASG7P6g030070 for ; Mon, 28 Nov 2005 08:07:35 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <00c901c5f435$ebc2bfa0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Mon, 28 Nov 2005 19:07:46 +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.86.1/1196/Mon Nov 28 01:41:34 2005 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [Sigtran] Traffic handling modes compatibility 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="===============0083661695==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0083661695== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C6_01C5F44F.044D84B0" This is a multi-part message in MIME format. ------=_NextPart_000_00C6_01C5F44F.044D84B0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, What traffic handling modes are considered compatible by an SGP when = performing registration procedure? Section 4.3.4.3 says: "If the SGP determines that the mode indicated in = an ASP Active message is unsupported or incompatible with the mode = currently configured for the AS, the SGP responds with an Error message = ("Unsupported / Invalid Traffic Handling Mode")." Section 3.7.1 says: "Within a particular Routing Context, Override, = Loadshare and Broadcast SHOULD NOT be mixed." This means that [according to RFC2119 (BCP14)] there may exist valid = reasons to mix different traffic handling modes. Sergey Mikhailov. ------=_NextPart_000_00C6_01C5F44F.044D84B0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi,
 
What traffic handling modes are = considered=20 compatible by an SGP when performing registration = procedure?
 
 
Section 4.3.4.3 says: "If the SGP = determines that=20 the mode indicated in an ASP Active message is unsupported or = incompatible with=20 the mode currently configured for the AS, the SGP responds with an Error = message=20 ("Unsupported / Invalid Traffic Handling Mode")."
 
Section 3.7.1 says: "Within a = particular Routing=20 Context, Override, Loadshare and Broadcast SHOULD NOT be = mixed."
This means that [according to RFC2119 = (BCP14)]=20 there may exist valid reasons to mix different traffic handling=20 modes.
 
 
Sergey = Mikhailov.
------=_NextPart_000_00C6_01C5F44F.044D84B0-- --===============0083661695== 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 --===============0083661695==-- From sigtran-bounces@ietf.org Mon Nov 28 11:16:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eglfv-0002Fc-3I; Mon, 28 Nov 2005 11:16:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eglft-0002FP-Q8 for sigtran@megatron.ietf.org; Mon, 28 Nov 2005 11:16:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25648 for ; Mon, 28 Nov 2005 11:15:33 -0500 (EST) Received: from phl-28-b-170.phl.dsl.cerfnet.com ([63.242.157.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eglzk-0003AC-HW for Sigtran@ietf.org; Mon, 28 Nov 2005 11:36:52 -0500 Received: from bn001320 (bn001320 [192.168.1.61]) by phl-28-b-170.phl.dsl.cerfnet.com (8.12.8/8.12.8) with SMTP id jASGG9oj008549 for ; Mon, 28 Nov 2005 11:16:09 -0500 From: "Barry Nagelberg" To: "SIGTRAN" Subject: RE: [Sigtran] Traffic handling modes compatibility Date: Mon, 28 Nov 2005 11:18:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <00c901c5f435$ebc2bfa0$150f0f0a@smikhailov> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, 1. Here is an example of an incompatibility: ASP1 sends a REG_REQ msg for RK x will Traffic Mode = Override ASP2 sends a REG_REQ msg for RK x will Traffic Mode = Loadshare This means that ASP2 is trying to join an existing AS, but wants to use a different traffic mode that what has already been established for the AS. 2. I can't think of any valid reason to mix traffic modes. Barry Nagelberg Adax, Inc. -----Original Message----- From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of Sergey Mikhailov Sent: Monday, November 28, 2005 11:08 AM To: SIGTRAN Subject: [Sigtran] Traffic handling modes compatibility Hi, What traffic handling modes are considered compatible by an SGP when performing registration procedure? Section 4.3.4.3 says: "If the SGP determines that the mode indicated in an ASP Active message is unsupported or incompatible with the mode currently configured for the AS, the SGP responds with an Error message ("Unsupported / Invalid Traffic Handling Mode")." Section 3.7.1 says: "Within a particular Routing Context, Override, Loadshare and Broadcast SHOULD NOT be mixed." This means that [according to RFC2119 (BCP14)] there may exist valid reasons to mix different traffic handling modes. Sergey Mikhailov. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 29 05:52:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh36K-0003lS-FV; Tue, 29 Nov 2005 05:52:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh36H-0003lN-Rn for sigtran@megatron.ietf.org; Tue, 29 Nov 2005 05:52:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16376 for ; Tue, 29 Nov 2005 05:51:56 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh3QK-0006Yo-E1 for Sigtran@ietf.org; Tue, 29 Nov 2005 06:13:26 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id jATApdrH035800 for ; Tue, 29 Nov 2005 02:51:40 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <003601c5f4d2$f44577b0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Subject: RE: [Sigtran] Traffic handling modes compatibility Date: Tue, 29 Nov 2005 13:52:05 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,HTML_30_40, 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.86.1/1197/Mon Nov 28 10:09:01 2005 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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="===============0279135255==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0279135255== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C5F4EC.155D1C50" This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C5F4EC.155D1C50 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Barry, Thank you for your reply. Yes, the explanation of 'incompatible' as simply 'different [from what = is=20 already established for the AS]' looks the most probable to me. But I was really confused by the modality used by the authors (the three = traffic handling modes 'SHOULD NOT be mixed' [rather than 'MUST NOT be=20 mixed'], in Section 3.7.1 of both RFC3332 and=20 draft-ietf-sigtran-rfc3332bis-05). This is because these keywords, = according=20 to section 2, are to be interpreted as described in RFC2119 (BCP14), and = this is what I was trying to do in order to resolve the uncertainty. If we accept your explanation, then it is unclear: what was the reason = of=20 specifying 'SHOULD NOT' rather than 'MUST NOT' in Section 3.7.1? Sergey Mikhailov. ----- Original Message -----=20 From: "Barry Nagelberg" To: "SIGTRAN" Sent: Monday, November 28, 2005 7:18 PM Subject: RE: [Sigtran] Traffic handling modes compatibility > Sergey, > > 1. Here is an example of an incompatibility: > > ASP1 sends a REG_REQ msg for RK x will Traffic Mode =3D Override > ASP2 sends a REG_REQ msg for RK x will Traffic Mode =3D Loadshare > > This means that ASP2 is trying to join an existing AS, but wants to = use a=20 > different traffic mode that what has already > been established for the AS. > > 2. I can't think of any valid reason to mix traffic modes. > > Barry Nagelberg > Adax, Inc. > > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On = Behalf=20 > Of Sergey Mikhailov > Sent: Monday, November 28, 2005 11:08 AM > To: SIGTRAN > Subject: [Sigtran] Traffic handling modes compatibility > > > Hi, > > What traffic handling modes are considered compatible by an SGP when=20 > performing registration procedure? > > > Section 4.3.4.3 says: "If the SGP determines that the mode indicated = in an=20 > ASP Active message is unsupported or > incompatible with the mode currently configured for the AS, the SGP=20 > responds with an Error message ("Unsupported / > Invalid Traffic Handling Mode")." > > Section 3.7.1 says: "Within a particular Routing Context, Override,=20 > Loadshare and Broadcast SHOULD NOT be mixed." > This means that [according to RFC2119 (BCP14)] there may exist valid=20 > reasons to mix different traffic handling modes. > > > Sergey Mikhailov. > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran >=20 ------=_NextPart_000_0033_01C5F4EC.155D1C50 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Barry,

Thank you for your reply.
Yes, the explanation = of=20 'incompatible' as simply 'different [from what is
already = established for=20 the AS]' looks the most probable to me.

But I was really confused = by the=20 modality used by the authors (the three
traffic handling modes = 'SHOULD NOT=20 be mixed' [rather than 'MUST NOT be
mixed'], in Section 3.7.1 of = both=20 RFC3332 and
draft-ietf-sigtran-rfc3332bis-05). This is because these = keywords, according
to section 2, are to be interpreted as described = in=20 RFC2119 (BCP14), and
this is what I was trying to do in order to = resolve the=20 uncertainty.

If we accept your explanation, then it is unclear: = what was=20 the reason of
specifying 'SHOULD NOT' rather than 'MUST NOT' in = Section=20 3.7.1?

Sergey Mikhailov.



----- Original Message = -----=20
From: "Barry Nagelberg" <barryn@adax.com>
To:=20 "SIGTRAN" <Sigtran@ietf.org>
Sent: Monday, November 28, 2005 7:18 PM
Subject: RE: = [Sigtran]=20 Traffic handling modes compatibility


> = Sergey,
>
> 1.=20 Here is an example of an incompatibility:
>
> ASP1 sends a = REG_REQ=20 msg for RK x will Traffic Mode =3D Override
> ASP2 sends a REG_REQ = msg for=20 RK x will Traffic Mode =3D Loadshare
>
> This means that = ASP2 is=20 trying to join an existing AS, but wants to use a
> different = traffic=20 mode that what has already
> been established for the = AS.
>
>=20 2. I can't think of any valid reason to mix traffic = modes.
>
> Barry=20 Nagelberg
> Adax, Inc.
>
> -----Original = Message-----
>=20 From: sigtran-bounces@ietf.org=20 [mailto:sigtran-bounces@ietf.org]On Behalf
> Of Sergey = Mikhailov
>=20 Sent: Monday, November 28, 2005 11:08 AM
> To: SIGTRAN
> = Subject:=20 [Sigtran] Traffic handling modes compatibility
>
>
>=20 Hi,
>
> What traffic handling modes are considered = compatible by an=20 SGP when
> performing registration = procedure?
>
>
>=20 Section 4.3.4.3 says: "If the SGP determines that the mode indicated in = an=20
> ASP Active message is unsupported or
> incompatible with = the mode=20 currently configured for the AS, the SGP
> responds with an Error = message=20 ("Unsupported /
> Invalid Traffic Handling = Mode")."
>
>=20 Section 3.7.1 says: "Within a particular Routing Context, Override, =
>=20 Loadshare and Broadcast SHOULD NOT be mixed."
> This means that = [according=20 to RFC2119 (BCP14)] there may exist valid
> reasons to mix = different=20 traffic handling modes.
>
>
> Sergey=20 Mikhailov.
>
>
>=20 _______________________________________________
> Sigtran mailing=20 list
> Sigtran@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/sigtran
> =
------=_NextPart_000_0033_01C5F4EC.155D1C50-- --===============0279135255== 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 --===============0279135255==-- From sigtran-bounces@ietf.org Tue Nov 29 06:14:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh3R9-0006CP-QC; Tue, 29 Nov 2005 06:14:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh3R8-0006CK-CD for sigtran@megatron.ietf.org; Tue, 29 Nov 2005 06:14:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18761 for ; Tue, 29 Nov 2005 06:13:28 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[Gj4WpJTmo1IirAmnYzqZois4Bsldih+1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh3lB-0007D4-1P for Sigtran@ietf.org; Tue, 29 Nov 2005 06:34:58 -0500 Received: from ns.pigworks.openss7.net (IDENT:uydeylBpUxII61BTpyAeJTE6m8o/kiaY@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jATBE8A07484; Tue, 29 Nov 2005 04:14:08 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jATBE8208431; Tue, 29 Nov 2005 04:14:08 -0700 Date: Tue, 29 Nov 2005 04:14:08 -0700 From: "Brian F. G. Bidulock" To: Sergey Mikhailov Subject: Re: [Sigtran] Traffic handling modes compatibility Message-ID: <20051129041408.A8081@openss7.org> Mail-Followup-To: Sergey Mikhailov , SIGTRAN References: <003601c5f4d2$f44577b0$150f0f0a@smikhailov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <003601c5f4d2$f44577b0$150f0f0a@smikhailov>; from smikhailov@linkbit.com on Tue, Nov 29, 2005 at 01:52:05PM +0300 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id jATBE8A07484 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, On Tue, 29 Nov 2005, Sergey Mikhailov wrote: > If we accept your explanation, then it is unclear: what was > the reason of specifying 'SHOULD NOT' rather than 'MUST > NOT' in Section 3.7.1? It is not so hard to conceive of an SG that could support mixed modes: there is just little current support for it in the protocol. We did not say that an implementation MUST NOT do a thing if it is conceivable that it can achieve it with some effort: we instead said SHOULD NOT. The following drafts offer proposals to support mixed modes in the protocol: http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-loadsel-03.tx= t http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-loadgrp-03.tx= t The above were developed because there was interest at one point in supporting mixed modes and there were some that felt it could be achieved even without protocol support. --brian --=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 Tue Nov 29 08:17:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh5Iv-00043R-5v; Tue, 29 Nov 2005 08:13:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh5It-00040y-KI for sigtran@megatron.ietf.org; Tue, 29 Nov 2005 08:13:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01746 for ; Tue, 29 Nov 2005 08:13:07 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh5cx-0002dz-Qc for sigtran@ietf.org; Tue, 29 Nov 2005 08:34:37 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jATDDM0X011391 for ; Tue, 29 Nov 2005 08:13:26 -0500 (EST) From: "Tolga Asveren" To: Date: Tue, 29 Nov 2005 07:54:52 -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 X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Sigtran] M3UA Deployment Considerations Draft X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org 00 version of M3UA Deployment Considerations draft is now available: http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uacons-00.txt Comments/suggestions are welcome. Thanks, Tolga _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 29 08:33:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh5bs-0003k6-Va; Tue, 29 Nov 2005 08:33:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh5bo-0003jm-6K for sigtran@megatron.ietf.org; Tue, 29 Nov 2005 08:33:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03463 for ; Tue, 29 Nov 2005 08:32:39 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh5vs-0003Cm-U0 for Sigtran@ietf.org; Tue, 29 Nov 2005 08:54:09 -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 jATDWHMj036800; Tue, 29 Nov 2005 05:32:20 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <004b01c5f4e9$663e3f80$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: References: <003601c5f4d2$f44577b0$150f0f0a@smikhailov> <20051129041408.A8081@openss7.org> Subject: Re: [Sigtran] Traffic handling modes compatibility Date: Tue, 29 Nov 2005 16:32:44 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.86.1/1197/Mon Nov 28 10:09:01 2005 on linkbit2 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by linkbit2.linkbit.com id jATDWHMj036800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Brian, Thank you very much this clarification. Now I've got confidence on the issue. Sergey Mikhailov. ----- Original Message -----=20 From: "Brian F. G. Bidulock" To: "Sergey Mikhailov" Cc: "SIGTRAN" Sent: Tuesday, November 29, 2005 2:14 PM Subject: Re: [Sigtran] Traffic handling modes compatibility > Sergey, > > On Tue, 29 Nov 2005, Sergey Mikhailov wrote: > >> If we accept your explanation, then it is unclear: what was >> the reason of specifying 'SHOULD NOT' rather than 'MUST >> NOT' in Section 3.7.1? > > It is not so hard to conceive of an SG that could support mixed > modes: there is just little current support for it in the protocol. > We did not say that an implementation MUST NOT do a thing if it is > conceivable that it can achieve it with some effort: we instead > said SHOULD NOT. > > The following drafts offer proposals to support mixed modes in > the protocol: > > http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-loadsel-03.t= xt > http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-loadgrp-03.t= xt > > The above were developed because there was interest at one point > in supporting mixed modes and there were some that felt it could > be achieved even without protocol support. > > --brian > > --=20 > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 > bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 > http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 > =A6 Therefore all progress depends on the =A6 > =A6 unreasonable man. -- George Bernard Shaw =A6 >=20 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 29 10:35:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh7Vn-00033U-9H; Tue, 29 Nov 2005 10:35:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh7Vh-0002iv-8m for sigtran@megatron.ietf.org; Tue, 29 Nov 2005 10:35:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20905 for ; Tue, 29 Nov 2005 10:34:28 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh7pm-0007w8-Al for sigtran@ietf.org; Tue, 29 Nov 2005 10:55:59 -0500 Received: by nproxy.gmail.com with SMTP id l37so568347nfc for ; Tue, 29 Nov 2005 07:35:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RHOCLHzRo6hoqXFqjXhJxKDbqwIUInNIKmfh4aNuzgKVnh3ykuGiscGyRN91Ix3Mq2QMdB4xiR+v6lupb3NYeUO+dDaMfY+o4dsw2NkBZUkL4vi7sZZWevx3GaKxNTK6D9BGmf8FrE4cFtj7E4ma+HonCUbzgch2r+TGxIw+Qnc= Received: by 10.48.220.6 with SMTP id s6mr592905nfg; Tue, 29 Nov 2005 07:35:10 -0800 (PST) Received: by 10.48.1.10 with HTTP; Tue, 29 Nov 2005 07:35:08 -0800 (PST) Message-ID: <17b146d60511290735k7a692114q8e143d9496d96f09@mail.gmail.com> Date: Tue, 29 Nov 2005 16:35:08 +0100 From: Ilie Glib 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.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Subject: [Sigtran] Traffic handling modes of SGPs X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Hello, SGP concept in RFC 3868 sais "Signalling Gateway Process (SGP) - A process instance of a Signalling Gateway. It serves as an active, load-sharing or broadcast process of a Signalling Gateway" It seems that no other part of the RFC allows SGPs to act in different traffic modes. Is this just a leftover? Or, shall ASPs know the traffic mode type of SGP by configuration? How override can be supported without a NTFY sent from ASPs to SGPs? Thank you in advance Ilie _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 29 12:00:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8qg-0007EO-T4; Tue, 29 Nov 2005 12:00:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8qe-0007E1-NZ for sigtran@megatron.ietf.org; Tue, 29 Nov 2005 12:00:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03351 for ; Tue, 29 Nov 2005 12:00:11 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh9Ah-0002xT-CG for Sigtran@ietf.org; Tue, 29 Nov 2005 12:21:44 -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 jATGxPtd037695 for ; Tue, 29 Nov 2005 08:59:31 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <008401c5f506$579a8340$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Tue, 29 Nov 2005 19:59:50 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.86.1/1197/Mon Nov 28 10:09:01 2005 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Sigtran] M3UA DATA message sending in broadcast mode 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="===============0303809540==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0303809540== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01C5F51F.753FE480" This is a multi-part message in MIME format. ------=_NextPart_000_007F_01C5F51F.753FE480 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, Could anybody please tell me what is 'tagging a DATA message broadcast', = regarding DATA messages sent by an SGP for AS in broadcast mode? Sergey Mikhailov. ------=_NextPart_000_007F_01C5F51F.753FE480 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi,
Could anybody please tell me what is = 'tagging a=20 DATA message broadcast', regarding DATA messages sent by an SGP for AS = in=20 broadcast mode?
 
Sergey = Mikhailov.
------=_NextPart_000_007F_01C5F51F.753FE480-- --===============0303809540== 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 --===============0303809540==-- From sigtran-bounces@ietf.org Tue Nov 29 13:58:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAgN-0001zx-MB; Tue, 29 Nov 2005 13:58:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAgM-0001yW-Tn for sigtran@megatron.ietf.org; Tue, 29 Nov 2005 13:58:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20349 for ; Tue, 29 Nov 2005 13:57:42 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[Aqa6mCGtu0NcSMqUxFQA/+tI8QbpJWlY]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhB0U-0007r3-Em for Sigtran@ietf.org; Tue, 29 Nov 2005 14:19:14 -0500 Received: from ns.pigworks.openss7.net (IDENT:v72mNqYHmGImXRQM+wdcDtfNEW0dyBAT@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jATIwOA14836; Tue, 29 Nov 2005 11:58:24 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jATIwO412058; Tue, 29 Nov 2005 11:58:24 -0700 Date: Tue, 29 Nov 2005 11:58:24 -0700 From: "Brian F. G. Bidulock" To: Sergey Mikhailov Subject: Re: [Sigtran] M3UA DATA message sending in broadcast mode Message-ID: <20051129115824.B11730@openss7.org> Mail-Followup-To: Sergey Mikhailov , SIGTRAN References: <008401c5f506$579a8340$150f0f0a@smikhailov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <008401c5f506$579a8340$150f0f0a@smikhailov>; from smikhailov@linkbit.com on Tue, Nov 29, 2005 at 07:59:50PM +0300 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id jATIwOA14836 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, Tagging a data message consists of adding a Correlation Id parameter to it. See http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-corid-03.txt --brian On Tue, 29 Nov 2005, Sergey Mikhailov wrote: >=20 > Hi, >=20 > Could anybody please tell me what is 'tagging a DATA messa= ge > broadcast', regarding DATA messages sent by an SGP for AS in broadca= st > mode? >=20 >=20 >=20 > Sergey Mikhailov. > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 29 14:05:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAnX-0005cR-HQ; Tue, 29 Nov 2005 14:05:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAnW-0005cM-Eq for sigtran@megatron.ietf.org; Tue, 29 Nov 2005 14:05:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21349 for ; Tue, 29 Nov 2005 14:05:06 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[FNMkIXS6gmW4yTOfo4pBYX0OH6KTFo32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhB7d-00089U-Kt for sigtran@ietf.org; Tue, 29 Nov 2005 14:26:39 -0500 Received: from ns.pigworks.openss7.net (IDENT:Fwa6L1uCZYzFny5OTWtclptWKuGSOgkg@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jATJ5jA15077; Tue, 29 Nov 2005 12:05:45 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jATJ5i912234; Tue, 29 Nov 2005 12:05:44 -0700 Date: Tue, 29 Nov 2005 12:05:44 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] M3UA Deployment Considerations Draft Message-ID: <20051129120544.C11730@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 Tue, Nov 29, 2005 at 07:54:52AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: 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 Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, You recommend proprietary extensions? --brian Tolga Asveren wrote: (Tue, 29 Nov 2005 07:54:52) > 00 version of M3UA Deployment Considerations draft is now available: > > http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uacons-00.txt > > Comments/suggestions are welcome. > > Thanks, > Tolga > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 29 14:29:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBAO-0004xE-G9; Tue, 29 Nov 2005 14:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBAM-0004x6-Kx for sigtran@megatron.ietf.org; Tue, 29 Nov 2005 14:29:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23776 for ; Tue, 29 Nov 2005 14:28:42 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhBUU-0000RJ-1G for sigtran@ietf.org; Tue, 29 Nov 2005 14:50:15 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id jATJT3kL021425 for ; Tue, 29 Nov 2005 14:29:05 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Sigtran] M3UA Deployment Considerations Draft Date: Tue, 29 Nov 2005 14:10:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20051129120544.C11730@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Well, actually we don't. It is seen as a last option if nothing else works. The point mentioning about it was more to emphasize that there are other solutions to address the discussed problems. OTOH maybe we did not use the best language to tell this -maybe we should have mentioned only of optional extensions rather than optional extensions/proprietary extensions-. > -----Original Message----- > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > Behalf Of Brian F. G. Bidulock > Sent: Tuesday, November 29, 2005 2:06 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] M3UA Deployment Considerations Draft > > > Tolga, > > You recommend proprietary extensions? > > --brian > > Tolga Asveren wrote: > (Tue, 29 Nov 2005 07:54:52) > > 00 version of M3UA Deployment Considerations draft is now available: > > > > > http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uacons-00.txt > > > > Comments/suggestions are welcome. > > > > Thanks, > > Tolga > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Nov 29 15:10:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBoJ-0007yy-LO; Tue, 29 Nov 2005 15:10:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBoI-0007xh-7J for sigtran@megatron.ietf.org; Tue, 29 Nov 2005 15:10:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28977 for ; Tue, 29 Nov 2005 15:09:57 -0500 (EST) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhC8O-0001yB-V2 for Sigtran@ietf.org; Tue, 29 Nov 2005 15:31:31 -0500 Received: from [192.168.1.17] (p508F74CC.dip.t-dialin.net [80.143.116.204]) by ilsa.franken.de (Postfix) with ESMTP id 8628E245D2; Tue, 29 Nov 2005 21:10:21 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20051129115824.B11730@openss7.org> References: <008401c5f506$579a8340$150f0f0a@smikhailov> <20051129115824.B11730@openss7.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4348aec6791d3e8083c3c252aeb8ecef@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Sigtran] M3UA DATA message sending in broadcast mode Date: Tue, 29 Nov 2005 21:09:03 +0100 To: bidulock@openss7.org X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, just scanned the M3UA RFC... On page 83, the last paragraph before 4.3.4.3.1 states: Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP MUST tag the first DATA message broadcast in each traffic flow with a unique Correlation Id parameter. So the phrase is defined in RFC 3332. The ETSI testcase refers to this =20= sentence. Best regards Michael On Nov 29, 2005, at 19:58 Uhr, Brian F. G. Bidulock wrote: > Sergey, > > Tagging a data message consists of adding a Correlation Id parameter > to it. See > > =20 > http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-corid=20 > -03.txt > > --brian > > On Tue, 29 Nov 2005, Sergey Mikhailov wrote: > >> >> Hi, >> >> Could anybody please tell me what is 'tagging a DATA =20 >> message >> broadcast', regarding DATA messages sent by an SGP for AS in =20 >> broadcast >> mode? >> >> >> >> Sergey Mikhailov. > >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www1.ietf.org/mailman/listinfo/sigtran > > > --=20 > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6= > bidulock@openss7.org =A6 world; the unreasonable one persists in =A6= > http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6= > =A6 Therefore all progress depends on the =A6= > =A6 unreasonable man. -- George Bernard Shaw =A6= > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 30 05:14:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhOzG-0006YQ-1w; Wed, 30 Nov 2005 05:14:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhOzF-0006Wy-7T for sigtran@megatron.ietf.org; Wed, 30 Nov 2005 05:14:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24444 for ; Wed, 30 Nov 2005 05:14:07 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhPJT-0004nC-IX for Sigtran@ietf.org; Wed, 30 Nov 2005 05:35:49 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id jAUADfWG041342; Wed, 30 Nov 2005 02:13:46 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <00bf01c5f596$d3ace4b0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "Michael Tuexen" , "Brian F. G. Bidulock" Subject: Re: [Sigtran] M3UA DATA message sending in broadcast mode Date: Wed, 30 Nov 2005 13:14:07 +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.86.1/1198/Tue Nov 29 02:05:20 2005 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1541986147==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1541986147== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01C5F5AF.F1E62180" This is a multi-part message in MIME format. ------=_NextPart_000_00BA_01C5F5AF.F1E62180 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Michael, Brian, Thank you very much for this clarification and for the link from Brian. Sincerely, Sergey Mikhailov. ----- Original Message -----=20 From: "Michael Tuexen" To: Cc: "Sergey Mikhailov" ; "SIGTRAN" = Sent: Tuesday, November 29, 2005 11:09 PM Subject: Re: [Sigtran] M3UA DATA message sending in broadcast mode > Sergey, >=20 > just scanned the M3UA RFC... >=20 > On page 83, the last paragraph before 4.3.4.3.1 states: >=20 > Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP > MUST tag the first DATA message broadcast in each traffic flow with > a unique Correlation Id parameter. >=20 > So the phrase is defined in RFC 3332. The ETSI testcase refers to this = =20 > sentence. >=20 > Best regards > Michael >=20 >=20 > On Nov 29, 2005, at 19:58 Uhr, Brian F. G. Bidulock wrote: >=20 >> Sergey, >> >> Tagging a data message consists of adding a Correlation Id parameter >> to it. See >> >> =20 >> http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-corid=20 >> -03.txt >> >> --brian >> >> On Tue, 29 Nov 2005, Sergey Mikhailov wrote: >> >>> >>> Hi, >>> >>> Could anybody please tell me what is 'tagging a DATA =20 >>> message >>> broadcast', regarding DATA messages sent by an SGP for AS in =20 >>> broadcast >>> mode? >>> >>> >>> >>> Sergey Mikhailov. >> >>> _______________________________________________ >>> Sigtran mailing list >>> Sigtran@ietf.org >>> https://www1.ietf.org/mailman/listinfo/sigtran >> >> >> --=20 >> Brian F. G. Bidulock =81 The reasonable man adapts himself to the = =81 >> bidulock@openss7.org =81 world; the unreasonable one persists in = =81 >> http://www.openss7.org/ =81 trying to adapt the world to himself. = =81 >> =81 Therefore all progress depends on the = =81 >> =81 unreasonable man. -- George Bernard Shaw = =81 >> >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www1.ietf.org/mailman/listinfo/sigtran >> >=20 > ------=_NextPart_000_00BA_01C5F5AF.F1E62180 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Michael, Brian,
 
Thank you very much for this = clarification and for=20 the link from Brian.
 
 
Sincerely,
Sergey Mikhailov.
 
 
 
----- Original Message -----=20
From: "Michael Tuexen" <Michael.Tuexen@lurchi.fr= anken.de>
To: <bidulock@openss7.org>
Cc: "Sergey Mikhailov" <smikhailov@linkbit.com>; = "SIGTRAN"=20 <Sigtran@ietf.org>
Sent: Tuesday, November 29, 2005 11:09 PM
Subject: Re: [Sigtran] M3UA DATA message sending in broadcast=20 mode

> Sergey,
>
> just scanned the M3UA=20 RFC...
>
> On page 83, the last paragraph before 4.3.4.3.1=20 states:
>
>    Whenever an ASP in a = Broadcast mode=20 AS becomes ASP-ACTIVE, the SGP
>    MUST tag the = first DATA=20 message broadcast in each traffic flow with
>    a = unique=20 Correlation Id parameter.
>
> So the phrase is defined in = RFC 3332.=20 The ETSI testcase refers to this 
> sentence.
> =
> Best=20 regards
> Michael
>
>
> On Nov 29, 2005, at = 19:58 Uhr,=20 Brian F. G. Bidulock wrote:
>
>> = Sergey,
>>
>>=20 Tagging a data message consists of adding a Correlation Id = parameter
>>=20 to it.  See
>>
>>   
>> = http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-corid=20
>> -03.txt
>>
>> = --brian
>>
>> On=20 Tue, 29 Nov 2005, Sergey Mikhailov=20 wrote:
>>
>>>
>>>   =20 Hi,
>>>
>>>    Could  = anybody =20 please  tell  me  what  is  'tagging  = a =20 DATA  
>>> = message
>>>   =20 broadcast', regarding DATA messages sent by an SGP for AS in =20
>>> broadcast
>>>   =20 mode?
>>>
>>>
>>>
>>>&nbs= p;  =20 Sergey Mikhailov.
>>
>>>=20 _______________________________________________
>>> Sigtran = mailing=20 list
>>> Sigtran@ietf.org
>>> https://www1.ietf= .org/mailman/listinfo/sigtran
>>
>>
>>=20 --
>> Brian F. G. Bidulock    ¦ The = reasonable man=20 adapts himself to the ¦
>> bidulock@openss7.org  =   ¦=20 world; the unreasonable one persists in  ¦
>> http://www.openss7.org/ ¦ = trying  to=20 adapt the  world  to himself.=20 ¦
>>         = ;            =    =20 ¦ Therefore  all  progress  depends on the=20 ¦
>>         = ;            =    =20 ¦ unreasonable man. -- George Bernard Shaw = ¦
>>
>>=20 _______________________________________________
>> Sigtran = mailing=20 list
>> Sigtran@ietf.org
>> https://www1.ietf= .org/mailman/listinfo/sigtran
>>
>=20
> ------=_NextPart_000_00BA_01C5F5AF.F1E62180-- --===============1541986147== 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 --===============1541986147==-- From sigtran-bounces@ietf.org Wed Nov 30 07:55:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRUQ-0005fw-Kv; Wed, 30 Nov 2005 07:55:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRUP-0005fZ-4h for sigtran@megatron.ietf.org; Wed, 30 Nov 2005 07:55:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10180 for ; Wed, 30 Nov 2005 07:54:26 -0500 (EST) Received: from web53808.mail.yahoo.com ([206.190.36.203]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhRof-0001KQ-G5 for sigtran@ietf.org; Wed, 30 Nov 2005 08:16:11 -0500 Received: (qmail 13719 invoked by uid 60001); 30 Nov 2005 12:54:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AFvzLB0/z4NZHotn84XRuJUSYXKX2JeIA+Tab21QGk6pZMeqkNmnmnXu7YArhWgke+0WHvG9zwffq1UwL1ahP+Ely+Ht2wNsKSEAbaZd8hTd9vG7a3D6/asJ/zsM7CuBtUk3cG0iH01R/ON0i+s8sagJnRLCR4R0seIsoEYHMW8= ; Message-ID: <20051130125459.13717.qmail@web53808.mail.yahoo.com> Received: from [220.227.128.163] by web53808.mail.yahoo.com via HTTP; Wed, 30 Nov 2005 04:54:59 PST Date: Wed, 30 Nov 2005 04:54:59 -0800 (PST) From: Saraswati Bose Subject: [SIGTRAN]: Clarification On load sharing and Sequence control value To: Brian Bidulock , sigtran MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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="===============0289635944==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org --===============0289635944== Content-Type: multipart/alternative; boundary="0-863685996-1133355299=:13087" Content-Transfer-Encoding: 8bit --0-863685996-1133355299=:13087 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian, Please check the below text from RFC-3868. 3.10.22. Sequence Control The field is coded with the value of the sequence control parameter associated with a group of messages and are chosen so as to ensure proper loadsharing of message groups over SLS values while ensuring that sequence control values within message groups have the sequence control value coded with the same value as the initial message of the message group. Please suggest in the below: 1. I think SSN is a single value unique across the AS? PLease suggest if I am wrong. 2. If SSN is a single value unique across the AS then how to apply the round robin alg. on SSN value? 3. In SUA no SLS is involved. So how to handle the sequence control parameter value during load sharing among ASPs using round robin algorithm over SSN? 4. Is TID/DRN value unique across AS? Regards, Saraswati. --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. --0-863685996-1133355299=:13087 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Brian,
Please check the below text from RFC-3868.
 
3.10.22. Sequence Control
The field is coded with the value of the sequence control parameter
associated with a group of messages and are chosen so as to ensure
proper loadsharing of message groups over SLS values while ensuring
that sequence control values within message groups have the sequence
control value coded with the same value as the initial message of the
message group.
 
Please suggest in the below:
 
1. I think SSN is a single value unique across the AS? PLease suggest if I am wrong.
 
2. If SSN is a single value unique across the AS then how to apply the round robin alg. on SSN value?
 
3. In SUA no SLS is involv! ed. So how to handle the sequence control parameter value during load sharing among ASPs using round robin algorithm over SSN?
 
4. Is TID/DRN value unique across AS?
 
Regards,
Saraswati.
 
 
 

Yahoo! Music Unlimited - Access over 1 million songs. Try it free. --0-863685996-1133355299=:13087-- --===============0289635944== 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 --===============0289635944==-- From sigtran-bounces@ietf.org Wed Nov 30 08:53:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSP1-0004eg-Dv; Wed, 30 Nov 2005 08:53:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSOy-0004aQ-8e for sigtran@megatron.ietf.org; Wed, 30 Nov 2005 08:53:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18082 for ; Wed, 30 Nov 2005 08:52:53 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhSjE-0003bp-1n for Sigtran@ietf.org; Wed, 30 Nov 2005 09:14:38 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id jAUDqT3K042488 for ; Wed, 30 Nov 2005 05:52:37 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <011201c5f5b5$661c17d0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Wed, 30 Nov 2005 16:52:55 +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_80_90, 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.86.1/1198/Tue Nov 29 02:05:20 2005 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: Subject: [Sigtran] AS state change (as defined for M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1657365730==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1657365730== Content-Type: multipart/alternative; boundary="----=_NextPart_000_010A_01C5F5CE.82C4C990" This is a multi-part message in MIME format. ------=_NextPart_000_010A_01C5F5CE.82C4C990 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, It seems that RFC3332 is not clear enough about AS state change (Section = 4.3.2, Figure 4): Figure 4: AS State Transition Diagram +----------+ one ASP trans to ACTIVE +-------------+ | AS- |---------------------------->| AS- | | INACTIVE | | ACTIVE | | |<--- | | +----------+ \ +-------------+ ^ | \ Tr Expiry, ^ | | | \ at least one | | | | \ ASP in ASP-INACTIVE | | | | \ | | | | \ | | | | \ | | one ASP | | all ASP \ one ASP | | Last ACTIVE trans | | trans to \ trans to | | ASP trans to to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE ASP- | | \ ACTIVE | | or ASP-DOWN INACTIVE| | \ | | (start Tr) | | \ | | | | \ | | | v \ | v +----------+ \ +-------------+ | | --| | | AS-DOWN | | AS-PENDING | | | | (queuing) | | |<----------------------------| | +----------+ Tr Expiry and no ASP +-------------+ in ASP-INACTIVE state) Tr =3D Recovery Timer IMHO, this picture is misleading for the case of Loadshare mode, because = Section 4.3.4.3 (Page 82) says: An SGP or IPSP, upon reception of an ASP Active message for the first ASP in a Loadshare AS, MAY choose not to direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources. Thus, 'one ASP trans to ACTIVE' on the picture above doesn't apply to = Loadshare mode, because in Loadshare mode it is required to have "n" = ASPs in state ASP-ACTIVE to move AS to AS-ACTIVE, i.e. enough ASPs to = handle the expected load. Regards, Sergey Mikhailov. ------=_NextPart_000_010A_01C5F5CE.82C4C990 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi,
 
It seems that RFC3332 is not clear = enough about AS=20 state change (Section 4.3.2, Figure 4):
 
 
          &nbs= p;       =20 Figure 4: AS State Transition=20 Diagram

       =20 +----------+   one ASP trans to ACTIVE  =20 +-------------+
       =20 |    AS-  =20 |---------------------------->|    =20 AS-     = |
        |=20 INACTIVE=20 |            =             &= nbsp;   =20 |   ACTIVE   =20 |
       =20 |         =20 |<---           = ;            =  =20 |            = =20 |
        = +----------+   =20 \            =            =20 +-------------+
         =  =20 ^   |         \ Tr=20 Expiry,           =     =20 ^   =20 |
           = |  =20 |          \ at least=20 one           &nbs= p;=20 |   =20 |
           = |  =20 |           \ ASP in=20 ASP-INACTIVE     |   =20 |
           = |  =20 |           =20 \            =            =20 |   =20 |
           = |  =20 |            = =20 \            =           =20 |   =20 |
           = |  =20 |            =  =20 \            =          =20 |    |
   one ASP |   | all=20 ASP      =20 \            one=20 ASP  |    | Last ACTIVE
   = trans  =20 |   | trans to      =20 \           trans to=20 |    | ASP trans to
  =20 to      |   |=20 ASP-DOWN        -------\  =20 ASP-     |    | = ASP-INACTIVE
  =20 ASP-    |  =20 |            =              = \  ACTIVE   |    | or = ASP-DOWN
  =20 INACTIVE|  =20 |            =             &= nbsp;=20 \          = |   =20 |  (start=20 Tr)
          =20 |  =20 |            =             &= nbsp; =20 \         |   =20 |
           = |  =20 |            =             &= nbsp;  =20 \        |   =20 |
           = |  =20 v            =             &= nbsp;   =20 \       |   =20 v
       =20 +----------+          &= nbsp;           &n= bsp;  =20 \  +-------------+
       =20 |         =20 |            =             &= nbsp; =20 --|           &nbs= p;=20 |
        | AS-DOWN =20 |            =             &= nbsp;   =20 | AS-PENDING  |
       =20 |         =20 |            =             &= nbsp;   =20 |  (queuing)  |
       =20 |         =20 |<----------------------------|      &nb= sp;     =20 |
        = +----------+   =20 Tr Expiry and no ASP    =20 +-------------+
         =             &= nbsp; =20 in ASP-INACTIVE state)

       Tr = =3D Recovery=20 Timer
 
 
IMHO, this = picture is=20 misleading for the case of Loadshare mode, because Section 4.3.4.3 (Page = 82)=20 says:
 
 
 
   An = SGP or IPSP,=20 upon reception of an ASP Active message for the first
   = ASP in a=20 Loadshare AS, MAY choose not to direct traffic to a = newly
   active=20 ASP until it determines that there are sufficient resources = to
  =20 handle the expected load (e.g., until there are "n" ASPs in=20 state
   ASP-ACTIVE in the AS).  In this case, the SGP = or IPSP=20 SHOULD withhold
   the Notify (AS-ACTIVE) until there are=20 sufficient resources.
Thus,=20 'one ASP trans to ACTIVE' on the picture above doesn't apply to = Loadshare mode,=20 because in Loadshare mode it is required to have "n" ASPs in state = ASP-ACTIVE to=20 move AS to AS-ACTIVE, i.e. enough ASPs to handle the expected=20 load.
 
 
 
Regards,
Sergey=20 Mikhailov.
------=_NextPart_000_010A_01C5F5CE.82C4C990-- --===============1657365730== 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 --===============1657365730==-- From sigtran-bounces@ietf.org Wed Nov 30 09:09:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSej-0005aM-0y; Wed, 30 Nov 2005 09:09:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSeh-0005Yq-50 for sigtran@megatron.ietf.org; Wed, 30 Nov 2005 09:09:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20321 for ; Wed, 30 Nov 2005 09:09:10 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[tgZ7LyZpXJXzwOJeaP/EFgCIW7vJzmDJ]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhSyy-0004G7-CJ for sigtran@ietf.org; Wed, 30 Nov 2005 09:30:53 -0500 Received: from ns.pigworks.openss7.net (IDENT:hn8v42ll3TA8loAHtM4cUXZfqn0HcVy6@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAUE9nA00774; Wed, 30 Nov 2005 07:09:49 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAUE9nL22629; Wed, 30 Nov 2005 07:09:49 -0700 Date: Wed, 30 Nov 2005 07:09:49 -0700 From: "Brian F. G. Bidulock" To: Saraswati Bose Subject: Re: [SIGTRAN]: Clarification On load sharing and Sequence control value Message-ID: <20051130070949.A22399@openss7.org> Mail-Followup-To: Saraswati Bose , sigtran References: <20051130125459.13717.qmail@web53808.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20051130125459.13717.qmail@web53808.mail.yahoo.com>; from saraswatibose@yahoo.com on Wed, Nov 30, 2005 at 04:54:59AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sigtran X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Saraswati, Saraswati Bose wrote: (Wed, 30 Nov 2005 04:54:59) > > Hi Brian, > > Please check the below text from RFC-3868. > > > 3.10.22. Sequence Control > The field is coded with the value of the sequence control parameter > associated with a group of messages and are chosen so as to ensure > proper loadsharing of message groups over SLS values while ensuring > that sequence control values within message groups have the sequence > control value coded with the same value as the initial message of the > message group. > > Please suggest in the below: > > 1. I think SSN is a single value unique across the AS? PLease suggest > if I am wrong. What do you mean by "single value unique across the AS"? > > 2. If SSN is a single value unique across the AS then how to apply the > round robin alg. on SSN value? SSN would be a poor choice for loadsharing. > > 3. In SUA no SLS is involved. So how to handle the sequence control > parameter value during load sharing among ASPs using round robin > algorithm over SSN? SLS (from the receive MTP message) is the only rational basis on which an SG can loadshare. > > 4. Is TID/DRN value unique across AS? What do you mean by "unique across AS"? --brian > > Regards, > Saraswati. > > > _________________________________________________________________ > > [1]Yahoo! Music Unlimited - Access over 1 million songs. Try it free. > > References > > 1. http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yahoo.com/unlimited/ -- 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 Nov 30 09:12:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSh5-0000H9-8d; Wed, 30 Nov 2005 09:12:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSh3-0000Aj-KL for sigtran@megatron.ietf.org; Wed, 30 Nov 2005 09:12:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20586 for ; Wed, 30 Nov 2005 09:11:36 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[1SBeqB7rnioqQ41QufNyddN+sDd3EGgK]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhT1L-0004MJ-KW for Sigtran@ietf.org; Wed, 30 Nov 2005 09:33:20 -0500 Received: from ns.pigworks.openss7.net (IDENT:4ydGOmTqzmRGruz7McUdDFs9q6XO58dl@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAUECJA00867; Wed, 30 Nov 2005 07:12:19 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAUECJn22678; Wed, 30 Nov 2005 07:12:19 -0700 Date: Wed, 30 Nov 2005 07:12:18 -0700 From: "Brian F. G. Bidulock" To: Sergey Mikhailov Subject: Re: [Sigtran] AS state change (as defined for M3UA) Message-ID: <20051130071218.B22399@openss7.org> Mail-Followup-To: Sergey Mikhailov , SIGTRAN References: <011201c5f5b5$661c17d0$150f0f0a@smikhailov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <011201c5f5b5$661c17d0$150f0f0a@smikhailov>; from smikhailov@linkbit.com on Wed, Nov 30, 2005 at 04:52:55PM +0300 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id jAUECJA00867 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, On Wed, 30 Nov 2005, Sergey Mikhailov wrote: >=20 > Hi, >=20 >=20 >=20 > It seems that RFC3332 is not clear enough about AS state chan= ge > (Section 4.3.2, Figure 4): >=20 See the new diagram in the I-G and rfc3332bis. --brian --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 30 09:13:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhShn-0000nq-Eo; Wed, 30 Nov 2005 09:13:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhShm-0000n9-2M for sigtran@megatron.ietf.org; Wed, 30 Nov 2005 09:13:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20779 for ; Wed, 30 Nov 2005 09:12:21 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhT1y-0004OG-RY for Sigtran@ietf.org; Wed, 30 Nov 2005 09:34:04 -0500 Received: from smikhailov (vallitek.ll.edunet.ru [213.184.131.30]) by linkbit2.linkbit.com (8.13.3/8.13.3) with SMTP id jAUEBfcn042603 for ; Wed, 30 Nov 2005 06:11:48 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <005401c5f5b8$145612e0$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: "SIGTRAN" Date: Wed, 30 Nov 2005 17:12:03 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.86.1/1198/Tue Nov 29 02:05:20 2005 on linkbit2 X-Virus-Status: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Sigtran] AS state change (as defined for M3UA) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1907675418==" Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1907675418== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C5F5D1.2F0EDB80" This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C5F5D1.2F0EDB80 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable (continue) Of course, the same applies to transition from AS-ACTIVE to AS-PENDING = (RFC3332, Section 4.3.2, Figure 4): 'Last ACTIVE ASP trans to ASP-INACTIVE or ASP-DOWN' is probably wrong = for Loadshare mode. Sergey Mikhailov. ------=_NextPart_000_0051_01C5F5D1.2F0EDB80 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
(continue)
 
Of course, the same applies to = transition from=20 AS-ACTIVE to AS-PENDING (RFC3332, Section 4.3.2, Figure 4):
'Last ACTIVE ASP trans to ASP-INACTIVE = or ASP-DOWN'=20 is probably wrong for Loadshare mode.
 
 
Sergey = Mikhailov.
------=_NextPart_000_0051_01C5F5D1.2F0EDB80-- --===============1907675418== 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 --===============1907675418==-- From sigtran-bounces@ietf.org Wed Nov 30 09:20:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSpJ-0005xl-S2; Wed, 30 Nov 2005 09:20:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSpI-0005xf-DU for sigtran@megatron.ietf.org; Wed, 30 Nov 2005 09:20:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21923 for ; Wed, 30 Nov 2005 09:20:07 -0500 (EST) Received: from [192.217.199.58] (helo=linkbit2.linkbit.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhT9Z-0004jz-Nm for Sigtran@ietf.org; Wed, 30 Nov 2005 09:41:51 -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 jAUEJlEr042641; Wed, 30 Nov 2005 06:19:55 -0800 (PST) (envelope-from smikhailov@linkbit.com) Message-ID: <006201c5f5b9$363d0250$150f0f0a@smikhailov> From: "Sergey Mikhailov" To: References: <011201c5f5b5$661c17d0$150f0f0a@smikhailov> <20051130071218.B22399@openss7.org> Subject: Re: [Sigtran] AS state change (as defined for M3UA) Date: Wed, 30 Nov 2005 17:20:13 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on linkbit2.linkbit.com X-Scanned-By: MIMEDefang 2.49 on 192.168.10.6 X-Virus-Scanned: ClamAV 0.86.1/1198/Tue Nov 29 02:05:20 2005 on linkbit2 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by linkbit2.linkbit.com id jAUEJlEr042641 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org That's right. Thank you. Regards, Sergey Mikhailov. ----- Original Message -----=20 From: "Brian F. G. Bidulock" To: "Sergey Mikhailov" Cc: "SIGTRAN" Sent: Wednesday, November 30, 2005 5:12 PM Subject: Re: [Sigtran] AS state change (as defined for M3UA) > Sergey, > > On Wed, 30 Nov 2005, Sergey Mikhailov wrote: > >> >> Hi, >> >> >> >> It seems that RFC3332 is not clear enough about AS state cha= nge >> (Section 4.3.2, Figure 4): >> > > See the new diagram in the I-G and rfc3332bis. > > --brian > > > --=20 > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 > bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 > http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 > =A6 Therefore all progress depends on the =A6 > =A6 unreasonable man. -- George Bernard Shaw =A6 >=20 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Nov 30 09:21:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSpT-0005yW-AE; Wed, 30 Nov 2005 09:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSpR-0005yL-2u for sigtran@megatron.ietf.org; Wed, 30 Nov 2005 09:21:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21933 for ; Wed, 30 Nov 2005 09:20:16 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[2DDebGCot589NbwYP9utmBCwICRCFNgo]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhT9i-0004kX-Ai for Sigtran@ietf.org; Wed, 30 Nov 2005 09:41:59 -0500 Received: from ns.pigworks.openss7.net (IDENT:NgvMz3+tkFM5ye4SnVDmYh8OHUDCVtBM@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAUEKvA01076; Wed, 30 Nov 2005 07:20:57 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAUEKvR22923; Wed, 30 Nov 2005 07:20:57 -0700 Date: Wed, 30 Nov 2005 07:20:57 -0700 From: "Brian F. G. Bidulock" To: Sergey Mikhailov Subject: Re: [Sigtran] AS state change (as defined for M3UA) Message-ID: <20051130072057.A22865@openss7.org> Mail-Followup-To: Sergey Mikhailov , SIGTRAN References: <005401c5f5b8$145612e0$150f0f0a@smikhailov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <005401c5f5b8$145612e0$150f0f0a@smikhailov>; from smikhailov@linkbit.com on Wed, Nov 30, 2005 at 05:12:03PM +0300 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id jAUEKvA01076 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: SIGTRAN X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Sergey, Its an illustration. See the illustration in the I-G or rfc3332bis and see if you like that one better. --brian On Wed, 30 Nov 2005, Sergey Mikhailov wrote: >=20 > (continue) >=20 >=20 >=20 > Of course, the same applies to transition from AS-ACTIVE to AS-PENDI= NG > (RFC3332, Section 4.3.2, Figure 4): >=20 > 'Last ACTIVE ASP trans to ASP-INACTIVE or ASP-DOWN' is probably wro= ng > for Loadshare mode. >=20 >=20 >=20 >=20 >=20 > Sergey Mikhailov. > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran