From deepak.gunjal@aricent.com Fri Oct 9 02:22:08 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C21C28C1BA for ; Fri, 9 Oct 2009 02:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.016 X-Spam-Level: * X-Spam-Status: No, score=1.016 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pJdwIVoB3ud for ; Fri, 9 Oct 2009 02:22:04 -0700 (PDT) Received: from jaguar.aricent.com (inoutbound.aricent.com [125.21.164.247]) by core3.amsl.com (Postfix) with ESMTP id 3F6623A6867 for ; Fri, 9 Oct 2009 02:22:02 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id n9997FlO010486 for ; Fri, 9 Oct 2009 14:37:15 +0530 Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id n9997EAo010443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Fri, 9 Oct 2009 14:37:15 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Fri, 9 Oct 2009 14:53:43 +0530 From: Deepak Gunjal To: "sigtran@ietf.org" Date: Fri, 9 Oct 2009 14:53:42 +0530 Thread-Topic: In IPSP-IPSP mode what should be the behavior on receving Notify(AS-PENDING) when AS is already AS-ACTIVE Thread-Index: AcpIwjGL2jb8n+4nT+i1cB/uzqsxPQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BDF44534797E3E46B55F3D12DE0C4BC40322075AD7GUREXMB01ASIA_" MIME-Version: 1.0 Subject: [Sigtran] In IPSP-IPSP mode what should be the behavior on receving Notify(AS-PENDING) when AS is already AS-ACTIVE X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 11:27:46 -0000 --_000_BDF44534797E3E46B55F3D12DE0C4BC40322075AD7GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Here is the brief description: I am running my application emulating the role of a AS having 2 ASP in over= ride mode. Out of 2 ASP one ASP is ACTIVE and other is down. My application has sent the ASP-ACTIVE to peer IPSP node and received the N= otify(AS-ACTIVE). Now I restarted the IP network services and as a result r= emote IPSP node marks the state of my AS as down and sends an Notify(AS-PEN= DING) which my M3UA stack treats as "UNEXPECTED" message and does nothing a= s it has not received any notification from SCTP that connection was down s= o it keeps the local AS ACTIVE and responds with ERROR message with error = code "UNEXPECTED message". My question is what should be my behavior when AS-PENDING is received? Regards Deepak ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." --_000_BDF44534797E3E46B55F3D12DE0C4BC40322075AD7GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Here is the brief description:<= /p>

 

I am running my application emulating the role of a AS h= aving 2 ASP in override mode. Out of 2 ASP one ASP is ACTIVE and other is d= own.

 

My application has sent the ASP-ACTIVE to peer IPSP node= and received the Notify(AS-ACTIVE). Now I restarted the IP network service= s and as a result remote IPSP node marks the state of my AS as down and sends an Notify(AS-PENDING) whic= h my M3UA stack treats as “UNEXPECTED” message and does nothing= as it has not received any notification from SCTP that connection was down= so it keeps the local AS ACTIVE and responds with ERROR  message with error code “UNEXPECTED message”.=

 

My question is what should be my behavior when AS-PENDIN= G is received?

 

Regards

Deepak



"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error,please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly proh= ibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
--_000_BDF44534797E3E46B55F3D12DE0C4BC40322075AD7GUREXMB01ASIA_-- From ashwani.grps@gmail.com Fri Oct 9 06:00:59 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058AE28C0FD for ; Fri, 9 Oct 2009 06:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.724 X-Spam-Level: X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjMqK0WkfO3d for ; Fri, 9 Oct 2009 06:00:58 -0700 (PDT) Received: from mail-yw0-f189.google.com (mail-yw0-f189.google.com [209.85.211.189]) by core3.amsl.com (Postfix) with ESMTP id 07A4A3A68F6 for ; Fri, 9 Oct 2009 06:00:57 -0700 (PDT) Received: by ywh27 with SMTP id 27so121316ywh.31 for ; Fri, 09 Oct 2009 06:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fwsVe5WH8HmVeGS3P4xjxPj3Gmkc1MC9WklZq/73cKA=; b=INELx6aY5NufN6s0jdathFBcyURPGgG5PVq7uS2BM/eb5o/Yo7g/qulz0Mp9uxbZPC 3u0cd6PvInVBHQELKjZSmpKUNTG09xaef+MOCjOjUV9kIhb5Mq4qtXI5aCZDuJOxmAnF YeLHNP/3zysPSNiQ0nKe++QOhDtMGqwgmWU0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qLfaE+oTON4JdssTNhpeHGmZFGwvLHN01UYcVbhzruE5ymbeVaRCdgy91AZ+TW3F47 JtTjwCqgp6WiezuMraMyueSMlNjp5IZT4fdIXDl+a5BaMunxLWQ4RE3A4HdPvZVdt99b P8ZL2DYmon0Ujm94KAHJkFZqhLdeIeTRfYHV4= MIME-Version: 1.0 Received: by 10.150.89.2 with SMTP id m2mr4756671ybb.73.1255093358622; Fri, 09 Oct 2009 06:02:38 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Oct 2009 18:32:38 +0530 Message-ID: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> From: Ashwani Kathuria To: Deepak Gunjal Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on receving Notify(AS-PENDING) when AS is already AS-ACTIVE X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 13:00:59 -0000 Hi Deepak, I think your M3UA stack is correct in sending the Error message but your underlying SCTP should send=A0some restart or down indication to your M3UA stack. 5.2.1.=A0 1+1 Sparing, Withdrawal of ASP, Backup Override ... =A0=A0 Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., =A0=A0 M3UA heartbeat loss or detection of SCTP failure), the initial ASP =A0=A0 Inactive message exchange (i.e., SGP to ASP1) would not occur. So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but in section 4.3.3 If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or SCTP-RESTART indication primitive from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP_STATUS indication primitive. The state of the ASP will be moved to ASP- DOWN. and in section 4.3.4.5 A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. The question is: As per section 4.3.3 M3UA should change the ASP to DOWN upon detecting SCTP failure and as per section 4.3.4.5 NOTIFY messages are not sent to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to DOWN marked ASPs? -- Ashwani On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal w= rote: > > Hi, > > > > Here is the brief description: > > > > I am running my application emulating the role of a AS having 2 ASP in ov= erride mode. Out of 2 ASP one ASP is ACTIVE and other is down. > > > > My application has sent the ASP-ACTIVE to peer IPSP node and received the= Notify(AS-ACTIVE). Now I restarted the IP network services and as a result= remote IPSP node marks the state of my AS as down and sends an Notify(AS-P= ENDING) which my M3UA stack treats as =93UNEXPECTED=94 message and does not= hing as it has not received any notification from SCTP that connection was = down so it keeps the local AS ACTIVE and responds with ERROR=A0 message wit= h error code =93UNEXPECTED message=94. > > > > My question is what should be my behavior when AS-PENDING is received? > > > > Regards > > Deepak > > ________________________________ > "DISCLAIMER: This message is proprietary to Aricent and is intended solel= y for the use of the individual to whom it is addressed. It may contain pri= vileged or confidential information and should not be circulated or used fo= r any purpose other than for what it is intended. If you have received this= message in error,please notify the originator immediately. If you are not = the intended recipient, you are notified that you are strictly prohibited f= rom using, copying, altering, or disclosing the contents of this message. A= ricent accepts no responsibility for loss or damage arising from the use of= the information transmitted by this email including damage from virus." > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > From deepak.gunjal@aricent.com Fri Oct 9 07:51:35 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5673A68BF for ; Fri, 9 Oct 2009 07:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc1-YUfdH5XE for ; Fri, 9 Oct 2009 07:51:28 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [125.21.164.247]) by core3.amsl.com (Postfix) with ESMTP id BCD833A6883 for ; Fri, 9 Oct 2009 07:51:26 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id n99EadL2023869 for ; Fri, 9 Oct 2009 20:06:39 +0530 Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id n99EaaYk023823 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 9 Oct 2009 20:06:36 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Fri, 9 Oct 2009 20:23:01 +0530 From: Deepak Gunjal To: Ashwani Kathuria Date: Fri, 9 Oct 2009 20:22:59 +0530 Thread-Topic: [Sigtran] In IPSP-IPSP mode what should be the behavior on receiving Notify(AS-PENDING) when AS is already AS-ACTIVE Thread-Index: AcpI4MlmJSWwlMRkQT+RrJ+Jc7KeNAADIV8A Message-ID: References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> In-Reply-To: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BDF44534797E3E46B55F3D12DE0C4BC40322075DA4GUREXMB01ASIA_" MIME-Version: 1.0 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on receiving Notify(AS-PENDING) when AS is already AS-ACTIVE X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 14:51:35 -0000 --_000_BDF44534797E3E46B55F3D12DE0C4BC40322075DA4GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ashwini, Thanks for the response. Now here the problem is that my local SCTP which is nothing but linux kerne= l SCTP (lksctp) has not sent any kind of notification to local M3UA that th= e connection is down due to network restart so my M3UA always assumes that = everything is up and running fine hence takes no action. My peer is Spectra tool emulating the role of IPSP. Now this leads to a situation where both parties assumes they are behaving = correctly and user data can not be exchanged. Strangely Spectra2 though says that ASP is down but it sends the Notify on = the existing connection!! Is there a way out to come out of this loop? As per the RFC and mentioned s= ection by you I could not found a resolve to this situation? Any suggestion= s are welcome. Regards Deepak -----Original Message----- From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] Sent: Friday, October 09, 2009 6:33 PM To: Deepak Gunjal Cc: sigtran@ietf.org Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on rec= eving Notify(AS-PENDING) when AS is already AS-ACTIVE Hi Deepak, I think your M3UA stack is correct in sending the Error message but your underlying SCTP should send some restart or down indication to your M3UA stack. 5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override ... Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., SGP to ASP1) would not occur. So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but in section 4.3.3 If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or SCTP-RESTART indication primitive from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP_STATUS indication primitive. The state of the ASP will be moved to ASP- DOWN. and in section 4.3.4.5 A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. The question is: As per section 4.3.3 M3UA should change the ASP to DOWN upon detecting SCTP failure and as per section 4.3.4.5 NOTIFY messages are not sent to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to DOWN marked ASPs? -- Ashwani On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal w= rote: > > Hi, > > > > Here is the brief description: > > > > I am running my application emulating the role of a AS having 2 ASP in ov= erride mode. Out of 2 ASP one ASP is ACTIVE and other is down. > > > > My application has sent the ASP-ACTIVE to peer IPSP node and received the= Notify(AS-ACTIVE). Now I restarted the IP network services and as a result= remote IPSP node marks the state of my AS as down and sends an Notify(AS-P= ENDING) which my M3UA stack treats as "UNEXPECTED" message and does nothing= as it has not received any notification from SCTP that connection was down= so it keeps the local AS ACTIVE and responds with ERROR message with erro= r code "UNEXPECTED message". > > > > My question is what should be my behavior when AS-PENDING is received? > > > > Regards > > Deepak > > ________________________________ > "DISCLAIMER: This message is proprietary to Aricent and is intended solel= y for the use of the individual to whom it is addressed. It may contain pri= vileged or confidential information and should not be circulated or used fo= r any purpose other than for what it is intended. If you have received this= message in error,please notify the originator immediately. If you are not = the intended recipient, you are notified that you are strictly prohibited f= rom using, copying, altering, or disclosing the contents of this message. A= ricent accepts no responsibility for loss or damage arising from the use of= the information transmitted by this email including damage from virus." > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." --_000_BDF44534797E3E46B55F3D12DE0C4BC40322075DA4GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ashwini,

 

Thanks for the response.

 

Now here the problem is that my local SCTP which is nothing but lin= ux kernel SCTP (lksctp) has not sent any kind of notification to local M3UA= that the connection is down due to network restart so my M3UA always assumes that everything is u= p and running fine hence takes no action.

My peer is Spectra tool emulating the role of IPSP.

 

 

Now this leads to a situation where both parties assumes they are b= ehaving correctly and user data can not be exchanged.

 

Strangely Spectra2 though says that ASP is down but it sends the No= tify on the existing connection!!

 

Is there a way out to come out of this loop? As per the RFC and men= tioned section by you I could not found a resolve to this situation? Any su= ggestions are welcome.

 

Regards

Deepak

 

-----Original Message-----
From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com]
Sent: Friday, October 09, 2009 6:33 PM
To: Deepak Gunjal
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on rec= eving Notify(AS-PENDING) when AS is already AS-ACTIVE

 

Hi Deepak,

 

I think your M3UA stack is correct in sending the Error message but=

your underlying SCTP should send some restart or down indicati= on to

your M3UA stack.

 

5.2.1.  1+1 Sparing, Withdrawal of ASP, Backup Override

...

   Note: If the SGP M3UA layer detects the loss of the M3= UA peer (e.g.,

   M3UA heartbeat loss or detection of SCTP failure), the= initial ASP

   Inactive message exchange (i.e., SGP to ASP1) would no= t occur.

 

So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but=

 

in section 4.3.3

   If the M3UA layer subsequently receives an SCTP-COMMUN= ICATION_DOWN or

   SCTP-RESTART indication primitive from the underlying = SCTP layer, it

   will inform the Layer Management by invoking the M-SCT= P_STATUS

   indication primitive.  The state of the ASP will = be moved to ASP-

   DOWN.

and in section 4.3.4.5

   A Notify message reflecting a change in the AS state M= UST be sent to

   all ASPs in the AS, except those in the ASP-DOWN state= , with

   appropriate Status Information and any ASP Identifier = of the failed

   ASP.

 

The question is:

As per section 4.3.3 M3UA should change the ASP to DOWN upon detect= ing

SCTP failure and as per section 4.3.4.5 NOTIFY messages are not sen= t

to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to D= OWN

marked ASPs?

 

-- Ashwani

 

 

On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal <deepak.gunjal@ari= cent.com> wrote:

> 

> Hi,

> 

> 

> 

> Here is the brief description:

> 

> 

> 

> I am running my application emulating the role of a AS having = 2 ASP in override mode. Out of 2 ASP one ASP is ACTIVE and other is down.

> 

> 

> 

> My application has sent the ASP-ACTIVE to peer IPSP node and r= eceived the Notify(AS-ACTIVE). Now I restarted the IP network services and = as a result remote IPSP node marks the state of my AS as down and sends an Notify(AS-PENDING) which my = M3UA stack treats as “UNEXPECTED” message and does nothing as i= t has not received any notification from SCTP that connection was down so i= t keeps the local AS ACTIVE and responds with ERROR  message with error code “UNEXPECTED message”.=

> 

> 

> 

> My question is what should be my behavior when AS-PENDING is r= eceived?

> 

> 

> 

> Regards

> 

> Deepak

> 

> ________________________________

> "DISCLAIMER: This message is proprietary to Aricent and i= s intended solely for the use of the individual to whom it is addressed. It= may contain privileged or confidential information and should not be circulated or used for any purpose other tha= n for what it is intended. If you have received this message in error,pleas= e notify the originator immediately. If you are not the intended recipient,= you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of th= is message. Aricent accepts no responsibility for loss or damage arising fr= om the use of the information transmitted by this email including damage fr= om virus."

> 

> _______________________________________________

> Sigtran mailing list

> Sigtran@ietf.org

> https://www.ietf.org/mailman/listinfo/sigtran

> 



"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error,please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly proh= ibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
--_000_BDF44534797E3E46B55F3D12DE0C4BC40322075DA4GUREXMB01ASIA_-- From bidulock@openss7.org Fri Oct 9 12:33:53 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042383A6782 for ; Fri, 9 Oct 2009 12:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR6EWPGpgC1m for ; Fri, 9 Oct 2009 12:33:51 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 9CD363A6839 for ; Fri, 9 Oct 2009 12:33:51 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:VwqghYs/lxkuo58rJY5bAT9OHDTwkyBa@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n99JZQ32008532; Fri, 9 Oct 2009 13:35:26 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:dpAXVw/iGYAupuZJgwEn90KAkZBcwhQ3@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n99JZQ3b005827; Fri, 9 Oct 2009 13:35:26 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n99JZPxQ005826; Fri, 9 Oct 2009 13:35:25 -0600 Date: Fri, 9 Oct 2009 13:35:25 -0600 From: "Brian F. G. Bidulock" To: Deepak Gunjal Message-ID: <20091009193525.GA375@openss7.org> Mail-Followup-To: Deepak Gunjal , Ashwani Kathuria , "sigtran@ietf.org" References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on receiving Notify(AS-PENDING) when AS is already AS-ACTIVE X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 19:33:53 -0000 Deepak, An SCTP that cannot provide SCTP RI is not usable for SIGTRAN for this very reason. --brian Deepak Gunjal wrote: (Fri, 09 Oct 2009 20:22:59) > > Hi Ashwini, > > > Thanks for the response. > > > Now here the problem is that my local SCTP which is nothing but linux > kernel SCTP (lksctp) has not sent any kind of notification to local > M3UA that the connection is down due to network restart so my M3UA > always assumes that everything is up and running fine hence takes no > action. > > My peer is Spectra tool emulating the role of IPSP. > > > > Now this leads to a situation where both parties assumes they are > behaving correctly and user data can not be exchanged. > > > Strangely Spectra2 though says that ASP is down but it sends the > Notify on the existing connection!! > > > Is there a way out to come out of this loop? As per the RFC and > mentioned section by you I could not found a resolve to this > situation? Any suggestions are welcome. > > > Regards > > Deepak > > > -----Original Message----- > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > Sent: Friday, October 09, 2009 6:33 PM > To: Deepak Gunjal > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior > on receving Notify(AS-PENDING) when AS is already AS-ACTIVE > > > Hi Deepak, > > > I think your M3UA stack is correct in sending the Error message but > > your underlying SCTP should send some restart or down indication to > > your M3UA stack. > > > 5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override > > ... > > Note: If the SGP M3UA layer detects the loss of the M3UA peer > (e.g., > > M3UA heartbeat loss or detection of SCTP failure), the initial ASP > > Inactive message exchange (i.e., SGP to ASP1) would not occur. > > > So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but > > > in section 4.3.3 > > If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN > or > > SCTP-RESTART indication primitive from the underlying SCTP layer, > it > > will inform the Layer Management by invoking the M-SCTP_STATUS > > indication primitive. The state of the ASP will be moved to ASP- > > DOWN. > > and in section 4.3.4.5 > > A Notify message reflecting a change in the AS state MUST be sent > to > > all ASPs in the AS, except those in the ASP-DOWN state, with > > appropriate Status Information and any ASP Identifier of the failed > > ASP. > > > The question is: > > As per section 4.3.3 M3UA should change the ASP to DOWN upon detecting > > SCTP failure and as per section 4.3.4.5 NOTIFY messages are not sent > > to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to DOWN > > marked ASPs? > > > -- Ashwani > > > > On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal > wrote: > > > > > > Hi, > > > > > > > > > > > > Here is the brief description: > > > > > > > > > > > > I am running my application emulating the role of a AS having 2 ASP > in override mode. Out of 2 ASP one ASP is ACTIVE and other is down. > > > > > > > > > > > > My application has sent the ASP-ACTIVE to peer IPSP node and > received the Notify(AS-ACTIVE). Now I restarted the IP network > services and as a result remote IPSP node marks the state of my AS as > down and sends an Notify(AS-PENDING) which my M3UA stack treats as > "UNEXPECTED" message and does nothing as it has not received any > notification from SCTP that connection was down so it keeps the local > AS ACTIVE and responds with ERROR message with error code "UNEXPECTED > message". > > > > > > > > > > > > My question is what should be my behavior when AS-PENDING is > received? > > > > > > > > > > > > Regards > > > > > > Deepak > > > > > > ________________________________ > > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error,please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, > altering, or disclosing the contents of this message. Aricent accepts > no responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www.ietf.org/mailman/listinfo/sigtran > > > > _________________________________________________________________ > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error,please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, > altering, or disclosing the contents of this message. Aricent accepts > no responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From ashwani.grps@gmail.com Sun Oct 11 23:11:13 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9290B28C0FA for ; Sun, 11 Oct 2009 23:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQUgq2EpEfyk for ; Sun, 11 Oct 2009 23:11:12 -0700 (PDT) Received: from mail-yx0-f199.google.com (mail-yx0-f199.google.com [209.85.210.199]) by core3.amsl.com (Postfix) with ESMTP id 411C828C0F0 for ; Sun, 11 Oct 2009 23:11:11 -0700 (PDT) Received: by yxe37 with SMTP id 37so2549145yxe.31 for ; Sun, 11 Oct 2009 23:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ssGpMVYOQtlBU+jCfOaWqkx2vkoV7K5wBX6PzQoiOdc=; b=Q0xmEZ5AfBDcL9T5PySCkIUbYO7OnwygQUrGaKfAlzauI5H2NRqVOcZuPQlb4glv8g iOGNEaIPkkzSM+vT2brF4ZDNMTssbBDLeOPKRKjdKQXwRWY1X5jvZtk8MGyA+b57c9vj DR3SqGVwkj4iNtMN0qsVKscJ7LubXPqaJNUTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=uKT29ltUVxckPRty377OpO7Jtg+EIpBIml16rzXsXoSnGS1aN7b07PyZM4meV8v2nT tkfa26Df0OkjiX3OkRenshe7cbEowTnUAu3MzLz4G5MJh/bDDR+W6B9GclLBJgoFn91u GsI6d6GhLC6sWPGnek3R1v/mn6SsgBzJii9fw= MIME-Version: 1.0 Received: by 10.150.214.11 with SMTP id m11mr9474156ybg.130.1255327869002; Sun, 11 Oct 2009 23:11:09 -0700 (PDT) In-Reply-To: <20091009193525.GA375@openss7.org> References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> <20091009193525.GA375@openss7.org> Date: Mon, 12 Oct 2009 11:41:08 +0530 Message-ID: <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> From: Ashwani Kathuria To: bidulock@openss7.org, Deepak Gunjal , Ashwani Kathuria , "sigtran@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on receiving Notify(AS-PENDING) when AS is already AS-ACTIVE X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 06:11:13 -0000 Deepak: Are you using the latest version of Linux kernel SCTP available. If yes, you can raise this this issue with them else try using latest version. --Ashwani On Sat, Oct 10, 2009 at 1:05 AM, Brian F. G. Bidulock wrote: > Deepak, > > An SCTP that cannot provide SCTP RI is not usable for > SIGTRAN for this very reason. > > --brian > > Deepak Gunjal wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Fri= , 09 Oct 2009 20:22:59) >> >> =A0 =A0Hi Ashwini, >> >> >> =A0 =A0Thanks for the response. >> >> >> =A0 =A0Now here the problem is that my local SCTP which is nothing but l= inux >> =A0 =A0kernel SCTP (lksctp) has not sent any kind of notification to loc= al >> =A0 =A0M3UA that the connection is down due to network restart so my M3U= A >> =A0 =A0always assumes that everything is up and running fine hence takes= no >> =A0 =A0action. >> >> =A0 =A0My peer is Spectra tool emulating the role of IPSP. >> >> >> >> =A0 =A0Now this leads to a situation where both parties assumes they are >> =A0 =A0behaving correctly and user data can not be exchanged. >> >> >> =A0 =A0Strangely Spectra2 though says that ASP is down but it sends the >> =A0 =A0Notify on the existing connection!! >> >> >> =A0 =A0Is there a way out to come out of this loop? As per the RFC and >> =A0 =A0mentioned section by you I could not found a resolve to this >> =A0 =A0situation? Any suggestions are welcome. >> >> >> =A0 =A0Regards >> >> =A0 =A0Deepak >> >> >> =A0 =A0-----Original Message----- >> =A0 =A0From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] >> =A0 =A0Sent: Friday, October 09, 2009 6:33 PM >> =A0 =A0To: Deepak Gunjal >> =A0 =A0Cc: sigtran@ietf.org >> =A0 =A0Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behav= ior >> =A0 =A0on receving Notify(AS-PENDING) when AS is already AS-ACTIVE >> >> >> =A0 =A0Hi Deepak, >> >> >> =A0 =A0I think your M3UA stack is correct in sending the Error message b= ut >> >> =A0 =A0your underlying SCTP should send some restart or down indication = to >> >> =A0 =A0your M3UA stack. >> >> >> =A0 =A05.2.1. =A01+1 Sparing, Withdrawal of ASP, Backup Override >> >> =A0 =A0... >> >> =A0 =A0 =A0 Note: If the SGP M3UA layer detects the loss of the M3UA pee= r >> =A0 =A0(e.g., >> >> =A0 =A0 =A0 M3UA heartbeat loss or detection of SCTP failure), the initi= al ASP >> >> =A0 =A0 =A0 Inactive message exchange (i.e., SGP to ASP1) would not occu= r. >> >> >> =A0 =A0So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages b= ut >> >> >> =A0 =A0in section 4.3.3 >> >> =A0 =A0 =A0 If the M3UA layer subsequently receives an SCTP-COMMUNICATIO= N_DOWN >> =A0 =A0or >> >> =A0 =A0 =A0 SCTP-RESTART indication primitive from the underlying SCTP l= ayer, >> =A0 =A0it >> >> =A0 =A0 =A0 will inform the Layer Management by invoking the M-SCTP_STAT= US >> >> =A0 =A0 =A0 indication primitive. =A0The state of the ASP will be moved = to ASP- >> >> =A0 =A0 =A0 DOWN. >> >> =A0 =A0and in section 4.3.4.5 >> >> =A0 =A0 =A0 A Notify message reflecting a change in the AS state MUST be= sent >> =A0 =A0to >> >> =A0 =A0 =A0 all ASPs in the AS, except those in the ASP-DOWN state, with >> >> =A0 =A0 =A0 appropriate Status Information and any ASP Identifier of the= failed >> >> =A0 =A0 =A0 ASP. >> >> >> =A0 =A0The question is: >> >> =A0 =A0As per section 4.3.3 M3UA should change the ASP to DOWN upon dete= cting >> >> =A0 =A0SCTP failure and as per section 4.3.4.5 NOTIFY messages are not s= ent >> >> =A0 =A0to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to= DOWN >> >> =A0 =A0marked ASPs? >> >> >> =A0 =A0-- Ashwani >> >> >> >> =A0 =A0On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal >> =A0 =A0 wrote: >> >> =A0 =A0> >> >> =A0 =A0> Hi, >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> Here is the brief description: >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> I am running my application emulating the role of a AS having 2= ASP >> =A0 =A0in override mode. Out of 2 ASP one ASP is ACTIVE and other is dow= n. >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> My application has sent the ASP-ACTIVE to peer IPSP node and >> =A0 =A0received the Notify(AS-ACTIVE). Now I restarted the IP network >> =A0 =A0services and as a result remote IPSP node marks the state of my A= S as >> =A0 =A0down and sends an Notify(AS-PENDING) which my M3UA stack treats a= s >> =A0 =A0"UNEXPECTED" message and does nothing as it has not received any >> =A0 =A0notification from SCTP that connection was down so it keeps the l= ocal >> =A0 =A0AS ACTIVE and responds with ERROR =A0message with error code "UNE= XPECTED >> =A0 =A0message". >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> My question is what should be my behavior when AS-PENDING is >> =A0 =A0received? >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> Regards >> >> =A0 =A0> >> >> =A0 =A0> Deepak >> >> =A0 =A0> >> >> =A0 =A0> ________________________________ >> >> =A0 =A0> "DISCLAIMER: This message is proprietary to Aricent and is inte= nded >> =A0 =A0solely for the use of the individual to whom it is addressed. It = may >> =A0 =A0contain privileged or confidential information and should not be >> =A0 =A0circulated or used for any purpose other than for what it is inte= nded. >> =A0 =A0If you have received this message in error,please notify the >> =A0 =A0originator immediately. If you are not the intended recipient, yo= u are >> =A0 =A0notified that you are strictly prohibited from using, copying, >> =A0 =A0altering, or disclosing the contents of this message. Aricent acc= epts >> =A0 =A0no responsibility for loss or damage arising from the use of the >> =A0 =A0information transmitted by this email including damage from virus= ." >> >> =A0 =A0> >> >> =A0 =A0> _______________________________________________ >> >> =A0 =A0> Sigtran mailing list >> >> =A0 =A0> Sigtran@ietf.org >> >> =A0 =A0> https://www.ietf.org/mailman/listinfo/sigtran >> >> =A0 =A0> >> =A0 =A0 =A0_____________________________________________________________= ____ >> >> =A0 =A0"DISCLAIMER: This message is proprietary to Aricent and is intend= ed >> =A0 =A0solely for the use of the individual to whom it is addressed. It = may >> =A0 =A0contain privileged or confidential information and should not be >> =A0 =A0circulated or used for any purpose other than for what it is inte= nded. >> =A0 =A0If you have received this message in error,please notify the >> =A0 =A0originator immediately. If you are not the intended recipient, yo= u are >> =A0 =A0notified that you are strictly prohibited from using, copying, >> =A0 =A0altering, or disclosing the contents of this message. Aricent acc= epts >> =A0 =A0no responsibility for loss or damage arising from the use of the >> =A0 =A0information transmitted by this email including damage from virus= ." > >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > From deepak.gunjal@aricent.com Sun Oct 11 23:23:53 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7418328C0E6 for ; Sun, 11 Oct 2009 23:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjNf2tGAWhuz for ; Sun, 11 Oct 2009 23:23:52 -0700 (PDT) Received: from jaguar.aricent.com (inoutbound.aricent.com [125.21.164.247]) by core3.amsl.com (Postfix) with ESMTP id 5B3713A6407 for ; Sun, 11 Oct 2009 23:23:51 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id D157436B8F; Mon, 12 Oct 2009 11:52:00 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id C59C136B7E; Mon, 12 Oct 2009 11:52:00 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Mon, 12 Oct 2009 11:53:48 +0530 From: Deepak Gunjal To: Ashwani Kathuria , "bidulock@openss7.org" , "sigtran@ietf.org" Date: Mon, 12 Oct 2009 11:53:46 +0530 Thread-Topic: [Sigtran] In IPSP-IPSP mode what should be the behavior on receiving Notify(AS-PENDING) when AS is already AS-ACTIVE Thread-Index: AcpLAs0y93RvKD37RjqqhpYWch4qmgAAWagg Message-ID: References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> In-Reply-To: <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on receiving Notify(AS-PENDING) when AS is already AS-ACTIVE X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 06:23:53 -0000 Hi, We are not using the latest version of the lksctp. It is the version 1.0.2 = which is being used in our product. I can certainly think of moving to newer version but before that just wante= d to confirm if I am not missing something at my end either at M3UA stack o= r at Application level? Regards Deepak -----Original Message----- From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] Sent: Monday, October 12, 2009 11:41 AM To: bidulock@openss7.org; Deepak Gunjal; Ashwani Kathuria; sigtran@ietf.org Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on rec= eiving Notify(AS-PENDING) when AS is already AS-ACTIVE Deepak: Are you using the latest version of Linux kernel SCTP available. If yes, you can raise this this issue with them else try using latest version. --Ashwani On Sat, Oct 10, 2009 at 1:05 AM, Brian F. G. Bidulock wrote: > Deepak, > > An SCTP that cannot provide SCTP RI is not usable for > SIGTRAN for this very reason. > > --brian > > Deepak Gunjal wrote: (Fri, 09 Oct 2009 20:22:59) >> >> Hi Ashwini, >> >> >> Thanks for the response. >> >> >> Now here the problem is that my local SCTP which is nothing but linux >> kernel SCTP (lksctp) has not sent any kind of notification to local >> M3UA that the connection is down due to network restart so my M3UA >> always assumes that everything is up and running fine hence takes no >> action. >> >> My peer is Spectra tool emulating the role of IPSP. >> >> >> >> Now this leads to a situation where both parties assumes they are >> behaving correctly and user data can not be exchanged. >> >> >> Strangely Spectra2 though says that ASP is down but it sends the >> Notify on the existing connection!! >> >> >> Is there a way out to come out of this loop? As per the RFC and >> mentioned section by you I could not found a resolve to this >> situation? Any suggestions are welcome. >> >> >> Regards >> >> Deepak >> >> >> -----Original Message----- >> From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] >> Sent: Friday, October 09, 2009 6:33 PM >> To: Deepak Gunjal >> Cc: sigtran@ietf.org >> Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior >> on receving Notify(AS-PENDING) when AS is already AS-ACTIVE >> >> >> Hi Deepak, >> >> >> I think your M3UA stack is correct in sending the Error message but >> >> your underlying SCTP should send some restart or down indication to >> >> your M3UA stack. >> >> >> 5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override >> >> ... >> >> Note: If the SGP M3UA layer detects the loss of the M3UA peer >> (e.g., >> >> M3UA heartbeat loss or detection of SCTP failure), the initial ASP >> >> Inactive message exchange (i.e., SGP to ASP1) would not occur. >> >> >> So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but >> >> >> in section 4.3.3 >> >> If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN >> or >> >> SCTP-RESTART indication primitive from the underlying SCTP layer, >> it >> >> will inform the Layer Management by invoking the M-SCTP_STATUS >> >> indication primitive. The state of the ASP will be moved to ASP- >> >> DOWN. >> >> and in section 4.3.4.5 >> >> A Notify message reflecting a change in the AS state MUST be sent >> to >> >> all ASPs in the AS, except those in the ASP-DOWN state, with >> >> appropriate Status Information and any ASP Identifier of the faile= d >> >> ASP. >> >> >> The question is: >> >> As per section 4.3.3 M3UA should change the ASP to DOWN upon detectin= g >> >> SCTP failure and as per section 4.3.4.5 NOTIFY messages are not sent >> >> to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to DOW= N >> >> marked ASPs? >> >> >> -- Ashwani >> >> >> >> On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal >> wrote: >> >> > >> >> > Hi, >> >> > >> >> > >> >> > >> >> > Here is the brief description: >> >> > >> >> > >> >> > >> >> > I am running my application emulating the role of a AS having 2 ASP >> in override mode. Out of 2 ASP one ASP is ACTIVE and other is down. >> >> > >> >> > >> >> > >> >> > My application has sent the ASP-ACTIVE to peer IPSP node and >> received the Notify(AS-ACTIVE). Now I restarted the IP network >> services and as a result remote IPSP node marks the state of my AS as >> down and sends an Notify(AS-PENDING) which my M3UA stack treats as >> "UNEXPECTED" message and does nothing as it has not received any >> notification from SCTP that connection was down so it keeps the local >> AS ACTIVE and responds with ERROR message with error code "UNEXPECTE= D >> message". >> >> > >> >> > >> >> > >> >> > My question is what should be my behavior when AS-PENDING is >> received? >> >> > >> >> > >> >> > >> >> > Regards >> >> > >> >> > Deepak >> >> > >> >> > ________________________________ >> >> > "DISCLAIMER: This message is proprietary to Aricent and is intended >> solely for the use of the individual to whom it is addressed. It may >> contain privileged or confidential information and should not be >> circulated or used for any purpose other than for what it is intended= . >> If you have received this message in error,please notify the >> originator immediately. If you are not the intended recipient, you ar= e >> notified that you are strictly prohibited from using, copying, >> altering, or disclosing the contents of this message. Aricent accepts >> no responsibility for loss or damage arising from the use of the >> information transmitted by this email including damage from virus." >> >> > >> >> > _______________________________________________ >> >> > Sigtran mailing list >> >> > Sigtran@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/sigtran >> >> > >> _________________________________________________________________ >> >> "DISCLAIMER: This message is proprietary to Aricent and is intended >> solely for the use of the individual to whom it is addressed. It may >> contain privileged or confidential information and should not be >> circulated or used for any purpose other than for what it is intended= . >> If you have received this message in error,please notify the >> originator immediately. If you are not the intended recipient, you ar= e >> notified that you are strictly prohibited from using, copying, >> altering, or disclosing the contents of this message. Aricent accepts >> no responsibility for loss or damage arising from the use of the >> information transmitted by this email including damage from virus." > >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." From Salil.Agrawal@ccpu.com Thu Oct 15 00:07:39 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4AD3A6988 for ; Thu, 15 Oct 2009 00:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEqnr17omtGU for ; Thu, 15 Oct 2009 00:07:39 -0700 (PDT) Received: from sd-smtp.ccpu.com (sd-smtp.ccpu.com [65.44.201.8]) by core3.amsl.com (Postfix) with ESMTP id 3032B3A68FF for ; Thu, 15 Oct 2009 00:07:38 -0700 (PDT) Received: from sd-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id ECBB5620A03 for ; Thu, 15 Oct 2009 00:07:37 -0700 (PDT) Received: from alladin.ccpu.com (alladin.ccpu.com [172.16.0.216]) by sd-smtp.ccpu.com (Postfix) with ESMTP id AB6EB6209FA for ; Thu, 15 Oct 2009 00:07:37 -0700 (PDT) Received: from IN-EXCHANGE.ccpu.com ([172.25.0.16]) by alladin.ccpu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 00:07:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 12:37:35 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Abort chunk bundled with data chunk Thread-Index: AcpLAs0y93RvKD37RjqqhpYWch4qmgAAWaggAJfLpAA= References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com><20091009193525.GA375@openss7.org><341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> From: "Salil Agrawal" To: X-OriginalArrivalTime: 15 Oct 2009 07:07:37.0355 (UTC) FILETIME=[2D2F2DB0:01CA4D66] X-TM-AS-Product-Ver: IMSS-7.0.0.3216-5.6.0.1016-16948.003 X-TM-AS-Result: No--6.796-5.0-31-1 X-imss-scan-details: No--6.796-5.0-31-1 Subject: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 07:07:39 -0000 Hi,=20 We have a confusion while understanding the SCTP RFC4960 section 9.1 it says "DATA chunks MUST NOT be bundled with ABORT" so sender must not bundle the data with abort.=20 But the second paragraph states that "An endpoint MUST NOT respond to any received packet that contains an ABORT chunk". Which means if any packet is received at the receiver end where ABORT is bundled with the DATA it should not send any response. Does it mean that for the DATA chunk SACK should not be generated? Please clarify. Thanks, Salil Agrawal From ashwani.grps@gmail.com Thu Oct 15 00:27:50 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4628A3A69BE for ; Thu, 15 Oct 2009 00:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=1.900, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc84-stC-yuw for ; Thu, 15 Oct 2009 00:27:49 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 65C9E3A699E for ; Thu, 15 Oct 2009 00:27:49 -0700 (PDT) Received: by gxk6 with SMTP id 6so597638gxk.13 for ; Thu, 15 Oct 2009 00:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Y7erLF+3IgQE4U3hVAEptFOvSRATKB8Y+AS6kbgbu6U=; b=QgQ+f+R8Fov6/YHueHy98xLYKlh/Q1dAL99rCmS1X53VIl9YXgQHmZ79EWK5oN96xg zI0sUWvOdbwx4WSD0X87avUktu3ETtBa/BFVFM+7OB1VFN32LkmGQ4MsqbM6/e7cwgg6 yEHObAZBFiBTBcmKY97zzXNdIU/v3PWaTUCv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Va6m+i6JkJmDqJHLo0WHlBePWuEnPQ5G/WibuMmwTyMWrmHxtgsrZlS9oydEj8cpyd hWSBBTZ1LJc0c0tp1+FRvqtT5zzHIFgUxKuR/UfgWTfRqkr1d+NFiImDuJ6eLjP/x39o u1iXGKa0C0VWKjty7KyteVDG1cbc4tlR8EpZY= MIME-Version: 1.0 Received: by 10.150.129.13 with SMTP id b13mr16529269ybd.314.1255591669594; Thu, 15 Oct 2009 00:27:49 -0700 (PDT) In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> Date: Thu, 15 Oct 2009 12:57:49 +0530 Message-ID: <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> From: Ashwani Kathuria To: Salil Agrawal Content-Type: text/plain; charset=ISO-8859-1 Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 07:27:50 -0000 Hi Salil, When you are bundling anything (control chunk) with DATA chunk it should be placed before DATA chunks in the SCTP packets. Now if you bundle the ABORT chunk with DATA chunk in a single SCTP packet the ABORT chunk will be processed before DATA chunk and association will be broken down. So, that DATA chunk will have no significance as it's association is now broken by the ABORT chunk placed before it. --Ashwani Kathuria On Thu, Oct 15, 2009 at 12:37 PM, Salil Agrawal wrote: > Hi, > > We have a confusion while understanding the SCTP RFC4960 section 9.1 it > says "DATA chunks MUST NOT be bundled with ABORT" so sender must not > bundle the data with abort. > > But the second paragraph states that "An endpoint MUST NOT respond to > any received packet that contains an ABORT chunk". Which means if any > packet is received at the receiver end where ABORT is bundled with the > DATA it should not send any response. Does it mean that for the DATA > chunk SACK should not be generated? Please clarify. > > Thanks, > Salil Agrawal > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > From Salil.Agrawal@ccpu.com Thu Oct 15 01:16:32 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF823A68C5 for ; Thu, 15 Oct 2009 01:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTe5iooVCPIO for ; Thu, 15 Oct 2009 01:16:31 -0700 (PDT) Received: from sd-smtp.ccpu.com (sd-smtp.ccpu.com [65.44.201.8]) by core3.amsl.com (Postfix) with ESMTP id 9E2263A659C for ; Thu, 15 Oct 2009 01:16:31 -0700 (PDT) Received: from sd-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 71FB5620A03; Thu, 15 Oct 2009 01:16:34 -0700 (PDT) Received: from alladin.ccpu.com (alladin.ccpu.com [172.16.0.216]) by sd-smtp.ccpu.com (Postfix) with ESMTP id 4CEFE6209FA; Thu, 15 Oct 2009 01:16:34 -0700 (PDT) Received: from IN-EXCHANGE.ccpu.com ([172.25.0.16]) by alladin.ccpu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 01:16:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 13:46:31 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Abort chunk bundled with data chunk Thread-Index: AcpNaQOifmB/+6eQRoamzkK5LoNWRwABnErg References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> From: "Salil Agrawal" To: "Ashwani Kathuria" X-OriginalArrivalTime: 15 Oct 2009 08:16:33.0957 (UTC) FILETIME=[CECA8D50:01CA4D6F] X-TM-AS-Product-Ver: IMSS-7.0.0.3216-5.6.0.1016-16948.003 X-TM-AS-Result: No--15.669-5.0-31-1 X-imss-scan-details: No--15.669-5.0-31-1 Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 08:16:32 -0000 Thanks Ashwani,=20 I understand that it does not make any sense to send the SACK, and abort chunk should be the placed before the DATA chunk. But the question is if the ABORT chunk is placed after the DATA chunk in the received packet then should be send the SACK for the DATA or not. Thanks,=20 Salil -----Original Message----- From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com]=20 Sent: Thursday, October 15, 2009 12:58 PM To: Salil Agrawal Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk Hi Salil, When you are bundling anything (control chunk) with DATA chunk it should be placed before DATA chunks in the SCTP packets. Now if you bundle the ABORT chunk with DATA chunk in a single SCTP packet the ABORT chunk will be processed before DATA chunk and association will be broken down. So, that DATA chunk will have no significance as it's association is now broken by the ABORT chunk placed before it. --Ashwani Kathuria On Thu, Oct 15, 2009 at 12:37 PM, Salil Agrawal wrote: > Hi, > > We have a confusion while understanding the SCTP RFC4960 section 9.1 it > says "DATA chunks MUST NOT be bundled with ABORT" so sender must not > bundle the data with abort. > > But the second paragraph states that "An endpoint MUST NOT respond to > any received packet that contains an ABORT chunk". Which means if any > packet is received at the receiver end where ABORT is bundled with the > DATA it should not send any response. Does it mean that for the DATA > chunk SACK should not be generated? Please clarify. > > Thanks, > Salil Agrawal > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > From ashwani.grps@gmail.com Thu Oct 15 01:41:18 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B3E3A67D4 for ; Thu, 15 Oct 2009 01:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg3vYC4HXRFE for ; Thu, 15 Oct 2009 01:41:17 -0700 (PDT) Received: from mail-yw0-f189.google.com (mail-yw0-f189.google.com [209.85.211.189]) by core3.amsl.com (Postfix) with ESMTP id A80953A67A8 for ; Thu, 15 Oct 2009 01:41:16 -0700 (PDT) Received: by ywh27 with SMTP id 27so619558ywh.31 for ; Thu, 15 Oct 2009 01:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zoecFxn7HC1ClhSi/2HsZoWEUXpnkl0sRT4qNdDHdtA=; b=rFPsgG785xwp9OZ7U8CwBXy5jWi+BYlEYpMvcSb2Wwid5O7xHZpwteRdUM6eLWRYYt 0k0j3ed+Yf+BQcnuI0oubsXtt5T5uiQawTGjTeCSxYWO7PwZWfPkHh0Qjdsvmbptwd9q n27E10caSVeVB1prx6hGy8UgdwOsDQJFS6uhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f3YVPLNC0ri7i9NZq/4JqZqV/ZlI/eHIv9EtxyU8PxEacqfQjWisEluHxTnmdTb+hA CMBDZcXFdWdOBHBpCvsLpVOeKM59KB+Cc6fEUplFBlmieHYg/tkxhLqjWi3Yjw1jRQBW 5Ae7xrpCnaNhheSGtUjmGjh6gLKj00hR8PBYw= MIME-Version: 1.0 Received: by 10.150.248.4 with SMTP id v4mr16720067ybh.184.1255596075996; Thu, 15 Oct 2009 01:41:15 -0700 (PDT) In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> Date: Thu, 15 Oct 2009 14:11:15 +0530 Message-ID: <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> From: Ashwani Kathuria To: Salil Agrawal Content-Type: text/plain; charset=ISO-8859-1 Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 08:41:18 -0000 Placing DATA chunk before control chunk (ABORT) makes it an Invalid SCTP packet. --Ashwani Kathuria On Thu, Oct 15, 2009 at 1:46 PM, Salil Agrawal wrote: > Thanks Ashwani, > > I understand that it does not make any sense to send the SACK, and abort > chunk should be the placed before the DATA chunk. But the question is if > the ABORT chunk is placed after the DATA chunk in the received packet > then should be send the SACK for the DATA or not. > > Thanks, > Salil > > > -----Original Message----- > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > Sent: Thursday, October 15, 2009 12:58 PM > To: Salil Agrawal > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Abort chunk bundled with data chunk > > Hi Salil, > > When you are bundling anything (control chunk) with DATA chunk it > should be placed before DATA chunks in the SCTP packets. > Now if you bundle the ABORT chunk with DATA chunk in a single SCTP > packet the ABORT chunk will be processed before DATA chunk and > association will be broken down. > So, that DATA chunk will have no significance as it's association is > now broken by the ABORT chunk placed before it. > > --Ashwani Kathuria > > On Thu, Oct 15, 2009 at 12:37 PM, Salil Agrawal > wrote: >> Hi, >> >> We have a confusion while understanding the SCTP RFC4960 section 9.1 > it >> says "DATA chunks MUST NOT be bundled with ABORT" so sender must not >> bundle the data with abort. >> >> But the second paragraph states that "An endpoint MUST NOT respond to >> any received packet that contains an ABORT chunk". Which means if any >> packet is received at the receiver end where ABORT is bundled with the >> DATA it should not send any response. Does it mean that for the DATA >> chunk SACK should not be generated? Please clarify. >> >> Thanks, >> Salil Agrawal >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran >> > From Salil.Agrawal@ccpu.com Thu Oct 15 01:58:36 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066F03A67FC for ; Thu, 15 Oct 2009 01:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNiOG4C0O8pJ for ; Thu, 15 Oct 2009 01:58:35 -0700 (PDT) Received: from sd-smtp.ccpu.com (sd-smtp.ccpu.com [65.44.201.8]) by core3.amsl.com (Postfix) with ESMTP id 35E4F3A679C for ; Thu, 15 Oct 2009 01:58:35 -0700 (PDT) Received: from sd-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 422F5620A04; Thu, 15 Oct 2009 01:58:35 -0700 (PDT) Received: from alladin.ccpu.com (alladin.ccpu.com [172.16.0.216]) by sd-smtp.ccpu.com (Postfix) with ESMTP id E6183620A03; Thu, 15 Oct 2009 01:58:34 -0700 (PDT) Received: from IN-EXCHANGE.ccpu.com ([172.25.0.16]) by alladin.ccpu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 01:58:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 14:28:32 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Abort chunk bundled with data chunk Thread-Index: AcpNc0YTTxn/PQvAT5ucEQbhQUdVFQAAjnrw References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> From: "Salil Agrawal" To: "Ashwani Kathuria" X-OriginalArrivalTime: 15 Oct 2009 08:58:34.0636 (UTC) FILETIME=[AD3BA4C0:01CA4D75] X-TM-AS-Product-Ver: IMSS-7.0.0.3216-5.6.0.1016-16948.003 X-TM-AS-Result: No--18.773-5.0-31-1 X-imss-scan-details: No--18.773-5.0-31-1 Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 08:58:36 -0000 Hi Ashwani,=20 The question is not that whether DATA chunk should be bundled with the ABORT or not. RFC is very clear about it that the sender should not do in that way but here the question is if we at the receiver end receives the same then what should be the action at the receiver end (should we send the SACK for the DATA or not). Thanks, Salil -----Original Message----- From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com]=20 Sent: Thursday, October 15, 2009 2:11 PM To: Salil Agrawal Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk Placing DATA chunk before control chunk (ABORT) makes it an Invalid SCTP packet. --Ashwani Kathuria On Thu, Oct 15, 2009 at 1:46 PM, Salil Agrawal wrote: > Thanks Ashwani, > > I understand that it does not make any sense to send the SACK, and abort > chunk should be the placed before the DATA chunk. But the question is if > the ABORT chunk is placed after the DATA chunk in the received packet > then should be send the SACK for the DATA or not. > > Thanks, > Salil > > > -----Original Message----- > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > Sent: Thursday, October 15, 2009 12:58 PM > To: Salil Agrawal > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Abort chunk bundled with data chunk > > Hi Salil, > > When you are bundling anything (control chunk) with DATA chunk it > should be placed before DATA chunks in the SCTP packets. > Now if you bundle the ABORT chunk with DATA chunk in a single SCTP > packet the ABORT chunk will be processed before DATA chunk and > association will be broken down. > So, that DATA chunk will have no significance as it's association is > now broken by the ABORT chunk placed before it. > > --Ashwani Kathuria > > On Thu, Oct 15, 2009 at 12:37 PM, Salil Agrawal > wrote: >> Hi, >> >> We have a confusion while understanding the SCTP RFC4960 section 9.1 > it >> says "DATA chunks MUST NOT be bundled with ABORT" so sender must not >> bundle the data with abort. >> >> But the second paragraph states that "An endpoint MUST NOT respond to >> any received packet that contains an ABORT chunk". Which means if any >> packet is received at the receiver end where ABORT is bundled with the >> DATA it should not send any response. Does it mean that for the DATA >> chunk SACK should not be generated? Please clarify. >> >> Thanks, >> Salil Agrawal >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran >> > From ashwani.grps@gmail.com Thu Oct 15 02:00:12 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E49F3A67A1 for ; Thu, 15 Oct 2009 02:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHaUawdjkcHh for ; Thu, 15 Oct 2009 02:00:11 -0700 (PDT) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 1A8773A679C for ; Thu, 15 Oct 2009 02:00:11 -0700 (PDT) Received: by gxk28 with SMTP id 28so633621gxk.9 for ; Thu, 15 Oct 2009 02:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=A42yeqdbLco0c+uE3b7yL81WpOrane9Zb+l8ayf3sFM=; b=W1o1LWPa0A+c24/fP0L0RMbavsn+YEIk8TPsR++T0BFMC0T7EYSQzaeyJdWcLRO3LJ D2B6PcErD1ziTq4JQKtJPQPvHvkSEpuL1vmiWwE2P2hNH7gcLzLwknvFNfK2Cqnm2i93 zhMa15XfXON2Hne1bH17D38+v/50rZzEjJPS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IRRCk2NjZ0uiaNfsqNPKW184+zKwXRIwE9uFpEtu+GA3wrEeiD91knBpMOk0YRU9BW FpjLIksiu7YSEWZA+nSFdNkmqXWc1FSB6rXMZAZus4pj3WaA05qqAUOsomsiIxJJiEoV AUKInmgFgfQdoNL1gF8kxB8nyMqalXZvIxRFw= MIME-Version: 1.0 Received: by 10.150.248.4 with SMTP id v4mr16752913ybh.184.1255597211054; Thu, 15 Oct 2009 02:00:11 -0700 (PDT) In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> References: <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> Date: Thu, 15 Oct 2009 14:30:11 +0530 Message-ID: <341a09720910150200k26967f86y8dd16330261752f8@mail.gmail.com> From: Ashwani Kathuria To: Salil Agrawal Content-Type: text/plain; charset=ISO-8859-1 Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:00:12 -0000 No, SACK should not be sent in such case. On Thu, Oct 15, 2009 at 2:28 PM, Salil Agrawal wrote: > Hi Ashwani, > > The question is not that whether DATA chunk should be bundled with the > ABORT or not. RFC is very clear about it that the sender should not do > in that way but here the question is if we at the receiver end receives > the same then what should be the action at the receiver end (should we > send the SACK for the DATA or not). > > Thanks, > Salil > > -----Original Message----- > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > Sent: Thursday, October 15, 2009 2:11 PM > To: Salil Agrawal > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Abort chunk bundled with data chunk > > Placing DATA chunk before control chunk (ABORT) makes it an Invalid SCTP > packet. > > --Ashwani Kathuria > > On Thu, Oct 15, 2009 at 1:46 PM, Salil Agrawal > wrote: >> Thanks Ashwani, >> >> I understand that it does not make any sense to send the SACK, and > abort >> chunk should be the placed before the DATA chunk. But the question is > if >> the ABORT chunk is placed after the DATA chunk in the received packet >> then should be send the SACK for the DATA or not. >> >> Thanks, >> Salil >> >> >> -----Original Message----- >> From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] >> Sent: Thursday, October 15, 2009 12:58 PM >> To: Salil Agrawal >> Cc: sigtran@ietf.org >> Subject: Re: [Sigtran] Abort chunk bundled with data chunk >> >> Hi Salil, >> >> When you are bundling anything (control chunk) with DATA chunk it >> should be placed before DATA chunks in the SCTP packets. >> Now if you bundle the ABORT chunk with DATA chunk in a single SCTP >> packet the ABORT chunk will be processed before DATA chunk and >> association will be broken down. >> So, that DATA chunk will have no significance as it's association is >> now broken by the ABORT chunk placed before it. >> >> --Ashwani Kathuria >> >> On Thu, Oct 15, 2009 at 12:37 PM, Salil Agrawal > >> wrote: >>> Hi, >>> >>> We have a confusion while understanding the SCTP RFC4960 section 9.1 >> it >>> says "DATA chunks MUST NOT be bundled with ABORT" so sender must not >>> bundle the data with abort. >>> >>> But the second paragraph states that "An endpoint MUST NOT respond to >>> any received packet that contains an ABORT chunk". Which means if any >>> packet is received at the receiver end where ABORT is bundled with > the >>> DATA it should not send any response. Does it mean that for the DATA >>> chunk SACK should not be generated? Please clarify. >>> >>> Thanks, >>> Salil Agrawal >>> _______________________________________________ >>> Sigtran mailing list >>> Sigtran@ietf.org >>> https://www.ietf.org/mailman/listinfo/sigtran >>> >> > From Salil.Agrawal@ccpu.com Thu Oct 15 02:06:33 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6453A67D4 for ; Thu, 15 Oct 2009 02:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0fH0h3joEmA for ; Thu, 15 Oct 2009 02:06:32 -0700 (PDT) Received: from sd-smtp.ccpu.com (sd-smtp.ccpu.com [65.44.201.8]) by core3.amsl.com (Postfix) with ESMTP id 749E23A682A for ; Thu, 15 Oct 2009 02:06:32 -0700 (PDT) Received: from sd-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 679C4620A03; Thu, 15 Oct 2009 02:06:35 -0700 (PDT) Received: from alladin.ccpu.com (alladin.ccpu.com [172.16.0.216]) by sd-smtp.ccpu.com (Postfix) with ESMTP id 04ACD6209FA; Thu, 15 Oct 2009 02:06:34 -0700 (PDT) Received: from IN-EXCHANGE.ccpu.com ([172.25.0.16]) by alladin.ccpu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 02:06:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 14:36:31 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Abort chunk bundled with data chunk Thread-Index: AcpNderuWJMGm0yyTcmCZd6fmB+XUwAAFN/A References: <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> <341a09720910150200k26967f86y8dd16330261752f8@mail.gmail.com> From: "Salil Agrawal" To: "Ashwani Kathuria" X-OriginalArrivalTime: 15 Oct 2009 09:06:34.0664 (UTC) FILETIME=[CB5A1A80:01CA4D76] X-TM-AS-Product-Ver: IMSS-7.0.0.3216-5.6.0.1016-16948.003 X-TM-AS-Result: No--21.403-5.0-31-1 X-imss-scan-details: No--21.403-5.0-31-1 Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:06:33 -0000 Thanks Ashwani,=20 That means if we receive any DATA chunk in a packet then we first need to check if this packet contains the ABORT or not before sending the SACK. If packet is not containing the ABORT then only SACK will we sent otherwise not.=20 Also if this is going to be expected behavior then it would impact the protocol performance as we need to traverse the whole packet before sending any SACK.=20 Thanks, Salil -----Original Message----- From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com]=20 Sent: Thursday, October 15, 2009 2:30 PM To: Salil Agrawal Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk No, SACK should not be sent in such case. On Thu, Oct 15, 2009 at 2:28 PM, Salil Agrawal wrote: > Hi Ashwani, > > The question is not that whether DATA chunk should be bundled with the > ABORT or not. RFC is very clear about it that the sender should not do > in that way but here the question is if we at the receiver end receives > the same then what should be the action at the receiver end (should we > send the SACK for the DATA or not). > > Thanks, > Salil > > -----Original Message----- > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > Sent: Thursday, October 15, 2009 2:11 PM > To: Salil Agrawal > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Abort chunk bundled with data chunk > > Placing DATA chunk before control chunk (ABORT) makes it an Invalid SCTP > packet. > > --Ashwani Kathuria > > On Thu, Oct 15, 2009 at 1:46 PM, Salil Agrawal > wrote: >> Thanks Ashwani, >> >> I understand that it does not make any sense to send the SACK, and > abort >> chunk should be the placed before the DATA chunk. But the question is > if >> the ABORT chunk is placed after the DATA chunk in the received packet >> then should be send the SACK for the DATA or not. >> >> Thanks, >> Salil >> >> >> -----Original Message----- >> From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] >> Sent: Thursday, October 15, 2009 12:58 PM >> To: Salil Agrawal >> Cc: sigtran@ietf.org >> Subject: Re: [Sigtran] Abort chunk bundled with data chunk >> >> Hi Salil, >> >> When you are bundling anything (control chunk) with DATA chunk it >> should be placed before DATA chunks in the SCTP packets. >> Now if you bundle the ABORT chunk with DATA chunk in a single SCTP >> packet the ABORT chunk will be processed before DATA chunk and >> association will be broken down. >> So, that DATA chunk will have no significance as it's association is >> now broken by the ABORT chunk placed before it. >> >> --Ashwani Kathuria >> >> On Thu, Oct 15, 2009 at 12:37 PM, Salil Agrawal > >> wrote: >>> Hi, >>> >>> We have a confusion while understanding the SCTP RFC4960 section 9.1 >> it >>> says "DATA chunks MUST NOT be bundled with ABORT" so sender must not >>> bundle the data with abort. >>> >>> But the second paragraph states that "An endpoint MUST NOT respond to >>> any received packet that contains an ABORT chunk". Which means if any >>> packet is received at the receiver end where ABORT is bundled with > the >>> DATA it should not send any response. Does it mean that for the DATA >>> chunk SACK should not be generated? Please clarify. >>> >>> Thanks, >>> Salil Agrawal >>> _______________________________________________ >>> Sigtran mailing list >>> Sigtran@ietf.org >>> https://www.ietf.org/mailman/listinfo/sigtran >>> >> > From ankisharma@gmail.com Thu Oct 15 02:48:42 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7C83A68B0 for ; Thu, 15 Oct 2009 02:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUM5Kija3ECb for ; Thu, 15 Oct 2009 02:48:41 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id E461A3A68AD for ; Thu, 15 Oct 2009 02:48:40 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so187139eyd.51 for ; Thu, 15 Oct 2009 02:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=daWeJH/rIW3K6isy6uVC4iTTYJU6QSGYHurRSRR+Ifw=; b=uyHDW6gNLBKFzjEmFFe6YFG4m0NNua2mSZAvmHs6DMN1qu+Bj0nmQmBARgjgkiPOGK DUDi03jj4ejKeeA+vqxASGd2xq1jhszQKaTGKWy12Fs3okVmjq6Ppko4SSSWIFIjDUlM mLtyteqpMbK7wz3sM0zB6qbfNADATRPSrslt0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sBUD5Q+c2nh3Jrq+INjElZudRe2QqRq8BlW5uKYbhtoH1MWdd1fhvjDdquN//X3xc2 l5pJkIkn2ssd42XN6oEeOin3ZttdqX9VeUDMFb6pfnpvB+2556sIQThBS71xjRiY/xQH Ha+5F9N+8+vMCoKIvOfAfpBWVUe0wLd+k1ceI= MIME-Version: 1.0 Received: by 10.216.86.200 with SMTP id w50mr3254851wee.173.1255600120679; Thu, 15 Oct 2009 02:48:40 -0700 (PDT) In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com> References: <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> <341a09720910150200k26967f86y8dd16330261752f8@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com> Date: Thu, 15 Oct 2009 10:48:40 +0100 Message-ID: <6dbbbf160910150248r1b2fab54j4c7cc503d160a4ac@mail.gmail.com> From: Ankit Kumar Sharma To: Salil Agrawal Content-Type: multipart/alternative; boundary=0016e6dab11b2c4e0e0475f62f87 Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:48:42 -0000 --0016e6dab11b2c4e0e0475f62f87 Content-Type: text/plain; charset=ISO-8859-1 Just wandering whether traversing a whole list of chunks after receiving every correct packet, is too much of a penalty to handle just one invalid case. If we reply with a SACK for the DATA(received in a packet containing ABORT), and then ABORT the association then it should also be ok. If we have received a DATA chunk in a packet, and then ABORT in a next packet then also we perform the same action. Just to add to more confusion, section 6.1 says that "The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window". Specification is saying about "valid DATA chunk" so is it talking about only syntactically correct DATA chunk? Cheers On Thu, Oct 15, 2009 at 10:06 AM, Salil Agrawal wrote: > Thanks Ashwani, > > That means if we receive any DATA chunk in a packet then we first need > to check if this packet contains the ABORT or not before sending the > SACK. If packet is not containing the ABORT then only SACK will we sent > otherwise not. > Also if this is going to be expected behavior then it would impact the > protocol performance as we need to traverse the whole packet before > sending any SACK. > > Thanks, > Salil > > > > -----Original Message----- > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > Sent: Thursday, October 15, 2009 2:30 PM > To: Salil Agrawal > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Abort chunk bundled with data chunk > > No, SACK should not be sent in such case. > > On Thu, Oct 15, 2009 at 2:28 PM, Salil Agrawal > wrote: > > Hi Ashwani, > > > > The question is not that whether DATA chunk should be bundled with the > > ABORT or not. RFC is very clear about it that the sender should not do > > in that way but here the question is if we at the receiver end > receives > > the same then what should be the action at the receiver end (should we > > send the SACK for the DATA or not). > > > > Thanks, > > Salil > > > > -----Original Message----- > > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > > Sent: Thursday, October 15, 2009 2:11 PM > > To: Salil Agrawal > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] Abort chunk bundled with data chunk > > > > Placing DATA chunk before control chunk (ABORT) makes it an Invalid > SCTP > > packet. > > > > --Ashwani Kathuria > > > > On Thu, Oct 15, 2009 at 1:46 PM, Salil Agrawal > > > wrote: > >> Thanks Ashwani, > >> > >> I understand that it does not make any sense to send the SACK, and > > abort > >> chunk should be the placed before the DATA chunk. But the question is > > if > >> the ABORT chunk is placed after the DATA chunk in the received packet > >> then should be send the SACK for the DATA or not. > >> > >> Thanks, > >> Salil > >> > >> > >> -----Original Message----- > >> From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > >> Sent: Thursday, October 15, 2009 12:58 PM > >> To: Salil Agrawal > >> Cc: sigtran@ietf.org > >> Subject: Re: [Sigtran] Abort chunk bundled with data chunk > >> > >> Hi Salil, > >> > >> When you are bundling anything (control chunk) with DATA chunk it > >> should be placed before DATA chunks in the SCTP packets. > >> Now if you bundle the ABORT chunk with DATA chunk in a single SCTP > >> packet the ABORT chunk will be processed before DATA chunk and > >> association will be broken down. > >> So, that DATA chunk will have no significance as it's association is > >> now broken by the ABORT chunk placed before it. > >> > >> --Ashwani Kathuria > >> > >> On Thu, Oct 15, 2009 at 12:37 PM, Salil Agrawal > > > >> wrote: > >>> Hi, > >>> > >>> We have a confusion while understanding the SCTP RFC4960 section 9.1 > >> it > >>> says "DATA chunks MUST NOT be bundled with ABORT" so sender must not > >>> bundle the data with abort. > >>> > >>> But the second paragraph states that "An endpoint MUST NOT respond > to > >>> any received packet that contains an ABORT chunk". Which means if > any > >>> packet is received at the receiver end where ABORT is bundled with > > the > >>> DATA it should not send any response. Does it mean that for the DATA > >>> chunk SACK should not be generated? Please clarify. > >>> > >>> Thanks, > >>> Salil Agrawal > >>> _______________________________________________ > >>> Sigtran mailing list > >>> Sigtran@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sigtran > >>> > >> > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > --0016e6dab11b2c4e0e0475f62f87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Just wandering whether traversing=A0a whole list of chunks after recei= ving every correct packet,=A0is too much of a penalty to handle just one=A0= invalid case.
=A0
If we reply with a SACK for the DATA(received in a packet containing A= BORT), and then ABORT the association then it should also be ok. If we have= received a DATA chunk in a packet, and then ABORT in a next packet then al= so we perform the same action.
=A0
Just to add to more confusion, section 6.1 says that "The SCTP en= dpoint MUST always acknowledge the reception of each valid DATA chunk when = the DATA chunk received is inside its receive window".=A0Specification= is saying about "valid DATA chunk" so is it=A0talking about only= syntactically correct DATA chunk?=A0
=A0
Cheers

On Thu, Oct 15, 2009 at 10:06 AM, Salil Agrawal = <Salil.Agraw= al@ccpu.com> wrote:
Thanks Ashwani,

That mean= s if we receive any DATA chunk in a packet then we first need
to check i= f this packet contains the ABORT or not before sending the
SACK. If packet is not containing the ABORT then only SACK will we sent
= otherwise not.
Also if this is going to be expected behavior then it wou= ld impact the
protocol performance as we need to traverse the whole pack= et before
sending any SACK.

Thanks,
Salil



-----Original Message= -----
From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com]
Sent: Thursday, October 15, 2009 2:30 PM
To: Salil Agr= awal
Cc: sigtran@ietf.org
Sub= ject: Re: [Sigtran] Abort chunk bundled with data chunk

No, SACK sho= uld not be sent in such case.

On Thu, Oct 15, 2009 at 2:28 PM, Salil Agrawal <Salil.Agrawal@ccpu.com>
wrote:
> Hi A= shwani,
>
> The question is not that whether DATA chunk should = be bundled with the
> ABORT or not. RFC is very clear about it that the sender should not do=
> in that way but here the question is if we at the receiver end
= receives
> the same then what should be the action at the receiver en= d (should we
> send the SACK for the DATA or not).
>
> Thanks,
> Sa= lil
>
> -----Original Message-----
> From: Ashwani Kathur= ia [mailto:ashwani.grps@gmail.com= ]
> Sent: Thursday, October 15, 2009 2:11 PM
> To: Salil Agrawal
= > Cc: sigtran@ietf.org
> S= ubject: Re: [Sigtran] Abort chunk bundled with data chunk
>
> P= lacing DATA chunk before control chunk (ABORT) makes it an Invalid
SCTP
> packet.
>
> --Ashwani Kathuria
>
> On = Thu, Oct 15, 2009 at 1:46 PM, Salil Agrawal
<Salil.Agrawal@ccpu.com>
> wrote:
>>= Thanks Ashwani,
>>
>> I understand that it does not make any sense to send t= he SACK, and
> abort
>> chunk should be the placed before th= e DATA chunk. But the question is
> if
>> the ABORT chunk is= placed after the DATA chunk in the received packet
>> then should be send the SACK for the DATA or not.
>>
&= gt;> Thanks,
>> Salil
>>
>>
>> -----= Original Message-----
>> From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com]
>> Sent: Thursday, October 15, 2009 12:58 PM
>> To: Salil Ag= rawal
>> Cc: sigtran@ietf.org<= /a>
>> Subject: Re: [Sigtran] Abort chunk bundled with data chunk<= br> >>
>> Hi Salil,
>>
>> When you are bundlin= g anything (control chunk) with DATA chunk it
>> should be placed = before DATA chunks in the SCTP packets.
>> Now if you bundle the A= BORT chunk with DATA chunk in a single SCTP
>> packet the ABORT chunk will be processed before DATA chunk and
= >> association will be broken down.
>> So, that DATA chunk w= ill have no significance as it's association is
>> now broken = by the ABORT chunk placed before it.
>>
>> --Ashwani Kathuria
>>
>> On Thu, Oct= 15, 2009 at 12:37 PM, Salil Agrawal
> <
Salil.Agrawal@ccpu.com>
>> wrote:
>&g= t;> Hi,
>>>
>>> We have a confusion while understanding the SC= TP RFC4960 section 9.1
>> it
>>> says "DATA chunk= s MUST NOT be bundled with ABORT" so sender must not
>>> b= undle the data with abort.
>>>
>>> But the second paragraph states that "An = endpoint MUST NOT respond
to
>>> any received packet that co= ntains an ABORT chunk". Which means if
any
>>> packet i= s received at the receiver end where ABORT is bundled with
> the
>>> DATA it should not send any response. Does it mean= that for the DATA
>>> chunk SACK should not be generated? Plea= se clarify.
>>>
>>> Thanks,
>>> Salil A= grawal
>>> _______________________________________________
>>>= ; Sigtran mailing list
>>> = Sigtran@ietf.org
>>> https://www.ietf.org/mailman/listinfo= /sigtran
>>>
>>
>
_______________________________________= ________
Sigtran mailing list
Sig= tran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran

--0016e6dab11b2c4e0e0475f62f87-- From deepak.gunjal@aricent.com Thu Oct 15 02:48:59 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F1F3A6A31 for ; Thu, 15 Oct 2009 02:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7bk+6MKz8ZO for ; Thu, 15 Oct 2009 02:48:54 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [125.21.164.247]) by core3.amsl.com (Postfix) with ESMTP id 6DD6D3A68DB for ; Thu, 15 Oct 2009 02:48:52 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id B4D9136BF5; Thu, 15 Oct 2009 15:17:04 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 9E98836BF2; Thu, 15 Oct 2009 15:17:04 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Thu, 15 Oct 2009 15:18:54 +0530 From: Deepak Gunjal To: Ashwani Kathuria Date: Thu, 15 Oct 2009 15:18:52 +0530 Thread-Topic: [Sigtran] In IPSP-IPSP mode what should be the behavior on receving Notify(AS-PENDING) when AS is already AS-ACTIVE Thread-Index: AcpI4MlmJSWwlMRkQT+RrJ+Jc7KeNAEm1XgA Message-ID: References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> In-Reply-To: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BDF44534797E3E46B55F3D12DE0C4BC4032210073AGUREXMB01ASIA_" MIME-Version: 1.0 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on receving Notify(AS-PENDING) when AS is already AS-ACTIVE X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:48:59 -0000 --_000_BDF44534797E3E46B55F3D12DE0C4BC4032210073AGUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems that both the end points keeps the connection alive as I can see a= fter network restart Spectra2 sends Notify(AS-PENDING) on the previously es= tablished connection and my M3UA stack responds with ERROR(Unexpected-Msg) = as the AS state at my stack is ACTIVE. So the ERROR message does reaches to= spectra2 and the sequence continues. I am still not able to figure out how to come out of this loop? As per RFC = there is no case where I can receive AS-PENDING for AS-ACTIVE. Any suggestions? Regards Deepak -----Original Message----- From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] Sent: Friday, October 09, 2009 6:33 PM To: Deepak Gunjal Cc: sigtran@ietf.org Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on rec= eving Notify(AS-PENDING) when AS is already AS-ACTIVE Hi Deepak, I think your M3UA stack is correct in sending the Error message but your underlying SCTP should send some restart or down indication to your M3UA stack. 5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override ... Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., SGP to ASP1) would not occur. So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but in section 4.3.3 If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or SCTP-RESTART indication primitive from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP_STATUS indication primitive. The state of the ASP will be moved to ASP- DOWN. and in section 4.3.4.5 A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. The question is: As per section 4.3.3 M3UA should change the ASP to DOWN upon detecting SCTP failure and as per section 4.3.4.5 NOTIFY messages are not sent to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to DOWN marked ASPs? -- Ashwani On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal w= rote: > > Hi, > > > > Here is the brief description: > > > > I am running my application emulating the role of a AS having 2 ASP in ov= erride mode. Out of 2 ASP one ASP is ACTIVE and other is down. > > > > My application has sent the ASP-ACTIVE to peer IPSP node and received the= Notify(AS-ACTIVE). Now I restarted the IP network services and as a result= remote IPSP node marks the state of my AS as down and sends an Notify(AS-P= ENDING) which my M3UA stack treats as "UNEXPECTED" message and does nothing= as it has not received any notification from SCTP that connection was down= so it keeps the local AS ACTIVE and responds with ERROR message with erro= r code "UNEXPECTED message". > > > > My question is what should be my behavior when AS-PENDING is received? > > > > Regards > > Deepak > > ________________________________ > "DISCLAIMER: This message is proprietary to Aricent and is intended solel= y for the use of the individual to whom it is addressed. It may contain pri= vileged or confidential information and should not be circulated or used fo= r any purpose other than for what it is intended. If you have received this= message in error,please notify the originator immediately. If you are not = the intended recipient, you are notified that you are strictly prohibited f= rom using, copying, altering, or disclosing the contents of this message. A= ricent accepts no responsibility for loss or damage arising from the use of= the information transmitted by this email including damage from virus." > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." --_000_BDF44534797E3E46B55F3D12DE0C4BC4032210073AGUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems that both the end points keeps the connection alive as I c= an see after network restart Spectra2 sends Notify(AS-PENDING) on the previ= ously established connection and my M3UA stack responds with ERROR(Unexpected-Msg) as the AS state at m= y stack is ACTIVE. So the ERROR message does reaches to spectra2 and the se= quence continues.

 

I am still not able to figure out how to come out of this loop? As = per RFC there is no case where I can receive AS-PENDING for AS-ACTIVE.=

 

Any suggestions?

 

Regards

Deepak

 

-----Original Message-----
From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com]
Sent: Friday, October 09, 2009 6:33 PM
To: Deepak Gunjal
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on rec= eving Notify(AS-PENDING) when AS is already AS-ACTIVE

 

Hi Deepak,

 

I think your M3UA stack is correct in sending the Error message but=

your underlying SCTP should send some restart or down indicati= on to

your M3UA stack.

 

5.2.1.  1+1 Sparing, Withdrawal of ASP, Backup Override

...

   Note: If the SGP M3UA layer detects the loss of the M3= UA peer (e.g.,

   M3UA heartbeat loss or detection of SCTP failure), the= initial ASP

   Inactive message exchange (i.e., SGP to ASP1) would no= t occur.

 

So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but=

 

in section 4.3.3

   If the M3UA layer subsequently receives an SCTP-COMMUN= ICATION_DOWN or

   SCTP-RESTART indication primitive from the underlying = SCTP layer, it

   will inform the Layer Management by invoking the M-SCT= P_STATUS

   indication primitive.  The state of the ASP will = be moved to ASP-

   DOWN.

and in section 4.3.4.5

   A Notify message reflecting a change in the AS state M= UST be sent to

   all ASPs in the AS, except those in the ASP-DOWN state= , with

   appropriate Status Information and any ASP Identifier = of the failed

   ASP.

 

The question is:

As per section 4.3.3 M3UA should change the ASP to DOWN upon detect= ing

SCTP failure and as per section 4.3.4.5 NOTIFY messages are not sen= t

to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to D= OWN

marked ASPs?

 

-- Ashwani

 

 

On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal <deepak.gunjal@ari= cent.com> wrote:

> 

> Hi,

> 

> 

> 

> Here is the brief description:

> 

> 

> 

> I am running my application emulating the role of a AS having = 2 ASP in override mode. Out of 2 ASP one ASP is ACTIVE and other is down.

> 

> 

> 

> My application has sent the ASP-ACTIVE to peer IPSP node and r= eceived the Notify(AS-ACTIVE). Now I restarted the IP network services and = as a result remote IPSP node marks the state of my AS as down and sends an Notify(AS-PENDING) which my = M3UA stack treats as “UNEXPECTED” message and does nothing as i= t has not received any notification from SCTP that connection was down so i= t keeps the local AS ACTIVE and responds with ERROR  message with error code “UNEXPECTED message”.=

> 

> 

> 

> My question is what should be my behavior when AS-PENDING is r= eceived?

> 

> 

> 

> Regards

> 

> Deepak

> 

> ________________________________

> "DISCLAIMER: This message is proprietary to Aricent and i= s intended solely for the use of the individual to whom it is addressed. It= may contain privileged or confidential information and should not be circulated or used for any purpose other tha= n for what it is intended. If you have received this message in error,pleas= e notify the originator immediately. If you are not the intended recipient,= you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of th= is message. Aricent accepts no responsibility for loss or damage arising fr= om the use of the information transmitted by this email including damage fr= om virus."

> 

> _______________________________________________

> Sigtran mailing list

> Sigtran@ietf.org

> https://www.ietf.org/mailman/listinfo/sigtran

> 



"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error,please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly proh= ibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
--_000_BDF44534797E3E46B55F3D12DE0C4BC4032210073AGUREXMB01ASIA_-- From Michael.Tuexen@lurchi.franken.de Thu Oct 15 03:03:04 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC213A6896 for ; Thu, 15 Oct 2009 03:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a82zW7Z6pDIR for ; Thu, 15 Oct 2009 03:03:03 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 1795F3A6860 for ; Thu, 15 Oct 2009 03:03:02 -0700 (PDT) Received: from [10.0.1.107] (unknown [194.95.73.153]) by mail-n.franken.de (Postfix) with ESMTP id 7122E1C0B4612; Thu, 15 Oct 2009 12:03:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com> Date: Thu, 15 Oct 2009 12:03:03 +0200 Content-Transfer-Encoding: 7bit Message-Id: <76AD3443-4DFE-421F-B1F2-874C28D20F37@lurchi.franken.de> References: <20091009193525.GA375@openss7.org> <341a09720910112311s2ecb8da4qd93841cf201f20ae@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> <341a09720910150200k26967f86y8dd16330261752f8@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com> To: Salil Agrawal X-Mailer: Apple Mail (2.1076) Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 10:03:04 -0000 On Oct 15, 2009, at 11:06 AM, Salil Agrawal wrote: > Thanks Ashwani, > > That means if we receive any DATA chunk in a packet then we first need > to check if this packet contains the ABORT or not before sending the > SACK. If packet is not containing the ABORT then only SACK will we > sent > otherwise not. I would just start processing the packet, process the DATA chunk, find the ABORT, decide the packet is illegal, discard the association, and do not send an ABORT since I received one. Best regards Michael > Also if this is going to be expected behavior then it would impact the > protocol performance as we need to traverse the whole packet before > sending any SACK. > > Thanks, > Salil > > > > -----Original Message----- > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > Sent: Thursday, October 15, 2009 2:30 PM > To: Salil Agrawal > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] Abort chunk bundled with data chunk > > No, SACK should not be sent in such case. > > On Thu, Oct 15, 2009 at 2:28 PM, Salil Agrawal > > wrote: >> Hi Ashwani, >> >> The question is not that whether DATA chunk should be bundled with >> the >> ABORT or not. RFC is very clear about it that the sender should not >> do >> in that way but here the question is if we at the receiver end > receives >> the same then what should be the action at the receiver end (should >> we >> send the SACK for the DATA or not). >> >> Thanks, >> Salil >> >> -----Original Message----- >> From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] >> Sent: Thursday, October 15, 2009 2:11 PM >> To: Salil Agrawal >> Cc: sigtran@ietf.org >> Subject: Re: [Sigtran] Abort chunk bundled with data chunk >> >> Placing DATA chunk before control chunk (ABORT) makes it an Invalid > SCTP >> packet. >> >> --Ashwani Kathuria >> >> On Thu, Oct 15, 2009 at 1:46 PM, Salil Agrawal > >> wrote: >>> Thanks Ashwani, >>> >>> I understand that it does not make any sense to send the SACK, and >> abort >>> chunk should be the placed before the DATA chunk. But the question >>> is >> if >>> the ABORT chunk is placed after the DATA chunk in the received >>> packet >>> then should be send the SACK for the DATA or not. >>> >>> Thanks, >>> Salil >>> >>> >>> -----Original Message----- >>> From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] >>> Sent: Thursday, October 15, 2009 12:58 PM >>> To: Salil Agrawal >>> Cc: sigtran@ietf.org >>> Subject: Re: [Sigtran] Abort chunk bundled with data chunk >>> >>> Hi Salil, >>> >>> When you are bundling anything (control chunk) with DATA chunk it >>> should be placed before DATA chunks in the SCTP packets. >>> Now if you bundle the ABORT chunk with DATA chunk in a single SCTP >>> packet the ABORT chunk will be processed before DATA chunk and >>> association will be broken down. >>> So, that DATA chunk will have no significance as it's association is >>> now broken by the ABORT chunk placed before it. >>> >>> --Ashwani Kathuria >>> >>> On Thu, Oct 15, 2009 at 12:37 PM, Salil Agrawal >> >>> wrote: >>>> Hi, >>>> >>>> We have a confusion while understanding the SCTP RFC4960 section >>>> 9.1 >>> it >>>> says "DATA chunks MUST NOT be bundled with ABORT" so sender must >>>> not >>>> bundle the data with abort. >>>> >>>> But the second paragraph states that "An endpoint MUST NOT respond > to >>>> any received packet that contains an ABORT chunk". Which means if > any >>>> packet is received at the receiver end where ABORT is bundled with >> the >>>> DATA it should not send any response. Does it mean that for the >>>> DATA >>>> chunk SACK should not be generated? Please clarify. >>>> >>>> Thanks, >>>> Salil Agrawal >>>> _______________________________________________ >>>> Sigtran mailing list >>>> Sigtran@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sigtran >>>> >>> >> > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > From David.Laight@ACULAB.COM Thu Oct 15 03:04:48 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594F13A68BA for ; Thu, 15 Oct 2009 03:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yM0-D5jM3c1 for ; Thu, 15 Oct 2009 03:04:47 -0700 (PDT) Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by core3.amsl.com (Postfix) with SMTP id 475C53A68B0 for ; Thu, 15 Oct 2009 03:04:47 -0700 (PDT) Received: (qmail 11863 invoked from network); 15 Oct 2009 10:04:48 -0000 Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 15 Oct 2009 10:04:48 -0000 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 07910-07 for ; Thu, 15 Oct 2009 11:04:47 +0100 (BST) Received: (qmail 11845 invoked by uid 599); 15 Oct 2009 10:04:47 -0000 Received: from unknown (HELO saturn2.Aculab.com) (10.202.163.6) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Thu, 15 Oct 2009 11:04:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 11:04:46 +0100 Message-ID: <00D42150952F70458C66072322F7FE25026E800E@saturn2.aculab.com> In-Reply-To: <76AD3443-4DFE-421F-B1F2-874C28D20F37@lurchi.franken.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] Abort chunk bundled with data chunk Thread-Index: AcpNfrbErB3rxFAGSO6r31TKhrQ/NgAABpGw From: "David Laight" To: =?iso-8859-1?Q?Michael_T=FCxen?= , "Salil Agrawal" X-ST-MF-Message-Resent: 10/15/2009 11:04 X-Virus-Scanned: by iCritical at mx0.aculab.com Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 10:04:48 -0000 > I would just start processing the packet, process the DATA chunk, > find the ABORT, decide the packet is illegal, discard the association, > and do not send an ABORT since I received one. That might lead to the application processing the data from the DATA chunk .... David Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1= 1PT, UK Registration No: 1397386 (Wales) P Please consider the environment and don't print this e-mail unless you = really need to From ashwani.grps@gmail.com Thu Oct 15 03:10:26 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3EF83A67E4 for ; Thu, 15 Oct 2009 03:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy743SSsv7i8 for ; Thu, 15 Oct 2009 03:10:25 -0700 (PDT) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id A64993A679C for ; Thu, 15 Oct 2009 03:10:25 -0700 (PDT) Received: by gxk28 with SMTP id 28so665994gxk.9 for ; Thu, 15 Oct 2009 03:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lxgRV2xoLWcpPAxwVQE0SjZ2Vvo91BB1NiHFm5hNtiY=; b=LAM5VIWqtc/QBdmBO7UBM4UGIHfP/LVcznlYKnbFsmiNHRYnfHYEC1lp99Av9inTIc THtIuK0cTss63uFDXftM6n6ACndQl7slA6JyjNm8KlbqtueTDwbTtIbjkNz1RQ5dFklG gLHjAKHo3wggBZzG0irM8NdDsilLiyvlRb5gY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XleeUdpaYEStX3W9qgDyFeQa8wPfJ1ET+dSjzxkHSflEKuYX9JFCtO2VuBhz1sTTW4 ziJ3fN40ZkfO0JAMQcRSdNtMem6EXx21pnZA4g7x7Ud1YVrQhCUVwd9sAtoItiUt4RYt BzBGT91CJQjDmwHmuLchfuBn+P5emSBJN6Tmc= MIME-Version: 1.0 Received: by 10.150.108.23 with SMTP id g23mr16882136ybc.207.1255601425238; Thu, 15 Oct 2009 03:10:25 -0700 (PDT) In-Reply-To: <6dbbbf160910150248r1b2fab54j4c7cc503d160a4ac@mail.gmail.com> References: <22F058C3ED9D784E90CE473F2A9847F003CEC739@in-exchange.ccpu.com> <341a09720910150027i3609b393qcdec16d23044c999@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC752@in-exchange.ccpu.com> <341a09720910150141n38cf727br1ef074aa2beab34a@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC773@in-exchange.ccpu.com> <341a09720910150200k26967f86y8dd16330261752f8@mail.gmail.com> <22F058C3ED9D784E90CE473F2A9847F003CEC779@in-exchange.ccpu.com> <6dbbbf160910150248r1b2fab54j4c7cc503d160a4ac@mail.gmail.com> Date: Thu, 15 Oct 2009 15:40:25 +0530 Message-ID: <341a09720910150310k65038ed9m4ca16b2444475b7b@mail.gmail.com> From: Ashwani Kathuria To: Ankit Kumar Sharma Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Salil Agrawal , sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 10:10:27 -0000 Hi Ankit/Salil As per protocol there should always be a check to validate the SCTP packet and the validation should be - to check that DATA chunks if bundled with conntrol chunks are not at the start of the packet and also - that DATA chunks should not be bundled with some specific control chunks like ABORT, SHUTDOWN or SHUTDOWN ACK etc. This is what protocol behavior should be. Now it's all on implementation how they take care of performance. --Ashwani Kathuria On Thu, Oct 15, 2009 at 3:18 PM, Ankit Kumar Sharma wrote: > Just wandering whether traversing=A0a whole list of chunks after receivin= g > every correct packet,=A0is too much of a penalty to handle just one=A0inv= alid > case. > > If we reply with a SACK for the DATA(received in a packet containing ABOR= T), > and then ABORT the association then it should also be ok. If we have > received a DATA chunk in a packet, and then ABORT in a next packet then a= lso > we perform the same action. > > Just to add to more confusion, section 6.1 says that "The SCTP endpoint M= UST > always acknowledge the reception of each valid DATA chunk when the DATA > chunk received is inside its receive window".=A0Specification is saying a= bout > "valid DATA chunk" so is it=A0talking about only syntactically correct DA= TA > chunk? > > Cheers > > On Thu, Oct 15, 2009 at 10:06 AM, Salil Agrawal > wrote: >> >> Thanks Ashwani, >> >> That means if we receive any DATA chunk in a packet then we first need >> to check if this packet contains the ABORT or not before sending the >> SACK. If packet is not containing the ABORT then only SACK will we sent >> otherwise not. >> Also if this is going to be expected behavior then it would impact the >> protocol performance as we need to traverse the whole packet before >> sending any SACK. >> >> Thanks, >> Salil >> >> >> >> -----Original Message----- >> From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] >> Sent: Thursday, October 15, 2009 2:30 PM >> To: Salil Agrawal >> Cc: sigtran@ietf.org >> Subject: Re: [Sigtran] Abort chunk bundled with data chunk >> >> No, SACK should not be sent in such case. >> >> On Thu, Oct 15, 2009 at 2:28 PM, Salil Agrawal >> wrote: >> > Hi Ashwani, >> > >> > The question is not that whether DATA chunk should be bundled with the >> > ABORT or not. RFC is very clear about it that the sender should not do >> > in that way but here the question is if we at the receiver end >> receives >> > the same then what should be the action at the receiver end (should we >> > send the SACK for the DATA or not). >> > >> > Thanks, >> > Salil >> > >> > -----Original Message----- >> > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] >> > Sent: Thursday, October 15, 2009 2:11 PM >> > To: Salil Agrawal >> > Cc: sigtran@ietf.org >> > Subject: Re: [Sigtran] Abort chunk bundled with data chunk >> > >> > Placing DATA chunk before control chunk (ABORT) makes it an Invalid >> SCTP >> > packet. >> > >> > --Ashwani Kathuria >> > >> > On Thu, Oct 15, 2009 at 1:46 PM, Salil Agrawal >> >> > wrote: >> >> Thanks Ashwani, >> >> >> >> I understand that it does not make any sense to send the SACK, and >> > abort >> >> chunk should be the placed before the DATA chunk. But the question is >> > if >> >> the ABORT chunk is placed after the DATA chunk in the received packet >> >> then should be send the SACK for the DATA or not. >> >> >> >> Thanks, >> >> Salil >> >> >> >> >> >> -----Original Message----- >> >> From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] >> >> Sent: Thursday, October 15, 2009 12:58 PM >> >> To: Salil Agrawal >> >> Cc: sigtran@ietf.org >> >> Subject: Re: [Sigtran] Abort chunk bundled with data chunk >> >> >> >> Hi Salil, >> >> >> >> When you are bundling anything (control chunk) with DATA chunk it >> >> should be placed before DATA chunks in the SCTP packets. >> >> Now if you bundle the ABORT chunk with DATA chunk in a single SCTP >> >> packet the ABORT chunk will be processed before DATA chunk and >> >> association will be broken down. >> >> So, that DATA chunk will have no significance as it's association is >> >> now broken by the ABORT chunk placed before it. >> >> >> >> --Ashwani Kathuria >> >> >> >> On Thu, Oct 15, 2009 at 12:37 PM, Salil Agrawal >> > >> >> wrote: >> >>> Hi, >> >>> >> >>> We have a confusion while understanding the SCTP RFC4960 section 9.1 >> >> it >> >>> says "DATA chunks MUST NOT be bundled with ABORT" so sender must not >> >>> bundle the data with abort. >> >>> >> >>> But the second paragraph states that "An endpoint MUST NOT respond >> to >> >>> any received packet that contains an ABORT chunk". Which means if >> any >> >>> packet is received at the receiver end where ABORT is bundled with >> > the >> >>> DATA it should not send any response. Does it mean that for the DATA >> >>> chunk SACK should not be generated? Please clarify. >> >>> >> >>> Thanks, >> >>> Salil Agrawal >> >>> _______________________________________________ >> >>> Sigtran mailing list >> >>> Sigtran@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/sigtran >> >>> >> >> >> > >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www.ietf.org/mailman/listinfo/sigtran > > From ankisharma@gmail.com Thu Oct 15 03:55:09 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909AC3A682A for ; Thu, 15 Oct 2009 03:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FciThVFwRRl4 for ; Thu, 15 Oct 2009 03:55:08 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 7AF1A3A6876 for ; Thu, 15 Oct 2009 03:55:07 -0700 (PDT) Received: by ewy4 with SMTP id 4so384099ewy.37 for ; Thu, 15 Oct 2009 03:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vcViKOaWwAY3ZWML4j76hef1oKN5AIc3IdeYYWq640I=; b=F8HyKppfUT9ROkB52U0zT2A65EcYC96jWRGjFW+Svtx0ub/a4GNUNZoAf3MxKdlUKI B9T6sX/kAnlNYMsQUcCGBtZXjimt56hP1miMaV72EIyjSVJYAJRjmLq6oMtG2FZbGX+p yohdBocSh7zO9bDBZ8tE01TnXrbeTR0lXttjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K+FQDIBvZqhIUdknxh5mr9jxr7LKmWqsLSXIByTYYYS2QjbAk/nw1ejXPWDRgTi1Cg v7IaoAAzn4AgvN+Yw+2kWMa/5c+mIm4UAuxI/ap7RKcfiwQS2F+hGStXQrgSUILcn2LD nvkonqfwMjkVlBiVam6JDx3QiUozKQ59rPxs8= MIME-Version: 1.0 Received: by 10.216.87.7 with SMTP id x7mr3132929wee.53.1255604107919; Thu, 15 Oct 2009 03:55:07 -0700 (PDT) In-Reply-To: References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> Date: Thu, 15 Oct 2009 11:55:07 +0100 Message-ID: <6dbbbf160910150355m442ecf62lb554656271bcace2@mail.gmail.com> From: Ankit Kumar Sharma To: Deepak Gunjal Content-Type: multipart/alternative; boundary=001636c5b1e2d4c0aa0475f71c52 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on receving Notify(AS-PENDING) when AS is already AS-ACTIVE X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 10:55:09 -0000 --001636c5b1e2d4c0aa0475f71c52 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Could you please check why your SCTP layer is not sending connection restar= t indication to M3UA? On Thu, Oct 15, 2009 at 10:48 AM, Deepak Gunjal wrote: > It seems that both the end points keeps the connection alive as I can se= e > after network restart Spectra2 sends Notify(AS-PENDING) on the previously > established connection and my M3UA stack responds with ERROR(Unexpected-M= sg) > as the AS state at my stack is ACTIVE. So the ERROR message does reaches = to > spectra2 and the sequence continues. > > > > I am still not able to figure out how to come out of this loop? As per RF= C > there is no case where I can receive AS-PENDING for AS-ACTIVE. > > > > Any suggestions? > > > > Regards > > Deepak > > > > -----Original Message----- > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > Sent: Friday, October 09, 2009 6:33 PM > To: Deepak Gunjal > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on > receving Notify(AS-PENDING) when AS is already AS-ACTIVE > > > > Hi Deepak, > > > > I think your M3UA stack is correct in sending the Error message but > > your underlying SCTP should send some restart or down indication to > > your M3UA stack. > > > > 5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override > > ... > > Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., > > M3UA heartbeat loss or detection of SCTP failure), the initial ASP > > Inactive message exchange (i.e., SGP to ASP1) would not occur. > > > > So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but > > > > in section 4.3.3 > > If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or > > SCTP-RESTART indication primitive from the underlying SCTP layer, it > > will inform the Layer Management by invoking the M-SCTP_STATUS > > indication primitive. The state of the ASP will be moved to ASP- > > DOWN. > > and in section 4.3.4.5 > > A Notify message reflecting a change in the AS state MUST be sent to > > all ASPs in the AS, except those in the ASP-DOWN state, with > > appropriate Status Information and any ASP Identifier of the failed > > ASP. > > > > The question is: > > As per section 4.3.3 M3UA should change the ASP to DOWN upon detecting > > SCTP failure and as per section 4.3.4.5 NOTIFY messages are not sent > > to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to DOWN > > marked ASPs? > > > > -- Ashwani > > > > > > On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal > wrote: > > > > > > Hi, > > > > > > > > > > > > Here is the brief description: > > > > > > > > > > > > I am running my application emulating the role of a AS having 2 ASP in > override mode. Out of 2 ASP one ASP is ACTIVE and other is down. > > > > > > > > > > > > My application has sent the ASP-ACTIVE to peer IPSP node and received t= he > Notify(AS-ACTIVE). Now I restarted the IP network services and as a resul= t > remote IPSP node marks the state of my AS as down and sends an > Notify(AS-PENDING) which my M3UA stack treats as =93UNEXPECTED=94 message= and > does nothing as it has not received any notification from SCTP that > connection was down so it keeps the local AS ACTIVE and responds with ERR= OR > message with error code =93UNEXPECTED message=94. > > > > > > > > > > > > My question is what should be my behavior when AS-PENDING is received? > > > > > > > > > > > > Regards > > > > > > Deepak > > > > > > ________________________________ > > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may cont= ain > privileged or confidential information and should not be circulated or us= ed > for any purpose other than for what it is intended. If you have received > this message in error,please notify the originator immediately. If you ar= e > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of t= his > message. Aricent accepts no responsibility for loss or damage arising fro= m > the use of the information transmitted by this email including damage fro= m > virus." > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www.ietf.org/mailman/listinfo/sigtran > > > > > ------------------------------ > "DISCLAIMER: This message is proprietary to Aricent and is intended solel= y > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or us= ed > for any purpose other than for what it is intended. If you have received > this message in error,please notify the originator immediately. If you ar= e > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of t= his > message. Aricent accepts no responsibility for loss or damage arising fro= m > the use of the information transmitted by this email including damage fro= m > virus." > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > > --001636c5b1e2d4c0aa0475f71c52 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Could you please check why your SCTP=A0layer is not sending=A0connecti= on restart indication to M3UA?

On Thu, Oct 15, 2009 at 10:48 AM, Deepak Gunjal = <deepak.g= unjal@aricent.com> wrote:

It= seems that both the end points keeps the connection alive as I can see aft= er network restart Spectra2 sends Notify(AS-PENDING) on the previously esta= blished connection and my M3UA stack responds with ERROR(Unexpected-Msg) as= the AS state at my stack is ACTIVE. So the ERROR message does reaches to s= pectra2 and the sequence continues.

= =A0

I = am still not able to figure out how to come out of this loop? As per RFC th= ere is no case where I can receive AS-PENDING for AS-ACTIVE.<= /p>

= =A0

An= y suggestions?

= =A0

Re= gards

De= epak

= =A0

--= ---Original Message-----
From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] Sent: Friday, October 09, 2009 6:33 PM
To: Deepak Gunjal
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] In IPSP-IPSP mode what s= hould be the behavior on receving Notify(AS-PENDING) when AS is already AS-= ACTIVE

= =A0

Hi= Deepak,

= =A0

I = think your M3UA stack is correct in sending the Error message but

yo= ur underlying SCTP should send=A0some restart or down indication to<= /font>

yo= ur M3UA stack.

= =A0

5.= 2.1.=A0 1+1 Sparing, Withdrawal of ASP, Backup Override

..= .

= =A0=A0 Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g.,=

= =A0=A0 M3UA heartbeat loss or detection of SCTP failure), the initial ASP

= =A0=A0 Inactive message exchange (i.e., SGP to ASP1) would not occur.

= =A0

So= peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but

= =A0

in= section 4.3.3

= =A0=A0 If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN o= r

= =A0=A0 SCTP-RESTART indication primitive from the underlying SCTP layer, it=

= =A0=A0 will inform the Layer Management by invoking the M-SCTP_STATUS

= =A0=A0 indication primitive.=A0 The state of the ASP will be moved to ASP-<= /span>

= =A0=A0 DOWN.

an= d in section 4.3.4.5

= =A0=A0 A Notify message reflecting a change in the AS state MUST be sent to=

= =A0=A0 all ASPs in the AS, except those in the ASP-DOWN state, with<= /font>

= =A0=A0 appropriate Status Information and any ASP Identifier of the failed<= /span>

= =A0=A0 ASP.

= =A0

Th= e question is:

As= per section 4.3.3 M3UA should change the ASP to DOWN upon detecting=

SC= TP failure and as per section 4.3.4.5 NOTIFY messages are not sent

to= DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to DOWN=

ma= rked ASPs?

= =A0

--= Ashwani

= =A0

= =A0

On= Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal <deepak.gunjal@aricent.com> wrote= :

&g= t;=A0

&g= t; Hi,

&g= t;=A0

&g= t;=A0

&g= t;=A0

&g= t; Here is the brief description:

&g= t;=A0

&g= t;=A0

&g= t;=A0

&g= t; I am running my application emulating the role of a AS having 2 ASP in o= verride mode. Out of 2 ASP one ASP is ACTIVE and other is down.

&g= t;=A0

&g= t;=A0

&g= t;=A0

&g= t; My application has sent the ASP-ACTIVE to peer IPSP node and received th= e Notify(AS-ACTIVE). Now I restarted the IP network services and as a resul= t remote IPSP node marks the state of my AS as down and sends an Notify(AS-= PENDING) which my M3UA stack treats as =93UNEXPECTED=94 message and does no= thing as it has not received any notification from SCTP that connection was= down so it keeps the local AS ACTIVE and responds with ERROR=A0 message wi= th error code =93UNEXPECTED message=94.

&g= t;=A0

&g= t;=A0

&g= t;=A0

&g= t; My question is what should be my behavior when AS-PENDING is received?

&g= t;=A0

&g= t;=A0

&g= t;=A0

&g= t; Regards

&g= t;=A0

&g= t; Deepak

&g= t;=A0

&g= t; ________________________________

&g= t; "DISCLAIMER: This message is proprietary to Aricent and is intended= solely for the use of the individual to whom it is addressed. It may conta= in privileged or confidential information and should not be circulated or u= sed for any purpose other than for what it is intended. If you have receive= d this message in error,please notify the originator immediately. If you ar= e not the intended recipient, you are notified that you are strictly prohib= ited from using, copying, altering, or disclosing the contents of this mess= age. Aricent accepts no responsibility for loss or damage arising from the = use of the information transmitted by this email including damage from viru= s."

&g= t;=A0

&g= t; _______________________________________________

&g= t; Sigtran mailing list

&g= t; Sigtran@ietf.org

&g= t; https://www.ietf.org/mailman/listinfo/sigtran

&g= t;=A0



"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than = for what it is intended. If you have received this message in error,please = notify the originator immediately. If you are not the intended recipient, y= ou are notified that you are strictly prohibited from using, copying, alter= ing, or disclosing the contents of this message. Aricent accepts no respons= ibility for loss or damage arising from the use of the information transmit= ted by this email including damage from virus."

______________________________________________= _
Sigtran mailing list
Sigtran@ie= tf.org
https://www.ietf.org/mailman/listinfo/sigtran


--001636c5b1e2d4c0aa0475f71c52-- From Michael.Tuexen@lurchi.franken.de Thu Oct 15 04:40:20 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AAE3A681C for ; Thu, 15 Oct 2009 04:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.038 X-Spam-Level: ** X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXQs-cR9JDO1 for ; Thu, 15 Oct 2009 04:40:18 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 8FCCE3A6781 for ; Thu, 15 Oct 2009 04:40:18 -0700 (PDT) Received: from [192.168.1.100] (p508FD4D6.dip.t-dialin.net [80.143.212.214]) by mail-n.franken.de (Postfix) with ESMTP id 201EA1C0B4047; Thu, 15 Oct 2009 13:40:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <00D42150952F70458C66072322F7FE25026E800E@saturn2.aculab.com> Date: Thu, 15 Oct 2009 13:40:19 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <00D42150952F70458C66072322F7FE25026E800E@saturn2.aculab.com> To: David Laight X-Mailer: Apple Mail (2.1076) Cc: sigtran@ietf.org Subject: Re: [Sigtran] Abort chunk bundled with data chunk X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 11:40:20 -0000 On Oct 15, 2009, at 12:04 PM, David Laight wrote: >> I would just start processing the packet, process the DATA chunk, >> find the ABORT, decide the packet is illegal, discard the >> association, >> and do not send an ABORT since I received one. > > That might lead to the application processing the data from > the DATA chunk .... ... correct. And the problem is? The message was sent from a peer with a broken SCTP stack. An SCTP implementation can process a packet from the beginning and does not need to roll back anything. A prescreening is not required, I think. Best regards Michael > > David > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton > Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > P Please consider the environment and don't print this e-mail unless > you really need to > From deepak.gunjal@aricent.com Thu Oct 15 05:03:09 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91AFE3A63D3 for ; Thu, 15 Oct 2009 05:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNKfmg+XV3JK for ; Thu, 15 Oct 2009 05:03:00 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id ABF753A67FB for ; Thu, 15 Oct 2009 05:02:58 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id C53DA23658; Thu, 15 Oct 2009 17:31:10 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id B70CE23682; Thu, 15 Oct 2009 17:31:10 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Thu, 15 Oct 2009 17:33:00 +0530 From: Deepak Gunjal To: Ankit Kumar Sharma Date: Thu, 15 Oct 2009 17:32:59 +0530 Thread-Topic: [Sigtran] In IPSP-IPSP mode what should be the behavior on receving Notify(AS-PENDING) when AS is already AS-ACTIVE Thread-Index: AcpNhfprkz7y8DxITqGALh3/J5hsnAAABQUQ Message-ID: References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> <6dbbbf160910150355m442ecf62lb554656271bcace2@mail.gmail.com> In-Reply-To: <6dbbbf160910150355m442ecf62lb554656271bcace2@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BDF44534797E3E46B55F3D12DE0C4BC40322100890GUREXMB01ASIA_" MIME-Version: 1.0 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on receving Notify(AS-PENDING) when AS is already AS-ACTIVE X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 12:03:09 -0000 --_000_BDF44534797E3E46B55F3D12DE0C4BC40322100890GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think while restarting the network it is upto the IP layer which get rest= arted i.e. transport restart and probably the SCTP connection context remai= ns active. That's why both end keeps on using the existing connection to send Notify a= nd ERROR. So if there any reference in the RFC that a peer can send Notify = with AS-PENDING from AS-ACTIVE state? If yes than what should be the behavior at receiving end? Regards Deepak ________________________________ From: Ankit Kumar Sharma [mailto:ankisharma@gmail.com] Sent: Thursday, October 15, 2009 4:25 PM To: Deepak Gunjal Cc: sigtran@ietf.org Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on rec= eving Notify(AS-PENDING) when AS is already AS-ACTIVE Could you please check why your SCTP layer is not sending connection restar= t indication to M3UA? On Thu, Oct 15, 2009 at 10:48 AM, Deepak Gunjal > wrote: It seems that both the end points keeps the connection alive as I can see a= fter network restart Spectra2 sends Notify(AS-PENDING) on the previously es= tablished connection and my M3UA stack responds with ERROR(Unexpected-Msg) = as the AS state at my stack is ACTIVE. So the ERROR message does reaches to= spectra2 and the sequence continues. I am still not able to figure out how to come out of this loop? As per RFC = there is no case where I can receive AS-PENDING for AS-ACTIVE. Any suggestions? Regards Deepak -----Original Message----- From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] Sent: Friday, October 09, 2009 6:33 PM To: Deepak Gunjal Cc: sigtran@ietf.org Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on rec= eving Notify(AS-PENDING) when AS is already AS-ACTIVE Hi Deepak, I think your M3UA stack is correct in sending the Error message but your underlying SCTP should send some restart or down indication to your M3UA stack. 5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override ... Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., SGP to ASP1) would not occur. So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but in section 4.3.3 If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or SCTP-RESTART indication primitive from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP_STATUS indication primitive. The state of the ASP will be moved to ASP- DOWN. and in section 4.3.4.5 A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. The question is: As per section 4.3.3 M3UA should change the ASP to DOWN upon detecting SCTP failure and as per section 4.3.4.5 NOTIFY messages are not sent to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to DOWN marked ASPs? -- Ashwani On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal > wrote: > > Hi, > > > > Here is the brief description: > > > > I am running my application emulating the role of a AS having 2 ASP in ov= erride mode. Out of 2 ASP one ASP is ACTIVE and other is down. > > > > My application has sent the ASP-ACTIVE to peer IPSP node and received the= Notify(AS-ACTIVE). Now I restarted the IP network services and as a result= remote IPSP node marks the state of my AS as down and sends an Notify(AS-P= ENDING) which my M3UA stack treats as "UNEXPECTED" message and does nothing= as it has not received any notification from SCTP that connection was down= so it keeps the local AS ACTIVE and responds with ERROR message with erro= r code "UNEXPECTED message". > > > > My question is what should be my behavior when AS-PENDING is received? > > > > Regards > > Deepak > > ________________________________ > "DISCLAIMER: This message is proprietary to Aricent and is intended solel= y for the use of the individual to whom it is addressed. It may contain pri= vileged or confidential information and should not be circulated or used fo= r any purpose other than for what it is intended. If you have received this= message in error,please notify the originator immediately. If you are not = the intended recipient, you are notified that you are strictly prohibited f= rom using, copying, altering, or disclosing the contents of this message. A= ricent accepts no responsibility for loss or damage arising from the use of= the information transmitted by this email including damage from virus." > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." --_000_BDF44534797E3E46B55F3D12DE0C4BC40322100890GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think while restarting the network i= t is upto the IP layer which get restarted i.e. transport restart and proba= bly the SCTP connection context remains active.

 

That’s why both end keeps on usi= ng the existing connection to send Notify and ERROR. So if there any refere= nce in the RFC that a peer can send Notify with AS-PENDING from AS-ACTIVE state?

 

If yes than what should be the behavio= r at receiving end?

 

Regards

Deepak


From: Anki= t Kumar Sharma [mailto:ankisharma@gmail.com]
Sent: Thursday, October 15, = 2009 4:25 PM
To: Deepak Gunjal
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] In IP= SP-IPSP mode what should be the behavior on receving Notify(AS-PENDING) whe= n AS is already AS-ACTIVE

 

Could you please chec= k why your SCTP layer is not sending connection restart indicatio= n to M3UA?

On Thu, Oct 15, 2009 at 10:48 AM, Deepak Gunjal <deepak.gunjal@aricent.com> wrote:=

It seems that both the end points keeps the connec= tion alive as I can see after network restart Spectra2 sends Notify(AS-PEND= ING) on the previously established connection and my M3UA stack responds with ERROR(Unexpected-Msg) as the AS state at m= y stack is ACTIVE. So the ERROR message does reaches to spectra2 and the se= quence continues.

 

I am still not able to figure out how to come out = of this loop? As per RFC there is no case where I can receive AS-PENDING fo= r AS-ACTIVE.

 

Any suggestions?

 

Regards

Deepak

 

-----Original Message-----
From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com]
Sent: Friday, October 09, 2009 6:33 PM
To: Deepak Gunjal
Cc: sigtran@ietf.org<= /a>
Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on rec= eving Notify(AS-PENDING) when AS is already AS-ACTIVE

 

Hi Deepak,

 

I think your M3UA stack is correct in sending the = Error message but

your underlying SCTP should send some restart= or down indication to

your M3UA stack.

 

5.2.1.  1+1 Sparing, Withdrawal of ASP, B= ackup Override

...

   Note: If the SGP M3UA layer detects t= he loss of the M3UA peer (e.g.,

   M3UA heartbeat loss or detection of S= CTP failure), the initial ASP

   Inactive message exchange (i.e., SGP = to ASP1) would not occur.

 

So peer M3UA is correct in sending NOTIFY (AS-PEND= ING) messages but

 

in section 4.3.3

   If the M3UA layer subsequently receiv= es an SCTP-COMMUNICATION_DOWN or

   SCTP-RESTART indication primitive fro= m the underlying SCTP layer, it

   will inform the Layer Management by i= nvoking the M-SCTP_STATUS

   indication primitive.  The state= of the ASP will be moved to ASP-

   DOWN.

and in section 4.3.4.5

   A Notify message reflecting a change = in the AS state MUST be sent to

   all ASPs in the AS, except those in t= he ASP-DOWN state, with

   appropriate Status Information and an= y ASP Identifier of the failed

   ASP.

 

The question is:

As per section 4.3.3 M3UA should change the ASP to= DOWN upon detecting

SCTP failure and as per section 4.3.4.5 NOTIFY mes= sages are not sent

to DOWN ASPs. So why in section 5.2.1 NOTIFY messa= ges are sent to DOWN

marked ASPs?

 

-- Ashwani

 

 

On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal <= deepak.gunja= l@aricent.com> wrote:

> Hi,

> Here is the brief description:<= o:p>

> I am running my application emulating the rol= e of a AS having 2 ASP in override mode. Out of 2 ASP one ASP is ACTIVE and= other is down.

> My application has sent the ASP-ACTIVE to pee= r IPSP node and received the Notify(AS-ACTIVE). Now I restarted the IP netw= ork services and as a result remote IPSP node marks the state of my AS as down and sends an Notify(AS-PENDING) whic= h my M3UA stack treats as “UNEXPECTED” message and does nothing= as it has not received any notification from SCTP that connection was down= so it keeps the local AS ACTIVE and responds with ERROR  message with error code “UNEXPECTED message”.=

> My question is what should be my behavior whe= n AS-PENDING is received?

> Regards

> Deepak

> ________________________________

> "DISCLAIMER: This message is proprietary= to Aricent and is intended solely for the use of the individual to whom it= is addressed. It may contain privileged or confidential information and should not be circulated or used for any purp= ose other than for what it is intended. If you have received this message i= n error,please notify the originator immediately. If you are not the intend= ed recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing t= he contents of this message. Aricent accepts no responsibility for loss or = damage arising from the use of the information transmitted by this email in= cluding damage from virus."

> _____________________________________________= __

> Sigtran mailing list=

> Sigtran@ietf.org<= /span>

> https://www.ietf.org/mailman/listinfo/sigtran=

 


"DISCLAIMER: This message is prop= rietary to Aricent and is intended solely for the use of the individual to = whom it is addressed. It may contain privileged or confidential information and should not be circu= lated or used for any purpose other than for what it is intended. If you ha= ve received this message in error,please notify the originator immediately.= If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, alt= ering, or disclosing the contents of this message. Aricent accepts no respo= nsibility for loss or damage arising from the use of the information transm= itted by this email including damage from virus."


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

 



"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error,please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly proh= ibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
--_000_BDF44534797E3E46B55F3D12DE0C4BC40322100890GUREXMB01ASIA_-- From ankisharma@gmail.com Thu Oct 15 07:08:22 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3E728C0F0 for ; Thu, 15 Oct 2009 07:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UA0aFdoUMA1 for ; Thu, 15 Oct 2009 07:08:20 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 1A4A33A687E for ; Thu, 15 Oct 2009 07:08:19 -0700 (PDT) Received: by ewy4 with SMTP id 4so567938ewy.37 for ; Thu, 15 Oct 2009 07:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hGDtXBdU06A9aFUuFMFdBqk6Mvv/i7dY1JJYyjAy9c0=; b=ICLSkuosivEYwck2DtyC5r04eOD/RKp4VT/v2BtxjggfVn1WDkVh2UdviZpCpUzHpN TABegmgxsyz25dfggJ7MXXXngH40MAYp9Do64R0MiSI3J3lfsD3KFSNb3bbOlM09X5tA 9mWvBoM8tCirYUCRGLX7jsg4JLMvUlIhgsU4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Hhf0CBSkw4MxgxbSMgTZJOhMx3//CPBH5P24hlhQLOc2CNxiCOyqc1VDxshNJs3wNB NnNPoxv95PuwPcCQS72qUe0FhDV3qkgIDjOvwo4ziXvgFkM+CNyfeugHTIXiKelh1mkg ZeD4ACrnUPaUZbx489kDSiKeNr+hkQ6v0q5+o= MIME-Version: 1.0 Received: by 10.216.88.85 with SMTP id z63mr24474wee.129.1255615698257; Thu, 15 Oct 2009 07:08:18 -0700 (PDT) In-Reply-To: References: <341a09720910090602t320e951ap38b853492c774920@mail.gmail.com> <6dbbbf160910150355m442ecf62lb554656271bcace2@mail.gmail.com> Date: Thu, 15 Oct 2009 15:08:18 +0100 Message-ID: <6dbbbf160910150708p1568c962hf370bbea230fabd7@mail.gmail.com> From: Ankit Kumar Sharma To: Deepak Gunjal Content-Type: multipart/alternative; boundary=0016e6d7ed30ab47f30475f9cf07 Cc: "sigtran@ietf.org" Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on receving Notify(AS-PENDING) when AS is already AS-ACTIVE X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 14:08:22 -0000 --0016e6d7ed30ab47f30475f9cf07 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Peer has detected a connection issue and probably that's why it has sent a notify message after marking the ASP down/inactive. Could you verify the SCTP heartbeat parameter value at your and peer's end? If they are different then configure them to have a same value. On Thu, Oct 15, 2009 at 1:02 PM, Deepak Gunjal w= rote: > I think while restarting the network it is upto the IP layer which get > restarted i.e. transport restart and probably the SCTP connection context > remains active. > > > > That=92s why both end keeps on using the existing connection to send Noti= fy > and ERROR. So if there any reference in the RFC that a peer can send Noti= fy > with AS-PENDING from AS-ACTIVE state? > > > > If yes than what should be the behavior at receiving end? > > > > Regards > > Deepak > ------------------------------ > > *From:* Ankit Kumar Sharma [mailto:ankisharma@gmail.com] > *Sent:* Thursday, October 15, 2009 4:25 PM > > *To:* Deepak Gunjal > *Cc:* sigtran@ietf.org > *Subject:* Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on > receving Notify(AS-PENDING) when AS is already AS-ACTIVE > > > > Could you please check why your SCTP layer is not sending connection > restart indication to M3UA? > > On Thu, Oct 15, 2009 at 10:48 AM, Deepak Gunjal > wrote: > > It seems that both the end points keeps the connection alive as I can see > after network restart Spectra2 sends Notify(AS-PENDING) on the previously > established connection and my M3UA stack responds with ERROR(Unexpected-M= sg) > as the AS state at my stack is ACTIVE. So the ERROR message does reaches = to > spectra2 and the sequence continues. > > > > I am still not able to figure out how to come out of this loop? As per RF= C > there is no case where I can receive AS-PENDING for AS-ACTIVE. > > > > Any suggestions? > > > > Regards > > Deepak > > > > -----Original Message----- > From: Ashwani Kathuria [mailto:ashwani.grps@gmail.com] > Sent: Friday, October 09, 2009 6:33 PM > To: Deepak Gunjal > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on > receving Notify(AS-PENDING) when AS is already AS-ACTIVE > > > > Hi Deepak, > > > > I think your M3UA stack is correct in sending the Error message but > > your underlying SCTP should send some restart or down indication to > > your M3UA stack. > > > > 5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override > > ... > > Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., > > M3UA heartbeat loss or detection of SCTP failure), the initial ASP > > Inactive message exchange (i.e., SGP to ASP1) would not occur. > > > > So peer M3UA is correct in sending NOTIFY (AS-PENDING) messages but > > > > in section 4.3.3 > > If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or > > SCTP-RESTART indication primitive from the underlying SCTP layer, it > > will inform the Layer Management by invoking the M-SCTP_STATUS > > indication primitive. The state of the ASP will be moved to ASP- > > DOWN. > > and in section 4.3.4.5 > > A Notify message reflecting a change in the AS state MUST be sent to > > all ASPs in the AS, except those in the ASP-DOWN state, with > > appropriate Status Information and any ASP Identifier of the failed > > ASP. > > > > The question is: > > As per section 4.3.3 M3UA should change the ASP to DOWN upon detecting > > SCTP failure and as per section 4.3.4.5 NOTIFY messages are not sent > > to DOWN ASPs. So why in section 5.2.1 NOTIFY messages are sent to DOWN > > marked ASPs? > > > > -- Ashwani > > > > > > On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gunjal > wrote: > > > > > > Hi, > > > > > > > > > > > > Here is the brief description: > > > > > > > > > > > > I am running my application emulating the role of a AS having 2 ASP in > override mode. Out of 2 ASP one ASP is ACTIVE and other is down. > > > > > > > > > > > > My application has sent the ASP-ACTIVE to peer IPSP node and received t= he > Notify(AS-ACTIVE). Now I restarted the IP network services and as a resul= t > remote IPSP node marks the state of my AS as down and sends an > Notify(AS-PENDING) which my M3UA stack treats as =93UNEXPECTED=94 message= and > does nothing as it has not received any notification from SCTP that > connection was down so it keeps the local AS ACTIVE and responds with ERR= OR > message with error code =93UNEXPECTED message=94. > > > > > > > > > > > > My question is what should be my behavior when AS-PENDING is received? > > > > > > > > > > > > Regards > > > > > > Deepak > > > > > > ________________________________ > > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may cont= ain > privileged or confidential information and should not be circulated or us= ed > for any purpose other than for what it is intended. If you have received > this message in error,please notify the originator immediately. If you ar= e > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of t= his > message. Aricent accepts no responsibility for loss or damage arising fro= m > the use of the information transmitted by this email including damage fro= m > virus." > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www.ietf.org/mailman/listinfo/sigtran > > > > > > ------------------------------ > > "DISCLAIMER: This message is proprietary to Aricent and is intended solel= y > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or us= ed > for any purpose other than for what it is intended. If you have received > this message in error,please notify the originator immediately. If you ar= e > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of t= his > message. Aricent accepts no responsibility for loss or damage arising fro= m > the use of the information transmitted by this email including damage fro= m > virus." > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > > > > ------------------------------ > "DISCLAIMER: This message is proprietary to Aricent and is intended solel= y > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or us= ed > for any purpose other than for what it is intended. If you have received > this message in error,please notify the originator immediately. If you ar= e > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of t= his > message. Aricent accepts no responsibility for loss or damage arising fro= m > the use of the information transmitted by this email including damage fro= m > virus." > --0016e6d7ed30ab47f30475f9cf07 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Peer has detected a connection issue and probably that's why it ha= s sent=A0a=A0notify message after marking the ASP down/inactive.
=A0
Could you verify the SCTP heartbeat parameter value=A0at your and peer= 's end? If they are different then configure them to have a same value.=

On Thu, Oct 15, 2009 at 1:02 PM, Deepak Gunjal <= span dir=3D"ltr"><deepak.gu= njal@aricent.com> wrote:

I think while r= estarting the network it is upto the IP layer which get restarted i.e. tran= sport restart and probably the SCTP connection context remains active.

=A0

That=92s why bo= th end keeps on using the existing connection to send Notify and ERROR. So = if there any reference in the RFC that a peer can send Notify with AS-PENDI= NG from AS-ACTIVE state?

=A0

If yes than wha= t should be the behavior at receiving end?

=A0

Regards<= /font>

Deepak


From:= Ankit Kumar Sharma [mailto:ankisharma@gmail.com]
Sent: Thursday, October 15,= 2009 4:25 PM=20


To: D= eepak Gunjal
Cc: sigtran@ietf.org
<= span style=3D"FONT-WEIGHT: bold">Subject: Re: [Sigtran] In IPSP-= IPSP mode what should be the behavior on receving Notify(AS-PENDING) when A= S is already AS-ACTIVE

=A0

Could you please check = why your SCTP=A0layer is not sending=A0connection restart indication to M3U= A?

On Thu, Oct 15, 2009 at 10:48 AM, Deepak Gunjal <<= a href=3D"mailto:deepak.gunjal@aricent.com" target=3D"_blank">deepak.gunjal= @aricent.com> wrote:

It seems that both the end points keeps t= he connection alive as I can see after network restart Spectra2 sends Notif= y(AS-PENDING) on the previously established connection and my M3UA stack re= sponds with ERROR(Unexpected-Msg) as the AS state at my stack is ACTIVE. So= the ERROR message does reaches to spectra2 and the sequence continues.

=A0

I am still not able to figure out how to = come out of this loop? As per RFC there is no case where I can receive AS-P= ENDING for AS-ACTIVE.

=A0

Any suggestions?

=A0

Regards

Deepak

=A0

-----Original Message-----
From: Ashwa= ni Kathuria [mailto:ashwani.grps@gmail.com]
Sent: Friday, October 09, 2009 6:33 PM
To: Deepak Gunjal
Cc: sigtran@ietf.org
Subj= ect: Re: [Sigtran] In IPSP-IPSP mode what should be the behavior on recevin= g Notify(AS-PENDING) when AS is already AS-ACTIVE

=A0

Hi Deepak,

=A0

I think your M3UA stack is correct in sen= ding the Error message but

your underlying SCTP should send=A0some r= estart or down indication to

your M3UA stack.

=A0

5.2.1.=A0 1+1 Sparing, Withdrawal of ASP,= Backup Override

...

=A0=A0 Note: If the SGP M3UA layer detect= s the loss of the M3UA peer (e.g.,

=A0=A0 M3UA heartbeat loss or detection o= f SCTP failure), the initial ASP

=A0=A0 Inactive message exchange (i.e., S= GP to ASP1) would not occur.

=A0

So peer M3UA is correct in sending NOTIFY= (AS-PENDING) messages but

=A0

in section 4.3.3

=A0=A0 If the M3UA layer subsequently rec= eives an SCTP-COMMUNICATION_DOWN or

=A0=A0 SCTP-RESTART indication primitive = from the underlying SCTP layer, it

=A0=A0 will inform the Layer Management b= y invoking the M-SCTP_STATUS

=A0=A0 indication primitive.=A0 The state= of the ASP will be moved to ASP-

=A0=A0 DOWN.

and in section 4.3.4.5

=A0=A0 A Notify message reflecting a chan= ge in the AS state MUST be sent to

=A0=A0 all ASPs in the AS, except those i= n the ASP-DOWN state, with

=A0=A0 appropriate Status Information and= any ASP Identifier of the failed

=A0=A0 ASP.

=A0

The question is:

As per section 4.3.3 M3UA should change t= he ASP to DOWN upon detecting

SCTP failure and as per section 4.3.4.5 N= OTIFY messages are not sent

to DOWN ASPs. So why in section 5.2.1 NOT= IFY messages are sent to DOWN

marked ASPs?

=A0

-- Ashwani

=A0

=A0

On Fri, Oct 9, 2009 at 2:53 PM, Deepak Gu= njal <dee= pak.gunjal@aricent.com> wrote:

>=A0

> Hi,

>=A0

>=A0

>=A0

> Here is the brief description:

>=A0

>=A0

>=A0

> I am running my application emulatin= g the role of a AS having 2 ASP in override mode. Out of 2 ASP one ASP is A= CTIVE and other is down.

>=A0

>=A0

>=A0

> My application has sent the ASP-ACTI= VE to peer IPSP node and received the Notify(AS-ACTIVE). Now I restarted th= e IP network services and as a result remote IPSP node marks the state of m= y AS as down and sends an Notify(AS-PENDING) which my M3UA stack treats as = =93UNEXPECTED=94 message and does nothing as it has not received any notifi= cation from SCTP that connection was down so it keeps the local AS ACTIVE a= nd responds with ERROR=A0 message with error code =93UNEXPECTED message=94.=

>=A0

>=A0

>=A0

> My question is what should be my beh= avior when AS-PENDING is received?

>=A0

>=A0

>=A0

> Regards

>=A0

> Deepak

>=A0

> ________________________________

> "DISCLAIMER: This message is pr= oprietary to Aricent and is intended solely for the use of the individual t= o whom it is addressed. It may contain privileged or confidential informati= on and should not be circulated or used for any purpose other than for what= it is intended. If you have received this message in error,please notify t= he originator immediately. If you are not the intended recipient, you are n= otified that you are strictly prohibited from using, copying, altering, or = disclosing the contents of this message. Aricent accepts no responsibility = for loss or damage arising from the use of the information transmitted by t= his email including damage from virus."

>=A0

> ____________________________________= ___________

> Sigtran mailing list

> Sigtran@ietf.org

> https://www.ietf.org/mailman/listin= fo/sigtran

>=A0

=A0


"DISCLAIME= R: This message is proprietary to Aricent and is intended solely for the us= e of the individual to whom it is addressed. It may contain privileged or c= onfidential information and should not be circulated or used for any purpos= e other than for what it is intended. If you have received this message in = error,please notify the originator immediately. If you are not the intended= recipient, you are notified that you are strictly prohibited from using, c= opying, altering, or disclosing the contents of this message. Aricent accep= ts no responsibility for loss or damage arising from the use of the informa= tion transmitted by this email including damage from virus."


___________________= ____________________________
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran

=A0



"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than = for what it is intended. If you have received this message in error,please = notify the originator immediately. If you are not the intended recipient, y= ou are notified that you are strictly prohibited from using, copying, alter= ing, or disclosing the contents of this message. Aricent accepts no respons= ibility for loss or damage arising from the use of the information transmit= ted by this email including damage from virus."

--0016e6d7ed30ab47f30475f9cf07-- From prasanna2602@gmail.com Tue Oct 20 00:12:46 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A0D3A67E1 for ; Tue, 20 Oct 2009 00:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stFJsXiEIzhV for ; Tue, 20 Oct 2009 00:12:45 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 030693A67A1 for ; Tue, 20 Oct 2009 00:12:44 -0700 (PDT) Received: by fxm18 with SMTP id 18so6041801fxm.37 for ; Tue, 20 Oct 2009 00:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=QqGJRQKcWLNJtpVe1hCw5iFjNp2ihqj2VeE8vLS0Iww=; b=quCGvUK13tq61tt4gtZCLSY2ZUOm+sYa7/yy5qNyvW7eDXDiUBOCiuMMs1TcerDqzk nPr1fjMR0VdMZvRjCy2AsM8ofllaTr23YsrQEOmovCmNhKhQSIB8uiVk4pNfCKM+VC7n iSbHvn7ZeIx8np39HqWA3r7wAd1usUGxQYR9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=t6oJhPhkbzFbB4ep8RALULQ7ouJjxQney0Jk8ek+F/6OzfRSWy619zjlM3Q3LvIQFF vHFhOvPTiy1vWviE+ab7p1ltdpqNgV63gFMY1ifHqXOxC4AKk2P7LG4YBgdgKN7A6+/m rw9QIQnRK8MFjVCN8WrKCXr6BSEldFQnUzjjM= MIME-Version: 1.0 Received: by 10.204.160.65 with SMTP id m1mr6058250bkx.193.1256022769059; Tue, 20 Oct 2009 00:12:49 -0700 (PDT) Date: Tue, 20 Oct 2009 12:42:49 +0530 Message-ID: <67b5210b0910200012o5264f01bu8ce3a839e23f508a@mail.gmail.com> From: Prasanna Kumar To: sigtran@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Sigtran] Bundling ABORT chunk with OOTB SHUTDOWN-ACK chunk in SCTP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 08:05:42 -0000 Hi, For the OOTB packet handling in SCTP RFC 4960 says that, if SCTP receives SHUTDOWN-ACK chunk as a OOTB chunk, it should send an SHUTDOWN-COMPLETE chunk with the T-Bit set and copying the V-Tag of the SHUTDOWN-ACK chunk. In RFC 4960 section 8.4: 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet must fill in the Verification Tag field of the outbound packet with the Verification Tag received in the SHUTDOWN ACK and set the T bit in the Chunk Flags to indicate that the Verification Tag is reflected. As the ABORT chunk can be bundled with control chunks, in a scenario where the SCTP is received the SHUTDOWN-ACK chunk bundled with the ABORT chunk and SHUTDOWN-ACK is placed first. In the same section of handling OOTB chunks, it says that the SCTP should discard the OOTB packet containing the ABORT chunk. In RFC 4960 section 8.4: 2) If the OOTB packet contains an ABORT chunk, the receiver MUST silently discard the OOTB packet and take no further action. Here what should be the expected behavior of the SCTP? Is it has to reply to the SHUTDOWN-ACK with the SHUTDOWN-COMPLETE or it should silently discard the packet? If it needs to be discarded, then its an overhead on performance as SCTP needs to traverse through the all chunks to detect the presence of the ABORT chunk in a packet. Please let me know the expected behavior in this scenario and thanks in advance. -- Regards, Prasanna. From Salil.Agrawal@ccpu.com Tue Oct 20 01:16:01 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DBA53A6767 for ; Tue, 20 Oct 2009 01:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5CGlfJrp02n for ; Tue, 20 Oct 2009 01:16:00 -0700 (PDT) Received: from sd-smtp.ccpu.com (sd-smtp.ccpu.com [65.44.201.8]) by core3.amsl.com (Postfix) with ESMTP id 289FB3A657C for ; Tue, 20 Oct 2009 01:15:59 -0700 (PDT) Received: from sd-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 67A1D6209FF for ; Tue, 20 Oct 2009 01:16:02 -0700 (PDT) Received: from alladin.ccpu.com (alladin.ccpu.com [172.16.0.216]) by sd-smtp.ccpu.com (Postfix) with ESMTP id 45719620964 for ; Tue, 20 Oct 2009 01:16:01 -0700 (PDT) Received: from IN-EXCHANGE.ccpu.com ([172.25.0.16]) by alladin.ccpu.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 01:16:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA515D.8E9C86F9" Date: Tue, 20 Oct 2009 13:45:12 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F0031C7E9B@in-exchange.ccpu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP packet containing an ABORT chunk bundled after a SHUTDOWN ACK Thread-Index: AcpRXXHCbqSSDLU+S/SL7l+INCaMfg== From: "Salil Agrawal" To: X-OriginalArrivalTime: 20 Oct 2009 08:16:01.0469 (UTC) FILETIME=[8F7E06D0:01CA515D] X-TM-AS-Product-Ver: IMSS-7.0.0.3216-5.6.0.1016-16958.003 X-TM-AS-Result: No--12.697-5.0-31-1 X-imss-scan-details: No--12.697-5.0-31-1 Subject: [Sigtran] SCTP packet containing an ABORT chunk bundled after a SHUTDOWN ACK X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 08:16:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA515D.8E9C86F9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We have a confusion while understanding the SCTP RFC4960 section 8.4 it = says=20 2) If the OOTB packet contains an ABORT chunk, the receiver MUST silently discard the OOTB packet and take no further action. Otherwise, and=20 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet must fill in the Verification Tag field of the outbound packet with the Verification Tag received in the SHUTDOWN ACK and set the T bit in the Chunk Flags to indicate that the Verification Tag is reflected. Now consider a negative scenario where association in CLOSED state = received an SCTP packet containing an ABORT chunk bundled after a = SHUTDOWN ACK chunk. Should it send the SHUTDOWN-COMPLETE or silently = discard the packet. =20 Thanks, Salil Agrawal ------_=_NextPart_001_01CA515D.8E9C86F9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A=
=0A=
=0A=

Hi,

=0A=

We have a confusion while understanding the SCTP RFC4960 section 8.4 = it says =0A=

2)  If the OOTB packet contains an ABORT =
chunk, the receiver MUST=0A=
       silently discard the OOTB packet and take no further action.=0A=
       Otherwise,
=0A=

and

5)  If the packet contains a SHUTDOWN ACK =
chunk, the receiver should=0A=
       respond to the sender of the OOTB packet with a SHUTDOWN=0A=
       COMPLETE.  When sending the SHUTDOWN COMPLETE, the receiver of=0A=
       the OOTB packet must fill in the Verification Tag field of the=0A=
       outbound packet with the Verification Tag received in the=0A=
       SHUTDOWN ACK and set the T bit in the Chunk Flags to indicate=0A=
       that the Verification Tag is reflected.
=0A=

Now consider a negative scenario where association in CLOSED =0A= state received an SCTP packet containing an ABORT chunk bundled after a = SHUTDOWN =0A= ACK chunk. Should it send the SHUTDOWN-COMPLETE or silently discard the =0A= packet.

=0A=

 

=0A=

Thanks,

=0A=

Salil Agrawal

------_=_NextPart_001_01CA515D.8E9C86F9-- From Salil.Agrawal@ccpu.com Tue Oct 20 01:19:39 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2383A657C for ; Tue, 20 Oct 2009 01:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT49azTCT4hr for ; Tue, 20 Oct 2009 01:19:38 -0700 (PDT) Received: from sd-smtp.ccpu.com (sd-smtp.ccpu.com [65.44.201.8]) by core3.amsl.com (Postfix) with ESMTP id 844933A6358 for ; Tue, 20 Oct 2009 01:19:38 -0700 (PDT) Received: from sd-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 0B33F6209FF for ; Tue, 20 Oct 2009 01:19:46 -0700 (PDT) Received: from alladin.ccpu.com (alladin.ccpu.com [172.16.0.216]) by sd-smtp.ccpu.com (Postfix) with ESMTP id E3993620964 for ; Tue, 20 Oct 2009 01:19:45 -0700 (PDT) Received: from IN-EXCHANGE.ccpu.com ([172.25.0.16]) by alladin.ccpu.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 01:19:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA515E.140CEC31" Date: Tue, 20 Oct 2009 13:48:23 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F0031C7E9C@in-exchange.ccpu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP packet containing an ABORT chunk bundled after a SHUTDOWNACK Thread-Index: AcpRXXHCbqSSDLU+S/SL7l+INCaMfgAAHKhY References: <22F058C3ED9D784E90CE473F2A9847F0031C7E9B@in-exchange.ccpu.com> From: "Salil Agrawal" To: "Salil Agrawal" , X-OriginalArrivalTime: 20 Oct 2009 08:19:45.0577 (UTC) FILETIME=[15123190:01CA515E] X-TM-AS-Product-Ver: IMSS-7.0.0.3216-5.6.0.1016-16958.003 X-TM-AS-Result: No--13.069-5.0-31-1 X-imss-scan-details: No--13.069-5.0-31-1 Subject: Re: [Sigtran] SCTP packet containing an ABORT chunk bundled after aSHUTDOWN ACK X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 08:19:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA515E.140CEC31 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please ignore this query, reply to Prasanna's query as both are same. =20 Thanks, salil ________________________________ From: sigtran-bounces@ietf.org on behalf of Salil Agrawal Sent: Tue 10/20/2009 1:15 AM To: sigtran@ietf.org Subject: [Sigtran] SCTP packet containing an ABORT chunk bundled after = aSHUTDOWN ACK Hi, We have a confusion while understanding the SCTP RFC4960 section 8.4 it = says=20 2) If the OOTB packet contains an ABORT chunk, the receiver MUST silently discard the OOTB packet and take no further action. Otherwise, and=20 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet must fill in the Verification Tag field of the outbound packet with the Verification Tag received in the SHUTDOWN ACK and set the T bit in the Chunk Flags to indicate that the Verification Tag is reflected. Now consider a negative scenario where association in CLOSED state = received an SCTP packet containing an ABORT chunk bundled after a = SHUTDOWN ACK chunk. Should it send the SHUTDOWN-COMPLETE or silently = discard the packet. =20 Thanks, Salil Agrawal ------_=_NextPart_001_01CA515E.140CEC31 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A=
=0A=
Please ignore = this query, =0A= reply to Prasanna's query as both are same.
=0A=
 
=0A=
Thanks,
=0A=
salil
=0A=

=0A=
=0A= From: sigtran-bounces@ietf.org on = behalf of =0A= Salil Agrawal
Sent: Tue 10/20/2009 1:15 AM
To: =0A= sigtran@ietf.org
Subject: [Sigtran] SCTP packet containing an = ABORT =0A= chunk bundled after aSHUTDOWN ACK

=0A=
=0A=
=0A=
=0A=

Hi,

=0A=

We have a confusion while understanding the SCTP RFC4960 section 8.4 = it says =0A=

2)  If the OOTB packet contains an ABORT =
chunk, the receiver MUST=0A=
       silently discard the OOTB packet and take no further action.=0A=
       Otherwise,
=0A=

and

5)  If the packet contains a SHUTDOWN ACK =
chunk, the receiver should=0A=
       respond to the sender of the OOTB packet with a SHUTDOWN=0A=
       COMPLETE.  When sending the SHUTDOWN COMPLETE, the receiver of=0A=
       the OOTB packet must fill in the Verification Tag field of the=0A=
       outbound packet with the Verification Tag received in the=0A=
       SHUTDOWN ACK and set the T bit in the Chunk Flags to indicate=0A=
       that the Verification Tag is reflected.
=0A=

Now consider a negative scenario where association in CLOSED state = received an =0A= SCTP packet containing an ABORT chunk bundled after a SHUTDOWN ACK = chunk. Should =0A= it send the SHUTDOWN-COMPLETE or silently discard the packet.

=0A=

 

=0A=

Thanks,

=0A=

Salil Agrawal

------_=_NextPart_001_01CA515E.140CEC31-- From adi.aquarian@gmail.com Tue Oct 20 02:14:01 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00CE3A6A14 for ; Tue, 20 Oct 2009 02:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft4AYiqDf9S4 for ; Tue, 20 Oct 2009 02:14:00 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id E08783A6A10 for ; Tue, 20 Oct 2009 02:14:00 -0700 (PDT) Received: by pzk42 with SMTP id 42so4562586pzk.31 for ; Tue, 20 Oct 2009 02:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=i0mvJd/ViNu9ljo7oLT2/h2PazaK013CP5yusMp/ch8=; b=niGpciTp8rL9icsZnzerfpq/FGCx7L4hQyeqwf/1VWbARJjC1mrGGNTck55dFAF9HA U8WqFfMePKc8jf+2n32iVriO/klI/2ApleUqdLAhoKgKyBOiFa7HIIWeJyEYgVCi/w4W I4CfxhUzkBt/WSbPtyMtsP4GySAoeVsPXZtWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=iM8F2owJc6hzcubTAd8OMUvAqpOB/3FLSs63mU1W72GJRAbnp7tF8rm1+FG2sYcbG6 avl3a/eKbQFIfDd/nWkVqZuzsEr8fOLziaZCfZ9bV2VLU2zYcx/SYJWCecOQmOZjB6E3 lRtZ85TaG4VDzBvX1mE9i4o7glttYu0f2topg= MIME-Version: 1.0 Received: by 10.143.24.37 with SMTP id b37mr417996wfj.183.1256030046121; Tue, 20 Oct 2009 02:14:06 -0700 (PDT) In-Reply-To: <67b5210b0910200012o5264f01bu8ce3a839e23f508a@mail.gmail.com> References: <67b5210b0910200012o5264f01bu8ce3a839e23f508a@mail.gmail.com> From: Aditya Sehgal Date: Tue, 20 Oct 2009 14:43:46 +0530 Message-ID: <1ac609990910200213r2a320097o8a905be30e643a9a@mail.gmail.com> To: Prasanna Kumar Content-Type: multipart/alternative; boundary=001636e0a758b9edb004765a48b4 Cc: sigtran@ietf.org Subject: Re: [Sigtran] Bundling ABORT chunk with OOTB SHUTDOWN-ACK chunk in SCTP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 09:14:02 -0000 --001636e0a758b9edb004765a48b4 Content-Type: text/plain; charset=ISO-8859-1 Prasanna, Section 9.1 of RFC 4960 also mentions that "an endpoint MUST NOT respond to any received packet that contains an ABORT chunk" Further, In section 8.4, points 3 onwards is an "else" portion of point 2 i.e. if the "oob" packet contains an ABORT chunk discard it else do point 3 onwards. So, an "oob" blue packet containing an ABORT chunk must be discarded. You will only have to traverse the whole chunks in case you receive an "oob" packet which should impact the performance minimally. Regards, Aditya Sehgal On Tue, Oct 20, 2009 at 12:42 PM, Prasanna Kumar wrote: > Hi, > > For the OOTB packet handling in SCTP RFC 4960 says that, if SCTP > receives SHUTDOWN-ACK chunk as a OOTB chunk, it should send an > SHUTDOWN-COMPLETE chunk with the T-Bit set and copying the V-Tag of > the SHUTDOWN-ACK chunk. In RFC 4960 section 8.4: > 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should > respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. > When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet > must fill in the Verification Tag field of the outbound packet with > the Verification Tag received in the SHUTDOWN ACK and set the T bit in > the Chunk Flags to indicate that the Verification Tag is reflected. > > As the ABORT chunk can be bundled with control chunks, in a scenario > where the SCTP is received the SHUTDOWN-ACK chunk bundled with the > ABORT chunk and SHUTDOWN-ACK is placed first. In the same section of > handling OOTB chunks, it says that the SCTP should discard the OOTB > packet containing the ABORT chunk. In RFC 4960 section 8.4: > 2) If the OOTB packet contains an ABORT chunk, the receiver MUST > silently discard the OOTB packet and take no further action. > > Here what should be the expected behavior of the SCTP? Is it has to > reply to the SHUTDOWN-ACK with the SHUTDOWN-COMPLETE or it should > silently discard the packet? If it needs to be discarded, then its an > overhead on performance as SCTP needs to traverse through the all > chunks to detect the presence of the ABORT chunk in a packet. > > Please let me know the expected behavior in this scenario and thanks in > advance. > > -- > Regards, > Prasanna. > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www.ietf.org/mailman/listinfo/sigtran > -- There are only 10 type of people in this World...Those who understand binary and those who dont --001636e0a758b9edb004765a48b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Prasanna,
Section 9.1 of RFC 4960 also mentions that "an endpoint M= UST NOT respond to any received packet that contains an ABORT chunk"

Further, In section 8.4, points 3 onwards = is an "else" portion of point 2 i.e. if the "oob" packe= t contains an ABORT chunk discard it else do point 3 onwards.

So, an "oob" blue packet containing an ABORT chunk must be di= scarded. You will only have to traverse the whole chunks in case you receiv= e an "oob" packet which should impact the performance minimally. =

Regards,
Aditya Sehgal

On Tue, Oct 20, 2009 at 12:42 PM, Pras= anna Kumar <= prasanna2602@gmail.com> wrote:
Hi,

For the OOTB packet handling in SCTP RFC 4960 says that, if SCTP
receives SHUTDOWN-ACK chunk as a OOTB chunk, it should send an
SHUTDOWN-COMPLETE chunk with the T-Bit set and copying the V-Tag of
the SHUTDOWN-ACK chunk. In RFC 4960 section 8.4:
5) If the packet contains a SHUTDOWN ACK chunk, the receiver should
respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE.
When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet
must fill in the Verification Tag field of the outbound packet with
the Verification Tag received in the SHUTDOWN ACK and set the T bit in
the Chunk Flags to indicate that the Verification Tag is reflected.

As the ABORT chunk can be bundled with control chunks, in a scenario
where the SCTP is received the SHUTDOWN-ACK chunk bundled with the
ABORT chunk and SHUTDOWN-ACK is placed first. In the same section of
handling OOTB chunks, it says that the SCTP should discard the OOTB
packet containing the ABORT chunk. In RFC 4960 section 8.4:
2) =A0If the OOTB packet contains an ABORT chunk, the receiver MUST
silently discard the OOTB packet and take no further action.

Here what should be the expected behavior of the SCTP? Is it has to
reply to the SHUTDOWN-ACK with the SHUTDOWN-COMPLETE or it should
silently discard the packet? If it needs to be discarded, then its an
overhead on performance as SCTP needs to traverse through the all
chunks to detect the presence of the ABORT chunk in a packet.

Please let me know the expected behavior in this scenario and thanks in adv= ance.

--
Regards,
Prasanna.
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran



--
There are only 1= 0 type of people in this World...Those who understand binary and those who = dont
--001636e0a758b9edb004765a48b4-- From santhana@huawei.com Thu Oct 22 06:39:59 2009 Return-Path: X-Original-To: sigtran@core3.amsl.com Delivered-To: sigtran@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD45F3A67D9 for ; Thu, 22 Oct 2009 06:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCcLw-1SVJqx for ; Thu, 22 Oct 2009 06:39:56 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6E09E28C151 for ; Thu, 22 Oct 2009 06:39:24 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRX00DCU4LN9E@szxga01-in.huawei.com> for sigtran@ietf.org; Thu, 22 Oct 2009 21:39:23 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRX00FYQ4LN5X@szxga01-in.huawei.com> for sigtran@ietf.org; Thu, 22 Oct 2009 21:39:23 +0800 (CST) Received: from BLRNSHTIPL2NC ([10.18.1.32]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRX00LF24LMWI@szxml04-in.huawei.com> for sigtran@ietf.org; Thu, 22 Oct 2009 21:39:23 +0800 (CST) Date: Thu, 22 Oct 2009 19:03:22 +0530 From: Santhana To: sigtran@ietf.org Message-id: <003201ca531c$39fe0960$2001120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_redeYGlvuik/XjKTiOfadg)" Thread-index: AcpTHDjRKYJKKA6yRdKci4cQnPJlXA== Subject: [Sigtran] [M3UA] Should ASP Id of ASPs be unique across AS X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 13:39:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_redeYGlvuik/XjKTiOfadg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Brian Should the ASP Identifiers of ASPs serving one AS should be unique (or) among all ASPs serving different AS, ASP Id should be unique. ASP Identifier: 32-bit unsigned integer The optional ASP Identifier parameter contains a unique value that is locally significant among the ASPs that support an AS. The SGP should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.8.2). I am getting this doubt bcos of the above RFC statement. Pls clarify. Regards Santhanakrishnan --Boundary_(ID_redeYGlvuik/XjKTiOfadg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Brian

            Should the ASP Identifiers of ASPs serving one AS should be unique (or) among all ASPs serving different AS, ASP Id should be unique.

 

ASP Identifier: 32-bit unsigned integer

 

      The optional ASP Identifier parameter contains a unique value that

      is locally significant among the ASPs that support an AS.  The SGP

      should save the ASP Identifier to be used, if necessary, with the

      Notify message (see Section 3.8.2).

 

I am getting this doubt bcos of the above RFC statement. Pls clarify.

 

Regards

Santhanakrishnan

--Boundary_(ID_redeYGlvuik/XjKTiOfadg)--