Subject: [Tsvwg] Why Payload Protocol in every data chunk?

From: [email-masked]
Date: Thu, 11 Jul 2002 12:56:19 -0400

Can anyone explain why we have the payload protocol parameter in every 
data chunk?  The only reason I can come up with would be to allow an 
association to be shared by multiple upper layers, otherwise this value 
could be exchanged only once, during assoc initialization...
I realize its late to change such a thing, but I'm just curious.

Thanks,
Dave Sclarsky
Radisys Corporation
520 Fellowship Road
Suite C-304
Mt. Laurel, NJ 08054
email:[email-masked]

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 11 Jul 2002 19:58:38 +0200

Dave,

you got the reason. So you can transport multiple upper layers
within on association. The PPI is transported between the SCTP
endpoints and given to the upper layer.

It can also be used for packet inspection in nodes between the
end points. You do not have to rely on the port numbers. Something
ethereal, for example, does and can dissect the SIGTRAN protocols even
if the well known ports are not used.

Best regards
Michael

> email:[email-masked]
[email-masked]

---

From: Phillip Conrad <[email-masked]>
Date: Thu, 11 Jul 2002 14:56:54 -0400

>I realize its late to change such a thing, but I'm just curious.

I'm assuming you mean the Payload Protocol ID (PPID) in the SCTP header 
(note that the scope of the tsvwg list is much broader than just SCTP, so 
it's helpful to mention which protocol you are discussing :-) ).

Two benefits of having the PPID per chunk:

(1) Multiplexing different kinds of data over the same SCTP association.

For example, in the RSerPool working group, one possibly design for ASAP 
would use an IANA-registered PPID to differentiate application messages 
from RSerPool control messages.   (This particular design might or might 
not still be on the table; I've been out of that loop for a couple of weeks.)

(2) Facilitating the construction of packet decoders (e.g. tcpdump, 
ethereal).  In current packet sniffers, well-known port numbers are 
sometimes used to infer which upper layer protocol is being used; the PPID 
is an alternative design.

I've had mixed feelings about whether this is a good use of bits or 
not.  An argument against the field is that since the protocol entities 
never touch it (they only pass it through to the other side) it is really 
just a glorified piece of payload.... so why not just make it contiguous 
with the rest of the payload bits?

However, I've become convinced that it will be helpful in the long run to 
have a standard way to identify what kind of data is being sent on a 
per-chunk basis, separate from conventions related to port numbers and/or 
stream numbers.   Since it made it into RFC2960, I'm inferring that this 
was the rough consensus of the working group as well.

Phill

-- Phill Conrad, Asst. Professor, Temple University
-- http://netlab.cis.temple.edu    [email-masked]