HTTP Implementation to replace AMQP for Telco Event Bus

Deployments at the Far Edge can often be considered more like appliances than traditional Kubernetes workloads. This lens can be applied to not only the deployment models, like Single Node OpenShift, but also in the characteristics of the workload. Many of the deployments at the Telco Far Edge are basically packet processing machines. The RAN DU, for example, connects to the radios that your User Equipment connects to wirelessly on the Fronthaul and forwards packets on to the Midhaul. It uses technologies like SR-IOV and DPDK to more efficiently move packets from the Fronthaul network to the Midhaul network.

These systems are more sensitive to synchronization issues on the network and use PTP for better synchronization and precision. Not only are they sensitive to network timing, but they also want to have a better understanding of overall platform health, including both software - specifically PTP, and hardware.

In OpenShift, we solved this problem by utilizing Red Hat Advanced Message Queuing Protocol (AMQP). By adding this generic messaging component we were able to feed it with events generated by the OpenShift PTP infrastructure and the Bare Metal Event Relay (BMER) component that maps Redfish HW events to messages on the messaging bus.

We developed and published a sidecar container image that CNF applications can add to their Pod definitions and it will subscribe to the messaging bus and allow those CNF applications to more easily consume events.

The Red Hat Advanced Message Queuing Protocol (AMQP) Operator is now deprecated which forced us to reexamine our solution. We decided that with the reduced CPU budget allocated for the CaaS platform in Telco Far Edge deployments, we needed a leaner solution.

We’re pleased to announce that we’ve replaced the AMQP with a native HTTP messaging infrastructure. The RH event bus infrastructure utilizes HTTP Protocol Binding for CloudEvents - Version 1.0, and as we move from AMQP to HTTP this won’t change. Instead of putting these messages into the event bus we just send them to the consuming sidecar directly.

This new direction provides us a path forward before the AMQP Operator is removed from the catalog and it provides an improved solution over the previous architecture.

It’s better because it reduces complexity by removing a large dependency and the removal of the AMQP processes further reduces the solutions’ compute needs, which is an ever-present initiative at the Far Edge.

If you are a CNF vendor wishing to have a deeper understanding of the running platform then this is your path forward starting in 4.13.