Load Balancing STIR/SHAKEN Servers

The ESBC can use STIR/SHAKEN to perform two key security functions:

You can configure the sti-as and sti-vs in the session-agent, sip-interface and realm-config with an sti-server-group or a list of sti-server names (up to 4). If you configure the sti-server-group, the selection of a server to send the AS/VS requests to is based on the strategy parameter configured in the sti-server-group. If you have configured multiple entries for sti-server, the ESBC treats the list as a group with round robin selection strategy.

Strategies include:

Hunt—Selects servers in the order in which they are listed. For example, if the first server is online, working, and has not exceeded defined constraints, all traffic is sent to the first server. If the first server is offline or if it exceeds a defined constraint, the second server is selected. If the first and second server s are offline or exceed defined constraints, the third server is selected. And so on through the list of servers.
RoundRobin—Selects each server in the order in which they are listed in the destination list, selecting each server in turn, one per transaction.
LeastBusy—Selects the server that has the fewest number of transactions. If multiple servers have the same number of transactions, the foremost server in the group will be used.
PropDist—Proportionally distributes the transactions among all of the available servers.
LowSusRate—The Lowest Sustained Rate strategy routes to the server with the lowest sustained rate of transaction (based on observed sustained rate).

You can load limit servers in a group by configuring max-burst-rate, max-sustain-rate, burst-rate-window and sustain-rate-window in the sti-server configuration. When the rate of AS/VS requests sent to a STIR server exceeds either the max-burst-rate or max-sustain-rate, the ESBC does not select the server, reducing its ovehead. If max-burst-rate, max-sustain-rate, burst-rate-window and sustain-rate-window are not configured (with their values equal to 0) there is no load limiting.

Server Availability

In addition to supporting load limiting, you can configure the ESBC with a server timeout function, called circuit breakers, that prevent the ESBC from continually trying to communicate with a non-responsive server. These circuit breakers start in a Closed state.

The ESBC monitors the number of times (over a monitoring window) it does not get a response from a STIR server. If the number of failures reaches your configured threshold, the circuit breaker changes to Open state. The ESBC puts the server in Out of Service status, and stops sending requests to it. After a retry time period, the circuit breaker changes to Half Open state and sets the server back to In Service status so that it can be selected again. During this Half Open state, the ESBC only sends one out of "nth" times that the server is selected (while the results of pending requests are not known yet). If the server responds, then the circuit breaker changes to Closed state and the ESBC resumes sending requests to the server normally (that is, not every "nth" times). If a failure happens, the circuit breaker changes to Open state again.

You can configure the following values in the applicable sti-config to specify these circuit breaker's thresholds and triggers. The parameters' default settings are also shown:

sti-config       
        circuit-breaker-window-duration        10       
        circuit-breaker-error-threshold        5       
        circuit-breaker-retry-time             15       
        circuit-breaker-half-open-frequency    6

circuit-breaker-window-duration—The default is 10 seconds.
circuit-breaker-error-threshold—The default is 5.
circuit-breaker-retry-time—The default is 15 seconds.
circuit-breaker-half-open-frequency—The default is 6. This means the ESBC attempts to re-use the server once every 6th time.