Re: Abort chunk bundled with data chunk
Ashwani Kathuria <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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:[email protected]] > Sent: Thursday, October 15, 2009 12:58 PM > To: Salil Agrawal > Cc: [email protected] > 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 <[email protected]> > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/sigtran >> >