Introduction to QoS

The switch comes with a set of traffic management tools that you can use to provide QoS for Layer 2 (bridged) or Layer 3 (routed) traffic flows. Many of these flows are multiplexed across a set of network switches and compete for network resources at convergence points. Without traffic management, the congested data flows compete for resources and the result is unpredictable. The resulting QoS can only be described as best-effort. The opposite is also true, without congestion there are sufficient network resources for all traffic to pass without competition. Without congestion, traffic management is not required. In this sense, you cannot separate discussions about QoS and traffic management from those on congestion. The switch provides a set of tools that you can use to provide network services that are far superior to best-effort thereby enabling the delivery of provisioned QoS.

To deliver QoS, the switch uses two types of traffic management tools:
  • Congestion management

  • Congestion handling

Congestion management acts to prevent congestion by prioritizing traffic flows through priority queuing and priority-aware servicing methods. Other functions, such as policing, are also considered congestion management. Policing indirectly prioritizes some traffic by limiting the rates of other traffic.

Congestion handling alleviates existing congestion by dropping lower priority traffic before higher priority traffic. The switch handles the congestion by queue-specific tail dropping. The basic QoS architecture of the switch identifies three primary functional areas:

  • Ingress QoS identification and classification

  • the switch‘s internals and queuing architecture

  • QoS marking/remarking for downstream use

Important

Important

Remarking packets with an ACL filter does not change the internal QoS level of the packets. You must add the permit internal-qos [value] statement to the ACL filter.

The QoS architecture is coherent end-to-end across a network. The QoS at any particular network element can be marked in the relevant Layer 2 or Layer 3 protocol fields and provided to the next hop. The receiving next hop can then use this information to classify its own ingress traffic, apply its specific internal traffic management features, and remark the results for subsequent hops.

Depending on the product, the QoS implementation on the switch can support the following options:

  1. Ingress priority mappings including: DSCP to internal QoS, 802.1p-bits to internal QoS, and port-level QoS configuration.

  2. Egress priority mappings including: internal QoS to DSCP and internal QoS to 802.1p-bits.

  3. Port-based rate limiting or ingress policers

  4. Port-based broadcast and multicast rate limiting

  5. Port-based egress shaping

  6. Egress queue rate limiting

For information about feature support, see Fabric Engine Feature Support Matrix.

Traffic management

Prioritized traffic handling requires QoS classification first. The switch typically classifies traffic by using the endpoint switch configuration in conjunction with the protocol elements of the incoming frame such as priority. You can add additional classification by using access control lists (ACLs) and other filtering functionality.

The switch‘s internal traffic management functions use the results of classification to determine the prioritization of traffic. Examples of internal functions that prioritize traffic would be both strict and weighted round robin (WRR) queue scheduling. These mechanisms prioritize data by favorable scheduling or weighting.

The disposition of a particular data frame is not necessarily fully determined as a result of classification. You can apply additional traffic management functions such as Ingress Port Rate Limiting or Policing depending on your switch features. Ingress Port Rate Limiting is a congestion management mechanism to limit the traffic rate accepted by the specified ingress port. Policing is a congestion management method that limits incoming traffic at the ingress that could cause congestion at the egress. While queuing strategies affect prioritization by favoring some traffic; policing is essentially the opposite. Policing works not by favoring some traffic, but by penalizing the bursty traffic. Queue scheduling and policing are only two of the available tools for congestion management. Additional details are presented in subsequent sections of this document.

In addition to the traffic management tools which aid in the prevention of congestion, tools are also provided to handle congestion as it occurs. Congestion handling tools monitor congestion levels at convergence points in the switch and selectively discard frames if congestion begins to increase. Per queue tail dropping is the primary congestion handling function of the switch. You can also use ACLs and filtering as congestion handling tools.

Differentiated Services (DiffServ)

Table 1. Differentiated Services product support

Feature

Product

Release introduced

Differentiated Services (DiffServ) including Per-Hop Behavior

5320 Series

Fabric Engine 8.6

5420 Series

VOSS 8.4

5520 Series

VOSS 8.2.5

5720 Series

Fabric Engine 8.7

Differentiated Services (DiffServ) is a traffic management tool that classifies network traffic into eight traffic classes, and then gives each class differentiated treatment. DiffServ networks map the traffic‘s class into a set of packet forwarding behavior, referred to as a Per-Hop Behavior (PHB). A PHB could specify which egress queue to use. For example, a switch may classify a packet by determining its protocol to be IPv4, subsequently extract the DSCP value, and apply a PHB by directing the packet to a specific queue. DiffServ does not prescribe a set of traffic classes and does not predetermine which types of traffic should be handled by a given class. DiffServ simply provides a generic means of classifying packets so they may be treated differently.

DiffServ applies to IP packets only.

DiffServ Access and DiffServ Core

A fundamental characteristic of DiffServ networks is the distinction made between switches at the network edges and those residing in the network interior. The switch refers to this distinction as DiffServ Access (edge) and DiffServ Core (interior), respectively.

It is important to note that the switch operates simultaneously as both a DiffServ Access switch and a DiffServ Core switch. The architectural premise is that the edge or access nodes perform the bulk of the work (classification, policing, etc.) and mark the packet for downstream processing. In theory this would permit the interior or core switches to bypass much of the edge processing as they would “trust” the classification and marking performed by the access switch. The notion of trust is key to the access/core switch distinction.
  • If you configure a port as an access port, the system does not trust packet markings.

  • If you configure a port as a core port, the system trusts packet markings.

On the access side, malicious users can send packets into a network with intent to cause serious harm (e.g., denial of service attacks). However, on core switches, the only traffic sources are one‘s own upstream switches. As such, a core switch has the opportunity to trust the classification, markings (and implied PHB) determined by the previous hop.

The following figure shows DiffServ network operations. The devices are on the network edge where they perform classification, marking, policing, and shaping functions.

Click to expand in new window
DiffServ network core and edge devices

Use a DiffServ Access port at the edge of a DiffServ network. The access port classifies traffic according to port QoS. Outgoing packet DSCP and 802.1p values are derived from port QoS and QoS maps. The system strips Dot1Q headers at ingress, and adds them back at egress only if you configure the egress port as a tagged or trunk port.

A DiffServ Core port does not change packet classification or markings; the port trusts the incoming traffic markings. A core port preserves the DSCP marking of all incoming packets, and uses these markings to assign the packet to an internal QoS level. For tagged packets, the port honors the 802.1p bits within a Dot1Q header, and uses these bits to classify ingress traffic. You can control the honoring (or not) of 802.1p bits by configuring the 802.1p override.

Per-Hop Behavior (PHB)

Traffic entering the DiffServ network enter a queue according to their marking, which determines the PHB of the packets. For example, if the system marks a video stream to receive the highest priority, it enters a high-priority queue. As these packets traverse the DiffServ network, the system forwards the video stream before other packets.

As a standard, DiffServ is described in the context of Layer 3. Classification is accomplished by mapping a packet priority field from the packet and then applying a per-hop behavior. DiffServ standards define the IPv4 header‘s Differentiated Services Code Point (DSCP) field to determine classification and subsequent per-hop behavior.

The RFC2598 standard provides only the following four fundamental per-hop behaviors:

  • Default (DF) — This PHB provides best-effort forwarding behavior.

  • Expedited Forwarding (EF) — This PHB provides performance-critical forwarding.

  • Assured Forwarding (AF) — This PHB classifies traffic based upon class (priority) only.

    Important

    Important

    The switch never classifies nor takes action based upon drop precedence. In response to congestion, the only drops available for a given traffic class are tail drops.

  • Class Selector (CS) — This PHB provides a simple mapping of a DSCP to one of eight traffic classes. While the switch provides all four PHBs, the CS PHB is most analogous to the switch‘s internal processing – classification occurs to derive priority, which subsequently determine the per-hop behavior (e.g., queuing).

DiffServ and filters

QoS (DiffServ) and filters operate independently; you do not have to use filters to provide QoS. However, filters can override QoS operations. For more information, see Traffic filtering fundamentals.

Traffic traversing the switch

The switch‘s traffic management capabilities are best understood by examining the functionality that is invoked as packets flow from ingress ports, through the switch, to egress ports. The following list includes the set of features and processing that the switch performs as flows traverse the switch:
  • Classification and ingress mapping

  • Filtering

  • Rate Limiting or Policing

  • Queueing

  • Remarking

  • Shaping

The switch classifies packets to determine their priority. While DiffServ is traditionally defined as Layer 3 functionality, the switch extends the logical concept to Layer 2. The switch can, based upon user configuration, determine a packet‘s priority from either its Layer 2 (p-bits) or Layer 3 (DSCP) information.
  • If the packet arrives on an untrusted port (DiffServ Access), then the packet‘s priority comes from user-configured parameters such as port priority.

  • If the packet arrives on a trusted port, priority comes from information contained in the packet‘s header (p-bits or DSCP).

After the switch determines the packet‘s configured or marked priority, it maps that value to be used internally. The QoS level used by the switch is referred to as the Internal QoS Level (IQL). The IQL is the internal numerical value that the switch uses to determine the packets per-hop behaviors such as queue selection and bandwidth guarantee.

The following list identifies the order of DiffServ operations for a packet:
  • Packet classification: IEEE 802.1p and DSCP markings classify (map) the packet to its appropriate PHB and QoS level.

  • Remarking: The switch can remark packets according to QoS actions you configure on the switch (internal QoS mappings).

  • Shaping: The switch provides port-based shaping. Port-based shaping shapes all outgoing traffic to a specific rate.