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: Tue, 4 May 2004 08:51:19 +0200

Hi Joe,

sorry for the late response. I've been away from my mail for a while and try now to catch up with the backlog.

Your logic in the pseudocode looks ok. 
In brief, the timer Tx is valid only in case the CCFH has been set to TERMINATE in order to give the service provider the possiblity to _quickly_ tear down the service if we suspect that there are problems with the DCC session and the server might not be able to debit the user's account for the services used (as you have correctly included in your pseudocode).
For other CCFH values we rely on the timers and mechanisms on the transport layer (and of course the error codes in the answer messages), and first try to move the session to an alternative server, if possible, and after that take appropriate action based on the CCFH value, if even the communication with the alternative server fails.

I also had a look at Marco's answer (thanks, Marco), and don't have anything to add there. I couldn't have answered better.

BR,
Leena

-----Original Message-----
From: Joe Harvell [mailto:[email-masked]]
Sent: 24. huhtikuuta 2004 19:49
To: Leena Mattila (TU/LMF)
Cc: [email-masked]
Subject: Re: [AAA-WG]: interaction of DCC failover procedures with
AAATrans transport failure detection failover action

Leena:

Thanks for your response.  I need some more clarification on Section 5.7 
in draft 4.  I have included my questions inline below.  Could you 
please provide answers?

Also, I have tried to piece together some pseudocode describing how this 
works based on my current understanding.  Could you please look over 
this and verify my understanding is correct?

First, here is an excerpt from Section 5.7 along with my inline questions.

> If the Credit-Control-Failure-Handling AVP is set to the value
> CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the
> end user upon the timer Tx expires. An answer message with granted-
> units may arrive later on due to the base protocol transport failover
> occurred in the path to the Credit Control Server (Twinit default
> value is 3 times more than the Tx recommended value). The credit
> control client SHOULD grant the service to the end user, start
> monitoring the resource usage and wait for the possible late answer
> until the timeout of the request (e.g. 120 seconds).
[JH]: So what timer detects the "timeout of the request"?  Is this an 
implementation defined timer not mentioned elsewhere in the spec along 
with a recommended value?  Is the "timeout of the request" you mention 
here a transport failure detection of the transport connection on which 
the request is pending?  I am assuming that this is not Tx since Tx 
already expired.  If this is the case, why don't the state machines in 
section 7 reference any event associated with this timer expiring. 
Please explain.
> If the request
> fails and the CC-Session-Failover AVP is set to FAILOVER_NOT
> SUPPORTED, the credit control client terminates or continues the
> service depending on the value set in the CCFH and MUST free all the
> reserved resources for the credit control session.
[JH]: The action to be taken matches with the behavior for "Failed CC 
initial answer received" event in the state machine in Section 7.  In 
this context, "Failed answer" refers to an answer received with 
Permanent Error type result code.  Is that what you mean here by "the 
request fails"?  Or are you actually describing what action is taken 
when "the possible late answer" described above does not arrive before 
"the timeout of the request" as mentioned above?
  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.
[JH]: You already indicated in your previous email that "the request 
timeout" described directly above refers to a transport failure 
detection for the connection on which the request is pending.
  If the credit control client receives a successful
> answer from the backup server, it continues the credit control session
> with such a server. If also the re-transmitted request fails, the
> credit control client terminates or continues the service depending on
> the value set in the CCFH and MUST free all the reserved resources for
> the credit control session.
[JH]:  I assume the meaning of "also the re-transmitted request fails" 
is the same as the meaning of "If the request fails" that I asked about 
above?  If not, please explain this, too.

Now, here is my pseudocode describing failure procedures as I understand 
them now:

Here are the events that can happen to a pending request:

     * Failure to Send to Selected Peer---The selected peer is
	unavailable as determined by Diameter Base Transport Failure
	Mechanism
     * Failure to Send---Neither selected peer nor alternate peer is
	available.
     * Temporary Error---Client receives one of the following Protocol 
Error notifications
           o DIAMETER_TOO_BUSY
           o DIAMETER_UNABLE_TO_DELIVER
                 + Note: Above notification is generated locally when a 
peer fails for each request pending with destination host equal to that peer
           o DIAMETER_LOOP_DETECTED
     * Permanent Failure
           o DIAMETER_RATING_FAILED
           o DIAMETER_AVP_UNSUPPORTED
           o DIAMETER_UNKNOWN_SESSION_ID
           o DIAMETER_AUTHORIZATION_REJECTED
           o DIAMETER_INVALID_AVP_VALUE
           o DIAMETER_MISSING_AVP
           o DIAMETER_RESOURCES_EXHAUSTED
                 + Note: Above error is not expected to be used by a DCC 
application.
           o DIAMETER_CONTRADICTING_AVPS
           o DIAMETER_AVP_NOT_ALLOWED
           o DIAMETER_AVP_OCCURS_TOO_MANY_TIMES
           o DIAMETER_NO_COMMON_APPLICATION
           o DIAMETER_UNSUPPORTED_VERSION
           o DIAMETER_UNABLE_TO_COMPLY
           o DIAMETER_INVALID_BIT_IN_HEADER
           o DIAMETER_INVALID_AVP_LENGTH
           o DIAMETER_INVALID_MESSAGE_LENGTH
           o DIAMETER_INVALID_AVP_BIT_COMBO
           o DIAMETER_NO_COMMON_SECURITY
     * Tx expiry
     * Transport Failure Detected

Failure to Send to Selected Peer or Temporary Error:
if(!retransmitted &&
     (CCR(I) || CC-Session-Failover==SUPPORTED) &&
     alternate peer available)
{
     send to alternate peer
}
else
{
     raise Failure to Send  (see below)
}

Failure to Send or Permanent Failure:
if(CCFH==CONTINUE)
{
    Grant Prepaid request and never talk to the Prepaid Server again. 
(This implies no prepaid resource limits from now on).
}
else
{
     Terminate GTP context.
}

Tx Expiry:
if(CCFH==TERMINATE)
{
     Terminate GTP context
}
else
{
     Grant prepaid request
}

Transport Failure Detected (logic executed for each pending request):
if(dstHost in message == failed host)
{
     raise Temporary Error (DIAMETER_UNABLE_TO_DELIVER) (follow logic 
described above for Temporary Error)
}
else
{
     if(CCR(I) || CC-Session-Failover==SUPPORTED)
     {
           if(!retransmitted AND alternate peer available)
           {
              send to alternate peer
           }
           else
           {
              raise Failure To Send
           }
     }
     else
     {
           raise Failure To Send
      }
}

Leena Mattila (TU/LMF) wrote:

> 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
>>