SIP-Aware Front-End Load Balancer

Feature Overview

With the wide adoption of cloud and virtualization technologies (NFV), the physical network functions (PNF) become virtual network functions (VNF) running on virtualized infrastructure manager (VIM) (like OpenStack), Ribbon includes virtualized SBC, PSX and RAMP product platforms. While NFV adoption will ultimately result in Capex/Opex reduction for operators, this also presents some challenges.

• Seamless Capacity Expansion with no impact on external network topology (i.e. need to reduce the impact of new VNFC creation on the peer(s))
• Need for IP Address Consolidation
• Challenges due to Cloud-native architecture
• Need for Single SIP IP Address Appearance

To address these concerns, a SIP-aware front-end Load-Balancer (SLB) is available for SBC and PSX. SLB as a front-end means that a single IP address is exposed towards peer operators. SLB in turn distributes the traffic among back-end call-processing VMs. Ultimately, SLB has its own capacity limits and deployments need to make use of DNS, should the traffic requirements demand more than one SLB instance (SLB is in HA mode and hence it is actually more than one HA pair). However, as long as a single SLB (HA pair) addresses the traffic equivalent to a single site traffic (and hence that equivalent number of back-end call-processing VMs), there is no need to return to using DNS for SLB. Instead, if the traffic goes beyond what a SLB can handle, the solution is to create a new SLB with a new IP and expose that to the peer.

Key Features of This Architecture 

The following are the advantages of this architecture:

• The peer operator need not update ACLs when a new VM is spawned.
• The SLB can have network-specific overload-detection and load-balancing mechanism(s) towards/between back-end call-processing VMs.
• The new VM instance can start traffic immediately.
• For access deployments, SLB can terminate IPSec/TLS/TCP connections towards the peers and scale-in/scale-out back-end VMs. If the back-end VM’s IP address is exposed directly, the UE will not re-anchor the registration state to a different VM (in case of scale-down).

The SBC must be configured to mark it as "behind" the SLB.

SLB/SBC Discovery Process

• The SBC initiates the handshake/discovery process by sending “SlbRegisterReq” to the pre-configured SLB IP Address.
• The SLB assigns a unique instance ID to each SBC and then the SBC embeds this ID in the branch and tags the parameter as follows:
  • • Via: SIP/2.0/UDP 10.3.0.175:5060;branch=z9hG4bK38B0000c956f5f96dae_cK0003.
    • To: 3334445566 <sip:3334445566@10.2.0.182:5060>;tag=gK38800063_cK0003.
• The SBC registers each zone with the SLB and download the SSP data associated with each zone.
• The zone name on SBC should ideally match that on the SLB.
• The SBC uses “SlbServiceStatusMsg” to update its status (In-Service/OOS) to the SLB.

Use-Case Diagrams

SLB as a Front-end for N:1 HA S-SBC

The SLB is deployed as front-end for Ribbon S-SBC. The Ribbon S-SBC can be deployed as an Access SBC and/or Peering SBC.

Typical S-SBC VNF Front-ended by an SLB VNF

SLB Front-ending Multiple S-SBC VNFs

Enhancements

• The SLB installs the necessary ACL rules that are required to allow the traffic from the successfully registered UE/IP-PBX. The necessary information for this is sent by the S-SBC in the control messages.
• The SLB deletes all the RCB affinity table entries and the ACL rules as informed by the S-SBC as a part of control information.
• The SLB starts a timer and maintains RCB affinity table entries until the timer expires.
• The timer is restarted when the S-SBC indicates, through a control message, that the RCB is refreshed.
• The SLB deletes these entries mapping and the ACL rules when the timer expires.

The SLB supports Access deployments. SLB previously handled peering deployments – it load-balanced OOD SIP requests that it received from a peering partner among back-end SBC instances. 

In a peering deployment, where each new call can be processed by any SBC, SLB can use Call ID-based hashing to load-balance incoming call requests. The SLB selects the same instance for mid-dialog/in-dialog requests based on instance-identifier that is present in remote tag (To-tag) and back-end SBC instances ensure that instance-identifier is a part of local-tag (that gets echoed as To-tag for ingress in-dialog SIP requests)

The SLB does not maintain any state/mapping to route in-dialog ingress SIP requests to the right instance.

In an Access deployment, there is always a registration from the UE or IP-PBX. SLB load-distributes initial registrations and once the initial registration is assigned to a given SBC, subsequent SIP messages from the UE or IP-PBX are be forwarded to the same SBC. In other words, the SLB needs to maintain "affinity" that gets created at the time of initial registration and is used for routing refresh registration, de-registrations, OOD INVITE and OOD Non-INVITEs from the UE/IP-PBX to the same SBC.

With access deployments, a UE or IP-PBX performs REGISTRation and back-end SBC maintains registration context (RCB) for that registration (until the UE/IP-PBX de-registers or the registration refresh timer expires).

The SLB maintains an affinity or mapping of specific registration requests forwarded to specific back-end SBC instances, so that subsequent OOD SIP requests (these include REGISTER re-transmissions, de-REGISTER, refresh REGISTER, OOD INVITE/Non-INVITE, and CANCEL, for example) from UE/IP-PBX are routed to the same instance.

The SLB maintains a combination of the UE’s AoR + UE’s IP address to back-end SBC mapping. SLB uses the instance-identifier (Reg-info) in user-portion of R-URI to select the right SBC instance for the messages received from the AS.