Something more technical this time.
Increasingly more and more systems while becoming more complex, are becoming multi-process, i. e. have tasks separated by type of the work to be done, or by number of workers doing same work. That is also very true in telecoms, where increase of complexity requires creation of separate dedicated units (processes, services, servers or server groups) which executes their own dedicated tasks, and increase of workload (be it CPS, MPS or whatever measure) requires increase of parallel units doing same job.
Historically, there are protocols created to do this or another specific task. Take, for example AAA (Authorization, Authentication and Accounting): there is RADIUS, DIAMETER, TACACS+ to start from. They are all great very well established and open AAA protocols, proven by decades of existence, IETF approved and each of them perhaps processed quadrillions of AAA requests in total. Their open nature make them very well suited in distributed environments, where pieces of equipment might be geographically and/or topologically distributed, and designed by different vendors.
However, outside of the described scenario, the list is probably short. Let's say besides AAA, we also want to query a NAS (Network Access Server), which by chance can be a SBC or Proxy, etc, for some specific info, like sessions status, or available resources, etc. There are few possible approaches, like: a) extending the above mentioned protocols (VSAs in case of RADIUS), or use separate protocol for monitoring, like SMPP. That becomes more complex.
Another case is scalability: with increase of load, the systems might need to increase number of devices to handle requests - in an example with RADIUS, that would be to increase number of RADIUS servers. While that is perfectly possible in most of the implementations, the setup becomes difficult to manage if each NAS is required to add a new RADIUS server whenever laod increases.
Setting aside AAA, there are many other inter-process messages running between processes responsible for operation of telecom system. Requests from RESTful APIs, for example. They might need to pass from the API endpoints, via some kind of authentication process, and then into execution queue. Or a process requiring real time routing information. The types of requests are countless.
One of the approaches is to search for possible alternatives outside of telecom domain, within broader software development area. Several message queuing protocols are available, and AMQP or Advanced Message Queuing Protocol is one of them. It has clearly some good advantage points worth considering it as an universal tool:
a) it is transparent to the payload, i.e. you can send any type of the message, the protocol does not enforce any specific format;
b) it is not only a delivery protocol - it also queues messages which is very desirable feature in congestion-prone networks;
c) It has a concept of Message Dispatcher- a.k.a proxy, which can tell what messages from whom go to what recipient, therefore load sharing becomes more easy solvable task;
d) it has well written and maintained libraries in all important programming languages;
e) and last but not least: one of most popular opensource AMQP Message Broker implementations: RabbitMQ Server was written in Erlang, a programming language created by telecom giant Ericsson with a purpose to write highly efficient telecom related code.
More on specifics of AMQP implementation later, in another post, with some details and examples.
