Chronological Thread 

< Chronological >      < Thread >

---

Hello everyone,
i have the following question:
If a SCTP DATA packet arrives at SCTP instance, and if the TCB doesn't
exists we need to send a ABORT with T-Bit set.
Why is that so?. Don't u think that the ABORT shouldn't be sent whereas
the DATA chunk should be silently discarded.Because
if we keep on sending ABORT to the received DATA packet where the TCB is not
found, the SCTP will be wasting it's resources for
those packets which it shouldn't be worrying about. The SCTP resources here
i mean is CPU time ( SCTP Time) utilized for
formation of ABORT packet and sending it to
the peer

Thanks in advance.
Harish Kulkarni


----- Original Message -----
From:
<discussion-request AT sctp.de>
To:
<discussion AT sctp.de>
Sent: Thursday, April 19, 2001 3:31 PM
Subject: discussion digest, Vol 1 #67 - 2 msgs


> Send discussion mailing list submissions to
> discussion AT sctp.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.sctp.de/mailman/listinfo/discussion
> or, via email, send a message with subject or body 'help' to
> discussion-request AT sctp.de
>
> You can reach the person managing the list at
> discussion-admin AT sctp.de
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of discussion digest..."
>
>
> Today's Topics:
>
> 1. Re: SCTP query (Dan Gora)
> 2. Re: SCTP query (Dan Gora)
>
> --__--__--
>
> Message: 1
> Date: Wed, 18 Apr 2001 10:34:59 -0700 (PDT)
> From: Dan Gora
> <dg AT adax.com>
> To:
> discussion AT sctp.de
> Subject: Re: [SCTP-Discussion] SCTP query
> Reply-To:
> discussion AT sctp.de
>
>
> I have a question regarding byte and bit ordering in the SCTP standard.
>
> I find it to be quite confusing to determine which bits should be
> set in a byte and what is the byte order for certain chunk types specified
> in the standard. I think that I can best illustrate through an example:
>
> take the Data Chunk from the Oct 2000 version of RFC 2960:
>
> 3.3.1 Payload Data (DATA) (0)
>
> The following format MUST be used for the DATA chunk:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type = 0 | Reserved|U|B|E| Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | TSN |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Stream Identifier S | Stream Sequence Number n |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Payload Protocol Identifier |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> \ \
> / User Data (seq n of Stream S) /
> \ \
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> According to this diagram the U bit is bit 13 the B bit is bit 14 and
> the E bit is bit 15 of the 32 bit word.
>
> If we turn the bits around so that the most significant bit is on the left
> and label the bytes in the word (Network Byte Order (Big Endian) where
bytes
> are transmitted in ascending order (ie byte 0, byte 1, byte 2, byte 3,
etc...))
> we get:
>
> 3 2 1 0
> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
> | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Length |U|B|E|Reserved | Type=0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | TSN |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Stream Sequence Number n | Stream Identifier S |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Payload Protocol Identifier |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> \ \
> / User Data (seq n of Stream S) /
> \ \
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> So, for example, we transmit a data chunk that is not fragmented (ie
> has the B and E bits set) with a length of 53 bytes.
> According to RFC diagram, the first word of the data chunk should look
like:
>
> 3 2 1 0
> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
> | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Length |U|B|E|Reserved | Type=0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |0 0 0 0 0 0 0 0|0 0 1 1 0 1 0 1|0 1 1 0 0 0 0 0|0 0 0 0 0 0 0 0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 0x00 0x35 0xc0 0x00
>
> But in fact the reference implementation and ethereal send and decode
> (respectively) DATA chunks as follows:
>
> 3 2 1 0
> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
> | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type = 0 | Reserved|U|B|E| Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 1|0 0 1 1 0 1 0 1|0 0 0 0 0 0 0 0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 0x00 0x03 0x35 0x00
>
>
> So, I guess the question is, is this right? It seems to me that the
> RFC has bits and bytes in the right order with the most significant byte
> and most significant bit on the left, but that the numbers on top of the
> diagrams which label the bits are in the wrong order. That is unless
> it is expressed somewhere that I missed that bit '0' of these diagrams
> is the most significant bit (quite anti-intuitive if you ask me...).
>
> I think that the RFC could be made much easier to understand as far as
> bit/byte ordering if the bit labels on the top of chunk definitions
> were "turned around" as follows and perhaps if byte labels were added
> to make it explicit which byte is transmitted first:
>
> 3.3.1 Payload Data (DATA) (0)
>
>
> Words are written Network Byte Order (Big Endian) and bytes are
transmitted in
> ascending order (ie byte 0, byte 1, byte 2, byte 3, etc...)).
>
> The following format MUST be used for the DATA chunk:
>
> 3 2 1 0
> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
> | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type = 0 | Reserved|U|B|E| Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | TSN |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Stream Identifier S | Stream Sequence Number n |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Payload Protocol Identifier |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> \ \
> / User Data (seq n of Stream S) /
> \ \
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Please let me know if I'm off the mark on this one, but it caused me quite
> a bit of head scratching to realize why data being decoded in ethereal
> and being sent in the reference implementation didn't match my
expectations
> of ordering....
>
>
> Thanks-
> dan
>
> -- Dan Gora, Adax Inc.
>
> (dg AT adax.com)
> phone: (510) 548-7047 fax: (510) 548-5526
>
>
> --__--__--
>
> Message: 2
> Date: Wed, 18 Apr 2001 10:50:24 -0700 (PDT)
> From: Dan Gora
> <dg AT adax.com>
> To:
> discussion AT sctp.de
> Subject: Re: [SCTP-Discussion] SCTP query
> Reply-To:
> discussion AT sctp.de
>
>
> > So, for example, we transmit a data chunk that is not fragmented (ie
> > has the B and E bits set) with a length of 53 bytes.
> > According to RFC diagram, the first word of the data chunk should look
like:
> >
> > 3 2 1 0
> > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
> > | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Length |U|B|E|Reserved | Type=0 |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |0 0 0 0 0 0 0 0|0 0 1 1 0 1 0 1|0 1 1 0 0 0 0 0|0 0 0 0 0 0 0 0|
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 0x00 0x35 0xc0 0x00
> >
> > But in fact the reference implementation and ethereal send and decode
> > (respectively) DATA chunks as follows:
> >
> > 3 2 1 0
> > 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
> > | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Type = 0 | Reserved|U|B|E| Length |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 1|0 0 1 1 0 1 0 1|0 0 0 0 0 0 0 0|
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 0x00 0x03 0x35 0x00
> >
>
>
> I blew this one, it should be:
>
> But in fact the reference implementation and ethereal send and decode
> (respectively) DATA chunks as follows:
>
> 3 2 1 0
> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
> | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type = 0 | Reserved|U|B|E| Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0|0 0 1 1 0 1 0 1|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 0x00 0x03 0x00 0x35
>
> sorry-
> dan
>
>
> --__--__--
>
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion
>
>
> End of discussion Digest_______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion
>
>

---

• [SCTP-Discussion] Re: discussion digest, Vol 1 #67 - 2 msgs, hari, 04/20/2001

---

Archive powered by MHonArc 2.6.19+.