Miss Part I? Click here.
From the previous discussion, it can be seen that a DPI device must fulfil a variety of functions that are best distributed over several functional units that best support the respective required function. Additionally, it must be possible to route packet flows from left or right port to the same inspection unit, even for a large number of external connections.
In general the steps to take for DPI are as follows:
- Identify packet source (physical link)
- Execute pre-classification (optional, may be needed for very high bandwidth, very high port count environments)
- Distribute evenly over classification units, with packets for the same flow going to the same classification unit for both directions.
- An additional function that may be implemented at this level is a health check function that goes beyond checking for physical presence of the DPI inspection units. This is typically achieved by adding special “check” packets to the packet flows and ensuring these packets flow through the entire inspection stack and appear again after processing in a reasonable time frame. If this is not the case, the respective inspection unit will be considered inoperable until a new check proves it is operational again. The goal here is to spot hung inspection applications early on and ensure appropriate reaction of the system.
- Actual Deep Packet Inspection. This includes multiple functions and has some requirements for maximum performance as well as maximum insight into the packet flows.
- Internal forwarding of the flow inside the unit. This step ensures that always the same processing unit (frequently referred to as Logical Core, LCore; this may be an actual CPU core dependent on the CPU architecture) sees all packets comprising the flow, and that in both directions.
- Execute the actual processing. Extract as little data as needed to figure out whether a flow triggers the need for further inspection. If that is the case, continue processing, potentially set up forwarding to another, deeper-level inspection unit and execute the rules set up for this case.
2. Apply policies, if needed, for the given flow using the flow fingerprints, ensuring that the possibly modified packet returns to its original path as quickly as possible.
In a nutshell, behave like an active, slightly longer direct cable between left and right physical ports.
The above steps define the building blocks that should be used to compose the chain of steps needed, while ensuring all other requirements that were mentioned above are satisfied.
General Architecture Review
There are several bladed architectures available today that allow the building of appliances fulfilling the requirements laid out earlier in this article.
Figure 3. General architecture of an ATCA-based DPI system
A particularly suitable architecture would however be AdvancedTCA® or ATCA®. ATCA has been designed to support an all-IP network running at very high bandwidth, while possessing all the additional capabilities required to support high availability.
Yet, the ATCA standard has been created in a way that does not require the use of these features from the outset, but allows them to be added over time as needed to build the application.
Hot swap support and built-in management features, together with scalability from very few to many blades make ATCA a perfect basis for DPI applications.
Figure 4. AdvancedTCA systems are an ideal platform for applications that use DPI
ATCA is built around an architecture that has two separate networks, Base (control plane) and Fabric (data plane). Today’s systems feature redundant switch blades and Fabric running at 40G, resulting in a total of 1.2Tbps aggregated bandwidth in the backplane, or 80Gbps per blade.
Hot swappable node blades and switches allow continued operation even in the case of hardware failures, as well as seamless in-operation insertion of additional blades, ensuring upgradeability of the system without interruption of service.