Subject: [AAA-WG]: interaction of DCC failover procedures with AAATrans transport failure detection failover action

From: Joe Harvell <[email-masked]>
Date: Tue, 13 Jan 2004 18:42:23 -0600

Section 5.6 describes failover procedures for session based credit control.  According to these procedures, the DCC client may retransmit the CCR to a backup server:

	If a protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY
	is received or the request timeout and the CC-Session-Failover AVP
	is set to FAILOVER SUPPORTED, the credit control client MAY send the
	request to a backup server if possible.

However, according to section 5.5.3 of the Diameter Base Protocol requires the transport failure algorithm in AAATrans to be supported.  This algorithm describes retransmitting pending requests to a backup server upon transport failure detection.

Clearly the DCC client should not retransmit pending requests for sessions in which failover is not supported (CC-Session-Failover AVP indicates failover is not supported).  But for pending requests for sessions in which failover is supported, should the Diameter client retransmit the request upon transport failure detection in addition to request timeout?

Also, I would like clarification on interaction of transport failure initiated failover (AAATrans) and Diameter Credit Control's session based failover procedures for pending CCRs of CC-Request-Type First Interrogation.  My understanding is that CCRs of the first interrogation would include the Destination-Realm AVP but not the destination host AVP (as suggested by section 6.1 of Diameter Base Protocol).  Furthermore CCRs of type other than First Interrogation would contain both Destination-Realm and Destination-Host AVPs. This means that when transport failure is detected by the Credit Control Client, all pending CCRs of type First Interrogation would be immediately sent to an available backup server regardless of any CC-Session-Failover configuration.  The other pending CCRs would not be forwardable to a backup server according to section 5.5.5 of Diameter Base Protocol, since the Destination-Host AVP must have identified the failed host.  However, these pending requests wo
uld actually be retransmitted if session failover is supported according to the rules in Section 5.6 of Diameter Credit Control Application.  My reasoning is that the pending Diameter request is internally failed with DIAMETER_UNABLE_TO_DELIVER according to Diameter Base Protocol 5.5.4, which triggers the session failover described in section 5.6 of Diameter Credit Control Application.

Is this an accurate description of the Diameter Credit Control client behavior upon transport failure detection?  Is my reasoning correct?

---
Joe Harvell
Shasta GGSN Development
Nortel Networks
+1 972.685.4886