('binary' encoding is not supported, stored as-is)
('binary' encoding is not supported, stored as-is)
David Lehmann wrote:
> RFC 2960 says that the payload protocol ID _is_ a 32 bit unsigned
> integer AND it is in network byte order.
>
>
> RFC 2960, section 3:
> -----------------------------------------------------------------
> 3. SCTP packet Format
>
> An SCTP packet is composed of a common header and chunks. A chunk
> contains either control information or user data.
>
> ...
> All integer fields in an SCTP packet MUST be transmitted in network
> byte order, unless otherwise stated.
> -----------------------------------------------------------------
>
> RFC 2960, section 3.3.1:
> -----------------------------------------------------------------
> 3.3.1 Payload Data (DATA) (0)
> Length: 16 bits (unsigned integer)
> TSN : 32 bits (unsigned integer)
> Stream Identifier S: 16 bits (unsigned integer)
> Stream Sequence Number n: 16 bits (unsigned integer)
> Payload Protocol Identifier: 32 bits (unsigned integer)
>
> -----------------------------------------------------------------
>
> RFC 2960 is clear: the Payload Protocol Identifier _is_
> a 32-bit unsigned integer AND since it is an integer field,
> it MUST be sent in network byte order.
>
> So even though SCTP treats the value as opaque (i.e. it is not
> interpreted by SCTP), the SCTP _user_ may interpreted it and
> expects a 32-bit unsigned integer.
>
And you missed:
o payload protocol-id - A 32 bit unsigned integer that is to be
passed to the peer indicating the type of payload protocol data
being transmitted. This value is passed as opaque data by SCTP.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the statement that is illustrated by:
All integer fields in an SCTP packet MUST be transmitted in network
byte order, unless otherwise stated.
^^^^^^^^^^^^^^^^^^^^^^^
Yes, maybe that is not clear.. that is what the recent I-G is trying
to clear up... Its opaque.. it states so to tell you that SCTP
will NOT muck with whatever the app sends. If the app wants
to send it has a 4 byte integer then it needs to be doing
ntohl()/htonl(). If instead it wants to use it has a
4 byte character string.. its welcome to do that too... Its
up to the APP since it is "opaque".
And 2960 specifically added the 'opaque' wording to tell you
that it will NOT be necessarily in network byte order.
R
--
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222
Received on Wed Mar 2 10:43:03 2005