This section describes the integration of SteelHeads into existing QoS architectures. This section includes the following topics:

When you integrate SteelHeads into your QoS architecture, you can:

You do not have to use all of the SteelHead functions on your optimized connections. You can selectively apply functions to different optimized traffic, based on attributes such as IP addresses, TCP ports, DSCP, VLAN tags, and payload.

When you integrate SteelHeads into an existing QoS architecture, it is helpful to understand how optimized and pass-through traffic appear to the WAN, or any WAN-side infrastructure. Figure 6‑13 shows how traffic appears on the WAN when SteelHeads are present.

When SteelHeads are present in a network:

For information about WAN visibility modes, see Overview of WAN Visibility.

This section provides examples of different QoS integration techniques, depending on the environment, as described in the following topics:

These examples assume that the post-integration goal is to treat optimized and nonoptimized traffic in the same manner with respect to QoS policies; you might want to allocate different network resources to optimized traffic.

For information about QoS marking, see QoS Marking.

In networks in which both classification or marking and enforcement are performed on traffic after it passes through the SteelHead, you have the following configuration options:

In some networks, QoS policies do not differentiate traffic that is optimized by the SteelHead. For example, because VoIP traffic is passed through the SteelHead, a QoS policy that gives priority to only VoIP traffic, without differentiating between non-VoIP traffic, is unaffected by the introduction of SteelHeads. In these networks, you do not need to make QoS configuration changes to maintain the existing policy, because the existing configuration treats all non-VoIP traffic identically, regardless of whether it is optimized by the SteelHead.

Another example of a network that might not require QoS configuration changes to integrate SteelHeads is where traffic is marked with DSCP or ToS values before reaching the SteelHead, and enforcement is made after reaching the SteelHeads based only on DSCP or ToS. The default SteelHead settings reflect the DSCP or ToS values from the LAN side to the WAN side of an optimized connection.

For example, you configure QoS by marking the DSCP values at the source or on LAN-side switches, and enforcement is performed on WAN routers, the WAN routers detect the same DSCP values for all classes of traffic, optimized or not.

You can mark or remark a packet with a different DSCP or ToS value as it enters the SteelHead. This remarking process is sometimes necessary because an end host can set an inappropriate DSCP value for traffic that might otherwise receive a lower priority. In this scenario, the QoS enforcement remains the responsibility of the WAN router.

Instead of enforcing the QoS policy on the WAN router, you can configure the SteelHead to enforce the QoS policy instead. However, Riverbed recommends that you also maintain a QoS policy on the WAN router to ensure that the traffic quality is guaranteed in the event that the SteelHead becomes unavailable.

This section describes how to use SteelHead QoS marking when integrating SteelHeads into an existing QoS architecture. This section includes the following topics:

SteelHeads can retain or alter the DSCP or IP ToS value of both pass-through traffic and optimized traffic. The DSCP or IP ToS values can be set in the QoS profile per QoS class and per QoS rule, or per application.

QoS reporting does not show any output if QoS marking is enabled without enabling QoS shaping. To get reporting for marked traffic, you must enable QoS shaping.

For example QoS marking configurations, see Configuring QoS Marking on SteelHeads.

By default, the setup of out-of-band control connections (OOB splice) are not marked with a DSCP value. If you are integrating a SteelHead into a network that provides multiple classes of service, SteelHead control traffic is classified into the default class. The default class is usually treated with the lowest priority. This traffic classification can lead to packet loss and high latency for SteelHead control traffic if the link is congested, which impacts optimization performance.

For optimized connections (inner channel), the client-side SteelHead sets a configured DSCP value from the very start of the connection, according to the first fully matching QoS rule. Riverbed Application Flow Engine (AFE) cannot classify traffic on the first packets (TCP handshake), so only QoS rules based on the IP protocol header (IP address, TCP port number, UDP port number, and so on) match on the first packet (TCP SYN). On the server-side SteelHead, the DSCP marking value seen on the TCP SYN packet is reflected onto the TCP SYN-ACK packet, so the packets of the TCP session setup (TCP handshake) are correctly marked with the configured DSCP.

For more information about AFE, see Application Flow Engine.

In versions of RiOS prior to v9.1, the Global DSCP feature was used to set a DSCP value to the first packets of a session (TCP handshake), which is no longer needed. For more information about Global DSCP, refer to an earlier version of the SteelHead Deployment Guide.

If your existing network provides multiple classes of service based on DSCP values, and you are integrating a SteelHead into your environment, you can use the out-of-band (OOB) DSCP marking feature to prevent dropped packets and other undesired effects for SteelHeads control traffic.

The OOB DSCP marking feature enables you to explicitly set a DSCP value for the control channel between SteelHeads (OOB splice).

To configure OOB DSCP marking, create a new rule in the QoS profile in use, which is based on the Riverbed control traffic application group, and configure the desired DSCP value.

If you want to set a DSCP value for only one direction, choose either the Riverbed Control Traffic (Client) or Riverbed Control Traffic (Server) application.

For more information about how to configure OOB DSCP marking, see the SteelHead Management Console User’s Guide.

By default, SteelHeads reflects the DSCP or IP ToS value found on pass-through traffic and optimized connections. The default value for DSCP or IP ToS are set to:

By default, the DSCP or IP ToS value on pass-through or optimized traffic is unchanged when it passes through the SteelHead.

If a DSCP or IP ToS value is set for certain traffic, this value is only significant for the SteelHead on which it is configured. Another SteelHead on the same network may set the DSCP or IP ToS value differently.

Figure 6‑15 shows the local significance of DSCP or IP ToS values.

Consider the following when using QoS marking: