It would be OK if someone smart responded to this posting, but until
they show up, http://www.ietf.org/rfc/rfc2960.txt is showing
- a 16-bit source and destination port numbers in the common header
(3.1), AND
- a 16-bit stream identifier (3.3.1), AND
- a 32-bit Payload Protocol Identifier (3.3.1)
so there seems to be a large number of bits to identify a bunch of
different "connections" and/or "protocols" in SCTP.
Ned, could you be remembering the PPI?
To be honest, I believe all the SCTP network traces I've seen had
zeros in both the stream identifier and PPI, but the bits are there...
Spencer
> >Out of curiosity, doesn't SCTP have a bigger port space (or its
> >moral equivalent)? If so, would that be a better option?
>
> I have in fact on several occasions proposed using SCTP as a
> transport for
> various email services. I did so no so much to take advantage of
> the larger
> port numbers, but because the multistream support SCTP provides
> could be
> leveraged in several interesting ways. (In fact the multiplexing
> might
> even lessen the need for so many connections.)
Ehem, where is this larger port number? The port numbers I see in
section 3.1 of RFC 2960 seem to be 16 bit.
I haven't looked at this in several years, but my recollection is
that the port
number space was larger. Faultly memory, or maybe that was in some
draft and
dropped from the final version.
Ned
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf