1. Accounting Guide
  2. Diameter Accounting
  3. Using FQDNs to Access CCFs over Diameter
  4. Handling Multiple CCFs

Handling Multiple CCFs

When a DNS response includes multiple CCFs as potential targets, the SBC uses a selection procedure based on your configuration, the DNS response, and current traffic conditions.

When configuring for FQDN-resolved CCF access order, you begin with determining whether you want to establish a primary and a secondary pool of servers and, if so, which FQDN is primary. This configuration establishes the first criteria for determining access order. The process of checking all potential resolutions begins with checking the resolutions from the primary account-server. If the system does not reach a CCF after that, it performs the same process using the secondary account-server.

When selecting from a pool, the SBC first refers to DNS server priority to determine the access order. The lower the priority number, the earlier the CCF appears in the list. Having established an order based on priority, the SBC then refines that order using IP address. Specifically, the SBC sorts servers that have the same priority based on the returned IP addressing. In this case, the system selects the lowest IP address in the resolution and attempts to reach that one first. If there is no response, the system tries the next lowest IP address until it has attempted every resolution.

Having identified server priority from DNS, the SBC proceeds with forwarding call-generated ACR signaling sequences with the group of highest priority servers only. The SBC uses weight to establish a round-robin method of selecting CCFs for call-generated ACR sequences from the highest priority list until it has attempted to reach all CCFs in that list. If there are no highest priority CCFs available, the SBC starts using CCFs from the next highest priority list.

The system only moves to the next priority group when all CCFs in the first priority group are down or have reached their acr buffer thresholds.

The SBC also uses weight to determine how many calls it can send to a given CCF within a single call session cycle. A call session cycle is defined as reaching the number of calls equal to the sum of all CCF weights. The system uses weight to determine the number of calls it can send to a CCF during that call cycle. The system selects each CCF of the same priority in round robin, and removes each CCF from the cycle when they reach their weight. The cycle ends when each CCF has handled its maximum. Regardless of how many calls may still be active, the system restarts the cycle once it has sent the lowest weight CCF its maximum number of calls.

If, at any point in the call session cycle, the system finds all CCFs busy, based on buffer usage, it begins to use the next highest priority group. This is also true for the secondary pool. When triggered by buffer usage by the entire primary pool, the system begins to use the highest priority group in the secondary pool. In addition, the system moves on to the secondary pool if it finds all CCFs in the primary unavailable.

Buffer Overflow Scenario

If the SBC determines that configured buffer limits are exhausted, it starts routing traffic to lower priority or secondary pool CCFs to avoid buffer overflow.

Three configurations under account-config specify this behavior:

  • acr-buffer-upper-threshold— Indicates the percentage of buffer usage beyond which the SBC routes new call sessions to alternate CCFs.
  • next-priority-selection-interval— When buffer usage has exceeded the upper threshold, the system starts this timer. When the timer expires, the system checks buffer usage again. If buffer usage still exceeds the threshold, the system changes its selection criteria to include the next lower priority CCFs or, if they are all in use, CCFs from the secondary-pool.
  • acr-buffer-lower-threshold— Indicates the percentage of buffer usage that triggers the SBC to start using that CCF again.

When buffer usage exceeds your acr-buffer-upper-threshold value, the SBC:

  1. Sends an SNMP trap and raises an alarm with information about the current usage of the ACRq along with the configured lower and upper threshold.

    The applicable alarm, named DIAM ACCT BUFFER THRESHOLD EXCEED, appears as follows with the ID a.

    1 alarms to show
ID         Task    Severity       First Occurred          Last Occurred
327738     3029       6        2021-11-16 10:31:18     2021-11-16 10:31:18
Count   Description
1       Buffer Usage (90%) hit Upper Threshold Limit for Diameter Accounting buffer!!!

    The applicable traps, within ap-diameter.mib, include apAcctMsgQueueUpperThresholdTrap (1.3.6.1.4.1.9148.3.13.1.2.2.0.7 ) and apAcctMsgQueueUpperThresholdClearTrap (1.3.6.1.4.1.9148.3.13.1.2.2.0.7 ).

  2. Starts routing calls to the CCFs from the next lower priority and continues routing existing sessions to the CCFs already assigned to them.
  3. If the next lower priority CCFs are busy, the SBC selects CCFs with the priority below that for new calls.
  4. If all priority CCFs are busy, the SBC selects CCFs from the secondary pool for all new sessions.
  5. Continues using lower priority, and any secondary pool CCFs until buffer usage becomes equal or less than your acr-buffer-lower-threshold value.
  6. Re-starts the next-priority-selection-interval timer each time buffer usage does not recover.

    On the second cycle through the next-priority-selection-interval, the SBC checks whether any of the highest priority CCFs are no longer servicing any sessions. If so, the system considers that (or those) CCFs available for service again, and places them at the top of the new session target list.

    When buffer usage recovers, the system completes all sessions on existing CCFs and restarts assigning new sessions to the highest priority CCFs available in the primary pool.

Note:

On expiry of usageCheck timer, SBC restarts the timer and then. instead of directly going for further lower priority, the system checks if any of the higher priority CCFs are available.

Furthermore, the SBC checks if outstanding ACRs of all the CCFs of any priority is zero and CCFs are eligible then SBC shall consider it as ready to serve.

The table below presents an example of a CCF distribution list.

DnsResult(Primary) DnsResult(Secondary)
CCF Number hostname port Priority Weightage CCF Number hostname port Priority Weightage
CCF1 10.196.0.13 3868 1 2 CCF11 10.196.0.43 3868 1 2
CCF2 10.196.0.14 3868 1 3 CCF12 10.196.0.44 3868 1 3
CCF3 10.196.0.15 3868 1 6 CCF13 10.196.0.45 3868 1 6
CCF4 10.196.0.16 3868 1 9 CCF14 10.196.0.46 3868 1 9
CCF5 10.196.0.21 3868 2 30 CCF15 10.196.0.51 3868 2 30
CCF6 10.196.0.22 3868 2 60 CCF16 10.196.0.52 3868 2 60
CCF7 10.196.0.31 3868 3 6 CCF17 10.196.0.61 3868 3 6
CCF8 10.196.0.32 3868 3 9 CCF18 10.196.0.62 3868 3 9
CCF9 10.196.0.33 3868 3 12 CCF19 10.196.0.63 3868 3 12

Having received resolution, the SBC routes the traffic in the CCFs primary pool with priority 1, which includes CCF1 to CCF4. If the SBC finds buffer usage has reached the upper threshold value, it starts selecting CCF5 and CCF6 for new sessions, while routing the existing sessions to CCF1 through CCF4.

Having cycled through CCF1 to CCF6, and after the usageCheck timer has expired, the SBC checks whether buffer usage has recovered:

  • If CCF1 to CCF4 have no outstanding request, the system routes ensuing sessions to CCF1 to CCF4.
  • If CCF1 to CCF4 still have outstanding requests, the system starts routing the traffic to CC7 to CC9.

If CCF1 to CCF9 are in use, and the timer has expired, the SBC attempts to use CCF1 to CCF4 again. If they are still busy, the system tries CCF5 and CCF6. If they are also busy, the SBC starts selecting from the secondary pool, specifically CCF11 to CCF14.

The SBC continues to monitor buffer usage, returning to the highest priority CCFs in the primary pool when it detects that usage has recovered. At this point, the SBC stops the usageCheck timer. sends an SNMP clear trap and clears the alarm.

Target List Updation

The SBC updates its CCF target list on a per-FQDN basis while minimizing DPRs and maintaining affinity when there is a:

  • DNS cache refresh
  • ACLI configuration changes

DNS refresh changes include:

  • IP Address Added—The system assigns the new address to a specific pool, connects with CCF, and routes new call sessions to newly added IP also based on its priority and weight.
  • IP Address Removed—The system stops sending new ACRs to the address and waits for ACAs to return until its acr-retry-interval expires. When it receives all the ACAs or the timer expires, the system sends DPR and disconnects the TCP connection.

    The system also ends any affinity processing for this CCF.

  • Port changes to an IP Address—The system responds to this as if the applicable IP address was removed.
  • Priority/Weight change—The system routes new call sessions based on modified priority without any impact on live sessions.

Configuration change impacts include:

  • Disabled account-config —The system stops making DNS queries, and tears down all connections by sending a DPR (without checking the status of any outstanding ACRs).
  • Primary Pool Added—This equates to enabling the account-config.
  • Secondary Pool Added—You can only add a secondary pool if you have already configured the primary. In this scenario, the system makes the DNS query and sets up the secondary pool list
  • Secondary Pool deleted—The system responds to this as if you have removed all secondary pool IP addresses.

    Note:

    You cannot remove a primary pool.
  • FQDN changed—The system makes a DNS query and gets the DNS result. Based on DNS result, the system compares the existing and the new lists and performs the same procedures as when an IP address is added or removed.
  • Pool Type changed—The system treats this scenario as if there was an FQDN change.
  • Other than FQDN changed—The system maintains CCF affinity and does not issue any DPRs.

DPR/DPA Support

The SBC supports transmission and reception of DPRs, which confirm disconnects and disables retries. DPR/DPA processing includes:

  • The CCF sends the DPR—The system replies with a DPA. It then removes any affinity mapping and routes any outstanding ACRs to alternate CCFs. If there is an FQDN refresh for this CCF after a TTL, the system reconnects to it.
  • The SBC sends the DPR—The system waits for all outstanding ACAs, based on the maximum retries. Assuming you have enabled the send-disconnect-peer-msg parameter, the system then removes any affinity mapping and routes outstanding ACRs to the next CCF.

    Note:

    The system also performs this procedure when you have configured the account-server with an IP address.

If you have configure the account-server with an IP address, the system responds to DPRs from the CCF by:

  • Responding with a DPA
  • Disconnecting the TCP connection with CCF
  • Removing any affinity mapping
  • Starting the restart-delay per the account-server configuration

At this point, you can remove the CCF from the ACLI., otherwise the system tries to reconnect to that CCF when the timer expires.