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

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/