Traffic Flow Hash Ubiquification: Flow-based QoS techniques, such as Weighted-Fair queuing (WFQ) rely on the original source and destination IP addresses of the packet to hash traffic flows in to "conversations." Certain IPsec protocols and modes effectively ubiquify the information needed to perform this hashing decision—the source and destination IP address. Consider the example of IPsec ESP in Tunnel mode. In this example, the inner IP header will be encapsulated within the ESP boundary and encrypted. Therefore, if the router wants to use WFQ to hash this traffic flow into a conversation, it will not be able to, as it will be unable to read the encrypted original source and destination IP address. Because most VPN endpoints supporting QoS rely on flow-based QoS techniques such as WFQ and Low-Latency Queueing/class-based weighted fair queueing (LLQ)/(CBWFQ), it is critical that the IPsec VPN endpoint have the capacity to classify traffic flows before IPsec or generic routing encapsulation (GRE) encapsulation or both. Cisco IOS offers this functionality with the IPsec Preclassify feature.
Packet Reordering and the IPsec Antireplay Window: If packets are received outside of the antireplay window in an IPsec VPN, they will be dropped. The nature of QoS is to reorder packets, which can sometimes result in delay of queued traffic. It is critical to ensure that n delays are not so long as to result in the packet being received outside of the antireplay window on the receiving VPN endpoint. Cisco IOS offers the capacity to extend the antireplay window on VPN endpoints to alleviate antireplay window errors if they should arise.
Packet Marking Obfuscation and (LLQ/CBWFQ): LLQ/CBWFQ is a QoS technique for reordering traffic flows locally on a network device. LLQ/CBWFQ requires that packets within a traffic flow be identified in some way. This is typically achieved by marking the packet by setting the DiffServ bits in the IP header. Network devices are therefore able to differentiate that traffic from other traffic flows and treat it (queue it) with the appropriate level of urgency. The scope of effect of LLQ/CBWFQ decisions is contained to the local device only.
Resource Reservation Protocol (RSVP): RSVP uses an exchange of RSVP signaling messages between two endpoints to reserve resources for delay-sensitive traffic between the two endpoints. Unlike LLQ/CBWFQ, where LLQ/CBWFQ classification and queuing decisions are local in scope, the scope of RSVP queueing decisions is end-to-end. Although RSVP can be configured to work in tandem with DiffServ-based QoS, it can also be configured to place traffic in the RSVP-reserved queue regardless of what type of DiffServ policy is configured on that specific network node.
Note - For more detailed information on LLQ/CBWFQ and DiffServ, visit CCO at the following URLs:
DiffServ—The Scalable End-to-End QoS Modelhttp://www.cisco.com/en/US/partner/tech/tk543/tk766/technologies_white_paper09186a00800a3e2f.shtml
Implementing DiffServ for End-to-End Quality of Service
As mentioned previously, QoS requires the use of end-to-end messaging techniques and the interpretation of certain bit values within the IP header. In some cases, if care is not taken during an IPsec/QoS deployment, IPsec can obfuscate the necessary messaging and IP header bits needed to deliver QoS. We will discuss QoS within this context, and explore some available techniques for delivering QoS within an IPsec VPN deployment.