By Mitrasingh Chetlall, Product Manager, Qosmos Division, Enea
Deep Packet Inspection (DPI) examines the data part of a packet as it passes an inspection point, identifying the different protocols and extracting metadata for service assurance, traffic management, policy, cybersecurity, etc. To ensure the high availability requirements of certain environments, such as telecom networks, DPI software must be capable of dynamically updating protocol signatures and classification functionalities. There are two types of updates: Protocol Data Binary and Protocol Bundle.
Why is hot swapping required for DPI engines?
High availability (HA) environments require network appliances to provide seamless software updates with no service downtime. The requirements of some environments are higher than others. Telco networks, for example, apply the law of five 9’s which means that any system operating in the core network needs to be available 99.999% of the time, which is equivalent to max. 5 minutes downtime per year.
Let us imagine a DPI component in a business critical use case in a telco network: a PCEF/PCRF, for example. To ensure business performance, the PCEF/PCRF solution needs to have access to application visibility 24/7 with max 5 minutes downtime per year. If the DPI component has no hot swapping capabilities, the network operator must stop and restart the solution embedding DPI each time it needs to perform updates and access new protocol signatures. As we know, telco user contexts can last for days, so any contexts established during the update process will not be classified anymore. This means that, from the operator’s perspective, even if the appliance is restarted in less than 5 minutes, the impacted service downtime goes way beyond the permitted 5 minutes and heavily affects service quality.
Hot swapping – an essential feature for a DPI engine
DPI technology, by nature, is based on an empirical approach. This means that signature and metadata extraction are identified through reverse engineering. In the case of Enea’s Qosmos ixEngine®, these functionalities are accessible to the end user via a DPI plugin.
However, some applications evolve at a fast pace. For example, the WhatsApp application was updated ten times in December 2017 alone. While most of these updates have no effect on the application’s protocol signature, we can be sure that on a monthly basis, at least one of them will impact the protocols and generate the need for a protocol bundle or data signature update within the DPI engine. So, for any appliance embedding DPI technology, it is crucial for the DPI component to be updated as frequently as possible to ensure the accuracy of the appliance.
Embedded DPI systems that lack dynamic updates of protocol libraries (hot swap updates) require regular maintenance activities in order to renew protocol signatures and this can have a significant effect on OpEx. This type of update involves an integration cost to rebuild the application as well as field operation costs to update the software. Furthermore, the stop/restart process erases the classification memory of persistent traffic, which renders the solution inaccurate following the maintenance activities. The only cost-effective way to ensure an accurate and high-performance DPI-based solution is therefore via dynamic protocol updates (hot swaps).
How does hot swapping work in a DPI context?
Hot swapping is the ability of the DPI engine to dynamically load protocol signatures for a seamless update with no service interruption at runtime.
In the case of Enea’s Qosmos DPI technology, this is achievable in two ways:
1. PDB (Protocol Data Binary) hot swap
2. PB (Protocol Bundle) hot swap.
A PDB hot swap loads up a new protocol data signature binary file (no C code involved, only serialized data) and replaces the existing one with the new one. Since the PDB file is used for 90% of the classification carried out by Qosmos ixEngine, it is important that it is kept up-to-date.
The PB hot swap replaces an existing protocol bundle with a new one at runtime. The protocol bundles contain not only C code for classification and metadata extraction, but also serialized data (PDB) for the protocol data engine, as well as logic for all the classification and extraction engines used in the DPI component.
The PDB hot swap
The standard protocol bundle as provided by Enea’s Qosmos Labs contains a data signature part called protocol data binary, aka PDB. Qosmos Labs deliver a hot swappable PDB update every 3 weeks. The following diagram illustrates how dynamic PDB updates work.
The systems administrator has to call a routine (based on Qosmos specific APIs for the PDB swap) to update the PDB dynamically. This routine consists of allocating memory for the new Qosmos PDB, loading the PDB into that memory and triggering the swap mechanism. The classification process that is active at the time of the swap will be completed using the legacy (standard) PDB. All subsequent classification attempts will be carried out using the new PDB. This has minimal performance impact and takes a couple of milliseconds. Besides performance aspects, this method is perfectly stable as no code is involved!
The PB hot swap
Every 9 weeks, Qosmos Labs provide all Enea’s DPI customers with a new version of the protocol bundle (PB) in the form of a shared object file. Each version of the PB provides new protocols, protocol updates and fixes, new classification techniques and any additional extracted metadata that are available. The dynamic PB update process is similar to that of the PDB updates, as the following diagram illustrates:
The new PB can be loaded dynamically in a runtime environment using a dedicated routine (based on Qosmos specific APIs for PB swap). This routine consists of allocating memory for the new PB, loading the PB file provided by Qosmos Labs into the allocated memory and triggering the swap mechanism. Since flow contexts are associated with a specific PB, all flows up to the moment of the swap will continue to work with the default PB. All subsequent flows will be directed to the newly loaded PB. Therefore, there is a short period of time when both PBs coexist and garbage collection mechanisms are required to expire never-ending flows. These mechanisms are easy to implement and once executed, the standard PB can be deactivated in favor of the new one.
The only way to ensure that network appliances have constant, reliable, high-precision visibility of traffic flows is through regular DPI engine updates. In high availability networks, where it is also necessary to comply with strict SLAs and OpEx requirements, the DPI engine must be capable of performing updates through dynamic upload hot swaps. In the case of Qosmos ixEngine, Qosmos Labs ensure the highest possible DPI performance by delivering two types of seamless update: high frequency signature-only updates (PDB hot swaps) interspersed with full PB hot swaps that provide functional as well as signature updates.
Qosmos ixEngine provides unbeatable traffic visibility. As the highest performance OEM solution on the market, it can identify over 3000 protocols and applications up to layer 7, and extract over 4500 application metadata, analyzing traffic in real time at up to 100 Gbps. Delivered in the form of a Software Development Kit (SDK), developers integrate the software libraries, modules and tools into their solutions in order to benefit not only from the precision of its flow analysis but also from the regular hot swap updates provided by Qosmos Labs. Qosmos ixEngine can be used in all environments: physical, virtualized and in SDN architectures.
For more information on Qosmos ixEngine, please click here.
To see a demonstration of Qosmos ixEngine for network and telecom applications, please click here.
About the Author
(Mitrasingh) Danny Chetlall is Product Manager at the Qosmos Division of Enea. He has over 14 years’ experience in the architecture, design and development of IP technologies with specific expertise in Deep Packet Inspection and networking applications. His responsibilities include the protocol signature and protocol bundle updates for Qosmos ixEngine.
To contact the author or for more information, click here.