However, over the past few years, designers have been looking for a marriage between security and QoS functionality. By turning to a secure flow processor (SFP), many policies can be applied concurrently to each packet with only one pass through the SFP. That is, a firewall ACL rule can be applied, along with a NAT/PAT translation, an IDS signature, and a QoS service level with the same stateful flow classification input. Thus, SFP greatly simplifies adding QoS functionality to a security appliance, or adding security functionality to a QoS router.

Over the past two months, we've laid out two articles that examined how secure flow processing (SFP) enhances security and performance, while lowering cost of security equipment versus packet filtering solutions (Click here for Article 1 and Click here for Article 2). Now we'll extend this conversation to QoS applications, illustrating how SFP enhances the capability of QoS routers, while increasing performance and lowering cost.

The QoS Problem Statement
QoS emerged to provide circuit-switched quality over packet-switched technology. For example, when you pick up the phone and make a call, the PSTN or ISDN networks dedicate 56 kbps or 64 kbps of guaranteed bandwidth through to the users on each side of the connection. With the Internet protocol (IP), no such guarantees are made. IP's 'best effort' unreliable delivery is not well suited for media-rich applications, such as voice (VoIP) and video conferencing (H.323).

Voice and video involve real-time streams of data, which if lost or delayed too much will cause a 'cellular' experience, i.e. you cannot communicate with the other party. Proper prioritization of traffic is required for the enhanced content of today's networks. For example, small VoIP or video conferencing packets must be delivered from end to end within a bounded time period, or voice quality diminishes.

To solve QoS problems in VoIP and IP video conference solutions, designers are turning to the real-time transfer protocol (RTP) [Figure 1]. Under this scheme, the receiver buffers a pre-defined period of data, which is a few seconds or more. This buffering smoothes playback of bursty IP data, accommodates delay for retransmission of lost IP packets, and can repeat packets if retransmission did not occur in time to make it into the playback buffer. Audio and video transmissions can be understood if received within a bounded period of time.

However, the RTP solution has limitations, the larger the playback buffer, the more system resources are consumed. Voice and video applications require multiple playback buffers for each user, and large routers must support large numbers of users.

RTP playback buffers accommodate a certain amount of latency to transmit data across the Internet. However, the other side of the problem is to bound the amount of transmission latency end to end. Thus, the system must smooth the arrival of real-time data in order to decrease the resource requirements of playback buffers at the receiver. It turns out that voice and video packets tend to be small (so they consume little Internet bandwidth), but require high priority to avoid the burstiness and delay of normal 'best-effort' Internet data.

QoS Router Application
Figure 2 shows an example of a router that implements QoS separating flows of data into three classes of service: 'Real-Time', 'Guaranteed Bandwidth, and 'Best Effort'. The router classifies traffic to belong to one of these classes of traffic, and then either marks the packet or configures a route within the QoS cloud that is appropriate for the packet's class of service. In either case, the policy decision whether to admit a packet and determine what class of service it receives is done at the edge of the QoS cloud.

At the transmitting edge of the cloud, much more work must be done to figure out which class of service a packet belongs to. First, the application that this packet belongs to must be known. Then a look-up of the application and the end-points is performed to determine the class of service. If the class of service is still valid for these end-points, then the packet is admitted into the QoS cloud, a class of service assigned, and the packet forwarded with this special class of service (CoS). Either a packet marking or the next hop determines the class of service this packet receives. The bottom line is that this admittance and class of service (CoS) assignment cannot be performed without state-based complex protocol analysis.

The QoS router must relate the relationships of all sub-flows, so the QoS can apply the same priority to all child flows. For example, a video conference will have four real-time data flows: one video and one audio in each direction. The QoS router must be able to associate all packets from these flows with a single application, and provide all related packets with the class of service the subscriber is paying for.

Furthermore, at the edge of the cloud, the stateful, application-aware QoS router must understand all protocols that require QoS. It must detect as early as possible that real-time flows are coming, so system resources can be allocated (e.g. buffers for large amounts of real-time data)

The easy part is implementing the policy inside the QoS cloud once the CoS is determined. The routers in the QoS cloud already know what CoS, based on where the packet came from (MPLS or Int-Serv), or the packet has a special marking in the IP header (Diff-Serv). This forwarding function can be performed one packet at a time by stateless packet inspection, once the packet is marked or the route determined by the admittance policy. Inside the QoS cloud the assigned CoS can be mapped to normal stateless router queuing.

The hard part of the design is determining and assigning the CoS. In the next-two sections, we'll look at this issue head on. In these sections, we'll illustrate an example of a QoS policy providing premium service levels to 'Internal User System' host for voice and video services. The SLA to be implemented by the QoS routers in these two examples is:

1. Provide 'Internal User System' host 'Guaranteed Bandwidth' service for H.323 control connections to any host in 'Outside' network.
2. Provide 'Internal User System' host 'Real-Time Bandwidth' service for H.323 media channels for to any host in 'Outside' network.
3. Provide 'Internal User' System' host 'Best Effort' service for all other traffic.

The stateless QoS policy example shows how best effort traffic can usurp premium bandwidth in a QoS router that depends on stateless router queuing for policy implementation. The stateful QoS policy example shows how valuable resources are freed when the voice and video services terminate when the router uses dynamic, stateful, application-aware flow analysis for making policy decisions.

Stateless QoS Class of Service Example
This example analyzes a stateless QoS implementation that inspects one packet at a time. Admitting packets to the QoS cloud and assigning class of service is performed without taking into consideration information from related prior packets. It is possible for dynamic protocols to be mis-assigned CoS.

Figure 3 illustrates the content of a QoS policy table to accomplish the service level agreement described above. From left to right, the first four columns contain the IP and TCP admittance (QoS policy) criteria to which the inspected packet would map. The 'Condition' column contains further conditions to consider. The 'CoS' column contains the class of service applied to the packet: 'Real-Time', 'Guaranteed Bandwidth', or 'Best-Effort'. The 'comment' column contains annotations.

In Figure 3, QoS mapping #1 assigns 'Guaranteed Bandwidth' level of service when 'Internal User System' sends packets anywhere on the Internet to TCP port 1720, which is the well-known port for H.323. QoS mapping #2 also provides 'Guaranteed Bandwidth' level of service when 'Internal User System' sends packets anywhere on the Internet to TCP ports above 1024, which refer to the dynamically ephemeral (dynamic) ports negotiated during protocol establishment.

QoS mapping #3 provides 'Real-Time' level of service when 'Internal User System' sends packets anywhere on the Internet to ephemeral UDP ports above 1024. QoS mapping #4 provides 'best-effort' IP routing to any packets that do not meet the first three QoS mappings.

The H.323 initiator dynamically creates an H.245 TCP connection, and then establishes multiple RTP streams. It is common practice to assign ephemeral ports to values greater than 1024.

In this example, the QoS policy is to assign 'Guaranteed Bandwidth' CoS to H.245 TCP packets and 'Real-Time' service to the RTP & RTCP packets. Unfortunately, the QoS mappings #3 conflict with QoS mapping #4, which allows any UDP/IP packets with ports above 1024 to usurp 'Real-Time' class of service from the voice and video RTP/RTCP streams.

QoS mappings #2 and #3 must be flexible enough to allow various values of ephemeral ports used by H.323 to be provided higher levels of service. Unfortunately, this allows packets other than H.323 to be provided a higher level of service. Any UDP protocol that utilizes ports above 1024 will interfere with the QoS for H.323. For example, L2TP, Quake, FileNet, CC:Mail, and pcAnywhere statistics all use UDP ports above 1024, and will interfere with video conferencing through the corporate QoS router, and may cause freeze frames, blue screens, audio dropouts, etc.

A Secure Flow Processing Solution
Now let's look at the impact an SFP engine can have on the router design. In this example, the SFP keeps track of information observed in all previous packets related to a flow. Figure 4 illustrates the content of a stateful QoS policy table to accomplish the same service level agreement utilizing a SFP.

One can immediately note the difference from the prior example. The QoS mappings no longer rely on uncertain conditions based on TCP or UDP port numbers. Instead, the QoS policy takes advantage of several key stateful result fields of the SFP. QoS mapping #1 accomplishes the same task as in the prior example. It assigns 'Guaranteed Bandwidth' priority to 'Internal User System' Q.931 packets. Note that the App. Protocol_Flag is used here to identify the application, rather than relying on a particular TCP port number.

The greatest advantage of SFP can be seen in QoS mappings #2 and #3. These mappings selectively pinpoint H.245, and more importantly, the RTP/RTCP media streams that were dynamically created during the course of each H.323 call, so the QoS policy can assign 'Guaranteed Bandwidth' and 'Real-Time' delivery priority through the QoS network.

Recall that without SFP the QoS policy was relegated to aggregate all inbound and outbound TCP and UDP traffic on all ports above 1024 to receive the higher classes of service. With SFP the QoS policy can rely on Parent_Flow_ID flag instead, and thus avoid mistakenly applying higher classes of service to unrelated applications. The Parent_Flow_ID flag allows the policy to statefully track the H.323 application.

When the SFP specifies non-zero Parent_Flow_ID in its result, it indicates that the packet belongs to a TCP connection or UDP stream which is related to a prior connection or stream. Recall that QoS mapping #1 assigned 'Guaranteed Bandwidth' class of service to 'Internal User System' Q.931 calls. The SFP analyzes the Q.931 messages, which negotiate ports for the H.245 dynamic connection. This allows the SFP to recognize the packets belonging to this specific H.245 connection and to produce results with non-zero Parent_Flow_ID, which contain the Flow_ID of the prior related Q.931 connection. This is how the QoS policy uses QoS mapping #2 to assign 'Guaranteed Bandwidth' class of service specifically to H.245 traffic related to 'Internal User System' initiated H.323 calls.

Similarly, the SFP engine analyzes H.245 messages, which negotiate UDP ports for dynamic media streams, which use RTP and RTCP protocols transported over UDP. This allows the SFP to recognize the packets belonging to these specific streams and to produce results with non-zero Parent_Flow_ID, which contain the Flow_ID of the prior related H.245 connection. The QoS policy uses QoS mapping #3 to assign 'Real-Time Delivery' specifically to the media streams related to 'Internal User System' H.323 calls.

Furthermore, the SFP recognizes when the H.323 control connections (Q.931 and H.245) close via TCP handshakes, TCP resets, or TCP timeouts and removes any state related to these connections and all related connections and streams. Thus, any 'late arrival packets will now produce results with Parent Flow ID set to zero which can now be assigned 'Best Effort' CoS by QoS mapping #4.

The audio and video streams of RTP/RTCP are particularly noteworthy, as they do not explicitly close, because UDP is connectionless. The RTP and RTCP packets are implicitly re-assigned to 'Best Effort' CoS after their parent flows (Q.931 and H.245) are closed. The QoS mapping #4 filters out any outbound traffic on any port not specifically advertised during the course of 'Internal User System' H.323 call, and assigns 'Best Effort' CoS.

Thus, the stateful QoS policy pinpoints the exact H.323 related traffic which to assign proper CoS, and accurately discriminates non-H.323 traffic, without degrading performance or increasing costs. In addition, the stateful QoS will automatically free resources used to buffer the 'Real Time Delivery' traffic when it detects that the related (parent flow) connections closed.

The SFP Advantage
At the core network, implementing SLAs by using queuing and scheduling within each router hop can be readily implemented at high speeds by aggregating packets by CoS using packet filtering technology. Routing engines utilize packet classifiers to implement traffic management decisions, one packet at a time (i.e. statelessly), as part of their packet processing.

However, at the edge, enforcing SLAs requires stateful SFP to accurately assign CoS to all traffic flowing through a network. Policy engines with the ability to analyze the entire application (which may consist of many inter-related connections) are required to provide enhanced QoS by analyzing all of today's complex, hierarchical applications to provide relational and stateful information to policy engines.

SFP provides several advantages over today's packet filtering QoS edge router solutions. These include:

1. SFP identifies all packets associated with each application enhancing the granularity and flexibility of the CoS assignment.
2. SFP allows volume traffic to be assigned CoS in the data plane at line speed.
3. SFP eliminates policy look-up latency for bulk of flow traffic.
4. SFP eliminates packet decode for processing.

SFP is a compute-intensive task, so implementing software on general-purpose processors cannot attain multi-Gbps performance ranges in an optimal manner. Implementing SFP in software will degrade edge routing performance, as this application specific classification requires considerable payload analysis, precise knowledge of how each application/protocol operates, and a stateful database in contrast to more general purpose slice and dice packet classification operations.

Another significant SFP performance advantage not yet discussed includes relieving the policy engine from having to perform a policy rule look-up on every packet. Since the SFP can associate every packet with a flow, and hence a policy, it can provide the QoS policy engine with the QoS mapping. That is, once the policy engine determines the QoS mapping for an application that starts up, the policy engine can program the SFP with the QoS mapping for future processing of packets.

After the first packet of a flow, the SFP not only identifies the application and flow ID, but also QoS mapping for every packet of every application. This capability enhances overall CoS assignment performance. Furthermore, since flow processors track hierarchal protocols, the QoS mapping table will be more compact and precise. This reduces the amount of memory accesses for QoS mapping look-up and the size of the memory used to store the QoS mapping table.

SFP also identifies and points to all IP and TCP/UDP headers in the packet, which may be used as criteria for QoS mapping. This may accelerate the QoS policy in assigning a QoS mapping.

About the Author
Robert Friend is a senior staff technologist at Hifn. He holds a patent for "switchable bus termination and address selector", and is an active member of the IETF, co-authoring the RFC1967, RFC1974, and RFC2395 specs, and contributing to RFC2118 and RFC3078 specifications. Robert received a BSEE from UCLA and can be reached at rfriend@hifn.com.