There is a continuous strong trend for detailed, real-time understanding of traffic in all networks. This will become even more crucial in SDN and OpenFlow architectures, which will not be able to function efficiently without L4-7 network intelligence. Initial SDN architectures focus on L2-L4. This can lead to inefficient traffic steering and inefficient use of physical equipment. There is a need to extend traffic intelligence to Layer 7, which means more effective use of network resources and smarter service implementations.
What is L4-7 network intelligence?
L4-7 network intelligence is created by techniques such as Deep Packet Inspection (DPI) which analyzes traffic and provides intelligence in the form of App ID and Metadata:
– Examples of App ID: SIP, SMTP, YouTube, FaceBook, BitTorrent, Skype, etc.
– Examples of extracted metadata: URL, file name, browser type, cookies, DNS queries, video codec, IMSI, SIP caller/callee, user ID, login, etc.
– Examples of computed metadata: delay, Jitter, application response time, etc.
Where can L4-7 network intelligence technology be located in an SDN architecture?
L4-7 software components can run inside [v]switches, where protocol information and metadata are fed northbound to the Controller and to the Applications.
Alternatively, L4-7 inspection software can be embedded in the Controller, feeding traffic information to applications through northbound API, or consumed directly by the Controller.
In both cases, L4-7 DPI embedded at a few strategic locations in an SDN architecture creates common-format L4-7 traffic intelligence, which can be consumed by different SDN elements. Some applications will also embed their own custom L4-7 analysis for specific service processing.
L4-7 network intelligence in [v]switches
In this case, the L4-7 DPI software is embedded in [v]switches and extracts App ID and metadata from the network traffic:
- L4-7 DPI, embedded in a virtual or physical switch, identifies each application protocol and extracts requested metadata per flow
- The switch can apply pre-defined policy directly, based on the L4-7 intelligence
- App ID and metadata could also be sent to the Controller
Example of use case: Service Insertion
With network intelligence limited to L2-4 visibility, switches cannot differentiate traffic between various types of L7 applications. This causes inefficient use of both bandwidth and compute resources since each specialized system (e.g. video optimization) has to analyze the entire traffic in order to pick out the relevant flows (e.g. video) and process them.
Thanks to L4-7 network intelligence embedded directly in [v]switches, each application flow can be forwarded directly to each specialized service processing/ VM guest or a specific quality of service path. This optimizes both network and compute resources. See figure below.
In addition, with this approach, traffic/flow steering can be changed dynamically in a programmatic fashion, to transparently insert new customized network services on a per flow basis. Service Insertion only represents one use case for L4-7 network intelligence. A number of other use cases require the same technology: video optimization, policy control, firewalling, network monitoring, etc.
L4-7 DPI in the Controller
In this alternative model, the L4-7 DPI software is embedded in Controller and feeds App ID and metadata to applications through northbound API. The information extracted by the DPI software could also be used directly by the Controller.
The much-needed standardization
A way to make L4-7 network intelligence a key enabler for future infrastructure is to create a standard by extending OpenFlow fields with additional information such as App IDs and corresponding metadata for each flow. This would create a common format which could be used by switches, controllers and applications. In addition, it would even work in proprietary, non-SDN environments: virtual switches could use extended DPI fields even before the official extension to OpenFlow. This means that the power of L4-7 network intelligence can be leveraged starting today!
By Jérôme Tollet, CTO & Co-Founder at Qosmos