: Diameter - Failover Implementation

"Monal Sengar" <[email protected]> Mon, 24 Jul 2006 15:31:07 +0530
Newsgroups gmane.ietf.aaa
Message-ID <[email protected]>
------=_Part_157495_32123958.1153735267101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi All,

In case of implementing Failover in Diameter base protocol, do we need to
send the requests in pending message queue on per peer basis or do we need
to distribute the requests based on the application Id.

In case, we implement the first option then we will have a mapping of
Primary peer to alternate peer.When primary peer is down , all the requests
in pending message queue will be routed to alternate peer.But in this case ,
alternate peer must support all the applicaiton Ids which primary peer is
supporting.

But in case of second option, we can retireve the pending message from the
pending message queue and based on the applicaiton Id , we can retireve the
proper alternate peer (from realm table and peer table) for this request
which will be supproting the application id present in the pending message
and route the request to the same.So for different pending requests we can
have different alternate peers.In such case there will not be any fixed
alternate peer but based on the application Id, we will find the proper
alternate peer from realm table and peer table.

Which option seems to be better?

Thanks in advance
Monal

------=_Part_157495_32123958.1153735267101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi All,<br><br>In case of implementing Failover in Diameter base protocol, do we need to send the requests in pending message queue on per peer basis or do we need to distribute the requests based on the application Id.<br>
<br>In case, we implement the first option then we will have a mapping of Primary peer to alternate peer.When primary peer is down , all the requests in pending message queue will be routed to alternate peer.But in this case , alternate peer must support all the applicaiton Ids which primary peer is supporting.
<br><br>But in case of second option, we can retireve the pending message from the pending message queue and based on the applicaiton Id , we can retireve the proper alternate peer (from realm table and peer table) for this request which will be supproting the application id present in the pending message and route the request to the 
same.So for different pending requests we can have different alternate peers.In such case there will not be any fixed alternate peer but based on the application Id, we will find the proper alternate peer from realm table and peer table.
<br><br>Which option seems to be better?<br><br>Thanks in advance<br>Monal<br>

------=_Part_157495_32123958.1153735267101--