Chronological Thread 

< Chronological >      < Thread >

---

From a BRI/PRI perspective I know that one D-Channel will support
many bearer channels. I cannot remember if multiple D-Channels are
used for a group bearer channels - I think it is not done. From
this understanding I reason that two D-Channels might carry
overlapping information like CIC values. Muxing two D-Channels
together into a single association would therefore cause confusion.

On the other hand (there are fingers), it seems easy enough to
create one association for each D-Channel. The benefits of
segregating signaling channels in this manner seem substantial and
easily obtained.

A D-Channel is point-to-point - there is no to/from addresses in the
packet. If multiple D-Channels are muxed into a single association,
then it seems there is not enough information available to discern
between the two D-Channels. Managing the CIC ranges of D-Channels
might work but requires manual and ongoing coordination between
connecting parties not necessarily motivated to maintain this
coordination.

Using stream ids within a single association might work to segregate
signaling channels by assigning a stream id to each D-Channel. The
RFC2960 and the sctplib manual suggests to me that an association
negotiates the streams: the initializer "asks" for n outbound
streams. What if you need 5 and only get 1? I am not sure that if
you ask from n outbound that you get n inbound streams which further
complicates this approach. The RFC2960 indicates stream id is an
optional parm to sctp_send. What if your signaling "other end" is
designed to not use stream segregation? Too many unanswered
questions in this approach. Your point (2) is challenged to be
inter-vendor interoperable (IVIO) if my reasoning here is correct.
If there is no requirement for IVIO, then using stream ids might
work. IMHO (IVIO > ~IVIO).

I know very little about B-ISDN. Perhaps those specs have
requirements for multiple D-Channels for a group of bearer channels?
Regardless, using a separate association for each D-Channel still
works.

Mike

----- Original Message -----
From: "Sundaresan M"
<sundarem AT future.futsoft.com>
To:
<discussion AT sctp.de>
Sent: Thursday, December 13, 2001 6:49 AM
Subject: [SCTP-Discussion] SCTP streams and D-Channel in IUA


: Hi,
:
: Thanks for the reply.
:
: So now my understanding is this. Please correct me if I am wrong.
:
: 1) On SCTP association the two peer ends negociate and agree on
the SCTP
: streams that will be used by them.
: 2) Later on during Establishment of the D-channel from the ASP
using
: ESTABLISH_REQUEST message the ASP will specify 1 particular
interface
: identifier on a PARTICULAR Stream.
: 3) This is the stream that particular interface identifier will
use all
: through the existence of that D-channel.
:
: If this is okay now I have a small query. Can multiple D-Channels
be
: Requested(using Establish_Request) on the same sctp stream. I
think this
: should be possible.
:
: Best Regards,
: Sundar.
:
sundarem AT future.futsoft.com
:
:
: -----Original Message-----
: From:
discussion-admin AT sctp.de

[mailto:discussion-admin AT sctp.de]On
: Behalf Of
discussion-request AT sctp.de
: Sent: Thursday, 13 December 2001 4:32 PM
: To:
discussion AT sctp.de
: Subject: discussion digest, Vol 1 #197 - 1 msg
:
:
:
: Message: 1
: From:
hari AT cosystems.com
: To:
<discussion AT sctp.de>
: Date: Wed, 12 Dec 2001 17:42:06 +0530
: Subject: [SCTP-Discussion] RE: discussion digest, Vol 1 #196 - 1
msg
: Reply-To:
discussion AT sctp.de
:
: Hello Sundar,
: In case of IUA, Each interface Id related mesgs will travel on a
specific
: SCTP stream ID,
: u need to build a table which co-relates the InterfaceId ---->
SCTP Stream
: ID. Once the SCTP_COMM_UP
: mesg is recved from SCTP the IUA need to build this relationship
table
: according to the number of Streams
: SCTP supported by the "SCTP association" between the SG and MGC.
:
: Hari
:
:
:
:
: -----Original Message-----
: From:
discussion-admin AT sctp.de

[mailto:discussion-admin AT sctp.de]On
: Behalf Of
discussion-request AT sctp.de
: Sent: Wednesday, December 12, 2001 4:32 PM
: To:
discussion AT sctp.de
: Subject: discussion digest, Vol 1 #196 - 1 msg
: Today's Topics:
:
: 1. Relationship between SCTP streams and D-Channel in IUA
(Sundaresan M)
:
: -- __--__--
:
: Message: 1
: From: "Sundaresan M"
<sundarem AT future.futsoft.com>
: To:
<discussion AT sctp.de>
: Date: Wed, 12 Dec 2001 15:14:53 +0530
: boundary="----=_NextPart_000_0013_01C1831F.C0B692E0"
: Subject: [SCTP-Discussion] Relationship between SCTP streams and
D-Channel
: in IUA
: Reply-To:
discussion AT sctp.de
:
: This is a multi-part message in MIME format.
:
: ------=_NextPart_000_0013_01C1831F.C0B692E0
: Content-Type: text/plain;
: charset="iso-8859-1"
: Content-Transfer-Encoding: 7bit
:
: BlankHi,
:
: This is Sundar from Future Software. I am currently designing
Testsuites for
: IUA(RFC3057).
:
: In Section 4.1.1 of RFC 3057, there is a statement as below:
: 4.1.1 Q.921 or Q.931 primitives procedures
:
: On receiving these primitives from the local layer, the IUA layer
:
: will send the corresponding QPTM message (Data, Unit Data,
Establish,
:
: Release) to its peer. While doing so, the IUA layer needs to fill
:
: various fields of the common and specific headers correctly. In
:
: addition the message needs to be sent on the SCTP stream that
:
: corresponds to the D channel (Interface Identifier).
:
: Now my question is what is the relationship between the D-channel
and the
: SCTP streams.
:
: Best Regards,
: Sundar.
: I'm not here just to make a living, I'm here to make a difference
!
:
: ********************
: Sundaresan.M.G
: Senior Software Engineer
: SIGTRAN-TE, GNNettest
: Future Software
: Voice : 4330550 @ 328
: ********************
:
:
:
:
: _______________________________________________
: discussion mailing list
:
discussion AT sctp.de
: http://www.sctp.de/mailman/listinfo/discussion

---

• [SCTP-Discussion] SCTP streams and D-Channel in IUA, Sundaresan M, 12/13/2001
  • Re: [SCTP-Discussion] SCTP streams and D-Channel in IUA, Michael Mueller/bhu5nji, 12/13/2001

---

Archive powered by MHonArc 2.6.19+.