Subject: [AAA-WG]: Failover mechanism in DCCA

From: Sumanth <[email-masked]>
Date: Sat, 02 Oct 2004 15:23:30 +0530

Hi all,

Apologies if this has been discussed already.

 From Section 5.7 Failure Procedures, seems to imply that DCCA client is 
managing failover to secondary servers and sometimes interpreting the 
protocol errors like DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY. 
These, I understand are more of BASE protocol functionalities and should 
be transparent to DCCA client. (Assuming DCCA would be layered on BASE)

In scenarios where DCCA client talking to Agents, and an Agent could be 
serving the requests for a particular realm 3 hops away, do we need to 
start all over again to try the alternate secondary server which could 
have been reached from the same Agent ? Further, how would the DCCA 
client know which is the alternate server that needs to be tried ?

As far as I see, DCCA should include Dest-Host AVP for the subsequent 
requests after initial CCA received *IF* failover_is_not_supported else 
it shouldn't include this AVP so that the BASE/Agents can do a failover 
to other servers in a given realm.

But, with the above approach it is not guaranteed that we always try the 
server which replied with initial CCA before failing over to the other 
alternate servers.

Regards,
~sumanth

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 2 Oct 2004 22:18:54 -0700 (PDT)

> be transparent to DCCA client. (Assuming DCCA would be layered on BASE)

The BASE failover facilities described in RFC 3539 operate only on
the first hop, and assume that state is not being kept, and therefore that
one AAA server is as good as another.

This is not necessarily true for the DCCA application, which builds state
on the Diameter client and server that may or may not be replicated to an
alternative server.  The result is that pure BASE failover functionality
can result in failover to a DCCA server without the required state.  This
is why DCCA needs to be able to control the failover behavior via the
CC-Session-Failover AVP.  My understanding is that if this AVP is not set
to FAILOVER_SUPPORTED then Diameter Base failover is turned off.

> client know which is the alternate server that needs to be tried ?

Diameter clients utilize the Watchdog functionality defined in RFC 3539 to
diagnose failures in the first hop.  Unless a Diameter client receives an
error message, it may be quite difficult for it to diagnose the cause of
a failure beyond the first hop.  In general, receipt of error messages is
not guaranteed for all potential failure scenarios.

> to other servers in a given realm.

In general, RFC 3539 tries to avoid failover while segments are still in
flight since this violates the law of "conservation of packets".  That
is why Diameter DCCA can terminate service early (prior to expiration of
the minimum Tw timer) but does not initiate a new request unless a
protocol error has been received, indicating that segments are no longer
in flight.  This enables DCCA to maintain conservative behavior.

> server which replied with initial CCA before failing over to the other

I'm also not sure how this approach can avoid multiple failovers and
violation of "conservation of packets".