[BXXPwg] Channel Number Range
Phillip T. Conrad
Wed, 06 Jun 2001 17:36:54 -0400
I'm working on a new version of the BEEP over SCTP Mapping draft. A previous draft version authored by Marshall Rose indicates that:
>the mapping between BEEP channel numbers and SCTP stream
>identifiers is the identity function
While this is an ideal solution because of its simplicity, I am concerned that this may create some problems.
Consider the following:
* RFC3080 (BEEP) specifies that the valid range for a channel number is: 1..2147483647
* RFC3080 (BEEP) specifies that an endpoint "should" support at least 257 concurrent channels.
* RFC2960 (SCTP) specifies that the stream identifier is an unsigned 16 bit integer (i.e. range 0..65535).
Discussion: It is implied that an endpoint "may" support as few as 257 concurrent channels. (Presumably, reasonable implementations might support fewer, say 512, 1024, or 8192. However, it is not specified that these channels have to be numbered in the range 1-514 (odd on one side, even on the other), or that the range of possible sequence numbers be limited in any way. Presumably the channel numbers could be arbitrarily chosen (respecting the odd/even rule) from the full range of 1..2147483647, provided the total *number* of concurrent open channels doesn't exceed the implementation limit.
(1) Is it reasonable for a BEEP implementation to reject a channel open request because the channel number request is out of some implementation dependent supported range? If so, what error message would the BEEP implementation issue?
My initial thought would be that this should NOT happen... that a BEEP implemenation "MUST" support the entire channel number range, though a limit may be placed on the "number" of open channels.
(2) If the answer to (1) is "yes", is it reasonable to have the channel number range be limited differently for different transport mappings? (e.g. the full range 1..2147483647 for BEEP over TCP, but only 1..65535 for BEEP over SCTP?)
(3) While it would increase complexity of implementation somewhat, is there any other reason that a dynamic mapping (handled by the mapping layer) between BEEP channel and SCTP stream number would create problems?
(4) In practice, a number of the initial SCTP implementation don't provide the entire 0..65536 channel range... is this true of the initial BEEP implementations also?
(5) Can anyone developing profiles for BEEP Application Layer Protocols comment on how they see channel numbers being used in their protocols? More specifically, are there real situations where one might forsee a need to use channel numbers that exceed 65535?
Asst. Professor, CIS Dept., Temple University