Subject: [BXXPwg] Channel Number Range

From: "Phillip T. Conrad" <[email-masked]>
Date: Wed, 06 Jun 2001 17:36:54 -0400

BEEP WG'ers:

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.

Question:

(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? 

Thanks,
Phill Conrad
Asst. Professor, CIS Dept., Temple University
http://www.cis.temple.edu/~conrad, http://netlab.cis.temple.edu 

_______________________________________________
BXXPwg mailing list
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 6 Jun 2001 18:09:34 -0700

> (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?

yes, it's reasonable.

as far as the error message, that's an api issue, which is out of scope for
the protocol spec.

> (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?)

yes.

> (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?

complexity is a problem.

> (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?

it depends on the implementation. i suspect that someone writing beep for
the pocketpc, may decide to use some simple datastructures that require some
limitations...

> (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?

with freedom comes responsibility.

/mtr