Rebalancing, as opposed to balancing, is taking some number of existing endpoints from functioning SBCs and redistributing these existing endpoints between current cluster members. Rebalancing can be automatically scheduled when a new SBC joins an existing cluster, or immediately invoked with the Acme Packet Command Line Interface (ACLI). When an SBC exits a cluster, whatever the reason, all of its endpoints are invalidated on the Oracle Communications Subscriber-Aware Load Balancer (Subscriber-Aware Load Balancer) and those endpoints are essentially balanced when they revisit the Subscriber-Aware Load Balancer.

A new SBC joins an existing cluster by initiating the establishment of an IP-in-IP tunnel between itself and the Subscriber-Aware Load Balancer. During an initial handshake the SBC designates which Subscriber-Aware Load Balancer service port or ports it is prepared to support. If there are existing SBCs supporting these designated service ports, the Subscriber-Aware Load Balancer instructs some or all of these SBCs to divest themselves of a specified number of endpoints. The Subscriber-Aware Load Balancer calculates the number of divested endpoints based upon the overall occupancy of that service relative to the Subscriber-Aware Load Balancer’s contribution to that occupancy. Existing cluster members not advertising support for service ports designated by the new cluster member are excluded from the rebalance queue.

The Subscriber-Aware Load Balancer sequences through eligible cluster members one at a time, using a proprietary protocol to request nomination and removal of eligible endpoints. The SBC replies with a CCP response that lists candidate endpoints. The Subscriber-Aware Load Balancer removes existing forwarding rules associated with those endpoints, and repeats the CCP request/response process until the cluster member divests itself of the specified number of endpoints.

When the divested endpoints re-engage with the Subscriber-Aware Load Balancer (upon their next scheduled registration refresh, for example), the Subscriber-Aware Load Balancer lacks a forwarding rule that maps them to a specific SBC. Consequently, the message is passed up to the software processes running on the Subscriber-Aware Load Balancer’s host, which chooses a new SBC destination for that endpoint – presumably, the new cluster member that has the most available capacity.

The cluster member, after being requested to nominate endpoints for rebalancing, uses several criteria for choosing the most attractive candidates. As part of its standard SIP processing performed by SBCs, the cluster member is aware of the expiry times for all of the entries in its SIP registration cache. Therefore, the cluster member can predict with a high degree of accuracy when any given endpoint will be signaling back into the cluster. As the forwarding rules on the cluster member are triggered by endpoint messages, the cluster member considers an endpoint whose registration entry is due to expire shortly an attractive candidate for rebalance. Note, however, that in many cases it is not prudent to nominate endpoints whose SIP registration cache entries are due to expire immediately, as this can cause a race condition between the CCP response and the SIP REGISTER message from the endpoint to the SIP registration function. To avoid this potential dilemma, cluster members are equipped with the ability to skip ahead to candidates whose expiry is not immediate.

Further, each cluster member categorizes the endpoints stored in its cache based upon a priority value that is determined via the Subscriber-Aware Load Balancer’s distribution policy (see Distribution Policy Configuration for more details). It nominates endpoints from its lowest priority buckets first.

Finally, the Subscriber-Aware Load Balancer does not rebalance an active SIP endpoint — an endpoint engaged in a phone conversation.

After removing endpoints from the first cluster member, the Subscriber-Aware Load Balancer moves to the next cluster member in the rebalance queue and uses the same CPP request/response exchange to remove additional endpoints. The same procedure repeats for additional cluster members until the Subscriber-Aware Load Balancer attains the target number of divested endpoints.