R
Michael Tuexen wrote:
> Dear all,
>
> I'm not sure why we are so controversial here.
>
> I think it is clear that the text is not clear:
> - David had questions.
> - the Linux guys did it wrong in the first versions.
>
> What does IANA say (http://www.iana.org/assignments/sctp-parameters):
> SCTP Payload Protocol Identifiers REFERENCE
> --------------------------------- ---------
>
> 1 - IUA [RFC3057]
> 2 - M2UA [RFC3331]
> 3 - M3UA [RFC3332]
> 4 - SUA [RFC2960]
> 5 - M2PA [RFC2960]
> 6 - V5UA [RFC2960]
> 7 - H.248 [H.248]
> 8 - BICC/Q.2150.3 [Q.1902.1/Q.2150.3]
> 9 - TALI [RFC3094]
> 10 - DUA <draft-ietf-sigtran-dua-03.txt> [Ong]
> 11 - ASAP <draft-ietf-rserpool-asap-03.txt> [Ong]
> 12 - ENRP <draft-ietf-rserpool-enrp-03.txt> [Ong]
> 13 - H.323 [H.323]
> 14 - Q.IPC/Q.2150.3 [Q.2631.1/Q.2150.3]
>
>
> What is the intention of the PPID? RFC 2960 says:
>
> Payload Protocol Identifier: 32 bits (unsigned integer)
>
> This value represents an application (or upper layer) specified
> protocol identifier. This value is passed to SCTP by its upper
> layer and sent to its peer. This identifier is not used by SCTP
> but can be used by certain network entities as well as the peer
> application to identify the type of information being carried in
> this DATA chunk. This field must be sent even in fragmented DATA
> chunks (to make sure it is available for agents in the middle of
> the network).
>
> The value 0 indicates no application identifier is specified by
> the upper layer for this payload data.
>
> Ethereal is one of these network entities, which uses the it as an 32 bit
> unsigned integer to find the upper layer protocol and dissect the
> user data. It is possible (and we use this in RSerPool) to bundle
> to DATA chunks with different upper layer protocols.
>
> This means that all applications I know use the field as an integer.
>
> What does the socketapi ID say:
>
> struct sctp_sndrcvinfo {
> uint16_t sinfo_stream;
> uint16_t sinfo_ssn;
> uint16_t sinfo_flags;
> uint32_t sinfo_ppid;
> uint32_t sinfo_context;
> uint32_t sinfo_timetolive;
> uint32_t sinfo_tsn;
> uint32_t sinfo_cumtsn;
> sctp_assoc_t sinfo_assoc_id;
> };
>
> This is a 32 bit integer. Of course, you can put anything in it
> (four 8 bit chars, two 16 bit ints), but you pass it AS AN INTEGER.
> And the important thing is, that the SCTP implementation does NOT
> change it. At least, this is what Solaris, Linux and KAME do. Since
> I have no other stack in my lab, I do not know what other implementations
> do.
>
> So why not change
>
> sinfo_ppid: 32 bits (unsigned integer)
>
> This value in sendmsg() is an opaque unsigned value that is passed to
> the remote end in each user message. In recvmsg() this value is the
> same information that was passed by the upper layer in the peer
> application. Please note that byte order issues are NOT accounted
> for and this information is passed opaquely by the SCTP stack from
> one end to the other.
>
> to
>
> sinfo_ppid: 32 bits (unsigned integer)
>
> This value in sendmsg() is an unsigned integer that is passed to
> the remote end in each user message. In recvmsg() this value is the
> same information that was passed by the upper layer in the peer
> application. Please note that the SCTP stack performs no byte
> order modification of this field. For example, if the DATA chunk
> has to contain a given value in network byte order, the SCTP user
> has to perform the htonl() computation.
>
> Best regards
> Michael
>
>
> On Mar 2, 2005, at 21:45 Uhr, David Lehmann wrote:
>
>> 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
>
>
-- Randall Stewart ITD 803-345-0369 <or> 815-342-5222Received on Wed Mar 2 18:20:11 2005
This archive was generated by hypermail 2.1.8 : Mon Mar 13 2006 - 15:22:24 EST