Policy frameworks usually can vary broadly from one system vendor to the next, from a no-rules approach to performing deep packet inspection-based classification.
However, all policies need to be based on
- Mobility policies per user ID
- Applications like SIP, H.323, Skype, MSN Messenger
- AP and station location
- Port’s subnet
- SSID of the wireless network
It is also essential that the policy framework should be unified across the wired and wireless Layer-2/Layer-3 across the LAN (Ethernet and Wi-Fi) to provide services such as VoWi-Fi and Video over Wi-Fi, which need end-to-end QoS. The Wi-Fi will have additional constraints and policies based on location and the SSID. The markings and mappings would be taken from the DiffServ, 802.1p and extended to WMM (or 802.11e)
However, these policies would still map to a traditional 5 tuple or 6 tuple based on SRC-IP, DST-IP, SPORT, DPORT, PROTOCOL, SSID/VLAN.
The policies can be implemented in a slow path and fast path architecture similar to the open flow architecture. The host processor handles all the control packets, connection tracking and initial packets as part of the slow path, and sets up the flow action entries for the fast path. The flow action entry has the edit and action fields as mentioned below with appropriate packet headers like MAC header data etc.
The host processor code has protocol helpers that allow connection tracking code to understand protocols, which use multiple network connections (e.g. FTP, H.323, SIP and similar) and mark the ‘child’ connections as being related to the initial connection, usually by reading the related address out of the data stream.
Once the flows are established the packets do not need to go to the host processor for any further processing and they are sent to the Ethernet/WLAN ports directly.
To process the Wi-Fi and Ethernet packets related to policy frameworks, a system must implement three main stages in the fast path after the initial parsing.
Classification parses the incoming packets, extracts the fields like MAC-addresses, source/destination IP address, source/destination ports, protocol, VLAN fields. In addition, this part of the process performs the basic checks for the IP version, TTL etc. A hash value is computed based on the 5/6 tuple and flow action entry is fetched based on the hash value. The flow action entry has the action fields and packet edit options.
The packet edit options in the Flow-Action-Entry field specify the packet modifications to be performed on the packet.
- 11 to 802.3 conversion
- Tunnelling options
- MAC address addition (for route)
The actions in in the Flow-Action-Entry field specify whether to drop, forward or capture the packet. These options are used to implement the firewall and other additional functionality.
In addition, the action field also specifies the TOS mapping and QoS rules to apply on the packet. (The slow path of the framework defines the actual mapping, and the action is executed here.)
The packets are then forwarded to the QoS engine, that implement the scheduling and rate shaping algorithms on a per AC per station basis.
Coming up next
Stay tuned to our blog – in our final article in this networking-focused miniseries, we will present the architecture to support this new framework.