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
Received on Wed Mar 2 17:51:22 2005
This archive was generated by hypermail 2.1.8 : Mon Mar 13 2006 - 15:22:24 EST