Re: SCTP API section 5.2.2

From: David Lehmann <lehmann@ulticom.com>
Date: Wed Mar 02 2005 - 15:45:25 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) Randall Stewart wrote:
> 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.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

No, I didn't miss that. I understood it to mean that it is opaque
to SCTP since SCTP does nothing with it. But it is not opaque
to the SCTP user.

> 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.
> ^^^^^^^^^^^^^^^^^^^^^^^

IMHO, it wasn't otherwise stated. If it was otherwise stated, I would
have expected something more explicit like: "This value is not transmitted
in network byte order." to counter act the explicit statement in
section 3.

> 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".

Yep, the RFC is not only unclear, but misleading. The RFC calls
it a 32 bit unsigned integer. How else do you expect someone
to interpret that?

Doesn't Ethereal interpret it as a 32-bit unsigned integer in
network-byte order? Can the Ethereal people comment?

> And 2960 specifically added the 'opaque' wording to tell you
> that it will NOT be necessarily in network byte order.

OK. (I seem to be losing sight of the purpose of this
field. It seems to me, it is just wasted bandwidth. If a user
protocol just needed four extra bytes, it should just put them in
its own headers.)

Regardless of all the misunderstanding above, it still comes
down to an API issue. Since the sinfo_ppid is presented as a 4-byte
unsigned integer (not four separate bytes), either the user of
the API or the socket library that is implementing the API has to do
the htonl() when sending and ntohl() when receiving... regardless
of whether it is two 2-byte values, one 4-byte value, or
four 1-byte values. In order to extract the proper values from
the given uint32_t somebody has to do the ntohl()/htonl().

The only other way around it is to cast the pointer to sinfo_ppid
to a (char *) and manually place each byte into the payload id.
Do we really expect users to do such a thing?
If so and if the protocol ID is truly opaque, shouldn't it be
four separate bytes? (I am not recommending this.)

I may be going out on a limb, but I think the vast majority of the
users will use it as an unsigned 32-bit integer and will be forced
to ntohl()/htonl() it themselves. This is not a problem, but
the API text should clearly state it.

-- 
David Lehmann
Ulticom, Inc.
http://www.ulticom.com

Received on Wed Mar 2 16:10:38 2005