[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 <Salil.Agrawal at ccpu.com> 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 at gmail.com]
> Sent: Thursday, October 15, 2009 12:58 PM
> To: Salil Agrawal
> Cc: sigtran at 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 <Salil.Agrawal at ccpu.com>
> 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 at ietf.org
>> https://www.ietf.org/mailman/listinfo/sigtran
>>
>