The DIAMETER load balancer is provisioned with a set of rules to determine where to forward an initial DIAMETER session request. Once a destination is assigned, it will keep on delivering the following DIAMETER requests/responses using the same Session-Id to the same destination. This is ideal to have a single entry point for DIAMETER traffic into a workload and distribute traffic across multiple DIAMETER-based microservices.
Load balancers are most commonly coming as a part of the kubernetes cluster in a form of ingress controller or as part of the cloud infrastructure in various forms. While these perform perfectly for UDP/TCP/HTTP type of traffic, we sometimes need more telecom protocols aware load balancers to properly distribute the telecom control plane within a workload. Slicce load balancers come to fulfill this need when the generic load balancer of the infrastructure is not able to load balance a specific telecom protocol.
In particular and focus on DIAMETER traffic, the DIAMETER Load balancer facilitate:
When using load balancing based on Application ID, the system intelligently distributes DIAMETER traffic among a set of services based on the Application ID included in the request. This ensures that messages related to different applications are directed to the appropriate server handling that specific service. Using round-robin, least connections, or other algorithms to balance load, it ensure that requests for a specific AppID are sent to the service or stateful set best suited to handle that application. This to empower the workload with efficient scaling.
Traffic Routing Based on ApplicationId
The DIAMETER Load Balancer can distribute traffic towards a same Realm/ApplicationId between multiple service instances of a same kind. In which case it can automatically detects a failing service and assure service continuity via remaining service instances. The service set can be elastic or auto-scaled since the load balancer will allow traffic distribution to new instances of the service immediately. It is also possible for an external orchstrator to orchestrate the load balancer via REST API in case the toplology of the workload is getting updated.
Automatic failover with API Orchestration
| Software packaging | Docker image, RPM or DEB package. |
| SCTP | RFC 4960; with multi-homing support |
| DIAMETER base protocol | RFC 3588, RFC 6733 |
| DIAMETER interfaces | Ro, Rf, Gx, Gy, S6a/S6d, Swx, Sy, SGs, SGd, Cx, Sh |
| Orchestration API | RESTful over HTTP2 |
