Panel | |
---|---|
In this section:
|
Multiexcerpt | ||||||
---|---|---|---|---|---|---|
| ||||||
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
To address these concerns, a SIP-aware front 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.
|
Multiexcerpt | ||
---|---|---|
| ||
The following are the advantages of this architecture:
The SBC must be configured When configuring the SBC, ensure to mark it as "behind" the SLB. |
Include Page _SLB note _SLB note
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
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.