RE: Multiple SCTP associations

one correction below...

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Tolga Asveren
> Sent: Wednesday, January 11, 2006 7:49 AM
> To: [email protected]
> Subject: RE: [Sigtran] Multiple SCTP associations
>
>
> Sergey,
>
> > -----Original Message-----
> > From: Sergey Mikhailov [mailto:[email protected]]
> > Sent: Wednesday, January 11, 2006 4:19 AM
> > To: [email protected]; [email protected]
> > Cc: SIGTRAN
> > Subject: Re: [Sigtran] Multiple SCTP associations
> >
> >
> > Tolga, Ilie,
> > thank you for your valuable replies on the subject!
> >
> > Please let me know, if I misinterpreted your answers.
> >
> > 1.
> > As far as I understand it, an SCTP endpoint, to say it
> strictly, may have
> > only one SCTP association; and a signaling process may use multiple SCTP
> > endpoints (and hence multiple SCTP associations) for communication with
> > different signaling processes of one AS/SG.
> [TOLGA]Yes.
[TOLGA]Actually no. Each signaling process is an SCTP endpoint. You have
different SCTP associations from this endpoint to different SCTP endpoints.

SCTP endpoint ==> local IP addresses, port
SCTP association ==> A relationship between two SCTP endpoints
> >
> > 2.
> > Multiple SCTP associations between the same two signaling
> > processes, while
> > not prohibited, will require reinterpretation of SCTP-to-ULP
> > events (to keep
> > communication status and ASP states consistent across multiple SCTP
> > associations), such as NETWORK STATUS CHANGE, COMMUNICATION
> > UP/LOST/ERROR,
> > RESTART and SHUTDOWN COMPLETE events (RFC2960).
> [TOLGA]The protocol never intends to use multiple associations between two
> signaling entities. If you follow that path -for some reason-, both sides
> will need to agree on the chneges necessary to support that scenario, i.e.
> it won't be a solution compliant with the protocol.
> >
> >
> > Regards,
> > Sergey Mikhailov.
> >
> >
> >
> > ----- Original Message -----
> > From: "Tolga Asveren" <[email protected]>
> > To: <[email protected]>
> > Sent: Tuesday, January 10, 2006 7:33 PM
> > Subject: RE: [Sigtran] Multiple SCTP associations
> >
> >
> > > Sergey,
> > >
> > > -----Original Message-----
> > > From: [email protected]
> [mailto:[email protected]]On Behalf
> > Of
> > Sergey Mikhailov
> > Sent: Tuesday, January 10, 2006 11:39 AM
> > To: SIGTRAN
> > Subject: [Sigtran] Multiple SCTP associations
> >
> >
> > Hi,
> >
> > It seems that multiple SCTP associations established between
> the same two
> > signaling processes are not [explicitly] prohibited.
> >
> > 1.
> > Is it legal for a signaling process to establish more than one SCTP
> > association to the same AS/SG where these multiple associations
> are served
> > by different signaling processes?
> > [TOLGA]Yes, this is how host redundancy is achieved (I assume you talk
> > about
> > M3UA/SUA). There are multiple ASPs serving an AS, and multiple SGPs in a
> > SG,
> > and there is a SCTP association between each SGP/ASP pair
> -well, obviously
> > it is not mandatory-.
> >
> > 2.
> > Is it legal for a signaling process to establish more than one SCTP
> > association to the same signaling process at the remote side?
> >
> > (I feel that the 2nd case may be reasonable only when the
> remote side does
> > not support multi-homed SCTP endpoints.)
> > [TOLGA]Multiple SCTP assocaitions between two etities will have problems
> > with ASP state machine if you follow it strictly considering the state
> > transitions associated with events from SCTP. This is easy to overcome
> > with
> > a some reasonable reinterpretation. OTOH, multiple SCTP
> associations won't
> > be a replacement for SCTP multihoming support because SCTP multihoming
> > provided network/NIC redundancy without loss/missequencing of messages.
> >
> > Regards,
> > Sergey Mikhailov.
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>