Re: Multiple SCTP associations

Brian,

Yes, I agree.
Thank you for pointing me to 1.3.2.4, now it seems clear.


Sergey Mikhailov.



----- Original Message ----- 
From: "Brian F. G. Bidulock" <[email protected]>
To: "Sergey Mikhailov" <[email protected]>
Cc: <[email protected]>; <[email protected]>; "SIGTRAN" 
<[email protected]>
Sent: Wednesday, January 11, 2006 2:10 PM
Subject: Re: [Sigtran] Multiple SCTP associations


> Sergey,
>
> I am not agreeing with Tolga much lately...
>
> It was never our intention to allow more than one SCTP association
> between a given pair of processes to persist.
>
> E.g. RFC 3332 1.3.2.4:
>
> ... In order to [sic] avoid redundant SCTP associations between two
> M3UA peers, one side (client) SHOULD be designated to establish the
> SCTP association, or M3UA configuration information established to
> detect redundant associations (e.g., via knowledge of the expected
> local and remote SCTP endpoint addresses).
>
> This passage makes it clear that measures are to be taken to avoid
> multiple associations.
>
> Also, an ASP Identifier is required whenever multiple ASPs exist at
> the same endpoint.  If the provided ASP Identifier is missing,
> ERR("ASP Identifier Required") is returned to ASP Up.  If the ASP
> Identifier is not unique, ERR("Invalid ASP Identifier") is returned
> to ASP Up.  Therefore, multiple associations to the same ASP will not
> allow ASP Up to proceed on all but one of them.
>
> This is the same for both M3UA (RFC 3332 Section 3.8.1) and SUA
> (RFC 3868 Section 3.9.12).
>
> --brian
>
> On Wed, 11 Jan 2006, Sergey Mikhailov wrote:
>
>> 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.
>>
>> 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).
>>
>>
>> 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
>
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email protected]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                        ¦ Therefore  all  progress  depends on the ¦
>                        ¦ unreasonable man. -- George Bernard Shaw ¦
>