12/10/09

The need for Native Diameter Load Balancing

Load balancing has been almost a mandatory component to successfully provide high availability and nearly transparent scalability to web-based applications in the last 20 years.

Unlike HTTP and other web application protocols (SMTP, FTP, etc.), which are synchronous and stateless, the Diameter protocol is not only asynchronous but also do not abide by to a single request/reply communication sequence like web based communication protocols. This makes it more difficult to distribute Diameter because traditional web based load balancers are designed to operate best in a synchronous messaging environment in which a single request is made and responded to before another is processed.

In traditional load balancing, the load balancing is achieved in layer 4 (TCP/UDP), unlike this in Diameter the load balancing need to be message based, which means it has to be done in the Diameter level, above the TCP (and SCTP in Diameter case) level, since sessions are long lived and can outlive the relating layer 4 signaling.

More than this Diameter, due to its dynamic nature and the ability to add almost infinite amount of standard and vendor specific AVP’s and Grouped AVP’s in almost any combination, is a challenge to traditional web based load balancers, which cannot support the complex structure of Diameter and cannot fully use the Diameter AVP’s dictionary in order to perform dynamic load balancing of Diameter messages (for example try to configure iRules for Diameter, not a pleasant experience, I can assure you, make sure you got a few weeks of spare time)
To meet Diameter load balancing demands the Diameter load balancer needs to be a real native Diameter entity, this means it has to be a Diameter proxy in order to successfully use the entire set of AVP’s for load balancing decisions.
Being a native Diameter entity also enables the Load Balancer to offer many other benefits which are crucial for service providers, such as stateful configuration, Diameter masquerading, the ability to work dynamically with SCTP and TCP per the same session and to engage in Diameter over TLS in different scenarios.

To act in a stateful mode, is important requirement for Diameter load balancers due to the nature of the information inside the Diameter messages and service provider’s assurance needs.

Another related issue affecting service providers launch of new services is the complexity, cost and time associated with new network functionalities introduction. With the wide adoption of Diameter by service providers, every new network component is either a Diameter server or client, and needs to communicate with the other Diameter servers and clients around, this result in vast configuration and management burden and slow introduction of new services.
Having a Diameter native load balancer masquerades the need for this slow configuration, and services can be integrated and launched smoothly and faster, all the Diameter introduction/routing handling can be done in the native Diameter load balancer.

The ability to load balance Diameter requires a unique understanding of the way
in which the applications that use Diameter behave. Protocols such as Diameter that are
asynchronous and communicate bi-directionally are challenging to scale, hence rise the need for a native Diameter load balancer that has the ability to be stateful, extract and route requests at the Diameter message level and can load balance based on connections.