Re: Which ASP shall answer in Traffic Mode = Multicast?

Hi,

I have query for Broadcast mode in SUA.

For M3UA, Broadcast mode : the role of SG would be to Broadcast messages to
all ASPs.
                                            the role at ASPs would be to
accept the message.
                                                      Now thru inter-ASP
communication, one of the ASPs may process it and rest would drop it,
                                                      or all ASPs
may process it.

However, will Broadcast mode also be applicable for SUA Class 2 Messages?
Potential issues:

   - This would mean that for a single SCCP Connect request from User,
   SUA would have to maintain multiple connections, one with each Peer ASP.
   - What happens if 1 out of multiple Peer ASPs does not send a COAK,
   (we will not be able to send further messages to this ASP for this
   connection)
   - What happens if a new ASP becomes active, (and some Class 2
   connections had already been established with earlier ASPs), we will not be
   able to send data for earlier connections towards this new ASP.

 RFC 3868, only explains Broadcast Mode in general (in section 4.3.4.3.  ASP
Active Procedures)
*"The algorithm at the SGP for  broadcasting traffic within an AS to all the
active ASPs is a simple broadcast algorithm, where every message is sent to
each of the  active ASPs."*

If we allow Broadcast Mode for Class 2 Messages then there would be a
slight conflict with the above section.

rgds
Saurabh


On 9/7/06, Brian F. G. Bidulock <[email protected]> wrote:
>
> Sedlak,
>
> I presume that you are speaking of broadcast traffic mode under, say,
> M3UA, rather that IP "broadcast" or "multicast".  Broadcast is a
> mechanism that permits all other traffic modes independent of the SG.
> The ASPs serving an AS decide between themselves which one will handle
> a given message.  In a typical arrangement, each ASP serving the AS
> would be responsible for active processing of 1 range of SLS (M3UA)
> and responsible for checkpointing on the remaining ranges of SLS.  ASPs
> heartbeat and checkpoint between each other or rely upon ASP Failure
> indications from the SGP to detect a failed ASP.  When an ASP fails,
> the active ASP in the AS responsible for acting as backup to the failed
> ASP takes starts actively processing messages rather than just check
> pointing for the range of SLS for the failed ASP.
>
> Of course, other arrangments are possible.  Active-Standby and Loadshare
> can also be preformed by ASPs in broadcast mode.
>
> The reason that you do not see much mention of this in the RFCs is because
> the RFCs do not dictate how ASPs in a broadcast AS behave because ASP-ASP
> communication and coordination is out of scope.  From the ASP-SG protocol
> perspective, the SG simply sends the message to each ASP serving the AS
> and
> does not dictate who processes it.
>
> Hope that helps.
>
> --brian
>
> Sedlak Michael wrote:                      (Thu, 07 Sep 2006 16:02:43)
> >
> >    Hello,
> >
> >    After  studying  the rfc, I could not find an answer on how to
> proceed
> >    after a multicast-message was sent to several ASP.
> >
> >    consider  a  case where 3 ASP are active in an AS, traffic mode type
> =
> >    multicast.
> >    When  an  SGP  sends a message to all 3 ASP, how do the ASP know
> which
> >    one  shall  transport  the message to the upper layer? And further
> on,
> >    which upper layer shall answer the message?
> >
> >    What could be a real-life scenario where multicast is needed?
> >
> >    thanks,
> >    Michael Sedlak
> >
> >    Solution Architect | All-IP Data Core
> >    KapschCarrierCom
> >
> >    The information contained in this e-mail message is privileged and
> >    confidential and is for the exclusive use of the addressee. The
> person
> >    who receives this message and who is not the addressee, one of his
> >    employees or an agent entitled to hand it over to the addressee, is
> >    informed  that  he  may  not  use,  disclose or reproduce the
> contents
> >    thereof.
>
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran