Re: SCTP API section 5.2.2

From: David Lehmann <lehmann@ulticom.com>
Date: Wed Mar 02 2005 - 08:42:50 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) Randall Stewart wrote:
> David Lehmann wrote:
>
>> Kacheong Poon wrote:
>>
>>> David Lehmann wrote:
>>>
>>>> That was a lot of words just to state that it is in network byte
>>>> order. For a couple fields, the draft does explicitly says that
>>>> the values are in "network byte order."
>>>
>>>
>>>
>>> Actually, even though the sinfo_ppid is "supposed" to be
>>> a 32 bit integer, it is really opaque to the SCTP stack and
>>> socket layer. So the app may as well put 4 8 bit bytes
>>> there. Specifying any byte order in the text is probably
>>> not correct. This also applies to the sinfo_context.
>>
>>
>>
>> I think that I would have to disagree. This is a 32-bit value
>> which is sent over the network and read by the peer SCTP user.
>> The payload protocol has to be interpreted by the upper layer.
>> There is nothing in RFC 2960 that makes this field different
>> from any other field (e.g. the stream number, SSN, etc) in
>> this regard.
>
>
>
> The word opaque in the spec does make it different.
> Data is also opaque.. do you want the SCTP stack
> playing around with what it "thinks" are int's..
>
> You don't. And I do agree with Kacheong completely here.. an
> app can in theory put 4 8 bit values or 2 16 bit values or
> whatever it chooses to do with the field...
>
> You can't say what byte order they are in since the user
> can do a ntohl() on them or NOT .. and so it is opaque as
> the original text in 2960 said...

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.

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

Received on Wed Mar 2 09:08:55 2005