Chronological Thread 

< Chronological >      < Thread >

---

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

---

• [SCTP-Discussion] SCTP query, Deepak Rathore, 04/09/2001
  • Re: [SCTP-Discussion] SCTP query, arun, 04/18/2001
    • Re: [SCTP-Discussion] SCTP query, Dan Gora, 04/18/2001
      • Re: [SCTP-Discussion] SCTP query, Dan Gora, 04/18/2001

---

Archive powered by MHonArc 2.6.19+.