In this section:

Related articles:

System - SLB

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 (That is, 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 to peer operators. The 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.

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


Modified: for 12.1.3

Notes
  • For versions up to and including 12.1.2, all the SBCs behind the SLB should be from the same cluster and share the same configuration. Load balancing across heterogenous SBC deployments are not supported (this does not apply to version 12.1.3 and newer.)
  • When an SBC is behind the SLB, you must enable SLB usage before making configuration changes.
  • If you move an SBC SWe from an SLB deployment to a non-SLB deployment (or vice versa), you must clear the configuration using the clearDBs.sh script, and then reconfigure the SBC SWe instance.

Refer to SIP-Aware Front-End Load Balancer for a feature overview and use case diagrams.

Refer to the following CLI when configuring the SLB.

Command Syntax

% set system slb 
	commInterface <addressContext | ipInterfaceGroup | pktIpVar>
    inviteReqTimeout <1...180>
	nonInviteReqTimeout <1...64>
	regReqTimeout <1...180>
	overloadControlOptions 
		neverRetry <enabled | disabled>
		utilizationOverride <disabled | 0 ... 100>
	globalUtilization <1 ... 100>

Command Parameters - slb

Parameter

Length/Range

Description

commInterface

N/A

Defines the communication interface for SLB traffic. See Command Parameters - commInterface table below for parameter details.

inviteReqTimeout

<1 .. 180>INVITE transaction timeout on the SLB.
nonInviteReqTimeout<1 .. 64>Non INVITE transaction timeout on the SLB.
overloadControlOptionsN/A
  • neverRetry - Defines parameters affecting the peer overload control mechanism for the SLB traffic towards the SBCs
    • enabled
    • disabled (default)
  • utilizationOverride - The number of registrations (RCBs) allowed. The Utilization value configured on the SBC to override the weight of the SBC on the SLB.
    • disabled (default)
    • 0-100
globalUtilization<1 .. 100>The Global Utilization threshold on the SLB to generate an alarm. The range is 1-100.
regReqTimeout1-180 secondsRegistration transaction timeout on SLB. The default value is 90 seconds.


Command Parameters - commInterface

Parameter

Description

addressContext

Address Context of the communication interface; defines the communication interface for SLB traffic.

ipInterfaceGroup

The IP Interface Group of the communication interface.

pktIpVar 

Name of configuration variable to get packet IP address for SLB communication.