ixEngine: Embedding DPI and L7 intelligence in an SDN architecture
Network Applications Layer
With relative ease, DPI software can be embedded in applications running in the network applications layer, similar to a network appliance (i.e., traffic steering). However, some application redesign may be needed to minimize the impact of potential bottlenecks created by a lengthy communication path. For instance, some of the traffic flows must be transmitted from the node – through the SDN controller – to the network application running a DPI engine. After the flow is identified, the application sends policy rules to the node to steer the flow, so only a fraction of the traffic is typically sent from the node to the network application. Given the possibility for delay, this DPI deployment works best for non-time-critical network applications, like analytics
DPI software may be deployed in the SDN controller, which may use the network intelligence for its own control services or send it to the network applications layer via the northbound API. The node (e.g., switch, network device) handling the flow sends the first non-empty packet to the SDN controller for L4-L7 analysis, possibly using the OpenFlow protocol with some extensions that are discussed at the end of the paper. Locating DPI in the controller avoids an increase in the cost of nodes; however, portions of the traffic (possibly less than 10 percent) must be duplicated and forwarded from nodes to the controller, which could lead to scalability and performance issues. A distributed controller architecture design can minimize these concerns.
Network nodes can also run DPI software, and after identifying the App ID and metadata, they can either:
- apply a pre-defined policy directly, or
- send this information to the SDN controller or a network application, and then receive back policies or rules.
When, the SDN controller is the recipient of the extracted information, it can instruct the node to apply a particular policy after having some sort of dialog with a network application. Afterwards, all subsequent flows of the same type do not require DPI analysis. Compared to the other options, implementing DPI in the node layer minimizes latency; then again, this approach is the costliest because it requires the largest number of DPI instances in the network. In the future, the number of DPI instances may be reduced by using methods for tagging or conveying DPI information in an end-to-end manner, as suggested in a recent draft IEFT recommending enhancements by adding a Network Service Header (NSH)*. Some workarounds are also envisioned using tagging/labeling, tunnel configuration, etc.
DPI capacity scales up and out with Qosmos ixEngine
While DPI may be integrated in different layers as listed above, its integration may follow several reference designs, to fit expectations of equipment manufacturers and service providers.
DPI as a VNFC
In the ETSI NFV software architecture working group, a network equipment is being defined as a Virtual Network Function (VNF) composed in turn of one or several Virtual Network Function Components (VNFC). While the former is standardized from its interface and APIs, the latter is only defined from the architecture point of view where the VNFC interfaces and APIs are defined by each vendor.
The VNFC DPI is one of the official use cases presented by the ETSI NFV reference document and explains all the benefits in integrating a DPI VNFC as part of a network equipment (VNF).
DPI as a shared function
Following the Intel® reference design in its Intel® DPDK® virtual switch, the DPI engine is integrated in the virtual switch enabling a shared DPI function for all the hosted virtual machines (virtual appliances).
While the classification is done at the hypervisor level thanks to the DPI engine, the service information is either used directly by the hypervisor with some enforcement function or passed to the hosted (virtual) applications. This can be done in several ways, one of which is currently being drafted at the IETF under the name of Network Service Header (NSH).