Gx fallback function

The Gx fallback functionality refers to the behavior related to the subscriber host instantiation in situations where the PCRF is unresponsive while peering connections are up or the PCRF is unavailable with all peering connections down. This functionality affects only Gx session processing related to CCR-I messages on the node and has no effect on already established Gx sessions.

The fallback behavior can be controlled via the local configuration on the node or can be controlled via AVPs provided by PCRF.

PCRF-provided AVPs that control fallback behavior are:

CC-Session-Failover AVP with the following values:
- FAILOVER_NOT_SUPPORTED
- FAILOVER_SUPPORTED
Credit-Control-Failure-Handling AVP with the following values:
- TERMINATE
- CONTINUE
- RETRY_AND_TERMINATE

If the fallback-related AVPs are not provided via PCRF, the node can provide a local configuration option to define the fallback behavior. If the response from the PCRF cannot be obtained, the local configuration can allow the subscriber host to be instantiated with default parameters, or alternatively the local configuration can deny subscriber host instantiation.

PCRF provided AVPs overrule the local configuration.

The local configuration that defines Gx fallback behavior can be found under the following CLI hierarchy:

config
    subscr-mgmt
      diam-appl-plcy
        on-failure 
          failover {enabled|disabled} 
            handling {continue|retry-and-terminate|terminate}

The failover configuration option (equivalent to CC-Session-Failover AVP) controls whether the secondary peer is used in if the primary peer is unresponsive. The unresponsiveness is determined by the timeout of the previously sent message.

The handling configuration option (equivalent to Credit-Control-Failure-Handling AVP) controls whether the subscriber is terminated or instantiated with default parameters if the PCRF is unresponsive.

Table: Handling options
	Handling: CONTINUE	Handling: RETRY-AND-TERMINATE	Handling: TERMINATE
Failover: ENABLED
After the message sent to the primary peer times out, the secondary peer (and consecutive peers after that) is attempted. After the message times out after it has been sent to all available peers, the HANDLING action is examined to determine whether to terminate the host instantiation attempt or whether to use default parameters to instantiate the host.	After the message times out after it has been sent to all available peers, the subscriber host is instantiated with default parameters (if they are configured)	After the message times out after it has been sent to all available peers, the subscriber host instantiation is terminated.	After the message sent to the primary peer times out, the subscriber host instantiation is terminated.
Failover: DISABLED
After the message sent to the primary peer times out, the HANDLING action is examined to determine whether to terminate the host instantiation attempt or whether to use default parameters to instantiate the host.	After the message sent to the primary server times out, the subscriber host is instantiated with default parameters (if they are configured)	After the message sent to the primary peer times out, the subscriber host is terminated.	After the message sent to the primary peer times out, the subscriber host is terminated.

The CCR retransmissions are controlled by the tx-timer command under diameter-application-policy.

If all peers are down (no connections are open), the handling action determines the behavior. If the action is set to continue, the subscriber host is immediately instantiated with the default-settings (provided that the defaults are available). In all other action cases, the host instantiation is immediately terminated.