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

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Wed, 14 Jan 2004 14:44:15 +0100

Hi Joe,

see answers inline.

BR,
Leena

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Joe Harvell
> Sent: 14. tammikuuta 2004 2:42
> To: [email-masked]
> Subject: [AAA-WG]: interaction of DCC failover procedures 
> with AAATrans
> transport failure detection failover action
> 
> 
> 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?
The "request timeout" in the referred text means actually transport
failure. We thought that the DCC application will see the transport
layer failure as a Twinit timer expiry. It's the timer Twinit in
AAATrans that is meant here, not the timer Tx in the DCC. Maybe it's
only the wording that should be clarified here. So, Yes, the Diameter
client should re-transmit the request to a backup server upon transport
failure detection.  
> 
> 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).  
Yes, this is correct. But I think it is also possible to address
a certain host directly already in the First Interrogation, given
that the Diameter client has the address of the server available,
e.g. preconfigured in the node or received from the AA(A) server.

> 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. 
Yes, in case of First Interrogation it does not really matter
whether the server or client supports failover since no session
state has been established yet in the server. It's the state
transfer between the primary and the secondary server that is
considered to be (on of) the tricky part(s) and why some servers
might not support failover.

> 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 
> would 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?
Yes, your understanding is correct.

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