Cisco Introduction Ip Qos (course)
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Cisco Introduction Ip Qos (course) as PDF for free.
More details
- Words: 138,008
- Pages: 850
Introduction
Overview The module presents a thorough overview of quality of service models and mechanisms as implemented in complex service provider and enterprise networks. It includes the following topics: n
Introduction to IP Quality of Service
n
Integrated Services Model
n
Differentiated Services Model
n
Building Blocks of IP QoS Mechanisms
n
Enterprise Network Case Study
n
Service Provider Case Study
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe the need for IP QoS
n
Describe the Integrated Services model
n
Describe the Differentiated Services model
n
Describe the building blocks of IP QoS mechanisms (classification, marking, metering, policing, shaping, dropping, forwarding, queuing)
n
List the IP QoS mechanisms available in the Cisco IOS
n
Describe what QoS features are supported by different IP QoS mechanisms
Introduction to IP Quality of Service Objectives Upon completion of this lesson, you will be able to perform the following tasks:
2
IP QoS Introduction
n
Describe different types of applications and services that have special resource requirements
n
List the network components that affect the throughput, delay and jitter in IP networks
n
List the benefits of deploying QoS mechanisms in IP networks
n
List QoS mechanisms available in Cisco IOS
n
Describe typical enterprise and service provider networks and their QoS-related requirements
Copyright 2001, Cisco Systems, Inc.
Why IP QoS? • Application X is slow! • Video broadcast occasionally stalls! • Phone calls over IP are no better than over satellite! • Phone calls have really bad voice quality! • ATM (the money-dispensing-type) are nonresponsive! • ...
© 2001, Cisco Systems, Inc.
IP QoS Introduction-5
The purpose of this module is to determine the following: n
What is, or might be, missing in today’s IP networks?
n
What can IP Quality of Service (QoS) do to help solve the problem?
A decade ago when the Internet was still in its early stages there was not much available. Most users were using Gopher to find information and FTP to retrieve it. The Internet was something new and exciting and no one was really bothered by the fact that it was slow. Today, however, the Internet is serving a large population of all walks of life. The Internet has also grown in its service offering. Users are using the Internet to view static or dynamic information, transmit voice and video, shop, play etc. Along with these new applications of the Internet come some demands on the service(s) it provides: n
Some applications are slow
n
Video broadcast or conferencing may have bad picture quality or appear jerky
n
Voice sessions may have bad voice quality or periods of silence
n
Critical transactions may take too long (too many seconds)
n
Bulk transfers take too long (too many hours)
This module focuses on most common quality-related problems people encounter in IP networks.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
3
Because ... • Application X is slow! (not enough BANDWIDTH) • Video broadcast occasionally stalls! (DELAY temporarily increases – JITTER) • Phone calls over IP are no better than over satellite! (too much DELAY) • Phone calls have really bad voice quality! (too many phone calls – ADMISSION CONTROL) • ATM (the money-dispensing-type) are non responsive! (too many DROPs) • ...
© 2001, Cisco Systems, Inc.
IP QoS Introduction-6
Quality of Service is usually identified by the following parameters:
4
IP QoS Introduction
n
Amount of bandwidth available to a certain application or user
n
Average delay experienced by IP packets on end-to-end or link basis
n
Jitter that affects applications that transmit packets at a certain fixed rate and expect to receive them at approximately the same rate (for example, voice and video)
n
Drops of packets when a link is congested can severely impact fragile applications
n
Admission control which prevents too many sessions from congesting links and causing degradation in quality of service (for example, voice sessions)
Copyright 2001, Cisco Systems, Inc.
What Causes ... • Lack of bandwidth – multiple flows are contesting for a limited amount of bandwidth • Too much delay – packets have to traverse many network devices and links that add up to the overall delay • Variable delay – sometimes there is a lot of other traffic which results in more delay • Drops – packets have to be dropped when a link is congested
© 2001, Cisco Systems, Inc.
IP QoS Introduction-7
If the network is empty any application should get enough bandwidth, acceptable low and fixed delay and not experience any drops. The reality, however, is that there are multiple users or applications using the network at the same time.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
5
Available Bandwidth
IP
IP
256 kbps 10 Mbps
IP
IP
512 kbps 100 Mbps
BW max = min(10M, 256k, 512k, 100M)=256kbps BW avail = BWmax /Flows • Maximum available bandwidth equals the bandwidth of the weakest link • Multiple flows are contesting for the same bandwidth resulting in much less bandwidth being available to one single application. © 2001, Cisco Systems, Inc.
IP QoS Introduction-8
The example above illustrates an empty network with four hops between a server and a client. Each hop is using different media with a different bandwidth. The maximum available bandwidth is equal to the bandwidth of the slowest link. The calculation of the available bandwidth, however, is much more complex in cases where there are multiple flows traversing the network. The calculation of the available bandwidth in the illustration is a rough approximation.
6
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
End-to-end Delay
IP
IP
Propagation delay (P1) Processing and queuing delay (Q1)
Propagation delay (P2) Processing and queuing delay (Q2)
IP
IP
Propagation delay (P3)
Propagation delay (P4)
Processing and queuing delay (Q3)
Delay = P1 + Q1 + P2 + Q2 + P3 + Q3 + P4 = X ms
• End-to-end delay equals a sum of all propagation, processing and queuing delays in the path • Propagation delay is fixed, processing and queuing delays are unpredictable in best-effort networks © 2001, Cisco Systems, Inc.
IP QoS Introduction-9
The figure illustrates the impact a network has on the end-to-end delay of packets going from one end to the other. Each hop in the network adds to the overall delay because of the following two factors: 1. Propagation (serialization) delay of the media that, for the most part, depends solely on the bandwidth. 2. Processing and queuing delays within a router, which can be caused by a wide variety of conditions. Ping (ICMP echoes and replies) can be used to measure the round-trip time of IP packets in a network. There are other tools available to periodically measure responsiveness of a network.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
7
Processing and Queuing Delay
IP
IP
Processing Delay
IP
bandwidth
Forwarding
IP
Queuing Delay Propagation Delay
• Processing Delay is the time it takes for a router to take the packet from an input interface and put it into the output queue of the output interface. • Queuing Delay is the time a packets resides in the output queue of a router. • Propagation or Serialization Delay is the time it takes to transmit a packet.
© 2001, Cisco Systems, Inc.
n
8
IP QoS Introduction
IP QoS Introduction-10
Processing Delay is the time it takes for a router to take the packet from an input interface and put it into the output queue of the output interface. The processing delay depends on various factors, such as: –
CPU speed
–
CPU utilization
–
IP switching mode
–
Router architecture
–
Configured features on both input and output interface
n
Queuing Delay is the time a packet resides in the output queue of a router. It depends on the number and sizes of packets already in the queue and on the bandwidth of the interface. It also depends on the queuing mechanism.
n
Propagation or Serialization Delay is the time it takes to transmit a packet. It usually only depends on the bandwidth of the interface. CSMA/CD media may add slightly more delay due to the increased probability of collisions when an interface is nearing congestion.
Copyright 2001, Cisco Systems, Inc.
Packet Loss
Forwarding
IP
IP
IP
IP
IP
Tail-drop
• Tail-drops occur when the output queue is full. These are the most common drops which happen when a link is congested. • There are also many other types of drops that are not as common and may require a hardware upgrade (input drop, ignore, overrun, no buffer, ...). These drops are usually a result of router congestion. © 2001, Cisco Systems, Inc.
IP QoS Introduction-11
The usual packet loss occurs when routers run out of buffer space for a particular interface (output queue). The figure illustrates a full output queue of an interface, which causes newly arriving packets to be dropped. The term used for such drops is simply “output drop” or “tail-drop” (packets are dropped at the tail of the queue). Routers might also drop packets for other (less common) reasons, for example: n
Input queue drop - main CPU is congested and cannot process packets (the input queue is full)
n
Ignore - router ran out of buffer space
n
Overrun - CPU is congested and cannot assign a free buffer to the new packet
n
Frame errors (CRC, runt, giant)—hardware-detected error in a frame
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
9
How to Increase Available Bandwidth? TCP Header Compression RTP Header Compression cTCP data
Compress the Headers IP
TCP
Fancy FIFO queuing queuing
data Compress the Payload
Compressed packet
Stacker Predictor
Priority Queuing (PQ) Custom Queuing (CQ) Modified Deficit Round Robin (MDRR) Class-based Weighted Fair Queing (CB-WFQ)
• Upgrade the link. The best solution but also the most expensive. • Take some bandwidth from less important applications. • Compress the payload of layer-2 frames. • Compress the header of IP packets. © 2001, Cisco Systems, Inc.
IP QoS Introduction-12
There are several approaches to solving a problem of insufficient bandwidth:
10
IP QoS Introduction
n
The best approach is to increase the link capacity to accommodate all applications and users with some extra bandwidth to spare. This solution sounds simple enough but in the real world it brings a high cost in terms of the money and time it takes to implement. Very often there are also technological limitations to upgrading to a higher bandwidth.
n
Another option is to classify traffic into QoS classes and prioritize it according to importance (business-critical traffic should get enough bandwidth, voice should get enough bandwidth and prioritized forwarding and the least important traffic should get the remaining bandwidth). There are a wide variety of mechanisms available in the Cisco IOS that provide bandwidth guarantees, for example: –
Priority or Custom Queuing
–
Modified Deficit Round Robin (on Cisco 12000 series routers)
–
Distributed ToS-based and QoS-group-based Weighted Fair Queuing (on Cisco 7x00 series routers)
–
Class-based Weighted Fair Queuing
n
Optimizing link usage by compressing the payload of frames (virtually) increases the link bandwidth. Compression, on the other hand, also increases delay due to complexity of compression algorithms. Using hardware compression can accelerate the compression of packet payloads. Stacker and Predictor are two compression algorithms available in Cisco IOS.
n
Another link efficiency mechanism is header compression. This mechanism is especially effective in networks where most packets carry small amounts of
Copyright 2001, Cisco Systems, Inc.
data (payload-to-header ratio is small). Typical examples of header compression are TCP Header Compression and RTP Header Compression.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
11
How to Reduce Delay? TCP Header Compression RTP Header Compression cRTP data
Compress the Headers IP
UDP RTP
Fancy FIFO queuing queuing
data
Compress the Payload
Compressed packet
Stacker Predictor
Priority Queuing (PQ) Custom Queuing (CQ) Strict Priority MDRR IP RTP prioritization Class-based Low-latency Queuing (CB-LLQ)
• Upgrade the link. The best solution but also the most expensive. • Forward the important packets first. • Compress the payload of layer-2 frames (it takes time). • Compress the header of IP packets. © 2001, Cisco Systems, Inc.
IP QoS Introduction-13
Assuming that a router is powerful enough to make a forwarding decision in a negligible time it can be said that most of the processing, queuing delay and propagation delay is influenced by the following factors: n
Average length of the queue
n
Average length of packets in the queue
n
Link bandwidth
There are several approaches to accelerate packet dispatching of delay-sensitive flows:
12
IP QoS Introduction
n
Increase link capacity. Enough bandwidth causes queues to shrink, making sure packets do not have to wait long before they can be transmitted. Additionally, more bandwidth reduces serialization time. On the other hand, this might be an unrealistic approach due to the costs associated with the upgrade.
n
A more cost-effective approach is to enable a queuing mechanism that can give priority to delay-sensitive packets by forwarding them ahead of other packets. There are a wide variety of queuing mechanisms available in Cisco IOS that have pre-emptive queuing capabilities, for example: –
Priority Queuing
–
Custom Queuing
–
Strict-priority or Alternate Priority queuing within the Modified Deficit Round Robin (on Cisco 12000 series routers)
–
IP RTP prioritization
–
Class-based Low-latency Queuing
Copyright 2001, Cisco Systems, Inc.
n
Payload compression reduces the size of packets and, therefore, virtually increases link bandwidth. Additionally, compressed packets are smaller and need less time to be transmitted. On the other hand, compression uses complex algorithms that take time and add to the delay. This approach is, therefore, not used to provide low-delay propagation of packets.
n
Header compression on the other hand is not as CPU-intensive and can be used in combination with other mechanisms to reduce delay. It is especially useful for voice packets that have a bad payload-to-header ratio, which is improved by reducing the header of the packet (RTP header compression).
By minimizing delay, jitter is also reduced (delay is more predictable).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
13
How to Prevent Packet Loss?
Weighted Random Early Detection (WRED)
IP
data
Dropper
Fancy FIFO queuing queuing
Custom Queuing (CQ) Modified Deficit Round Robin (MDRR) Class -based Weighted Fair Queuing (CB-WFQ)
• Upgrade the link. The best solution but also the most expensive. • Guarantee enough bandwidth to sensitive packets. • Prevent congestion by randomly dropping less important packets before congestion occurs © 2001, Cisco Systems, Inc.
IP QoS Introduction-14
Packet loss is usually a result of congestion on an interface. Most applications that use TCP experience slow down due to TCP adjusting to the network’s resources (dropped TCP segments cause TCP sessions to reduce their window sizes). There are some other applications that do not use TCP and cannot handle drops (fragile flows). The following approaches can be taken to prevent drops of sensitive applications: n
Increased link capacity to ease or prevent congestion.
n
Guarantee enough bandwidth and increase buffer space to accommodate bursts of fragile applications. There are several mechanisms available in Cisco IOS that can guarantee bandwidth and/or provide prioritized forwarding to dropsensitive applications, for example:
n
–
Priority Queuing
–
Custom Queuing
–
Modified Deficit Round Robin (on Cisco 12000 series routers)
–
IP RTP prioritization
–
Class-based Weighted Fair Queuing
–
Class-based Low-latency Queuing
Prevent congestion by dropping other packets before congestion occurs. Weighted Random Early Detection can be used to start dropping other packets before congestion occurs.
There are some other mechanisms that can also be used to prevent congestion: n
14
IP QoS Introduction
Traffic Shaping delays packets instead of dropping them (Generic Traffic Shaping, Frame Relay Traffic Shaping and Class-based Shaping). Copyright 2001, Cisco Systems, Inc.
n
Traffic Policing can limit the rate of less important packets to provide better service to drop-sensitive packets (Committed Access Rate and Class-based Policing).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
15
Which Applications Have Which QoS Requirements? Throughput
Delay
Loss Loss
Jitter
Interactive (e.g. Telnet)
Low
Low
Low
Not Important
Batch (e.g. FTP)
High High
Not Important
Low
Not Important
Fragile (e.g. SNA)
Low
Low
None
Not Important
Voice
Low
Low and Predictable
Low
Low
Video
High High
Low and Predictable
Low
Low
• Enterprise networks are typically focused on providing QoS to applications © 2001, Cisco Systems, Inc.
IP QoS Introduction-15
When QoS is considered in a network implementation, important applications and their QoS requirements have to be identified. The figure illustrates a table of different types of applications with the corresponding QoS requirements (throughput or bandwidth, delay, loss and jitter). Once the applications are identified and prioritized it must be decided which QoS mechanisms are to be put in place. The approach to provide QoS to applications is usually used in Enterprise Networks where important (business-critical) applications are easy to identify. Most applications can be classified based on TCP or UDP port numbers. Some applications use dynamic port numbers that, somewhat, makes classification more difficult. Cisco IOS supports Network-based Application Recognition (NBAR), which can be used for such application.
16
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Which Services can be Implemented in a Network? Throughput
Delay
Loss Loss
Jitter
Gold
Guaranteed
Low
Low
Low
Silver Silver
Guaranteed
No Guarantee
No Guarantee
No Guarantee
Bronze
Guaranteed Limitted
No Guarantee
No Guarantee
No Guarantee
Best Effort
No Guarantee
No Guarantee
No Guarantee
No Guarantee
. . ..
. . ..
. . ..
. . ..
...
• Service provider networks typically offer services based on source and destination addresses © 2001, Cisco Systems, Inc.
IP QoS Introduction-16
Service providers, on the other hand, are there to provide connectivity to customers. They typically are not concerned with the applications that customers are using. They are, however, interested in providing different levels of services to customers. Some customers are willing to pay more for their connectivity to the Internet, providing they obtain some guarantees. The figure illustrates one of the many different approaches to defining services. In reality, each service provider creates its own list of services according to market research and competitive needs. Cisco IOS is simply the tool used to implement those services.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
17
How can QoS be Applied? • Best effort – no QoS is applied to packets (default behavior) • Integrated Services model – applications signal to the network that they require special QoS • Differentiated Services model – the network recognizes classes that requires special QoS
© 2001, Cisco Systems, Inc.
IP QoS Introduction-17
By investigating the history of the Internet it can be divided into three QoS-related periods: n
Best-effort. The Internet was designed for best-effort, no-guarantee delivery of packets. This behavior is still predominant in today’s Internet.
n
Integrated Services model. Introduced to supplement the best-effort delivery by setting aside some bandwidth for applications that require bandwidth and delay guarantees. The Integrated Services model expects applications to signal their requirements to the network. Resource Reservation Protocol (RSVP) is used to signal QoS requirements to the network.
n
Differentiated Services model. Added to provide more scalability in providing QoS to IP packets. The main difference is that the network recognizes packets (no signaling is needed) and provides the appropriate services to them.
Today’s IP networks can use all three models at the same time.
18
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Summary IP Quality of Service is used to improve performance of IP networks. Quality of Service can be measured based on available bandwidth, end-to-end delay, packet loss and jitter. Different QoS mechanisms can be used to provide a predictable service. There are many different types of QoS mechanisms available in the Cisco IOS: n
Queuing mechanisms: Priority Queuing (PQ), Custom Queuing (CQ), Weighted Fair Queuing (WFQ) with its distributed versions, IP RTP Prioritization, Modified Deficit Round Robin (MDRR), Class-based Weighted Fair Queuing (CB-WFQ) and Class-based Low-latency Queuing (CB-LLQ)
n
Traffic Shaping mechanisms: Generic Traffic Shaping (GTS), Frame Relay Traffic Shaping (FRTS) and Class-based Shaping
n
Traffic Policing mechanisms: Committed Access Rate (CAR) and Classbased Policing
n
Dropping mechanisms: Weighted Random Early Detection (WRED)
n
Link Efficiency mechanisms: Stacker, Predictor, TCP Header Compression and RTP Header Compression
n
Signaling mechanism: Resource Reservation Protocol (RSVP)
Review Questions Answer the following questions: n
What are the relevant parameters that define the quality of service?
n
What can be done to give more bandwidth to an application?
n
What can be done to reduce delay?
n
What can be done to prevent packet loss?
n
Name the three QoS models?
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
19
Integrated Services Model Objectives Upon completion of this lesson, you will be able to perform the following tasks:
20
IP QoS Introduction
n
Describe the IntServ model
n
List the key benefits and drawbacks of the IntServ model
n
List some implementations that are based on the IntServ model
n
Describe the need for Common Open Policy Service (COPS)
Copyright 2001, Cisco Systems, Inc.
Integrated Services • The Internet was initially based on a besteffort packet delivery service • Today's Internet carries many more different applications than 20 years ago • Some applications have special bandwidth and/or delay requirements • The Integrated Services model (RFC1633) was introduced to guarantee a predictable behavior of the network for these applications
© 2001, Cisco Systems, Inc.
IP QoS Introduction-22
The Internet Engineering Task Force (IETF) is responsible for standardization of the Internet and most of the protocols used in the Internet. When faced with a challenge, vendors introduce their own solutions. However, the IETF is there to create standards that allow different vendor’s equipment to interoperate. One of the challenges in the past was to introduce Quality of Service into the best-effort driven Internet. The Integrated Services (IntServ) model was proposed as standard with Resource Reservation Protocol (RSVP) as the mechanism used to signal QoS requirements to the network. The IntServ model is described in the RFC 1633 (http://www.ietf.org/rfc/rfc1633.txt). The use of RSVP for Integrated Services is described in RFC 2210 (http://www.ie tf.org/rfc/rfc2210.txt).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
21
IntServ Building Blocks Local Admission Control request
request
reserve
Policy Enforcement Point (PEP) request
reserve
Local Admission Control request
reserve
reply
request
reserve
Remote Admission Control
Policy Decision Point (PDP)
• Resource Reservation is used to identify an application (flow) and signal if there are enough available resources for it • Admission Control is used to determine if the application (flow) can get the requested resources © 2001, Cisco Systems, Inc.
IP QoS Introduction-23
The IntServ model itself describes the application of QoS in IP networks. Additional standards were developed to cover the exact protocols used to implement Quality of Service: n
Resource Reservation is implemented using the Resource Reservation Protocol (RSVP)
n
Admission Control is either implemented locally on the routers or offloaded to central servers
Common Open Policy Service (COPS) is another IETF standard that defines a protocol that can be used for policy exchange between network devices (Policy Enforcement Point or PEP) and policy servers (Policy Decision Point or PDP). An additional standard was added to integrate RSVP with COPS. The COPS (Common Open Policy Service) Protocol is defined in RFC 2748 (http://www.rfc-editor.org/rfc/rfc2748.txt). COPS usage for RSVP is defined in RFC 2749 (http://www.rfc-editor.org/rfc/rfc2749.txt).
22
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Reservation and Admission Protocols • The resource ReSerVation Protocol (RSVP) was developed to communicate resource needs between hosts and network devices (RFC 2205-2215) • Common Open Policy Service (COPS) was developed to offload admission control to a central policy server (RFC 2748-2753)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-24
Following is a list of some of the IETF standards (RFCs) that describe RSVP, COPS, the IntServ model and applications: n
Resource ReSerVation Protocol (RSVP), Version 1, Functional Specification (http://www.ietf.org/rfc/rfc2205.txt)
n
RSVP Management Information Base using SMIv2 (http://www.ietf.org/rfc/rfc2206.txt)
n
RSVP Extensions for IPSEC Data Flows (http://www.ietf.org/rfc/rfc2207.txt)
n
Resource ReSerVation Protocol (RSVP), Version 1, Applicability Statement, Some Guidelines on Deployment (http://www.ietf.org/rfc/rfc2208.txt)
n
Resource ReSerVation Protocol (RSVP), Version 1, Message Processing Rules (http://www.ietf.org/rfc/rfc2209.txt)
n
The Use of RSVP with IETF Integrated Services (http://www.ietf.org/rfc/rfc2210.txt)
n
Specification of the Controlled-Load Network Element Service (http://www.ietf.org/rfc/rfc2211.txt)
n
Specification of Guaranteed Quality of Service (http://www.ietf.org/rfc/rfc2212.txt)
n
Integrated Services Management Information Base using SMIv2 (http://www.ietf.org/rfc/rfc2213.txt)
n
Integrated Services Management Information Base, Guaranteed Service Extensions using SMIv2 (http://www.ietf.org/rfc/rfc2214.txt)
n
General Characterization Parameters for Integrated Service Network Elements (http://www.ietf.org/rfc/rfc2215.txt)
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
23
24
IP QoS Introduction
n
The COPS (Common Open Policy Service) Protocol (http://www.ietf.org/rfc/rfc2748.txt)
n
COPS usage for RSVP (http://www.ietf.org/rfc/rfc2749.txt)
n
RSVP Extensions for Policy Control (http://www.ietf.org/rfc/rfc2750.txt)
n
Signaled Preemption Priority Policy Element (http://www.ietf.org/rfc/rfc2751.txt)
n
Identity Representation for RSVP (http://www.ietf.org/rfc/rfc2752.txt)
n
A Framework for Policy-based Admission Control (http://www.ie tf.org/rfc/rfc2753.txt)
n
SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks (http://www.ietf.org/rfc/rfc2814.txt)
n
Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients (http://www.ietf.org/rfc/rfc2940.txt)
n
COPS Usage for Policy Provisioning (COPS-PR) (http://www.ietf.org/rfc/rfc3084.txt)
Copyright 2001, Cisco Systems, Inc.
RSVP-enabled Applications • RSVP is typically used by applications carrying voice or video over IP networks (initiated by a host) • RSVP with extensions is also used by MPLS Traffic Engineering to establish MPLS/TE tunnels (initiated by a router)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-25
RSVP, as a resource reservation protocol, was designed for use by end devices in networks (for example, personal computers and servers). It is a protocol that has to be supported by an application that requires network resources and needs guarantees. n
Typical examples of applications that would benefit from RSVP are voice sessions that require a small amount of bandwidth with low-delay propagation.
n
Cisco routers that act as voice gateways can use RSVP to request resources (controlled-load and guaranteed-delay).
n
Cisco routers that use Multiprotocol Label Switching (MPLS) Traffic Engineering (MPLS/TE) use RSVP with extensions to reserve bandwidth and set up MPLS/TE tunnels through MPLS and RSVP enabled networks.
n
Cisco Soft Phone or Microsoft NetMeeting are Windows applications that use RSVP to get resources for their VoIP sessions.
There are an increasing number of applications that use RSVP to request QoS guarantees from a network.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
25
IntServ Implementation Options RSVP
1) Explicit RSVP on each network node
Class of Service or Best Effort 2) RSVP ‘pass -through’ and CoS transport - map RSVP to CoS at network edge - pass -through RSVP request to egress 3) RSVP at network edges and ‘pass -through’ with - best-effort forwarding in the core (if there is enough bandwidth in the core)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-26
The figure illustrates three options available when implementing QoS mechanisms via RSVP in a network. 1. The first option is to simply enable RSVP on all interfaces of all the routers in the network. This approach is mainly used in enterprise networks that have more predictable RSVP flows (in terms of quantity and direction because they typically use hub-and-spoke topology). Large service provider networks are less inclined to use RSVP throughout their networks either because RSVP would require too many concurrent reservations on a single interface or because the routers are not capable of providing guarantees to individual flows on high-bandwidth interfaces. 2. An alternative option is to use RSVP on network edges where there is typically less bandwidth per interface and congestion is more likely. The edgeto-core routers (for example, access or distribution layer routers) mark RSVP flows with IP markers, which can then be used in a DiffServ enabled core— the Differentiated Services model is covered in the next lesson). 3. Another option is to use RSVP on network edges and rely on best-effort delivery in a non-congested core.
26
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Explicit RSVP Transport IntServ End-to-End RSVP
All Routers • WFQ applied per flow based on RSVP requests
© 2001, Cisco Systems, Inc.
IP QoS Introduction-27
In the first scenario, each router in the network processes RSVP messages and keeps track of the special resource needs for each individual RSVP flow. Weighted Fair Queuing (WFQ) can be used in the backbone to provide resource allocation on a flow-by-flow basis. One concern with this approach is that RSVP is resource intensive on backbone routers - in terms of the amount of signaling and the amount of special information that they need to keep on each RSVP flow. A second issue is that WFQ is a very CPU-intensive algorithm and does not run at high speed on today’s routers. In the backbone, high speed is a mandatory requirement.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
27
RSVP Pass-Through IntServ - DiffServ Integration RSVP
RSVP
Precedence Classifier
Premium Standard
WRED
• RSVP protocol sent on to destination • WFQ applied to manage egress flow
Ingress Router • RSVP protocol Mapped to classes Passed through to egress
Egress Router
Backbone • WRED applied based on class
© 2001, Cisco Systems, Inc.
IP QoS Introduction-28
An alternative to enabling RSVP end-to-end is to use RSVP as a means to signal special requirements between the customer and the ISP edge, but not to use it in the backbone. In this model, packets are mapped on RSVP flows into special service classes which give each class preferential treatment in the core of the network when congestion occurs. This avoids the scalability problem of end-to-end RSVP, since these flows are processed between the end station and the network edge and not in the middle of the backbone. By using WRED on routers, instead of WFQ, much higher speeds can be supported. Alternatively, Class-based WFQ can be used on moderate-speed links to provide better control of bandwidth allocation. The third option is not to use RSVP in the core and rely on best-effort delivery if the core is not congested. Lastly, mapping classes of service to ATM is more straightforward than mapping RSVP directly to ATM. This concept may accelerate the ability of ISPs to offer an RSVP service and enable new application areas.
28
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
IntServ Support in IOS • RSVP and Weighted Fair Queuing supported since ’95 • RSVP signaling for VoIP calls supported on all VoIP platforms • IOS supports hop-by-hop and pass-through RSVP • RSVP-to-DSCP (DiffServ Code Point) mapping (RSVP proxy) in 12.1T
© 2001, Cisco Systems, Inc.
IP QoS Introduction-29
Both RSVP and WFQ have been available for some time and can be used on all low-end platforms and on high-end platforms that are typically used to concentrate customer networks. Newer RSVP mechanisms include: n
Mapping of RSVP to DSCP (the Differentiated Services model with the details of the DiffServ Code point is covered in the next lesson).
n
Mapping of RSVP to ATM SVCs (this technology is covered in the “IP QoS IP over ATM” module).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
29
Benefits and Drawbacks of the IntServ Model + RSVP benefits: • Explicit resource admission control (end to end) • Per-request policy admission control (authorization object, policy object) • Signaling of dynamic port numbers (for example, H.323)
–RSVP drawbacks: • Continuous signaling due to stateless architecture • Not scalable
© 2001, Cisco Systems, Inc.
IP QoS Introduction-30
The main benefits of RSVP are: n
It signals QoS requests per individual flow. The network can then provide guarantees to these individual flows. The problem of this is that it does not scale to large networks because of the large numbers of concurrent RSVP flows.
n
It informs network devices of flow parameters (IP addresses and port numbers). Some applications use dynamic port numbers, which can be difficult for network devices to recognize. NBAR is a mechanism that has been introduced to supplement RSVP for applications that use dynamic port numbers but do not use RSVP.
It supports admission control that allows a network to reject (or down-grade) new RSVP sessions if one of the interfaces in the path has reached the limit (all reservable bandwidth is booked). The main drawbacks of RSVP are:
30
IP QoS Introduction
n
Continuous signaling due to stateless operation of RSVP.
n
RSVP is not scalable to large networks where per-flow guarantees would have to be made to thousands of flows.
Copyright 2001, Cisco Systems, Inc.
Common Open Policy Service • Common Open Policy Service (COPS) provides the following benefits when used with RSVP: – Centralized management of services – Centralized admission control and authorization of RSVP flows
• RSVP-based QoS solutions become more scalable
© 2001, Cisco Systems, Inc.
IP QoS Introduction-31
The Common Open Policy Service (COPS) is an add-on to RSVP. It can be used to offload certain tasks from network devices to a central server. The result is that the configuration of individual devices is more standardized (template-based) and all individual parameters are managed from a centralized location. In addition, COPS supports admission control of individual flows (the network device determines the available resources and the central server authorizes the flow).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
31
Summary The Integrated Services (IntServ) model was introduced to allow vendors of routers to add interoperable QoS mechanisms to their best-effort packet forwarding. Resource Reservation Protocol (RSVP) is used by end-devices to signal QoS requirements to the network. Common Open Policy Service (COPS) is used to offload policy management to central servers.
Review Questions Answer the following questions:
32
IP QoS Introduction
n
What are the two building blocks of the Integrated Services model?
n
Which protocol is used to signal QoS requirements to the network?
Copyright 2001, Cisco Systems, Inc.
Differentiated Services Model Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe the DiffServ model
n
List the key benefits of the DiffServ model compared to the IntServ model
n
Describe the purpose of the DS field in IP headers
n
Describe the interoperability between DSCP-based and IP-precedence-based devices in a network
n
Describe the Expedited Forwarding service
n
Describe the Assured Forwarding service
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
33
Differentiated Services Model • Differentiated Services model describes services associated with traffic classes • Complex traffic classification and conditioning is performed at network edge resulting in a per-packet Differentiated Services Code Point (DSCP). • No per-flow/per-application state in the core • Core only performs simple ‘per-hop behavior's’ on traffic aggregates • Goal is Scalability © 2001, Cisco Systems, Inc.
IP QoS Introduction-36
The Differentiated Services (DiffServ) model describes services associated with traffic classes. Traffic classes are identified by the value of the DiffServ Code Point (DSCP replaces IP precedence in the ToS field of the IP header). The main goals of the DiffServ model are to provide scalability and a similar level of QoS to the IntServ model, without having to do it on a per-flow basis. The network simply identifies a class (not application) and applies the appropriate perhop behavior (QoS mechanism). The DiffServ model and associated standards are described in the following IETF standardization documents (RFCs):
34
IP QoS Introduction
n
An Architecture for Differentiated Services (http://www.ietf.org/rfc/rfc2475.txt)
n
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (http://www.ietf.org/rfc/rfc2474.txt)
n
Assured Forwarding per-hop behavior (PHB) Group (http://www.ietf.org/rfc/rfc2597.txt)
n
An Expedited Forwarding per-hop behavior (PHB) (http://www.ietf.org/rfc/rfc2598.txt)
Copyright 2001, Cisco Systems, Inc.
Additional Requirements • Wide variety of services and provisioning policies • Decouple service and application in use • No application modification • No hop-by-hop signaling • Interoperability with non-DS-compliant nodes • Incremental deployment
© 2001, Cisco Systems, Inc.
IP QoS Introduction-37
The DiffServ model describes services and allows for more user-defined services to be used in a DiffServ-enabled network. Services are provided to classes. A class can be identified as a single application or, as in most cases, it can be identified based on source or destination IP address. The idea is for the network to recognize a class without having to receive any request from applications. This allows the QoS mechanisms to be applied to other applications that do not have the RSVP functionality, which is the case for 99% of applications that use IP. The introduction of the DiffServ Code Point (DSCP) replaces the IP precedence but maintains interoperability with non-DS compliant devices (those that still use IP precedence). Because of this backward-compatibility DiffServ can be gradually deployed in large networks.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
35
DiffServ Elements • The service defines QoS requirements and guarantees provided to a traffic aggregate; • The conditioning functions and per-hop behaviors are used to realize services; • The DS field value (DS code point) is used to mark packets to select a per-hop behavior • Per-hop Behavior (PHB) is realized using a particular QoS mechanism • Provisioning is used to allocate resources to traffic classes
© 2001, Cisco Systems, Inc.
IP QoS Introduction-38
A traffic aggregate is a collection of all flows that require the same service. A service is implemented using different QoS mechanisms (a QoS mechanism implements a per-hop behavior). The DiffServ field (DS fie ld) is the former 8-bit Type of Service field. The main difference is that the DSCP supports more classes (64) than IP precedence (8). The most important part of designing QoS is to provision services as explained on the next page.
36
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Why is Provisioning Important? • QoS does not create bandwidth! • QoS manages bandwidth usage among multiple classes • QoS gives better service to a wellprovisioned class with respect to another class
© 2001, Cisco Systems, Inc.
IP QoS Introduction-39
Provisioning requires a thorough network analysis to determine parameters for services that are being deployed in the network. The result of provisioning is the allocation of bandwidth among all classes in times of congestion. Services are implemented by defining per-hop behavior (PHB) properties. PHBs are implemented by using the available QoS mechanisms in networks devices.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
37
Topological Terminology DS interior node
DS Egress Boundary node
DS Ingress Boundary node
Boundary link
Upstream DS domain
Downstream DS domain DS region
Traffic Stream = set of flows Behaviour Aggregate (flows with the same DSCP)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-40
A DS domain consists of DS boundary nodes and DS interior nodes. DS boundary nodes interconnect the DS domain to other DS or non-DS-capable domains. While DS interior nodes only connect to other DS interior or boundary nodes within the same DS domain. Both DS boundary nodes and interior nodes must be able to apply the appropriate PHB to packets based on the DS code point; otherwise unpredictable behaviour may result. DS boundary nodes act both as a DS ingress node and as a DS egress node for traffic traversing the network in different directions. Traffic enters a DS domain at a DS ingress node and leaves a DS domain at a DS egress node. A DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms to any Traffic Conditioning Agreement (TCA) between it and the other domain to which the ingress node is connected. A DS egress node may perform traffic conditioning functions on traffic forwarded to a directly connected peering domain, depending on the details of the TCA between the two domains. A differentiated services region (DS Region) is a set of one or more contiguous DS domains. DS regions are capable of supporting differentiated services along paths that span the domains within the region. The DS domains in a DS region may support different PHB groups internally and different code point-PHB mappings. However, to permit services that span across the domains, the peering DS domains must each establish a peering Service Level Agreement (SLA) that defines (either explicitly or implicitly) a TCA. The TCA specifies how transit traffic from one DS domain to another is conditioned at the boundary between the two DS domains. It is possible that several DS domains within a DS region may adopt a common service provisioning policy and may support a common set of PHB groups and
38
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
code point mappings. This eliminates the need for traffic conditioning between those DS domains.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
39
Traffic Terminology • Flow: a single instance of an application-toapplication flow of packets which is identified by source address, source port, destination address, destination port and protocol id. • Traffic stream: an administratively significant set of one or more flows which traverse a path segment. A traffic stream may consist of a set of active flows which are selected by a particular classifier. • Traffic profile: a description of the temporal properties of a traffic stream such as average and peak rate and burst size.
© 2001, Cisco Systems, Inc.
IP QoS Introduction-41
The terminology used throughout the course includes the following:
40
IP QoS Introduction
n
Flow (or microflow) is a sequence of packets identified by source and destination IP addresses, protocol identifier (for example, TCP and UDP) and source and destination port numbers.
n
Traffic stream is a collection of flows with a common set of parameters (for example, the same port number and the same source and destination network).
n
Traffic profile specifies typical properties of a traffic stream (average rate and burstiness). Provisioning should be performed based on traffic profiles and the importance of traffic streams.
Copyright 2001, Cisco Systems, Inc.
Traffic Terminology • Behavior Aggregate (BA) is a collection of packets with the same DS code point crossing a link in a particular direction. • Per-Hop Behavior (queuing in a node) externally observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate. • PHB Mechanism: a specific algorithm or operation (e.g., queuing discipline) that is implemented in a node to realize a set of one or more per-hop behaviors. © 2001, Cisco Systems, Inc.
IP QoS Introduction-42
Other important terms used throughout the course are: n
Behavior Aggregate (BA) identifies packets marked with the same DSCP
n
Per-hop Behavior (PHB) is applied to each BA according to the QoS policy
n
PHB mechanism is the actual QoS mechanism that satisfies PHB specification
Other terms can be found in RFC 2475, which defines the Differentiated Services model (http://www.ie tf.org/rfc/rfc2475.txt).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
41
Packet Header Terminology
DSCP field: 6bits
Unused: 2bits
Former ToS byte = new DS field
• DS code point: a specific value of the DSCP portion of the DS field, used to select a PHB (Per-Hop Behavior; forwarding and queuing method) • DS field: the IPv4 header ToS octet or the IPv6 Traffic Class octet when interpreted in conformance with the definition given in RFC2474. The bits of the DSCP field encode the DS code point, while the remaining bits are currently unused. © 2001, Cisco Systems, Inc.
IP QoS Introduction-43
The DiffServ model uses the DS field in the IP header to mark packets according to their classification into Behavior Aggregates (BAs). The DS field occupies the same eight bits of the IP header that were previously used for the Type of Service (ToS) field. There are three IETF standards describing the purpose of those eight bits: n
RFC 791 includes specification of the ToS field where the high-order three bits are used for IP precedence. The other bits are used for delay, throughput, reliability and cost.
n
RFC 1812 modifies the meaning of the ToS field by removing any meaning from the five low-order bits (those bits should all be zero).
n
RFC 2474 replaces the ToS field with the DS field where the six high-order bits are used for the DiffServ Code Point (DSCP). The remaining two bits are currently not used.
Each DSCP value identifies a Behavior Aggregate (BA). Each BA is assigned a per-hop behavior (PHB). Each PHB is implemented using the appropriate QoS mechanism or a set of QoS mechanisms.
42
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
DSCP Encoding • Three pools: – “xxxxx0”
Standard Action
– “xxxx11”
Experimental/Local Use
– “xxxx01”
EXP/LU (possible std action)
• Default DSCP: “000000” • Default PHB: FIFO, tail-drop
© 2001, Cisco Systems, Inc.
IP QoS Introduction-44
Unlike IP precedence, which lacked any standard definitions of values and corresponding PHBs, the DSCP has half of its value range reserved for standard defined PHBs. The low-order bit of the DSCP identifies whether the DSCP value identifies a standard action (PHB) or a user-defined action. The second bit could, potentially, (in the future) also be used to identify additional standard actions. The default value of DSCP is 0. The associated PHB is FIFO service with a tail-drop. FIFO queuing is discussed in the “IP QoS – Queuing mechanisms module”. The default DSCP value seamlessly maps to the default IP precedence value, which is also 0 according to RFC 1812.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
43
DSCP Usage DS Code point selects per-hop behavior (PHB) throughout the network • Default PHB • Class Selector (IP precedence) PHB • Expedited Forwarding (EF) PHB • Assured Forwarding (AF) PHB
© 2001, Cisco Systems, Inc.
IP QoS Introduction-45
The following per-hop behaviors are defined by IETF standards: n
Default PHB – used for best-effort service
n
Class Selector PHB – used for backward compatibility with non-DS compliant devices (RFC 1812 compliant devices and, optionally, RFC 791 compliant devices)
n
Expedited Forwarding PHB – used for low-delay service
n
Assured Forwarding PHB – used for guaranteed bandwidth service
The Default PHB and the Class Selector PHB are described in RFC 2474 (http://www.ietf.org/rfc/rfc2474.txt), Expedited Forwarding PHB is described in RFC 2598 (http://www.ietf.org/rfc/rfc2598.txt) and Assured Forwarding in RFC 2597 (http://www.ietf.org/rfc/rfc2597.txt).
44
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Backward Compatibility Using the Class Selector • Non-DS compliant node: node that does not interpret the DSCP correctly or that does not support all the standardized PHB’s • Legacy node: a non-DS compliant node that interprets IPv4 ToS such as defined by RFC791 and RFC1812. • DSCP is backward compatible with IP Precedence (Class Selector Code point, RFC 1812) but not with the ToS byte definition from RFC 791 (“DTR” bits)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-46
The history of the eight bits in question (ToS field alias DS field) can be divided into three periods according to the RFCs describing the purpose of those bits: RFC 791 RFC 791 defines the Type of Service field with the following components: n
Bits seven, six and five are used for IP precedence
n
Bit four is used for delay (0 = Normal Delay, 1 = Low Delay)
n
Bit three is used for throughput (0 = Normal Throughput, 1 = High Throughput)
n
Bit two is used for reliability (0 = Normal Reliability, 1 = High Reliability)
n
Bits one and zero are not used and should be zero (bit one was later applied a meaning of monetary-cost by RFC 1349; this RFC also replaces individual bits with a four-bit ToS value to allow more types of services)
RFC 1812 RFC 1812 loosens the strict representation of the ToS field (obsole tes RFC 795). RFC 2474 RFC 2474 replaces the ToS field with the DS field where a range of eight values (Class Selector) is used for backward compatibility with IP precedence. There is no compatibility with the delay, throughput, reliability and monetary-cost bits.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
45
Class Selector Code Point • Compatibility with current IP precedence usage (RFC 1812) • “xxx000” DS code points • Differentiates probability of timely forwarding (PTF) – PTF (xyz000) >= PTF(abc000) if xyz > abc
© 2001, Cisco Systems, Inc.
IP QoS Introduction-47
RFC 1812 simply prioritizes packets according to the precedence value. The PHB is defined as the probability of timely forwarding. Packets with higher IP precedence should (on the average) be forwarded in less time than packets with lower IP precedence. RFC 2474 adopts this set of PHBs and values by creating the Class Selector PHB group. Class Selector can be identified by the low-order three bits of the DSCP or low-order five bits of the DS field: all bits are zero.
46
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Expedited Forwarding • Expedited Forwarding (EF) PHB: – Ensures a minimum departure rate – Guarantees bandwidth – the class is guaranteed an amount of bandwidth with prioritized forwarding – Polices bandwidth – the class is not allowed to exceed the guaranteed amount (excess traffic is dropped) • DSCP value: “101110”; looks like IP precedence 5 to non-DS compliant devices
© 2001, Cisco Systems, Inc.
IP QoS Introduction-48
The Expedited Forwarding PHB is identified based on the following parameters: n
Ensures a minimum departure rate to provide the lowest possible delay to delay-sensitive applications
n
Guarantees bandwidth to prevent starvation of the application if there are multiple applications using Expedited Forwarding PHB
n
Polices bandwidth to prevent starvation of other applications or classes that are not using this PHB
n
Packets requiring Expedited Forwarding should be marked with DSCP binary value “101110” (46 or 0x2E)
Non-DS compliant devices will regard EF DSCP value as IP precedence 5 (101), which is the highest user-definable IP precedence and is typically used for delay-sensitive traffic such as Voice over IP.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
47
IOS EF PHB Implementations • Priority Queuing • IP RTP Prioritization • Class-based Low-latency Queuing (CB-LLQ) • Strict Priority queuing within Modified Deficit Round Robin (MDRR) on GSR
© 2001, Cisco Systems, Inc.
IP QoS Introduction-49
Expedited Forwarding PHB can be implemented on Cisco routers using several different QoS mechanisms:
48
IP QoS Introduction
n
Routers running older Cisco IOS versions can use Priority Queuing (PQ) and put delay-sensitive traffic into a “high” priority queue. Priority Queuing, however, does not fully comply with the specification of the EF PHB – it does not have the capability to police the bandwidth used by the EF class.
n
IP RTP Prioritization can be used in combination with Weighted Fair Queuing (WFQ) or Class-based Weighted Fair Queuing (CB-WFQ). IP RTP Prioritization provides expedited forwarding with bandwidth guarantee and bandwidth policing.
n
Class-based Low-latency Queuing (CB-LLQ) is a mechanism similar to IP RTP Prioritization. It is the preferred mechanism for implementing EF PHB.
n
Strict Priority within Modified Deficit Round Robin (MDRR) on the Cisco 12000 series routers provides low-latency queuing but does not police bandwidth. Alternate Priority MDRR prevents starvation of other classes but it does not police bandwidth of the EF class.
Copyright 2001, Cisco Systems, Inc.
Assured Forwarding • Assured Forwarding (AF) PHB: –Guarantees bandwidth –Allows access to extra bandwidth if available • Four standard classes (af1, af2, af3 and af4) • DSCP value range: “aaadd0” where “aaa” is a binary value of the class and “dd” is drop probability
© 2001, Cisco Systems, Inc.
IP QoS Introduction-50
The Assured Forwarding PHB is identified based on the following parameters: n
Guarantees a certain amount of bandwidth to an AF class
n
Allows access to extra bandwidth, if available
n
Packets requiring AF PHB should be marked with DSCP value “aaadd0” where “aaa” is the number of the class and “dd” is the drop probability
There are four standard-defined AF classes. Each class should be treated independently and have bandwidth allocated based on the QoS policy.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
49
AF Encoding Class AF1 AF2 AF3 AF4
Value 001dd0 010dd0 011dd0 100dd0
Drop
Value
Probability (dd) Low
01
Medium
10
High
11
• Each AF class uses three DSCP values • Each AF class is independently forwarded with its guaranteed bandwidth • Differentiated RED is used within each class to prevent congestion within the class © 2001, Cisco Systems, Inc.
IP QoS Introduction-51
As the figure illustrates there are three DSCP values assigned to each of the four AF classes. Assured Forwarding class AF class 1
AF class 2
AF class 3
AF class 4
50
IP QoS Introduction
Drop Probability Low Medium High Low Medium High Low Medium High Low Medium High
DSCP value 001 01 0 001 10 0 001 11 0 010 01 0 010 10 0 010 11 0 011 01 0 011 10 0 011 11 0 100 01 0 100 10 0 100 11 0
Copyright 2001, Cisco Systems, Inc.
AF PHB Definition • A DS node MUST allocate a configurable, minimum amount of forwarding resources (buffer space and bandwidth) per AF class • Excess resources may be allocated between non-idle classes. The manner must be specified. • Reordering of IP packets of the same flow is not allowed if they belong to the same AF class
© 2001, Cisco Systems, Inc.
IP QoS Introduction-52
An AF implementation must attempt to minimize long-term congestion within each class, while allowing short-term congestion resulting from bursts. This requires an active queue management algorithm. An example of such an algorithm is Weighted Random Early Detection (WRED). The AF specification does not define the use of a particular algorithm, but does require that several properties hold. An AF implementation must detect and respond to long-term congestion within each cla ss by dropping packets, while handling short-term congestion (packet bursts) by queuing packets. This implies the presence of a smoothing or filtering function that monitors the instantaneous congestion level and computes a smoothed congestion level. The dropping algorithm uses this smoothed congestion level to determine when packets should be discarded. The dropping algorithm must treat all packets within a single class and precedence level identically. This implies that, for any given smoothed congestion level, the discard rate of a particular microflow's packets within a single precedence level will be proportional to that flow's percentage of the total amount of traffic passing through that precedence level. The congestion indication feedback to the end nodes, and thus the level of packet discard at each drop precedence in relation to congestion, must be gradual rather than abrupt. This allows the overall system to reach a stable operating point. WRED uses two (configurable) smoothed congestion level thresholds. When the smoothed congestion level is below the first threshold, no packets of the relevant drop precedence are discarded. When the smoothed congestion level is between the first and the second threshold, packets are discarded with linearly increasing probability, ranging from zero to a configurable value reached just prior to the second threshold. When the smoothed congestion level is above the second
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
51
threshold, packets of the relevant drop precedence are discarded with 100% probability. To allow the AF PHB to be used in many different operating environments, the dropping algorithm control parameters must be independently configurable for each packet drop precedence and for each AF class. Within the limits above, this specification allows for a range of packet discard behaviours.
52
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
AF PHB Implementation • CBWFQ (4 classes) with WRED within each class • (M)DRR with WRED within each class • Optionally Custom Queuing (does not support differentiated dropping)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-53
As with Expedited Forwarding there are multiple QoS mechanisms in the Cisco IOS that can accommodate some or all of the requirements of Assured Forwarding PHB: n
The preferred implementation is to use the Class-based Weighted Fair Queuing (CB-WFQ) with four classes (four independent queues) and Weighted Random Early Detection (WRED) within each queue.
n
A similar solution can be provided on the Cisco 12000 series routers by using the Modified Deficit Round Robin (MDRR) queuing with WRED in each queue. The AF PHB can also be implemented using the old-fashioned IP precedence. The only restriction is the number of available IP precedence values.
n
Example 1:
n
n
Four classes but no differentiated dropping:
n
AF1—IP precedence 1
n
AF2—IP precedence 2
n
AF3—IP precedence 3
n
AF4—IP precedence 4
Example 2: n
Two classes with differentiated dropping (two drop precedence values):
n
AF1—IP precedence 1 for high-drop, IP precedence 2 for low-drop
n
AF1—IP precedence 3 for high-drop, IP precedence 4 for low-drop
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
53
54
IP QoS Introduction
n
In both examples IP precedence 0 can be used for a best-effort class and IP precedence 5 for an EF class.
n
A similar solution as shown in Example 1 is also possible with Custom Queuing, except it has no support for differentiated dropping and DSCP. A workaround is possible if access-lists are used to match the DSCP value (direct matching of DSCP available only in IOS 12.1 and above) with a combination of IP precedence and ToS value.
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Describe the DiffServ model
n
List the key benefits of the DiffServ model compared to the IntServ model
n
Describe the purpose of the DS field in IP headers
n
Describe the interoperability between DSCP-based and IP-precedence-based devices in a network
n
Describe the Expedited Forwarding service
n
Describe the Assured Forwarding service
Review Questions Answer the following questions: n
What are the benefits of the DiffServ model compared to the IntServ model?
n
What is a DiffServ Code Point?
n
Name the standard PHBs?
n
How was backward compatibility with IP precedence achieved?
n
Describe the PHB of Assured Forwarding.
n
Describe the PHB of Expedited Forwarding.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
55
Building Blocks of IP QoS Mechanisms Objectives Upon completion of this lesson, you will be able to perform the following tasks:
56
IP QoS Introduction
n
Describe different classification options in IP networks
n
Describe different marking options in IP networks
n
List the mechanisms that are capable of measuring the rate of traffic
n
List the mechanisms that are used for traffic conditioning, shaping and avoiding congestion
n
List the forwarding mechanisms available in Cisco IOS
n
List the queuing mechanisms available in Cisco IOS
Copyright 2001, Cisco Systems, Inc.
Router Functions Defragmentation Decompression (payload, header) Source -based qos-label/precedence setting Destination-based qos-label/precedence setting Rate -limiting Class -based marking Policy-based-routing ...
Input I/O
Input Processing
Rate -limiting Random dropping Shaping Compression (payload, header) Fragmentation Queuing and scheduling ...
Forwarding
Output Processing
Output I/O
Process switching Fast/optimum switching Netflow switching CEF switching
• Depending on the configuration, a router may perform a number of actions prior to forwarding a packet (input processing) • Depending on the configuration, a router may perform a number of actions prior to enqueuing a packet in the hardware queue (output processing) © 2001, Cisco Systems, Inc.
IP QoS Introduction-58
Basic router function takes packets received on the input interface, makes a forwarding decision and transmits the packet out through the output interface. Today’s routers, however, can do much more than that. The figure lists a small subset of features that affect packet processing on input or output interfaces. Following is a list of some of the features available with Cisco routers: n
Payload compression (Stacker, Predictor)
n
Header compression (TCP and RTP header compression)
n
BGP-policy marking (CEF-based marking or QoS Policy propagation through BGP)
n
Traffic Policing (CAR, CB Policing)
n
Traffic Shaping (GTS, FRTS, CB-Shaping)
n
Class-based marking
n
Encryption (CET or IPsec)
n
WRED
n
Policy-based Routing
n
Accounting (IP accounting, NetFlow accounting)
n
Filtering (access lists)
n
Reverse-path checking
n
Address and port translation (NAT, PAT)
n
Stateful filtering (firewalling)
n
Web-cache redirection
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
57
58
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
IP QoS Actions • Classification – Each class-oriented QoS mechanism has to support some type of classification (access lists, route maps, class maps, etc.) • Metering – Some mechanisms measure the rate of traffic to enforce a certain policy (e.g. rate limiting, shaping, scheduling, etc.) • Dropping – Some mechanisms are used to drop packets (e.g. random early detection) • Policing – Some mechanisms are used to enforce a rate limit based on the metering (excess traffic is dropped) • Shaping – Some mechanisms are used to enforce a rate limit based on the metering (excess traffic is delayed) © 2001, Cisco Systems, Inc.
IP QoS Introduction-59
IP QoS mechanisms can perform different types of actions. All QoS mechanisms can be divided into the following QoS actions: n
Classification – most QoS mechanisms support multiple classes. There are different classification tools available with different QoS mechanisms (for example, access lists, route maps, class maps and rate-limit access lists). Some QoS mechanisms have the capability to match directly on certain parameters. For example: –
CAR (QoS group and DSCP)
–
WRED (IP precedence)
–
ToS-based dWFQ (IP precedence)
–
QoS-group-based dWFQ (QoS group)
–
WFQ (flow parameters)
–
PQ and CQ (interface, packet size and protocol)
n
Some mechanisms require the information about traffic rate of classes (for example, CAR, GTS, FRTS, CB-Shaping, CB-Policing, CB-WFQ, CB-LLQ, MDRR and IP RTP Prioritization).
n
Some mechanisms are used for dropping purposes. They utilize a dropping scheme different from the usual tail-drop. WRED is an example of such mechanism.
n
Some mechanisms are used to limit traffic rate by dropping excess traffic (CAR and CB-Policing).
n
Some mechanisms are used to limit traffic rate by delaying excess traffic (GTS, FRTS and CB-Shaping).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
59
60
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
IP QoS Actions • Marking – Some mechanisms have the capability to mark packets based on classification and/or metering (e.g. CAR, class-based marking, etc.) • Queuing – Each interface has to have a queuing mechanism • Forwarding – There are several supported forwarding mechanisms (process switching, fast switching, CEF switching, etc.)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-60
n
Some mechanisms have the capability to mark packets with different types of markers (IP precedence, DSCP, QoS group, MPLS experimental bits, ATM CLP bit, Frame Relay DE bit and 802.1q or ISL priority/cos bits)
n
Some mechanisms are used for queuing on output interfaces (for example, FIFO, PQ, CQ, WFQ, dWFQ, ToS-based dWFQ, QoS-group-based dWFQ, CB-WFQ, IP RTP Prioritization and MDRR)
n
Cisco IOS also has different types of forwarding mechanisms (Process Switching, Fast Switching, Optimum Switching, Silicon Switching, Autonomous Switching, NetFlow Switching, Cisco Express Forwarding and Policy-based routing)
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
61
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Queuing
Shaping Dropping
Scheduling Dropping
• Most traditional QoS mechanisms include extensive built-in classifiers – – – – –
Committed Access Rate (CAR) QoS Policy Propagation via BGP (QPPB) Route-maps Queuing mechanisms ...
• Modular QoS CLI (first implemented in 12.0(5)T) separates classifier from other actions – Includes all traditional classifiers + Network Based Application Recognition (NBAR) © 2001, Cisco Systems, Inc.
IP QoS Introduction-61
Most QoS mechanisms include several different classification options. The following table lists some QoS mechanisms with the corresponding classification options. QoS Mechanism
Classification options
Committed Access Rate (CAR)
Access list Rate limit access list QoS-group DSCP
QoS Policy Propagation through BGP (QPPB)
Route map
Policy-based routing
Route map
Generic Traffic Shaping
Access list
Priority Queuing and Custom Queuing
Access list Packet size Input interface Protocol
All mechanisms available using the Class map which can use: another class modular QoS CLI (CB-WFQ, CB-LLQ, map, access list, protocol (including CB-Shaping, CB-Policing, CB-Marking) NBAR), input interface, source or destination MAC address, IP precedence, DSCP, QoS group, MPLS experimental bits, etc.)
62
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Queuing
Shaping Dropping
Scheduling Dropping
• Token Bucket model is used for metering – – – – – – – –
Committed Access Rate (CAR) Generic Traffic Shaping (GTS) Frame Relay Traffic Shaping (FRTS) Class-based Weighted Fair Queuing (CB-WFQ) Class-based Low Latency Queuing (CB-LLQ) Class-based Policing Class-based Shaping IP RTP Prioritization
© 2001, Cisco Systems, Inc.
IP QoS Introduction-62
The figure lists QoS mechanisms in the Cisco IOS that have the capability to measure the rate of traffic by using the Token Bucket model.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
63
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
• Marker is used to set: – – – – – – –
IP precedence DSCP QoS group MPLS experimental bits Frame Relay DE bit ATM CLP bit IEEE 802.1Q or ISL CoS
Conditioner
Queuing
Shaping Dropping
Scheduling Dropping
• Marking mechanisms: – Comitted Access Rate (CAR) – QoS Policy Propagation through BGP (QPPB) – Policy-based Routing (PBR) – Class-based Marking
© 2001, Cisco Systems, Inc.
IP QoS Introduction-63
The figure lists markers that can be set using Cisco routers and the queuing mechanisms that have marking capabilities. The following table lists all the mechanisms that have marking capabilities and the markers that are supported by those mechanisms.
64
IP QoS Introduction
QoS Mechanism
Available markers
Committed Access Rate (CAR)
IP precedence DSCP QoS group MPLS experimental bits
QoS Policy Propagation through BGP (QPPB)
IP precedence QoS group
Policy-based Routing (PBR)
IP precedence QoS group
Class-based Marking
IP precedence DSCP QoS group MPLS experimental bits ATM CLP bit Frame Relay DE bit 802.1Q/ISL cos/priority
Copyright 2001, Cisco Systems, Inc.
Comparison of Markers Marker Marker
Preservation
Value range
IP precedence
Throught a network
8 values, 2 reserved (0 to 7)
DSCP
Throught a network
64 values, 32 are standard (0 to 63)
QoS group group
Local to a router
100 values (0 to 99)
MPLS experimental experimental bits bits
Throughout an MPLS network (optionally throughout throughout an entire IP network)
8 values
Frame Relay DE bit
Throughout a Frame Relay network
2 values (0 or 1)
ATM CLP bit
Throughout an ATM network
2 values (0 or 1)
IEEE 802.1Q or or ISL ISL CoS CoS
Throughout a LAN switched network
8 values (0 to 7)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-64
The figure describes the differences between markers in terms of preservation of the marker and a value range. Markers can: n
Be local to the router (the QoS group is not part of a packet or frame; it is a piece of information attached to a packet while it is stored in the router’s memory)
n
Have a limited range due to layer-2 technology that they use (ATM CLP, FR DE, 802.1q/ISL cos/priority, MPLS exp bits)
n
Have an unlimited range (IP precedence, DSCP)
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
65
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Queuing
Shaping Dropping
Scheduling Dropping
• Shaping mechanisms: – Generic Traffic Shaping (GTS) – Frame Relay Traffic Shaping (FRTS) – Class-based Shaping – Hardware shaping on ATM VC
© 2001, Cisco Systems, Inc.
IP QoS Introduction-65
The figure lists four mechanisms that are used for traffic shaping purposes. All of these mechanisms are implemented in software (Cisco IOS) except for ATM shaping which is implemented in hardware. Traffic shaping is used to limit the departure rate of packets, frames or cells by delaying them if they exceed the contractual rate. A token bucket model is used to measure the arrival rate and determine when packets can be forwarded.
66
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Queuing
Shaping Dropping
Scheduling Dropping
• Dropping mechanisms – Committed Access Rate (CAR) and Class-based Policing can drop packets that exceed the contractual rate – Weighted Random Early Detection (WRED) can randomly drop packets when an interface is nearing congestion © 2001, Cisco Systems, Inc.
IP QoS Introduction-66
Another way of enforcing rate limits is to drop excess traffic. Committed Access Rate (CAR) and Class-based Policing can be used for this purpose. Weighted Random Early Detection (WRED) is a congestion-avoidance mechanism that randomly drops packets when interfaces are nearing congestion.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
67
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Forwarding
Shaping Dropping
Queuing Scheduling Dropping
• Cisco Express Forwarding (CEF) is recommended from IOS 12.0 • Some QoS features work only in combination with CEF
© 2001, Cisco Systems, Inc.
IP QoS Introduction-67
The Cisco IOS supports a large number of different forwarding mechanisms (depending on the platform and the IOS version). From the QoS perspective it can be said that: n
Most newer mechanisms require Cisco Express Forwarding (CEF)
n
Some older mechanisms do not work with CEF (Process or Fast switching is required)
Some other forwarding mechanisms available in the Cisco IOS include:
68
IP QoS Introduction
n
Process switching, which is the oldest forwarding mechanisms available since the first releases of Cisco IOS.
n
Fast switching, which is the first optimization of forwarding. It uses a cache to store most used destinations and it is performed in the interrupt code to improve performance.
n
Optimum switching, which is a further optimized version of fast switching on high-end routers.
n
NetFlow switching, which forwards packets by recognizing and caching flow information.
Copyright 2001, Cisco Systems, Inc.
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Forwarding
Shaping Dropping
Queuing Scheduling Dropping
• Traditional queuing mechanisms – FIFO, Priority Queuing (PQ), Custom Queuing (CQ)
• Weighted Fair Queuing (WFQ) family – WFQ, dWFQ, CoS-based dWFQ, QoS-group dWFQ
• Advanced queuing mechanisms – Class-based WFQ, Class-based LLQ © 2001, Cisco Systems, Inc.
IP QoS Introduction-68
The last mechanism that handles packets in the IOS is the queuing mechanism. The figure lists most of the queuing mechanisms.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
69
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Forwarding
Shaping Dropping
Queuing Scheduling Dropping
• Tail drop on queue congestion • WFQ has an improved tail-drop scheme • WRED randomly drops packets when nearing congestion
© 2001, Cisco Systems, Inc.
IP QoS Introduction-69
All queuing mechanisms include a drop policy. Most mechanisms use a simple taildrop scheme (the last packet to arrive is dropped if there is no room in the queue). Weighted Fair Queuing (WFQ) uses a more intelligent dropping scheme, which is discussed in the “IP QoS – Queuing mechanisms” module. Some queuing mechanisms also include the Weighted Random Early Detection (WRED) to prevent congestion in their queues.
70
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Describe different classification options in IP networks
n
Describe different marking options in IP networks
n
List the mechanisms that are capable of measuring the rate of traffic
n
List the mechanisms that are used for traffic conditioning, shaping and avoiding congestion
n
List the forwarding mechanisms available in the Cisco IOS
n
List the queuing mechanisms available in the Cisco IOS
Review Questions Answer the following questions: n
Name the QoS building blocks.
n
What is the purpose of classification?
n
What is the purpose of marking?
n
Which markers do you know?
n
Which mechanisms can classify and mark packets?
n
Which mechanisms have the ability to measure the rate of traffic?
n
Which forwarding mechanisms do you know?
n
Which queuing mechanisms do you know?
n
How, when and where do routers drop packets?
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
71
Enterprise Network Case Study Objectives Upon completion of this lesson, you will be able to perform the following tasks:
72
IP QoS Introduction
n
Describe a typical structure of an enterprise network
n
Describe the need for QoS in enterprise networks
n
List typical QoS requirements in enterprise networks
n
List the QoS mechanisms that are typically used in enterprise networks
Copyright 2001, Cisco Systems, Inc.
Traditional Enterprise Networks Core (central sites and data centres)
X.25 (ancient), Frame Relay (old), ATM (newer)
Distribution (regional centres)
X.25 (ancient), Frame Relay (old), ATM (newer)
Access (branch offices)
• Traditional enterprise network use a hub-and-spoke topology • Redundant connections are used to improve resilience • Partial mesh can be used between the core sites and the distribution sites © 2001, Cisco Systems, Inc.
IP QoS Introduction-74
This lesson describes typical Enterprise Networks to show the topology and technologies involved in such networks. Designing IP QoS networks largely depends on the topology and QoS requirements. The figure illustrates a three-layered network: 1. The core interconnects the data center(s) with the distribution-layer routers. 2. The distribution layer routers concentrate links towards a number of accesslayer routers. 3. The access-layer routers connect branch offices to the network. Most traffic in enterprise networks goes between branches and the data center.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
73
Modern Enterprise Networks Core (central sites and data centres)
MPLS/VPN (new)
Access (branch offices)
• Modern enterprise network use a full mesh topology provided by an MPLS/VPN backbone • Redundant connections to the backbone can be used to improve resilience • The MPLS/VPN backbone uses redundant connections and a partial mesh to improve resilience © 2001, Cisco Systems, Inc.
IP QoS Introduction-75
Modern enterprise networks can use MPLS/VPN backbones to get a virtual full mesh even though most traffic still goes between the data center and the branches. Implementing QoS in such environments requires QoS guarantees from the service provider and provisioning in the enterprise part of the network.
74
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
QoS in Enterprise Networks • Typical enterprise networks have a large number of different applications • Some applications are business-critical and require some guarantees (bandwidth, delay) • The network should provide enough resources to these business-critical applications • Applications are usually identified based on TCP or UDP port numbers
© 2001, Cisco Systems, Inc.
IP QoS Introduction-76
Enterprise networks are typically concerned with providing differentiated QoS to applications. Applications can be classified based on TCP or UDP port numbers and marked with IP precedence or DSCP at network edges. The network should guarantee resources to all business-critical applications (classes).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
75
Case Study • Typical line speeds – Core - Distribution – Distribution - Branch
< 2 Mbps 64 kbps - 256 kbps
• Typical protocols – SNA, NetBIOS, Desktop protocols (IPX), Some TCP/IP, Voice, Multimedia
• Typical QoS requirements – SNA and voice are high priority – Guaranteed bandwidth for some application – Rest of the traffic is best-effort © 2001, Cisco Systems, Inc.
IP QoS Introduction-77
The figure shows a case study where relatively low bandwidths are used which calls for QoS to manage bandwidth according to the needs of the enterprise.
76
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Case Study Implementation #1 • Core - Distribution – Custom queuing
• Distribution - Branch – Priority queuing or – Custom Queuing with a priority queue
• Options – Traffic shaping – Adaptation to Frame Relay congestion notification
© 2001, Cisco Systems, Inc.
IP QoS Introduction-78
The figure lists mechanisms that could be used to accommodate the need of the enterprise. This solution would normally be used in networks where an old IOS version is being used and an upgrade is not an option (due to the cost of getting newer IOS versions, memory upgrade, flash upgrade, etc.). The listed mechanisms (Priority Queuing and Custom Queuing) have been available since Cisco IOS version 10.0.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
77
Case Study Implementation #2 • Core - Distribution – Class-based Weighted Fair Queuing (CB-WFQ) – Class-based Low Latency Queuing (CB-LLQ)
• Distribution - Branch – Class-based Weighted Fair Queuing (CB-WFQ) – Class-based Low Latency Queuing (CB-LLQ)
• Options – Class-based Shaping – Adaptation to Frame Relay congestion notification – Class-based Policing – Weighted Random Early Detection (WRED) © 2001, Cisco Systems, Inc.
IP QoS Introduction-79
This figure shows a solution using advanced mechanisms to provide better control of bandwidth usage. This solution requires newer Cisco IOS software versions (12.1 or 12.2, depending on the details of the implementation).
78
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Describe a typical structure of an enterprise network
n
Describe the need for QoS in enterprise networks
n
List typical QoS requirements in enterprise networks
n
List the QoS mechanisms that are typically used in enterprise networks
Review Questions Answer the following questions: n
What is the typical enterprise network topology?
n
How is resilience achieved?
n
Based on which information do typical enterprise networks apply QoS?
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
79
Service Provider Case Study Objectives Upon completion of this lesson, you will be able to perform the following tasks:
80
IP QoS Introduction
n
Describe a typical structure of a service provider network
n
Describe the need for QoS in service provider networks
n
List typical QoS requirements in service provider networks
n
List the QoS mechanisms that can be used in service provider networks
Copyright 2001, Cisco Systems, Inc.
Typical Service Provider Networks
Core
ATM, SONET/SDH, DPT, GE, ...
Partial mesh Rings
ATM, SONET/SDH, DPT, GE, ...
Redundant connections Rings
Distribution (regional POPs)
Frame Relay, ATM, Leased line (analog, TDM), dial-up (PSTN, ISDN, GSM), xDSL, (fast)ethernet, ...
Single connections Optional redundant connections Dial backup
Access (customers)
• • • •
Typical service provider networks use a high -speed partially-meshed core (backbone) Regional POPs use two or more connections to the core There may be another layer of smaller POPs connected to distribution-layer POPs Customers are usually connected to the service provide via a single point-to-point link (a secondary link or a dial line can be used to improve resilience)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-84
As the figure illustrates, Service Provider networks significantly differ from typical enterprise networks. Enterprise Networks are used as a tool to support the enterprise whereas with Service Providers the network is the business itself. Enterprise networks are concerned with providing quality to business-critical applications and Service Providers tend to broaden their service offering by introducing QoS.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
81
QoS in Service Provider Networks Networks • Service providers extend their service offerings by introducing quality • Customers can get bandwidth guarantees (like CIR in Frame Relay) • Customers can get delay guarantees (like CBR in ATM) • Customers can get preferential treatment in case of congestion (Olympic service) • QoS mechanisms have to be deployed where congestion is likely (usually at network edge) • Customer’s traffic is identified based on source or destination IP addresses © 2001, Cisco Systems, Inc.
IP QoS Introduction-85
Service Providers want to offer customers more than plain connectivity. Service Providers want to establish differentiated levels of service for customers with incremental pricing and SLA agreements. The customer should not only shop around among a number of service providers that offer connectivity to the Internet or provide MPLS/VPNs, but also have a menu of services they can choose from. Some customers are satisfied with the best-effort service; some want certain service guarantees.
82
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Case Study A service provider wants to offer gold, silver, bronze and premium services • Premium gets 40% of available bandwidth with a low-delay guarantee • Gold gets 30% of available bandwidth • Silver gets 20% of available bandwidth • Bronze gets 10% of available bandwidth
© 2001, Cisco Systems, Inc.
IP QoS Introduction-86
The case study shows an example of a Service Provider which offers differentiated service levels where customers can choose the type of service they want and are willing to pay for. The service provider offers four services. Each of the services is basically a virtual service-provider network using a common infrastructure. The Premium service is guaranteed the most bandwidth and low-delay propagation of packets. Each of the following services is guaranteed less bandwidth. Premium customers will benefit most in times of congestion, whereas Bronze customers will only receive 10 percent of any link’s bandwidth.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
83
Case Study Implementation • Class-based Weighted Fair Queuing (CBWFQ) on slow to moderate-speed links • Class-based Low Latency Queuing (CB-LLQ) on slow to moderate-speed links • Weighted Random Early Detection (WRED) on fast links
© 2001, Cisco Systems, Inc.
IP QoS Introduction-87
Service Provider networks would generally use newer Cisco IOS software and can therefore deploy the latest available mechanisms. The case study is implemented using CB-WFQ in combination with WRED and CB-LLQ at networks edges (between access and distribution layer). WRED can be used on high-speed links (on core links).
84
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Describe a typical structure of a service provider network
n
Describe the need for QoS in service provider networks
n
List typical QoS requirements in service provider networks
n
List the QoS mechanisms that can be used in service provider networks
Review Questions Answer the following questions: n
What is the typical topology of service provider networks?
n
How is resilience achieved?
n
Based on which information do typical service provider networks apply QoS?
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
85
Summary After completing this module, you should be able to perform the following tasks:
86
IP QoS Introduction
n
Describe the need for IP QoS
n
Describe the Integrated Services model
n
Describe the Differentiated Services model
n
Describe the building blocks of IP QoS mechanisms (classification, marking, metering, policing, shaping, dropping, forwarding and queuing)
n
List the IP QoS mechanisms available in the Cisco IOS
n
Describe what QoS features are supported by different IP QoS mechanisms
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Introduction to IP Quality of Service Question: What are the relevant parameters that define the quality of service? Answer: Throughput (bandwidth), delay and jitter. Question: What can be done to give more bandwidth to an application? Answer: An application can get more throughput by increasing the bandwidth of the links in the path and/or using a QoS mechanism to guarantee bandwidth when the application has to contend with other flows. Payload and header compression also virtually increase the available bandwidth by reducing the overhead. Question: What can be done to reduce delay? Answer: Delay can be reduced by increasing the bandwidth of the links in the path and/or using a queuing mechanism that ensures minimum queuing delay for delaysensitive applications. Header compression will also help by reducing the serialization delay of small packets on low-speed links. Payload compression would have a similar result but it increases the delay because of the complexity of the compression algorithm. Question: What can be done to prevent packet loss? Answer: Packet loss can also be prevented by providing enough bandwidth. Alternatively a differentiated dropping mechanism can be used to drop packets of less important flows to prevent drops of high-priority flows. Another option is to use a queuing mechanism to guarantee enough bandwidth to high-priority flows. Question: Name the three QoS models? Answer: Best effort, Integrated services and Differentiated services.
Integrated Services Model Question: What are the two building blocks of the Integrated Services model? Answer: Resource reservation and admission control. Question: Which protocol is used to signal QoS requirements to the network? Answer: Resource reservation protocol (RSVP) is used to reserve network resources for applications.
Differentiated Services Model Question: What are the benefits of the DiffServ model compared to the IntServ model? Answer: DiffServ provides more scalable QoS solutions by applying QoS mechanisms (per-hop behavior) to traffic classes instead of individual applications. The DiffServ model does not require any signaling mechanism thus allowing QoS provisioning to non-RSVP applications. Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
87
Questions: What is a DiffServ Code Point? Answer: The DSCP is used to mark IP packets. It occupies the high-order 6 bits of the DiffServ field (former ToS field). Questions: Name the standard PHBs? Answer: Expedited Forwarding (EF), Assured Forwarding (AF) and Class Selector (CS). Questions: How was backward compatibility with IP precedence achieved? Answer: Backward compatibility is provided by using the DSCP values that map into IP precedence values that are typically used to achieve a similar goal: EF maps into IP precedence 5, AF1 maps into IP precedence 1, AF2 maps into IP precedence 2, AF3 maps into IP precedence 3, AF4 maps into IP precedence 4, the default DSCP maps into the default IP precedence 0. Questions: Describe the PHB of Assured Forwarding. Answer: AF PHB provides a bandwidth guarantee to a traffic class with the possibility to use more bandwidth if it is available. Questions: Describe the PHB of Expedited Forwarding. Answer: EF PHB provides a bandwidth guarantee to a traffic class and it ensures a minimum queuing delay. The traffic class is also limited to the provisioned bandwidth.
88
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Building Blocks of IP QoS Mechanisms Review Questions Answer the following questions: Name the QoS building blocks.
n
Classification, marking, metering, dropping, policing, shaping and queuing. What is the purpose of classification?
n
Classification is used to assign packets to traffic classes with different QoS requirements (behavior aggregates). What is the purpose of marking?
n
Marking is used to allow simplified classification on other devices in the network. Which markers do you know?
n
IP precedence, DSCP, MPLS experimental bits, QoS group, Frame Relay DE bit, ATM CLP bit, 802.1q CoS bits, ISL priority bits. Which mechanisms can classify and mark
n
packets? Policy-based Routing (PBR) Committed Access Rate (CAR) QoS Policy Propagation through BGP (QPPB) Class-based Policing Class-based Marking Which mechanisms have the ability to measure
n
the rate of traffic? Committed Access Rate (CAR) Generic Traffic Shaping (GTS) Frame Relay Traffic Shaping (FRTS) Class-based Weighted Fair Queuing (CB-WFQ) Class-based Low Latency Queuing (CB-LLQ) Class-based Policing Class-based Shaping IP RTP Prioritization n
Which forwarding mechanisms do you know? Process Switching, Fast Switching, Optimum Switching, NetFlow Switching, CEF switching …
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
89
n
Which queuing mechanisms do you know? FIFO, Priority Queuing (PQ), Custom Queuing (CQ), WFQ, dWFQ, CoS-based dWFQ, QoS-group dWFQ, Class-based WFQ, Class-based LLQ
n
How, when and where do routers drop packets? Routers typically drop packets when an output interface is congested. The output queue fills up and the newly arriving packets have to be dropped (tail drop).
90
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Enterprise Network Case Study Review Questions Answer the following questions: What is the typical enterprise network topology?
n
Enterprise networks typically use the hub-and-spoke topology. How is resilience achieved?
n
Resilience is achieved by using redundant links. Based on which information do typical enterprise
n
networks apply QoS? Enterprise networks typically provide QoS to applications. Applications are typically identified based on the TCP or UDP port numbers.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
91
Service Provider Case Study Review Questions Answer the following questions: What is the typical topology of service provider
n
networks? Typical service provider networks use a partially meshed core with a redundant hub-and-spoke topology for the POPs. n
How is resilience achieved? Resilience is achieved by using partial mesh (core) and redundant links (distribution, access).
n
Based on which information do typical service provider networks apply QoS? Service providers typically apply QoS to customer traffic. Customer traffic is identified based on source or destination IP addresses.
92
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Classification and Marking
Overview This module describes the mechanisms that are used to classify and mark IP packets. This module builds on the knowledge acquired from the introductory module where classification and marking is discussed. Theoretical knowledge is supplemented by detailing Policy-based routing (PBR) and QoS Policy Propagation through BGP (QPPB) mechanisms.
Objectives Upon completion of this module, you will be able to: n
Describe Policy-based routing and how it is used to classify and mark IP packets
n
Describe QoS Policy Propagation through BGP and how it is used to classify and mark IP packets
n
List other mechanisms that also support classification and marking capabilities (Committed Access Rate, Class-based Policing and Class-based Marking)
Traffic Classification and Marking Classification • Most QoS mechanisms in the Cisco IOS include some type of classification • Some mechanisms classify packets automatically, some require manual configuration
Marking • Only a small number of mechanisms also include a marking capability
© 2001, Cisco Systems, Inc.
Classification and Marking-3
This module focuses on the QoS mechanisms that are used for classification and marking purposes only. Most QoS mechanisms include some type of classification but only a small number of mechanisms also include marking capability. Classification is the term used for identifying a Behavior Aggregate to which a packet belongs. A Behavior Aggregate is a collection of flows requiring the same quality of service. Marking is the term used for coloring packets by applying a class-identifying value to one of the following markers: IP precedence, DSCP, QoS group (value is local to a router), MPLS experimental bits (can be used only in MPLS-enabled networks), ATM CLP bit (value can be used only within ATM networks), Frame Relay DE bit (value can be used only within Frame Relay networks), IEEE 802.1q or ISL cos/priority bits (value can be used on within LAN-switched networks).
2-2
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Traffic Classification and Marking • This module describes the two mechanisms that are used for classification and marking only: – Policy-based Routing (PBR) – QoS Policy Propagation through BGP (QPPB)
• Other classification and/or marking mechanisms are described in other QoS modules
© 2001, Cisco Systems, Inc.
Classification and Marking-4
This module describes the two QoS mechanisms that are used purely for classification and marking purposes: n
Policy-based Routing (PBR)
n
QoS Policy Propagation through BGP (QPPB)
There are other QoS mechanisms that also support classification and marking: n
Committed Access Rate (CAR) – this mechanism is described in the “IP QoS – Traffic Shaping and Policing” module
n
Class-based Policing (CB-Policing) – this mechanism is described in the “IP QoS – Modular QoS CLI (Chapter 2)” module
n
Class-based Marking (CB-Marking) – this mechanism is described in the “IP QoS – Modular QoS CLI (Chapter 2)” module
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-3
Policy-based Routing Objectives Upon completion of this lesson, you will be able to:
2-4
n
Describe Policy Based Routing (PBR)
n
Configure PBR on Cisco routers
n
Monitor and troubleshoot PBR
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Policy-based Routing • Policy-based Routing (PBR) is a mechanism that can be used to bypass the default destination-based forwarding functionality of routers • PBR is implemented using a route map where match commands are used to classify packets and set commands are used to process packets • Route maps are applied to interfaces for processing of inbound packets (forwarding and/or marking) © 2001, Cisco Systems, Inc.
Classification and Marking-7
The primary function of Policy-based Routing (PBR) is to bypass the destination-based forwarding functionality of routers by using a route map to make a forwarding decision based on other information. One additional feature of Policy Based Routing is the ability to modify IP packets by marking them with IP precedence or QoS group.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-5
PBR “match” and “set” Options
Match on: • Standard and extended access lists • Length of packets (min,max)
Set: • Output interface (bypass the routing table) • Next-hop address (bypass the routing table) • ToS field (QoS marking) • IP precedence (QoS marking) • QoS group (QoS marking)
IP Input interface
Output interface
PBR has two primary applications: • Implementation of more complex routing paradigms than a simple destination-based forwarding • Classification and marking of packets for QoS purposes © 2001, Cisco Systems, Inc.
Classification and Marking-8
PBR classifies packets based on standard or extended access lists, the length of packets and the incoming router interface (a route map is applied to an input interface). The route map sets the following parameters: n
Output interface: force the router to forward packets to an interface even if it would not provide for optimal routing
n
Next-hop address: to make a forwarding decision by using a different next-hop address than the one determined by the routing table
n
ToS value: the ToS value in this case applies to bits 4,3,2 and 1 of the ToS field
n
IP precedence: three-bit field used to identify a class of service
n
QoS group: the local parameter with an expanded value range
The first two parameters (output interface and next-hop address) are used to bypass the default destination-based routing. The other three parameters are used for QoS purposes (ToS value is less commonly used).
2-6
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
PBR Capabilities PBR can only classify and mark inbound or locallyoriginated packets
Meter
Inbound or Locally-originated
Classifier
Marker
Dropper
Forwarding Outbound
Meter
Classifier
© 2001, Cisco Systems, Inc.
Marker
Shaper Dropper
Queuing
Classification and Marking-9
The figure illustrates the “full” QoS building-block scheme showing that PBR works only on input and that it supports only classification and marking. The “Forwarding” box could be colored as well since PBR can be used to make a forwarding decision. PBR contains no mechanism for metering or dropping of data packets.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-7
Configuring Classification and Marking Using PBR • Create a route map • Apply the route map to an incoming interface and/or • Apply the route map to locally originated traffic • Monitor and debug policy routing
© 2001, Cisco Systems, Inc.
Classification and Marking -10
Configuring PBR involves the following steps:
2-8
n
Creating a route map where the match statement is used to match with the source or destination IP address or with any other parameter that can be matched by an access list (standard or extended). It can also match packets based on their size.
n
Applying the route-map to: n
An input interface to process inbound packets on that interface or
n
To locally originated packets
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Route Map Rules Router(config)#
route-map [permit | deny] [<sequence-number>] match set <parameter> • Route maps are identified by a case sensitive name • Route maps can have multiple statements (same name, different sequence number) • Packets are processed in the specified sequence • Packets not matched by the route map are forwarded using the default destination-based forwarding • If packets are matched by the “match” condition but the route map statement is using the “deny” option, the default destination-based forwarding is applied to the packet © 2001, Cisco Systems, Inc.
Classification and Marking -11
A brief refresher about route maps: n
Route maps can have one or more statements. A route map, or a set of route-map statements with the same name is identified by a case-sensitive name .
n
Individual route-map statements are identified by their name and sequence number. When packets are processed by a route map they are evaluated in the order specified by sequence numbers.
n
A route map is basically made to be a filtering mechanism. When used for PBR:
n
Copyright 2001, Cisco Systems, Inc.
n
permit means “do whatever the set commands says”
n
deny means “do not do anything”
When a packet is matched by one of the route-map statements it is processed by that statement and the processing of the packet ends. Ordering route-map statements correctly is therefore necessary.
IP QoS Classification and Marking
2-9
PBR Classification Router(config-route-map)#
match ip address <#acl>
• Classify using a standard access list against the source address • Classify using an extended access list against the source and/or destination address, source and/or destination TCP/UDP port, IP precedence, DSCP, ToS Router(config-route-map)#
match length <min> <max>
• Classify using a range of packet lengths that will be matched by the route map statement
© 2001, Cisco Systems, Inc.
Classification and Marking -12
Route maps have a number of match options but only two can be used for policybased routing purposes:
2-10
n
match ip address is used to examine the packet’s headers with a standard or an extended access list
n
match length is used to mach packets based on their length
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
PBR Marking Router(config-route-map)#
set ip precedence <precedence> • Set the specified IP precedence to packets matched by the route map • IP precedence supports 8 classes, two are reserved (6 and 7) Router(config-route-map)#
set ip qos-group • Classify using a range of packet lengths that will be matched by the route map statement • QoS group supports 100 classes (0-99) Router(config-route-map)#
set ip tos • Set the low-order 4 bits of the Type-of-service (ToS) field • These bits are used to specify the delay, throughput and reliability parameters (specified in RFC 791, no longer used after RFC 1812) © 2001, Cisco Systems, Inc.
Classification and Marking -13
The following marking options are available with route maps: n
IP precedence
n
QoS group
n
ToS value (the four bits below IP precedence in the ToS field) used for Delay, Throughput, Reliability and Monetary Cost
IP precedence is encoded into the three high-order bits of the ToS field in the IP header. It supports eight classes of which two are reserved and should not be used for user-defined classes (IP precedence 6 and 7). Ip precedence 0 is the default value and is usually used for the best-effort class. QoS group has one major advantage over IP precedence and one major drawback: n
QoS group supports up to 100 classes. Values 0 to 99 can be used to mark packets.
n
QoS group is a parameter that is local to the router where it is set. It is not part of any header. It is usually set on input interface and later examined (matched) on output interfaces. Once the packet is transmitted, the QoS-group information is lost, and the next router must reclassify and mark the packet.
ToS value is encoded into bits 4,3,2 and 1 of the ToS field (according to older RFCs 791 and 1349). This value was made obsolete by the introduction of the DiffServ Code Point, which does not take into account compatibility with these bits.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-11
Applying a Route Map Router(config-if)#
ip policy-map
• Specifies the route map used to set QoS and other policy-routing parameters for packets received through the specified interface Router(config)#
ip local policy-map
• Specifies the route map used to set QoS and other policy-routing parameters for packets generated by the router
© 2001, Cisco Systems, Inc.
Classification and Marking -14
Once a route map is configured it must be applied to either packets coming into the router through an interface or to packets being generated by the router. The first command (ip policy-map) is used for forwarded packets. The second command (ip local policy-map) is used for packets generated by a router and is typically used for tunneling packets (e.g. DLSw) Note
2-12
IP QoS Classification and Marking
Policy-based routing is a mechanism that puts interfaces into Process Switching mode. This will significantly degrade performance. PBR has been available in the fast-switching path since Cisco IOS version 11.3. The ip route-cache policy command can be used on an interface to enable caching for PBR. This command has been available since Cisco IOS software version 12.0.
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting PBR Router#
show route-map
• Displays the route map and number of packets and bytes matched by each statement Router#
debug ip policy
• Displays all packets matched by policy routing routemaps
© 2001, Cisco Systems, Inc.
Classification and Marking -15
The show route-map command is used to display the route map with its match and set options. The debug ip policy command is used to display all packets being processed by PBR. The show ip policy command is used to see a list of all interfaces that are enabled for PBR. The output also displays the corresponding route maps. The show ip local policy command is used to display the configured parameters for local PBR with a number of packets and bytes that have been policy-routed by the local PBR.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-13
Monitoring and Debugging Policy Routing Router#show Router#show route-map route-map CPE CPE route-map route-map CPE, CPE, permit, permit, sequence sequence 10 Match Match clauses: ip address address (access-lists): (access-lists): 199 Set clauses: clauses: ip precedence precedence flash-override flash-override Policy routing matches: 3418 packets, 412108 bytes route-map route-map CPE, CPE, permit, permit, sequence sequence 20 Match Match clauses: ip address address (access-lists): (access-lists): MatchPing MatchPing Set clauses: clauses: ip precedence precedence priority priority Policy Policy routing routing matches: matches: 82 82 packets, packets, 31045 31045 bytes bytes Router#show Router#show access-list access-list MatchPing MatchPing Extended Extended IP IP access access list MatchPing MatchPing permit icmp any any echo (25 matches) Router# Router# © 2001, Cisco Systems, Inc.
Classification and Marking -16
The figure shows a sample output of the show route-map and show access-list commands.
2-14
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Monitoring and Debugging Policy-based Routing Router#debug Router#debug ip ip policy policy Policy Policy routing routing debugging debugging is is on on Router#ping Router#ping 192.168.1.1 192.168.1.1 Type Type escape escape sequence sequence to to abort. abort. Sending Sending 5, 5, 100-byte 100 -byte ICMP ICMP Echos Echos to to 192.168.1.1, 192.168.1.1, timeout timeout is is 22 seconds: seconds: !!!!! !!!!! Success Success rate rate is is 100 100 percent percent (5/5), (5/5), round-trip round -trip min/avg/max min/avg/max == 28/31/32 28/31/32 ms ms Router# Router# 2d02h: 2d02h: IP: IP: s=192.168.1.2 s=192.168.1.2 (local), (local), d=192.168.1.1, d=192.168.1.1, len len 100, 100, policy policy match match 2d02h: 2d02h: IP: IP: route route map map CPE, CPE, item item 20, 20, permit permit ... ...
© 2001, Cisco Systems, Inc.
Classification and Marking -17
The debug ip policy command is similar to the debug ip packet except that the debug ip policy only displays policy-routed packets. This command should be used with caution as it may produce too much output.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-15
IP Precedence Marking Case Study #1 • Branch office of a bank has two LANs connected to an access router • Ethernet0 is the front office with the real time transactions • Ethernet1 is the back office with non-real time transactions (like e-mail)
• The network provides different services to two classes: • Business traffic (marked with IP precedence 2) • Other traffic (marked with IP precedence 0)
• Packets coming from Ethernet 0 should be classified and marked as Business traffic • Packets coming from Ethernet 1 should be classified and marked as Other traffic © 2001, Cisco Systems, Inc.
Classification and Marking -18
The case study involves a bank branch office where a single router connects two LANs to the corporate network via one serial interface. This case study focuses on the classification and marking part of a larger QoS solution, which includes other QoS mechanisms.
2-16
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Case #1- Solution Mark all traffic with precedence 2 E0
Mark all traffic with precedence 0 WAN core
interface interface ethernet ethernet 0 ip policy-map policy-map set-prec-2 set-prec-2 Core E1 !! interface ethernet ethernet 1 Branch interface policy-map set-prec-0 set-prec-0 office ip policy-map !! route-map route-map set-prec-2 set-prec-2 permit permit 10 10 set ip ip precedence 2 !! route-map route-map set-prec-0 set-prec-0 permit permit 10 10 set ip ip precedence 0
© 2001, Cisco Systems, Inc.
Classification and Marking -19
Policy-based routing can be used to mark packets with IP precedence values. All packets from Ethernet 0 are marked with IP precedence 2. Since matching is applied to all packets no “match” command is needed in the route map. The other route map is applied to the other Ethernet interface and it marks packets with IP precedence 0.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-17
IP Precedence Marking Case Study #2 • Branch office of a bank has one LAN connected to an access router • The network provides different services to three classes: • Transaction traffic (marked with IP precedence 2) • Business traffic (marked with IP precedence 1) • Other traffic (marked with IP precedence 0)
• TN3270 should be marked as Transaction traffic • Internal HTTP should be marked as Business traffic • All other traffic should be marked as Other traffic
© 2001, Cisco Systems, Inc.
Classification and Marking -20
The second case study is more complicated because classification is not done based on the input interface. Instead, classification if performed based on application (TCP or UDP port numbers).
2-18
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Case #2 - Solution
E0
WAN core
Core
interface interface eth eth 0 0
Mark Mark IP IP precedence: precedence: Telnet Telnet = 22 Corporate Corporate Web Web == 1 everything everything else else == 0
ip ip policy-map policy-map set-prec set-prec Branch !! office route-map set-prec route-map set-prec permit permit
10 10 match match ip ip address address CorporateWebTraffic CorporateWebTraffic set set ip precedence 11 route-map route-map set-prec set-prec permit permit 20 20 match match ip ip address address TN3270 TN3270 set set ip precedence 22 route-map route-map set-prec set-prec permit permit 30 30 set set ip precedence 00 !! ip ip access-list access-list extended extended CorporateWebTraffic CorporateWebTraffic permit permit tcp tcp any any 10.1.1.0 10.1.1.0 0.0.0.255 0.0.0.255 eq eq www www ip ip access-list access-list extended extended TN3270 TN3270 permit permit tcp tcp any any any any eq eq telnet telnet
© 2001, Cisco Systems, Inc.
Classification and Marking -21
A route map is created with three statements, one for each application: n
The first statement uses an access list to identify corporate web traffic (destination port 80). IP precedence 1 is applied to these packets.
n
The second statement uses another access list to identify outbound telnet sessions. IP precedence 2 is applied to these packets.
n
The last statement sets IP precedence 0 to all other packets.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-19
Route Map - Review • Policy routing with route maps can classify and mark IP packets based on a wide variety of conditions • No metering, shaping or dropping is possible • Performance depends on the IOS version – Policy routing is fast -switched in 11.3 and 12.0 – (d)CEF or Net Flow-switched in 12.0(3)T
© 2001, Cisco Systems, Inc.
Classification and Marking -22
Policy-based Routing features:
2-20
n
Static classification and marking (no metering, shaping, policing or dropping is possible).
n
PBR has performance limitations due to implementation (complex access lists can degrade performance, sub-optimal order of statements can also degrade performance due to sequential processing) and the IOS version (newer IOS versions support fast-switched operation of PBR).
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Summary Policy based routing is used for two purposes: n
Bypassing the traditional destination-based forwarding
n
Marking of IP packets with Ip precedence or QoS group
n
What are the applications of Policy-based Routing?
n
What configuration tool is used to implement PBR?
n
How can PBR be applied to IP traffic?
n
Describe the classification options with PBR.
n
Describe the marking options with PBR.
Lesson Review
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-21
QoS Policy Propagation through BGP (QPPB) Objectives Upon completion of this lesson, you will be able to:
2-22
n
Describe the QPPB mechanism
n
Configure the QPPB mechanism on Cisco routers
n
Monitor and troubleshoot QPPB
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
IP QoS Policy Propagation Through BGP (QPPB) • QPPB uses BGP attributes to advertise class of service to other routers in the network • BGP Communities are usually used to propagate class of service information bound to IP networks • Packet classification policy can be propagated via BGP without having to use complex access lists at each of a large number of border (edge) routers • A route map is used to translate BGP information (e.g. BGP Community value) into IP precedence or QoS group
© 2001, Cisco Systems, Inc.
Classification and Marking -27
QoS Policy Propagation through BGP is a mechanism that can be split into two parts: n
Policy propagation via BGP, where a QoS policy is encoded into a BGP attribute. BGP Communities are typically used to encode a QoS policy.
n
Marking of packets with IP precedence or QoS group based on the QoS policy learned via BGP.
BGP Policy is usually set on ingress routers (ingress for route propagation, egress for packet forwarding) in an Autonomous System. BGP then carries the information to other routers in the AS and translates (using a route map) this information into IP precedence or QoS group. Marking is then enabled on perinterface basis.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-23
QPPB Capabilities QPPB can only classify and mark inbound packets
Meter
Inbound or Locally-originated
Classifier
Marker
Dropper
Forwarding Outbound
Meter
Classifier
© 2001, Cisco Systems, Inc.
Marker
Shaper Dropper
Queuing
Classification and Marking -28
Similar to PBR, QPPB also supports classification and marking only on the input interface.
2-24
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
BGP Marking Meter Inbound traffic stream
Classifier
Marker
Dropper
1. Propagate the class of service by encoding it into BGP attributes: • • • •
BGP communities, AS paths, IP prefixes or any other BGP attribute
2. Translate the selected BGP attribute into either: • IP precedence or • QoS group
3. Enable Cisco Express Forwarding (CEF) and packet marking on interfaces © 2001, Cisco Systems, Inc.
Classification and Marking -29
QoS policy can be applied to source or destination IP addresses or networks. When BGP entries are inserted into the routing table a route map is used to translate a certain BGP parameter or attribute into IP precedence or QoS group. Packet marking is then enabled on input interfaces.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-25
Cisco Express Forwarding Review • The two main components of CEF operation – Forwarding Information Base – Adjacency Tables
• CEF was first introduced on the following platforms: – Cisco 7x00 series in 11.1CC – All RISC-based platforms in IOS 12.0
• QPPB is only supported on high-end routers (Cisco 7x00 and above)
© 2001, Cisco Systems, Inc.
Classification and Marking -30
QPPB has the following requirements:
2-26
n
Cisco Express Forwarding (CEF)
n
A high end platform (Cisco 7x000 routers)
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Review: Standard IP Switching BGP table
IP routing table
Switching cache
ARP cache
Address 10.0.0.0 ...
Protocol BGP conn.
Address 10.0.0.0 ...
IP address 1.2.3.4 ...
© 2001, Cisco Systems, Inc.
Prefix /8 ...
Address 10.0.0.0 1.2.3.0
Prefix /8 ...
AS-Path 42 13 ...
Prefix /8 /24
Next hop 1.2.3.4 ...
Next-hop 1.2.3.4 ---
Communities 37:12 ...
Other attr. ...
Outgoing interface --Ethernet 0
L2 header MAC header ...
MAC address 0c.00.11.22.33.44 ... Classification and Marking -31
The figure illustrates how BGP routing information is used on routers that are configured with the default switching operation: n
A BGP entry is inserted into the main routing table (the network points to the BGP next-hop address.
n
A recursive routing lookup is needed when the first packet arrives. After the output interface is identified, a cache entry is generated. Multi-access media requires additional information from the ARP cache.
n
The subsequent packets are forwarded using the fast-switching cache.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-27
Review: CEF Switching BGP table
IP routing table
FIB table (CEF cache)
Address 10.0.0.0 ...
Protocol BGP OSPF conn.
Address 10.0.0.0 ...
IP address Adjacency 1.5.4.1 table ...
Prefix /8 ...
Address 10.0.0.0 1.2.3.0 1.5.4.0
Prefix /8 ...
AS-Path 42 13 ...
Prefix /8 /24 /24
Next hop 1.2.3.4 ...
Next-hop 1.2.3.4 1.5.4.1 ---
Communities 37:12 ...
Other attr. ...
Outgoing interface --Ethernet 0 Ethernet 0
Adjacency pointer 1.5.4.1 ...
Layer 2 header MAC header ...
ARP cache IP address MAC address 1.5.4.1 0c.00.11.22.33.44 ... ...
© 2001, Cisco Systems, Inc.
Classification and Marking -32
CEF switching is different from the default operation in the following ways:
2-28
n
CEF switching cache (the FIB table and the adjacency table) reflects the information from the main routing table. Changes in the FIB table are not triggered by packets but by changes in the main routing table itself.
n
The CEF switching cache is split into two tables: n
Forwarding Information Base (FIB) which contains all networks that are taken from the routing table. Those entries point to directly accessible next-hops. Adjacency pointers are used to get information about these next-hops from the Adjacency table
n
Adjacency table contains a list of directly connected neighboring IP devices. A layer-2 header is created in advance to accelerate the encapsulation process.
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
CEF Switching with QoS Packet Marking BGP table
IP routing table
FIB table (CEF cache)
Address 10.0.0.0 ...
Protocol BGP OSPF conn.
Address 10.0.0.0 ...
IP address Adjacency 1.5.4.1 table ...
Prefix /8 ...
Address 10.0.0.0 1.2.3.0 1.5.4.0
Prefix /8 ...
AS-Path 42 13 ...
Prefix /8 /24 /24
Next hop 1.2.3.4 ...
Next-hop 1.2.3.4 1.5.4.1 ---
Adjacency pointer 1.5.4.1 ...
Layer 2 header MAC header ...
Communities Other attr. 37:12 BGP table... map ...
Outgoing interface Precedence QoS group --3 7 Ethernet 0 ----Ethernet 0 -----
Precedence QoS group 3 7 ... ... ARP cache IP address MAC address 1.5.4.1 0c.00.11.22.33.44 ... ...
© 2001, Cisco Systems, Inc.
Classification and Marking -33
When using CEF for packet marking a table map is used in the BGP configuration mode to process routes inserted into the routing table. A route map (used as a table map in BGP) can translate any BGP parameter or attribute into IP precedence or QoS group. This information is then passed on to the FIB table. Once packet marking is enabled the router will perform two CEF lookups: n
The first lookup is used to mark packets
n
The second lookup is used to make a forwarding decision
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-29
QPPB Configuration Tasks • Create a route map to set IP precedence or QoS group • Apply the route map to BGP routes transferred to main IP routing table • Enable per-interface packet marking
© 2001, Cisco Systems, Inc.
Classification and Marking -34
Before configuring routers to support QPPB, a QoS design, which must include the following, is needed: n
BGP attribute used to encode class of service (BGP Communities are usually used)
n
Marker (when using QPPB only IP precedence or QoS group can be used)
The following configuration steps are necessary on routers that perform packet marking:
2-30
n
Enable CEF
n
Create a route map that translates a BGP attribute into IP precedence or QoS group
n
Apply the route map to process BGP routes before they are entered into the main routing table.
n
Enable per interface marking.
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Setting IP Precedence or QoS Group in the IP Routing Table Router(config-router)#
table-map
• Specifies the route map used to set additional routing table attributes Router(config)#
route-map permit <seq> set ip precedence <precedence> set ip qos-group
• Specifies IP precedence and QoS group values in the routing table/FIB table entry
© 2001, Cisco Systems, Inc.
Classification and Marking -35
Use the table -map command in the BGP configuration mode to populate the main routing table with the class of service information. A route map can “tag” networks with IP precedence, QoS group or both.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-31
Enable Per-interface Packet Marking Router(config-if)#
bgp-policy source ip-prec-map
• Applied to packets received through this interface • Uses FIB to map packet source IP address to IP precedence • Rewrites IP precedence in the packet Router(config-if)#
bgp-policy source ip-qos-map
• Applied to packets received through this interface • Uses FIB to map packet source IP address to QoS group • QoS group attached to the incoming packet © 2001, Cisco Systems, Inc.
Classification and Marking -36
Once the FIB table contains the class of service information (IP precedence or QoS group), marking can be configured on input interfaces. CEF-based marking is performed based on the following:
2-32
n
Find the source address (taken from the packet being marked) in the FIB table and mark it with the IP precedence value attached to the address/network. Use the bgp-policy source ip-prec-map interface command to mark the packet.
n
Find the source address (taken from the packet being marked) in the FIB table and mark it with the QoS group value attached to the address/network. Use the bgp-policy source ip-qos-map interface command to mark the packet.
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Enable Per-interface Packet Marking Router(config-if)#
bgp-policy destination ip-prec-map
• Applied to packets received through this interface • Uses FIB to map packet destination IP address to IP precedence • Rewrites IP precedence in the packet Router(config-if)#
bgp-policy destination ip-qos-map
• Applied to packets received through this interface • Uses FIB to map packet destination IP address to QoS group • QoS group attached to the incoming packet © 2001, Cisco Systems, Inc.
Classification and Marking -37
n
Find the destination address (taken from the packet being marked) in the FIB table and mark it with the IP precedence value attached to the address/network. Use the bgp-policy destination ip-qos-map interface command to mark the packet.
n
Find the destination address (taken from the packet being marked) in the FIB table and mark it with the QoS group value attached to the address/network. Use the bgp-policy destination ip-qos-map interface command to mark the packet.
All four commands can be attached to the same interface (although not recommended) and they are processed in the following order: n
Source-based IP precedence marking
n
Source-based QoS group marking
n
Destination-based IP precedence marking (overrides source-based marking)
n
Destination-based QoS group marking (overrides source-based marking)
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-33
Case Study
WAN core NAP router
NAP router
POP router
AS 24
AS 12
Customer (AS 73)
Create an end-to-end IP QoS solution in a Service Provider network: • Customer in AS 73 is a Premium customer • All packets to and from AS 73 shall be sent with precedence flash © 2001, Cisco Systems, Inc.
Classification and Marking -38
This case study shows how customer networks can be marked with a BGP community identifying a class of service, which is then propagated throughout the Autonomous System 12 and used on edge routers to classify and mark packets towards the customer networks with IP precedence flash (IP precedence 3). Each IP precedence value is also identified by a name:
2-34
IP QoS Classification and Marking
IP precedence value
IP precedence name
0
Routine
1
Priority
2
Immediate
3
Flash
4
Flash-override
5
Critical
6
Internet
7
Network
Copyright 2001, Cisco Systems, Inc.
Step #1 Distribute QoS functions
WAN core NAP router
NAP router
AS 24
POP router
AS 12
Customer (AS 73)
packets for AS73 marked with precedence flash packets from serial interface marked with precedence flash © 2001, Cisco Systems, Inc.
Classification and Marking -39
To achieve the same level of quality in both directions the packets going to and coming from the customer network must first be classified and marked. Classification and marking of packets coming from the customer network is trivial: n
PBR without a match statement is used on the interface connection from the customer network to the ISP’s network.
n
Another option is to use other mechanisms such as Committed Access Rate (CAR), Class-based Policing or Class-based Marking.
Classifying and marking packets going to the customer network is a more difficult task because: n
Classifying and marking must be performed on all edge routers.
n
Classifying and marking requires the identification of the customer network. Using PBR, CAR, CB-Policing or CB-Marking does not scale because it involves the use of access lists (this is especially difficult if customer networks are dynamically learned via BGP).
QPPB is the only scalable mechanism that can classify and mark packets based on their source or destination IP address.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-35
Step #2 Select QoS mechanisms
WAN core NAP router
NAP router
POP router
AS 24
AS 12
Customer (AS 73)
CEF-based marking packets for AS73 marked with precedence flash
PBR on interface
packets from serial interface marked with precedence flash © 2001, Cisco Systems, Inc.
Classification and Marking -40
The case study will employ PBR to do the marking of outbound packets (from the customer perspective). QPPB will be used to mark inbound packets on remote edge (border) routers.
2-36
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Step #3 - Design Individual QoS Mechanisms Mark BGP routes from AS 73 with special community (12:17) Configure community propagation
WAN core NAP router
AS 24
NAP router
POP router
Customer ASSet 12 FIB table (AS 73) on based
BGP community Configure CEF packet marking for packets coming from adjacent AS © 2001, Cisco Systems, Inc.
Classification and Marking -41
Customers networks are tagged with BGP Community 12:17 and sent to all internal BGP neighbors. Edge routers use a table map to translate BGP Community 12:17 into IP precedence 3. Destination-based precedence marking is enabled on interfaces connecting the AS to other ASs.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-37
Mark Routes Coming From AS 73
WAN core NAP router
NAP router
AS 24
POP router
AS 12
Customer (AS 73)
router bgp 12 neighbor 1.2.3.4 remote-as 73 neighbor 1.2.3.4 route-map Premium in ! route-map Premium permit 10 set community 12:17 additive
© 2001, Cisco Systems, Inc.
Classification and Marking -42
The figure illustrates how a route map is used to process inbound BGP routing updates coming from the customer’s AS 73. The BGP community attribute 12:17 is added to the routing updates.
2-38
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Configure Community Propagation
WAN core NAP router
NAP router
AS 24
POP router
AS 12
Customer (AS 73)
router bgp 12 neighbor 2.3.4.5 remote-as 12 neighbor 2.3.4.5 send-community
© 2001, Cisco Systems, Inc.
Classification and Marking -43
BGP Community propagation is not enabled by default. It is, therefore, necessary to use the send-community option on all internal BGP sessions to allow BGP Communities to be propagated throughout the autonomous system.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-39
Set FIB Table Based on BGP Community
WAN core NAP router
AS 24
© 2001, Cisco Systems, Inc.
NAP router
POP router
router bgp 12 Customer table-map PremiumCheck AS 12 (AS 73) ! route-map PremiumCheck permit 10 match community 17 set ip precedence flash ! route-map PremiumCheck permit 20 set ip precedence 0 ! ip community-list 17 permit 12:17
Classification and Marking -44
The edge routers use route maps to translate BGP Community values into appropriate IP precedence values. The figure illustrates how all routes carrying BGP community 12:17 are tagged with IP precedence 3 in the routing table and the FIB table. All other networks are tagged with IP precedence 0. Note
2-40
IP QoS Classification and Marking
Setting IP precedence 0 on all packets not specifically matched by a table map is also a security feature because it prevents IP precedence spoofing. Anyone trying to use a high IP precedence value (e.g. 6 or 7) will be remarked with IP precedence 0 and get the best-effort service.
Copyright 2001, Cisco Systems, Inc.
Configure CEF Packet Marking
WAN core NAP router
AS 24
NAP router
POP router
AS 12
Customer (AS 73)
ip cef ! interface hssi 0/0 bgp-policy destination ip-prec-map !
© 2001, Cisco Systems, Inc.
Classification and Marking -45
The last configuration step is to enable CEF-based marking on border interfaces. The case study requires that all packets going to (destination-based marking) the customer’s network be marked with IP precedence 3. QPPB marking is only available in combination with CEF switching. The global ip cef command enables CEF switching on all interfaces that support CEF.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-41
IP QoS and BGP Interaction Review • IP QoS features work independently of BGP routing • BGP is used only to propagate policies for source or destination IP prefixes through the network • QPPB works only on high-end platforms
© 2001, Cisco Systems, Inc.
Classification and Marking -46
Although QPPB support is only available on high-end routers there is no limitation when it comes to tagging BGP routes. Only marking routers have to support QPPB: all other routers simply have to support BGP.
2-42
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Summary QPPB is a mechanism that is used to implement more scalable QoS solutions. It uses BGP to propagate QoS policy information and CEF to mark packets with IP precedence or QoS group.
Lesson Review n
Why is QPPB needed?
n
How is QoS policy propagated through a network?
n
How are QoS traffic classes defined by QPPB?
n
Which IP forwarding mechanisms support QPPB?
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-43
Other QoS Mechanisms with Classification and Marking Capability Objectives Upon completion of this lesson, you will be able to:
2-44
n
Explain how most QoS mechanisms support some type of classification
n
Name CAR, CB-Policing and CB-Marking as mechanisms that support classification and marking
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Classification • Most QoS mechanisms include some type of classification • Some mechanisms have automatic classification (e.g. WFQ, WRED, ...) • Some mechanisms require manual configuration of classification (e.g. CQ, PQ, CB-WFQ, ...)
© 2001, Cisco Systems, Inc.
Classification and Marking -51
Most QoS mechanisms include some type of classification: n
Some mechanisms classify packets automatically. Weighted Fair Queuing (WFQ), for instance, classifies packets into flows. Weighted Random Early Detection (WRED) classifies packets based on their IP precedence values, etc.
n
Other mechanisms require manual configuration of classification.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-45
Marking The following mechanism (in addition to PBR and QPPB) contain classification and marking capability : • Committed Access Rate (CAR) • Class-based Policing • Class-based Marking
© 2001, Cisco Systems, Inc.
Classification and Marking -52
Only a few remaining mechanisms have marking capabilities: n
Committed Access Rate (CAR), which is used for traffic policing
n
Class-based Policing, which is also used for traffic policing
n
Class-based Marking, which is used for classification and marking purposes only. It may however be combined with other mechanisms available with the Modular QoS CLI
CAR and Class-based Policing are discussed in detail in the “IP QoS – Traffic Shaping and Policing” module. Class-based Marking is discussed in detail in the “IP QoS – Modular QoS CLI (Service Policy)” module. This module includes a high-level overview of these QoS mechanisms.
2-46
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Committed Access Rate (CAR) • CAR is a mechanism used for traffic policing • CAR uses a token bucket model to measure the rate of traffic and (optionally) drop excess traffic • CAR can also be used to mark packets with: – – – –
IP precedence DiffServ Code Point (DSCP) MPLS experimental bits QoS group
• CAR can mark packets with different values depending on whether they conform or exceed the specified policy
© 2001, Cisco Systems, Inc.
Classification and Marking -53
CAR is a mechanism used to limit the traffic rate of a class and optionally mark packets with one of the following markers: n
IP precedence
n
DSCP
n
MPLS experimental bits
n
QoS group
CAR can also mark packets with two different values depending on whether they: n
Conform to the policy (packet is within the contractual bit-rate)
n
Exceed the policy (packet is over the contractual bit-rate)
Conforming and exceeding packets can be marked with different values.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-47
Class-based Policing • Class-based Policing is similar to CAR except it is implemented using the modular QoS CLI • CB-Policing uses two token buckets to determine if packets conform, exceed or violate the QoS policy • CB-Policing can also be used to mark packets with: – – – – – –
IP precedence DiffServ Code Point (DSCP) MPLS experimental bits QoS group ATM CLP bit Frame Relay DE bit
• CB-Policing can mark packets with different values depending on whether they conform, exceed or violate the policy © 2001, Cisco Systems, Inc.
Classification and Marking -54
Class-based Policing (CB-Policing) is a mechanism similar to CAR with the following main differences: n
Modular QoS CLI is used to implement CB-Policing on Cisco routers
n
CB-Policing supports more marking options than Committed Access Rate
n
CB-Policing uses two token buckets to identify not just conforming and exceeding packets but also violating packets.
Class-based policing can mark packets with three different values depending on whether they conform, exceed or violate the policy. Class-based Marking can mark packets with the following markers:
2-48
n
IP precedence
n
DSCP
n
MPLS experimental bits
n
QoS group
n
ATM CLP bit
n
Frame Relay DE bit
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Class-based Marking • Class-based Marking is used to classify and mark packets • This mechanism uses the modular QoS CLI where classes are manually configured • Class-based Marking can mark packets with the following markers: – – – – – – –
IP precedence DSCP MPLS experimental bits QoS group ATM CLP bit Frame Relay DE bit IEEE 802.1Q or ISL’s CoS
© 2001, Cisco Systems, Inc.
Classification and Marking -55
Class-based Marking is also implemented using the Modular QoS CLI. It supports the following markers: n
IP precedence
n
DSCP
n
MPLS experimental bits
n
QoS group
n
ATM CLP bit
n
Frame Relay DE bit
n
IEEE 802.1Q or ISL cos/priority bits
Class-based marking can be combined with other mechanisms available in the Modular QoS CLI.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-49
Summary The following mechanisms are used for classification and marking purposes: n
Policy-based Routing (PBR)
n
QoS Policy Propagation through BGP (QPPB)
n
Committed Access Rate (CAR)
n
Class-based Policing
n
Class-based Marking
PBR is a mechanism that was primarily intended for bypassing the destinationbased forwarding and marking packets with IP precedence or QoS group. QPPB is a mechanism that can also be used to mark packets with IP precedence or QoS group. Its main advantage is scalability.
Lesson Review
2-50
n
Which mechanisms in IOS support classification and marking of packets?
n
Which fields or parameters can be used to mark packets in Cisco IOS?
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Summary After completing this module, you should be able to perform the following tasks: n
Describe Policy-based routing and how it is used to classify and mark IP packets
n
Describe QoS Policy Propagation through BGP and how it is used to classify and mark IP packets
n
List other mechanisms that also support classification and marking capabilities (Committed Access Rate, Class-based Marking)
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-51
Review
Questions and Answers Policy-based Routing Question: What are the applications of Policy-based Routing? Answer: PBR is used to bypass the destination-based forwarding or to classify and mark packets. Question: What configuration tool is used to implement PBR? Answer: Route maps are used to implement PBR. Question: How can PBR be applied to IP traffic? Answer: PBR can be applied to input packets or packets originated by the router. Question: Describe the classification options with PBR. Answer: PBR’s classification options include standard and extended access lists as well as packet size based classification. PBR can also classify based on the input interface because it is used on per-interface basis. Question: Describe the marking options with PBR. Answer: PBR can set the next-hop address or output interface to bypass the default destination based forwarding. PBR can also mark packets with the following options: ToS bits, IP precedence or QoS group.
QoS Policy Propagation through BGP (QPPB)
Question: Why is QPPB needed? Answer: QPPB can propagate a QoS class of service information throughout an autonomous system. This allows more scalable QoS designs where classification is performed on one router and automatically propagated to all other routers in the AS.
Question: How is QoS policy propagated through a network? Answer: BGP is used to propagate the CoS by encoding it into any available BGP attribute.
Question: How are QoS traffic classes defined by QPPB? Answer: QPPB is limited to assigning IP networks to traffic classes. Question: Which IP forwarding mechanisms support QPPB? Answer: QPPB requires CEF switching to mark packets with IP precedence or QoS group.
2-52
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Other QoS Mechanisms with Classification and Marking Capability
Question: Which mechanisms in IOS support classification and marking of packets?
Answer: Policy-based Routing (PBR) Committed Access Rate (CAR) QoS Policy Propagation through BGP (QPPB) Class-based Policing Class based Marking
Question: Which fields or parameters can be used to mark packets in Cisco IOS? Answer: IP precedence, DSCP, MPLS experimental bits, QoS group, Frame Relay DE bit, ATM CLP bit, 802.1q CoS bits, ISL priority bits.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-53
Queuing Mechanisms
Overview This module describes the queuing mechanisms that can be used on output interfaces. It includes the following topics: n
Queuing Overview
n
FIFO Queuing
n
Priority Queuing
n
Custom Queuing
n
Weighted Fair Queuing
n
Distributed Weighted Fair Queuing
n
Modified Deficit Round-robin
n
IP RTP Prioritization
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe and configure FIFO Queuing (FQ)
n
Describe and configure Priority Queuing (PQ)
n
Describe and configure Custom Queuing (CQ)
n
Describe and configure basic Weighted Fair Queuing (WFQ), distributed WFQ, ToS-based distributed WFQ and QoS-group-based distributed WFQ
n
Describe and configure Modified Weighted Round-robin (MDRR) queuing
n
Describe and configure IP RTP Prioritization
Queuing Overview Objectives Upon completion of this lesson, you will be able to perform the following tasks:
3-2
Queuing Mechanisms
n
Understand how queuing works on Cisco routers
n
List the most used queuing mechanisms
Copyright 2001, Cisco Systems, Inc.
Queuing in Cisco IOS • Cisco routers running Cisco IOS have a number of different queuing mechanisms • This module focuses on the following: – First In First Out (FIFO) – Priority Queuing (PQ) – Custom Queuing (CQ) – Weighted Fair Queuing (WFQ) with the different distributed versions – Modified Deficit Round Robin (MDRR) – IP RTP Prioritization • These mechnisms are implemented as software queues © 2001, Cisco Systems, Inc.
Queuing Mechanisms -5
The lesson discusses how output queuing mechanisms are implemented on Cisco routers running Cisco IOS. It discusses most of the queuing mechanisms in detail, except Class-based Weighted Fair Queuing and Class-based Low-latency Queuing, which are discussed in the “IP QoS – Modular QoS CLI (Chapter 2)” module.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-3
Output Interface Queue Structure
Forwarder
Software Queuing System
Any supported queuing mechanism
Hardware Queue (TxQ)
Output Interface
Always FIFO
• Each Interface has its hardware and software queuing system • The hardware queuing system always uses FIFO queuing (Transmission queue or TxQ) • The software queuing system can be selected and configured depending on the platform and Cisco IOS version © 2001, Cisco Systems, Inc.
Queuing Mechanisms -6
Queuing on routers is necessary to accommodate bursts when the arrival rate of packets is greater than the departure rate due to one of the following two reasons: n
Input interface is faster than the output interface
n
Output interface is receiving packets coming in from multiple other interfaces
Initial implementations of queuing used a single FIFO (first-in first-out or first-come first-serve queuing) strategy. More complex queuing mechanisms were introduced when special requirements need routers to differentiate between packets of different importance. Queuing was split into two parts: n
The hardware queue that still uses FIFO strategy, which is necessary for the interface drivers to transmit packets one by one. The hardware queue is sometimes referred to as the transmit queue or TxQ.
n
The software queue that schedules packets into the hardware queue based on the QoS requirements
Listed on the previous graphic are some of the available software queuing strategies with their goals:
3-4
Queuing Mechanisms
n
FIFO: no differentiation of packets (true fairness but no guarantees)
n
Priority Queuing (PQ): strict prioritizing of packets
n
Custom Queuing (CQ): service (bandwidth) guaranteed to up to 16 classes
n
Weighted Fair Queuing (WFQ) and Distributed WFQ: service (bandwidth) guarantee to individual flows
n
Distributed ToS-based WFQ: service (bandwidth) guaranteed to up to 4 classes
Copyright 2001, Cisco Systems, Inc.
n
Distributed QoS-group-based WFQ: service (bandwidth) guaranteed to up to 100 classes
n
Modified Deficit Round-robin (MDRR): service (bandwidth) guaranteed to up to 8 classes; low-delay guarantee if Strict or Alternate Priority is used
n
IP RTP Prioritization: low-delay guarantee
Most queuing mechanisms depend on the availability on different platforms and Cisco IOS versions. For example: n
MDRR is only available on Cisco 12000 series routers (GSR)
n
Distributed ToS-based and QoS-group-based WFQ are only available on Cisco 7x00 series routers with Versatile Interface Processors (VIP)
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-5
Bypassing the Software Queue
Software Queue Empty?
No
Yes
Hardware Queue Full?
Hardware Queue (TxQ)
No
Yes
Software Queuing System
• When a packet is being forwarded the router will bypass the software queue if:
– the software queue is empty and – the hardware queue is not full © 2001, Cisco Systems, Inc.
Queuing Mechanisms -7
The implementation of software queuing was optimized for periods when the interface is not congested. The software queuing system is bypassed whenever there is no packet in the software queue and there is room in the hardware queue. The software queue is, therefore, only used when data must wait to be placed into the hardware queue.
3-6
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Hardware Queue (TxQ) Size • Routers determine the length of the hardware queue based on the configured bandwidth of the interface • Long TxQ may result in poor performance of the software queue • Short TxQ may result in a large number of interrupts which causes high CPU utilization and low link utilization
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -8
The double queuing strategy (software and hardware queue) has its impacts on the result of overall queuing: n
Software queue is used for a certain reason. If the hardware queue is too long it will contain a large number of packets scheduled in the FIFO fashion. This is probably against the QoS design that required a certain complex software queuing system (for example, Custom Queuing).
So why use the hardware queue at all? Or why not just set its length to one? That would force all packets to go through the software queue and be scheduled one by one to the interface for transmission. This approach has the following drawbacks: n
Each time a packet is transmitted, the interface driver interrupts the CPU and requests more packets to be delivered into its hardware queue. Some queuing mechanisms have complex scheduling that takes time to deliver more packets. The interface does not send anything during that time (link utilization is decreased) if the hardware queue is empty because its maximum size is one.
n
The CPU schedules packets one by one instead of many at the same time (in the same interrupt interval). This increases the CPU utilization.
Choosing the appropriate length of the hardware queue is very important. The default TxQ size is determined by the IOS based on the bandwidth of the media and should be fine for most queuing implementations. Faster interfaces have longer hardware queues because they produce less delay. Slower interfaces have shorter hardware queues to prevent too much delay in the worst-case scenario where the entire hardware queue is full of MTU-sized packets.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-7
Queuing Components Forwarded Packets Software Queuing System Class 1?
Add/Drop
Queue 1
Class 2?
Add/Drop
Queue 2
Hardware Queuing System Scheduler
Class n?
Add/Drop
Hardware Q
Interface
Queue n
• Each queuing mechanism has three main components that define it: – Classification (selecting the class) – Insertion policy (determining whether a packet can be enqueued) – Service policy (scheduling packets to be put into the hardware queue) © 2001, Cisco Systems, Inc.
Queuing Mechanisms -9
The figure illustrates the actions that have to be taken before a packet can be transmitted: n
Most queuing mechanisms include classification of packets.
n
Once a packet is classifie d, a router has to determine whether it can put the packet into the queue or it has to drop the packet. Most queuing mechanisms will drop a packet only if the corresponding queue is full (tail-drop). Some mechanisms use a more intelligent dropping scheme (Weighted Fair Queuing) or a random dropping scheme (Weighted Random Early Detection).
n
If the packet is allowed to be enqueued it will be put into the FIFO queue for that particular class.
n
Packets are then taken from the individual per-class queues and put into the hardware queue.
Queuing systems differ in the following ways:
3-8
Queuing Mechanisms
n
Classification options: some mechanisms classify packets automatically (for example, WFQ), while other mechanisms require manual configuration of classification (for example, PQ or CQ).
n
Insertion policy: most queuing mechanisms use the tail-dropping scheme.
n
Scheduling policy: this is the most important part of every queuing mechanism because it determines the order in which the packets will leave the router.
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Understand how queuing works on Cisco routers
n
List the most used queuing mechanisms
Review Questions Answer the following questions: n
Which queuing mechanisms do Cisco routers support?
n
When is a software queuing mechanisms not used?
n
How does TxQ length affect the software queuing system?
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-9
FIFO Queuing Objectives Upon completion of this lesson, you will be able to perform the following tasks:
3-10
Queuing Mechanisms
n
Describe FIFO queuing
n
Describe the drawbacks of FIFO queuing
n
Configure FIFO queuing on Cisco routers
n
Monitor and troubleshoot FIFO queuing
Copyright 2001, Cisco Systems, Inc.
FIFO Queuing Forwarded Packets FIFO Queuing System
All in one queue
Tail-drop
Queue 1
Hardware Queuing System FIFO Scheduler
Hardware Q
Interface
Routers serve packets in the first-come first-serve fashion FIFO uses one single queue
All packets are classified into one class
Newly arriving packets are dropped if the queue is full
• Software FIFO queue is basically an extension to the hardware FIFO queue © 2001, Cisco Systems, Inc.
Queuing Mechanisms-14
FIFO queuing has no classification because all packets belong to the same class. Packets are dropped when the output queue is full (tail-drop). The scheduler services packets in the order they arrived. Software FIFO queue is basically an extension of the hardware FIFO queue.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-11
Benefits and Drawbacks of FIFO Queuing + Benefits • Simple and fast (one single queue with a simple scheduling mechanism) • Supported on all platforms • Supported in all switching paths • Supported in all IOS versions
– Drawbacks • Unfair allocation of bandwidth among multiple flows • Causes starvation (aggressive flows can monopolize links) • Causes jitter (bursts or packet trains temporarily fill the queue) © 2001, Cisco Systems, Inc.
Queuing Mechanisms-15
FIFO queuing might be regarded as the fairest queuing mechanism but it has a long list of drawbacks: n
FIFO does not fairly allocate bandwidth among multiple flows. Some flows receive more bandwidth because they use larger packets or send more packets.
n
FIFO is extremely unfair when an aggressive flow is contesting with a fragile flow. Aggressive flows send a large number of packets, many of which are dropped. Fragile flows send a modest amount of packets and most of them are dropped because the queue is always full due to the aggressive flow. This type of behavior is called starvation.
n
Short or long bursts cause a FIFO queue to fill. Packets entering an almost full queue have to wait a long time before they can be transmitted. Another time, the queue might be empty causing packets of the same flow to experience almost no delay. Variation in delay is called jitter.
In spite of all the drawbacks FIFO is still the most used queuing mechanism because of the following benefits:
3-12
Queuing Mechanisms
n
It is simple and fast. Most high-end routers with fast interfaces are not really challenged by the drawbacks mentioned earlier. Furthermore, routers are not capable of complex classification and scheduling when they have to process a large number of packets per second. FIFO is, therefore, the most suitable queuing mechanisms on these platforms.
n
It is supported on all platforms.
n
It is supported in all IOS versions.
Copyright 2001, Cisco Systems, Inc.
Configuring FIFO Queuing Router(config-if)#
no fair-queue fair-queue
• FIFO queuing is enabled by default on all interfaces that have a default bandwidth of more than 2Mbsp • Weighted Fair Queuing is enabled if the bandwidth is less than 2Mbps • Disable WFQ to enable FIFO on interfaces that have less than 2Mbps of bandwidth
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-16
Cisco routers have two default queuing mechanisms: n
All interfaces with the default bandwidth above 2Mbps use FIFO queuing. No configuration is necessary on such interfaces.
n
All interfaces with the default bandwidth below 2Mbps use Weighted Fair Queuing (WFQ). The no fair-queue command must be used to disable WFQ and enable FIFO.
There is no special command that specifically enables FIFO.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-13
Configuring FIFO Queuing Router(config-if)#
hold-queue out
• FIFO queuing allows a maximum of 40 packets to be stored in the output queue • This command can be used to increase or decrease the maximum number of buffered packets • A large value can be set to support longer bursts (less drops, more buffer usage) • A small value can be set to prevent bursts (more drops)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-17
One of the considerations when using FIFO queuing is the maximum burst size. Routers allow (by default) up to 40 packets to be in the output queue. Shortening the queue causes more drops, especially for bursty sessions. Lengthening the queue allows more packets to be enqueued. A long queue should be used to allow bursts without drops. The hold-queue command is used to set the maximum number of packets in the output queue.
3-14
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
FIFO Example The Ethernet interface has a default bandwidth of 10Mbps. FIFO is the default queuing and it does not need to be configured.
interface interface Ethernet0/0 ip ip address address 1.1.1.1 1.1.1.1 255.0.0.0 255.0.0.0 !! interface interface Serial0/0 Serial0/0 ip ip address address 2.2.2.2 2.2.2.2 255.0.0.0 255.0.0.0 no no fair-queue fair-queue hold-queue hold-queue 50 50 out out !!
© 2001, Cisco Systems, Inc.
The serial interface (A/S) has a default bandwidth of 128 kbps. WFQ is the default queuing and it has to be disabled to enable FIFO queuing. Up to 50 frames are allowed to be enqueued before the router will start tail-dropping newely arriving packets.
Queuing Mechanisms-18
The example shows how FIFO can be enabled on an interface that uses WFQ by default. The serial interface in question has the default bandwidth of 128 kbps (below 2 Mbps). The ethernet interface has the default bandwidth of 10 Mbps (above 2 Mbps) and requires no configuration. The maximum output queue size was also slightly increased from the default 40 to 50.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-15
Monitoring and Troubleshooting FIFO Router#
show interface interface [] []
• The command displays information about the selected interface(s) Router#show Router#show interface interface Serial0/0 Serial0/0 The queue is currently empty ( 0/50). Serial0/0 Serial0/0 is is up, up, line line protocol protocol is is up up There can be a maximum of 50 frames in the Hardware Hardware is PowerQUICC Serial queue (0/50). Internet Internet address is 1.1.1.1/8 MTU MTU 1500 1500 bytes, bytes, BW BW 128 128 Kbit, Kbit, DLY DLY 20000 20000 usec, usec, reliability reliability 255/255, 255/255, txload txload 1/255, 1/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation HDLC, HDLC, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) FIFO queuing is enabled Last Last input input 00:00:02, 00:00:02, output 00:00:04, output hang neveron an interface with the default bandwidth of Last Last clearing clearing of "show "show interface" interface" counters never 128kbps. Queueing Queueing strategy: strategy: fifo fifo Output Output queue queue 0/50, 0/50, 00 drops; drops; input input queue queue 0/75, 0 drops 55 minute minute input input rate rate 00 bits/sec, bits/sec, 00 packets/sec packets/sec 55 minute 0 bits/sec, bits/sec, 0 0 packets/sec packets/sec minute output output rate rate 0 …… © 2001, Cisco Systems, Inc.
Queuing Mechanisms-19
FIFO queuing is not supported by a large arsenal of show and debug commands. The show interface command can be used to determine the queuing strategy of an interface and to display the following statistics:
3-16
Queuing Mechanisms
n
The current queue size (buffer usage)
n
The maximum queue size (default 40 or whatever is configured with the hold-queue out command)
Copyright 2001, Cisco Systems, Inc.
Summary FIFO queuing is the oldest queuing mechanism in the Cisco IOS. It is used on fast interfaces because of its simplicity and speed. FIFO produces undesirable behavior on congested (low-speed) interfaces that manifest itself as: n
Unfair allocation of bandwidth
n
Starvation of less-aggressive flows
n
Delay
n
Jitter
FIFO is the default queuing mechanism on all interfaces that have the default bandwidth of more than 2 Mbps. FIFO queuing can be enabled on interfaces with the default bandwidth of 2 Mbps or less by disabling WFQ.
Review Questions Answer the following questions: n
Why is FIFO the fastest queuing mechanism?
n
Describe the classification and scheduling of FIFO queuing.
n
List the drawbacks of FIFO queuing.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-17
Priority Queuing Objectives Upon completion of this lesson, you will be able to perform the following tasks:
3-18
Queuing Mechanisms
n
Describe Priority Queuing
n
Describe the benefits and drawbacks of Priority Queuing
n
Configure Priority Queuing on Cisco routers
n
Monitor and troubleshoot Priority Queuing
Copyright 2001, Cisco Systems, Inc.
Priority Queuing Forwarded Packets Priority Queuing System
High?
Tail-drop
Queue 1
Medium?
Tail-drop
Queue 2
Hardware Queuing System Pre-emptive Scheduler
Normal?
Tail-drop
Queue 3
Low?
Tail-drop
Queue 4
Hardware Q
Interface
• Priority Queuing (PQ) uses four FIFO queues © 2001, Cisco Systems, Inc.
Queuing Mechanisms-24
Priority Queuing (PQ) is one of the first mechanisms that allowed classification of packets into multiple classes. Scheduling is done in strict priority. PQ can classify packets into one of the four queues: n
High queue
n
Medium queue
n
Normal queue (the default queue)
n
Low queue
Scheduling prefers packets in the same order. Each class uses one FIFO queue, where packets are dropped if a queue is full.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-19
Priority Queuing Classification • Priority Queuing classification for IP supports the following options: – Source interface – IP access list (standard and extended) – Packet size (greater or smaller than specified) – Fragments – TCP source or destination port numbers – UDP source or destination port numbers
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-25
Priority Queuing can classify IP packets with the following tools:
3-20
Queuing Mechanisms
n
Direct matching on the source interface.
n
Standard or extended IP Access list. Extended IP access lists support matching on the following parameters: –
Source IP address
–
Destination IP address
–
Source TCP or UDP port number or port range
–
Destination TCP or UDP port number or port range
–
IP precedence (high-order three bits of the ToS field)
–
DSCP (high-order six bits of the ToS field)
–
ToS value (bits one through four of the ToS field)
–
Fragments
–
TCP flags (ACK, SYN, RST, URG, PSH)
n
Direct matching of TCP or UDP source and destination port numbers.
n
Direct matching of fragments.
n
Direct matching of packets based on their size.
Copyright 2001, Cisco Systems, Inc.
Priority Queuing Classification • Priority Queuing also supports classification of other protocols with the following options: – Protocol-specific access list (if available for the specified protocol) – Packet size (greater or smaller than specified) • Some of the supported protocols are: – IPX – CLNS – DECNET – AppleTalk – VINES – DLSw
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-26
Priority Queuing is a multi-protocol QoS mechanism because it supports classification tools for other (non-IP) protocols. The figure lists the match options for some of the supported Layer-3 protocols as well as other higher-layer protocols. Although other protocols are supported, the classification options are not as powerful as with IP. Most protocols can use their corresponding access lists to classify packets. Matching on packet size is also available with all supported protocols.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-21
Priority Queuing Insertion Policy • Each queue has a maximum number of packets that it can hold (queue size). • After a packet is classified to one of the following queues the router will enqueue the packet if the queue limit has not been reached (tail-drop within each class).
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-27
Priority Queuing is basically a collection of four parallel FIFO queues. Each queue suffers from all FIFO problems isolated to the class (unfair, starvation, delay, jitter). Each queue uses the tail-drop scheme when the queue is full. Each of the four queues can be configured with the maximum number of packets that it can hold.
3-22
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Priority Queuing Scheduling
Packet in HIGH queue? Yes
No
Packet in MEDIUM queue? Yes
No
Packet in NORMAL queue? Yes
No
Packet in LOW queue? Yes
© 2001, Cisco Systems, Inc.
No
Dispatch Packet And start checking the HIGH queue again
Hardware Q
Queuing Mechanisms-28
Priority Queuing uses strict priority scheduling. As long as there are packets in the high queue no other queue will be served. If the high queue is empty the router starts serving the medium queue. Congestion in any of the queues, except the low queue, causes a different type of starvation. A congested higher-priority queue causes all lower-priority queues to starve (class starvation).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-23
Benefits and Drawbacks of Priority Queuing + Benefits • Provides low-delay propagation to high-priority packets • Supported on most platforms • Supported in all IOS versions (above 10.0)
– Drawbacks • All drawbacks of FIFO queuing within a single class • Starvation of lower -priority classes when higherpriority classes are congested • Manual configuration of classification on every hop
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-29
As mentioned previously, Priority Queuing suffers from the same drawbacks as FIFO queuing, except it is localized to four classes. Each class can experience starvation, delay and jitter if one or more flows in the class cause congestion. Furthermore, one higher-priority queue can cause all other queues to starve if it is congested. Priority Queuing requires manual configuration of classification. The main benefit of PQ is that it enables the user to create a class that is used for applications that require low delay (high queue).
3-24
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Priority Queuing • Configure priority lists –Configure classification –Select a queue –Set maximum queue size • Apply the priority list to outbound traffic on an interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-30
The configuration of Priority Queuing can be split into the following four steps: 1. Classify data into four classes 2. Assign a queue to each class 3. Set the maximum queue size (if the default is not appropriate) 4. Apply the priority queuing system to one or more interfaces
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-25
Priority Queuing Classification Router(config)# priority-list list-number list-number protocol protocol-name {high|medium|normal|low} queue-keyword keyword-value
• Selects the queue based on layer-3 protocol • Additional classification (queue-keyword): – fragment (IP packets with non-zero fragment offset) – gt/lt <size>: based on packet size (including L2 frame) – list: ACL classification – tcp/udp <port>: TCP or UDP port number • System and link-level messages are classified in high by default © 2001, Cisco Systems, Inc.
Queuing Mechanisms -31
The first three configuration steps are achieved using the priority-list command. A Priority Queuing system is identified with a common number (list-number). Priority Queuing supports the following direct classification options of IP packets: 1. Match fragments 2. Match packets based on their size 3. Match packets based on their source or destination TCP/UDP port number A far more powerful classification tool is an access list (standard or extended).
3-26
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Priority Queuing Classification Router(config)# priority-list list-number interface intf {high|medium|normal|low} {high|medium|normal|low}
• Classifies the packet based on incoming interface Router(config)# priority-list list-number default default {high|medium|normal|low}
• Classifies all unclassified packets in a default queue
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-32
Additionally, PQ supports classification based on source interface. By default, all traffic not specifically classified goes into the normal queue. This behavior can be changed by using the priority-list default command. Note
The priority-list commands are evaluated in the order they were entered. This is especially important when overlapping classification is configured for separate queues. For example: Line 1: all IP traffic goes into the high priority queue Line 2: all TCP traffic goes into the medium queue The medium queue in this example would never g et any packets because it appears second in the configuration and it is a subset of the first line.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-27
Priority Queuing Scheduling and Dropping Parameters Router(config)# priority-list list-number queue-limit high medium normal low low
• Specifies the maximum queue sizes of individual priority queues Router(config-if)# priority-group list
• Assigns Priority Queuing definition to an interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-33
Priority Queuing uses the following default maximum queue sizes for the four queues: n
High queue has a default queue limit of 20
n
Medium queue has a default queue limit of 40
n
Normal queue has a default queue limit of 60
n
Low queue has a default queue limit of 80
The last configuration step is to apply a priority-list to an interface. Use the priority-group command with a corresponding priority-list number to enable Priority Queuing on an interface.
3-28
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Sample PQ Configuration
E0
WAN core
E1
interface interface serial0 serial0 Branch priority-group priority-group 1
Core
office priority-list priority-list priority-list priority-list priority-list priority-list priority-list priority-list
1 1 1 1
protocol protocol ip high list 101 interface interface ethernet ethernet 00 medium medium default normal queue-limit 20 40 60 80
access-list access-list 101 101 permit permit tcp tcp any any any any eq 23
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-34
The figure illustrates a simple example where outbound traffic is classified into the following three classes: 1. All outbound telnet sessions (access list 101) are using the high priority queue 2. All traffic coming into the router via interface Ethernet 0 is forwarded through the medium queue 3. All other traffic is using the default normal queue
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-29
Monitoring Priority Queuing Router# show interface interface interface
• Displays information and statistics about queuing on interface Router# show queueing [priority|custom|fair|random-detect] interface
• Displays queuing parameters on interfaces Router# show queue queue interface interface
• Displays queue contents © 2001, Cisco Systems, Inc.
Queuing Mechanisms-35
The show interface command can be used to determine the queuing strategy of an interface. If the queuing strategy is PQ some statistics are also displayed. The show queueing priority command can be used to display all non-default parameters of priority lists. Note
3-30
Queuing Mechanisms
To use the show queueing command, you must enter at least the first six characters to differentiate the command (show queuei vs. show queue).
Copyright 2001, Cisco Systems, Inc.
Show Interface Router#show Router#show interface interface serial serial 1/0 1/0 Serial1/0 Serial1/0 is is up, up, line line protocol protocol is is up up Hardware Hardware is is M4T M4T Internet Internet address address is is 20.0.0.1/8 20.0.0.1/8 MTU MTU 1500 1500 bytes, bytes, BW BW 19 19 Kbit, Kbit, DLY DLY 20000 20000 usec, usec, rely rely 255/255, 255/255, load load 93/255 93/255 Encapsulation Encapsulation HDLC, HDLC, crc crc 16, 16, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) Last Last input input 00:00:00, 00:00:00, output output 00:00:00, 00:00:00, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0 0/75/0 (size/max/drops); (size/max/drops); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: priority-list priority-list 11 Output Output queue queue (queue (queue priority: priority: size/max/drops): size/max/drops): high: high: 0/20/0, 0/20/0, medium: medium: 0/40/0, 0/40/0, normal: normal: 0/60/0, 0/60/0, low: low: 0/80/0 0/80/0 55 minute minute input input rate rate 18000 18000 bits/sec, bits/sec, 88 packets/sec packets/sec 55 minute minute output output rate rate 7000 7000 bits/sec, bits/sec, 88 packets/sec packets/sec …… rest rest ignored ignored ... ...
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-36
The show interface command displays the parameters and the statistics of all four priority queues. The first parameter is the current size of the queue, the second is the maximum allowed size of the queue and the third parameter is the number of drops since the last clearing of counters.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-31
Show Queuing Priority
Router#show Router#show queueing queueing priority Current Current priority priority queue queue configuration: configuration: List List 11 11
Queue Args Args high protocol ip list 101 high medium medium interface interface Ethernet6/0
• The “show queueing priority” command displays only the non-default parameters
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-37
The show queueing priority command lists all non-default parameters. The figure shows the two parameters: n
All packets permitted by access list 101 go into the high queue
n
All packets coming from interface Ethernet6/0 go into the medium queue
The commands that set default parameters are not displayed, either in the running configuration or by using this command.
3-32
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Summary Priority Queuing uses four FIFO queues. Strict priority queuing is used. Starvation within a single class or starvation of lower-priority classes is possible when one flow congests a higher-priority queue. Priority queuing can be used to guarantee all the bandwidth and low-delay propagation.
Review Questions Answer the following questions: n
When would you use priority queuing?
n
What are the benefits and drawbacks of priority queuing?
n
How many classes does priority queuing support?
n
How does priority queuing schedule packets?
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-33
Custom Queuing Objectives Upon completion of this lesson, you will be able to perform the following tasks:
3-34
Queuing Mechanisms
n
Describe Custom Queuing
n
Describe the benefits and drawbacks of Custom Queuing
n
Configure Custom Queuing on Cisco routers
n
Monitor and troubleshoot Custom Queuing
Copyright 2001, Cisco Systems, Inc.
Custom Queuing Forwarded Packets Custom Queuing System
Class 1?
Tail-drop
Queue 1
Class 2?
Tail-drop
Queue 2
Hardware Queuing System Round Robin Scheduler
Class 16?
Tail-drop
Hardware Q
Interface
Queue 16
• Custom Queuing (CQ) uses 16 FIFO queues for user defined traffic classes © 2001, Cisco Systems, Inc.
Queuing Mechanisms-42
Custom Queuing (CQ) is similar to Priority Queuing in the way it is configured and in the supported classification options. The scheduling, however, is completely different. CQ uses up to 16 queues that can be used for user-defined classes. The classification options are identical to those of Priority Queuing. The scheduling mechanism uses the round-robin service where each queue is allowed to forward a certain number of bytes (not packets). Tail-drop is still used within each individual queue.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-35
Custom Queuing Classification • Custom Queuing classification for IP supports the following options: – Source interface – IP access list (standard and extended) – Packet size (greater or smaller than specified) – Fragments – TCP source or destination port numbers – UDP source or destination port numbers • Custom Queuing classification is identical to that of Priority Queuing
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-43
Custom Queuing (similar to Priority Queuing) can classify IP packets with the following tools:
3-36
Queuing Mechanisms
n
Direct matching on the source interface.
n
Standard or extended IP Access list. Extended IP access lists support matching on the following parameters: –
Source IP address
–
Destination IP address
–
Source TCP or UDP port number or port range
–
Destination TCP or UDP port number or port range
–
IP precedence (high-order three bits of the ToS field)
–
DSCP (high-order six bits of the ToS field)
–
ToS value (bits one through four of the ToS field)
–
Fragments
–
TCP flags (ACK, SYN, RST, URG, PSH)
n
Direct matching of TCP or UDP source and destination port numbers.
n
Direct matching of fragments.
n
Direct matching of packets based on their size.
Copyright 2001, Cisco Systems, Inc.
Custom Queuing Insertion Policy • Each queue has a maximum number of packets that it can hold (queue size). • After a packet is classified to one of the following queues the router will enqueue the packet if the queue limit has not been reached (tail-drop within each class).
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-44
Once the packet is classified a router has to determine if the packet can be enqueued. The packet is dropped if the queue is full. Each queue, unless configured otherwise, can buffer up to 20 packets before the first packet is dropped.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-37
Custom Queuing Scheduling No Packet in Queue N?
No
Next Queue (increase N)
Yes
Is Queue N over the threshold?
Yes
Dispatch Packet
Hardware Q
• Custom Queuing uses round-robin service policy • Each queue is allowed to forward a configurable amount of bytes (threshold) in one round © 2001, Cisco Systems, Inc.
Queuing Mechanisms-45
Custom Queuing uses round-robin scheduling, where each queue gets some service (bandwidth). Each queue is configured with the number of bytes (byte-count) it can send in one round. The last packet is always sent, even if the total amount of bytes sent in one round is above the limit (byte-count). The router then starts processing the next queue.
3-38
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Custom Queuing Scheduling Parameters 1500
1499
1500
Threshold (byte-count) = 3000 Up to 4499 bytes can be forwarded in one round in the worst case
• The threshold (byte count) parameter specifies the lower boundary on how many bytes the system allows to be delivered from a given queue during a particular cycle • The router is allowed to send the entire packet even if the sum of all bytes is more than the threshold © 2001, Cisco Systems, Inc.
Queuing Mechanisms-46
The figure illustrates the worst case scenario where the following parameters were used to implement Custom Queuing on an interface: n
MTU of the interface is 1500 bytes
n
Byte-count is 3000 (twice the MTU)
The example shows how the router first sent two packets with a total size of 2999 bytes. Since this is still within the limit (3000) the router can send the next packet (MTU-sized). The result was that the queue received almost 50% more bandwidth in this round than it should. This is one of the drawbacks of Custom Queuing – it does not allocate bandwidth accurately.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-39
CQ Design Guideline • Configure the amount to remove from a queue in each round to configure the proportional “weight” of the queue • Amounts to remove should approximate a small multiple of the interface’s MTU • Ratio between largest and smallest queue should be a small positive integer, not more than 10:1
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-47
The limit or weight of the queue is configured in bytes. The accuracy of Custom Queuing depends on the weight (byte-count) and the MTU. If the ratio between the byte-count and the MTU is too small CQ will not allocate bandwidth accurately. If the ratio between the byte-count and the MTU is too large CQ will cause long delays. This problem is discussed in detail on the next two pages.
3-40
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Delay vs. Bandwidth Allocation Queue 1 5999
4500 Queue 2 4499
3000
Round Robin Scheduler
64 kbps MTU=1500
Queue 3 2999
1500
BW BW (Queue 1) == bc1/(bc1+bc2+bc3) bc1/(bc1+bc2+bc3) == 4500/9000 == 50% Delay Delay (Queue (Queue 1) 1) = (bc2+bc3)/Bandwidth = 562ms
Worst-case Worst-case Delay Delay (Queue (Queue 1) = ((bc2+1499) +(bc3+1499))/Bandwidth +(bc3+1499))/Bandwidth == 937ms
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-48
The figure illustrates sample calculations of bandwidth guarantees and the maximum delay. The time it takes to complete a round depends on the bandwidth of the interface, the MTU size and the sum of all queue byte-counts. The case study parameters are: n
The first queue uses a byte-count of 4500 (three times the MTU)—5999 bytes can be sent in the worst case
n
The second queue uses a byte-count of 3000 (two times the MTU)—4499 bytes can be sent in the worst case
n
The third queue uses byte-count 1500 (MTU)—2999 bytes can be sent in the worst case
The first calculation shows that the first queue should receive approximately 50% of the bandwidth. The second calculation shows the round-robin delay of 562ms for Queue 1 when all classes are congested. The third calculation shows the round-robin delay of 937ms for Queue 1 when all classes are congested and manage to send the maximum number of bytes (byte-count + MTU - 1) in one round. Although this worst case is very unlikely it is also unlikely that classes will use the exact configured maximum.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-41
Worst-case Delay • MTU=1500, byte-count (4500, 3000, 1500) Max(delay)=(5999+4499)*8/64000=1312 ms • MTU=1000, byte-count (4500, 3000, 1500) Max(delay)=(5499+3999)*8/64000=1187 ms • MTU=250, byte-count (450, 300, 150) Max(delay)=(699+549)*8/64000=156 ms Expected delay=(500+500)*8/64000=125 ms Custom queuing is not appropriate for lowdelay environment. Changing MTU and bytecounts might be a workaround.
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-49
The figure shows several calculations where the worst-case maximum delay was reduced by reducing both the MTU and the byte-counts. Note
3-42
Queuing Mechanisms
The calculation merely shows the impact the MTU and the byte-count have on the delay. Lowering the MTU is not a recommended solution because it potentially increases the CPU utilization of the router due to fragmentation of packets.
Copyright 2001, Cisco Systems, Inc.
Benefits and Drawbacks of Custom Queuing + Benefits • Guarantees throughput to traffic classes (prevents starvation between traffic classes) • Supported on most platforms • Supported in all IOS versions (above 10.0)
– Drawbacks • • • •
All drawbacks of FIFO queuing within a single class Manual configuration of classification on every hop Not accurate bandwidth allocation High jitter due to implementation of scheduling
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-50
In addition to all the benefits and drawbacks of Priority Queuing, Custom Queuing can also guarantee bandwidth to up to 16 classes. Custom Queuing can cause all queues to experience delay due to the implementation of scheduling (one round can take a long time).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-43
Custom Queuing Classification Router(config)# queue-list list-number protocol protocol-name protocol-name queue-number queue-number queue-keyword keyword-value
• Classifies the packet into a custom queue based on protocol and other protocol-specific criteria • Selection criteria identical to priority queuing Router(config)# queue-list list-number interface incoming-intf queue-number queue-number
• Classifies the packet into a custom queue based on incoming interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-51
Custom queuing uses the same classification options as Priority Queuing. Instead of using names queues are numbered (1 to 16).
3-44
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Custom Queuing Classification Router(config)# queue-list list-number default default queue-number
• Classifies all unclassified packets into a default queue Router(config-if)# custom-queue list-number
• Starts custom queuing on an interface and assigns specified CQ definition to the interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-52
All traffic that is not specifically classified is put into Queue 1. n
Use the queue -list default command to change the default queue.
n
Use the custom-queue interface command to apply a queue-list to an interface.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-45
Custom Queuing Scheduling Parameters Router(config)# queue-list list queue queue queue-number byte-count bc
• Specifies the lower boundary on how many bytes the system allows to be delivered from a given queue during one round-robin cycle Default: 1500 bytes Router(config)# queue-list list queue queue queue-number limit limit
• Specifies the maximum number of packets in a queue • Incoming packets are tail-dropped if the limit is exceeded © 2001, Cisco Systems, Inc.
3-46
Queuing Mechanisms
Queuing Mechanisms-53
n
Use the byte-count option to change the default weight of a queue (default equals MTU size)
n
Use the limit option to change the number of packets that a queue can hold (default is 20)
Copyright 2001, Cisco Systems, Inc.
Custom Queuing with Preemptive Queues Forwarded Packets Custom Queuing has queue 0 for system and link-level messages which use pre-emptive scheduling
Custom Queuing System Class 0?
Tail-drop
Queue 0
Class 1?
Tail-drop
Queue 1
Class 2?
Tail-drop
Queue 2
Hardware Queuing System Pre -emptive Scheduler
Hardware Q
Intf
Round Robin Scheduler
Class 16?
© 2001, Cisco Systems, Inc.
Tail-drop
Queue 16
Queue 1 is the lowest custom queue that is serviced by the round robin scheduler
Queuing Mechanisms-54
Custom queuing has another queue—Queue 0. This queue is used for system packets (routing protocols, link-level messages). This queue is not served by the round-robin scheduler. Instead, a strict priority scheduler is used to prioritize packets from this queue.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-47
Custom Queuing with Preemptive Queues Forwarded Packets Custom Queuing System Class 0?
Tail-drop
Queue 0
Class 1?
Tail-drop
Queue 1
Class 2?
Tail-drop
Queue 2
Custom queues can be configured to use the pre -emptive scheduler
Hardware Queuing System Pre -emptive Scheduler
Round Robin Scheduler
Class 16?
© 2001, Cisco Systems, Inc.
Tail-drop
Hardware Q
Intf
Queue 2 is now the lowest custom queue that is serviced by the round robin scheduler
Queue 16
Queuing Mechanisms-55
The strict priority scheduler can be extended to other queues that are normally served by the round-robin scheduler. The figure illustrates how Queue 1 was moved into the priority-scheduled part of the Custom Queuing system. The delimiter can be set to any queue by specifying the lowest custom queue (Queue 2 in this example). In fact, Custom Queuing can be turned into Priority Queuing with 17 queues if Queue 16 is selected as the lowest custom queue.
3-48
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Custom Queuing Scheduling Parameters Router(config)# queue-list list-number lowest-custom queue-number queue-number
• Set the lowest queue to be treated as custom queue • Queues below the specified queue are pre-emptive priority queues (Q1 having highest priority) • Queue 0 is always treated as pre-emptive – System and link-level messages are classified in Q0 by default
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-56
Use the lowest-custom option to achieve the following: n
All queues from Queue 0 to the queue before the one specified in the command use priority queuing (Queue 0 has the highest priority)
n
All queues from the one specified in the command to Queue 16 use the round-robin scheduler
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-49
Custom Queuing Example
E0
WAN core
E1
Branch office
interface interface serial 1/0 1/0 Core custom-queue-list 5 !! queue-list queue-list 55 protocol protocol ip ip 11 list list 101 101 queue-list queue-list 5 queue 1 limit 40 queue-list queue-list 5 lowest-custom lowest-custom 22 queue-list queue-list 5 interface interface ethernet ethernet 0/0 0/0 22 queue-list queue-list 55 queue queue 22 byte-count byte-count 3000 queue-list queue-list 5 protocol ip 3 queue-list queue-list 55 queue queue 33 byte-count byte-count 5000 queue-list queue-list 5 default default 4 !! access-list access-list 101 permit permit ip any any precedence precedence 5
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-57
The figure shows a sample configuration where four queues are used:
3-50
Queuing Mechanisms
n
Queue 1 is used for delay-sensitive applications (marked with IP precedence 5). It uses the strict priority scheduler.
n
Queue 2 is used for all packets coming from interface Ethernet0/0.
n
Queue 3 is used for all IP packets that do not end in one of the first two queues.
n
Queue 4 is used for all other traffic.
Copyright 2001, Cisco Systems, Inc.
Custom Queuing - Show Interface Router#show Router#show interface interface serial serial 1/0 1/0 Serial1/0 Serial1/0 is is up, up, line line protocol protocol is is up up Hardware Hardware is is M4T M4T Internet Internet address address is is 20.0.0.1/8 20.0.0.1/8 MTU MTU 1500 1500 bytes, bytes, BW BW 19 19 Kbit, Kbit, DLY DLY 20000 20000 usec, usec, rely rely 255/255, 255/255, load load 107/255 107/255 Encapsulation Encapsulation HDLC, HDLC, crc crc 16, 16, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) Last Last input input 00:00:00, 00:00:00, output output 00:00:00, 00:00:00, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0 0/75/0 (size/max/drops); (size/max/drops); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: custom-list custom-list 55 Output Output queues: queues: (queue (queue #: #: size/max/drops) size/max/drops) 0: 0: 0/20/0 0/20/0 1: 1: 0/40/0 0/40/0 2: 2: 0/20/0 0/20/0 3: 3: 0/20/0 0/20/0 4: 4: 0/20/0 0/20/0 5: 5: 0/20/0 0/20/0 6: 6: 0/20/0 0/20/0 7: 7: 0/20/0 0/20/0 8: 8: 0/20/0 0/20/0 9: 9: 0/20/0 0/20/0 10: 10: 0/20/0 0/20/0 11: 11: 0/20/0 0/20/0 12: 12: 0/20/0 0/20/0 13: 13: 0/20/0 0/20/0 14: 14: 0/20/0 0/20/0 15: 15: 0/20/0 0/20/0 16: 16: 0/20/0 0/20/0 …… rest rest ignored ignored ... ...
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-58
The show interface command is used to determine the queuing strategy of an interface. If custom queuing is used on an interface the following information is also displayed: n
The number of the queue-list
n
Statistics for each of the 17 queues:
Copyright 2001, Cisco Systems, Inc.
–
Current size
–
Maximum size
–
Total number of drops since the last clearing of counters
Queuing Mechanisms
3-51
Show Queueing Custom Router#show Router#show queueing queueing custom Current Current custom custom queue queue configuration: List List 55 55 55 55 55
Queue 33 11 22 11 22
Args Args default default protocol protocol ip ip list 101 interface interface Ethernet0/0 byte-count byte-count 3000 limit 40 byte-count byte-count 5000
• The “show queueing custom” command displays only the non-default parameters © 2001, Cisco Systems, Inc.
Queuing Mechanisms-59
The show queueing custom command can be used to display all non-default parameters of Custom Queuing.
3-52
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Summary Custom Queuing introduces a scheduler that can guarantee bandwidth to 16 classes. In addition to the round-robin scheduling between 16 classes, a number of classes can be switched to priority scheduling.
Review Questions Answer the following questions: n
When would you use custom queuing?
n
What are the benefits and drawbacks of custom queuing?
n
How many classes does custom queuing support?
n
How does custom queuing schedule packets?
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-53
Weighted Fair Queuing Objectives Upon completion of this lesson, you will be able to perform the following tasks:
3-54
Queuing Mechanisms
n
Describe WFQ
n
Describe the benefits and drawbacks of WFQ
n
Configure WFQ on Cisco routers
n
Monitor and troubleshoot WFQ
Copyright 2001, Cisco Systems, Inc.
Weighted Fair Queuing • Queuing algorithm should fairly share the bandwidth among flows by: – reducing response time for interactive flows by scheduling them to the front of the queue – preventing high volume conversations from monopolizing an interface • Implementation: Messages are sorted into conversations (flows) and transmitted by the order of the last bit crossing its channel • Unfairness is reinstated by introducing “weight” (IP precedence) to give proportionately more bandwidth to flows with higher weight
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-64
Weighted Fair Queuing (WFQ) was introduced as a solution to the problems of the following queuing mechanisms: n
FIFO queuing causes starvation, delay and jitter
n
PQ causes starvation of other lower-priority classes and suffers from all FIFO problems within each of the four queues
n
CQ causes long delays and also suffers from all FIFO problems within each of the 16 queues
The idea of WFQ is to: n
Have a dedicated queue for each flow (no starvation, delay or jitter within the queue)
n
Fairly and accurately allocate bandwidth among all flows (minimum scheduling delay, guaranteed service)
n
Use IP precedence as weight when allocating bandwidth
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-55
Weighted Fair Queuing Forwarded Packets Weighted Fair Queuing System
Flow 1?
WFQ-drop
Queue 1
Flow 2?
WFQ-drop
Queue 2
Hardware Queuing System WFQ Scheduler
Flow N?
WFQ-drop
Hardware Q
Interface
Queue N
• WFQ uses per-flow FIFO queues © 2001, Cisco Systems, Inc.
3-56
Queuing Mechanisms
Queuing Mechanisms-65
n
WFQ uses automatic classification. Manually defined classes are not supported.
n
WFQ dropping is not a simple tail-drop. WFQ drops packets of the most aggressive flows.
n
WFQ scheduler is a simulation of a TDM system (time-division multiplexer). The bandwidth is equally distributed to all active flows.
Copyright 2001, Cisco Systems, Inc.
Weighted Fair Queuing Implementations • Implementation parameters –Queuing platform: central CPU or VIP –Classification mechanism –Weighted fairness • Modified Tail-Drop within each queue
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-66
WFQ is supported on most Cisco routers as well as Versatile Interface Processors (VIP). The implementation on the VIP slightly differs from the one discussed in this lesson. n
Classification identifies a flow and assigns a queue to the flow
n
Weight is used for scheduling to give proportionately more bandwidth to flows with a higher IP precedence
n
Tail-dropping scheme is improved to drop packets of the most aggressive flows
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-57
WFQ Classification IP
TCP
Src. Dst. Proto. Addr. Addr.
ToS
Payload
Src. Port
Dst. Port
Hash Algorithm
WFQ Classification uses the following parameters: • source IP address • destination IP address • source TCP or UDP port • destination TCP or UDP port • transport protocol • type of service (ToS) field A hash algorithm is used to produce the index of the queue where the packet is enqueued
#queue (Index of the queue)
• Packets of the same flow end up in the same queue • ToS field is the only parameter that might change causing packets of the same flow to end up in different queues © 2001, Cisco Systems, Inc.
Queuing Mechanisms-67
WFQ classification has to identify individual flows (the term conversation is also used to signify flows). A flow is identified based on the following information taken from the IP header and the TCP or UDP headers: n
Source IP address
n
Destination IP address
n
Protocol number (identifying TCP or UDP)
n
Type of Service Field
n
Source TCP/UDP port number
n
Destination TCP/UDP port number
All these parameters are usually fixed for a single flow, although there are some exceptions: n
A QoS design could mark packets with different IP precedence values even if they belong to the same flow. This kind of behavior should be avoided when using WFQ.
n
Some applications change port numbers (for example, TFTP).
If packets of the same flow do not have the same parameters (for example, a different ToS field) the packets can end up in different queues and reordering can occur. The parameters are used as input for a hash algorithm that produces a fixed-length number that is used as the index of the queue.
3-58
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
WFQ Classification Details • Fixed number of per-flow queues is configured • A hash function is used to translate flow parameters into queue number • System packets (8 queues) and RSVP flows (if configured) are mapped into separate queues • Two or more flows could map into the same queue, resulting in lower per-flow bandwidth • Important: the number of queues configured has to be larger than the expected number of flows
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-68
WFQ uses a fixed number of queues. The hash function is used to assign a queue to a flow. There are eight additional queues for system packets and optionally up to 1000 queues for RSVP flows. WFQ uses 256 queues by default. The number of queues can be configured in the range between 16 and 4096 (the number must be a power of 2). If there are a large number of concurrent flows it is very likely that two flows could end up in the same queue. It is recommended to have several times as many queues as there are flows (on the average). This may not be possible in larger environments where the number of concurrent flows is in thousands. The probability of two flows ending up in the same flow could be calculated using the following formula:
P =1−
Queues
Flows
Queues! ⋅ ( Queues − Flows)!
The following table lists the probability values for 3 sizes of the WFQ system (64, 128 and 256 queues), with the number of concurrent flows from 5 to 40. Flows 5 10 15 20 25 30 35 40
Copyright 2001, Cisco Systems, Inc.
64 queues 15% 52% 83% 96% 100% 100% 100% 100%
128 queues 8% 30% 57% 79% 92% 98% 99% 100%
256 queues 4% 16% 34% 53% 70% 83% 91% 96%
Queuing Mechanisms
3-59
WFQ Insertion and Drop Policy • WFQ has two modes of dropping: –Early dropping when the congestion discard threshold (CDT) is reached –Aggressive dropping when the hold-queue limit (HQO) is reached • WFQ always drops packets of the most aggressive flow
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-69
WFQ uses two parameters that affect the dropping of packets.
3-60
Queuing Mechanisms
n
The congestive discard threshold (CDT) is used to start dropping packets of the most aggressive flow, even before the hold-queue limit is reached.
n
The hold-queue limit defines the total maximum number of packets that can be in the WFQ system at any time.
Copyright 2001, Cisco Systems, Inc.
WFQ Insertion and Drop Policy N-th packet
N>HQO?
No
Yes Worst Finish Time?
No
Enqueue packet
Yes
Yes
No Drop the packet with the worst finish time (old) and enqueue the N-th packet (new)
N>CDT?
Worst Finish Time?
No
Yes Old
New
• HQO (hold-queue out limit) is the max . number of packets that the WFQ system can hold • CDT (congestive discard threshold) is the threshold when WFQ starts dropping packets of the most aggressive flow • N is the number of packets in the WFQ system when the N -th packet arrives
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-70
The figure illustrates the dropping scheme of WFQ. The process can be split into the following steps: Step 1
Drop the new packet if the WFQ system is full (hold-queue limit reached) and the new packet has the worst finish time (the last in the entire system).
Step 2
Drop the packet with the worst finish time in the WFQ system if the system is full. Enqueue the new packet.
Step 3
Drop the new packet if the queue, where the packet should be enqueued, is the longest (not in packets but in the finish time of the new packet) and there are more packets in the WFQ system than the CDT.
Step 4
Otherwise enqueue the new packet.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-61
Case Study • WFQ system can hold a maximum of ten packets (hold-queue limit) • Early dropping (of aggressive flows) should start when there are eight packets (congestive discard threshold) in the WFQ system
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-71
The following case study is used to describe how packets are dropped in different situations. The WFQ system was reduced to a modest hold-queue limit of ten and a congestive discard threshold of eight.
3-62
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Case Study Interface Congestion
• Absolute maximum (HQO=10) exceeded, new packet is the last in the TDM system and is dropped
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-72
There are already ten packets in the WFQ system. The new packet would be the eleventh and also the last in the entire WFQ system. The packet is dropped.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-63
Case Study Interface Congestion
• Absolute maximum exceeded (HQO=10), new packet is not the last in the TDM system, last packet is dropped
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-73
In this example there are also ten packets in the system when the eleventh packet arrives. The new packet, if enqueued, would not be the last in the system. The packet is therefore allowed to be enqueued and the last packet in the system is deleted.
3-64
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Case Study Flow Congestion
• CDT exceeded (CDT=8), new packet would be the last in the TDM system and is dropped
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-74
This example illustrates how WFQ can drop packets even if the WFQ system is still within the hold-queue limit. The system, however, is above the CDT limit. In this case a packet can be dropped if it is the last in the system.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-65
Case Study Flow Congestion
• CDT exceeded (CDT=8), new packet would not be the last. Packet is enqueued
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-75
This example is different from the previous one in that the new packet would not be the last in the WFQ system. The packet can be enqueued and no other packet is dropped.
3-66
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Drop Mechanism within WFQ Exceptions • Packet classified into an empty sub-queue is never dropped • The packet precedence has no effect on the dropping scheme
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-76
There is an exception to the CDT rule —if the WFQ system is above the CDT limit, and the new packet would be the last in the system, the packet is still enqueued if the flow queue is empty. The dropping strategy is not directly influenced by IP precedence.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-67
WFQ Scheduling • Each packet is tagged with its Finish time in a virtual TDM system • The scheduler selects the packets with the earliest finish time tag (thus the packet that leaves the virtual TDM the earliest) • Reference: “On the Efficient Implementation of Fair Queuing", Keshav, Berkeley, 1994
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-77
The length of queues (for scheduling purposes) is not in packets but in the time it would take to transmit all the packets in the queue. The following pages discuss the WFQ scheduling issue in detail. The end result is that WFQ adapts to the number of active flows (queues) and allocates equal amounts of bandwidth to each flow (queue). The side effect is that flows with small packets (usually interactive flows) get a much better servic e because they do not need a lot of bandwidth. They, however, need low-delay, which they get because small packets have a low finish time.
3-68
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Fair Queuing Finish Time Calculation If Flow Flow FF Active, Active, Then FT(Pk+1 k+1) = FT(Pkk) + Size(Pk+1 k+1) Otherwise FT(P0) = Now + Size(P0) FT(A1)=0+100 A1[100]
FT(B1)=50+300 B1[300]
FT(B2)=350+300
FT(A2)=100+20
A2[20]
FT(A3)=120+10 B2[300]
A3[10]
t
100
70 60 50
0
Hence the resulting scheduling is:
B2
B1
© 2001, Cisco Systems, Inc.
A3 A2
A1 Queuing Mechanisms-78
The figure illustrates how two queues (Queue A and Queue B) are contesting for link bandwidth. For this example, assume the time units are in milliseconds and time T (value 0 is used in the figure) is the starting point. Queue A is receiving packets in the following order and the following times: n
Packet A1 arrives at time T + 0ms and would require 100ms to be transmitted
n
Packet A2 arrives at time T + 60ms (the input interface is obviously faster than the output interface because the arrival time of packet A2 is before the finish time of packet A1) and would require 20 ms to be transmitted
n
Packet A3 arrives at time T + 60ms (the input interface is obviously much faster than the output interface) and would require 10 ms to be transmitted
Queue B is receiving packets in the following order and the following times: n
Packet B1 arrives at time T + 50ms and would require 300ms to be transmitted
n
Packet B2 arrives at time T + 100ms and would also require 300ms to be transmitted
The finish time of packets in Queue A are: n
Packet A1 has a finish time which is the sum of the current time (because the queue was empty at the time of arrival) and the time it takes to transmit this packet (100ms): FTA1 = 0ms + 100ms = 100ms
n
Packet A2 has a finish time which is the sum of the finish time of the last packet in Queue A (Packet A1) and the time it would take to transmit this packet (20ms): FTA2 = 100ms + 20ms = 120ms
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-69
n
Packet A3 has a finish time which is the sum of the finish time of the last packet in Queue A (Packet A2) and the time it would take to transmit this packet (20ms): FTA3 = 120ms + 10ms = 130ms
The finish time of packets in queue B are: n
Packet B1 has a finish time which is the sum of the current time (because the queue was empty at the time of arrival) and the time it takes to transmit this packet (300ms): FTB1 = 50ms + 300ms = 350ms
n
Packet B2 has a finish time which is the sum of the finish time of the last packet in Queue B (Packet B1) and the time it would take to transmit this packet (300ms): FTB2 = 350ms + 300ms = 650ms
The packets are scheduled into the hardware queue (TxQ) in the ascending order of finish times: 1. A1 (100ms) 2. A2 (120ms) 3. A3 (130ms) 4. B1 (350ms) 5. B2 (650ms) The following remarks should be noted in conclusion of the case study:
3-70
Queuing Mechanisms
n
WFQ prevents reordering of packets within a single flow (conversation)
n
Small packets are automatically preferred over large packets
Copyright 2001, Cisco Systems, Inc.
Weight in WFQ Scheduling WFQ system (real size packets) 2
Flow with P=001
1
3
Flow with P=000
2
1 Precedence-1 packets appear half the real size
Virtual Packet Size = Real Packet Size / (IP precedence + 1)
WFQ system (virtual size packets) 4
Flow with P=001
3 3
Flow with P=000
2 2
1 Precedence -1 flow gets twice as much bandwidth as precedence -0 flow
1
Hardware FIFO Queue 3 © 2001, Cisco Systems, Inc.
3
2
2
1
1 Queuing Mechanisms-79
This figure introduces the weight into the finish time calculation. The time it takes to transmit the packet is divided by IP precedence increased by one (to prevent division by zero). The WFQ implementation in Cisco routers was optimized in the following way: n
The real time it takes to transmit the packet is not relevant. The packet size can be used instead because it is proportional to the transmit time.
n
The packet size is not divided by IP precedence (division is a CPU-intensive operation). Instead, the size is multiplied by a fixed value (one multiplication value for each IP precedence value).
Packets with IP precedence one appear half the size they really are. The result is that these packets receive twice as much bandwidth as packets with IP precedence zero.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-71
Weighted Fair Queuing Finish Time Calculation Finish Time is adjusted based on IP precedence of the packet
If Flow F Active, Then FT(Pk+1) = FT(Pk) + Size(P Size(P k+1 k+1)/(IPPrec+1) Otherwise FT(P00) = Now + Size(P0)/(IPPrec+1) IOS implementation scales the finish time to allow integer arithmetic
If Flow F Active, Then FT(Pk+1) = FT(Pk) + Size(P Size(P k+1 k+1)*4096/(IPPrec+1) Otherwise FT(P00) = Now + Size(P0)*4096/(IPPrec+1) RSVP packets and high-priority internal packets (PAK-Priority) have special weights (4 and 128) © 2001, Cisco Systems, Inc.
Queuing Mechanisms-80
The first formula in the figure is the first optimisation where the finish time is really the sum of packet sizes divided by an increased IP precedence value. The second formula shows further optimisation where, instead of dividing, the packet size is multiplied by 4096/(IP precedence + 1). A value for each IP precedence is stored in a table and it does not have to be calculated for each packet. Packets belonging to RSVP flows and system packets have special low weights that guarantee them more bandwidth. Note
3-72
Queuing Mechanisms
Cisco IOS versions after 12.0(5)T use a new formula where the weight is calculated on the following formula: Weight = 32384 / (IP precedence +1)
Copyright 2001, Cisco Systems, Inc.
IP Precedence to Weight Mapping IP Precednece 0
Weight 4096
1 3
2048 1365 1024
4
819
5
682 585 512
2
6 7 32 (virtual IP precedence) 1024 (virtual IP precedence)
128 (PAC-Priority) 4 (RSVP)
• RSVP packets and high-priority internal packets (PAK-Priority) have special weights (4 and 128) • Lower weight makes packets appear smaller (preffered) © 2001, Cisco Systems, Inc.
Queuing Mechanisms-81
The table above shows the mapping between IP precedence values and WFQ weights. Note
According to the new formula for weight in Cisco IOS versions after 12.0(5)T the following values are used: IP precedence 0 IP precedence 1 IP precedence 2 IP precedence 3 IP precedence 4 IP precedence 5 IP precedence 6 IP precedence 7
Copyright 2001, Cisco Systems, Inc.
weight 32384 weight 16192 weight 10794 weight 8096 weight 6476 weight 5397 weight 4626 weight 4048
Queuing Mechanisms
3-73
Weighted Fair Queuing Voice and Data integration • WAN link speed • Voice requirements
128 kbps 30 kbps
• VoIP is precedence 5 (counts as 6 data sessions) • 1 VoIP session, 5 data sessions – voice gets up to 6/(6+5)*128 = 69 kbps (enough)
• 1 VoIP session, 20 data sessions – voice gets up to 6/(6+20)*128 = 29 kbps (problem)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-82
The case study above is concerned with the propagation of voice packets across a 128 kbps link without using RSVP. Assume that VoIP is using G.729 codec that uses approximately 30 kbps of bandwidth (including RTP, UDP, IP and frame headers). All voice packets are marked with IP precedence 5. n
The first calculation is where a voice session is contesting for available bandwidth with 5 precedence-0 data sessions. WFQ would guarantee 69 kbps to the voice session.
n
The second calculation is where the same voice session is contesting for available bandwidth with 20 precedence-0 data sessions. WFQ would now guarantee only 29 kbps to the voice session.
The conclusion is that, although WFQ can give a much better service to flows with small packets or high IP precedence value, it is not an exact tool that can guarantee a fixed amount of bandwidth.
3-74
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Benefits and Drawbacks of Weighted Fair Queuing + Benefits • Simple configuration (classification does not have to be configured) • Guarantees throughput to all flows • Drops packets of most aggressive flows • Supported on most platforms • Supported in all IOS versions (above 11.0)
– Drawbacks • • • • •
All drawbacks of FIFO queuing within a single queue Multiple flows can end up in one queue Does not support the configuration of classification Can not provide fixed bandwidth guarantees Performance limitations due to complex classification and scheduling mechanisms
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-83
The main benefits of WFQ are: n
Simple configuration (no manual classification is necessary)
n
Drops packets of the most aggressive flows
The main drawbacks are: n
It is not always possible to have one flow per queue
n
Does not allow manual classification
n
It cannot provide fixed guarantees
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-75
Weighted Fair Queuing Configuration Router(config-intf)# fair-queue [cdt [dynamic-queues [reservable-queues]]]
• congestive-discard-threshold (CDT) –Number of messages allowed in the WFQ system before the router starts dropping new packets for the longest queue. –The value can be in the range from 1 to 4096 (default is 64)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-84
WFQ is automatically enabled on all interfaces that have a default bandwidth of less than 2 Mbps. Use the fair-queue command to enable WFQ on interfaces where it is not enabled by default or was previously disabled. The CDT value can be changed from the default 64.
3-76
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Weighted Fair Queuing Configuration Router(config-intf)# fair-queue [cdt [dynamic-queues [reservable-queues]]]
• dynamic-queues – Number of dynamic queues used for best-effort conversations (values are: 16, 32, 64, 128, 256, 512, 1024, 2048, and 4096 - the default is 256) • reservable-queues – Number of reservable queues used for reserved conversations in the range 0 to 1000 (used for interfaces configured for features such as RSVP the default is 0)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-85
The number of dynamic queues can also be changed from the default number of 256 queues. The maximum number of reservable queues should be set when RSVP requires guarantees for the reserved bandwidth.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-77
Weighted Fair Queuing Additional Parameters Router(config-if)# hold-queue max-limit out
• Specifies the maximum number of packets that can be in all output queues on the interface at any time • The default value for WFQ is 1000 • Under special circumstances WFQ can consume a lot of buffers which may require lowering this limit
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-86
The same hold-queue command that can be used with FIFO queuing can also be used with WFQ. The default hold-queue limit with WFQ is 1,000 packets. The WFQ system will generally never reach the hold-queue limit because the CDT limit starts dropping packets of aggressive flows. Under special circumstances it would be possible to fill the WFQ system. For example, a denial-of-service attack that floods the interface with a large number of packets (each different) could fill all queues at the same rate.
3-78
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Fair Queuing Defaults • Fair Queuing is enabled by default on – physical interfaces whose bandwidth is less than or equal to 2.048 Mbps – interfaces configured for Multilink PPP
• Fair Queuing is disabled – if you enable the autonomous or silicon switching engine mechanisms – for any sequenced encapsulation: X.25, SDLC, LAPB, reliable PPP
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-87
The figure explains the default behavior of WFQ. As mentioned previously, WFQ is automatically enable d on all interfaces slower than 2Mbps. WFQ is also required on interfaces using Multilink PPP. WFQ cannot be used if reordering of frames is not allowed due to sequence numbering of Layer-2 frames or if the switching path does not support WFQ.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-79
Monitoring and Troubleshooting WFQ Router# show interface interface interface interface
• Displays interface delays including the activated queuing mechanism with the summary information Router# show queue interface
• Displays detailed information about the WFQ system of the selected interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-88
The same show commands can be used as with other queuing mechanisms:
3-80
Queuing Mechanisms
n
show interface
n
show queue
n
show queueing
Copyright 2001, Cisco Systems, Inc.
Show Interface Router#show Router#show interface interface serial serial 1/0 1/0 Hardware Hardware is is M4T M4T Internet Internet address address is is 20.0.0.1/8 20.0.0.1/8 MTU MTU 1500 1500 bytes, bytes, BW BW 19 19 Kbit, Kbit, DLY DLY 20000 20000 usec, usec, rely rely 255/255, 255/255, load load 147/255 147/255 Encapsulation Encapsulation HDLC, HDLC, crc crc 16, 16, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) Last Last input input 00:00:00, 00:00:00, output output 00:00:00, 00:00:00, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0 0/75/0 (size/max/drops); (size/max/drops); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 0/1000/64/0 0/1000/64/0 (size/max (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 0/4/256 0/4/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) 55 minute minute input input rate rate 18000 18000 bits/sec, bits/sec, 88 packets/sec packets/sec 55 minute minute output output rate rate 11000 11000 bits/sec, bits/sec, 99 packets/sec packets/sec …… rest rest deleted deleted ... ...
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-89
The show interface command can be used to determine the queuing strategy. The summary statistics are also displayed. The sample output in the figure shows that there are currently no packets in the WFQ system that allows up to 1,000 packets (hold-queue limit) with CDT 64. WFQ is using 256 queues. The maximum number of concurrent conversations (active queues) was 4.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-81
Show Queue
Router#show Router#show queue queue serial serial 1/0 1/0 Input Input queue: queue: 0/75/0 0/75/0 (size/max/drops); (size/max/drops); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 2/1000/64/0 2/1000/64/0 (size/max (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 2/4/256 2/4/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) (depth/weight/discards/tail (depth/weight/discards/tail drops/interleaves) drops/interleaves) 1/4096/0/0/0 1/4096/0/0/0 Conversation Conversation 124, 124, linktype: linktype: ip, ip, length: length: 580 580 source: source: 193.77.3.244, 193.77.3.244, destination: destination: 20.0.0.2, 20.0.0.2, id: id: 0x0166, 0x0166, ttl: ttl: 254, 254, TOS: TOS: 00 prot: prot: 6, 6, source source port port 23, 23, destination destination port port 11033 11033 (depth/weight/discards/tail (depth/weight/discards/tail drops/interleaves) drops/interleaves) 1/4096/0/0/0 1/4096/0/0/0 Conversation Conversation 127, 127, linktype: linktype: ip, ip, length: length: 585 585 source: source: 193.77.4.111 193.77.4.111 destination: destination: 40.0.0.2, 40.0.0.2, id: id: 0x020D, 0x020D, ttl: ttl: 252, 252, TOS: TOS: 00 prot: prot: 6, 6, source source port port 23, 23, destination destination port port 11013 11013
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-90
The show queue command also displays the flow (conversation) statistics:
3-82
Queuing Mechanisms
n
Queue depth is the number of packets in the queue
n
Weight is 4096/(IP precedence + 1) or 32384/(IP precedence + 1), depending on the Cisco IOS version
n
Discards is the number of drops due to the CDT limit
n
Tail drops is the number of drops due to the hold-queue limit
Copyright 2001, Cisco Systems, Inc.
Queuing comparison
Weighted Fair Queuing
Priority Queuing
Custom Queuing
No queue lists
4 queues
16 queues
Low volume traffic given priority Conversation dispatching
High priority queue serviced first Packet-by-packet dispatching
Round-robin service
Interactive traffic gets priority
Critical traffic gets through
Proportional allocation of bandwidth
Works well on speeds up to 2 Mbps
Designed for low-bandwidth links
Designed for medium-speed links
Enabled by default
Must configure
Must configure
Threshold dispatching
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-91
The table shows the main differences between WFQ, PQ and CQ.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-83
Summary The goal of WFQ is to: n
Perform queuing on a per-flow basis
n
Guarantee service to all flows
n
Share bandwidth fairly
n
Prioritize traffic by giving higher-priority flows proportionately more bandwidth
n
Prioritize low-volume (interactive) traffic
Review Questions Answer the following questions:
3-84
Queuing Mechanisms
n
How does WFQ classify packets?
n
When does WFQ drop packets?
n
How does WFQ schedule packets?
Copyright 2001, Cisco Systems, Inc.
Distributed Weighted Fair Queuing Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe and configure dWFQ
n
Describe and configure ToS-based dWFQ
n
Describe and configure QoS-group-based dWFQ
n
Monitor and troubleshoot WFQ
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-85
Distributed WFQ • The term “distributed” is primarily used for features available on Versatile Interface Processors (VIP) on Cisco 7x00 routers • Cisco IOS supports the following four versions of dWFQ: – Flow-based dWFQ – ToS-based dWFQ – QoS-group-based dWFQ – Distributed Class-based WFQ • This lesson focuses on the first three versions of dWFQ
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-96
The distributed versions of Weighted Fair Queuing are implemented on Cisco 7x00 series routers with Versatile Interface Processors (VIPs). There are four different versions of distributed WFQ, three of which are discussed in this module: n
Flow-based dWFQ or simply dWFQ
n
ToS-based dWFQ
n
QoS-group-based dWFQ or QoS-based dWFQ
VIP is basically a router within a router. It has its own processor and its own (different) version of the IOS. Most features implemented on VIPs have different functionality than those available on the Route Switch Processor (RSP).
3-86
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Flow-based dWFQ Forwarded Packets Flow-based dWFQ System
Flow 1?
WFQ-drop
Queue 1
Flow 2?
WFQ-drop
Queue 2
Hardware Queuing System WFQ Scheduler
Flow N?
WFQ-drop
Hardware Q
Interface
Queue N
• Flow-based dWFQ looks the same as RSP/LE WFQ, but ... © 2001, Cisco Systems, Inc.
Queuing Mechanisms-97
The structure of Distributed Flow-based WFQ (dWFQ) is similar to that discussed in the previous lesson. There are, however, some differences.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-87
Flow-based dWFQ Classification IP
TCP
Src. Dst. Proto. Addr. Addr.
Payload
Src. Port
WFQ Classification uses the following parameters: • source IP address • destination IP address • source TCP or UDP port • destination TCP or UDP port • transport protocol
Dst. Port
A hash algorithm is used to produce the index of the queue where the packet is enqueued
Hash Algorithm
#queue (9-bit index of the queue)
• The number of queues is 512 (not tunable) • ToS is not used for classification (except in IOS version 11.1CC) © 2001, Cisco Systems, Inc.
Queuing Mechanisms-98
Classification identifies flows but it does not use the ToS field. It uses all the other parameters that identify a flow (conversation): n
Source IP address
n
Destination IP address
n
Protocol number (identifying TCP or UDP)
n
Source TCP/UDP port number
n
Destination TCP/UDP port number
The number of queues is 512 and cannot be changed.
3-88
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
dWFQ Insertion and Drop Policy • dWFQ drops packets when both the individual queue limit (IQL) and aggregate queue limit (AQL) are reached • dWFQ is not as strict with aggressive flows as non-distributed WFQ • This insertion and drop policy is the same for all three versions of dWFQ (flow-based, ToSbased and QoS-group-based)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-99
The dropping scheme of dWFQ is similar to that of non-distributed WFQ, except that it is not as strict with aggressive flows. The same dropping policy is used for all three versions of dWFQ (Flow-based dWFQ, ToS-based dWFQ and QoS-group-based dWFQ).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-89
dWFQ Insertion and Drop Policy N-th packet
M>QL?
No
Yes
N>AQL?
No
Enqueue packet
Yes
M>IQL?
No
Yes
• QL (queue limit) is the maximum number of packets the selected que ue can hold • AQL (aggregate queue limit) is the max. number of packets that the dWFQ system can hold • IQL (individual queue limit) is the max. number of packets that an individual queue a congested dWFQ system can hold • N is the number of packets in the dWFQ system when the N -th packet arrives • M is the number of packets in the queue to which the packet is cl assified © 2001, Cisco Systems, Inc.
Queuing Mechanisms-100
When a new packet is to be inserted into one of the queues the router follows these rules: 1. Enqueue the packet if the WFQ system is within the aggregate queue limit 2. Enqueue the packet if the queue is within the individual queue limit 3. Otherwise, drop the packet
3-90
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Flow-based dWFQ Scheduling Flow-based dWFQ System Queue 1
Queue 2
dWFQ Scheduler (Calendar Queuing)
Packets are scheduled (ordered) in advance for faster transfer to the hardware queue Hardware Queuing System
Calendar Queue
Hardware Q
Interface
Queue N
• Uses Calendar Queuing (optimized version of scheduling based on finish time, more jitter) • Weight (IP precedence) is NOT used for scheduling purposes (pure Fair Queuing) © 2001, Cisco Systems, Inc.
Queuing Mechanisms -101
The scheduler uses the same finish time calculation except it does not include the weight. It is a pure Fair Queuing mechanism. The scheduler was also optimized for performance (Calendar Queuing).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-91
Configuring Flow-based dWFQ Router(config-if)# fair-queue fair-queue
• The command enables dWFQ on an interface connected to a VIP2-40 or newer interface processor • For all other interfaces, this command enables RSPbased WFQ • Can be configured on interfaces but not on subinterfaces • dWFQ is not supported on Fast EtherChannel, tunnel, or other logical or virtual interfaces (MPPP)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -102
Using the fair-queue interface command enables dWFQ if the following requirements are met:
3-92
Queuing Mechanisms
n
Interface is on a VIP2-40 or newer
n
Distributed CEF is enabled
Copyright 2001, Cisco Systems, Inc.
Configuring Flow-based dWFQ Router(config)# fair-queue aggregate-limit aggregate-limit aggregate-packets
• The total number of packets in all output queues before some packets may be dropped Router(config)# fair-queue individual-limit individual-packets
• The maximum individual per-flow queue size during periods of congestion • Defaults: aggregate-limit depends on the transmission rate and the available buffer space on the VIP; individual-limit is half of the aggregate-limit • Don’t change the defaults unless necessary © 2001, Cisco Systems, Inc.
Queuing Mechanisms -103
Use these two commands to change the default limits that govern the dropping of packets when individual queues and the WFQ system are congested.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-93
Flow-based dWFQ Example interface interface FastEthernet FastEthernet 1/1/0 ip ip address address 80.0.2.70 80.0.2.70 255.255.255.0 255.255.255.0 fair-queue fair-queue fair-queue fair-queue aggregate-limit aggregate-limit 200 200 fair-queue fair-queue individual-limit individual-limit 30 30 !!
• dWFQ on a FastEthernet interface • dWFQ system should not contain more than 200 packets • No queue should accept new packets when the dWFQ system is congested and the queue is longer than 30 packets © 2001, Cisco Systems, Inc.
Queuing Mechanisms -104
The example illustrates how dWFQ was implemented on a FastEthernet interface.
3-94
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Show Interface Router#show Router#show interfaces interfaces FastEthernet1/1/0 FastEthernet1/1/0 FastEthernet1/1/0 FastEthernet1/1/0 is is up, up, line line protocol protocol is is up up Hardware Hardware is is cyBus cyBus FastEthernet FastEthernet Interface, Interface, address address is is 0007.f618.4448 0007.f618.4448 Description: Description: pkt pkt input input i/f i/f for for WRL WRL tests tests (to (to pagent) pagent) Internet Internet address address is is 80.0.2.70/24 80.0.2.70/24 MTU MTU 1500 1500 bytes, bytes, BW BW 100000 100000 Kbit, Kbit, DLY DLY 100 100 usec, usec, rely rely 255/255, 255/255, load load 1/255 1/255 Encapsulation Encapsulation ARPA, ARPA, loopback loopback not not set, set, keepalive keepalive not not set, set, 100BaseTX/FX 100BaseTX/FX ARP ARP type: type: ARPA, ARPA, ARP ARP Timeout Timeout 04:00:00 04:00:00 Last Last input input never, never, output output 01:11:01, 01:11:01, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters 01:12:31 01:12:31 Queueing Queueing strategy: strategy: VIP-based VIP-based fair fair queuing queuing Output Output queue queue 0/40, 0/40, 00 drops; drops; input input queue queue 0/75, 0/75, 00 drops drops 30 30 second second input input rate rate 00 bits/sec, bits/sec, 00 packets/sec packets/sec 30 30 second second output output rate rate 00 bits/sec, bits/sec, 00 packets/sec packets/sec …… rest rest deleted deleted ... ...
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -105
The usual show interface command reveals that VIP-based fair queuing is enabled (dWFQ). Some other show commands used with other queuing mechanisms do not display any valuable information (RSP regards this interface as FIFO).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-95
Show Interface Fair-queue
Router#show Router#show interface interface fastethernet fastethernet 1/1/0 fair fair FastEthernet FastEthernet 1/1/0 1/1/0 queue size 0 pkts pkts output output 0, 0, wfq drops 0, nobuffer nobuffer drops drops 0 WFQ: WFQ: aggregate aggregate queue queue limit limit 200 individual individual queue queue limit limit 30 max available buffers 0
• Displays dWFQ statistics
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -106
This command can be used to display some statistics about dWFQ.
3-96
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Benefits and Drawbacks of Flowbased dWFQ + Benefits • Automatic classification • High performance
– Drawbacks • Does not support the configuration of classification • Does not use IP precedence as weight • Only supported on Cisco 7x00 series routers with VIP 2-40 or newer
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -107
The distributed version of WFQ has one advantage over normal WFQ: better performance. The main drawbacks include: n
Lack of tuning capability
n
Not weighted
n
Only supported on VIPs
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-97
ToS-based dWFQ Forwarded Packets ToS -based dWFQ System
Class 1?
WFQ-drop
Queue 1
Class 2?
WFQ-drop
Queue 2
Hardware Queuing System dWFQ Scheduler
Class 3?
WFQ-drop
Queue 3
Class 4?
WFQ-drop
Queue 4
Hardware Q
Interface
• ToS-based dWFQ has four classes © 2001, Cisco Systems, Inc.
Queuing Mechanisms -108
The ToS-based dWFQ differs from Flow-based dWFQ in the following ways:
3-98
Queuing Mechanisms
n
Classification is done based on the two low-order IP precedence bits
n
Scheduling is configurable by setting weights manually
n
Four queues are used
Copyright 2001, Cisco Systems, Inc.
ToS-based dWFQ Classification IP
Payload ToS -based dWFQ Classification uses the two low -order IP precedence bits to classify packets
IP Prec. XXX 00000
#queue (2-bit index of the queue)
Queue 1
IP precedence 0 and 4
Queue 2 Queue 3
1 and 5 2 and 6
Queue 4
3 and 7
• The number of queues is 4 (fixed) • Classification is based on the two low-order IP precedence bits © 2001, Cisco Systems, Inc.
Queuing Mechanisms -109
The classification uses the two low-order IP precedence bits. The result of classification is that: n
Packets with IP precedence values 0 and 4 are classified into Queue 0
n
Packets with IP precedence values 1 and 5 are classified into Queue 1
n
Packets with IP precedence values 2 and 6 are classified into Queue 2
n
Packets with IP precedence values 3 and 7 are classified into Queue 3
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-99
ToS-based dWFQ Scheduling • One weight per class configured as a % –Sum of all weights must be =< 99 –Some bandwidth needed for Class 0 • Tail-Drop within each queue • First release: 11.1cc, 12.0
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-110
Weights that determine how much bandwidth is guaranteed to each class are configured in percentage points. Weights can be assigned to Queues 1¸ 2 and 3. Queue 0 gets the rest of the bandwidth.
3-100
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring ToS-based dWFQ Router(config-intf)# fair-queue tos
• Enables ToS-based distributed WFQ Router(config-intf)# fair-queue tos num num weight weight weight
tos number - 2 low order precedence bits (only classes 1, 2 and 3 can be configured with weight; class 0 takes the remaining bandwidth) weight - percentage of the output link bandwidth allocated to this class (the sum for all classes cannot exceed 99) Defaults: unclassified traffic is assigned to class 0; class 1 - 20, class 2 - 30, class 3 - 40 class 0 has the remaining weight (100%-W1-W2-W3); default 10 © 2001, Cisco Systems, Inc.
Queuing Mechanisms -111
ToS-based dWFQ is enabled using the fair-queue tos interface command. Note
Copyright 2001, Cisco Systems, Inc.
Distributed CEF has to be enabled prior to using this command.
Queuing Mechanisms
3-101
Configuring ToS-based dWFQ Router(config-if)# fair-queue tos tos num limit class-packets
• Configures maximum number of packets allowed in the selected queue • If not configured, the default is individual-limit • If queue limit is not configured it is set to the number of available buffers multiplited by weight Router(config-if)# fair-queue fair-queue individual-limit individual-limit individual-packet individual-packet
• If individual limit is not configured it is set to one quarter of the number of available buffers Router(config-if)# fair-queue aggregate-limit aggregate-packets
• If aggregate limit is not configured is set to the number of availble buffers
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-112
These three optional commands can be used to control individual queue sizes. The default behavior is:
3-102
Queuing Mechanisms
n
Aggregate queue limit equals maximum available buffers
n
Individual queue limit equals one quarter of maximum available buffers
n
Per-queue limit equals maximum available buffers multiplied by weight
Copyright 2001, Cisco Systems, Inc.
ToS-based WFQ Configuration Example interface interface Hssi0/0/0 Hssi0/0/0 ip address 188.1.3.70 255.255.255.0 fair-queue tos tos fair-queue tos tos 1 weight weight 20 fair-queue tos tos 1 limit 27 fair-queue tos tos 2 weight weight 30 fair-queue tos tos 2 limit 27 fair-queue tos tos 3 weight weight 40 fair-queue tos tos 3 limit 27 !!
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -113
The example shows how ToS-based dWFQ is configured on VIP-based interfaces.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-103
Show Interface Fair-queue
Router#show interfaces fair-queue fair-queue Hssi0/0/0 Hssi0/0/0 queue queue size size 00 pkts pkts output output 947, 947, wfq wfq drops drops 0, nobuffer drops 0 WFQ: WFQ: aggregate aggregate queue queue limit limit 386 386 individual individual queue queue limit limit 96 96 max available available buffers buffers 386 386 Class Class Class Class Class Class Class Class
© 2001, Cisco Systems, Inc.
0: 0: 1: 1: 2: 2: 3: 3:
weight weight weight weight weight weight weight weight
10 10 20 20 30 30 40 40
limit limit limit limit limit limit limit limit
20 27 27 27
qsize qsize qsize qsize qsize qsize qsize qsize
00 00 00 00
pkts pkts pkts pkts pkts pkts pkts pkts
output output output output output output output output
947 947 drops drops 00 00 drops drops 00 00 drops drops 00 00 drops drops 00
Queuing Mechanisms -114
The show interface fair-queue command can be issued to display parameters and statistics for VIP-based interfaces.
3-104
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Benefits and Drawbacks of ToSbased dWFQ + Benefits • Automatic classification • Guarantees throughput to all classes • High performance
– Drawbacks • All drawbacks of FIFO queuing within a single class • Does not support the configuration of classification • Only four classes are supported • Unusual interpretation of IP precedence (high-priority packets with IP precedence 6 and 7 share queues with lower-priority packets with IP precedence 2 and 3) • Only supported on Cisco 7x00 series routers with VIP 2-40 or newer © 2001, Cisco Systems, Inc.
Queuing Mechanisms -115
The ToS-based dWFQ represents the first class-oriented queuing mechanism available on VIPs. The main drawbacks of this queuing mechanism are that it: n
Supports only four classes
n
Mixes packets of different IP precedence values
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-105
QoS-group-based dWFQ Forwarded Packets QoS-group-based dWFQ System
Class 1?
WFQ-drop
Queue 1
Class 2?
WFQ-drop
Queue 2
Hardware Queuing System dWFQ Scheduler
Class 100?
WFQ-drop
Hardware Q
Interface
Queue 100
• QoS-group-based dWFQ supports 100 classes © 2001, Cisco Systems, Inc.
Queuing Mechanisms -116
QoS-group-based dWFQ was introduced to provide a solution to ToS-based dWFQ drawbacks:
3-106
Queuing Mechanisms
n
4 classes are upgraded to 100 classes
n
Classification is more flexible (any other parameter can be translated into the QoS group number)
Copyright 2001, Cisco Systems, Inc.
QoS-group-based dWFQ Classification Packet Buffer
Buffer Header
Frame Header
IP Header
Payload
QoS group
• The number of queues is 100 • Classification is based on the QoS group parameter • The parameter is local to the router and it has to be set by some other QoS mechanism: – Policy-based Routing (PBR) – Committed Access Rate (CAR) – QoS Policy Propagation through BGP (QPPB) – Class-based Marking – Class-based Policing © 2001, Cisco Systems, Inc.
Queuing Mechanisms -117
Classification is performed using the QoS group parameter to select one of the 100 queues. The QoS group parameter is local to the router so it has to be set on every hop using one of the QoS mechanisms that supports marking: n
Policy-based Routing (PBR)
n
QoS Policy Propagation through BGP(QPPB)
n
Committed Access Rate (CAR)
n
Class-based Policing
n
Class-based Marking
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-107
QoS-group-based dWFQ Scheduling • Scheduling is identical to that of ToS-based dWFQ • One weight per class configured as a % –Sum of all weights must be =< 99 –Some bandwidth needed for Class 0 • Tail-Drop within each queue
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-118
Scheduling and configuration of scheduling and dropping is identical to that of ToSbased dWFQ. The only difference is that there are up to 100 queues to configure.
3-108
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring QoS-group-based dWFQ Router(config-intf)# fair-queue qos-group qos-group
• Enables ToS-based distributed WFQ Router(config-intf)# fair-queue qos-group qos-group num weight weight
qos-group number - classes 1 through 99 can be configured with weight; class 0 takes the remaining bandwidth weight - percentage of the output link bandwidth allocated to this class (the sum for all classes cannot exceed 99) Defaults: unclassified traffic is assigned to class 0; class 1 - 20, class 2 - 30, class 3 - 40 class 0 has the remaining weight (100%-W1-W2-W3); default 10 © 2001, Cisco Systems, Inc.
Queuing Mechanisms -119
Replacing ToS-based dWFQ involves using only the fair-queue qos-group interface command. All existing fair-queue tos commands are replaced with fair-queue qos-group commands. Note
Copyright 2001, Cisco Systems, Inc.
Replacing ToS-based dWFQ with QoS-group-based dWFQ causes all packets to go into Queue 0 because classification is no longer perform ed based on IP precedence value. Some additional configuration steps are necessary.
Queuing Mechanisms
3-109
Configuring QoS-group-based dWFQ Router(config-intf)# fair-queue qos-group qos-group num limit class-packets
• Configures individual queue depth – class-packets - maximum number of packets allowed in the queue for the class during periods of congestion
• If not configured, the default is individual-limit, which is half of the aggregate queue limit Router(config-intf)# fair-queue fair-queue aggregate-limit aggregate-packets aggregate-packets fair-queue fair-queue individual-limit individual-packet
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -120
These commands have the same meaning as with ToS-based dWFQ.
3-110
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
QoS-group-based dWFQ Example • QoS-group-based dWFQ can be used to implement mapping of different parameters into QoS group: – Assume another mechanism has been configured to translate QoS class information into QoS group (e.g. QPPB) – Use QoS-group-based dWFQ output queuing
• Example: – allocate 10% to class 1 traffic allocate 30% to class 2 traffic allocate 60% to other traffic
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -121
The case study involves using three queues. Classification and marking is performed using QPPB where the QoS group is set based on some BGP information (for example, BGP community attribute).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-111
QoS-group based WFQ Configuration Example interface interface FastEthernet1/0/0 FastEthernet1/0/0 bgp-policy bgp-policy destination destination ip-qos-map ip-qos-map !! ... ... !! interface interface Hssi0/0/0 Hssi0/0/0 ip ip address address 188.1.3.70 188.1.3.70 255.255.255.0 255.255.255.0 bgp-policy bgp-policy destination destination ip-prec-map ip-prec-map fair-queue fair-queue qos-group qos-group fair-queue fair-queue aggregate-limit aggregate-limit 60 fair-queue fair-queue qos-group qos-group 1 weight weight 10 fair-queue fair-queue qos-group qos-group 2 weight weight 30 fair-queue fair-queue qos-group qos-group 2 limit limit 27 27 !!
© 2001, Cisco Systems, Inc.
3-112
Queuing Mechanisms
Queuing Mechanisms -122
Copyright 2001, Cisco Systems, Inc.
Monitoring QoS-group-based dWFQ Router#show Router#show interfaces interfaces fair-queue fair-queue Hssi0/0/0 Hssi0/0/0 queue queue size size 00 pkts pkts output output 4, 4, wfq wfq drops drops 0, 0, nobuffer nobuffer drops drops 00 WFQ: WFQ: aggregate aggregate queue queue limit limit 60 60 individual individual queue queue limit limit 96 96 max max available available buffers buffers 386 386 Class Class 0: 0: weight weight 60 60 limit limit 231 231 qsize qsize 00 pkts pkts output output 44 drops drops 00 Class Class 1: 1: weight weight 10 10 limit limit 38 38 qsize qsize 00 pkts pkts output output 00 drops drops 00 Class Class 2: 2: weight weight 30 30 limit limit 27 27 qsize qsize 00 pkts pkts output output 00 drops drops 00
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -123
The show interface fair-queue command only displays information for queues with a weight higher than zero.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-113
Benefits and Drawbacks of QoSgroup-based dWFQ + Benefits • Guarantees throughput to all classes • A large number of classes (100) • High performance
– Drawbacks • All drawbacks of FIFO queuing within a single class • Requires other QoS mechanisms to set QoS group • Only supported on Cisco 7x00 series routers with VIP 2-40 or newer
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -124
QoS-group-based dWFQ is the first high-performance class-oriented queuing mechanism. Its main drawback is that it is only available on Cisco 7x00 series routers with VIPs.
3-114
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
dWFQ Summary Classification
Classes
Weighted
Implementation
Fairnes
WFQ
Per-flow
16 to 4096
Yes (IP precedence)
RSP/LE
dWFQ
Per-flow
512
No
VIP
ToS dWFQ
IP precedence
4
Manual
VIP
QoS dWFQ
QoS group
100
Manual
VIP
CB-WFQ*
Manual
64
Manual
RSP/LE/VIP
* Class-based WFQ is covered in the “Modular QoS CLI” module © 2001, Cisco Systems, Inc.
Queuing Mechanisms -125
The figure illustrates the comparison of all versions of Weighted Fair Queuing. n
Traditional WFQ is only available on low-end (LE) routers and the Route Switch Processor (RSP) of Cisco 7x00 series routers
n
All three distributed versions are only available on VIP-based interfaces of Cisco 7x00 series routers
Class-based WFQ is now available on low-end routers, the RSP and on the VIP (distributed)
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-115
Summary There are five versions of WFQ: n
Flow-based WFQ (non-distributed, per-flow queuing)
n
Flow-based dWFQ (not weighted, per-flow queuing, fixed number of queues)
n
ToS-based dWFQ (four queues, limited classification options)
n
QoS-group-based dWFQ (up to 100 queues, requires marking on every hop)
n
CB-WFQ
Review Questions Answer the following questions:
3-116
Queuing Mechanisms
n
Which distributed Weighted Fair Queuing mechanisms do you know?
n
What are the main differences between dWFQ versions?
n
What platforms support dWFQ?
Copyright 2001, Cisco Systems, Inc.
Modified Deficit Round-robin Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe MDRR queuing
n
Describe the benefits and drawbacks of MDRR queuing
n
Configure MDRR queuing on Cisco GSR routers
n
Monitor and troubleshoot MDRR
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-117
Modified Deficit Round Robin • Deficit Round Robin (DRR) is a class-based queuing mechanism available on Cisco GSR routers • MDRR supports 8 classes • Low-latency queuing is introduced in the Modified Deficit Round Robin (MDRR)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -130
Modified Deficit Round-robin (MDRR) is a class-oriented queuing mechanism available on Cisco 12000 series routers (GSR). It supports eight classes, one of which can be used for low-delay propagation.
3-118
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
MDRR Architecture Forwarded Packets Modified Deficit Round Robin
Class 1?
Tail -drop WRED
VOQ 1
Class 2?
Tail -drop WRED
VOQ 2 MDRR Scheduler
Class 8?
Tail -drop WRED
Hardware Queuing System or Crossbar Switching Fabric
Interface
VOQ 8
• MDRR supports 8 classes (8 RR queues, one can be high-priority) • MDRR is implemented on the receive side (in front of the Crossbar Switching Matrix) and on the transmit side (in front of an interface) © 2001, Cisco Systems, Inc.
Queuing Mechanisms -131
MDRR classifies packets based on IP precedence value. Each queue can be configured to support WRED. MDRR can be implemented on output to interfaces (as in all other queuing mechanisms) or in front of the GSR’s Crossbar Switching Matrix.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-119
MDRR Features • Deficit Round Robin (DRR) is using eight Virtual Output Queues (VOQ) to prevent head-of-line blocking • DRR can use Weighted Random Early Detection (WRED) within each class to prevent congestion within the class • Modified DRR (MDRR) can have one high priority queue for delay-sensitive traffic being serviced in either of the two supported modes: – Strict priority – Alternate priority
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -132
DRR was the first implementation that was later improved by allowing one queue to be high priority.
3-120
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
MDRR Classification IP precedence 0 VOQ 0 IP precedence 1
VOQ 1
VOQ 2
IP precedence 7
VOQ 7
• MDRR supports classification of any IP precedence into any of the 8 virtual output queues • One of the 8 queues can be used as low-latency queue © 2001, Cisco Systems, Inc.
Queuing Mechanisms -133
Classification is done using IP precedence to put packets into one of the eight Virtual Output Queues (VOQ). One of these queues can be configured as high priority.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-121
MDRR Insertion and Drop Policy
Tail-drop or WRED
Virtual Output Queue
• MDRR uses a traditional tail-drop scheme if a queue is congested • MDRR can also use Weighted Random Early Detection (WRED) to prevent congestion
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -134
Each queue uses the tail-drop scheme unless it is configured with WRED.
3-122
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
DRR Scheduling Each queue can transmit a configured amount of bytes in one round: MTU + (weight-1)*512 VOQ 0 VOQ 1
Round Robin Scheduler
VOQ 7
• Service policy for one queue in one round: 1. Add MTU+(Weight-1)*512 tokens to the token bucket. 2. Transmit packets until tokens are used up or the queue is empty. 3. Reset the token bucket to 0 if the queue is empty. Otherwise remember the deficit (how much more tokens were used than available). 4. Start serving the next queue. © 2001, Cisco Systems, Inc.
Queuing Mechanisms -135
The scheduling of DRR is similar to that of Custom Queuing, except it is more accurate. DRR remembers the number of bytes it sent above the threshold in the previous round (deficit).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-123
MDRR Scheduling with Strict Priority Queue LL Queue VOQ 0 VOQ 1
Str ict Qu Priori t eui ng y
The Strict Priority Low-latency Queue is not limitted by the Token Bucket mechanism
Round Robin Scheduler
VOQ 7
• Service policy for MDRR with Strict Priority: 1. Transmit packets from the Strict Priority Low-latency Queue until the queue is empty. 2. Serve the next-in-line round robin queue. 3. Start serving the Low-latency queue again.
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -136
MDRR can schedule one queue ahead of all the others if it is configured as a Strict Priority queue. This queue can be used for delay-sensitive applications (for example, voice). The problem of this solution is that it can cause other queues to starve if the high priority queue is congested.
3-124
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
MDRR Scheduling with Alternate Priority Queue LL Queue VOQ 0 VOQ 1
Alt er Pr nate Qu iority eui ng
The Alternate Priority Queue is using the Token Bucket to limit the amount of bytes it can transmit in one round
Round Robin Scheduler
VOQ 7
• Service policy for MDRR with Alternate Priority: 1. Transmit packets from the Alternate Priority Low-latency Queue until the tokens are used up or the queue is empty. 2. Serve the next-in-line round robin queue 3. Start serving the Low-latency queue again.
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -137
The high priority queue can be set to Alternate Priority mode where all other queues still get service, even if the high-priority queue is congested. The high priority queue, however, experiences slightly more delay because it has to wait for the currently served queue to reach its threshold or be emptied.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-125
Benefits and Drawbacks of MDRR + Benefits • Accurate bandwidth allocation (takes into account the deficit from the previous round as opposed to Custom Queuing) • Prevents head-of-line blocking in front of the crossbar switching fabric • Supports low-latency queuing (strict priority and alternate priority) • High performance
– Drawbacks • Limited classification tools (only IP precedence) • Limited number of classes (only 8) • Only supported on Cisco 12000 series routers (GSR)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -138
MDRR is a high performance queuing mechanism that supports eight classes and allocates bandwidth according to configured weights. It also supports one queue for low-delay propagation of packets.
3-126
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Interface MDRR Router(config)# cos-queue-group cos-queue-group-name cos-queue-group-name
• Create a queue group template and enter COS queue group configuration mode Router(config-cos-que)# precedence precedence queue {queue-number|low-latency} {queue-number|low-latency}
• Map IP precedence to a queue Router(config-cos-que)# queue queue-number weight
• Set weight of a queue
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -139
Configuration of MDRR requires a cos-queue -group to be configured first. All MDRR configuration is performed in the cos-queue -group configuration mode. The first step is to map an IP precedence value to one of the eight queues. Each queue can be configured with a weight that determines the number of bytes that can be transmitted in one round.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-127
Configuring Interface MDRR Router(config-cos-que)# queue low-latency {alternate-priority weight|strict-priority}
• Specify the type of low-latency queue Router(config-if)#
tx-cos cos-queue-group-name
• Associate a COS queue group name with the transmit queues on an interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -140
One of the queues can be turned into a high priority queue. The type of queue is determined by the alternate-priority or strict-priority keywords. The last step is to apply the cos-queue-group to an output interface.
3-128
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Receive MDRR Router(config)# slot-table-cos slot-table-name
• Define a slot table name and enter slot table configuration mode Router(config-slot-cos)# destination slot slot {slot-number|all} {slot-number|all} cos-queue-group-name
• Define destination slot parameters for this slot table name Router(config)# rx-cos-slot line-card-number cos-queue-group-name
• Link a slot-table-cos template to a line card
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -141
MDRR can also be applied to traffic leaving the line card through the Crossbar Switching Matrix. A slot-table -cos has to be configured where the destination line cards are specified using the destination slot command. The slot table is then applied to one or more line cards using the rx-cos-slot command.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-129
MDRR Example interface interface POS3/0 POS3/0 ip address 1.0.0.1 255.0.0.0 tx-cos tx-cos C4template C4template !! cos-queue-group cos-queue-group C4template precedence 0 queue 0 precedence 1 queue 1 precedence 2 queue 1 precedence 3 queue 2 precedence 4 queue 2 precedence 5 queue low-latency precedence 6 queue 3 precedence 7 queue 3 queue 0 10 10 queue 1 20 20 queue 2 40 40 queue queue low-latency low-latency alternate-priority alternate-priority 80 80 exit exit !! © 2001, Cisco Systems, Inc.
Queuing Mechanisms -142
The example illustrates a sample configuration of MDRR applied to traffic leaving the POS interface.
3-130
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting MDRR Router#
show cos statistics • Display MDRR statistics Router#show Router#show cos statistics Slot Slot 33 ----------------------------Dest Dest slot slot 55 cos-queue-group: cos-queue-group: C7template C7template ... ... Queue Queue Lengths Lengths To To Fabric Fabric Queues Queues (DRR (DRR configured) configured) C7template Queue Average High Queue Average High Water Water Mark Mark 00 712.000 5562.000 712.000 5562.000 11 702.000 7716.000 702.000 7716.000 22 702.000 11540.000 702.000 11540.000 33 753.000 14368.000 753.000 14368.000 44 0.000 0.000 0.000 0.000 55 0.000 0.000 0.000 0.000 66 0.000 0.000 0.000 0.000 Low latency 0.000 0.000 Low latency 0.000 0.000 ... ...
Weight Weight 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -143
The show cos statistics can be used to display results of MDRR.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-131
Summary MDRR is a class-oriented queuing mechanism available on the Cisco 1200 series routers. It allows bandwidth guarantees to eight classes and low-delay propagation to one class. MDRR can be applied to outbound traffic or traffic leaving a line card through the Crossbar Switching Matrix.
Review Questions Answer the following questions:
3-132
Queuing Mechanisms
n
Describe the scheduling mechanism of MDRR.
n
Which two types of low-latency queuing does MDRR support?
n
What are the benefits and drawbacks of MDRR?
n
Where can MDRR be applied?
Copyright 2001, Cisco Systems, Inc.
IP RTP Prioritization Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe IP RTP prioritization
n
Describe the benefits and drawbacks of IP RTP prioritization
n
Configure IP RTP prioritization on Cisco routers
n
Monitor and troubleshoot IP RTP Prioritization
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-133
IP RTP Prioritization • IP RTP Prioritization provides low-latency queuing when used in combination with WFQ or CB-WFQ • It can only be used with UDP traffic with predictable port numbers • It is usually used for VoIP traffic • IP RTP Prioritization is limited to prevent starvation of other traffic
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -148
IP RTP Prioritization is an add-on to WFQ to support low-delay propagation of packets. It can be used for UDP traffic only. IP RTP Prioritization also polices the high priority traffic to prevent starvation of other queues.
3-134
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
IP RTP Prioritization Forwarded Packets High Priority?
Weighted Fair Queuing System Flow 1?
WFQ-drop
Queue 1
Flow 2?
WFQ-drop
Queue 2
Hardware Queuing System
WFQ Scheduler
Flow N?
WFQ-drop
RTP Scheduler
Hardware Q
Interface
Queue N
• IP RTP prioritization adds one high-priority queue to WFQ © 2001, Cisco Systems, Inc.
Queuing Mechanisms -149
IP RTP Prioritization supports one high priority queue. Packets from this queue are scheduled ahead of other packets as long as they are within the configured rate. Excess packets are dropped.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-135
IP RTP Priority Classification Forwarded Packets
IP
UDP
Payload UDP Destination port
UDP port In range? No
Yes
RTP Queue
WFQ Queuing System
• IP RTP Prioritization classifies packets based on the UDP port number • Classification is specified by a range of UDP port numbers © 2001, Cisco Systems, Inc.
Queuing Mechanisms -150
IP RTP Prioritization classifies packets based on UDP port numbers. If the destination UDP port is within the configured range it is enqueued into the high priority queue.
3-136
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
IP RTP Priority Insertion and Drop Policy Classified Packets
Token Bucket
Packet within Contract?
Yes
RTP Queue
No
• IP RTP Prioritization limits the amount of high-priority traffic • Excess traffic is dropped © 2001, Cisco Systems, Inc.
Queuing Mechanisms -151
Packets that exceed the policy are dropped. A token Bucket model is used to measure the arrival rate of packets into this queue.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-137
Benefits and Drawbacks of IP RTP Prioritization + Benefits • Adds low-latency queuing to WFQ and CBWFQ • Prevents starvation of other traffic
– Drawbacks • Poor classification options • Obsoleted by Class-based Low-latency Queuing
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -152
The main benefit of IP RTP Prioritization is that it allows low-latency propagation when using WFQ. The main drawback is that it has limited classification capabilities (UDP port range only). IP RTP Prioritization was made obsolete by the introduction of Class-based Low Latency Queuing (discussed in the “IP QoS - Modular QoS CLI” module).
3-138
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring IP RTP Prioritization Router(config-if)# ip rtp priority priority starting-port port-range port-range bandwidth bandwidth
• Creates a separate priority queue for VoIP packets and specifies maximum bandwidth available to voice traffic • Maximum bandwidth shall always be slightly larger than actually required bandwidth due to jitter in the network and the Layer-2 overhead • Only UDP packets with a destination port number in the configured range are classified into this queue Router(config-if)# max-reserved-bandwidth percent
• Specifies the maximum bandwidth percentage that can be allocated to class-based WFQ and priority RTP traffic • The remaining bandwidth is available to flow-classified best-effort traffic and control packets • Default: 75% of the interface bandwidth can be reserved © 2001, Cisco Systems, Inc.
Queuing Mechanisms-153
Configuration of IP RTP Prioritization requires using the ip rtp priority command where the following parameters have to be specified: n
Starting UDP port number
n
UDP port range (added to the starting port number)
n
Maximum and guaranteed bandwidth
If the requested bandwidth is less than 75% of the bandwidth configured on the interface, the command will fail. Reservable bandwidth can be increased by using the max-reserved-bandwidth interface command.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-139
IP RTP Prioritization Example interface interface Serial0/0 Serial0/0 bandwidth bandwidth 128 ip ip address address 10.0.0.1 10.0.0.1 255.255.255.252 encapsulation ppp ppp fair-queue fair-queue ip ip rtp priority 16384 16383 50 50 !!
Up to 75% of configured bandwidth is reservable.
BWavail = BW * 0.75 - BWRTP
Router#show Router#show queue queue serial0/0 serial0/0 Input Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total Total output output dr drops: ops: 00 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations Conversations 0/1/256 0/1/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 46 46 kilobits/sec kilobits/sec Router# Router#
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -154
The sample configuration shows how 50 kbps of bandwidth is guaranteed for RTP traffic. The show queue command shows there is only 46 kbps of bandwidth (128 kbps • 75% -50 kbps = 46 kbps) remaining for WFQ.
3-140
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Summary IP RTP Prioritization adds low-latency queuing capability to WFQ. It can only classify packets into one queue based on the UDP port range.
Review Questions Answer the following questions: n
When would you use IP RTP prioritization?
n
What are the drawbacks of IP RTP prioritization?
n
How many high-priority queues does IP RTP prioritization support?
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-141
Summary After completing this module, you should be able to perform the following tasks:
3-142
Queuing Mechanisms
n
Describe and configure FIFO Queuing (FQ)
n
Describe and configure Priority Queuing (PQ)
n
Describe and configure Custom Queuing (CQ)
n
Describe and configure basic Weighted Fair Queuing (WFQ), distributed WFQ, ToS-based distributed WFQ and QoS-group-based distributed WFQ
n
Describe and configure Modified Weighted Round-robin (MDRR) queuing
n
Describe and configure IP RTP Prioritization
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Queuing Overview Question: Which queuing mechanisms do Cisco routers support? Answer: First In First Out (FIFO), Priority Queuing (PQ), Custom Queuing (CQ), Weighted Fair Queuing (WFQ) with the different distributed versions, Modified Deficit Round Robin (MDRR), IP RTP Prioritization, Class-based WFQ and Class-based Low-latency Queuing. Question: When is a software queuing mechanisms not used? Answer: Routers bypass the software queue (hold queue) if it is empty and there is room in the hardware queue (TxQ). Question: How does TxQ length affect the software queuing system? Answer: A long TxQ can cause FIFO drawbacks; a short TxQ can cause high CPU utilization and low link utilization.
FIFO Queuing Question: Why is FIFO the fastest queuing mechanism? Answer: It has no classification and the simplest scheduling mechanism. Question: Describe the classification and scheduling of FIFO queuing. Answer: FIFO has only one queue and all packets are enqueued into this queue. Scheduling takes packets out of the queue in the order they arrived (first come first serve). Question: List the drawbacks of FIFO queuing. Answer: FIFO queuing can cause starvation and jitter.
Priority Queuing Question: When would you use priority queuing? Answer: To provide minimum-delay forwarding for delay-sensitive packets. Question: What are the benefits and drawbacks of priority queuing? Answer: PQ has all the drawbacks of FIFO queuing within each class and in addition it can cause starvation of lower-priority classes. Question: How many classes does priority queuing support? Answer: PQ supports four classes. Question: How does priority queuing schedule packets? Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-143
Answer: PQ schedules packets in the priority order. Lower-priority packets are scheduled only when all higher-priority queues are empty.
Custom Queuing Question: When would you use custom queuing? Answer: CQ is used to guarantee bandwidth to traffic classes. Question: What are the benefits and drawbacks of custom queuing? Answer: CQ has all the drawbacks of FIFO queuing within each class. In addition CQ can cause jitter due to the implementation of scheduling. Question: How many classes does custom queuing support? Answer: CQ supports up to 16 classes. Question: How does custom queuing schedule packets? Answer: CQ uses weighted round robin scheduling to ensure that each class is serviced.
Weighted Fair Queuing Question: How does WFQ classify packets? Answer: WFQ classifies packets based on the flow information (source and destination IP addresses and TCP/UDP port numbers, protocol identifier and ToS field). Question: When does WFQ drop packets? Answer: WFQ drops packets of the longest queue when the number of packets in the queuing system reaches the CDT (congestive discard threshold). Question: How does WFQ schedule packets? Answer: WFQ schedules packets with the shortest finish time.
Distributed Weighted Fair Queuing Question: Which distributed Weighted Fair Queuing mechanisms do you know? Answer: Distributed WFQ versions: flow-based, ToS-based and QoS-groupbased. Question: What are the main differences between dWFQ versions? Answer: Distributed versions of WFQ differ primarily in the classification. Question: What platforms support dWFQ? Answer: Cisco 7x00 series routers with VIP-based interfaces support dWFQ. 3-144
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Modified Deficit Round-robin Question: Describe the scheduling mechanism of MDRR. Answer: MDRR uses an improved implementation of round robin scheduling to provide more accurate allocation of bandwidth.
Question: Which two types of low-latency queuing does MDRR support? Answer: MDRR can use one queue for strict priority or alternate priority queuing. Question: What are the benefits and drawbacks of MDRR? Answer: MDRR is fast accurate and prevents head-of-line blocking in front of the crossbar switching matrix. MDRR only supports 8 queues and can only classify based on IP precedence.
Question: Where can MDRR be applied? Answer: MDRR can be used on output interfaces or in front of the crossbar switching matrix.
IP RTP Prioritization Question: When would you use IP RTP prioritization? Answer: To provide low-latency queuing with IOS versions that do not support CB-LLQ. Question: What are the drawbacks of IP RTP prioritization? Answer: Limited classification options (only one UDP port range is supported). Question: How many high-priority queues does IP RTP prioritization support? Answer: One per interface.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-145
4
Traffic Shaping and Policing
Overview This module describes for the QoS mechanisms that are used to limit the available bandwidth to traffic classes. It discusses two options—traffic policing and traffic shaping. Committed Access Rate (CAR) is discussed as a mechanism to provide traffic policing. Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping (FRTS) are discussed as traffic shaping mechanisms. It includes the following topics: n
Traffic Shaping and Policing
n
Generic Traffic Shaping
n
Frame Relay Traffic Shaping
n
Committed Access Rate
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe and configure Generic Traffic Shaping (GTS)
n
Describe and configure Frame Relay Traffic Shaping (FRTS)
n
Describe and configure Committed Access Rate (CAR)
n
Identify other mechanisms that support traffic shaping and policing (Classbased Policing and Class-based Shaping)
Traffic Shaping and Policing Overview The lesson introduces mechanisms for traffic policing and traffic shaping. Committed Access Rate (CAR), Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping (FRTS) are introduced in this section.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
4-2
n
Describe the need for implementing traffic policing and shaping mechanisms
n
List traffic policing and shaping mechanisms available in Cisco IOS
n
Describe the benefits and drawbacks of traffic shaping and policing mechanisms
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Traffic Shaping and Policing Meter
Classifier
Marker
Dropper
Traffic stream
• Traffic Shaping and Policing mechanisms are used to rate-limit traffic classes • They have to be able to classify packets and meter their rate of arrival • Traffic Shaping delays excess packets to stay within the rate limit • Traffic Policing typically drops excess traffic to stay within the limit; alternatively it can remark excess traffic © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-5
Both shaping and policing mechanisms are used in a network to control the rate at which traffic is admitted into the network. Both mechanisms use classification, so they can differentiate traffic. They also use metering to measure the rate of traffic and compare it to the configured shaping or policing polic y. The difference between shaping and policing can be described in terms of their rate-limiting implementation: n
Shaping meters the traffic rate and delays excessive traffic so that it stays within the desired rate limit. With shaping, traffic bursts are smoothed out producing a steadier flow of data. Reducing traffic bursts helps reduce congestion in the core of the network.
n
Policing drops excess traffic in order to control traffic flow within specified limits. Policing does not introduce any delay to traffic that conforms to traffic policies. It can however, cause more TCP retransmissions, because traffic in excess of specified limits is dropped.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-3
Why Use Rate Limiting • To handle congestion at ingress to ATM/FR network with asymmetric link bandwidths • To limit access to resources when highspeed access is used but not desired • To limit certain applications or classes • To implement a virtual TDM system
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-6
Rate limiting is typically used to satisfy one of the following requirements:
4-4
n
Prevent and manage congestion in ATM and Frame Relay networks, where asymmetric bandwidths are used along the traffic path. This prevents the layer-2 network from dropping large amounts of traffic by differentiately dropping excess traffic at ingress to the ATM or Frame Relay networks based on Layer-3 information (for example: IP precedence, DSCP, access list, protocol type, etc.)
n
Limit the access rate on an interface when high-speed physical infrastructure is used in transport, but sub-rate access is desired.
n
Engineer bandwidth so that traffic rates to certain applications or classes of traffic follow a specified traffic -rate policy.
n
Implement a virtual TDM system, where an IP network is used, but has the bandwidth characteristics of a TDM system (that is, fixed maximum available bandwidth). Inbound and outbound policing can, for example, be used on one router to split a single point-to-point link into two or more virtual point-to-point links by assigning a portion of the bandwidth to each class, thus preventing any class from monopolizing the link in either direction.
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Typical Traffic Shaping or Policing Applications High-speed link
WAN
Output interface is not congested queuing and WRED do not work
Congestion in WAN network results in non-intelligent layer2 drops
256 kbps
128 kbps Server Farm
© 2001, Cisco Systems, Inc.
FastEthernet
64 kbps
Low-speed link
Limiting access to resources
Implementing a virtual TDM or Leased line over a single physical link on one side
Internet
IP QoS Traffic Shaping and Policing-7
The figure shows three possible applications of rate-limiting (shaping or policing) mechanisms. The first picture shows a Layer-2 WAN with unequal link bandwidths along a Layer-3 path. The ingress (left side) of the network has a highspeed link available into the Layer-2 backbone, which enables it to send traffic at a high rate. At the egress side, the sent traffic hits a low-speed link, and the Layer-2 network is forced to drop a large amount of traffic. If traffic were rate-limited at the ingress, optimal traffic flow occurs, resulting in minimal dropping by the Layer2 network. The second picture shows a hosting farm, which is accessible from the Internet via a shared link. Depending on the service contract, the hosting provider may offer different bandwidth guarantees to customers, and may want to limit the resources a particular server uses. Rate limiting can be used to divide the shared resource (upstream link) between many servers. The third example shows the option of implementing virtual leased lines over a Layer-3 infrastructure, where rate-limited reserved bandwidth is available over a shared link.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-5
Shaping vs. Policing • Benefits of Shaping – Shaping does not drop packets – Shaping supports interaction with Frame Relay congestion indication
• Benefits of Policing – Policing supports marking – Less buffer usage (shaping requires an additional queuing system)
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-8
A shaper typically delays excess traffic using a buffer, or mechanism, to hold packets and shape the flow when the data rate of the source is higher than expected. Traffic shaping smoothes traffic by storing traffic above the configured rate in a queue. Therefore, shaping increases buffer utilization on a router, but causes non-deterministic packet delays. Shaping can also interact with a Frame Relay network, adapting to indications of Layer-2 congestion in the WAN. A policer typically: n
Drops non-conforming traffic
n
Supports marking of traffic
n
Is more efficient in terms of memory utilization (no additional buffering of packets in needed)
n
Does not increase buffer usage
Both policing and shaping ensure that traffic does not exceed a bandwidth limit, but they have different impacts on the traffic:
4-6
n
Policing drops packets more often, generally causing more retransmissions of connection-oriented protocols
n
Shaping adds variable delay to traffic, possibly causing jitter
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
How do Routers Measure Traffic Rate Bandwidth
Link bandwidth Exceeding traffic Rate limit Conforming Traffic Time
• Routers use the Token Bucket mathematical model to keep track of packet arrival rate • The Token Bucket model is used whenever a new packet is processed • The return value is conform or exceed © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-9
In order to perform rate limiting, routers must meter (or measure) traffic rates through their interfaces. To enforce a rate limit, metered traffic is said to: n
Conform to the rate limit, if the rate of traffic is below or equal to the configured rate limit
n
Exceed the rate limit, if the rate of traffic is above the configured rate limit
The metering is usually performed with an abstract model called a token bucket, which is used when processing each packet. The token bucket can calculate whether the current packet conforms or exceeds the configured rate limit on an interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-7
Token Bucket
200 700
500 bytes
© 2001, Cisco Systems, Inc.
Conform Action
500 bytes
IP QoS Traffic Shaping and Policing -10
The token bucket is a mathematical model used in a device that regulates the data flow. The mode has two basic components: n
Tokens: where each token represents the permission to send a fixed number of bits into the network
n
The bucket: which has the capacity to hold a specified amount of tokens
Tokens are put into the bucket at a certain rate by the operating system. Each incoming packet, if forwarded, takes tokens from the bucket, representing the packet’s size. If the bucket fills to capacity, newly arriving tokens are discarded. Discarded tokens are not available to future packets. If there are not enough tokens in the bucket to send the packet, the regulator may: n
Wait for enough tokens to accumulate in the bucket (traffic shaping)
n
Discard the packet (policing)
The figure shows a token bucket, with the current capacity of 700 bytes. When a 500-byte packet arrives at the interface, its size is compared to the bucket capacity (in bytes). The packet conforms to the rate limit (500 bytes < 700 bytes), and the packet is forwarded. 500 tokens are taken out of the token bucket leaving 200 tokens for the next packet.
4-8
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Token Bucket
200
300 bytes
Exceed Action
s byte 300
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -11
When the next packet arrives immediately after the first packet, and no new tokens have been added to the bucket (which is done periodically), the packet exceeds the rate limit. The packet size is greater than the current capacity of the bucket, and the exceed action is performed (drop in the case of pure policing, delay in the case of shaping).
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-9
Token Bucket Be
Bc of tokens is added every Tc [ms]
Link BW
Link Utilization Bc
Bc
Bc
Bc
Bc
Bc
2*Tc
3*Tc
4*Tc
5*Tc
Tc = Bc / CIR Tc
Average BW (CIR)
Time
Bc + B e
• Bc is normal burst size (specifies sustained rate) • Be is excess burst size (specifies length of burst)
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -12
Token bucket implementations usually rely on three parameters: CIR, Bc and Be. CIR is the Committed Information Rate (also called the committed rate, or the shaped rate). Bc is known as the burst capacity. Be is known as the excess burst capacity. Tc is an interval constant that represents time. A Bc of tokens are forwarded without constraint in every Tc interval. In the token bucket metaphor, tokens are put into the bucket at a certain rate, which is Bc tokens every Tc seconds. The bucket itself has a specified capacity. If the bucket fills to capacity (Bc + Be), it will overflow and therefore newly arriving tokens are discarded. Each token grants permission for a source to send a certain number of bits into the network. To send a packet, the regulator must remove, from the bucket, the number of tokens equal in representation to the packet size. For example, if 8000 bytes worth of tokens are placed in the bucket every 125 milliseconds, the router can steadily transmit 8000 bytes every 125 milliseconds, if traffic constantly arrives at the router. If there is no traffic at all, 8000 bytes per 125 milliseconds get accumulated in the bucket, up to the maximum size (Bc+Be). One second’s accumulation therefore collects 64000 bytes worth of tokens, which can be transmitted immediately in the case of a burst. The upper limit, Bc+Be, defines the maximum amount of data, which can be transmitted in a single burst, at the line rate. Note
4-10
Again, note that the token bucket mechanism used for traffic shaping has both a token bucket and a queue used to delay packets. If the token bucket did not have a data buffer, it would be a policer. For traffic shaping, packets that arrive that cannot be sent immediately (because there are not enough tokens in the bucket) are delayed in the data buffer.
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Although token bucket permits burstiness, traffic bursts are bound. This guarantee is made so that traffic flow will never send faster than the token bucket's capacity. In the long-term, this means that the transmission rate will not exceed the established rate at which tokens are placed in the bucket (the committed rate).
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-11
Traffic Shaping and Policing Mechanisms • Shaping Mechanisms: – Generic Traffic Shaping (GTS) – Frame Relay Traffic Shaping (FRTS) – Class-based Shaping
• Policing Mechanisms: – Committed Access Rate (CAR) – Class-based Policing
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -13
There are five token-bucket based rate-limiting methods available in Cisco IOS. Three methods are shaping mechanisms: n
Generic traffic shaping
n
Frame Relay traffic shaping
n
Class-based shaping
Two methods are policing mechanisms: n
Committed access rate
n
Class-based policing
All these methods are discussed next in specific sections.
4-12
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Describe the need for implementing traffic policing and shaping mechanisms
n
List traffic policing and shaping mechanisms available in Cisco IOS
n
Describe the benefits and drawbacks of traffic shaping and policing mechanisms
Lesson Review Answer the following questions: 1. How do shaping and policing mechanisms keep track of the traffic rate? 2. Which shaping mechanisms are available with the Cisco IOS software? 3. Which policing mechanisms are available with the Cisco IOS software? 4. What are the main differences between shaping and policing?
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-13
Generic Traffic Shaping Overview This lesson describes the Generic Traffic Shaping (GTS) mechanism.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
4-14
n
Describe the GTS mechanism
n
Describe the benefits and drawbacks of GTS
n
Configure GTS on Cisco routers
n
Monitor and troubleshoot GTS
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Generic Traffic Shaping Meter
Classifier Traffic stream
Marker
Shaper Dropper
• Can shape multiple classes (classification) • Can measure traffic rate of individual classes (metering) • Delays packets of exceeding classes (shaping) © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -18
Generic Traffic Shaping (GTS) shapes traffic by reducing the outbound traffic flow to avoid congestion. This is achieved by constraining traffic to a particular bit rate using the token bucket mechanism. GTS is applied on a per-interface basis and can use access lists to select the traffic to shape. It works with a variety of Layer-2 technologies, including Frame Relay, ATM, Switched Multi-megabit Data Service (SMDS) and Ethernet. As shown in the block diagram, GTS performs three basic functions: n
Classification of traffic, so that different traffic classes can have different policies applied to them
n
Metering, using a token-bucket mechanism, to distinguish between conforming and exceeding traffic
n
Shaping, using buffering, to delay exceeding traffic and shape it to the configured rate limit
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-15
GTS Building Blocks
Forwarder
Classifier
Yes
Shaping WFQ
No
No No
Classifier
Yes
Yes
No
Classifier
Shaping WFQ
Yes Yes
No
Shaping WFQ
Yes
No
© 2001, Cisco Systems, Inc.
Physical Interface queue(s) IP QoS Traffic Shaping and Policing -19
GTS is implemented as a queuing mechanism, where there are separate WFQ delay queues implemented for each traffic class. Each WFQ-queue delays packets until they conform to the rate-limit, and also schedules them according to the WFQ algorithm. Conforming traffic is then sent to the physical interface. Arriving packets are first classified into one of the shaping classes. Traffic not classified into any class is not shaped. Classification can be performed using access lists. Once a packet is classified into a shaping class, its size is compared to the amount of available token in the token bucket of that class. The packet is forwarded to the main interface queue if there are enough tokens. A number of tokens taken out of the token bucket is equal to the size of the packet (in bytes). If, on the other hand, there are not enough tokens to forward the packet, the packet is buffered in the WFQ system assigned to this shaping class. The router will then periodically replenish the token bucket and check if there are enough tokens to forward one or more packets out of the shaping queue. Packets are scheduled out of the shaping queue according to the WFQ scheduling algorithm.
4-16
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS Overview • GTS is multiprotocol • GTS uses WFQ as the shaping queue • GTS can be implemented in combination with any queuing mechanisms: – FIFO Queuing – Priority Queuing (PQ) – Custom Queuing (CQ) – Weighted Fair Queuing (WFQ)
• GTS works on output only
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -20
The GTS implementation in Cisco IOS supports multiple protocols and works on a variety of interface types. WFQ is used as the shaping delay queue, providing fair scheduling within a traffic class. Other queuing strategies (FIFO, PQ, CQ and WFQ) may be employed after GTS to provide traffic scheduling on the shaped traffic. Also, GTS only works at the output of an interface. GTS can be used to shape all outbound traffic on an interface or it can separately shape multiple classes. Classification is performed using any type of access list including all non-ip access lists.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-17
GTS Implementation Dispatches packets at configured rate
Shaping Queue (WFQ)
Dispatches packets at line rate
Dispatches packets at line rate
Software Queue
Hardware Queue
(FIFO, PQ, CQ, WFQ, ...)
(FIFO)
Bypass the software queue if it is empty and there is room in the hardware queue
• The software queue may have no function if the sum of all shaping rates is less than link bandwidth © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -21
Packet flow through GTS is implemented using three queues. The first, the shaping queue, is WFQ-based and shapes traffic according to the specified rate using a token bucket model. This queue dispatches packets to the software queue, which may be configured with other queuing mechanisms (PQ, CQ, WFQ or FIFO). If the software queue is empty, traffic is forwarded directly to the output hardware queue. GTS supports distributed implementation on VIP adapters. This offloads traffic shaping from the route switch processor (RSP) to the Versatile Interface Processor (VIP), and constructs all of the queues in VIP packet memory. Only IP traffic can be shaped with dWFQ. Another requirement is that dCEF switching must be enabled.
4-18
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Configuring GTS Router(config-if)#
traffic-shape rate bit-rate [burst-size [excessburst-size]]
• Enables traffic shaping of all outbound (sub)interface traffic • In IOS versions prior to 11.2(19) and 12.0(4), optimum switching is disabled on all interfaces if traffic shaping is enabled on any interface
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -22
To enable traffic shaping for outbound traffic on an interface, use the trafficshape rate interface configuration command. Of the parameters to be specified, bit-rate is the only mandatory one. The burst-size and excess-burst-size are optional. Generic traffic shaping can be used in all switching paths. Older Cisco IOS versions may use slower switching paths when GTS is in effect.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-19
Configuring GTS Router(config-if)#
traffic-shape rate bit-rate [burst-size [excessburst-size]]
• Bit rate – average traffic rate in bps (equivalent to Frame Relay CIR) • Burst size – amount of traffic sent in a measurement interval in bits (equivalent to Frame Relay Bc) Default value: 1/8 of bit rate
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-23
Bit rate (in bits per second) is configured as the average traffic rate to which the traffic should be shaped on the output of the interface. Burst size (in bits) can be configured to allow for varying levels of allowed burstiness. That is, traffic, which bursts over the average traffic rate, also conforms if it falls within the burst rate in an interval. By default, this is set to one eighth of the average traffic rate, which sets the Tc at one eighth of a second. This parameter is equivalent to the Frame Relay Bc parameter.
4-20
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Configuring GTS Router(config-if)#
traffic-shape rate bit-rate [burst-size [excessburst-size]]
• Excess-burst-size - amount of excess traffic that can be sent during the first burst in bps (equivalent to Frame Relay Be) Default value: no excess burst • Measurement interval (Tc) is computed from bit-rate and burst -size Tc smaller than 25 ms is rejected, Tc greater than 125 ms is reduced © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -24
The excess-burst-size parameter (in bits), equivalent to the Frame Relay Be parameter, defines the excess burst of traffic, which can still be sent through the first noticed burst. By default, there is no excess burst allowed. The Tc parameter defines the measurement interval, which is used in the operation of the token bucket. By default, it is directly computed from the bit rate and the burst size as Bc divided by the average bit rate. To ensure proper operation of shaping, those parameters are bounded to values between 25 and 125 ms.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-21
Configuring GTS Router(config-if)#
traffic-shape group access-list bit-rate [burst [excess-burst]] • Shapes outbound traffic matched by the specified access list • Several traffic-shape group commands can be configured on the same interface • The “traffic-shape rate“ and “traffic-shape group“ commands cannot be mixed on the same interface • Separate token bucket and shaping queue is maintained for each traffic-shape group command • Traffic not matching any access list is not shaped
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -25
Classification of traffic to be shaped is performed using access lists. To enable traffic shaping based on a specific access list for outbound traffic on an interface, use the traffic-shape group interface configuration command. The traffic-shape group command allows specification of one or more previously defined access lists to shape traffic on the interface. One traffic-shape group command must be specified for each access list on the interface. Cisco IOS uses separate token buckets and shaping queues for each class, as differentiated by the access list specification. Traffic not matching any access list bypasses traffic shaping and is immediately sent to the software or hardware interface queue. Use the traffic-shape rate command if no classification is needed and shaping should be applied to all traffic. Remember that the traffic-shape group command using an IP access list permitting all IP traffic is not equivalent to the traffic-shape rate command if non-IP traffic is present in the network.
4-22
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS Example #1 • ISP wants to sell a service in which a customer may use all of a E1 line for 30 seconds in a burst, but on a long term average is limited to 256 kbps • GTS parameters – bit-rate: 256000 - output rate is 256000 bps – burst-size: 32000 the number of bits sent in 125 msec – excess-burst-size: 61440000 = 2048000 * 30
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-26
In the first GTS example, an ISP wants to control the amount of traffic injected into the Frame Relay WAN by the customer. The SP service uses an E1 line as the access line, limits the customer to 256 Kbps on the average, but also permits bursts of up to thirty seconds at the E1 line rate. The parameters are calculated based on the service requirements. CIR (the average bit rate) is set at the specified average rate, the burst size is set to one eighth of the CIR (32000 bits), and the excess burst size reflects the allowed thirtysecond burst at full E1 line rate. The excess burst size was calculated using the following formula: 1. Each second of transmission at line-speed requires 2 Mbits 2. Thirty second burst therefore requires 30 x 2 Mbits 3. The excess burst size is 30 x 2048000 = 61440000 It takes thirty seconds to empty the token bucket. How long does it take to fill it up again? The token bucket is emptied at 2Mbps but it is replenished at 256kbps. It takes eight times as long to fill it as it does to empty it. Every thirty second burst would, therefore, require a four-minute silence on the line to accumulate tokens.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-23
GTS Example #1
WAN Core Customer interface interface ethernet ethernet0/0 0/0 traffic-shape traffic-shape rate rate 256000 256000 32000 32000 61440000 61440000 !! interface interface serial1/0 serial 1/0 traffic-shape traffic-shape rate rate 256000 256000 32000 32000 61440000 61440000
• Since ISP wants to control the total amount of load the configuration would be done on both the inbound and outbound interfaces © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-27
The figure shows the router configuration required to implement this service. All the output traffic is shaped, and the shaping needs to be configured on all customer edge sites, which will perform admission control using GTS.
4-24
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS Example #2
WAN Core Customer interface interface ethernet ethernet 0/0 0/0 traffic-shape traffic-shape group group 101 101 64000 64000 interface interface serial serial 1/0 1/0 traffic-shape traffic-shape group group 101 101 64000 64000 !! access-list access -list 101 101 permit permit tcp tcp any any any any eq eq www www
• The customer wants to be sure that Web traffic will never use more than 64 kbps © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-28
In the second example, a customer wants to limit web usage, so that web traffic never uses more than 64 Kbps on the access link. The router configuration is shown in the figure, using default parameters for traffic bursts. An access list defines web traffic as the only shaped traffic. All other traffic bypasses GTS and can use the full access line bandwidth.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-25
Monitoring GTS Router(config)#
show traffic-shape
• Displays current traffic shaping configuration MAX = (Bc + Be)/8
Router#show access I/F list Se3/3
CIR
Be
Bc = Tc * CIR
traffic-shape Target Byte Sustain Excess Interval Increment Adapt Rate Limit bits/int bits/int (ms) (bytes) Active 100000 2000 8000 8000 80 1000 -
Bc
Tc=Bc/CIR
do we listen to FECN/BECN?
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-29
The figure shows the results of the show traffic-shape command issued on a router that shapes traffic to 100kbps with Bc and Be set to 8000. To display the current traffic-shaping configuration, use the show traffic-shape command. To display the current traffic -shaping statistics, use the show trafficshape statistics command. Output of both the commands is detailed in the ensuing figures. Information displayed includes:
4-26
n
The rate that traffic is shaped to
n
The maximum number of bytes transmitted per internal interval
n
Configured sustained bits per interval
n
Configured excess bits in the first interval
n
Interval being used internally (may be smaller than the committed burst divided by the CIR)
n
Number of bytes that will be sustained per internal interval
n
If Frame Relay has FECN/BECN adaptation configured
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Monitoring GTS Router(config)#
show traffic-shape statistic
• Displays traffic shaping statistics Number of packets/bytes sent on the interface
Router#show traffic-shape traffic-shape statistic statistic Access Packets Bytes Access Queue Queue Packets Bytes I/F List Depth List Depth Se3/3 77 16091 16091 3733112 3733112
Depth of the associated WFQ queue for delayed packets
Packets Packets Delayed 414 414
Bytes Bytes Delayed 96048 96048
Shaping Shaping Active Active yes yes
Subset of the previous number of packets/bytes delayed via the WFQ queue
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-30
The show traffic-shape statistics command displays the statistics of traffic shaping for all the configured interfaces. Displayed in the output is: n
The interface where the traffic-shape rate or traffic-shape group command is used (traffic-shape rate command is used on interface serial3/3 in the example)
n
The associated access list if the traffic-shape group command is used
n
The number of packets currently in the shaping queue (queue depth)
n
The total number of packets that have been processed by the traffic-shape command since the last clearing of interface counters (16091 packets in the example)
n
The total number of bytes that have been processed by the traffic-shape command since the last clearing of interface counters (3733112 bytes in the example)
n
The total number of packets that have been delayed by the traffic-shape command since the last clearing of interface counters (414 packets in the example)
n
The total number of bytes that have been delayed by the traffic-shape command since the last clearing of interface counters (96048 bytes in the example)
n
If the queue depth is more than 0 than shaping is active
The expected result of traffic shaping is a high ratio between transmitted packets and delayed packets. Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-27
If the number of delayed packets is very high (compared to the total number of packets) then there are probably non-responsive aggressive flows being shaped and the queue depth could show high buffer utilization. If the number of delayed packets is zero then it is very likely that the access list does not match any traffic.
4-28
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Monitoring GTS Router(config)#
show traffic-shape queue
• Displays the shaping queue contents router#show router#show traffic-shape traffic-shape queue queue Traffic queued in shaping queue on Serial0 (depth/weight) 1/4096 Conversation 254, linktype: linktype: ip, ip, length: 232 source: source: 1.1.1.1, 1.1.1.1, destination: destination: 1.1.2.47, id: 0x0001, ttl: ttl: 208, 208, TOS: TOS: 00 prot: prot: 17, source source port port 11111, 11111, destination destination port port 22222 22222
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -31
The show traffic-shape queue command displays the contents of the shaping queue associated with an interface. This command can be used to determine the types of flows that are congesting the shaping queue. The command displays the parameters that are used for classification within WFQ: n
Source IP address
n
Destination IP address
n
Time to live (TTL)
n
Type of Service (ToS) field
n
Protocol ID
n
Source port number
n
Destination port number
The example shows that there is a non-responsive UDP flow (protocol 17) congesting the shaping queue.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-29
GTS on Frame Relay Interfaces • GTS can be implemented on any type of (sub)interface • GTS supports additional features when implemented on Frame Relay interfaces: – Adaptation to Frame Relay congestion notification – BECT-to-FECN reflection – FECN creation on congestion
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -32
GTS applies on a per-interface basis, can use access lists to select the traffic to shape, and works with a variety of Layer-2 technologies, including: n
Frame Relay
n
ATM
n
Switched Multi-megabit Data Service (SMDS)
n
Ethernet
On a Frame Relay subinterface, GTS can be set up to shape to a specified rate and to adapt dynamically to available bandwidth by integrating Frame Relay congestion signaling with GTS.
4-30
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Frame Relay Refresher • Frame Relay Explicit Congestion Notification – FECN (Forward Explicit Congestion Notification) – BECN (Backward Explicit Congestion Notification) – CLLM (Consolidated Link Layer Management)
• Implicit Congestion Notification – Network discards detected by end user at higher layers – DE (Discard Eligibility) bit
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -33
Frame Relay performs congestion notification to its Layer-2 endpoints by including congestion signaling inside the Layer-2 frame headers. n
The FECN, BECN and DE bits in the Q.922 header of the frame provide inband congestion signaling.
n
The Forward Explicit Congestion Notification (FECN) is bit set by a Frame Relay network to notify a device (FR DTE, which may be a router) that it should initiate congestion avoidance procedures.
n
The Backward Explicit Congestion Notification (BECN) is bit set by a Frame Relay network to notify a device (DTE) that it should initiate proper congestion avoidance procedures.
n
CLLM is an enhanced signaling method, used by Frame Relay switches, which expands on the FECN/BECN mechanism to improve congestion management.
n
The Discard Eligibility (DE) bit indicates that a frame may be discarded in preference to other frames, if congestion occurs, to maintain the committed quality of service within the network. Frames with the DE bit set are considered Be excess data.
Congestion notification may be explicit (honored by Layer-2 devices) or implicit (detected and honored by higher-layer protocols, not by the Layer-2 network). FECN/BECN and CLLM are explicit methods, while BE-setting is an implicit notification method.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-31
Frame Relay FECN/BECN Congestion Control Switch Switch monitors monitors all all transmit transmit queues queues for for congestion congestion
S e n d e r
Frame 1
No Congestion this Side Frame Frame 22
BECN
Frame 11
Frame Frame Relay Relay Switch
FECN
Congestion this Side Frame 2
R e c e i v e r
Same Virtual Circuit (VC)
• FR Switch detects congestion on output queue and informs: – The receiver by setting the FECN bit on forwarded frames – The source by setting the BECN bit on frames going in the opposite direction © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -34
A Frame Relay switch can explicitly report congestion in two directions: Forward and Backward. When a frame queue inside a switch is congested, the switch will generate congestion signals based on the FECN and BECN bits. If congestion occurs in a queue towards the main receiver of traffic, FECN signals are sent to the receiving Layer-2 endpoint and BECN signals are sent to the sending Layer-2 endpoint. FECN and BECN bits are not sent as separate frames, but are piggybacked inside data frames.
4-32
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS Frame Relay Congestion Adaptability • On a Frame Relay (sub)interface, GTS can adapt dynamically to available Frame Relay bandwidth by integrating BECN signals – The GTS bit rate is reduced when BECN packets are received to reduce the data flow through congested Frame Relay network – Adaptation is done on per (sub)interface basis – GTS bit rate is gradually increased when the congestion is no longer present (no BECN packets are received any more)
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -35
BECN is the flag that the sending DTE (router as a Frame Relay endpoint) is able to integrate to determine the congestion status of the Layer-2 WAN.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-33
GTS Frame Relay Congestion Adaptability Mechanisms • Bit-rate adaptation – Traffic shaping bit-rate is reduced when a packet with BECN bit is received in the Tc – Traffic shaping bit-rate is increased if no BECN bits were received in the Tc
• FECN to BECN propagation – A test packet with BECN bit set is sent to the sender if a packet with FECN bit set is received
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -36
The first adaptation mechanism is bit-rate adaptation. GTS is able to respond to Layer-2 congestion by reducing its shaping rate to three-quarters of the current rate, until the Layer-2 network recovers from congestion. When BECN flags are no longer received, the rate is slowly ramped up again to the original shaping rate. This is also a lower limit of rate reduction, which bounds the reduction process so that at least some throughput is maintained. The BECN-integrating functionality is performed on a per sub-interface (DLCI) basis. However, if the congestion was caused by simplex traffic (such as a multicast video stream) or by an aggressive TCP connection, it is expected that the reverse traffic (frames flowing from the receiver to the sender, marked with the BECN bit) might come by less frequently than required to feed the integration. So the receiving DTE (the receiving router) can help matters when it receives a message with FECN set by first checking to see if it has any data, and if it does not, originating a message with BECN set. This message might be a Q.922 TEST RESPONSE message, which would by virtue of its message type be understood to be a message to discard and not reply to. This feature is called FECN-to-BECN propagation.
4-34
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
An Example of BECN Integration becn INC added every Tc in the token Bucket
9000
BECN Integration 8000
becn 7000
6000
5000
Inc
4000
traffic-shape rate 64000 8000 8000 traffic-shape adaptive 32000
3000
2000
BECN received at Tc#1 and Tc#3
1000
Hypothesis: no idle traffic
0 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
time represented in units of Tc © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -37
The figure shows the shaped rate of a token bucket-based GTS responding to BECN packets it received. As mentioned, the rate is reduced to three-quarters of the previous rate for every Tc interval, which saw at least one BECN message received at the router. When no BECN messages are received in a Tc period, the shaped rate is brought up slowly, up one-sixteenth of the current rate.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-35
FECN to BECN Propagation
S e n d e r
FECN
Frame Relay Switch Switch
Congestion
BECN in Q.922Test
R e c e i v e r
If there is no reverse traffic, the switch is not able to set BECN in frames going back to sender
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -38
The other adaptation method, FECN-to-BECN propagation, configures a Frame Relay sub-interface to reflect received FECN bits as BECN in Q.922 TEST RESPONSE messages. This enables the sender to notice congestion in the Layer2 network, even if there is no data traffic flowing from the receiver back to the sender.
4-36
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Configuring Bit-rate Adaptation Router(config-if)#
traffic-shape adaptive [bit-rate]
• Configures Traffic Shaping Frame Relay bit-rate adaptation bit-rate - lowest bit-rate the traffic is shaped to in response to continuous BECN signals Default: 1/2 the specified traffic shaping rate • Traffic shaping has to be enabled
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -39
Frame Relay bit rate adaptation is configured using the traffic-shape adaptive command, which specifies the lower limit to which the shaped rate should be reduced in presence of incoming BECN signals. By default, this is half the configured sustained (committed) rate in GTS. The bit rate is configured in bits per second.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-37
Configuring FECN to BECN propagation Router(config-if)#
traffic-shape traffic-shape fecn-adapt
• Configures the router to send Frame Relay TEST message with BECN bit set in response to receiving a frame with FECN bit set • Can be used without adaptive traffic shaping Router(config-if)#
traffic-shape traffic-shape fecn-create fecn-create
• Sets FECN bit in all outgoing packets that have been delayed due to traffic shaping • Use for debugging/simulation only © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -40
The traffic-shape fecn-adapt command enables the FECN-to-BECN propagation. It can be used without adaptive GTS, as configured with the previous command. This feature should be used for testing purposes only. If the feature is combined with the adaptation feature it is very likely that the first delayed packet will cause the shaping to slow down to the minimum shaping rate. For example: 1. Router A (sender) sends a frame with a FECN bit because it had to delay a packet. 2. Router B (receiver) replies with the TEST frame with the BECN bit set 3. Router A (sender) reduces the shaping rate due to the received BECN causing even more delay and more packets with the FECN bit set.
4-38
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS Frame Relay Adaptation Design Conservative scenario • Set shaping rate to CIR • Set minimum rate to MIR (or 1/2 CIR)
Optimistic scenario • Set shaping rate to EIR • Set minimum rate to CIR
Realistic scenario • Set shaping rate to EIR • Set minimum rate to MIR (or 1/2 CIR)
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -41
To illustrate different possibilities of adaptation, consider the following three scenarios for using GTS over a Frame Relay circuit n
In a conservative scenario, where there should be minimal congestion and dropping, the shaping rate is set to the contracted Frame Relay CIR (Committed Information Rate) and the minimum rate of adaptation is set either to MIR (Minimum Information Rate) or half the CIR value. MIR depends on the provider’s over provisioning of the network and can be as low as one-tenth of the CIR. This configuration minimizes dropping, but does not allow excess bandwidth to be fully utilized.
n
In an optimistic scenario, the normal shaping rate may be set to the EIR (Excess Information Rate) and the minimum rate to the CIR. This configuration would probably cause too much dropping in a loaded Frame Relay network.
n
In a realistic scenario, utilizing most excess bandwidth can be achieved by setting the shaping rate to the EIR and the minimum adaptation rate to the MIR (or half the CIR). This would allow full advantage to be made of the Frame Relay network, if possible, and to adapt to a realistic level if congestion is indicated.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-39
GTS Frame Relay Adaptation Example
WAN Core Customer
interface interface serial 0/0 0/0 traffic-shape traffic-shape rate rate 64000 8000 8000 traffic-shape traffic-shape adaptive adaptive 48000 48000
• EIR = 64 kbps • CIR = 48 kbps • Assumption: Frame Relay network is usually not congested © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -42
This GTS shape rate adaptation example shows a configuration of GTS, where traffic is shaped to the EIR of 64 Kbps, with the adaptive floor being equal to CIR, which is contracted at 48 Kbps. No FECN-to-BECN propagation is configured. This example would work optimally only if the Frame Relay network is unlikely to get congested because setting the adaptive floor to the CIR cannot lower the shaping rate below the CIR. Lowering the rate below the contracted CIR may be necessary in most commercial Frame Relay networks.
4-40
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Summary n
GTS can be applied only on output interfaces
n
GTS performs traffic shaping or smoothing
n
GTS cannot mark or drop packets
n
GTS supports BECN and FECN in Frame Relay environments
n
GTS does not support cascaded policies
n
GTS does not provide managed discard
n
GTS cannot run in distributed mode
n
GTS supports only extended IP access lists
n
GTS supports RSVP as it uses WFQ
Lesson Review Answer the following questions: 1. What software queuing mechanisms are supported in combination with GTS? 2. Which queuing structure does GTS use? 3. What features does GTS include when used on Frame Relay interfaces?
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-41
Frame Relay Traffic Shaping Overview The section describes the Frame Relay Traffic Shaping (FRTS) mechanism.
Objectives Upon completion of this section, you will be able to perform the following tasks:
4-42
n
Describe the FRTS mechanism
n
Describe the benefits and drawbacks of FRTS
n
Compare the GTS and FRTS mechanisms
n
Configure FRTS on Cisco routers
n
Monitor and troubleshoot FRTS
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Frame Relay Traffic Shaping Meter
Classifier
Marker
Traffic stream
Shaper Dropper
• Can NOT shape multiple classes • Can be implemented on per-vc basis (classification) • Can measure traffic rate of individual virtual circuits (metering) • Delays packets of exceeding VC-s (shaping) • Dynamic Traffic Throttling on a Per-VC Basis (BECN or ForeSight) • Enhanced Queuing Support on a Per-VC Basis (PQ, CQ or WFQ) © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -48
Cisco has long provided support for FECN for DECnet and OSI, and BECN for SNA traffic using LLC2 encapsulation and DE bit support. FRTS builds upon this existing Frame Relay support with additional capabilities that improve the scalability and performance of a Frame Relay network, thereby increasing the density of VCs and improving response time. Frame Relay Traffic Shaping (FRTS) can eliminate bottlenecks in Frame Relay networks that have high-speed connections at the central site and low-speed connections at branch sites. Rate enforcement can be configured to limit the rate at which data is sent on the VC at the central site. Using FRTS, rate enforcement can be configured to either the CIR or some other defined value such as the excess information rate on a per-VC basis. The ability to allow the transmission speed used by the router to be controlled by criteria other than line speed (that is, by the CIR or the excess information rate) provides a mechanism for sharing media by multiple VCs. Bandwidth can be allocated per VC, creating a virtual time-division multiplexing (TDM) network. PQ, CQ and WFQ can also be defined at the VC or subinterface level. Using these queuing methods allows for finer granularity in prioritising and queuing of traffic, thus providing more control over the traffic flow on an individual VC. If CQ is combined with the per-VC queuing and rate enforcement capabilities, Frame Relay VCs are enabled to carry multiple traffic types, such as IP, SNA and IPX, with guaranteed bandwidth for each traffic type. Using information contained in the BECN-tagged packets received from the network, FRTS can also dynamically throttle traffic. With BECN-based throttling, packets are held in the buffers of the router to reduce the data flow from the router into the Frame Relay network. The throttling is done on a per-VC basis and Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-43
the transmission rate is adjusted based on the number of BECN-tagged packets received. With the Cisco FRTS feature, ATM ForeSight closed loop congestion control can be integrated to actively adapt to downstream congestion conditions.
4-44
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
FRTS Building Blocks
No classifier, shaping performed on individual VC
Forwarder + Frame Relay maps
Enough Tokens?
Enough Tokens?
Shaping Queue
No
No Yes
Shaping Queue
Yes Enough Tokens?
No
Shaping Queue
Yes
Traffic for VCs that are not shaped
© 2001, Cisco Systems, Inc.
Physical Interface queue(s)
IP QoS Traffic Shaping and Policing-48
In this block diagram, FRTS operation on a physical Frame Relay interface is shown. There is no global pre-classification of traffic, but packets are sent to their individual VCs instead. Shaping is then performed on a per-VC basis, with a separate shaping queue/token bucket for each VC. Packets coming out of their individual per-VC shapers are then sent to the physical interface queue (Tx queue/Tx ring).
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-45
FRTS Overview • FRTS is multiprotocol • FRTS can use one of the following queuing mechanisms as the shaping queue: – Priority Queuing (PQ) – Custom Queuing (CQ) – Weighted Fair Queuing (WFQ)
• FRTS can only be implemented in combination with WFQ on the interface • FRTS works on output only
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -50
FRTS is a shaping implementation that supports multiple protocols. Unlike GTS, which performs a WFQ-based scheduling on the entry of the shaper with an arbitrary scheduling mechanism on the physical interface, FRTS performs its operations the other way around. FRTS can use priority queuing, custom queuing, or weighed fair queuing as the scheduling method on the entry of the shaper. This allows for finer granularity in the prioritization and queuing of traffic and provides more control over the traffic flow on an individual VC. If CQ is combined with the per-VC queuing and rate enforcement capabilities, Frame Relay VCs are enabled to carry multiple traffic types, with bandwidth guaranteed for each traffic type. For example, if CQ is combined with the per-VC queuing and rate enforcement capabilities, FR VC’s can be enabled to carry IP, SNA and IPX traffic, with bandwidth guaranteed for each. At the physical interface itself (after the packet has been fancy queued and shaped) WFQ needs to be enabled in conjunction with FRTS. WFQ is currently the only supported interface scheduling method. FRTS can only be configured on the output of an interface.
4-46
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS vs. FRTS Generic Traffic Shaping
Frame Relay Traffic Shaping
• Works on any (sub)interface
• Works only on Frame Relay
• Shapes traffic on (sub)interface basis
• Shapes traffic of individual virtual circuits
• Any physical interface queuing can be used
• Only WFQ can be used on physical interface
• Only WFQ can be used for shaping queue
• CQ, PQ or WFQ can be used in shaping queue
Generic Traffic Shaping is equivalent to Frame Relay Traffic Shaping when it’s configured on point-to-point Frame Relay subinterfaces
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -51
The figure compares GTS to FRTS, based on their main differences. Generic Traffic Shaping: n
Works on any (sub) interface type
n
Shapes traffic on that (sub)interface basis
n
Can use any physical interface queuing (FIFO, PQ, CQ or WFQ)
n
Only uses WFQ as the shaping queue (that is, on the input of the shaper)
In contrast, Frame Relay Traffic Shaping: n
Works only on Frame Relay (sub) interfaces
n
Shapes traffic inside individual FR Virtual Circuits
n
Only permits WFQ as the physical interface queuing method
n
Can use any queuing method as the shaping queue (that is, on the input of the shaper)
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-47
Configuring FRTS • Define the shaping parameters (map-class) – Token-bucket parameters – Frame Relay congestion adaptation – Shaping queue type
• Enable Frame Relay traffic shaping on physical interface • Apply the shaping definition – For all VCs on (sub)interface – For individual PVC/SVC
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -52
Enabling FRTS on an interface enables both traffic shaping and per-VC queuing on all the interface's PVCs and SVCs. Traffic shaping enables the router to control the circuit's output rate and, if configured, to react to congestion notification information. Queuing enables per-VC scheduling of traffic to be shaped. Configuring FRTS involves: Step 1
4-48
Defining the shaping parameters with the map-class command
Step 2
Enabling FRTS on the physical interface
Step 3
Applying the shaping parameters to all, or selected, VCs on that interface
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Creating a Map Class Router(config)#
map-class frame-relay name
• Creates a new Frame Relay map class or starts editing existing map-class • Map class names are case sensitive
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -53
The map-class frame -relay command defines the per-VC shaping and queuing parameters. A case-sensitive name must be assigned to each map class.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-49
Define Map-class Shaping Queue Router(config-map-class)#
frame-relay priority-group number
• Selects priority queuing as the shaping queue structure Router(config-map-class)#
frame-relay custom-queue-list number
• Selects custom queuing as the shaping queue structure Router(config-map-class)#
frame-relay frame-relay fair fair cdt max-queue rsvp-queues rsvp-queues max-buf max-buf
• Selects WFQ as the shaping queue structure • FRF.12 requires weighted fair queuing © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -54
Inside the map class, the frame-relay priority-group, frame-relay customqueue -list, and frame-relay fair keywords enable a queuing discipline of either priority, custom or weighed fair queuing, respectively. This queuing discipline is used for traffic departing on a VC, before shaping is applied to it. If FRF.12 payload compression is used, WFQ needs to be configured as the queuing discipline.
4-50
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Define Traffic Shaping Parameters Router(config-map-class)#
frame-relay [in|out] [in|out] cir cir bit-rate frame-relay [in|out] [in|out] bc bits frame-relay [in|out] be bits
• Specifies the shaping parameters in CIR/Bc/Be values • Tc is computed from CIR and Bc • Only outgoing values can be specified for FRTS Router(config-map-class)#
frame-relay traffic-rate traffic-rate average-rate peak-rate
• Specifies only the CIR and peak rate • Tc is specified by the router • Bc and Be are computed from Tc, average and peak rate
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -55
Per-VC traffic shaping parameters specify shaping behavior for the configured map class. Two configuration mechanisms are available: n
Specification of CIR, Bc and Be parameters of the per-VC token bucket
n
Specification of per-VC average rate and peak rate, where Bc and Be are computed from the default Tc, average rate and peak rate
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-51
Define Congestion Adaptation Mechanism Router(config-map-class)#
frame-relay adaptive-shaping adaptive-shaping becn|foresight becn|foresight
• Enables adaptive shaping for the Frame Relay map class • Congestion indication mechanism could be BECN or Foresight (CLLM) Router(config-map-class)#
frame-relay mincir rate
• Specifies the minimum bit rate for congestion adaptation algorithm
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -56
As part of the map class definition, either BECN or ForeSight are used as the congestion backward notification mechanism to which traffic shaping will adapt. The BECN adaptation feature is the same as with GTS, thus the router reacts to received BECN signals by reducing its shaping rate. The ForeSight adaptation feature uses the network traffic control software used in Cisco Frame Relay switches. When the ForeSight feature is enabled on the switch, the switch will periodically send out a ForeSight message based on the time value configured. The time interval can range from 40 to 5000 milliseconds. The ForeSight feature allows Cisco Frame Relay routers to process and react to ForeSight messages and adjust VC-level traffic shaping in a timely manner. Note
The ForeSight feature is only available in combination with Cisco WAN switches.
The difference between the BECN and ForeSight congestion notification methods is that BECN requires a user packet to be sent in the direction of the congested DLCI to convey the signal. The sending of user packets is not predictable and, therefore, is not reliable as a notification mechanism. Rather than wait for user packets to provide the congestion notification, timed periodic ForeSight messages guarantee that the router receives notification before congestion becomes a problem. Traffic can be slowed down in the direction of the congested DLCI.
4-52
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Define Dedicated Queue for VoFR Packets Router(config-map-class)#
frame-relay voice bandwidth bps queue depth
• Creates dedicated queue for VoFR packets • VoFR queue has priority over regular queues configured on the same VC • Specified bandwidth has to include L2 and VoFR overhead • Voice calls over Frame Relay will not be placed unless the voice queue is configured • Voice over FR call will be rejected if there is not enough bandwidth available in the voice queue
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -57
The frame-relay voice-bandwidth map-class command is used to configure how much bandwidth is reserved for voice over Frame Relay (VoFR) traffic, if used in the network. The router then creates a dedicated priority queue, used only for VoFR traffic. If not enough reserved voice bandwidth remains on the PVC, any new calls that are attempted will be rejected. When the amount of bandwidth to allocate to voice is calculated, the overall bandwidth calculation must include the voice packetization overhead and not just the raw compressed speech codec bandwidth.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-53
Enable FRTS on an Interface Router(config-if)#
frame-relay traffic-shaping
• Enables Frame Relay traffic shaping on a physical interface • No special queuing can be configured on the interface • Weighted Fair Queuing is used as the physical interface queuing mechanism regardless of interface bandwidth
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-57
After the map class is configured, traffic shaping must be applied to the physical interface. As mentioned, WFQ is the only supported mechanism on the physical interface running FRTS.
4-54
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Apply FRTS to a VC Router(config-if)#
frame-relay class map-class-name
• Applies the specified Frame Relay map class to all VCs configured on the specified (sub)interface Router(config-if)#
frame-relay interface-dlci interface-dlci DLCI DLCI class map-class-name
• Applies the specified Frame Relay map class only to the specified DLCI • Traffic for DLCIs that have no map class defined (on DLCI or on (sub)interface) is not shaped © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -59
Map class settings are then applied to all or specific VCs on an interface or subinterface. All VCs without shaping information are not shaped and only use the physical interface queuing discipline (WFQ).
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-55
Frame Relay Traffic Shaping Example
Customer
interface Serial1/1 frame-relay frame -relay traffic-shaping ! interface Serial1/1.1 point-to-point point-to-point frame-relay frame -relay 101 WAN interface-dlci 101 class class slow_vcs slow_vcs ! interface Serial1/1.2 point-to-point Core point-to-point frame-relay frame -relay interface-dlci 102 102 class class fast_vcs fast_vcs ! map-class map-class frame-relay frame-relay fast_vcs fast_vcs frame-relay frame -relay custom-queue-list custom-queue-list 11 frame-relay frame -relay traffic-rate 32000 64000 ! map-class map-class frame-relay frame-relay slow_vcs slow_vcs frame-relay frame -relay priority-group 1 frame-relay frame -relay traffic-rate 9600 9600 16000 16000
• Customer uses different policies and queuing mechanisms for each DLCI © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-59
The figure shows an FRTS configuration example, where two VCs are individually shaped with two map class parameter sets. In this example, two generic map classes are defined, one for generic fast VCs and the other for slow VCs. The fast VC map class uses custom queuing to allocate bandwidth within the shaped rate. The slow VC map class uses priority queuing to always forward mission-critical traffic, and then shape it to the required rate.
4-56
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Frame Relay QoS Autosense • Frame Relay QoS parameters are usually defined manually on the router • The same parameters are also carried in ELMI (CLLM) messages • QoS Autosense allows the router to learn the DLCI QoS parameters from the switch – ELMI must be configured on the router and the switch – Only Cisco Frame Relay switches are supported
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -61
When used in conjunction with traffic shaping, the router can respond to changes in the network dynamically. This optional feature allows the router to learn QoS parameters from the Cisco switch and use them for traffic shaping, configuration, or management purposes. Enhanced Local Management Interface (ELMI) also simplifies traffic shaping configuration on the router. Previously, users needed to configure traffic shaping rate enforcement values, possibly for every VC. Enabling ELMI reduces the chance of specifying inconsistent or incorrect values when configuring the router. It is not necessary to configure traffic shaping on the interface to enable ELMI. One option is to enable it to learn what values being used by the switch. If the router is required to respond to the QoS information received from the switch by adjusting the output rate, traffic shaping must be configured on the interface using the frame-relay traffic-shaping command in interface configuration mode.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-57
Configuring QoS Autosense Router(config-if)#
frame-relay qos-autosense
• Enable the Enhanced Local Management Interface feature • Allows QoS parameters (CIR, Bc, Be) to be passed by the switch to the router automatically in ELMI messages
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -62
The frame-relay qos-autosense command enables:
4-58
n
ELMI on the router
n
The router to learn QoS parameters from the switch over the ELMI protocol
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Monitoring Frame Relay Traffic Shaping • Show frame-relay PVC – Displays VC QoS and shaping parameters
• Show traffic-shape statistics – Displays GTS and FRTS statistics
• Show traffic-shape queue – Displays GTS and FRTS shaping queue contents
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -63
The listed show commands enable monitoring of per-VC QoS and general GTS parameters.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-59
Display PVC Information Router#
show frame-relay pvc
• Displays VC QoS and shaping parameters Router#show Router#show frame-relay frame-relay pvc pvc 20 20 PVC PVC Statistics Statistics for for interface interface Serial4/0 Serial4/0 (Frame (Frame Relay Relay DCE) DCE) DLCI DLCI == 20, 20, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.1 Serial4/0.1 input output in input pkts pkts 16963 16963 output pkts pkts 33632 33632 in bytes bytes 4669839 4669839 out dropped pkts in out bytes bytes 12442428 12442428 pkts 00 in FECN FECN pkts pkts 00 in out out in BECN BECN pkts pkts 00 out FECN FECN pkts pkts 00 out BECN BECN pkts pkts 00 in DE pkts 0 out DE pkts 0 in DE pkts 0 out DE pkts 0 out out out bcast bcast pkts pkts 31361 31361 out bcast bcast bytes bytes 9095644 9095644 Shaping Shaping adapts adapts to to BECN BECN pvc pvc create create time time 1w3d, 1w3d, last last time time pvc pvc status status changed changed 1w3d 1w3d cir bc be limit interval cir 64000 64000 bc 64000 64000 be 00 limit 1000 1000 interval 125 125 mincir 32000 byte increment 1000 BECN response yes mincir 32000 byte increment 1000 BECN response yes pkts bytes pkts bytes pkts 1103 1103 bytes 1632516 1632516 pkts delayed delayed 1091 1091 bytes delayed delayed 16287 16287 shaping shaping active active traffic traffic shaping shaping drops 1136 Current Current fair fair queue queue configuration: configuration: Discard Dynamic Reserved Discard Dynamic Reserved threshold queue threshold queue count count queue queue count count 64 16 00 64 16 Output Output queue queue size size 46/max 46/max total 50/drops 1136 © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-63
The show frame -relay pvc command displays information about individual FR PVC status and provides information about:
4-60
n
Configured CIR
n
Shaping
n
Queuing
n
Congestion adaptation
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Display Shaping Statistics Router#
show traffic-shape statistics
• Displays GTS and FRTS statistics Router#show Router#show traffic-shape traffic-shape statistics statistics Access Packets Access Queue Queue Packets I/F List Depth I/F List Depth Se4/0.1 50 1283 Se4/0.1 50 1283 Se4/0.2 00 14 Se4/0.2 14
Bytes Bytes 1903236 1903236 4060
Packets Packets Delayed Delayed 1271 1271 0
© 2001, Cisco Systems, Inc.
Bytes Bytes Delayed Delayed 1899472 1899472 0
Shaping Shaping Active Active yes yes no
IP QoS Traffic Shaping and Policing -65
The show traffic-shape statistics command displays the statistics of traffic shaping for all configured interfaces. In the output, the amount of delayed traffic, the shaping queue sizes and the amount of transmitted traffic is displayed. Displayed in the output is: n
The interface where the frame-relay taffic-shaping command is used
n
The number of packets currently in the shaping queue (queue depth)
n
The total number of packets that have been processed by the frame-relay taffic-shaping command since the last clearing of interface counters (16091 packets in the example)
n
The total number of bytes that have been processed by the frame-relay tafficshaping command since the last clearing of interface counters (3733112 bytes in the example)
n
The total number of packets that have been delayed by the frame-relay tafficshaping command since the last clearing of interface counters (414 packets in the example)
n
The total number of bytes that have been delayed by the frame-relay tafficshaping command since the last clearing of interface counters (96048 bytes in the example)
n
If the queue depth is more than 0 than shaping is active
The expected result of traffic shaping is a high ratio between transmitted packets and delayed packets.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-61
If the number of delayed packets is very high (compared to the total number of packets) then there are probably non-responsive aggressive flows being shaped and the queue depth could show high buffer utilization. If the number of delayed packets is zero then it is very likely that the access list does not match any traffic.
4-62
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Display Shaping Queue Information Router#
show traffic-shape queue
• Displays GTS and FRTS shaping queue contents Router#show Router#show traffic-shape traffic-shape queue queue Traffic Traffic queued queued in in shaping shaping queue queue on on Serial4/0.1 Serial4/0.1 dlci dlci 20 20 Queueing Queueing strategy: strategy: weighted weighted fair fair Queueing Queueing Stats: Stats: 46/50/64/1377 46/50/64/1377 (size/max (size/max total/threshold/drops) Conversations Conversations 1/2/16 1/2/16 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) (depth/weight/discards/tail (depth/weight/discards/tail drops/interleaves) drops/interleaves) 46/32384/1377/0/0 46/32384/1377/0 /0 Conversation Conversation 5, 5, linktype: linktype: ip, ip, length: length: 1504 1504 source: source: 193.77.3.1, 193.77.3.1, destination: destination: 193.77.3.1, 193.77.3.1, id: id: 0x00F4, 0x00F4, ttl: ttl: 255, 255, prot: prot: 1
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -66
The show traffic-shape queue command displays the queuing configuration of individual interfaces.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-63
Display Shaping Queue Information PE_2#show PE_2#show traffic-shape traffic-shape queue queue Traffic Traffic queued queued in in shaping shaping queue queue on on Serial4/0.1 Serial4/0.1 dlci dlci 20 20 Queueing Queueing strategy: strategy: priority-group priority-group 11 Queueing Queueing Stats: Stats: high 16/20/19 (queue/size/max total/drops) Packet Packet 1, 1, linktype: linktype: ip, ip, length: length: 1504, 1504, flags: flags: 0x10000048 source: source: 193.77.3.1, 193.77.3.1, destination: destination: 193.77.3.1, 193.77.3.1, id: id: 0x0141, 0x0141, ttl: ttl: 255, 255, prot: prot: 11 data: data: 0x0800 0x0800 0x9105 0x9105 0x2659 0x2659 0x1F89 0x1F89 0x0000 0x0000 0x0000 0x0000 0x3819 0x3819 0x223C 0x223C 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD Packet Packet 2, 2, linktype: linktype: ip, ip, length: length: 1504, 1504, flags: flags: 0x10000048 source: source: 193.77.3.1, 193.77.3.1, destination: destination: 193.77.3.1, 193.77.3.1, id: id: 0x0141, 0x0141, ttl: ttl: 255, prot: prot: 11 data: data: 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -67
The show traffic-shape queue command also displays the contents of the shaping queue associated with an interface. The example shows the contents of the high queue in the Priority Queuing system used as the shaping queue.
4-64
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Summary n
FRTS enables granular, per-VC queuing and shaping definition
n
FRTS can be applied only on output interfaces
n
FRTS enables per-VC queuing, which is performed before shaping
n
FRTS performs traffic shaping or smoothing within a VC
n
FRTS supports the same congestion adaptation mechanisms as GTS
Lesson Review Answer the following questions: 1. What are the main differences between GTS and FRTS? 2. Where can FRTS be used? 3. What classification options does FRTS have?
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-65
Committed Access Rate Overview The lesson describes the Committed Access Rate (CAR) mechanism.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
4-66
n
Describe the CAR mechanism
n
Describe the benefits and drawbacks of CAR
n
Describe the differences between CAR, GTS and FRTS
n
Configure CAR on Cisco routers
n
Monitor and troubleshoot CAR
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Committed Access Rate Meter Inbound or Outbound
Classifier
Marker
Dropper
• Primarily intended for rate limiting • Can be used on inbound and outbound traffic • Does not queue (delay) packets • Can also mark packets • Can be implemented for differentiated marking © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -72
Committed Access Rate (CAR) provides the capability to allow the service provider to rate-limit traffic in and out of router interfaces, thereby enabling various forms of ingress and egress rate-limiting in a network. CAR is a policing mechanism, not a queuing mechanism. Therefore it does not buffer or delay packets, which do or do not conform to the policy, but simply rate-limits them according to a simple “forward or drop” policy, according to the configuration. CAR also uses a token-bucket metering mechanism, similar to GTS, but without a delay queue. The CAR rate-limiting feature manages a network's access bandwidth policy by ensuring that traffic falling within specified rate parameters is sent, while dropping packets that exceed the acceptable amount of traffic or sending them with a different priority. CAR is often configured on interfaces at the edge of a network to limit traffic into or out of the network. CAR can also be used for packet marking. The operator can specify a policy that determines which packets should be assigned to which traffic class, and use CAR to implement the marking. The IP header already provides a mechanism to do this, namely the three precedence bits in the ‘type of service’ field in the IP header. CAR allows the setting of policies, based on information in the IP or TCP header such as IP address, application port, physical port or sub-interface, IP protocol, etc., to decide how the precedence bits should be marked or “colored.” Once marked, appropriate treatment can be given in the backbone to ensure that premium packets receive premium service in terms of bandwidth allocation, delay control, etc.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-67
Note
CAR can also be used to police (or “recolor”) precedence bits set externally to the network either by the customer or by a downstream service provider. Thus the network can decide to either accept or override external decisions.
CAR is implemented using the following abstract mechanisms:
4-68
n
The classifier, which differentiates traffic into multiple classes, which may be treated in a discriminate manner
n
The meter, which uses a token-bucket scheme to measure the rate of classified traffic
n
The marker, which can be used to mark or re-mark classified traffic (for example, with precedence or DSCP values)
n
The dropper, which may drop packets (in the rate-limiting scenario) according to the configured policy
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR on Input and Output Meter
Inbound
Classifier
Marker
Dropper
Forwarding Outbound
Meter
Classifier
Marker
Dropper
Queuing
• CAR on input is processed just before forwarding (most other QoS mechanisms are processed before CAR) • CAR on output is processed immediately after forwarding (most other QoS mechanisms are processed after CAR) © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -73
CAR can be configured on router input or output interfaces. When configured on the input side, CAR is usually processed last in a series of QoS mechanisms. Therefore, CAR rate-limiting and marking occurs just before the forwarding decision. On the output side, CAR is processed just after the forwarding decision. Therefore all output QoS mechanisms (queuing, WRED, etc.) are generally processed after CAR. VIP-based distributed CAR (dCAR) is a version of CAR that runs on the Versatile Interface Processor (VIP). It is supported on the Cisco 7500 routers with a VIP2-40 or later versatile interface processor. Distributed Cisco Express Forwarding (dCEF) switching must be enabled on any interface that uses dCAR, even when only output-based CAR is configured.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-69
CAR Implementation Dispatches packets at configured rate
CAR
Dispatches packets at line rate
Dispatches packets at line rate
Software Queue
Hardware Queue
(FIFO, PQ, CQ, WFQ, ...)
(FIFO)
Bypass the software queue if it is empty and there is room in the hardware queue
• The software queue may have no function if the sum of all CAR rates is less than link bandwidth © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -74
Whether configured on input or output, CAR has the option of managing throughput on a certain interface’s output. With the Cisco IOS queuing design, there are two output queues: n
A software queue, which may be configured for different queuing types (for example: FIFO, Priority Queuing, Custom Queuing, Weighted Fair Queuing)
n
A hardware interface queue, which is always FIFO and immediately used, if the software queue is empty
One possible implementation caveat arises when CAR is configured so that the aggregate policed bandwidth of output flows does not exceed the link bandwidth. In that case, the software queue is always empty and there is no queuing impact on traffic.
4-70
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Interface-wide CAR Diagram drop
Class Class 1? 1?
transmit
CAR CAR continue drop
Class Class 2? 2?
transmit
CAR CAR
Output Queue or Forward
continue
drop
Class n?
transmit
CAR CAR
• CAR has three different actions: – Transmit – Continue – Drop © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -75
The basic rate-limiting function of CAR does the following: n
Allows control of the maximum rate of traffic transmitted or received on an interface.
n
Provides the ability to define Layer-3 aggregate or granular rate limits and to specify traffic -handling policies when the traffic either conforms to or exceeds the specified rate limits.
n
Uses granular bandwidth rate limits to match a particular type of traffic based on precedence, MAC address, or other parameters.
When CAR is in effect, traffic is first classified and then undergoes CAR processing. CAR then meters the traffic and, based on the result of CAR metering, traffic either conforms or exceeds the configured policy. There are three possible basic actions on each packet, depending on it conforming or exceeding the policy: n
Transmit—the packet is sent.
n
Drop—the packet is discarded.
n
Continue—the packet is evaluated using the next rate policy in a chain of rate limits. If there is not another rate policy, the packet is sent.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-71
CAR Diagram Meter Meter
Conforms? Conforms?
Yes / No
Transmit? Transmit?
Yes
Forward or Enqueue
No Mark? Mark? Set Set IP IP prec? prec? Set Set DSCP? DSCP? Set Set MPLS MPLS exp? exp? Set Set QoS QoS grp? grp?
Continue? Continue? Yes
Yes
Yes
Yes
Set SetIP IPPrecedence Precedence Set Set DSCP DSCP
Yes
Go to Next CAR command
No Drop? Drop?
Yes
Set Set MPLS MPLS Experimental Set Set QoS QoS Group Group
• Marking depends on whether the packet conforms to or exceeds the policy © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -76
As mentioned previously, CAR can also be used to mark or remark traffic as well as performing rate limiting. Depending on traffic conformance, the following marking/remarking actions can be performed within CAR processing:
4-72
n
Set precedence (or DSCP value) and transmit—the IP Precedence (ToS) or DSCP bits in the packet header are rewritten. The packet is then sent. This action can be used to either color (set precedence) or recolor (modify existing packet precedence) the packet.
n
Set MPLS experimental bits and transmit – the MPLS experimental bits can be set. These are usually used to signal QoS parameters in a MPLS cloud.
n
Set QoS group and transmit—the QoS group can be set. It is only used locally within the router. The QoS group can be used in later QoS mechanisms and performed in the same router, such as CB-WFQ.
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Configuring CAR Router(config-if)# rate-limit {input | output} [access-group [rate-limit] #acl | qos-group number | dscp dscp dscp] mean-rate B cc Bee conform-action { drop || transmit transmit || continue continue || set-prec-transmit value | set-prec-continue set-prec-continue value value | set-qos-transmit value | set-qos-continue value set-dscp-transmit value | set-dscp-continue set-dscp-continue value value | set-mpls-transmit value | set-mpls-continue value value } exceed-action {{ drop | transmit | continue | set-prec-transmit value | set-prec-continue set-prec-continue value value | set-qos-transmit value | set-qos-continue value set-dscp-transmit value | set-dscp-continue set-dscp-continue value value | set-mpls-transmit value | set-mpls-continue value value }
• Specifies all four conditioner elements for a particular traffic class • Repeat this command for different classes of traffic • If a match is not found, the default action is to transmit © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -77
To configure CAR and Distributed CAR (dCAR) policies, use the rate-limit interface configuration command. The figure illustrates all the command options which are discussed in detail on the following pages. A single CAR rate policy includes information about the rate limit, conform actions and exceed actions. Each interface can have multiple CAR rate policies corresponding to different types of traffic. For example, low priority traffic may be limited to a lower rate than high priority traffic. When there are multiple rate policies, the router examines each policy in the order entered until the packet matches. If no match is found, the default action is to transmit. Rate policies can be independent: each rate policy deals with a different type of traffic. Alternatively, rate policies can be cascading: a packet may be compared to multiple different rate policies in succession. Cascading of rate policies allows a series of rate limits to be applied to packets to specify more granular policies. For example, the total traffic on an access link can be rate limited to a specified subrate bandwidth, and then the World Wide Web traffic on the same link can be limited to a given proportion of the subrate limit. CAR can be configured to match packets against an ordered sequence of policies until an applicable rate limit is encountered—that is, rate limiting several MAC addresses with different bandwidth allocations at an exchange point. Up to a 100 rate polic ies can be configured on a subinterface. The CAR action may be one of the following: n
Continue: evaluate the next rate-limit command
n
Drop: drop the packet
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-73
4-74
n
Set-prec-continue new-prec: set the IP Precedence and evaluate the next rate-limit command
n
Set-prec-transmit new-prec: set the IP Precedence and send the packet
n
Set-dscp-continue new-prec: set the DSCP value and evaluate the next ratelimit command
n
Set-dscp-transmit new-prec: set the DSCP value and send the packet
n
Set-mpls-continue new-prec: set the MPLS experimental bits and evaluate the next rate-limit command
n
Set-mpls-transmit new-prec: set the MPLS experimental bits and send the packet
n
Transmit: send the packet
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR Classification Router(config-if)#
rate-limit {input | output} [access-group [rate-limit] [access-group [rate-limit] #acl | qos-group number number | dscp dscp] ...
• IP packets are classified: – based on their direction (input or output)
• Optional classification based on: – numbered IP access list (standard or extended) – IP precedence rate-limit access list – MAC address rate-limit access list – QoS-group set by a previous conditioner in the same node – DSCP © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-77
CAR classifies traffic using many IOS-based classification mechanisms. The most basic classification is to first specify whether inbound or outbound traffic on the interface is being policed. Then, additional more granular specification can further classify traffic that needs to be policed separately.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-75
Null CAR Classifier Router(config-if)#
rate-limit {input | output} ...
• Selects packets in ingress or egress direction that have not been classified with any previous rate-limit commands on this interface • Usually used as the last rate-limit command on an interface
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -78
The null CAR classifier is in effect when no additional classifiers are present, apart from the input or output application of the rate-limiting rule. This can be used either as a default rate-limiting class (used as the last rate-limit command on the interface to classify packets, not classified by any previous rules), or, if only global policy is applied to an interface, classifying all traffic into one group (that is, policing to a specified aggregate input rate).
4-76
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR Classifier Based on IP Access List Router(config-if)#
rate-limit {input | output} access-group number ...
• Classifies packets received over an interface with the IP access list • Classification based on IP precedence can be done with IP access list Router(config)# access-list access-list acl-index acl-index {deny {deny | permit} permit} source [source-wildcard] access-list access-list acl-index acl-index {deny {deny | permit} permit} protocol source sourcewildcard destination destination-wildcard [precedence precedence] [tos tos] [dscp dscp] [log]
• Configures an IP access list to be used as packet classifier © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -80
The basic classification of traffic is based on extended IP access lists, which describe traffic based on Layer-3 and Layer-4 parameters, such as source and destination IP addresses, protocols and port numbers. Normal IOS access control lists are used and then applied to the interface rate-limit command. As IOS access lists can filter on IP precedence, access-list based classification can also classify traffic solely on IP precedence. Such an approach is not recommended if only precedence-based classification is desired, as there is a more efficient mechanism present.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-77
CAR Classifier Based on IP Precedence Router(config-if)#
rate-limit {input | output} access-group rate-limit number ...
• The IP precedence classifier uses rate-limit access lists from 1 to 99 to match on IP precedence values
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -81
To classify incoming or outgoing traffic based solely on IP precedence, rate-limit access lists can be used. Rate-limit access lists match only on the precedence bits in the IP header, and can perform precedence matching with a wildcard specification.
4-78
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
IP Precedence-based Rate-limit Access List Router(config)#
access-list rate-limit rate-limit acl-index precedence precedence
• ACL index is between 1 and 99 • Matches packets with specified IP precedence • Only one line is allowed in the access list Router(config)#
access-list rate-limit rate-limit acl-index mask precedence-mask
• ACL index is between 1 and 99 • Matches packets that match any precedence value specified in the mask • Precedence mask has one bit for each precedence value (bit 0 = precedence 0) © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -82
To configure classification rules on the IP precedence value, use the access-list rate-limit global configuration command. The CAR process then treats packets with different IP precedence differently. Use the mask keyword to assign multiple IP precedence values to the same rate-limit list. The ACL indices for precedencebased classification range from 1 to 99.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-79
CAR Classifier Based on Upstream MAC Address Router(config-if)#
rate-limit {input | output} access-group rate-limit number ...
• The upstream MAC address classifier uses rate-limit access lists from 100 to 199 to match on the MAC address of upstream router or host
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -83
Rate-limit access lists are also used to classify traffic based on the upstream MAC address. That is, for output-based CAR, traffic is classified on the destination MAC address, and for input-based CAR, traffic is classified using the source MAC address. MAC-based classification is particularly useful at ISP peering points, where a multi-access LAN network connects ISP border routers. MAC-based classification can classify traffic based on their upstream neighbor (another ISP border router) and on their QoS peering policy with other providers.
4-80
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
MAC Address Rate-limit Access List Router(config)#
access-list rate-limit acl-index mac-address
• ACL index is between 100 and 199 • Matches packets received from upstream neighbor with specified MAC address • Only MAC address is allowed in the access list (each upstream neighbor requires a different ratelimit statement)
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -84
To configure classification rules on the upstream MAC value, use the access-list rate-limit global configuration command. The CAR process then treats packets with different upstream (source or destination) MAC addresses differently. The ACL indices for precedence-based classification range from 100 to 199.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-81
QoS-group CAR classifier Router(config-if)#
rate-limit {input | output} qos-group number ...
• Selects IP packets already marked in this node with specified QoS group • QoS group marking could be done through: – Policy-based routing – CEF marking based on QPPB – Inbound rate-limit on another interface – Inbound Class-based Marking on another interface
• Available only on high-end platforms
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -85
The operator may also classify traffic based on their QoS group value. The QoS group is a tag, which may be assigned to each packet during the forwarding process, and is local to the router. The QoS group may be set: n
By some marking mechanism in the same router, such as policy routing, inbound rate-limiting on another interface, or inbound class-based marking on another interface.
n
By QPPB (QoS Policy Propagation through BGP), which distributes centrally administered QoS group values to routers over BGP sessions. The routers automatically mark traffic based on the QPPB-learned policy during the CEF forwarding process.
The QoS-group-based classification and marking is generally available only on high-end router platforms.
4-82
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
DSCP-based CAR Classifier Router(config-if)#
rate-limit {input | output} dscp dscp ...
• Selects IP packets marked with the specified DiffServ Code Point • DSCP marking could be done through: – Rate-limit on another interface or router – Class-based Marking on another interface or router
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -86
In a DiffServ-based model, the whole DSCP value can be used as the packet classifier. The marking of the DSCP value is accomplished through class-based marking or rate limiting on another interface or router.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-83
CAR Meter Router(config-if)#
rate-limit {input | output} [access-group [access-group [rate-limit] [rate-limit] number | qos-group number | dscp dscp] mean-rate Bc Bee ...
• The rate-limit meter measure the contract compliance of traffic class selected with classifier • Modified token-bucket algorithm is used – mean-rate specifies average traffic rate – B c specifies the normal burst size – B e specifies the excess burst size
• Token-bucket size is defined by Be alone © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -87
The CAR metering mechanism uses a modified token bucket scheme, which decides whether a packet conforms or exceeds the contracted rate. CAR is configured with three parameters: n
Mean rate specifies the average traffic rate which traffic should be policed to (analogous to committed rate with GTS). This is the long-term sustained throughput through the CAR policing mechanism.
n
Bc specifies the normal burst size, which is the amount of tokens added periodically to the token bucket.
n
Be specifies the excess burst size, which equals the size of the bucket in the CAR implementation. This is the maximum burst size that can be sent by the token bucket at one time, at the access line rate.
If CAR is used as a pure policer, packets exceeding the contracted rate are dropped.
4-84
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR Actions • CAR actions can be split into two sub-actions: – Marking action – Processing action
• Marking actions support the setting of: – – – –
IP precedence DSCP MPLS experimental bits QoS group
• Processing actions: – Transmit – packet is transmitted – Continue – packet is also processed by the next “rate-limit” command – Drop – packet is dropped © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -88
CAR actions can be divided into marking and processing actions. The marking actions support the setting of QoS signaling values inside the packet header (precedence, DSCP, MPLS experimental) or locally to the router (QoS group). The processing actions define the basic action of a single CAR rule. Those actions may be to transmit (forward) the packet immediately, drop the packet, or continue with the evaluation of the next CAR rule. Each CAR rate limit statement is checked sequentially for a match. When a match is found, the CAR meter (the token bucket), if there is one, is evaluated. If the action is a “continue” action, the policer will go to the next rate-limit on the list to find a subsequent match. If a match is found the traffic is subjected to the next applicable rate-limit. If an end of rate-limit list is encountered without finding a match or “continue” action, the default behavior is to transmit.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-85
CAR Actions • Processing actions “transmit”, “continue” and “drop” can be used as stand-alone actions • Processing actions “transmit” and “continue” can be combined with marking actions (set-mark_actionproc_action): – – – – – – – –
set-prec-transmit set-qos-transmit set-mpls-transmit set-dscp-transmit set-prec-continue set-qos-continue set-mpls-continue set-dscp-continue
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -89
The three processing actions can be used stand-alone to enforce a pure ratelimiting functionality. Alternatively, the “transmit” and “continue” actions can be, and often are, combined with marking actions, whic h enable further differentiation of the traffic.
4-86
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR Actions • Conforming and exceeding packets can be configured with different actions • There are three typicall usages of CAR: – Pure rate limiting • Transmit conforming packets • Drop exceecing packets
– Differentiated marking • Transmit conforming packets with marker value x (e.g IP precedence 3) • Transmit exceeding packets with marker value y (e.g IP precedence 2)
– Pure marking • Transmit confirming and exceeding packets with the same marker value
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -90
Based on the “conform” or “exceed” results of the CAR meter, three CAR configuration philosophies are usually used: n
Use only the “transmit” and “drop” actions—effectively enabling only local rate limiting on an interface.
n
Use all processing actions, and additionally mark traffic based on its conformance of exceeding the configured rate limit. For example, conforming traffic may be colored with one marker value (precedence, DSCP, QoS, etc.), and exceeding traffic with another value. This differentiation may be used locally or elsewhere in the network to differentiate between in-contract (conforming) traffic and out-of-contract (exceeding) traffic.
n
Transmit all traffic and use only the marking actions to color traffic with a marker value.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-87
Displaying CAR Parameters and Statistics Router#
show interfaces intf rate-limit
• Displays CAR parameters and statistics Router#show Router#show interfaces interfaces serial serial 0/0 0/0 rate-limit rate-limit Serial0 Serial0 Input Input matches: matches: qos-group qos-group 4 params: params: 128000 128000 bps, bps, 64000 64000 limit, limit, 128000 128000 extended extended limit limit conformed conformed 00 packets, packets, 00 bytes; bytes; action: action: transmit transmit exceeded exceeded 0 0 packets, packets, 00 bytes; bytes; action: action: set-prec-transmit set-prec-transmit 0 0 last last packet: packet: 421250660ms 421250660ms ago, current current burst: burst: 00 bytes bytes last last cleared cleared 00:00:59 00:00:59 ago, ago, conformed conformed 00 bps, bps, exceeded exceeded 00 bps bps Output Output matches: matches: access-group access -group 181 181 params: limit params: 8000 8000 bps, bps, 8000 8000 limit, limit, 16000 16000 extended extended limit conformed -prec-transmit 33 conformed 19 19 packets, packets, 21576 21576 bytes; bytes; action: action: set set-prec-transmit exceeded exceeded 5 packets, packets, 7520 bytes; action: drop last last packet: packet: 145344ms 145344ms ago, ago, current current burst: burst: 11552 11552 bytes bytes last last cleared cleared 00:03:01 00:03:01 ago, ago, conformed conformed 00 bps, bps, exceeded exceeded 00 bps bps © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -91
To display information about the Committed Access Rate (CAR) for an interface, use the show interfaces rate-limit EXEC command. Information retrieved by the show interface rate limit command includes:
4-88
n
Packets that match this rate limit
n
Parameters for this rate limit (as configured by the rate-limit command)
n
Average rate
n
Normal burst size
n
Excess burst size
n
Number of packets that have conformed to the rate limit
n
Conform action
n
Number of packets that have exceeded the rate limit
n
Exceed action
n
Time since the last packet
n
Instantaneous burst size at the current time
n
Time since the burst counter was reset
n
Rate of conforming traffic
n
Rate of exceeding traffic
n
Rate limits applicable to packets sent out by the interface
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Display Rate-limit Access Lists Router(config)#
show access-lists rate-limit
• List rate-limit access lists Router#show Router#show access-lists access-lists rate-limit rate-limit Rate-limit Rate-limit access access list list 10 10 1 Rate-limit Rate-limit access access list list 11 11 mask 81 Rate-limit Rate-limit access access list list 120 120 4000.1234.ABCD
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -92
To display information about rate-limit access lists, use the show access-lists rate-limit EXEC command. Information displayed includes: n
Whether the access list is precedence-based or MAC address-based
n
What the IP precedence and IP precedence mask for packets in this rate-limit access list are or what the MAC address for packets in this rate-limit access list are
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-89
CAR – Limiting Example #1 • A service provider connects all its customers via 2 Mbps physical leased lines (or ADSL links) and uses CAR to limit the actual amount of traffic the user can send or receive • In addition several differentiated services could be provided based on customers needs
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -92
The first CAR case study shows a service provider, which uses a unified infrastructure to connect all customers to an IP backbone. 2 Mbps leased lines or ADSL links are used to connect customers to a POP. CAR is used to limit the actual traffic rate to a lower value, as specified by the customer contract. CAR can be used to offer differentiated, easy to upgrade services in this scenario, as throughput is not limited by physical infrastructure, but rather by the traffic policing by the ISP.
4-90
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR – Limiting Example #1 interface serial 0/0 rate-limit input 256000 4000 96000 conform-action transmit exceed-action drop rate-limit output 256000 4000 96000 conform-action transmit exceed-action drop
Customer
2M bps
2 Mbps
Internet NAP
Customer bps 2M
ISP
Customer
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-93
In the configuration example, CAR is applied on the input and output of a customer interface on the provider edge router. Traffic is policed to 256 Kbps on input and output, with some bursting allowed. All exceeding traffic is dropped at the provider edge. The result of the configuration is that traffic to and from the customer is limited to the average rate of approximately 256kbps (256000 in the configuration) with sustained bursts of approximately 32kbps (4kBps or 4000 in the configuration). Initial bursts at line speed can last up to 3 seconds because the token bucket can hold up to 96000 tokens (bytes) which equals 768000 bits (3 x 256000 bits).
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-91
CAR – Limiting and Marking Example #2 • Web traffic is limited to 512 Kbps and transmitted with higher precedence – Excess Web traffic is classified as regular traffic
• All other traffic is limited to 256 Kbps and transmitted with precedence 0 – Excess traffic is dropped – Burst size is 16000 bytes – Excess burst size is 24000 bytes
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -94
The second case study provides a differentiated service for a customer, where web traffic needs to be given more bandwidth compared to other traffic types. Web traffic is limited to 512 Kbps, and a higher precedence is set. Web traffic exceeding the configured rate limit is reclassified as regular traffic. Regular traffic is limited to 256 Kbps, and colored with a precedence value of 0. The same burst values are configured for web and all other traffic.
4-92
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR – Limiting and Marking Example #2 2 Mbps Internet
Customer
NAP
ISP
interface serial 0/0 rate-limit input access-group 101 512000 64000 128000 conform-action set-prec-transmit 1 exceed -action continue rate-limit input 256000 16000 24000 conform-action set-prec-transmit 0 exceed-action drop rate-limit output access -group 101 512000 64000 128000 conform-action set-prec-transmit 1 exceed -action continue rate-limit output 256000 16000 24000 conform-action set-prec-transmit 0 exceed-action drop ! access-list 101 permit tcp any any eq www access-list 101 permit tcp any eq www any © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -95
The configuration implements the policy outlined in the previous case study. Traffic is classified with extended access lists (to differentiate web traffic from other traffic), and CAR uses the access list to apply the correct policing to the traffic. Precedence values of 0 and 1 are set to signal preferential treatment of the webtraffic to other QoS mechanisms, such as queuing and WRED. The access list 101 identifies HTTP traffic using the default well-known port number 80 (“www” in the configuration) either as the source or destination port number in TCP segments. The conforming part of the class (up to 512 kbps) is marked with IP precedence 1. The exceeding part of the class is further evaluated by the next rate-limit command where it is limited together with the rest of the traffic (non-HTTP) to 256 kbps. The total throughput, therefore, will never exceed 768 kbps (512 kbps of conforming HTTP traffic + 256 kbps of exceeding HTTP traffic and all other traffic). WRED can be used in combination with CAR to provide differentiated congestion avoidance anywhere in the network.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-93
CAR – Limiting Example #3 • The customer can send or receive up to 128 Kbps of premium traffic – Premium traffic is marked with precedence 1 Excess premium traffic is dropped
• Non-premium (best-effort) traffic is not rate limited
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -96
In the third case study, an ISP’s customer can exchange up to 128 Kbps of premium traffic with the world. Premium traffic is marked with precedence 1 by the customer, and the ISP polices the traffic to 128 Kbps using CAR. Other traffic is not rate-limited.
4-94
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR – Limiting Example #3 interface serial 0/0 rate-limit input access -group rate-limit 13 128000 16000 48000 conform-action transmit exceed -action drop rate-limit output access-group rate -limit 13 128000 16000 48000 conform-action transmit exceed -action drop ! access-list rate-limit 13 1
Customer
2M bps
2 Mbps
Internet NAP
Customer bps 2M
ISP
Customer © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -97
The configuration shows traffic classification based on the packet precedence, classified by the rate-limit access list. CAR only polices premium traffic, and all other traffic has policing applied to it. The premium traffic, previously marked with IP precedence 1, is classified using the rate-limit access list 13. The premium traffic is strictly policed to 128kbps where all excess traffic is dropped. All other traffic is not policed.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-95
CAR – Precedence Spoofing Example #4
Customer
interface serial 0/0 rate-limit input access-group rate-limit 1 64000 8000 8000 conform-action drop exceed-action drop ! access-list rate-limit 1 mask FE Internet
2M bps
2 Mbps NAP
Customer bps 2M
ISP
Customer
• If a customer is trying to spoof a service provider with high-precedence traffic, the traffic is dropped – Drop all non-precedence-0 traffic received from a customer © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -98
This case study shows a possible solution for preventing precedence spoofing for best-effort customers. The customer may only send traffic with the precedence value of 0. The CAR policing rule matches all non-zero-precedence traffic and drops it unconditionally. The CAR metering parameters can be arbitrarily set to any value. The rate-limit access list in this example is using the mask option to match multiple IP precedence values. Each bit in the mask corresponds to one IP precedence value. The mask FE (11111110 binary) in the example matches all packets with IP precedence values between 1 and 7. The rate-limit command drops all packets that do not have IP precedence 0.
4-96
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR – Limiting Example #5 • Application: Web server collocation – The customer can locate his server at service provider premises (switched LAN) – CAR is used to limit the amount of traffic the web server can generate – Unknown traffic is rate-limited to 64 kbps to allow remote configuration of new servers
• Alternate application: central site in an enterprise network
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -99
The fifth case study application uses web hosting as the example of QoS application. The SP hosts a web-farm and wants to police traffic going to and from specific servers. CAR is used, with MAC-based classification, to differentiate traffic to or from different servers. A default policing statement allows some traffic through to allow management protocols to run to yet unprovisioned servers. This application can also be used to manage traffic flows to centralized servers in enterprise networks.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-97
CAR – Limiting Example #5
Server
Core network LAN switch Server
Server
© 2001, Cisco Systems, Inc.
Distribution Router
interface FastEthernet 0/0 rate-limit input access-group rate -limit 100 10000000 100000 100000 conform-action transmit exceed-action drop rate-limit output access-group rate-limit 100 10000000 100000 100000 conform-action transmit exceed-action drop rate-limit input 64000 8000 24000 conform-action transmit exceed-action drop rate-limit output 64000 8000 24000 conform-action transmit exceed-action drop ! access-list rate-limit 100 00ae.0123.abcd ! Server MAC address
IP QoS Traffic Shaping and Policing-100
The figure shows the configuration used to police traffic going to a specific server. MAC-based rate-limit ACLs are used, which filter based on the upstream server MAC address. The special rate-limit access list is used to identify traffic from a web server which may have multiple IP addresses. The traffic is limited to Ethernet speed even if the underlying interface is using another type of media (for example: FastEthernet). In the event that a customer changes the interface card (MAC address changes) on the server, he can still get limited access to the server (64kbps) for administrative purposes. The MAC-based rate-limit access list has to be modified to reflect the new MAC address being used by the server.
4-98
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR – Marking Example #6
WAN Core Customer interface ethernet 0/0 rate-limit input 10000000 8000 8000 conform-action set-prec-transmit 2 exceed-action drop ! interface ethernet 0/1 rate-limit input 10000000 8000 8000 conform-action set-prec-transmit 0 exceed-action drop !
• CAR can be used purely for marking purposes © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-101
In this example, CAR is used purely for marking purposes. All traffic from one customer (attached to the ethernet0/0 interface) is rate-limited to the line rate and CAR marks all incoming packets with a configured precedence. Another customer is connected to the same router, also rate-limited to the line rate, and marked with a lower precedence. The bit rate in the rate-limit command should be higher or equal to the physical bandwidth of the interface to implement marking without any rate limiting. Another option is to use the same action for both conforming and exceeding traffic.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-99
CAR – Marking Example #7 Customer WAN Core interface ethernet 0/0 rate-limit input access-group 101 10000000 8000 8000 conform-action set -prec-transmit 2 exceed-action drop rate-limit input access-group 102 10000000 8000 8000 conform-action set -prec-transmit 1 exceed-action drop rate-limit input 10000000 8000 8000 conform-action set -prec-transmit 0 exceed-action drop ! access-list 101 permit tcp any any eq telnet access-list 102 permit tcp any any eq www © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-102
This configuration extends the possibilities of the previous example, using application-specific marking. CAR is used to mark telnet traffic with a higher precedence and web-traffic with a lower precedence. All other traffic is marked with precedence zero. Note
There is no true policed rate limiting in this example, as traffic is rate -limited to the line rate.
The first rate-limit command identifies inbound telnet sessions (access list 101) and marks them with IP precedence 2 without limiting it. The second rate-limit command identifies inbound HTTP sessions (access list 102) and marks them with IP precedence 1 without limiting it. The third rate-limit command marks all other packets (no access list is used) with IP precedence 0 without limiting it.
4-100
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Summary n
CAR can be applied on input and output interfaces
n
CAR performs no buffering or shaping
n
CAR can mark packets
n
In Frame Relay, CAR has no support for BECN or FECN
n
Cascaded policies can be applied
n
CAR provides managed discard between the normal burst and extended burst parameters
n
CAR can run in distributed mode (on 7500 VIP)
n
CAR can apply access lists based on ToS bits/MAC address and IP extended access lists
n
CAR is not RSVP aware
Lesson Review Answer the following questions: 1. What classification options does CAR support? 2. What are the main differences between CAR and traffic shaping? 3. Where can CAR be implemented?
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-101
Summary
4-102
n
GTS/FRTS perform traffic shaping or smoothing
n
GTS/FRTS cannot mark or drop packets
n
GTS/FRTS can intelligently adapt to Layer-2 congestion
n
GTS/FRTS do not support cascaded policies
n
GTS/FRTS do not provide managed discard
n
CAR performs no buffering or shaping
n
CAR can mark packets
n
In Frame Relay, CAR has no support for BECN or FECN
n
Cascaded policies can be applied in CAR
n
Both GTS and CAR can run in distributed mode
n
CAR is not RSVP aware, while GTS is
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Traffic Shaping and Policing Question: How do shaping and policing mechanisms keep track of the traffic rate? Answer: Both mechanisms use a token bucket as a rate measurement method. Question: Which shaping mechanisms are available with the Cisco IOS software? Answer: Cisco IOS supports Generic Traffic Shaping, Frame Relay Traffic Shaping, and Class-based Shaping. Question: Which policing mechanisms are available with the Cisco IOS software? Answer: Cisco IOS supports Committed Access Rate (CAR) and Class-based Policing. Question: What are the main differences between shaping and policing? Answer: To stay within the configured rate, shaping delays excessive traffic while policing drops excessive traffic.
Generic Traffic Shaping Question: What software queuing mechanisms are supported in combination with GTS? Answer: Any software queuing method (FIFO, priority queuing, custom queuing, WFQ, CB-WFQ) is supported on an interface in combination with GTS. Question: Which queuing structure does GTS use? Answer: GTS uses WFQ as the shaping queue. Question: What features does GTS include when used on Frame Relay interfaces? Answer: GTS can adapt its rate to Frame Relay congestion signaling, and propagate FECN signals to BECN signals, sent towards the sender on the Frame Relay network.
Frame Relay Traffic Shaping Question: What are the main differences between GTS and FRTS? Answer: FRTS shapes traffic of individual Frame Relay VCs. Also, the shaping queue of FRTS is configurable and can be any of the software queuing mechanisms. Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-103
Question: Where can FRTS be used? Answer: FRTS can only be used on Frame Relay interfaces. Question: What classification options does FRTS have? Answer: None, FRTS shapes all traffic on a Frame Relay VC.
Committed Access Rate Question: What classification options does CAR support? Answer: CAR supports Access Control Lists (ACLs), rate-limit ACLs, DSCP value, and QoS-group as its classifiers. Question: What are the main differences between CAR and traffic shaping? Answer: CAR never delays excess traffic, but can drop or transmit it. CAR also supports marking of conforming and exceeding traffic, and supports nested classification and policing. CAR can also be used both on input and output of interfaces, while traffic shaping can only be used on output. Question: Where can CAR be implemented? Answer: CAR can be implemented on input or output of interfaces.
4-104
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
5
Congestion Avoidance
Overview This module describes the problems of congested networks. It introduces Random Early Detection (RED), WRED, and Flow-based WRED as mechanisms to prevent congestion on router interfaces.
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe Random Early Detection (RED)
n
Describe and configure Weighted Random Early Detection (WRED)
n
Describe and configure Flow-based WRED
Random Early Detection Overview The section describes the need for congestion avoidance in nearly-congested networks and explains the benefits of using RED on congested links.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
5-2
Congestion Avoidance
n
Explain the need for congestion avoidance mechanisms.
n
Explain how RED works and how it can prevent congestion.
n
Describe the benefits and drawbacks of RED.
Copyright 2001, Cisco Systems, Inc.
Router Interface Congestion • Router interfaces congest when the output queue is full –Additional incoming packets are dropped –Dropped packets may cause significant application performance degradation –By default, routers perform tail-drop –Tail-drop has significant drawbacks –WFQ, if configured, has a more intelligent dropping scheme
© 2001, Cisco Systems, Inc.
Congestion Avoidance-5
When an interface on a router cannot transmit a packet immediately, the packet is queued, either in an interface Tx ring, or the interface output hold queue, depending on the switching path used. Packets are then taken out of the queue and eventually transmitted on the interface. If the arrival rate of packets to the output interface exceeds the router’s capability to buffer and forward traffic, the queues increase to their maximum length and the interface becomes congested. Tail drop is the router’s default queuing response to congestion. When the output queue is full and tail drop is in effect, all packets trying to enter (at the tail of) the queue are dropped until the congestion is eliminated and the queue is no longer full. Congestion avoidance techniques monitor network traffic loads in an effort to anticipate and avoid congestion at common network bottleneck points. Congestion avoidance is achieved through packet dropping using more complex techniques than simple tail-drop. As mentioned, tail drop is the default queuing response to congestion. Tail drop treats all traffic equally and does not differentiate between classes of service. Weighted fair queuing, if configured on an interface, has a more elaborate scheme for dropping traffic, as it is able to punish the most aggressive flows via its Congestion Discard Threshold (CDT)-based dropping algorithm. Unfortunately, WFQ does not scale to backbone speeds. WFQ dropping is discussed in detail in its associated module. This module introduces Random Early Detection (RED) and its scalable dropping method, which is suitable for low and high-speed networks.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-3
Tail-drop Flaws • Simple tail-drop has significant flaws –TCP synchronization –TCP starvation –High delay and jitter –No differentiated drop –Poor feedback to TCP
© 2001, Cisco Systems, Inc.
Congestion Avoidance-6
The simple tail-dropping scheme unfortunately does not work very well in environments with a large number of TCP flows or in environments in which selective dropping is deserved. Understanding of the interaction between TCP stack intelligence and dropping in the network is required to implement a more efficient and fair dropping scheme, especially in SP environments. Tail drop has the following shortcomings:
5-4
Congestion Avoidance
n
When congestion occurs, dropping affects most of the TCP sessions, which simultaneously back-off and then restart again. This causes inefficient link utilization at the congestion point (TCP global synchronization)
n
TCP starvation, where all buffers are temporarily seized by aggressive flows, and normal TCP flows experience buffer starvation.
n
Buffering at the point of congestion can introduce delay and jitter, as packets are stuck waiting in queues.
n
There is no differentiated drop mechanism, and therefore premium traffic is dropped in the same way as best-effort traffic.
n
Even in the event of a single TCP stream across an interface, the presence of other non-TCP traffic can congest the interface and TCP traffic will also be dropped. In this scenario, the feedback to the TCP protocol is very poor and therefore it cannot adapt properly to a congested network.
Copyright 2001, Cisco Systems, Inc.
TCP Synchronization
Average link utilization
Flow A Flow B Flow C
• Multiple TCP sessions start at different times • TCP window sizes are increased • Tail-drops cause many packets of many sessions to be dropped at the same time • TCP sessions restart at the same time (synchronized) © 2001, Cisco Systems, Inc.
Congestion Avoidance-7
A router can handle multiple concurrent TCP sessions. There is a high probability that when traffic exceeds the queue limit at all, it vastly exceeds the limit due to the bursty nature of packet networks. However, there is also a high probability that excessive traffic depth caused by packet bursts is temporary and that traffic does not stay excessively deep except at points where traffic flows merge, or at edge routers. If the receiving router drops all traffic that exceeds the queue limit, as is done by default (with tail drop), many TCP sessions then simultaneously go into slow start. Consequently, traffic temporarily slows down to the extreme and then all flows slow-start again. This activity creates a condition called global synchronization. Global synchronization occurs as waves of congestion crest only to be followed by troughs during which the transmission link is not fully utilized. Global synchronization of Transmission Control Protocol (TCP) hosts, for example, can occur because packets are dropped all at once. Global synchronization manifests when multiple TCP hosts reduce their transmission rates in response to packet dropping, then increase their transmission rates once again when the congestion is reduced. The most important point is that the waves of transmission known as global synchronization result in significant link under-utilization.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-5
TCP Starvation, Delay and Jitter Packets of aggressive flows
Packets of starving flows Prec. 3
TCP does not react well if multiple packets are dropped
Prec. 3
Prec. 3
Prec. 0
Prec. 3
Prec. 0
Prec. 0
Prec. 0
Queue
Delay Tail-drop does not look at IP precedence
Packets experience long delay if interface is constantly congested
• Constant high buffer usage (long queue) causes delay • More aggressive flows can cause other flows to starve • Variable buffer usage causes jitter • No differentiated dropping © 2001, Cisco Systems, Inc.
Congestion Avoidance-8
Another TCP-related phenomenon, which reduces optimal throughput of network applications is TCP starvation. When multiple flows are established over a router, some of these flows may be much more aggressive as compared to others. For instance, when a file transfer application’s TCP transmit window increases, it can send a number of large packets to its destination. The packets immediately fill the queue on the router, and other, less aggressive flows can be starved, because they are tail-dropped at the output interface. During periods of congestion, packets are queued up to the full queue length, which also causes increased delay for packets already in the queue. In addition, queuing, being a probabilistic mechanism, introduces unequal delays for packets of the same flow, producing jitter.
5-6
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Conclusion • Tail-drop should be avoided • Tail-drop can be avoided if congestion is prevented • Congestion can be prevented if TCP sessions (that still make up more than 80 percent of average Internet traffic) can be slowed down • TCP sessions can be slowed down if some packets are occasionally dropped • Therefore: packets should be dropped when interface is nearing congestion © 2001, Cisco Systems, Inc.
Congestion Avoidance-9
Based on the knowledge of TCP behavior during periods of congestion, it can be concluded that tail-drop is not the optimal mechanism for congestion avoidance and therefore should not be used. Instead, more intelligent congestion avoidance mechanisms should be used, which would slow down traffic before actual congestion occurs. IP traffic can be “slowed down” only for traffic using an adaptive transmission protocol, such as TCP. Dropping packets of a TCP session indicates to the sender that it should lower its transmission rate to adapt to changing network conditions. UDP, on the other hand, has no built-in adaptive mechanisms – it sends packets out at a rate specified by the application. About 80% of Internet traffic today is carried over the TCP protocol. If TCP packets of aggressive flows are intelligently dropped, those sessions will slow down and congestion will be avoided. Therefore, to prevent congestion, the output queues should not be allowed to get full, and TCP can be controlled via packet dropping. The new dropping mechanisms should drop packets before congestion occurs, and drop them in such a way that primarily influences aggressive traffic flows.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-7
Random Early Detection • Random Early Detection (RED) is a mechanism that randomly drops packets even before a queue is full • RED drops packets with an increasing probability • RED result: – TCP sessions slow down to the approximate rate of outputlink bandwidth – Average queue size is small (much less than the maximum queue size)
• IP precedence can be used to drop lower precedence packets more aggressively than higherprecedence packets
© 2001, Cisco Systems, Inc.
Congestion Avoidance -10
Random Early Detection is a dropping mechanism that randomly drops packets before a queue is full. The dropping strategy is based primarily on the average queue length - that is, when the average queue gets longer (fuller), RED will be more likely to drop an incoming packet than when the queue is shorter. Because RED drops packets randomly, it has no per-flow intelligence. The rationale behind this is that an aggressive flow will represent most of the arriving traffic, therefore it is more probable that RED will drop a packet of an aggressive session. RED therefore punishes more aggressive sessions with higher statistical probability, and is therefore able to somewhat selectively slow down the most significant cause of congestion. Directing one TCP session at a time to slow down allows for full utilization of the bandwidth, rather than utilization that manifests itself as crests and troughs of traffic. As a result, the TCP global synchronization is much less likely to occur, and TCP can utilize the bandwidth more efficiently. The average queue size also decreases significantly, as the possibility of the queue filling up is very small. This is due to very aggressive dropping in the event of traffic bursts, when the queue is already quite full. RED distributes losses over time and maintains normally low queue depth while absorbing spikes. RED can also utilize precedence/DSCP bits in packets to establish different drop profiles for different classes of traffic.
5-8
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
RED Profile Drop Probability
No drop
Random drop
Full drop
100%
Maximum Drop Probability
10% 20
Minimum Threshold
© 2001, Cisco Systems, Inc.
40
Average Queue Size
Maximum Threshold
Congestion Avoidance -11
The probability of a packet being dropped is based on three configurable parameters: n
Minimum threshold - When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold.
n
Maximum threshold - When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.
n
Mark probability denominator - This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
These parameters define the RED profile, which implements the packet dropping strategy, based on the average queue length.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-9
RED Modes • RED has three modes: – No drop – when the average queue size is between 0 and the minimum threshold – Random drop - when the average queue size is between the minimum and the maximum threshold – Full drop (tail-drop) – when the average queue size is at maximum threshold or above
• Random drop should prevent congestion (prevent tail-drops)
© 2001, Cisco Systems, Inc.
Congestion Avoidance -12
As seen in the previous figure, RED has three dropping modes, based on the average queue size:
5-10
Congestion Avoidance
n
When the average queue size is between 0 and the configured minimum threshold, no drops occur and all packets are queued.
n
When the average queue size is between the configured minimum threshold, and the configured maximum threshold, random drop occurs, which is linearly proportional to the average queue length. The maximum probability of drop (when the queue is almost completely full) is 15% in Cisco IOS software.
n
When the average queue size is at or higher than the maximum threshold, RED performs full (tail) drop in the queue. This event is unlikely, as RED should slow down TCP traffic ahead of congestion. If a lot of non-TCP traffic is present, RED cannot effectively drop traffic to reduce congestion, and taildrops are likely to occur.
Copyright 2001, Cisco Systems, Inc.
Before RED
Average link utilization
Flow A Flow B Flow C
• TCP synchronization prevents average link utilization close to the link bandwidth • Tail-drops cause TCP sessions to go into slow-start © 2001, Cisco Systems, Inc.
Congestion Avoidance -13
The figure shows TCP throughput behavior compared to link bandwidth in a scenario of congestion, and simple tail-dropping on a router. The global synchronization phenomenon causes all sessions to slow down when congestion occurs, as all sessions are penalized when tail-drop is used because it drops packets with no discrimination between individual flows. When all sessions slow down, the interface becomes uncongested, and all TCP sessions restart their transmission at roughly the same time. The interface quickly becomes congested again, causing tail-dropping, and all TCP sessions back off again. This behavior cycles constantly, resulting in a link that is always underutilized on the average.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-11
After RED
Average link utilization
Flow A Flow B Flow C
• Average link utilization is much closer to link bandwidth • Random drops cause TCP sessions to reduce window sizes © 2001, Cisco Systems, Inc.
Congestion Avoidance -14
The figure shows TCP throughput behavior compared to link bandwidth in a scenario of congestion, and RED configured on a router. RED randomly drops packets, influencing a small number of sessions at a time, before the interface reaches congestion. Overall throughput of sessions is increased, as well as average link utilization. Global synchronization is very unlikely to occur, as there is selective, but random dropping of adaptive traffic.
5-12
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Summary n
Tail-drop does not perform adequate congestion avoidance on router interfaces.
n
RED randomly drops packets before an interface is congested, punishing aggressive flows.
n
RED prevents interface congestion and prevents TCP global synchronization, but works well only in predominantly TCP-based environments.
Lesson Review 1. What are the main drawbacks of using tail-drop as a means of congestion control? 2. What does RED do to prevent TCP synchronization? 3. What are the three modes of RED?
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-13
Weighted Random Early Detection Overview The section describes the WRED mechanism available in Cisco IOS.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
5-14
Congestion Avoidance
n
Describe the Weighted Random Early Detection (WRED) mechanism
n
Configure WRED on Cisco routers
n
Monitor and troubleshoot WRED on Cisco routers
Copyright 2001, Cisco Systems, Inc.
Weighted Random Early Detection • WRED uses a different RED profile for each weight • Each profile is identified by: – minimum threshold – maximum threshold – maximum drop probability • Weight can be – IP precedence (8 profiles) – DSCP (64 profiles) • WRED drops less important packets more aggressively than more important packets
© 2001, Cisco Systems, Inc.
Congestion Avoidance -19
Weighted Random Early Detection (WRED) combines RED with IP Precedence or DSCPs and does packet drops based on IP Precedence or DSCP markings. As with RED, WRED monitors the average queue depth in the router and determines when to begin packet drops based on the queue depth. When the average queue depth crosses the user-specified “minimum threshold,” WRED begins to drop packets (both TCP and UDP) with a certain probability. If the average queue depth ever crosses the user-specified ”maximum threshold,” then WRED reverts to ”tail drop,” where all incoming packets might be dropped. The idea behind using WRED is to maintain the queue depth at a level somewhere between the minimum and maximum thresholds, and to implement different drop policies for different classes of traffic. WRED can selectively discard lower priority traffic when the interface becomes congested and provide differentiated performance characteristics for different classes of service. WRED can also be configured so that non-weighted RED behavior is achieved. For interfaces configured to use the Resource Reservation Protocol (RSVP), WRED chooses packets from other flows to drop rather than the RSVP flows. Also, IP Precedence or DSCPs govern which packets are dropped − traffic that is at a lower priority has a higher drop rate and therefore is more likely to be throttled back. WRED reduces the chances of tail drop by selectively dropping packets when the output interface begins to show signs of congestion. By dropping some packets early rather than waiting until the queue is full, WRED avoids dropping large numbers of packets at once and minimizes the chances of global synchronization. Thus, WRED maximizes the utilization of transmission lines. Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-15
In addition, WRED statistically drops more packets from large users than small ones. Therefore, traffic sources that generate the most traffic are more likely to be slowed down than traffic sources that generate little traffic. WRED avoids the global synchronization problems that occur when tail drop is used as the congestion avoidance mechanism. Global synchronization manifests when multiple TCP hosts simultaneously reduce their transmission rates in response to packet dropping, then increase their transmission rates again once the congestion is reduced. WRED is only useful when the bulk of the traffic is TCP traffic. With TCP, dropped packets indicate congestion, so the packet source reduces its transmission rate. With other protocols, packet sources might not respond or might re-send dropped packets at the same rate, and so dropping packets does not decrease congestion. WRED treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP traffic, in general, is more likely to be dropped than IP traffic. WRED should be used wherever there is a potential bottleneck (congested link), which could very well be an access/edge link. However, WRED is normally used in the core routers of a network rather than at the network’s edge. Edge routers assign IP Precedences to packets as they enter the network. WRED uses these precedences to determine how to treat different types of traffic. Note that WRED is not recommended for any voice queue, although it may be enabled on an interface carrying voice traffic. RED will not throttle back voice traffic, because it is UDP-based, and the network itself should not be designed to lose voice packets since lost voice packets result in reduced voice quality. WRED controls congestion by impacting other prioritized traffic, and avoiding congestion helps to ensure voice quality.
5-16
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
WRED Profiles Drop Probability 100%
10% 10
20
40
Average Queue Size
• WRED profiles can be manually set • WRED has 8 default value sets for IP precedence based WRED • WRED has 64 default value sets for DSCP based WRED
© 2001, Cisco Systems, Inc.
Congestion Avoidance -20
The figure shows two WRED profiles, used for traffic of different QoS classes. The RED class has a much lower minimum and maximum threshold. Traffic of that class will be dropped much earlier and more aggressively. When heavy congestion occurs, the RED class will ultimately be tail dropped. The BLUE class has a higher minimum and maximum thresholds, therefore dropping occurs later and is less likely, compared to the RED class. This maintains differentiated levels of service in the event of congestion. To avoid the need of setting all WRED parameters in a router, 8 default values are already defined for precedence-based WRED, and 64 DiffServ-aligned values are defined for DSCP-based WRED. Therefore, the default settings should suffice in the vast majority of deployments.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-17
IP Precedence and Class Selector Profiles Drop Probability
100%
10% IP precedence
0
20
© 2001, Cisco Systems, Inc.
1 2 3 4 5 6 7 RSVP 22 24 26 28 31 33 35 37 40
Average Queue Size
Congestion Avoidance -21
A Per-Hop Behavior (PHB) is the externally observable forwarding behavior applied at a DiffServ-compliant node to a DiffServ Behavior Aggregate (BA). With the ability of the system to mark packets according to DSCP setting, collections of packets − each with the same DSCP setting and sent in a particular direction − can be grouped into a DiffServ BA. Packets from multiple sources or applications can belong to the same DiffServ BA. In the Assured Forwarding PHB (as defined in RFC 2474,) WRED uses the Drop Preference (second digit of the AF number) to determine drop probability. This enables differentiated dropping of AF traffic classes, which have different drop preference.
5-18
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
DSCP-based WRED (Expedited Forwarding) Drop Probability
100%
10%
EF
20
© 2001, Cisco Systems, Inc.
36 40
Average Queue Size
Congestion Avoidance -22
The Expedited Forwarding PHB is identified based on the following parameters: n
Ensures a minimum departure rate to provide the lowest possible delay to delay-sensitive applications
n
Guarantees bandwidth to prevent starvation of the application if there are multiple applications using Expedited Forwarding PHB
n
Polices bandwidth to prevent starvation of other applications or classes that are not using this PHB
n
Packets requiring Expedited Forwarding should be marked with DSCP binary value “101110” (46 or 0x2E)
For the Expedited Forwarding DiffServ traffic class, WRED configures itself by default so that the minimum threshold is very high, increasing the probability of no drops being applied to that traffic class. EF-traffic is therefore expected to be dropped very late, compared to other traffic classes, in the event of congestion.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-19
DSCP-based WRED (Assured Forwarding) Drop Probability
100%
AF Low Drop AF Medium Drop AF High Drop
10%
20 24
28 32
© 2001, Cisco Systems, Inc.
40
Average Queue Size
Congestion Avoidance -23
The Assured Forwarding PHB is identified based on the following parameters: n
Guarantees a certain amount of bandwidth to an AF class
n
Allows access to extra bandwidth, if available
n
Packets requiring AF PHB should be marked with DSCP value “aaadd0” where “aaa” is the number of the class and “dd” is the drop probability or drop preference of the traffic class.
There are four standard-defined AF classes. Each class should be treated independently and have bandwidth allocated based on the QoS policy. For the Assured Forwarding DiffServ traffic class, WRED configures itself by default for three different profiles, depending on the Drop Preference DSCP marking bits. AF-traffic should therefore be classified into the three possible classes based on the application sensitivity to dropping. WRED implements a congestion avoidance PHB in agreement with the initial classification.
5-20
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
WRED Building Blocks Calculate Average Queue Size
IP packet
WRED
IP precedence or DSCP
Select WRED Profile
© 2001, Cisco Systems, Inc.
Min. threshold Max. threshold Max prob. denom.
Queue Full?
No
Current Queue Size FIFO Queue
Yes
Random Drop
Tail Drop
Congestion Avoidance -24
The figure shows how WRED is implemented, and the parameters that influence WRED dropping decisions. The WRED algorithm is constantly updated with the calculated average queue size, which is based on the recent history of queue sizes. The configured WRED profiles define the dropping thresholds (and therefore the WRED probability slopes). When a packet arrives at the output queue, the IP precedence of DSCP-value is used to select the correct WRED profile for the packet. The packet is then passed to WRED to perform a drop/enqueue decision. Based on the profile and the average queue size, WRED calculates the probability for dropping the current packet and either drops it or passes it to the output queue. If the queue is already full, the packet is tail-dropped. Otherwise, it is eventually transmitted out onto the interface.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-21
Configuring WRED and dWRED Router(config-if)# random-detect random-detect
• Enables IP precedence based WRED • Default service profile is used • Non-distributed WRED cannot be combined with fancy queuing - FIFO queuing has to be used • WRED can run distributed on VIP-based interfaces (dWRED) • dWRED can be combined with dWFQ © 2001, Cisco Systems, Inc.
Congestion Avoidance -25
The random-detect command is used to enable WRED on an interface. By default, WRED is precedence-based, using eight default WRED profiles. Used on VIP-based interfaces, this command enables distributed WRED (dWRED), where the VIP CPU performs WRED dropping. This can significantly increase router performance, when used in the context of distributed CEF switching, which is a prerequisite for dWRED functionality. Also, dWRED can be combined with dWFQ, enabling truly distributed queuing and congestion avoidance techniques, running independently from the central CPU. With centralized platforms, WRED, if configured, cannot be combined with other queuing methods (priority, custom, and weighted-fair queuing). Those methods use either tail-dropping or their own dropping methods. Therefore, WRED can only be configured with FIFO queuing on an interface. This is not a major issue, because WRED is usually applied in the network core, where there should be no queuing configured. WRED is suited for the network core as it has a relatively low performance impact on routers.
5-22
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Changing WRED profile Router(config-if)# random-detect precedence precedence precedence precedence min-threshold max-threshold mark-prob-denominator mark-prob-denominator
• Changes RED profile for specified IP precedence value • Packet drop probability at maximum threshold is 1 / mark-prob-denominator • Non-weighted RED is achieved by using the same RED profile for all precedence values © 2001, Cisco Systems, Inc.
Congestion Avoidance -26
In this example, WRED is enabled with default values, and then the values are changed for each IP Precedence level. The configured values, which are described above under Random Early Detection, are repeated here for convenience: n
Minimum threshold - When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold.
n
Maximum threshold - When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.
n
Mark probability denominator - This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
It is interesting to note, that the maximum probability of drop at the maximum threshold can be expressed as 1/mark-prob-denominator. The maximum drop probability is 10%, if default settings are used. If required, RED can be configured as a special case of WRED, by assigning the same profile to all eight precedence values.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-23
Changing WRED Sensitivity to Bursts Router(config-if)# random-detect exponential-weighting-constant n
Qavg ( t + 1) = Qavg (t ) ⋅ (1 − 2 − n ) + Qt ⋅ 2 − n New average queue size
Previous average queue size
Current queue size
• WRED takes the average queue size to determine the current WRED mode (no drop, random drop, full drop) • High values of N allow short bursts • Low values of N make WRED more burst-sensitive • Default value (9) should be used in most scenarios • Average output queue size with N=9 is average t+1 = average t * 0.998 + queue_sizet * 0.002 © 2001, Cisco Systems, Inc.
Congestion Avoidance -27
As mentioned previously, WRED does not calculate the drop probability using the current queue length, but rather uses the average queue length. The average queue length is constantly recalculated, using two terms: the previously calculated average queue size and the current queue size. An exponential weighting constant N influences the calculation by weighing the two terms, therefore influencing how the average queue size follows the current queue size, in the following way: n
A low value of N makes the current queue size more significant in the new average size calculation, therefore allowing larger bursts
n
A high value of N makes the previous average queue size more significant in the new average seize calculation, so that bursts influence the new value to a smaller degree.
The default value is 9 and should suffice for most scenarios, except perhaps those involving extremely high-speed interfaces (like OC12), where it can be increased slightly (to about 12) to allow more bursts.
5-24
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Configuring DSCP-based WRED Router(config-if)# random-detect random-detect {prec-based {prec-based || dscp-based} dscp-based}
• Selects WRED mode • Precedence-based WRED is the default mode • DSCP-based uses 64 profiles
© 2001, Cisco Systems, Inc.
Congestion Avoidance -28
The random-detect dscp-based command is used to enable DSCP-based WRED on an interface, using the 64 default DSCP-based WRED profiles.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-25
Changing WRED Profile Router(config-if)# random-detect dscp dscp dscp dscp min-threshold max-threshold mark-probdenominator denominator
• Changes RED profile for specified DSCP value • Packet drop probability at maximum threshold is 1 / mark-prob-denominator
© 2001, Cisco Systems, Inc.
Congestion Avoidance -29
The DSCP-weighted WRED profiles can be changed, again using the known three WRED parameters. The mask-prob-denominator defines the packet drop probability at the WRED maximum threshold. The maximum drop probability is 10%, if default settings are used. Normally, the DSCP-weighed profiles should be left at their default settings, as those settings are appropriate for most situations, if traffic is classified according to the DiffServ service specification.
5-26
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
WRED Case Study • WRED is applied to a core link in a network with the following IP precedence definitions IP prec.
© 2001, Cisco Systems, Inc.
Meaning
0
HighHigh-drop best effort traffic
1
LowLow -drop best best-effort traffic
2
Premium Premium traffic traffic outside outside of the contract
3
Premium Premium traffic traffic in in the the contract contract
4
Unused
5
VoiceVoice-overover -IP
6
Routing protocol traffic
7
Routing protocol protocol traffic traffic Congestion Avoidance -30
This WRED case study presents a network carrying traffic with eight different service levels, each assigned a precedence value, with which packets are marked. The figure shows the precedence to traffic -type mapping, where higher precedence values are assigned to more important traffic. Voice traffic, for example, is ranked just below essential routing protocol traffic, whereas other IP traffic is divided into premium and best-effort levels, also depending on dropsensitivity. Traffic is classified at the edge of the network, and WRED provides differentiated handling of traffic in the core, if core interfaces are nearing congestion. This information is used to build a custom WRED profile, based on the above policy. When congestion is about to occur, WRED will drop packets, preferring lower-precedence traffic, which is either drop-resistant or part of a best-effort service. Premium traffic should experience few drops, and voice and routing protocol traffic are unlikely to get dropped, because they are assigned a very high minimum dropping threshold. While it is not recommended to use WRED with voice traffic, this example aggregates many types of traffic, including voice, on a single access line. WRED is configured so that voice is unlikely to be dropped, and other aggressive flows are dropped first. Ideally, there would also be a separate voice queue configured, and voice traffic priority scheduled against other traffic.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-27
WRED Case Study Guidelines • Best-effort traffic should be dropped before premium traffic • Out-of-contract or high-drop best -effort traffic should be dropped very aggressively • Voice traffic should be dropped only under extreme congestion • Routing protocol traffic should be less dropresistant than VoIP (depends on the routing protocol and control over amount of VoIP traffic) • Configure WRED with default values on an interface first and tune the per -precedence parameters based on default values
© 2001, Cisco Systems, Inc.
Congestion Avoidance -31
The WRED dropping strategy for different traffic classes can be outlined as n
Best-effort traffic should be dropped before premium traffic.
n
Out-of-contract or high-drop best-effort traffic should be dropped very aggressively.
n
Voice traffic should be dropped only under extreme congestion.
n
Routing protocol traffic should be less drop-resistant than VoIP (depends on the routing protocol and control over amount of VoIP traffic).
To implement this dropping policy, WRED is configured with default parameters and then tuned to comply with the above policy.
5-28
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Packet Discard Probability
Sample WRED Profile
VoIP
Precedence 3
Routing
Precedence 1
0.1
Precedence 2 Precedence 0
RSVP
37
35
30
25
20
15
10
© 2001, Cisco Systems, Inc.
Average Queue Size
Congestion Avoidance -32
The figure presents the values chosen to tune WRED dropping according to the case study policy. Different precedence traffic will be assigned different minimum and maximum threshold values to reflect the relative dropping strategies outlined in the requirements. Note that the maximum drop probability is 10% (default) and the same for all precedence levels. This setting should not be changed in most implementations.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-29
WRED Configuration
interface interface Serial Serial 0/1/0 0/1/0 ip address address 200.200.14.250 200.200.14.250 255.255.255.252 255.255.255.252 random-detect random-detect precedence 0 10 10 25 25 10 10 random-detect precedence 1 20 20 35 35 10 10 random-detect precedence 2 15 15 25 25 10 10 random-detect precedence 3 25 25 35 35 10 10 random-detect precedence 2 11 precedence 44 11 random-detect precedence 5 35 35 40 40 10 10 random-detect precedence 6 30 30 40 40 10 10 random-detect precedence 7 30 30 40 40 10 10
© 2001, Cisco Systems, Inc.
Congestion Avoidance -33
This configuration excerpt shows the implementation of the dropping policy, illustrated by the case study. The threshold values reflect the values chosen in the previous figure. Note that precedence 4 is not used to mark traffic in the case study network, so the drop probability of precedence 4 traffic is 100% (1 divided by 1 times 100%).
5-30
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Monitoring WRED • Show interface – displays the queuing/dropping mechanism in use displays WRED parameters (VIP only)
• Show queueing – displays the RED profile for each interface
• Show queue – displays the interface output queue
• Show interface random-detect – displays RED statistics (VIP only)
© 2001, Cisco Systems, Inc.
Congestion Avoidance -34
The listed commands provide means to monitor WRED configuration and operation.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-31
Interface Parameters Router# show interface intf
• Displays interface parameters Router#show Router#show interface interface serial serial 1/0 1/0 Serial1/0 Serial1/0 is up, up, line line protocol protocol is up Hardware Hardware is is CD2430 CD2430 in in sync sync mode mode Internet Internet address address is is 192.168.1.2/30 192.168.1.2/30 MTU MTU 1500 1500 bytes, bytes, BW BW 128 128 Kbit, Kbit, DLY DLY 200 200 usec, usec, rely rely 255/255 255/255 ... ... Encapsulation Encapsulation HDLC, HDLC, loopback loopback not not set, set, keepalive keepalive set set (10 sec) Last Last input 00:00:07, output 00:00:07, output hang never Last Last clearing clearing of "show "show interface" interface" counters never Input Input queue: queue: 2/75/0 2/75/0 (size/max/drops); (size/max/drops); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: random random early early detection detection (WRED) (WRED) 55 minute minute input input rate rate 00 bits/sec, bits/sec, 00 packets/sec packets/sec 55 minute output rate 0 bits/sec, bits/sec, 0 packets/sec packets/sec 337102 337102 packets packets input, input, 27357987 27357987 bytes, bytes, 00 no no buffer buffer Received Received 265169 265169 broadcasts, broadcasts, 00 runts, runts, 00 giants, giants, 0 throttles throttles 00 input input errors, errors, 00 CRC, CRC, 00 frame, frame, 00 overrun, overrun, 00 ignored, ignored, 00 abo abort rt ... ... rest rest deleted deleted ... ...
© 2001, Cisco Systems, Inc.
Congestion Avoidance -35
The show interface command will display whether or not WRED is the preferred congestion avoidance mechanism on the interface.
5-32
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
WRED Parameters and Statistics Router# show queueing random-detect
• Displays per-interface parameters WRED statistics Router#show Router#show queueing queueing random-detect random-detect Current Current random-detect random -detect configuration: configuration: Serial1/0 Serial1/0 Queueing Queueing strategy: strategy: random random early early detection detection (WRED) (WRED) Exp-weight-constant: Exp-weight-constant: 99 (1/512) (1/512) Mean Mean queue queue depth: depth: 38 38 Class Class 00 11 22 33 44 55 66 77 rsvp rsvp © 2001, Cisco Systems, Inc.
Random drop drop 174 0 0 0 0 0 0 0 6 0 0 00
Tail drop drop 34 0 0 0 0 0 0 0 3 0 0 00
Minimum threshold threshold 20 22 22 24 24 26 28 31 33 35 35 37 37
Maximum threshold threshold 40 40 40 40 40 40 40 40 40 40 40 40 40
Mark probability probability 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 Congestion Avoidance -36
The show queuing command shows the configuration and statistics for configured WRED profiles.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-33
dWRED Parameters and Statistics Router#show Router#show interfaces interfaces random-detect random-detect FastEthernet1/0/0 FastEthernet1/0/0 queue queue size size 0 0 packets packets output output 29692, 29692, drops drops 00 WRED: WRED: queue queue average average 00 weight weight 1/512 Precedence Precedence 0: 0: 109 109 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 11 packets packets output, output, drops: drops: 00 random, random, 00 threshold threshold Precedence Precedence 1: 1: 122 122 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 (no (no traffic) traffic) Precedence Precedence 2: 2: 135 135 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 14845 14845 packets packets output, output, drops: drops: 0 random, random, 0 threshold threshold Precedence Precedence 3: 3: 148 148 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 (no (no traffic) traffic) Precedence Precedence 4: 4: 161 161 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 (no (no traffic) traffic) Precedence Precedence 5: 5: 174 174 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 (no (no traffic) traffic) Precedence Precedence 6: 6: 187 187 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 14846 14846 packets packets output, output, drops: drops: 0 random, random, 0 threshold threshold Precedence Precedence 7: 7: 200 200 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 (no (no traffic) traffic) © 2001, Cisco Systems, Inc.
ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight
Congestion Avoidance -37
The show interfaces random-detect command shows the dWRED profile configuration for the specified interface. Use this command to display dWRED statistics on interfaces performing distributed services.
5-34
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Queue Details Router# show queue queue intf
• Displays queue contents Router#show Router#show queue queue serial serial 1/0 1/0 Output Output queue queue for for Serial1/0 Serial1/0 is is 65/0 65/0 Packet Packet 1, 1, source: source: data: data:
linktype: linktype: ip, ip, length: length: 1504, 1504, flags: flags: 0x48 0x48 192.168.1.2, 192.168.1.2, destination: destination: 192.168.1.2, 192.168.1.2, id: id: 0x001A, 0x001A, ttl: ttl: 255, 255, prot: prot: 11 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD
Packet Packet 2, 2, linktype: linktype: ip, ip, length: length: 1504, 1504, flags: flags: 0x48 0x48 source: source: 192.168.1.2, 192.168.1.2, destination: destination: 192.168.1.2, 192.168.1.2, id: id: 0x001A, 0x001A, ttl: ttl: 255, 255, prot: prot: 11 data: data: 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD Packet Packet 3, 3, linktype: linktype: ip, ip, length: length: 1504, 1504, flags: flags: 0x48 0x48 source: source: 192.168.1.2, 192.168.1.2, destination: destination: 192.168.1.2, 192.168.1.2, id: id: 0x001A, 0x001A, ttl: ttl: 255, 255, prot: prot: 11 data: data: 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD ... ... rest rest deleted deleted ... ... © 2001, Cisco Systems, Inc.
Congestion Avoidance -38
The show queue command will display the output queue contents.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-35
WRED caveats and restrictions • Since the same policy is applied to all flows, a single non-adaptive flow can monopolize the buffer resources at an interface – RED is suitable when TCP represents at least 80% of the traffic – Non-TCP traffic should be rate-limited
• Non-distributed RED implementation is mutually exclusive with PQ, CQ and WFQ
© 2001, Cisco Systems, Inc.
Congestion Avoidance -39
WRED is very effective in achieving congestion avoidance, but only when at least 80% of traffic is based on the TCP protocol, which can quickly react to selective random drops in some of the sessions. If non-adaptive flows, using for example the UDP protocols, arrive at the interface, those flows do not react to WRED dropping, but can instead monopolize the interface (and its buffers). Such traffic should be rate-limited to enforce a steady traffic mix. Also, WRED cannot be used together with fancy queuing with centralized switching. dWRED and dWFQ can coexist, however, on most distributed applications, sometimes even implemented in interface (line card) hardware.
5-36
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Summary n
WRED uses precedence or DSCP-dependent dropping slopes to differentiate RED dropping for different classes of traffic.
n
WRED is configured on router interfaces and can run distributed on VIPbased interfaces.
Lesson Review 1. What are the key differences between RED and WRED? 2. What can be used as weight in WRED? 3. Which dropping modes does WRED have?
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-37
Flow-based Weighted Random Early Detection Overview The section describes the Flow-based WRED mechanism available in Cisco IOS.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
5-38
Congestion Avoidance
n
Describe the Flow-based WRED mechanism.
n
Describe the benefits of Flow-based RED over normal WRED.
n
Configure Flow-based WRED on Cisco routers.
n
Monitor and troubleshoot Flow-based WRED on Cisco routers.
Copyright 2001, Cisco Systems, Inc.
Flow-based WRED • WRED differentiates between packets of different priority • WRED does not differentiate between packets of different flows • Aggressive flows can monopolize the queue and cause other flows to starve • Flow-based WRED is used to keep track of flows • Flow-based WRED drops packets of aggressive flows ahead of other packets © 2001, Cisco Systems, Inc.
Congestion Avoidance -44
WRED relies on a measurement called the average queue length to determine when to drop packets. When the packet count of the average queue length is in the upper range, WRED begins dropping packets. At this point, WRED applies a nonzero drop probability to all packets that arrive on an interface, indiscriminate of the kinds of flows to which the packets belong. Therefore, normal WRED applies the same loss rate to all kinds of flows, adaptive and non-adaptive. Flow-based Weighted Random Early Detection (FRED) is a feature of WRED that forces WRED to afford greater fairness to all flows on an interface with regard to how packets are dropped. Flow-based WRED relies on these two main approaches to remedy the problem of unfair packet drop: n
It classifies incoming traffic into flows based on parameters such as destination and source addresses and ports.
n
It maintains state information about active flows, which are flows that have packets in the output queues.
Flow-based WRED uses this classification and state information to ensure that each flow does not consume more than its permitted share of the output buffer resources. Flow-based WRED determines which flows monopolize resources, and more heavily penalizes these flows. Here is how flow-based WRED ensures fairness among flows: it maintains a count of the number of active flows that exist through an output interface. Given the number of active flows and the output queue size, flow-based WRED determines the number of buffers available per flow. To allow for some burstiness, flow-based WRED scales the number of buffers available per flow by a configured factor and Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-39
allows each active flow to have a certain number of packets in the output queue. This scaling factor is common to all flows. The outcome of the scaled number of buffers becomes the per-flow limit. When a flow exceeds the per-flow limit, the probability that a packet from that flow will be dropped increases.
5-40
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Types of Flows • There are three types of flows –Robust flows - adapt to packet loss by slowing down (WRED is effective); consistent buffer usage –Fragile flows - cannot adapt to drops (WRED should not be used); low buffer usage –Non-adaptive flows - do not adapt to packet loss (WRED is not effective); high and constant buffer usage
© 2001, Cisco Systems, Inc.
Congestion Avoidance -45
Before you consider the advantages that flow-based WRED offers, it helps to think about how WRED (without flow-based WRED configured) affects different kinds of packet flows. Even before flow-based WRED classifies packet flows, flows can be thought of as belonging to one of these categories: n
Nonadaptive flows, which are flows that do not respond to congestion.
n
Robust flows, which on average have a uniform data rate and slow down in response to congestion.
n
Fragile flows, which, though congestion-aware, have fewer packets buffered at a gateway than do robust flows.
Because of its packet-drop behavior − that is, that all flows, even those with relatively fewer packets in the output queue, are susceptible to packet drop during periods of congestion − WRED tends toward a bias against fragile flows. Though fragile flows have fewer buffered packets, they are dropped at the same rate as packets of other flows.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-41
Flow-based WRED Objective • Per-active-flow loss rate that increases with the flow’s buffer usage –Robust: normal loss rate –Fragile: very light loss rate –Non-adaptive: very high loss rate
© 2001, Cisco Systems, Inc.
Congestion Avoidance -46
As FRED takes a flow’s buffer usage in consideration, it bases its dropping strategy on the amount of buffers used by active flows. The router therefore classifies flows based on their amount of buffer usage, and is able to penalize aggressive flows. All flows are characterized as robust flows, which can adapt to a normal loss rate; fragile flows, which need a very light loss rate; and non-adaptive flows, which can survive a very high loss rate. Therefore, FRED tries to identify non-adaptive flows and impose a higher drop rate onto them, compared to other, better-behaved flows.
5-42
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Flow-based WRED Building Blocks Calculate Average Per-flow Queue Size
WFQ Classifier (hash)
Scaling Factor Calculate Maximum Per-flow Queue Size
IP src&dst addr, PID TCP/UDP src&dst port IP packet
WRED
IP precedence or DSCP
Select WRED Profile
Min. threshold Max. Threshold Max prob. Denom.
Queue Full?
No
Current Number of Queue + Active Size Flows FIFO Queue
Yes
Random Drop
Tail Drop
© 2001, Cisco Systems, Inc.
Congestion Avoidance -47
This block diagram shows how FRED performs its dropping calculations based on the flow classification and queue sizes. An incoming packet is first classified into an active flow. A default WRED profile is chosen for the packet based on the precedence/DSCP value. FRED then determines the characteristics of the flow, by calculating the average per-flow buffer usage (average per-flow queue size) in the system, and based on it, the maximum per-flow queue size, using a scaling factor. By default, FRED computes the maximum per-flow queue size directly from the average queue per-flow queue size (the average size of queue used by flows in the router, calculated as the number of used buffers divided by the number of active flows), using a multiplicative factor of 4. If a flow uses more buffers than the maximum per-flow queue size, Cisco IOS deems the flow non-adaptive, and chooses a more aggressive RED profile for that flow, lowering the maximum threshold by half the difference between the current maximum and minimum threshold difference. In short, a flow is considered non-adaptive when its flow-depth is larger than the expected maximum due to burstiness, which depends on the scaling factor: average-flow-depth * (scaling factor) < flow-depth
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-43
Configuring Flow-based WRED Router(config-if)# random-detect random-detect flow flow
IOS IOS 12.0(3)T
• Configures Flow-based Weighted Random Early Detection on the specified interface • Disables distributed WRED on VIP-based interfaces • Disables all queuing and reverts to FIFO queuing
© 2001, Cisco Systems, Inc.
Congestion Avoidance -48
To enable flow-based WRED, use the random-detect flow interface configuration command. You must use this command to enable flow-based WRED before you can use the random-detect flow average-depth-factor and random-detect flow count commands to further configure the parameters of flow-based WRED.
5-44
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Tuning Flow-based WRED Router(config-if)# random-detect flow average-depth-factor scaling-factor scaling-factor
• Specifies the scaling factor used to compute maximum per-flow queue size from average perflow queue size • Default value is 4 Router(config-if)# random-detect flow flow count count number
• Specifies the maximum number of flows tracked by the flow-based WRED • Default value is 256 © 2001, Cisco Systems, Inc.
Congestion Avoidance -49
Two FRED tuning parameters, the random-detect flow average-depth-factor, and the random-detect flow count, are available to change the default behavior of FRED. The first parameter changes the multiplicative scaling factor used in calculating the maximum per-flow queue size, used to differentiate non-adaptive flows from adaptive and fragile flows. If there is a large number of low-bandwidth flows over an interface (resulting in a very low average per-flow queue size), the scaling factor could be increased to detect truly aggressive flows. The second parameter specifies the maximum amount of flows, tracked by FRED at any given instant (snapshot of the queue). This parameter may be increased to support an interface, carrying a large number of concurrent flows.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-45
Monitoring Flow-based WRED • All standard WRED commands – show interface – show queueing – show queue – show interface random-detect
• Displays flow parameters – show queueing random-detect
© 2001, Cisco Systems, Inc.
Congestion Avoidance -50
To monitor FRED, use the standard (W)RED monitoring commands.
5-46
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Displays Flow Parameters Router# show queueing random-detect CPE_1# show queueing CPE_1#show queueing random-detect random -detect Current Current random-detect random -detect configuration: configuration: Serial0 Serial0 Queueing strategy: Queueing strategy: random random early early detection detection (WRED) (WRED) Exp-weight-constant: Exp-weight -constant: 99 (1/512) (1/512) Mean Mean queue queue depth: depth: 00 Max Average Max flow flow count: count: 256 256 Average depth depth factor: factor: 44 Flows Flows (active/max (active/max active/max): active/max): 0/0/256 0/0/256 Class Class 00 11 22 33 44 55 66 77 rsvp rsvp
© 2001, Cisco Systems, Inc.
Random Random drop drop 00 00 00 00 00 00 00 00 00
Tail Minimum Maximum Mark Tail Minimum Maximum Mark drop drop threshold threshold threshold threshold probability probability 00 20 40 1/10 20 40 1/10 00 22 40 1/10 22 40 1/10 00 24 40 1/10 24 40 1/10 00 26 40 1/10 26 40 1/10 00 28 40 1/10 28 40 1/10 00 31 40 1/10 31 40 1/10 00 33 40 1/10 33 40 1/10 00 35 40 1/10 35 40 1/10 00 37 40 1/10 37 40 1/10
Congestion Avoidance -51
The show queuing command shows the configuration and statistics for configured WRED profiles, together with FRED parameters, such as the number of active flows in the queue, and the depth scaling factor.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-47
Benefits of Flow-based WRED • Ensures that flows that respond to WRED packet drops by backing off packet transmission are protected from flows that do not respond to WRED packet drops • Prohibits a single flow from monopolizing the buffer resources at an interface – Flow-based WRED punishes aggressive UDP flows
© 2001, Cisco Systems, Inc.
Congestion Avoidance -52
FRED therefore has substantial benefits compared to WRED, as it can also be used in environments that do not exhibit a predominantly TCP-based traffic mix. FRED enables differentiated dropping between fragile and non-adaptive flows, in which the loss rate is higher with non-adaptive flows. This is something that WRED is unable to do, because it drops packets without regard to flow buffer usage. Therefore, FRED protects fragile and adaptive flows from non-adaptive flows, which may, in the case of RED, monopolize router queues in their path.
5-48
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Drawbacks of Flow-based WRED • Flow-based WRED is not distributed • Works only in combination with FIFO queuing • Not predictable • Depends on host behavior for effectiveness
© 2001, Cisco Systems, Inc.
Congestion Avoidance -53
Since FRED does not yet run in a distributed mode, and only works in combination with FIFO queuing, its applications are limited. FRED is also not predictable in its operation, and somewhat depends on the behavior of endpoints, which must properly adapt their sending rate based on loss signals from the network.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-49
Summary n
Flow-based WRED differentiates flows and keeps state information about current flows in the output queue.
n
Flow-based WRED can penalize non-adaptive flows by dropping their packets more aggressively.
n
Flow-based WRED is configured on router interfaces
Lesson Review 1. What is the difference between WRED and Flow-based WRED? 2. How many queues does Flow-based WRED have? 3. What are the benefits and drawbacks of Flow-based WRED?
5-50
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Summary n
RED randomly drops packets before an interface is congested, punishing aggressive flows.
n
WRED uses precedence or DSCP-dependent dropping slopes to differentiate RED dropping for different classes of traffic.
n
WRED is configured on router interfaces and can run distributed on VIPbased interfaces.
n
Flow-based WRED differentiates flows and keeps state information about current flows in the output queue.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-51
Review
Questions and Answers Random Early Detection Question: What are the main drawbacks of using tail-drop as a means of congestion control? Answer: Tail drop causes global synchronization of TCP session, TCP starvations, and jitter. Question: What does RED do to prevent TCP synchronization? Answer: RED performs random dropping of packets, as the average queue length indicates a possible trend towards congestion. As aggressive flows usually have more packets in the queue compared to non-aggressive flows, random dropping punishes aggressive flows with higher probability by dropping their packets. Packet drops signal the aggressive TCP sender to slow down and adapt its sending rate. Question: What are the three modes of RED? Answer: RED has three queue management modes: no drop, when the average queue length is below the minimum threshold, random drop, when the average queue length is between the minimum and maximum thresholds and full drop, when the average queue length is above the maximum threshold.
Weighted Random Early Detection Question: What are the key differences between RED and WRED? Answer: WRED can perform differentiated dropping, taking IP precedence or
DSCP value into account. RED drops are based only on the average queue length and all packets share the same drop profile. Question: What can be used as weight in WRED? Answer: IP precedence or DSCP value can be used as the weight in WRED.
Question: Which dropping modes does WRED have? Answer: As is the case with RED, WRED has three queue management modes:
no drop, when the average queue length is below the minimum threshold, random drop, when the average queue length is between the minimum and maximum thresholds and full drop, when the average queue length is above the maximum threshold. With WRED different threshold values are used for each weight (IP precedence or DSCP) value, establishing differentiated dropping profiles.
Flow-based Weighted Random Early Detection 5-52
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Question: What is the difference between WRED and Flow-based WRED? Answer: Flow-based WRED is able to differentiate between different flows based on their buffer usage. Therefore, it is more precise than WRED when differentiating between different senders, and can more appropriately punish aggressive sessions. Question: How many queues does Flow-based WRED have? Answer: By default, Flow-based WRED maintains 256 flow queues. Question: What are the benefits and drawbacks of Flow-based WRED? Answer: Flow-based WRED has the potential to punish aggressive UDP sessions by freeing the queue resources early. It can not, however, lower their sending rate. Also, Flow-based WRED currently does not run distributed on the VIP.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-53
6
Link Efficiency Mechanisms
Overview The module describes one approach to handling congested links; compression. It discusses link efficiency mechanisms that either compress the payload of packets (Stacker and Predictor) or reduce packet overhead by compressing their headers (TCP and RTP header compression). It also discusses two different layer-2 link fragmentation mechanisms (PPP Multilink and Frame Relay Fragmentation).
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe and configure Stacker payload compression
n
Describe and configure Predictor payload compression
n
Describe and configure TCP header compression
n
Describe and configure RTP header compression
n
Describe and configure PPP Multilink with interleaving
n
Describe and configure Frame Relay Fragmentation
Payload Compression Overview This lesson describes two payload compression mechanisms. It describes the Stacker and Predictor mechanisms that can be used to reduce the size of data in packets or frames.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
6-2
n
Describe and configure Stacker compression
n
Describe and configure Predictor compression
n
Monitor and troubleshoot compression
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Payload Compression QoS does not create bandwidth. Payload compression does. Payload compression uses a compression algorithm to squeeze the payload of layer-2 frames Payload compression increases perceived throughput and decreases perceived latency
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms -5
While many mechanisms exist for optimizing throughput and reducing delay in network traffic within the QoS portfolio, QoS does not create bandwidth. QoS optimizes the use of existing resources, and enables the differentiation of traffic according to the operator policy. Payload compression does create additional bandwidth, because it squeezes packet payloads, and therefore increases the amount of data that can be sent through a transmission resource in a given time period. Payload compression is mostly performed on layer-2 frames and therefore compresses the entire layer-3 packet. Note that IP PCP (Payload Compression Protocol) is a fairly new technique for compressing payloads on layer 3, and can handle out-of-order data. The IP PCP compression method is not discusses in this lesson. As compression squeezes payloads, it both increases the perceived throughput, and decreases perceived latency in transmission, because smaller, packets (with compressed payloads) take less time to transmit (than the larger, uncompressed packets).
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-3
Compression Building Blocks Forwarder FH
Compression Algorithm
IP
Output Queue FH
Compression is a CPU-intensive task It adds to the overall delay experienced by IP packets.
cIP
Packets reduced in size take less time to transmit. More packets can be transmitted.
Compression reduces the size of the frame payload Entire IP packet is compressed Compression adds delay due to its complexity Serialization delay is reduced, overall latency might be reduced © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms -6
The figure shows a basic block diagram of a compression method. When a router forwards a packet, it is subjected to the layer-2 compression method after it has been encapsulated at the output. The compression method squeezes the payload of the layer-2 frame (the entire layer-3 packet), and transmits the packet on the interface. Layer-2 compression requires serialization of packet delivery, which means that packets must be received by the remote layer-2 station in the same order as they were sent. Compression is a CPU-intensive task and can add per-packet delay due to the application of the compression method to each frame. The transmission (serialization) delay, however, is reduced, because the resulting frame is smaller. Depending on the complexity of the payload compression algorithm, overall latency might be reduced, especially on low-speed links.
6-4
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Compression Results Link bandwidth 256 kbps
NO COMPRESSION
Delay=1 ms
Delay=8 ms
Throughput 256 kbps
Total Delay=9 ms
Link bandwidth 256 kbps
COMPRESSION COMPRESSION
Delay=10 ms
HARDWARE HARDWARE COMPRESSION COMPRESSION
Delay=4 ms
Throughput 500 kbps
Total Delay=14 ms
Link bandwidth 256 kbps
Delay=2 ms
Delay=4 ms
Throughput 500 kbps
Total Delay=6 ms
Compression increases throughput Compressions may increase delay © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms -7
The figure compares three throughput/latency scenarios on a point-to-point link. If no compression is used, the perceived throughput is limited by the link bandwidth, and the average delay is influenced only by the forwarding/buffering delay and the serialization (transmission) delay. If compression is enabled, the packet latency between the two hops is a function of forwarding delay, compression delay, and transmission delay. Even if the transmission delay is now shorter, the compression/decompression delay may increase the overall latency between the two hops. Throughput is generally increased and is limited by the effectiveness of the compression algorithm. If hardware-assisted compression is used, the compression/decompression delays may become insignificant compared to transmission and forwarding delays, and overall latency may decrease. Throughput is again limited by the effectiveness of the compression method and may be significantly higher than the link bandwidth limit.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-5
Compression Algorithms Cisco routers support the following compression algorithms: • STAC or Stacker (STAC Electronics or Hi/fn, Inc.) • MPPC (Microsoft Point-to-point Compression) • Predictor (public domain algorithm)
These algorithms differ in compression capabilities, CPU and memory utilization © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms -8
Cisco IOS supports three different compression algorithms used in layer-2 compression: STAC (or Stacker), Microsoft Point-to-Point Compression (MPPC), and predictor. These algorithms differ vastly in their compression efficiency, and in utilization of router resources.
6-6
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Stacker and MPPC Compression Stacker or STAC is a compression algorithm developed by STAC Electronics Stacker uses the LZ (Lempel-Ziv) algorithm that searches for redundant strings and replaces them with short tokens It builds a dictionary where token values are mapped to these strings MPPC is developed by Microsoft and also uses the LZ algorithm
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms -9
The STAC (or Stacker) algorithm is based on the well-known LZ (Lempel-Ziv) compression algorithm. The LZ (sometimes also called LZW) algorithm searches the byte stream for redundant strings, and replaces them with shorter dictionary tokens. The dictionary is built in real time, and there is no need to exchange the dictionary between the compression peers, because the dictionary is reconstructed from the data received by the remote peer. The MPPC method also uses the same LZ algorithm. The STAC and MPPC algorithms yield very good compression results, but are CPU-intensive.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-7
Predictor Compression Predictor is a public domain compression algorithm Predictor uses a hashed sequence of characters as an index into the compression dictionary The entry in the dictionary is compared to the next sequence of characters
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-10
The predictor is a simple, very fast, and CPU-friendly algorithm, but this algorithm yields a lower compression ratio. It is based on predicting the next byte-sequence in the stream based on a simple dictionary, which is rebuilt from the source or the compressed data without the need to exchange a dictionary between the peers.
6-8
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Stacker/MPPC vs. Predictor Stacker and MPPC are very CPU-intensive • • • • •
Good average compression ratio Slower Produces more delay Should be used on slower links Stacker has more tuning capabilities
Predictor requires more memory • • • •
Less efficient than Stacker or MPPC Faster, uses less CPU time Produces less delay Can be used on faster links
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-11
The STAC, MPPC, and predictor algorithms are usually used to perform layer-2 payload compression on point-to-point links between Cisco IOS routers. The STAC and MPPC methods are CPU-intensive. However these methods yield very good compression rates on the average, produce more compression/decompression delay in the router, and should be used on slower links if software compression is used. Predictor is a leaner and simpler algorithm, which can be deployed on faster links with software compression, and which introduces less delay in the packet path. However, predictor yields considerably lower compression ratios compared to the STAC algorithm.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-9
Compression and Layer-2 Encapsulation STAC
Predictor
MPPC
PPP
ü*
ü
ü
Frame Relay
ü*
O
O
HDLC
ü
O
O
LAPB
ü
ü
O
X.25
ü
O
O
* PPP and Frame Relay Stacker is also supported by hardware compression modules © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-12
The figure shows a comparison of different compression methods used by Cisco IOS to perform layer-2 payload compression. The STAC method is the most versatile, because it runs on any supported point-to-point layer-2 encapsulation. Predictor only supports PPP and LAPB, while MPPC only runs within PPP. Hardware-accelerated compression substantially increases compression throughput for CPU-intensive compression methods (such as STAC and MPPC, both based on the LZ algorithm) and is recommended when used on high-bandwidth links.
6-10
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Performance Compression performance depends on the following factors: • Router platform (CPU power) • Compression algorithm (Stacker, MPPC or Predictor) • Hardware compression support
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-13
Real-life compression performance depends on many factors, the most important being: n
Router CPU performance, if compression is performed in software. The router runs the compression algorithm for each packet on an interface, configured for compression.
n
The compression algorithm because there are large differences in the performance of the algorithm itself. Generally, CPU-intensive algorithms produce better compression ratios.
n
Hardware compression support offloads the task of compression from the CPU, which decreases forwarding latency and frees the CPU to perform other tasks.
n
Data compressibility, which influences both the compression ratio and sometimes the performance of the algorithm itself.
On average, Stacker and MPPC can yield up to 50% reduction in data size (a compression ratio of 2), when used on real network traffic. Predictor can theoretically achieve such a rate, if network traffic includes mostly predictive text data. In most networks, predictor compression ratio is much lower than Stacker’s, and usually in the 30-40% range of data size reduction (that is, compression ratios less than 1.8).
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-11
Configuring Stacker Interface configuration steps: • Select one of the supported layer-2 encapsulations (PPP, F/R, HDLC, LAPB or X.25) • Enable Stacker compression • Optionally select the ratio, force software based compression or enable distributed compression
Monitor compression © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-14
Stacker (STAC) compression is configured on interfaces with the appropriate supported encapsulation. The STAC method can be tuned, and software or hardware compression can be selected. After STAC has been enabled on an interface, Cisco IOS provides a means to monitor the compression ratios in real time.
6-12
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Stacker with PPP Encapsulation Router(config-if)# compress stac stac
• Enables STAC with default parameters Router(config-if)# compress stac stac distributed distributed
• Offloads compression to a VIP • Supported on VIP2-40 or newer Router(config-if)# compress stac stac ratio ratio {high {high || low low || medium} medium}
• Balance throughput with delay • Low compression ratio is the default
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-15
The compress stac command enables STAC compression on an interface with supported encapsulation. STAC can also run distributed on the VIP processor. The compress stac ratio command tunes STAC so that the compression ratio is traded for delay. For example, selecting a low compression ratio produces less CPU usage, while the high compression ratio performs better compression, but increases the CPU load and adds delay, which may decrease throughput. The recommended ratio depends on the type of network traffic and its sensitivity to delay. The rule of thumb is to start with the default low ratio, and try to increase the ratio and measure throughput. If observed compression ratios increase (as shown by the show compression command), but throughput actually decreases, the configured ratio should be lowered again.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-13
Configuring Stacker with Frame Relay Encapsulation Router(config-if)# frame-relay payload-compression payload-compression FRF9 FRF9 stac stac
• Enables STAC with default parameters Router(config-if)# frame-relay payload-compression payload-compression FRF9 FRF9 stac stac distributed distributed
• Offloads compression to a VIP • Supported on VIP2-40 or newer Router(config-if)# frame-relay payload-compression payload-compression FRF9 FRF9 stac stac ratio ratio {high {high || low} low}
• Balance throughput with delay • Low compression ratio is the default
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-16
Cisco IOS supports the native Frame Relay compression protocol according to the FRF.9 standard. The compression method used is equivalent to STAC compression. Also, the commands required to configure Frame Relay STAC compression are analogous to the command used to configure STAC with other supported encapsulations. This command should be used when using the default Frame Relay encapsulation over Frame Relay networks.
6-14
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Predictor or MPPC Router(config-if)# compress predictor predictor
• Enables Predictor compression Router(config-if)# compress mppc mppc [ignore-pfc] [ignore-pfc]
• Enables MPPC compression • Use the ignore-pfc option to ignore the protocol number negotiation
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-17
The compress predictor command configures predictor compression. No tuning parameters are available for this command. The compress mppc command configures MPPC compression, and is used mainly with Windows clients and when running a layer-2 tunneling session (for example, the Point-to-Point Tunneling Protocol (PPTP). The ignore -pfc keyword instructs the router to ignore the protocol field compression flag negotiated by LCP. For example, the uncompressed standard protocol field value for IP is 0x0021 and 0x21 when compression is enabled. When the ignore -pfc option is enabled, the router will continue to use the uncompressed value (0x0021). Using the ignore -pfc option is helpful for some asynchronous driver devices that use an uncompressed protocol field (0x0021), even though the pfc is negotiated between peers. If protocol rejects are displayed when the debug ppp negotiation command is enabled, setting the ignore -pfc option may remedy the problem.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-15
Hardware Compression Hardware compression is available using the following modules: • Compression Advanced Interface Module (CAIM) is a daughter-board module for Cisco 2600 series routers • Compression Service Adapter (CSA) module for Cisco 7x00 series routers • Compression Network Module (NM-COMPR2) for Cisco 3620 and Cisco 3640 series routers • AIM-COMPR4 is a daughter-board compression module for Cisco 3660 series routers © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-18
There are a number of hardware compression modules and daughter boards available for use in Cisco routers.
6-16
n
The Compression Advanced Interface Module (CAIM) is a daughter board that is placed in the AIM motherboard slot on Cisco 2600-series routers. It does not occupy any network interface slots, and accelerates the STAC and MPPC compression methods.
n
The Compression Service Adapter (CSA) is a port adapter for the Cisco 7x00 series routers. The CSA offloads the compression task from the main CPU or the VIP2 (using distributed compression). When used in the Cisco 7200-series router, the CSA can offload compression at any interface. If used on the VIP2, it offloads compression at the adjacent port adapter on the same VIP only.
n
The Compression Network Module is a network module for the Cisco 3600series routers. The Compression Network Module occupies a network module slot in the router, and can offload compression at any router interface.
n
The AIM-COMPR4 is a hardware-compression daughter board used in the Cisco 3660 router. The AIM-COMPR4 integrates with the router motherboard and does not occupy any network module slots in the chassis.
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuration Example interface interface Serial1/0 Serial1/0 encapsulation encapsulation ppp ppp compress compress stac !! interface interface Serial1/1 Serial1/1 encapsulation encapsulation ppp ppp compress compress stac stac caim caim 0 0 !! interface interface Serial1/2 Serial1/2 encapsulation encapsulation ppp ppp compress compress predictor predictor !! interface interface Serial1/2 Serial1/2 encapsulation -relay encapsulation frame frame-relay frame-relay frame-relay map map ip ip 1.1.1.1 1.1.1.1 102 102 broadcast broadcast ietf ietf !! interface interface Serial1/2.1 Serial1/2.1 point-to-point point-to-point frame-relay frame-relay interface-dlci interface-dlci 101 ietf frame-relay frame-relay payload-comp payload-comp FRF9 FRF9 stac stac !!
© 2001, Cisco Systems, Inc.
Software compression using the STAC algorithm Hardware compression using the STAC algorithm on the CAIM module (Cisco 2600 routers) Software compression using the Predictor algorithm
payload-compress payload-compress frf9 stac stac Software compression using the STAC algorithm
IP QoS Link Efficiency Mechanisms-19
The figure shows configuration examples that specify different compression configurations. In the example, the Serial1/0 interface uses software compression (this setting may automatically use hardware compression on high-end series). The Serial1/1 interface performs compression with the assistance of the CAIM (in a Cisco 2600-series router). Interfaces Serial1/2 and its Serial 1/2.1 sub-interface both use software STAC compression on the frame-relay level.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-17
Monitoring Compression Router#
show compression compression
• Displays compression statistics Router#show Router#show compression compression Serial5/1/0 Serial5/1/0 Software Software compression compression enabled enabled uncompressed uncompressed bytes bytes xmt/rcv xmt/rcv 21339/21339 21339/21339 compressed bytes compressed bytes xmt/rcv xmt/rcv 0/0 0/0 11 min min avg ratio xmt/rcv 2.110/2.110 55 min min avg avg ratio ratio xmt/rcv xmt/rcv 2.143/2.143 2.143/2.143 10 10 min min avg avg ratio ratio xmt/rcv xmt/rcv 2.143/2.143 2.143/2.143 no no bufs bufs xmt 0 no bufs rcv 0 resyncs resyncs 00 Additional Additional Stacker Stacker Stats: Stats: Transmit 00 Compressed Transmit bytes: bytes: Uncompressed Uncompressed == Compressed == Received 9953 Received bytes: bytes: Compressed Compressed == 9953 Uncompressed Uncompressed ==
© 2001, Cisco Systems, Inc.
9109 9109 00
IP QoS Link Efficiency Mechanisms-20
The show compression command displays per-interface compression statistics. The ratio shown in the output indicates the compression ratio (the ratio of uncompressed over the actual compressed byte stream size) on the input and the output of an interface.
6-18
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Summary n
Stacker and MPPC payload compression methods yield better compression ratios, is more CPU-intensive, and may introduce additional delay
n
The predictor payload compression method is faster, can be used in higherbandwidth scenarios, but generally yields lower average compression ratios
Lesson Review 1. What is the purpose of using payload compression? 2. List the payload compression algorithms than can be used. 3. What are some of the benefits and drawbacks of Stacker? 4. What are some of the benefits and drawbacks of Predictor?
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-19
Header Compression Overview This lesson describes the mechanisms that are used to reduce overhead on slow links by compressing IP and TCP headers in TCP header compression, or IP, UDP and RTP headers in RTP header compression.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
6-20
n
Describe and configure TCP header compression
n
Monitor and troubleshoot TCP header compression
n
Describe and configure RTP header compression
n
Monitor and troubleshoot RTP header compression
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Header Compression Header compression reduces the overhead by compressing packet and segment headers TCP Header compression compresses the IP and TCP headers RTP header compression compresses the IP, UDP and RTP headers Header compression is especially effective on slow links with interactive traffic or delay sensitive traffic (many short packets)
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-26
All compression methods are based on eliminating redundancy when sending the same or similar data over a transmission medium. One piece of data, which is often repeated, is the protocol header. In a flow, the header information of packets in the same flow does not change much over the lifetime of that flow. Therefore, most of header information could be sent only at the beginning of the session, stored in a dictionary, and then referenced in later packets by a short dictionary index. Two methods were standardized by the IETF (Internet Engineering Task Force) for use with IP protocols: n
TCP header compression (also known as the Van Jacobson or VJ header compression) is used to compress the packet TCP headers over slow links, thus considerably improving the interactive application performance.
n
RTP header compression is used to compress UDP and RTP headers, thus lowering the delay for transporting real-time data, such as voice and video over slower links.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-21
Header Compression Basics Compression is performed by eliminating static or predicable header information Session indices are used instead Only changing parameters in headers are still sent Header compression is enabled on a linkby-link basis
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-26
Header compression methods work by not transmitting repeated information in packet headers throughout a session. For a TCP session, such parameters are the IP header and the TCP port numbers. The two peers on a point-to-point layer-2 connection (such as a dial-up link) agree on session indices, which index a dictionary of packet headers. The dictionary is built at the start of every session, and is used for all subsequent (non-initial) packets. Only changing (non-constant) parameters in the headers are actually sent with the session index. It is important to note that header compression is performed on a link-by-link basis. Header compression cannot be performed across multiple routers, because routers need full Layer-3 header information to be able to route packets to the next hop.
6-22
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Header Compression Building Blocks Header Compression Algorithm
Forwarder FH
IP
L4 (L5)
payload
Output Queue FH
The header compression algorithm keeps track of flows and static parameters in headers
cH
payload
IP and higher-layer headers are compressed
Compression reduces the size of packet headers The payload is not changed © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-28
The figure shows a block diagram of a header compression method. The header compression algorithm tracks active transport-layer connections over an interface. After the packet has been forwarded, the header compression algorithm compresses the layer-3 and layer-4 headers within the frame, and replaces them with a session index from the session dictionary (table). The packet is then sent to the output queue, and transmitted to the remote peer. When the remote peer receives the packet, the header is decompressed using the local session table, and passed to the forwarding process.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-23
Header Compression Results NO COMPRESSION Link bandwidth 64 kbps Delay=1 ms
COMPRESSION COMPRESSION
Throughput 64 kbps
Delay=8 ms
Link bandwidth 64 kbps
Throughput 100 kbps
Delay=4 ms Delay=2 ms
Header compression increases throughput Header compressions reduces delay © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-29
By compressing the header, the layer-2 frame gets smaller and therefore more data is sent through a channel in a given time period. Also, the packet transmission time is smaller; therefore header compression both increases the throughput and reduces the overall delay of a transmission line.
6-24
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Header Compression Algorithms TCP Header Compression (RFC 1144) • Used to reduce the overhead of TCP segments • Most effective on slow links with a lot of TCP sessions with small payloads (for example, Telnet)
RTP Header Compression (RFC 1889) • Used to reduce delay and increase throughput for Real Time Protocol (RTP) • Improves voice quality • Most effective on slow links © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-30
The two header compression methods available in Cisco IOS are the TCP header compression (standardized by RFC 1144), and the RTP header compression (standardized by RFC 1889). TCP header compression is usually used to improve the interactive session response over low-speed links, where layer-3 and layer-4 headers represent a significant portion of the layer-2 frame. RTP header compression is used mostly on slow links, to reduce delay and increase throughput of an RTP-based application (usually voice traffic).
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-25
TCP Header Compression Most Internet Applications use TCP as the transport protocol Most of the information in the headers (IP and TCP) is static or predictable throughout the session IP (20 bytes) and TCP (20 bytes) use 40 bytes TCP Header Compression can squeeze these two headers into 3 to 5 bytes © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-31
With TCP header compression, the IP and TCP headers, which normally use 20 bytes each, is reduced to a session index, and the changing part of the header. With all optimizations, the combined header length of 40 bytes can be reduced to a 3 to 5-byte compressed header.
6-26
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
TCP Header Compression Case Study Link bandwidth is 64 kbps The link is used for a number of interactive TCP sessions PPP encapsulation is used Average packet size is 5 bytes Each segment has 46 bytes of overhead (PPP, IP and TCP headers) © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-32
This case study illustrates the benefits of TCP header compression on slow links. A 64 kbps link is used to transport a TCP-based application using PPP as the layer-2 framing protocol. For the case study application (telnet), the average packet payload size is 5 bytes. Since PPP has 6 bytes of frame header, the total header overhead is 6+20+20=46 bytes, counting the PPP, IP, and TCP headers.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-27
TCP Header Compression Case Study 6
20
PPP
IP
20 TCP
5
6
4
5
Telnet
PPP
cT
Telnet
46 5 Overhead = 46/(46+5) Overhead = 90% Delay = (46+5) / 64 kbps Delay = 6 ms IP packet Overhead Delay on size No comp. 64 kbps 10 82% 7 ms 50 48% 12 ms 100 32% 18 ms 500 8% 67 ms 1500 3% 189 ms © 2001, Cisco Systems, Inc.
10 5 Overhead = 10/(10+5) Overhead = 67% Delay = (10+5) / 64kbps Delay = 2 ms Overhead Comp. 50% 17% 9% 2% 1%
Delay on 64 kbps 2 ms 7 ms 13 ms 62 ms 184 ms IP QoS Link Efficiency Mechanisms-33
The figure shows the packet size before and after header compression. The IP and TCP headers are reduced to 4 bytes, resulting in 10 bytes of overall headers. The overhead is reduced from 90% to 67%, when small packets are used. Because of size reduction, the transmission delay decreases from 6 ms to 2 ms on the same link. The table in the figure shows how header compression impacts performance when different packet sizes are used. Header compression is most effective on small packets, used on slow links.
6-28
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring TCP Header Compression Router(config-if)#
ip tcp header-compression [passive]
• Enables TCP Header Compression on an interface using PPP or HDLC encapsulation • Use the passive option to enable TCP Header Compression only if initiated by the peer Router(config-if)#
frame-relay ip tcp header-compression [passive]
• Enables TCP Header Compression on an interface using Frame Relay encapsulation • Use the passive option to enable TCP Header Compression only if initiated by the peer © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-34
TCP header compression is configured with the ip tcp header-compression command. The passive option instructs the peer to use header compression only if the remote peer initiates header compression. This is often used in a dialup environment, where this option is enabled on the access server. On frame relay, the frame-relay ip tcp header-compression configures header compression with interfaces using pure frame relay encapsulation. In Cisco IOS, TCP header compression is now fast and CEF-switched. Up to 256 connections, which is also the default value, can be compressed over a point-topoint link.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-29
TCP Header Compression Example interface Serial0/0 ip address 10.2.1.2 255.255.255.252 encapsulation frame-relay frame-relay ip tcp header -compress !
interface Dialer1 ip address negotiated ip tcp header-compression !
Frame Relay
POTS / ISDN
RouterA
RouterC
RouterB interface Serial0 ip address 10.2.1.1 255.255.255.252 encapsulation frame-relay frame-relay ip tcp header -compression ! interface Virtual-template1 ip address 10.1.1.1 255.255.0.0 ip tcp header-compression passive ! © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-34
The figure shows an example configuration of three peers using TCP header compression. RouterC uses header compression on a dialer interface, connecting to the central access server (RouterB). The access server (RouterB) is configured to perform header compression only if the remote peer (RouterC) initiates it, and therefore supports peers using headercompression, and peers using plain layer-2 transmission. The access server (RouterB) connects to a remote site (RouterA) over framerelay. Both frame-relay endpoints (RouterA and RouterB) are configured to perform TCP header compression over the frame-relay link.
6-30
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Monitoring TCP Header Compression Router# show ip ip tcp tcp header-compression header-compression [interface]
• Displays TCP Header Compression statistics Router#show Router#show ip ip tcp tcp header-compression header-compression serial0/0 serial0/0 TCP/IP TCP/IP header header compression compression statistics: statistics: Interface Interface Serial0/0: Serial0/0: Rcvd: 24 total, 20 compressed, Rcvd: compressed, 0 errors errors 00 dropped, dropped, 00 buffer buffer copies, copies, 00 buffer buffer failures failures Sent: 24 Sent: 24 total, total, 20 20 compressed, compressed, 679 679 bytes bytes saved, saved, 249 249 bytes bytes sent sent 3.72 3.72 efficiency efficiency improvement improvement factor factor Connect: Connect: 255 255 rx slots, 255 tx tx slots, slots, 12 12 long long searches, searches, 44 misses misses 00 collisions collisions 83% 83% hit hit ratio, ratio, five five minute minute miss miss rate rate 00 misses/sec, misses/sec, 00 max
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-36
The show ip tcp header-compression command displays the statistics of TCP header compression on an interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-31
Monitoring TCP Header Compression Router# show frame-relay ip ip tcp tcp header-compression header-compression [interface]
• Displays TCP Header Compression statistics on frame-relay (sub)interfaces Router#show Router#show frame-relay frame-relay ip ip tcp tcp header-compression header-compression DLCI Link/Destination DLCI 100 100 Link/Destination info: info: point-to-point point -to-point dlci dlci Interface Interface Serial0/0: Serial0/0: Rcvd: 24 total, 23 compressed, Rcvd: compressed, 0 errors errors 00 dropped, dropped, 00 buffer buffer copies, copies, 00 buffer buffer failures failures Sent: 27 Sent: 27 total, total, 26 26 compressed, compressed, 864 864 bytes bytes saved, saved, 225 225 bytes bytes sent sent 4.84 4.84 efficiency efficiency improvement improvement factor factor Connect: 256 rx slots, 256 tx slots, Connect: 256 tx slots, 11 long searches, searches, 1 misses 0 collisions collisions 96% 96% hit hit ratio, ratio, five five minute minute miss miss rate rate 00 misses/sec, misses/sec, 00 max
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-37
The show frame -relay ip tcp header-compression command displays the statistics of TCP header compression on a Frame Relay interface.
6-32
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
RTP Header Compression Voice sessions use Real-time Transport Protocol (RTP) RTP uses UDP for transport Most of the information in the headers (IP, UDP and RTP) is static throughout the session IP (20 bytes), UDP (8 bytes) and RTP (12 bytes) use 40 bytes RTP header compression can squeeze these three headers into 3 to 5 bytes © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-37
Real-Time Protocol (RTP) is the Internet Standard (RFC 1889) protocol for the transport of real-time data. It is intended to provide end-to-end network transport functions for applications that support audio, video, or simulation data over multicast or unicast network services. RTP is used in most Voice over IP applications to transport packetized voice. RTP includes a data portion and a header portion. The data portion of RTP is a thin protocol that provides support for the real-time properties of applications, such as continuous media, and includes timing reconstruction, loss detection, and content identification. RTP contains a relatively large sized header. The 12 bytes of the RTP header, combined with 20 bytes of IP header (IPH) and 8 bytes of the User Datagram Protocol (UDP) header, create a 40-byte IP/UDP/RTP header. For compressed-payload audio applications, the RTP packet typically has a 20-byte to 160-byte payload. Given the size of the IP/UDP/RTP header combinations, it is inefficient to send the IP/UDP/RTP header without compressing it. To avoid the unnecessary consumption of available bandwidth, the RTP header compression feature (CRTP) is used on a link-by-link basis. CRTP can reduce the header from 40 bytes to a 3 to 5-byte header, which significantly reduces delay on slow links.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-33
RTP Header Compression Case Study Link bandwidth is 64 kbps The link is used for Voice over IP PPP encapsulation is used G.729 codec is used (8 kbps of voice data, 50 samples per second, 20 bytes per sample) Each segment has 46 bytes of overhead (PPP, IP, UDP and RTP headers)
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-39
This case study illustrates the benefits of RTP header compression on slow links. A 64 kbps link is used to transport Voice over IP using PPP as the layer-2 framing protocol. For the case study application (voice using the G.729 audio compression codec), the average payload size is 20 bytes. Since PPP has 6 bytes of frame header, the total header overhead is 6+20+20=46 bytes, counting the PPP, IP, UDP, and RTP headers.
6-34
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
RTP Header Compression Case Study 6
20
PPP
IP
46
8 12
20
UDP RTP
Voice
6
4
PPP
20
10
cR
20 Voice
20
Overhead = 46 / (46 + 20) = 70% Delay = (46 + 20) / 64 kbps = 8 ms BW = (46 + 20) * 50 * 8 = 26 kbps
Overhead = 10 / (10 + 20) = 33% Delay = (10 + 20) / 64kbps = 4 ms BW = (10 + 20) * 50 * 8 = 12 kbps
2 voice sessions / 64 kbps
5 voice sessions / 64 kbps
Codec
Voice Bandwidth G.711 64 kbps G.729 8 kbps
© 2001, Cisco Systems, Inc.
RTP Bandwidth 82 kbps 26 kbps
RTP Overhead 22% 61%
CRTP Bandwidth 68 kbps 12 kbps
CRTP Overhead 3% 33%
IP QoS Link Efficiency Mechanisms-40
The figure shows the packet size before and after header compression. The IP, UDP, and RTP headers are reduced to 4 bytes, resulting in 10 bytes of overall headers. The overhead is reduced from 70% to 33%, when small packets are used. Because of size reduction, the transmission delay decreases from 8 ms to 4 ms, and the bandwidth used to transport a single voice call (using the G.729 codec) is reduced from 26 to 12 kbps. The table in the figure shows how header compression impacts performance when a different audio codec is used. For the traditional G.711 voice codec, CRTP still optimizes its transmission over slow links. However, the difference is more obvious when using advanced, low-bandwidth codecs are used.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-35
Configuring RTP Header Compression Router(config-if)#
ip rtp header-compression [passive]
• Enables RTP Header Compression on an interface using PPP or HDLC encapsulation • Use the passive option to enable RTP Header Compression only if initiated by the peer Router(config-if)#
frame-relay ip rtp header-compression [passive]
• Enables RTP Header Compression on an interface using Frame Relay encapsulation • Use the passive option to enable RTP Header Compression only if initiated by the peer © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-41
RTP header compression is configured with the ip rtp header-compression command. The passive option instructs the peer to use RTP header compression only if the remote peer initiates RTP header compression. On frame relay, the frame-relay ip rtp header-compression configures header compression with interfaces using pure frame relay encapsulation. In Cisco IOS, RTP header compression is now fast and CEF-switched. If distributed CEF (dCEF) is configured, CRTP also runs in distributed mode. Up to 256 connections, which is also the default value, can be compressed over a pointto-point link.
6-36
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
RTP Header Compression Example interface Serial0/0 ip address 10.2.1.2 255.255.255.252 encapsulation frame-relay frame-relay ip rtp header-compression !
interface Serial0/0 ip address 10.1.1.2 255.255.255.252 encapsulation ppp ip rtp header-compression !
RouterB Frame Relay RouterA
RouterC TDM (leased line)
ip cef distributed ! interface Serial5/1/0 ip address 10.2.1.1 255.255.255.252 encapsulation frame-relay frame-relay ip rtp header-compression ! interface Serial5/1/1 ip address 10.1.1.1 255.255.0.0 encapsulation ppp ip rtp header-compression ! © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-41
The figure shows an example implementation of CRTP on a two-tiered scenario, where two sites (using routers Router A and RouterC) are interconnected over a TDM and Frame Relay network. Over the TDM network, a leased line carries all (including packetized voice) traffic. RTP header compression is used within the PPP session between RouterA and RouterB. Over the frame-relay network, the point-to-point Frame Relay channel between RouterB and RouterC uses CRTP over the native Frame Relay encapsulation.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-37
Monitoring RTP Header Compression Router# show ip ip rtp rtp header-compression header-compression [interface]
• Displays RTP Header Compression statistics Router#show Router#show ip ip rtp rtp header-compression header-compression serial0/0 serial0/0 RTP/UDP/IP RTP/UDP/IP header header compression compression statistics: statistics: Interface Interface Serial1: Rcvd: Rcvd: 00 total, total, 00 compressed, compressed, 00 errors errors 00 dropped, dropped, 00 buffer buffer copies, 0 buffer failures Sent: Sent: 430 total 429 compressed, 15122 15122 bytes bytes saved, saved, 139318 139318 bytes bytes sent sent 1.10 1.10 efficiency efficiency improvement improvement factor factor Connect: Connect: 16 rx slots, slots, 16 tx tx slots, slots, 1 long searches, 1 misses 99% 99% hit hit ratio, ratio, five five minute minute miss miss rate 0 misses/sec, 0 max.
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-43
The show ip rtp header-compression command displays the statistics of CRTP on an interface.
6-38
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Monitoring RTP Header Compression Router# show frame-relay ip ip tcp tcp header-compression header-compression [interface]
• Displays RTP Header Compression statistics on frame-relay (sub)interfaces Router#show Router#show frame-relay frame-relay ip ip tcp tcp header-compression header-compression DLCI DLCI 17 17 Link/Destination Link/Destination info: info: ip ip 165.3.3.2 165.3.3.2 Interface Interface Serial0: Serial0: Rcvd: 00 total, Rcvd: total, 00 compressed, compressed, 00 errors errors 00 dropped, dropped, 00 buffer buffer copies, copies, 00 buffer buffer failures failures Sent: 6000 Sent: 6000 total, total, 5998 5998 compressed, compressed, 227922 227922 bytes bytes saved, saved, 251918 251918 bytes bytes sent sent 1.90 1.90 efficiency efficiency improvement improvement factor factor Connect: 16 rx slots, 16 tx slots, 2 long searches, Connect: 16 rx slots, 16 tx slots, 2 long searches, 22 misses misses 99% 99% hit hit ratio, ratio, five five minute minute miss miss rate rate 00 misses/sec, misses/sec, 00 max
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-44
The show frame -relay ip rtp header-compression command displays the statistics of CRTP on a frame-relay interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-39
Summary n
TCP header compression optimizes performance of interactive TCP-based applications on slow links, by shrinking IP and TCP headers to 3-5 byte indices
n
RTP header compression optimizes performance of delay-sensitive RTP-based applications, such as voice, on slow links, by shrinking IP, UDP, and RTP headers to 3-5 byte indices
n
TCP and RTP header compression methods can be implemented with Cisco IOS software
Lesson Review 1. List the different header compression methods than can be used. 2. Where are header compression mechanisms most effective? 3. What type of traffic benefits most by using TCP Header Compression? 4. What type of traffic benefits most by using RTP Header Compression?
6-40
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Link Fragmentation and Interleaving Objectives This lesson describes the mechanism used to reduce the maximum size of PPP or Frame Relay frames. It also explains the interleaving of multiple frames of large packets with frames of small packets.
Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe Link Fragmentation and Interleaving (LFI)
n
Describe and configure Multilink PPP
n
Monitor and troubleshoot Multilink PPP
n
Describe and configure Frame Relay Fragmentation
n
Monitor and troubleshoot Frame Relay Fragmentation
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-41
Queuing and Serialization Delay 8ms
Empty Network
8ms
64 kbps Delay Variation Queuing Delay
Congested Network
8ms
184 ms
8ms
64 kbps
Problems: • Large delay due to slow link and MTU-sized packets • Jitter (variable delay) due to variable link utilization © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-49
When considering delay between two hops in a network, queuing delay in a router must be considered, because it may be comparable to, or even exceed the transmission delay on a line. In an empty network, an interactive or voice session experiences low or no queuing delay, because it does not compete with other applications on an interface output queue. Also, the small delay does not vary enough to produce considerable jitter on the receiving side. In a congested network, interactive data and voice applications compete in the router queue with other applications. Queuing mechanisms may prioritize voice traffic in the software queue, but the hardware queue (Tx ring) always uses a FIFO scheduling mechanism. Therefore, after packets of different applic ations leave the software queue, they will mix with other packets in the hardware queue, even if their software queue processing was expedited. Thus, a voice packet may be immediately sent to the hardware queue, where two large FTP packets may still be waiting for transmission. The voice packet must wait until the FTP packets are transmitted, thus producing a delay in the voice path. Because links are variably utilized, this delay varies with time and may produce unacceptable jitter in jitter-sensitive applications such as voice.
6-42
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Voice Reassembly Probability of arrival
Less delay More loss
Usable packets
More delay Less loss
Jitter
Unusable packets
Min. Delay
Avg. Delay
Delay
Playback Point (max. Acceptable Delay)
Jitter can be offset by more buffering More buffering causes even more delay which is not acceptable for two-way communication © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-49
Jitter can always be offset by more buffering on the receive side. However, more buffering produces more overall delay. This delay must not cross certain thresholds in delay-sensitive applications, such as packetized voice. The voice delay threshold (usually around 150 ms of one-way delay) represents the limit at which the quality of packetized voice telephony is still regarded as acceptable by end users.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-43
Voice Reassembly Probability of arrival
Less delay More loss
More delay Less loss
Usable packets
Jitter
Unusable packets
Min. Delay
Avg. Delay
Delay
Playback Point (max. Acceptable Delay)
The right solution is to reduce average delay © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-50
A better solution than adding additional buffering is to reduce the average delay along the packet path. This allows for more jitter before packets are deemed unusable by the voice reassembly on the receiving endpoint (IP telephone). Reduced average delay can be provided through link fragmentation and interleaving, by reducing delays on critical links in the packet path.
6-44
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Link Fragmentation and Interleaving Delay to large B2
A3
Fragmentation
A3
B1
A2
TxQ
A1
Interleaving
A3 A3 A3 A2 B3 A2 A2 A2 B2 A1 A1 A1 B1 A1
Reduce delay and jitter by fragmenting large frames and prioritizing small frames © 2001, Cisco Systems, Inc.
TxQ
Acceptable Delay
IP QoS Link Efficiency Mechanisms-52
Link fragmentation and interleaving (LFI) is a layer-2 technique, where all layer-2 frames are broken into small, equal-size fragments, and transmitted over the link in an interleaved fashion. The figure shows the interface hardware output queue, populated by frames of differing sizes; large and small. When fragmentation and interleaving is in effect, all frames waiting in the queuing system are fragmented, smaller frames are prioritized, and a mixture of fragments is sent over the link. Small frames may be scheduled behind larger frames in the WFQ system. LFI fragments all frames, and this reduces the queuing delay of small frames, as they are sent almost immediately. Link fragmentation therefore reduces delay and jitter by expediting transfer of smaller frames through the hardware queue.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-45
LFI with WFQ MTU=1500 WFQ
TxQ TxQ is sized in the number of packets
WFQ
TxQ MTU=1500, LFI MTU=160
Maximum delay caused by the TxQ is the number of packets multiplied by the time it takes to transmit the longest frame (usually MTU-sized)
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-52
The longest delay, used with the WFQ scheduling algorithm, is the product of the number of packets in the queue and the size of the maximum packet (to calculate the worst-case delay at any instant). Before LFI, the maximum possible size of a packet was limited by the interface MTU, which might be set to a value up to 1500 bytes on a serial line. LFI MTU is considerably smaller, because it reflects the maximum size of a fragment in a LFI implementation. For example, an LFI MTU of 160 bytes (which is commonly used) reduces the worst-case maximum delay to one tenth of the delay of a normal nonLFI-enabled link, because the next scheduled fragment now has to wait only until the previous fragment has been transmitted. Before using LFI, any packet had to wait until the whole previous frame has been transmitted, which might be up to the full MTU in size.
6-46
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Fragmentation Options Three types of LFI mechanisms are available: • Multilink PPP with Interleaving • FRF.11 Annex C specification for VoFR PVCs • FRF.12 specification for data PVCs
Using separate PVCs for voice and data can be used to interleave packets in ATM networks
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-53
There are three LFI mechanisms implemented in Cisco IOS: n
Multilink PPP with Interleaving is by far the most common and widely used form of LFI.
n
FRF.11 Annex C LFI is used with Voice over Frame Relay (VoFR).
n
FRF.12 Frame Relay LFI is used with Frame Relay data connections.
n
In an ATM network, using separate PVCs carrying voice and data can be used to interleave packets when they are output on an interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-47
Configuring MLP with Interleaving Configuration steps: • Enable Multilink PPP on an interface (using a Multilink Group interface) • Enable PPP Multilink interleaving on the Multilink interface • Specify maximum fragment size by setting the maximum delay on the Multilink interface
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-54
To configure Multilink PPP (MLP) with interleaving, the following configuration steps must be performed:
6-48
Step 1
First, enable multilink on an interface (using a multilink group interface).
Step 2
Second, in the multilink interface, enable interleaving within Multilink PPP.
Step 3
Third, in the multilink interface configuration, specify the maximum fragment size of MLP by specifying the maximum desired delay on the point-to-point link.
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring MLP with Interleaving Router(config-if)#
ppp multilink
• Enables Multilink PPP • Also requires WFQ or CB-WFQ to be enabled on the interface Router(config-if)#
ppp multilink interleave
• Enables interleaving of frames with fragments Router(config-if)#
ppp multilink multilink fragment-delay fragment-delay delay delay
• Configure maximum fragment delay in milliseconds • The router calculates the maximum fragment size from the bandwidth and the maximum fragment delay • Default is 30 ms © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-56
The ppp multilink command enables PPP multilink on an interface. This requires either Weighted Fair Queuing (WFQ) or CB-WFQ (Class-Based Weighted Fair Queuing) to be enabled on the same interface. The ppp multilink interleave command enables interleaving of fragments within the multilink connection. The ppp multilink fragment delay command specifies the maximum desired fragment delay for the interleaved multilink connection. The maximum fragment size is calculated from the interface bandwidth and the specified maximum delay. The default is set at 30 milliseconds. If dCEF is configured on a VIP interface, MLP with interleaving runs distributed on the VIP.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-49
MLP with Interleaving Example interface interface Multilink1 Multilink1 ip ip address 10.1.1.1 10.1.1.1 255.255.255.252 255.255.255.252 fair-queue fair-queue ppp ppp multilink multilink multilink-group multilink-group 1 ppp ppp multilink multilink fragment-delay 20 ppp ppp multilink multilink interleave interleave !! interface interface Serial0/0 Serial0/0 no no ip address address encapsulation encapsulation ppp ppp ppp multilink multilink multilink-group multilink-group 1 !!
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-56
The figure shows an example configuration of MLP with interleaving on a multilink group interface. A non-default maximum desired delay of 20 ms is configured.
6-50
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting MLP Interleaving Router# show interface interface [intf] [intf]
• Displays statistics including the number of interleaved frames Router #show interfaces Router#show interfaces multilink multilink 11 Multilink1 Multilink1 is is up, up, line line protocol protocol is is up up Hardware is multilink Hardware is multilink group group interface interface Internet Internet address address is is 172.22.130.1/30 172.22.130.1/30 MTU MTU 1500 1500 bytes, bytes, BW BW 64 64 Kbit, Kbit, DLY DLY 100000 100000 usec, usec, reliability reliability 255/255, 255/255, txload txload 27/255, 27/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation PPP, loopback loopback not not set set Keepalive set (10 sec) Keepalive set (10 sec) DTR DTR is is pulsed pulsed for 2 seconds on reset LCP LCP Open, Open, multilink multilink Open Open Open: Open: IPCP IPCP Last Last input input 00:00:03, 00:00:03, output output never, never, output output hang hang never never Last Last clearing clearing of "show interface" counters 6d00h Input Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 0/1000/64/0/2441 0/1000/64/0/2441 (size/max (size/max total/threshold/drops/interleaves) total/threshold/drops/interleaves) Conversations Conversations 0/7/16 0/7/16 (active/max (active/max active/max active/max total) total) Reserved Conversations 0/0 (allocated/max Reserved Conversations 0/0 (allocated/max allocated) allocated) 55 minute minute input input rate rate 00 bits/sec, bits/sec, 00 packets/sec packets/sec 55 minute minute output output rate rate 7000 7000 bits/sec, bits/sec, 66 packets/sec packets/sec © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-59
The show interface command output includes MLP statistics information and indicates whether MLP Interleaving is enabled on the interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-51
Monitoring and Troubleshooting MLP Interleaving Router# debug ppp multilink multilink fragments
• Displays information about individual multilink fragments and interleaving events Router#debug Router#debug ppp ppp multilink multilink fragments fragments Multilink Multilink fragments fragments debugging debugging is is on on Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar
17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17
20:03:08.995: -FS: II 20:03:08.995: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.015: -FS: II 20:03:09.015: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.035: -FS: II 20:03:09.035: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.075: Se0/0 MLP -FS: II 20:03:09.075: Se0/0 MLP-FS: 20:03:09.079: Se0/0 MLP -FS: II 20:03:09.079: Se0/0 MLP-FS: 20:03:09.091: -FS: II 20:03:09.091: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.099: -FS: II 20:03:09.099: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.103: 20:03:09.103: Mu1 Mu1 MLP: MLP: Packet Packet 20:03:09.107: Se0/0 MLP -FS: II 20:03:09.107: Se0/0 MLP-FS: 20:03:09.119: Se0/0 MLP -FS: 20:03:09.119: Se0/0 MLP-FS: II 20:03:09.123: 20:03:09.123: Mu1 Mu1 MLP: MLP: Packet Packet 20:03:09.131: 20:03:09.131: Mu1 Mu1 MLP: MLP: Packet Packet 20:03:09.135: -FS: II 20:03:09.135: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.155: Se0/0 MLP -FS: 20:03:09.155: Se0/0 MLP-FS: II
© 2001, Cisco Systems, Inc.
seq seq C0004264 C0004264 size size 70 70 seq seq 80004265 80004265 size size 160 160 seq seq 4266 4266 size size 160 160 seq 4267 size 160 seq 4267 size 160 seq seq 40004268 40004268 size size 54 54 seq seq C0004269 C0004269 size size 70 70 seq seq C000426A C000426A size size 70 70 interleaved interleaved from queue 24 seq C000426B size 70 seq C000426B size 70 seq seq C000426C C000426C size size 70 70 interleaved interleaved from queue 24 interleaved 24 interleaved from from queue queue 24 seq seq C000426D C000426D size size 70 70 seq C000426E size 70 seq C000426E size 70
IP QoS Link Efficiency Mechanisms-60
The debug ppp multilink fragments command is a valuable troubleshooting tool when monitoring MLP operations. The command outputs the result of every fragmentation operation, indicating whether the interleave operation fragments packets into correct-sized fragments. This command should be used with extreme caution in a production environment, because of the amount of output created.
6-52
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Frame Relay Fragmentation FRF.11 Annex C specifies fragmentation of voice frames (VoFR): • Only frames with data payload type are fragmented • Voice bypasses the fragmentation engine regardless of frame size
FRF.12 specifies fragmentation of data frames: • Data frames that exceed the specified fragmentation size are fragmented • Smaller time -sensitive packets can be interleaved • VoIP packets do not get a special treatment
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-61
In Frame Relay networks, two fragmentation standards are available on layer-2 (within the Frame Relay encapsulation): n
When Voice over Frame Relay (FRF.11) and fragmentation are both configured on a PVC, Frame Relay fragments are transmitted in the FRF.11 Annex C format. This fragmentation method is used when FRF.11 voice traffic is transmitted on the PVC and uses the FRF.11 Annex C fragmentation standard. With FRF.11, all data packets contain fragmentation headers regardless of size. This form of fragmentation is not recommended for use with Voice over IP.
n
FRF.12 fragmentation is defined by the FRF.12 Implementation Agreement. The FRF.12 Implementation Agreement was developed to allow long data frames to be fragmented into smaller pieces and interleaved with real-time frames. In this way, real-time voice and non-real-time data frames are carried together on lower-speed links without causing excessive delay to the real-time traffic. As a result, FRF.12 is the recommended fragmentation to be used with VoIP.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-53
FRF.12 versus FRF.11 Annex-C Fragmentation FRF.11 Annex-C Fragmentation
FRF.12 Fragmentation
Used on DLCIs configured for VoFR Does not fragment voice packets regardless of what fragmentation size is configured Must be supported by platforms that support VoFR
Used on DLCIs carrying data traffic only (including VoIP) Fragments voice packets if the fragmentation size parameter is set to a value smaller than the voice packet size Predominantly used for VoIP – Must be supported only by Cisco IOS platforms that transport VoIP over slow speed WAN links
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-61
If a PVC is not configured for VoFR, it uses normal Frame Relay (FRF.3.1) data encapsulation. If fragmentation is turned on for this DLCI, it uses FRF.12 for the fragmentation headers. PVCs carrying VoIP use FRF.12 fragmentation because VoIP is a layer 3 technology that is transparent to layer 2 Frame Relay. VoIP and VoFR can be supported on different PVCs on the same interface, but not on the same PVC. FRF.12 fragments voice packets if the fragmentation size parameter is set to a value smaller than the voice packet size. FRF.11 Annex-C (VoFR) does not fragment voice packets regardless of what fragmentation size is configured. FRF.11 Annex-C needs only to be supported by platforms that support VoFR. Because FRF.12 is predominantly used for VoIP, it is important to use FRF.12 as a general feature on Cisco IOS platforms that transport VoIP over slow speed WAN links.
6-54
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Implementation Notes When Frame Relay fragmentation is configured, the following conditions and restrictions apply: • WFQ at the PVC level is the only queuing strategy that can be used. • FRTS must be configured to enable FR fragmentation • VoFR frames are never fragmented, regardless of size. • When using FRF.12 fragmentation, the VoIP packets will not include the FRF.12 header, provided the size of the VoIP packet is smaller than the fragment size configured. However, when using FRF.11 Annex C or Cisco proprietary fragmentations, VoIP packets will include the fragmentation header. • If fragments arrive out of sequence, packets are dropped © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-62
When deploying a solution using Fragmentation and Interleaving on a Frame Relay backbone, it is a good idea to be aware of the following key issues: n
At the PVC level, WFQ is the only permitted queuing strategy when used together with Frame Relay fragmentation
n
Frame Relay Traffic Shaping must be enable d together with Frame Relay Fragmentation
n
If native voice over Frame Relay (VoFR) is used, its frames are never fragmented
n
In VoIP applications, FRF.11 Annex C adds an additional fragmentation header to packets, while FRF.12 does not
n
If the Frame Relay network delivers fragments out of sequence, fragments are dropped and a lost frame results.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-55
Configuring Frame Relay Fragmentation (FRF.11 C) Router(config)#
map-class frame-relay name
• Enter Map Class configuration mode Router(config-map-class)#
frame-relay fragment size
• Set the maximum fragment size Router(config-map-class)#
frame-relay voice voice bandwidth bandwidth bps
• Set aside an amount of bandwidth for FRF.11 voice traffic (VoFR) © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-64
FRF.11 Annex C fragmentation is configured within the Frame Relay map class. The frame-relay fragment command sets the maximum fragment size. The frame-relay voice bandwidth command reserves an amount of bandwidth used only for FRF.11-encapsulated VoFR traffic.
6-56
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Frame Relay Fragmentation (FRF.11 C) Router(config-if)# | (config-subif)# | (config-fr-dlci)#
frame-relay class name name
• Apply the Frame Relay Map Class to an interface, subinterface or DLCI Router(config-fr-dlci)#
vofr
• Enable FRF.11 encapsulation Router(config-map-class)#
service-policy output name
• Use distributed Class-based Low Latency Queuing on Cisco 7500 routers to prioritize VoFR frames • Traditional WFQ can be used on all other platforms © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-65
On an interface, the frame-relay class command applies the map class to the interface, subinterface, or a DLCI. The vofr interface command changes the encapsulation on a DLCI to support only FRF.11 VoFR traffic. The service-policy output command, used within a map class, applies a QoS policy to the frame relay traffic class. Low Latency Queuing (configured within CB-WFQ) is recommended on a VoFR circuit.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-57
Configuring Frame Relay Fragmentation (FRF.12) Router(config)#
map-class frame-relay name
• Enter Map Class configuration mode Router(config-map-class)#
frame-relay fragment size
• Set the maximum fragment size Router(config-if)# | (config-subif)# | (config-fr-dlci)#
frame-relay class name name
• Apply the Frame Relay Map Class to an interface or subinterface © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-66
FRF.11 Annex C fragmentation is also configured within the Frame Relay map class. The frame-relay fragment command sets the maximum fragment size. On an interface, the frame-relay class command applies the map class to the interface, sub-interface, or a DLCI.
6-58
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Frame Relay Fragmentation FRF.11 C Example interface interface serial serial 0/0 0/0 encapsulation frame-relay frame-relay frame-relay traffic shaping !! interface interface serial serial 0/0.1 0/0.1 point-to-point point-to-point frame-relay frame-relay interface-dlci interface-dlci 100 100 vofr class class FRF11 FRF11 !! map-class map-class frame-relay frame-relay FRF11 FRF11 frame-relay frame-relay fragment fragment 160 160 frame-relay frame-relay cir cir 65536 65536 frame-relay frame-relay bc bc 2600 2600 frame-relay frame-relay fair-queue fair-queue !!
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-67
The figure shows a configuration example where FRF.11 Annex C fragmentation is applied to a VoFR circuit configured on the Serial0/0.1 interface. The maximum fragment size is set to 160 bytes.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-59
Frame Relay Fragmentation FRF.12 Example interface interface serial serial 0/0 0/0 encapsulation frame-relay frame-relay frame-relay traffic shaping !! interface interface serial serial 0/0.1 0/0.1 point-to-point point-to-point frame-relay frame-relay interface-dlci interface-dlci 100 100 class class FRF12 FRF12 !! map-class map-class frame-relay FRF12 frame-relay frame-relay fragment fragment 160 160 frame-relay frame-relay cir cir 65536 65536 frame-relay frame-relay bc bc 2600 2600 frame-relay frame-relay fair-queue fair-queue !!
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-68
The figure shows a configuration example where FRF.12 fragmentation is applied to a data Frame Relay circuit configured on the Serial0/0.1 interface. The maximum fragment size is also set to 160 bytes. This would be used in a VoIP over Frame Relay environment.
6-60
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting Frame Relay Fragmentation Router# show frame-relay pvc pvc [interface intf] [dlci]
• Displayst PVC parameters and statistics
The following values are possible: • VoFR – FRF.11 Annex C Relay DTE) • VoFR-cisco – Cisco Relay DTE) proprietary fragmentation STATIC, STATIC, INTERFACE INTERFACE• =end-to-end = Serial1 Serial1– FRF.12 fragmentation in in bytes bytes 1730 1730 in in FECN FECN pkts pkts 00 out out BECN BECN pkts pkts 00
Router# -relay pvc Router# show show frame frame-relay pvc interface interface serial serial 1 45 PVC PVC Statistics Statistics for for interface interface Serial1 Serial1 (Frame (Frame DLCI DLCI == 45, 45, DLCI DLCI USAGE USAGE == LOCAL, LOCAL, PVC PVC STATUS STATUS ==
input output input pkts pkts 85 85 output pkts pkts 289 289 out dropped out bytes bytes 6580 6580 dropped pkts pkts 11 11 in out in BECN BECN pkts pkts 00 out FECN FECN pkts pkts 00 in out in DE DE pkts pkts 00 out DE DE pkts pkts 00 out out out bcast bcast pkts pkts 00 out bcast bcast bytes bytes 00 pvc pvc create create time time 00:02:09, 00:02:09, last last time time pvc pvc status status changed changed 00:02:09 00:02:09 Service type VoFR Service type VoFR configured configured voice voice bandwidth bandwidth 25000, 25000, used used voice voice bandwidth bandwidth 22000 22000 fragment fragment fragment type type VoFR VoFR fragment size size 100 100 cir bc 1000 be limit 125 interval cir 20000 20000 bc 1000 be 00 interval 50 50 mincir 20000 byte increment 125 BECN mincir 20000 byte increment 125 BECN response response no no fragments 290 bytes 6613 fragments delayed 1 bytes fragments 290 bytes 6613 fragments delayed 1 bytes delayed delayed 33 33 shaping shaping inactive inactive ... ... © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-69
The show frame -relay pvc command output includes settings related to either FRF.11 Annex C or FRF.12 fragmentation. The output shows the fragment size used on the Frame Relay PVC.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-61
Monitoring and Troubleshooting Frame Relay Fragmentation Router# show frame-relay fragment fragment [interface intf] [dlci]
• Displayst PVC parameters and statistics Router#show Router#show frame-relay frame-relay fragment fragment interface dlci interface dlci frag-type frag-type Serial0 108 VoFR-cisco Serial0 108 VoFR-cisco Serial0 109 VoFR Serial0 109 VoFR Serial0 110 end-to-end Serial0 110 end-to-end
frag-size frag-size 100 100 100 100 100 100
in-frag in-frag 1261 0 0 0
out-frag out-frag 1298 243 0 0
dropped-frag dropped-frag 0 0 0 0
Router#show Router#show frame-relay frame-relay fragment fragment interface interface Serial1/0 Serial1/0 fragment-size fragment fragment-size 45 45 fragment type type end-to-end end-to-end in out in fragmented fragmented pkts pkts 00 out fragmented fragmented pkts pkts 00 in out in fragmented fragmented bytes bytes 0 0 out fragmented fragmented bytes bytes 00 in out -fragmented pkts in un-fragmented un-fragmented pkts pkts 00 out un un-fragmented pkts 00 in un-fragmented bytes 0 out un -fragmented in un-fragmented bytes 0 out un-fragmented bytes bytes 0 0 in out in assembled assembled pkts pkts 00 out pre-fragmented pre-fragmented pkts pkts 00 in out in assembled assembled bytes 0 out pre-fragmented pre-fragmented bytes bytes in out in dropped reassembling pkts pkts 00 out dropped dropped fragmenting fragmenting pkts pkts 00 in in timeouts timeouts 0 in out-of-sequence fragments 0 in out -of-sequence fragments 0 in in fragments fragments with with unexpected unexpected BB bit bit set set 00 out out interleaved interleaved packets packets 00
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-70
The show frame -relay fragment command displays statistics of Frame Relay fragmentation methods. This output shows whether Frame Relay fragmentation is in effect and working as configured. The output also shows possible fragmentation timeouts, indicating that some fragments were lost in the Frame Relay network and could not be reassembled. If the number of timeouts is significant, this may indicate significant frame loss in the Frame Relay network.
6-62
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Summary n
Link fragmentation and interleaving methods reduce the average delay on a transmission line by fragmenting frames into small fragments and scheduling their transfer in an interleaved fashion
n
Multilink PPP with Interleaving is the preferred LFI method, used with the PPP protocol
n
FRF.11 C and FRF.12 are the preferred LFI methods, used in a Frame Relay environment
n
Multilink PPP with Interleaving, FRF.11 C, and FRF.12 methods are available in Cisco IOS
Lesson Review 1. List the different link fragmentation methods that can be used. 2. What mechanism is needed to implement link fragmentation with PPP encapsulation? 3. What are the differences between different Frame Relay link fragmentation mechanisms?
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-63
Summary
6-64
n
Stacker and MPPC payload compression methods yield better compression ratios, is more CPU-intensive, and may introduce additional delay
n
The Predictor payload compression is faster, can be used in higher-bandwidth scenarios, but generally yields lower average compression ratios
n
TCP header compression optimizes performance of interactive TCP-based applications on slow links, by shrinking IP and TCP headers to 3-5 byte indices
n
RTP header compression optimizes performance of delay-sensitive RTP-based applications, such as voice, on slow links, by shrinking IP, UDP, and RTP headers to 3-5 byte indices
n
Multilink PPP with Interleaving is the preferred LFI method, used with the PPP protocol
n
FRF.11 C and FRF.12 are the preferred LFI methods, used in a Frame Relay environment
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Payload Compression Question: What is the purpose of using payload compression? Answer: The purpose of payload compression is primarily to increase throughput of a link, and secondarily, to decrease propagation delay on a link. Question: List the payload compression algorithms than can be used. Answer: Cisco IOS supports Stacker, predictor, and MPPC algorithms to compress Layer-2 link data. Question: What are some of the benefits and drawbacks of Stacker? Answer: Stacker provides good compression ratios with most types of traffic and works on most Layer-2 encapsulations. On the downside, Stacker is very CPU intensive and may have throughput limitations and increase processing delay. Question: What are some of the benefits and drawbacks of Predictor? Answer: Predictor is very fast and works well on text-type traffic. Predictor does not yield very good compression ratios with all types of traffic, and supports only select encapsulations.
Header Compression List the different header compression methods than can be used. Where are header compression mechanisms most effective? What type of traffic benefits most by using TCP Header Compression? What type of traffic benefits most by using RTP Header Compression?
Link Fragmentation and Interleaving Question: List the different link fragmentation methods that can be used. Answer: Cisco IOS supports TCP and RTP header compression. Question: What mechanism is needed to implement link fragmentation with PPP encapsulation? Answer: PPP link fragmentation is implemented with PPP Multilink with Interleaving. Question: What are the differences between different Frame Relay link fragmentation mechanisms?
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-65
Answer: The FRF.11 Annex C method is used only to fragment Voice over Frame Relay (VoFR). The FRF.12 method is used only to fragment data over Frame Relay, including Voice over IP.
6-66
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
7
Signaling Mechanism
Overview The module describes RSVP as the signaling mechanism used in QoS enabled networks. The module builds on knowledge about the IntServ model with the addition of Common Open Policy Service (COPS) discussed in the introductory module.
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe Resource Reservation Protocol (RSVP).
n
Configure RSVP.
n
Describe and configure RSVP on shared media using Subnet Bandwidth Management (SBM).
n
Monitor and troubleshoot RSVP.
Resource Reservation Protocol (RSVP) Overview The section introduces Resource Reservation Protocol (RSVP) as the signaling mechanism in QoS-enabled networks using the Integrated Services model.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
7-2
n
Describe Resource Reservation Protocol (RSVP).
n
Configure RSVP.
n
Monitor and troubleshoot RSVP.
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Resource Reservation Protocol • RSVP is a protocol used to reserve resources in a path between a source and a destination • RSVP signals all network devices that a certain application needs certain QoS guarantees • RSVP requires applications to initiate the request • RSVP by itself does not provide any guarantees • An RSVP-interoperable QoS mechanism (WFQ, CBWFQ) must be used to implement guarantees according to RSVP reservations
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-5
RSVP is an Internet Engineering Task Force (IETF) signaling protocol, used to reserve bandwidth in a path between a source and a destination. In RSVP, the end-node (the application node) station reserves bandwidth for a flow along its path to a destination in a network. The user can supply the information about how much capacity to reserve. RSVP mechanisms enable real-time traffic to reserve bandwidth necessary for consistent latency. A video conferencing application can use settings in the router to propagate a request for a path with the required bandwidth and delay for video conferencing destinations. RSVP then signals all network devices along the path, and confirms or rejects the reservation. RSVP will check and repeat reservations at regular intervals. When RSVP is used, the routers sort and prioritize packets much as a statistical time-division multiplexer would sort and prioritize several signal sources that share a single channel. RSVP requires RSVP-aware applications, as signaling is performed by the endnode. In addition, RSVP does not provide any guarantees by itself. RSVP is the protocol used to communicate QoS requirements between the end-node and the layer-3 network, assessing the ability or inability of the network to support the requested level of service. RSVP is the signaling protocol underlying the IntServ QoS reference model. Together with appropriate QoS-enforcing mechanisms in the network, such as WFQ, it forms a foundation for implementation of IntServ-based services.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-3
End-to-end RSVP Local Admission Control
Local Admission Control request
reserve
request
reserve
Local Admission Control request
reserve
request
reserve
• All network devices have to be enabled for RSVP • Each network device determines whether it has enough resources
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-6
If end-to-end RSVP is desired in a network, all devices in the reservation path must be RSVP-enabled. When a device receives an RSVP message, it determines whether it has enough resources to satisfy the reservation request at the local level. There are two main RSVP messages used for signaling. When a reservation is needed, the sending client sends an RSVP PATH message into the network requesting a specific bandwidth to a specific destination (or multicast address, in the case of IP multicast application). The purpose of the PATH message is to discover all RSVP-enabled routers along the path from the sender to the receiver, and to create initial reservations. The PATH message is forwarded along the flow path and every intermediate RSVP-capable router adds its identification to the PATH message. When the receiving end-node receives the PATH message, it confirms the reservation by replying with an RSVP RESV message. The RESV message is forwarded back upstream towards the initial sender using the list of RSVP-enabled routers generated by the PATH message. If the RESV message successfully arrives at the initial sender, each hop in the end-to-end connection has reserved the appropriate resources and an end-to-end reservation is established. If the appropriate resources are not available, the reservation is refused and the application must default to traditional, best effort communications. RSVP keeps track of the soft state of reservations in routers. This soft state provides dynamic membership information, adapts to routing changes, and, as the number of flows increases, enables dynamic changes in reservations to meet those changing needs. RSVP reservations time out unless periodically refreshed by the communication endpoint, usually at 30-second intervals. The benefits of soft state behavior are:
7-4
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
n
Connectionless behavior − routers automatically adapt to route changes.
n
Timeliness − state changes propagate immediately, but only as far as needed.
n
n
Robustness − the method is self-correcting, because incorrect reservations will always time-out even in the most unexpected situations. Flexibility − provides easy dynamic reservation changes.
The cost of this approach is that it requires ongoing refresh processing for established states by the endpoints.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-5
Pass-through RSVP Local Admission Control
Local Admission Control request
reserve
Local Admission Control
request request
RSVP not enabled
reserve
request
request
reserve
reserve
reserve
Best-effort forwarding
• Part of the network may not support RSVP • Best-effort delivery is used in those parts
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-7
When a part of the network does not support RSVP, that is, when the RSVP messages are not processed by every intermediate hop between the two application endpoints, some other mechanism may be employed to try to meet the application requirements in the non-RSVP-enabled part of the network. One such possibility may be to perform only best-effort delivery between RSVP-enabled networks using an undersubscribed network in between. The PATH messages discover all RSVP-aware routers, and are forwarded as plain IP packets on nonRSVP-enabled hops. The RESV messages are then interpreted only by the RSVPaware hops, discovered via the PATH message.
7-6
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Pass-through RSVP with Class of Service Local Admission Control
Local Admission Control request
reserve
Local Admission Control
request request
RSVP not enabled
reserve
request
request
reserve
reserve
reserve
Mark RSVP flow with DSCP
Class-based guarantee
• Part of the network may not support RSVP • Mark RSVP flows with a Class-of-service marker (e.g. IP precedence or DSCP) • Make sure the core provides guarantees to the RSVP class © 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-8
Another option may be to apply class-of-service based delivery on a non-RSVPenabled part of the network. In that case, RSVP-based application traffic is marked with appropriate class markers (IP precedence or DSCP bits) at the entry to the non-RSVP-enabled part. The core network can then be engineered to provide special service to the RSVP class, using, for example, WFQ and WRED. IP precedence and DSCP are packet markers, located in the ToS byte of the IP header, which identify traffic classes on each hop in the network. IP precedence or DSCP bits are usually set at the network edge, where traffic is classified and marked, and the markers used to identify traffic classes in downstream network devices. Each device along the path may apply appropriate QoS mechanisms based on the packet marker, resulting in differentiated per-hop behaviour (PHB) for each class of traffic. The DiffServ model defines several standard PHBs, based on marking traffic with the DSCP header bits.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-7
RSVP Applications • RSVP is used for applications where bandwidth and delay related guarantees are necessary • Typical applications are: – Voice over IP (Cisco phones, Microsoft NetMeeting, ...) – MPLS Traffic Engineering
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-9
RSVP allows end systems to request QoS guarantees from the network. The need for network resource reservations differs for data traffic versus real-time traffic, as described in the following paragraphs: n
Data traffic seldom needs reserved bandwidth because internetworks provide datagram services for data traffic. This asynchronous packet switching may not need guarantees of service quality. End-to-end controls between data traffic senders and receivers help ensure adequate transmission of bursts of information.
n
Real-time traffic (that is, voice or video information) experiences problems when using datagram services. Because real-time traffic sends an almost constant flow of information, the network “pipes” must be consistent. Some guarantee must be provided that service between real-time hosts will not vary. Routers operating on a first-in, first-out (FIFO) basis risk unrecoverable disruption of the real-time information that is being sent.
Many network-aware applications today use RSVP for signaling. Some wellknown examples include Cisco IP telephones, Microsoft NetMeeting, and MPLS Traffic Engineering.
7-8
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Configuring Simple RSVP Router(config-if)#
ip rsvp rsvp bandwidth bandwidth [total-BW [per-flow-BW]]
• Set the amount of reservable bandwidth (total-BW) and the maximum per-flow reservable bandwidth (per-flow-BW) in kbps • Both default to 75% of the configured bandwidth • Total reservable bandwidth cannot exceed 75% of the configured bandwidth Router(config-if)#
bandwidth bandwidth
• Set the interface bandwidth in kbps • This value should reflect the real bandwidth of the link
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-10
Basic RSVP is configured by two interface commands. The ip rsvp bandwidth command sets the maximum total amount of reservable bandwidth on an interface. By default, it is configured to 75% of the configured bandwidth, which is also its maximum allowed value. A per-flow reservable bandwidth can also be configured, setting the maximum bandwidth a single flow can reserve over this interface. By default, it is also set to 75% of the configured bandwidth. Note
RSVP cannot be configured with VIP-distributed Cisco Express Forwarding (dCEF).
The bandwidth interface command sets the interface bandwidth and is used by routing protocols (to calculate costs) and by a variety of QoS mechanisms. With RSVP, this is used as the configured bandwidth parameter, referenced by the limits in the ip rsvp bandwidth command.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-9
Configuring Proxy RSVP Router(config)# ip ip rsvp rsvp sender sender session-IP sender-IP sender-IP protocol protocol dport dport sport sport src-hopsrc-hopIP IP src-intf bandwidth burst
• Simulates a host sending a PATH message • Generates a PATH message on behalf of a host or an application Router(config)# ip ip rsvp reservation reservation session-IP sender-IP protocol dport sport next-hop-IP next-hop-intf {ff {ff | se | wf} {rate | load} bw burst
• Simulates a host sending a RESV message • Generates a RESV message on behalf of a host or an application © 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-11
RSVP typically requires both host and network implementations, although Cisco IOS software provides an RSVP command line interface that allows you to statically set up RSVP reservations without host involvement. Use the ip rsvp sender command to make the router simulate that it is receiving RSVP PATH messages from an upstream host. The command can be used to proxy RSVP PATH messages for non-RSVP-capable senders. By including a local (loopback) previous hop address and previous hop interface, you can also use this command to proxy RSVP for the router you are configuring. To enable a router to simulate receiving and forwarding Resource Reservation Protocol (RSVP) RESV messages, use the ip rsvp reservation global configuration command. To disable this feature, use the no form of this command. Use this command to make the router simulate receiving RSVP RESV messages from a downstream host. This command can be used to proxy RSVP RESV messages for non-RSVP-capable receivers. By giving a local (loopback) next hop address and next hop interface, you can also use this command to proxy RSVP for the router you are configuring. Several different reservation types can be specified. For detailed reservation settings, consult the Cisco IOS documentation.
7-10
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
RSVP Admission Control • RSVP has two tasks: – Determine if there are enough available resources – Determine if the application in question is allowed access to these resources
• RSVP-enabled devices keep track of existing reservations locally • RSVP-enabled devices can offload the authorization part of admission control to central servers (COPS)
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-12
A RSVP-enabled router therefore needs to perform two tasks: n
The router needs to determine whether there are currently available resources, which can be used to satisfy the reservation request.
n
The router needs to be able to authorize an application to make the reservation request (admission control).
The first task can be performed by keeping track of existing reservations, and of total reservable capacity locally on each device. If a reservation request exceeds the locally available reservable resources, the reservation request is denied. Authorization of reservations could be performed locally, but such an approach would not scale to more than a few devices. Fortunately, there is a standardized, centralized framework for policy networking, which includes authorization within admission control. This framework is based on a set of services and protocols called the Common Open Policy Service (COPS).
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-11
Common Open Policy Service Local Admission Control request
request
reserve
Policy Enforcement Point (PEP) request
reserve
Local Admission Control request
reserve
reply
request
reserve
Remote Admission Control
Policy Decision Point (PDP)
• COPS allows a more centralized approach to building RSVP enabled networks (more scalable) • COPS provides additional control over who can reserve what © 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-13
Common Open Policy Service (COPS) is an open framework designed for management in policy networking. COPS provides a service to network devices and implements management protocols, which enable scalable provisioning of Quality of Service policies in a network. COPS is designed so that it provides a centrally managed, but distributed system for configuring network devices according to centralized policy decisions. In the case of RSVP, COPS provides centralized databases, which network devices query for reservation/admission control information. RSVP-enabled devices therefore need no locally stored configuration, but receive this information in realtime from the appropriate COPS server. COPS, therefore, scales QoS provisioning, and enables a device-independent QoS policy throughout the network. COPS defines the following types of policy services:
7-12
n
The Policy Enforcement Point (PEP) is the device that enforces network policy (a router performing RSVP admission control, a firewall filtering traffic).
n
The Policy Decision Point (PDP) is the device that stores policy information and makes it available to the PEP devices.
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Configuring RSVP for COPS ip rsvp policy local acl Process Locally?
ip rsvp policy local
Yes
Yes
Reject?
No
Reject Message Send an error message to the source
No ip rsvp policy local local-override
Default Local Policy?
Yes
Local Override?
No
No
Process Remotely?
Ask PDP
No
Default Remote Policy? No © 2001, Cisco Systems, Inc.
Yes
Reject?
Yes
No
Yes
Process Message Default Reject?
Yes
No IP QoS Signaling Mechanism-14
The figure shows the flowchart used to consult either the local policy settings, or the COPS service. Both the local policy and the COPS service can be used simultaneously on the same router. Individual COPS commands are also presented in the flowchart, next to the functions they enable. The admission process in policy networking proceeds as follows for locally processed messages: n
The router receives a PATH or RESV message and first tries to adjudicate it locally (that is, without referring to the policy server). If the router has been configured to adjudicate specific access control lists (ACLs) locally and the message matches one of those lists, the policy module of the router applies the operators with which it had been configured. Otherwise, policy processing continues.
n
For each message rejected by the operators, the router sends an error message to the sender and removes the PATH or RESV message from the database. If the message is not rejected, policy processing continues.
n
If the local override flag is set for this entry, the message is immediately accepted with the specified policy operators. Otherwise, policy processing continues.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-13
Configuring RSVP for COPS (cont.) Process Locally?
Yes
Reject?
No
Default Local Policy?
Yes
No
Yes
Local Override?
No ip rsvp policy cops acl servers
Yes
No
Process Remotely?
Ask PDP
No
Reject?
Yes
No
ip rsvp policy cops servers Default Remote Policy? No © 2001, Cisco Systems, Inc.
Reject Message Send an error message to the source
Yes
Process Message Default Reject? No
Yes ip rsvp policy default-reject
IP QoS Signaling Mechanism-15
If policy decisions are offloaded to a policy server, policy processing continues as follows: n
If the message does not match any ACL configured for local policy, the router applies the default local policy. However, if no default local policy has been configured, the message is directed toward remote policy processing.
n
If the router has been configured with specific ACLs against specific policy servers (more specifically, PDPs), and the message matches one of these ACLs, the router sends that message to the specific PDP for adjudication. Otherwise, policy processing continues.
n
If the PDP specifies a “reject” decision, the message is discarded and an error message is sent back to the sender, indicating this condition. If the PDP specifies an “accept” decision, the message is accepted and processed using normal RSVP processing rules.
n
If the message does not match any ACL configured for specific PDPs, the router applies the default PDP configuration. If a default COPS configuration has been entered, policy processing continues. Otherwise, the message is considered to be unmatched.
n
If the default policy decision for unmatched messages is to reject, the message is immediately discarded and an ERROR message is sent to the sender indicating this condition. Otherwise, the message is accepted and processed using normal RSVP processing rules.
Whenever a request for adjudication (of any sort) is sent to a PDP, a 30-second timer associated with the PATH or RESV message is started. If the timer runs out
7-14
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
before the PDP replies to the request, the PDP is assumed to be down and the request is given to the default policy.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-15
RSVP Example interface Serial0/0 bandwidth 128 ip address 10.10.3.33 255.255.255.252 encapsulation ppp fair-queue 64 256 10 ip rtp header-compression ip rsvp bandwidth 80
interface Serial0/0 bandwidth 256 ip address 10.5.8.65 255.255.255.252 encapsulation ppp fair-queue 64 256 20 ip rtp header-compression ip rsvp bandwidth 160
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-15
The figure shows a basic example of RSVP configuration in Cisco IOS routers. The two routers in the figure are both configured for RSVP, and both utilize WFQ to guarantee bandwidth to RSVP flows in RSVP-reserved queues. Different maximum reservable bandwidths are allocated, based on the real bandwidth of the link.
7-16
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
RSVP with COPS Example COPS (PEP)
COPS (PDP)
interface Serial0/0 bandwidth 2048 ip address 10.1.1.1 255.255.255.252 encapsulation ppp fair-queue 64 256 100 ip rsvp bandwidth 512 ! ip rsvp policy cops 100 servers 10.100.1.1 10.101.1.1 ip rsvp policy default-reject ip rsvp policy cops minimal ip rsvp policy cops timeout 600 ip rsvp policy cops report-all ! access-list 100 permit udp any any
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-16
This figure shows a COPS-enabled RSVP configuration. The RSVP interface configuration does not change, and COPS parameters are defined with the ip rsvp policy commands. In this example, the COPS PDP adjudicates all UDP traffic reservations.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-17
Monitoring and Troubleshooting RSVP Router#
show ip rsvp installed [detail]
• Lists installed reservations per interface Router#show Router#show ip ip rsvp rsvp installed installed RSVP:Ethernet2/1 RSVP:Ethernet2/1 BPS To From Protoc BPS To From Protoc Conversation Conversation 44K 145.20.0.202 145.10.0.201 UDP 44K 145.20.0.202 145.10.0.201 44K 145.20.0.202 145.10.0.201 UDP 44K 145.20.0.202 145.10.0.201 98K 145.20.0.202 145.10.0.201 UDP 98K 145.20.0.202 145.10.0.201 UDP 1K 145.20.0.202 145.10.0.201 UDP 1K 145.20.0.202 145.10.0.201 UDP RSVP:Serial3/0 RSVP:Serial3/0 has has no no installed installed reservations reservations
© 2001, Cisco Systems, Inc.
DPort DPort Sport Sport
Weight
1000 1001 1001 1002 1002 10 10
0 13 13 6 6 00
1000 1001 1001 1002 1002 10 10
264 264 266 266 265 265 264 264
IP QoS Signaling Mechanism-17
The show ip rsvp installed command shows all active conversations over an RSVP-enabled path, which has resource reservations installed. The actual reserved bandwidth is shown, along with the session parameters (endpoints and applications).
7-18
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting RSVP Router#
show ip rsvp installed [detail] [interface] Router#show Router#show ip ip rsvp rsvp installed installed detail detail RSVP:Ethernet2/1 RSVP:Ethernet2/1 has has the the following following installed installed reservations reservations RSVP RSVP Reservation. Reservation. Destination Destination is is 145.20.0.202, 145.20.0.202, Source Source is is 145.10.0.201, 145.10.0.201, Protocol Protocol is is UDP, UDP, Destination Destination port port is is 1000, 1000, Source Source port port is is 1000 1000 Reserved Reserved bandwidth:44K bandwidth:44K bits/sec, bits/sec, Maximum Maximum burst:1K burst:1K bytes, bytes, Peak Peak rate: rate: 44K 44K bits/sec bits/sec QoS 0 (PQ) QoS provider provider for for this this flow:WFQ. flow:WFQ. Conversation Conversation number:264. number:264. Weight: Weight:0 (PQ) Conversation supports 1 reservations Conversation supports 1 reservations Data Data given given reserved reserved service:316 service:316 packets packets (15800 (15800 bytes) bytes) Data Data given given best-effort best-effort service:0 service:0 packets packets (0 (0 bytes) bytes) Reserved Reserved traffic traffic classified classified for for 104 104 seconds seconds Long-term Long-term average average bitrate bitrate (bits/sec):1212 (bits/sec):1212 reserved, reserved, 0M 0M best-effort best-effort RSVP Reservation. Destination is 145.20.0.202, RSVP Reservation. Destination is 145.20.0.202, Source Source is is 145.10.0.201, 145.10.0.201, Protocol Protocol is is UDP, UDP, Destination Destination port port is is 1001, 1001, Source Source port port is is 1001 1001 Reserved Reserved bandwidth:44K bandwidth:44K bits/sec, bits/sec, Maximum Maximum burst:3K burst:3K bytes, bytes, Peak Peak rate: rate: 44K 44K bits/sec bits/sec QoS 13 QoS provider provider for for this this flow:WFQ. flow:WFQ. Conversation Conversation number:266. number:266. Weight: Weight:13 Conversation Conversation supports 1 reservations Data Data given given reserved reserved service:9 service:9 packets packets (450 (450 bytes) bytes) Data Data given given best-effort best-effort service:0 service:0 packets packets (0 (0 bytes) bytes) Reserved Reserved traffic traffic classified classified for for 107 107 seconds seconds Long-term Long-term average average bitrate bitrate (bits/sec):33 (bits/sec):33 reserved, reserved, 0M 0M best-effort best-effort ... ... © 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-18
The show ip rsvp installed detail command shows detailed information about active conversations currently installe d in the RSVP reservation table. Detailed timing and accounting for every conversation is displayed, together with the QoS mechanism used to provide service guarantees.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-19
Monitoring and Troubleshooting RSVP Router(config)#
show ip rsvp reservation [detail]
• List RSVP reservations
Router(config)#
show ip rsvp request [detail]
• List pending RSVP requests
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-19
The show ip rsvp reservation command lists all existing RSVP reservations over an interface. The show ip rsvp request command shows all pending RSVP requests that have no fixed reservation in place.
7-20
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting RSVP with COPS Router#
show ip rsvp policy [{cops | local} [acl]]
• Lists all policies Router#show Router#show ip ip rsvp rsvp policy policy cops cops COPS/RSVP COPS/RSVP settings: settings: Generate Generate reports for all decisions Do Do not not query query PDP PDP for for error error messages messages COPS/RSVP COPS/RSVP entry. entry. ACLs: ACLs: 100 100 PDPs: 10.100.1.1 10.101.1.1 PDPs: 10.100.1.1 10.101.1.1 Current Current state: state: Connected Connected Currently Currently connected connected to to PDP PDP 10.100.1.1, 10.100.1.1, port port 00 COPS/RSVP COPS/RSVP entry. entry. ACLs: ACLs: 101 101 PDPs: PDPs: 10.102.1.1 10.102.1.1 Current Current state: state: In In reconnect reconnect loop loop wait wait Reconnect Reconnect timer timer is is 960 960 seconds seconds
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-20
The show ip rsvp policy command shows the policy settings, whether the policy is locally defined or policy decisions are offloaded to the COPS server. The output shows associations between flow specifications and associated COPS servers, which perform admission control for those flows. This command is used to verify connectivity to COPS services and the associations between the local device and a COPS server.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-21
Monitoring and Troubleshooting RSVP with COPS Router#
show cops servers
• Lists all COPS servers Router#show Router#show cops cops servers servers COPS COPS SERVER: SERVER: Address: Address: 10.100.1.1. 10.100.1.1 . Port: Port: 3288. 3288. State: 0. Keepalive: 120 sec Number Number of of clients: clients: 1. 1. Number Number of of sessions: sessions: 1. 1. COPS COPS CLIENT: CLIENT: Client Client type: type: 1. 1.
© 2001, Cisco Systems, Inc.
State: State: 0. 0.
IP QoS Signaling Mechanism-21
The show cops servers command displays the state of all configured COPS servers.
7-22
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Summary n
RSVP enables end-stations to signal QoS requirements to the network.
n
RSVP does not provide any guarantees; router QoS mechanisms do.
n
RSVP does not necessarily require an end-to-end RSVP-aware path.
n
COPS provides scalable QoS provisioning.
Lesson Review 1. What is RSVP used for? 2. Does RSVP provide QoS guarantees? 3. What QoS mechanism should be used to provide QoS guarantees to RSVP reservations? 4. What are the benefits of using COPS with RSVP?
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-23
Subnet Bandwidth Management Overview This section describes a mechanism that is used on shared media where more complex reservation is required. SBM protocol is used between RSVP devices reachable over the same subnet.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
7-24
n
Describe Subnet Bandwidth Management (SBM).
n
Configure SBM.
n
Monitor and troubleshoot RSVP with SBM.
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Subnet Bandwidth Management • RSVP manages unidirectional reservation of resources • RSVP on shared media can result in oversubscription • SBM is an add-on to RSVP on shared media to prevent oversubscription
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-26
RSVP is used to manage reservation of resources unidirectionally, between Layer3 hops. On a shared medium, many Layer-3 hops can be active between many routers on the shared segment. The shared medium is shared between all routers, therefore the routers need to keep track about all routers’ usage of the shared medium, in order to maintain a consistent picture of available bandwidth on that medium. If routers were independently reserving bandwidth over a shared medium, oversubscription would occur if each router had full access to the medium bandwidth. Subnet Bandwidth Management (SBM) is an add-on to the RSVP protocol, which provides arbitration of bandwidth allocation on a shared medium to prevent RSVPcaused oversubscription. SBM specifies a signaling method and protocol for LANbased admission control for RSVP flows. SBM allows RSVP-enabled routers and Layer 2 and Layer 3 devices to support reservation of LAN resources for RSVPenabled data flows. The SBM signaling method is similar to that of RSVP itself.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-25
Without SBM Ethernet bandwidth 10Mbps 7.5 Mbps is reservable
Reserve 6 Mbps
Mbps rve 6 e s e R 6 Mbps booked 0 7.5 Mbps free 1.5
Ethernet Reserv e 7 Mb ps
Reserve 7 Mbps 7 Mbps booked 0 7.5 Mbps 512 kbps free
• Both routers are within the 75% reservable limit • Total reserved bandwidth is 13 Mbps (above Ethernet bandwidth) • Ethernet should be treated carefully because it is impossible to achieve 100% utilization (collisions; depending on implementation)
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-27
The figure shows a possible scenario of RSVP oversubscription on a shared segment. Both right-hand routers think of the Ethernet segment as a link with a bandwidth of 10 Mbps. Based on the 75% rule, by default 7.5 Mbps of that bandwidth is reservable. The upper router reserves 6 Mbps of the reservable bandwidth, and the bottom router reserves 7 Mbps of the reservable bandwidth. Obviously, the combined reserved bandwidth exceeds the Ethernet media bandwidth and results in an unwanted oversubscription.
7-26
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
With SBM
Reserve 6 Mbps Reserve 6 Mbps
e erv Res
bps 6M
6 Mbps booked 0 7.5 Mbps free 1.5 6 Mbps booked 0 7.5 Mbps free 1.5 One of the routers on the segment is elected to be the Designated Subnet Bandwidth Manager (DSBM) The shared media is effectively transformed into a star of point-to-point links
© 2001, Cisco Systems, Inc.
Re ser ve 6
Erro r
Mb ps
Reserve 7 Mbps 7 Mbps booked 0 7.5 Mbps 512 kbps free
IP QoS Signaling Mechanism-28
SBM’s solution to the problem is to introduce a Designated Subnet Bandwidth Manager (DSBM) router, which tracks all reservations over a shared segment. The DSBM is one of the existing subnet routers, designated to be the DSBM via an election process on the subnet. When a DSBM is used, the shared medium is effectively transformed into a virtual mesh of point-to-point links. When a DSBM client sends or forwards an RSVP PATH message over an interface attached to a managed segment, it sends the PATH message to the segment’s DSBM instead of to the RSVP session destination address, as is done in conventional RSVP processing. As part of its message processing procedure, the DSBM builds and maintains a PATH state for the session and notes the previous Layer 2/Layer 3 hop from which it received the PATH message. After processing the PATH message, the DSBM forwards it toward its destination address. n
The DSBM receives the RSVP reservation request (RSVP RESV) message and processes it in a manner similar to the way RSVP itself handles reservation request processing, basing the outcome on available bandwidth. The procedure is as follows:
n
If it cannot grant the request because of lack of resources, the DSBM returns a RESVERR message to the requester.
n
If sufficient resources are available and the DSBM can grant the reservation request, it forwards the RESV message toward the PHOP(s) using the local PATH state for the session.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-27
DSBM Election • DSBM is elected based on the DSBM priority • Each DSBM candidate advertises its priority in the range from 64 to 128 • The candidate with the highest priority is elected to be the DSBM • RSVP enabled devices can participate in Subnet Bandwidth Management without being DSBM candidates
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-29
On a LAN segment configured for SBM, a DSBM is elected based on each router’s DSBM-candidate priority. All RSVP messages of participating routers are sent to the DSBM to adjudicate the reservation requests. Such a LAN segment is called a managed segment in SBM terms. Of all SBM-enabled routers on a segment, some or all routers are DSBM candidates; that is, not all routers need to be configured as DSBM candidates to perform SBM-assisted RSVP. A DSBM is chosen among the candidates based on the configured DSBM priority, which ranges from 64 to 128, the latter being the highest priority.
7-28
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Configuring DSBM Router(config-if)#
ip rsvp dsbm candidate priority
• Configures the router to bid in the election of the DSBM • Default priority is 64
Router(config)#
ip rsvp rsvp dsbm dsbm non-resv-send-limit {burst | max-unit | minunit | peak | rate} value
• The NonResvSendLimit object specifies how much traffic can be sent onto a managed segment without a valid RSVP reservation • All values are unlimited by default
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-30
The ip rsvp dsbm candidate interface command specifies this router as a DSBM candidate on the attached LAN network. A priority used in the DSBM election process is assigned, the default being the lowest priority of 64. The ip rsvp dsbm non-resv-send-limit command limits the amount of traffic, which can be sent to a managed segment without an RSVP reservation. By default, any amount of traffic can be sent to the segment. This command should be used in a network, where RSVP is predominantly used for signaling to allow some non-RSVP traffic to transit shared LAN segments.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-29
SBM Example interface interface Ethernet0/0 Ethernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 ip ip rsvp rsvp bandwidth bandwidth 7500 7500 7500 7500 ip ip rsvp rsvp dsbm dsbm candidate 100 ip ip rsvp rsvp dsbm dsbm non-resv-send-limit rate 100 ip ip rsvp rsvp dsbm dsbm non-resv-send-limit non-resv-send-limit burst burst 1000 1000 ip ip rsvp rsvp dsbm dsbm non-resv-send-limit peak 100 !!
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-31
The figure shows an interface configuration example, where SBM is used to signal RSVP across a shared LAN segment. The local router is configured as a DSBM candidate, and RSVP with SBM is enabled using the ip rsvp bandwidth command. In this example, non-reserved traffic is limited to a mere 100 Kbps, with one-megabyte bursts allowed. Such an example configuration could be used in a fully RSVP-enabled network, where some bandwidth needs to be provisioned for network control (routing protocols, time management, and so forth).
7-30
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting SBM Router#
show ip sbm [detail] • Lists interfaces where SBM is active • The detailed option displays detailed information about local configuration and the DSBM configuration Router#show Router#show ip ip rsvp rsvp sbm sbm Interface DSBM DSBM Interface DSBM DSBM Addr Addr DSBM Priority Priority DSBM Candidate Candidate Et0/0 10.1.1.1 100 yes Et0/0 10.1.1.1 100 yes Et0/1 10.1.2.1 100 yes Et0/1 10.1.2.1 100 yes Router#show Router#show ip ip rsvp rsvp sbm sbm detail detail Interface:Ethernet 0/0 Interface:Ethernet0/0 Local Configuration Current Local Configuration Current DSBM DSBM IP IP IP Address:10.1.1.1 Address:10.1.1.1 IP Address:10.1.1.1 Address:10.1.1.1 DSBM II Am DSBM candidate:yes candidate:yes Am DSBM:yes DSBM:yes Priority:100 Priority: 100 Priority:100 Priority:100 Non Non Non Resv Resv Send Send Limit Limit Non Resv Resv Send Send Limit Limit Rate:100 Kbytes/sec Rate:100 Rate:100 Kbytes/sec Rate:100 Kbytes/sec Kbytes/sec Burst:1000 Burst:1000 Burst:1000 Kbytes Burst:1000 Kbytes Kbytes Peak:100 Peak:100 Peak:100 Kbytes/sec Kbytes/sec Peak:100 Kbytes/sec Kbytes/sec Min Min Min Unit:unlimited Unit:unlimited Min Unit:unlimited Unit:unlimited Max Max Max Unit:unlimited Unit:unlimited Max Unit:unlimited Unit:unlimited © 2001, Cisco Systems, Inc.
My My Priority Priority 100 100 100 100
IP QoS Signaling Mechanism-32
The show ip sbm command shows per-interface SBM parameters, displaying other SBM-enabled routers on the attached segment. The show ip sbm detail command also shows the non-reserved sending limits of discovered neighbors. In this output, all routers on the segment have the same DSBM priority. In that case, the tiebreaker is a router’s IP address on that segment, and the router with the highest IP address will win the election.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-31
Summary n
SBM enables RSVP to run over shared LAN segments.
n
DSBM routers provide shared LAN adjudication of RSVP-reservations.
n
SBM can limit the amount of non-RSVP traffic sent into a network.
Lesson Review 1. What is the purpose of Subnet Bandwidth Management? 2. How do routers on a common subnet communicate reservation requests? 3. What is a DSBM? 4. How do routers elect a DSBM?
7-32
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Summary n
RSVP enables end-stations to signal QoS requirements to the network
n
RSVP does not provide any guarantees; router QoS mechanisms do.
n
SBM enables RSVP to run over shared LAN segments.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-33
Review Questions and Answers Resource Reservation Protocol (RSVP) Question: What is RSVP used for? Answer: RSVP is used by applications to signal their QoS requirements to the network and to set up reservations along the application path. Question: Does RSVP provide QoS guarantees? Answer: No, RSVP is only used for signaling. Per-hop mechanisms, such as WFQ, are used to guarantee a service level to a RSVP-enabled application. Question: What QoS mechanism should be used to provide QoS guarantees to RSVP reservations? Answer: Usually, WFQ and CB-WFQ are used to provide per-hop guarantees. Question: What are the benefits of using COPS with RSVP? Answer: Using COPS-compliant policy management software enables scaling of RSVP-enabled networks by offloading part of the admission control functions to a centralized database.
Subnet Bandwidth Management
Question: What is the purpose of Subnet Bandwidth Management? Answer: The purpose of SBM is to prevent oversubscription of a shared segment by introducing an arbiter, which keeps tracks of all reservations over a shared segment.
Question: How do routers on a common subnet communicate reservation requests? Answer: Routers communicate reservation requests by forwarding all RSVP messages to the arbiter (the DSBM).
Question: What is a DSBM? Answer: The DSBM (Designated Subnet Bandwidth Manager) is an elected layer3 device on a shared segment, which keeps tracks of all reservations.
Question: How do routers elect a DSBM? Answer: Routers elect a DSBM with a priority-based election system. Router IP address is the final tiebreaker.
7-34
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
8
Modular QoS CLI Classification
Overview This chapter focuses on the classification element of the modular QoS commandline interface. It includes the following topics: n
Introduction to Modular QoS CLI
n
Classification Options
n
Network Based Application Recognition (NBAR)
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe the classification element of the Modular QoS CLI
n
Describe and configure all currently supported classification options within the MQC
n
Understand Network-based Application Recognition (NBAR)
n
Monitor and troubleshoot class maps
Introduction to Modular QoS CLI Objectives Upon completion of this lesson, you will be able to perform the following tasks:
8-2
n
Describe the MQC concepts and structure
n
Configure class maps
n
Monitor and troubleshoot class maps
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Modular QoS CLI • The Modular QoS CLI (MQC) provides a modular approach to configuration of QoS mechanisms • Classification is configured separately from the QoS service policy • MQC also provides modularity to implementation of QoS mechanisms in the Cisco IOS: – New QoS mechanisms can reuse old classification options – New QoS classification options can also be used by older QoS mechanisms © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification -5
The Quality of Service mechanisms that have been added to the Cisco IOS all had their own set of classification options. For example: n
Committed Access Rate (CAR) can classify packets by using: –
Access lists
–
QoS group
–
DSCP
–
Rate limit access list
n
Traffic Shaping (GTS) can classify packets by using access lists
n
Priority Queuing (PQ) and Custom Queuing (CQ) can classify packets by using: –
Access lists
–
Packets size
–
Fragment
–
TCP or UDP port number
The Modular Quality of Service Command Line Interface (MQC) was introduced to allow any supported classification to be used with any QoS mechanism. The separation of classification from the QoS mechanism allows new IOS versions to introduce new QoS mechanisms and reuse all available classification options. On the other hand, old QoS mechanisms can benefit from new classification options. Another important benefit of the MQC is the reusability of configuration. MQC allows the same QoS policy to be applied to multiple interfaces. CAR, for example,
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-3
required entire configurations to be copy-pasted between interfaces and modifying configurations was tiresome. The Modular QoS CLI, therefore, is a consolidation of all the QoS mechanisms that have so far only been available as standalone mechanisms. This module focuses on the classification element of the Modular QoS CLI.
8-4
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Separation of Classification
packet
Classification
Traffic Policy
Class 1?
CB-WFQ
Class 2?
CB-LLQ
Class N?
CB-Policing
© 2001, Cisco Systems, Inc.
Interface or Forwarding
IP QoS - Modular QoS CLI Classification -6
Implementing QoS by using the MQC consists of three steps: Step 1
Configuring classification by using the class-map command
Step 2
Configuring traffic policy by associa ting the traffic class with one or more QOS features using the policy-map command
Step 3
Attaching the traffic policy to inbound or outbound traffic on interfaces, subinterfaces or virtual circuits by using the service-policy command Class maps are used to create classification templates that are later used in policy maps where QoS mechanisms are bound to classes. Routers can be configured with a large number of class maps (currently limited to 256). Each traffic policy, however, may support a limited number of classes (for example: Class-based Weighted Fair Queuing and Class-based Low-latency Queuing are limited to 64 classes). The figure illustrates an implementation where traffic is classified into N classes. Each class is handled by one or more QoS mechanisms (for example, Class-based Weighted Fair Queuing, Class-based Low-latency Queuing, Class-based Policing).
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-5
Class Maps • Each class is identified using a Class Map • Each Class Map is identified by a casesensitive name • Class maps can operate in two modes – Match All – all conditions have to succeed – Match Any – at least one condition must succeed
• The default mode is Match all
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification -7
A class map is created using the class-map global configuration command. Class maps are identified by case-sensitive names. Each class map contains one or more conditions that determine if the packet belongs to the class. There are two ways of processing conditions when there is more than one condition in a class map: n
Match all—all conditions have to be met to bind a packet to the class
n
Match any—at least one condition has to be met to bind the packet to the class
The default match strategy of class maps is “Match all”.
8-6
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Classification using Class Maps
Match all conditions?
Match all
Class Map name
Yes
Match
No
Match Mode? Match any
Yes Match at least one condition?
No
© 2001, Cisco Systems, Inc.
No Match
IP QoS - Modular QoS CLI Classification -8
The figure illustrates the full process of determining if a packet belongs to a class (match) or not (no match). The process goes through the list of conditions and: n
Returns a “match” result if one of the conditions is met and the match-any strategy is used
n
Returns a “match” result if all conditions are met and the match-all strategy is used
n
Otherwise it returns “no match”
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-7
Classification Using Match All Strategy Class Map name
Yes
No More Conditions?
Match
Match Yes Condition? No
No Match
• Match-all requires all conditions to return a positive answer • If one condition is not met the class map will return a “no match” result
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-9
The figure illustrates a simplified flowchart for the match-all strategy. The processing of a match-all class map can be divided into the following steps:
8-8
Step 1
Evaluate a condition
Step 2
Return a “no match” result and stop processing the class map if the condition is not met
Step 3
Go to Step 1 if there are more conditions
Step 4
Returns a “match” result
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Classification Using Match Any Strategy Class Map name
Match
Match Yes Condition? No
More Conditions?
No
No Match
Yes
• Match-any requires at least one condition to return a positive answer • If no condition is met the class map will return a “no match” result © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-10
The figure illustrates a simplified flowchart for the match-any strategy. The processing of a match-all class map can be divided into the following steps: Step 1
Evaluate a condition
Step 2
Return a “match” result and stop processing the class map if the condition is met
Step 3
Go to Step 1 if there are more conditions
Step 4
Return a “no match” result
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-9
Classification Options The main classification options include the following: • Access list (all access lists are available) • IP Precedence value • IP DSCP value • QoS group number • MPLS experimental bits • Protocol (including NBAR)
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-11
Class maps can classify packets by using the following classification tools:
8-10
n
Access lists for any protocol can be used within the class-map configuration mode. The Modular QoS CLI can be used for other protocols, not only IP.
n
IP packets can be classified directly by specifying IP precedence values.
n
IP packets can also be classified directly by specifying IP DSCP (differentiated services code point) values. DiffServ enabled networks can have up to 64 classes if DSCP is used to mark packets.
n
A QoS group parameter can be used to classify packets in situations where up to 100 classes are needed or the QoS group parameter is used as an intermediary marker (for example, MPLS to QoS group translation on input and QoS group to class translation on output).
n
Packets can also be matched based on the value in the experimental bits of the MPLS header of labeled packets.
n
Classification can be performed by identifying a Layer-3 or Layer-4 protocol. Advanced classification is also available by using the Network-based Application Recognition (NBAR) tool where dynamic protocols are identified by inspecting higher-layer information.
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Other Classification Options The other classification options include the following: • • • • • • • •
Using another Class Map Frame Relay DE bit IEEE 802.1Q/ISL CoS/Priority values Input interface Source MAC address Destination MAC address RTP (UDP) port range Any packet
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-12
There are many other classification options: n
Another class map can used to implement template-based configurations
n
Packets can be matched based on the underlying Frame Relay DE bit
n
Packets can be matched based on the information contained in the three Class of Service bits (when using IEEE 802.1Q encapsulation) or Priority bits (when using the ISL encapsulation)
n
Packets can be classified according to the input interface
n
Packets can be matched based on their source or destination MAC addresses
n
RTP (real-time protocol) packets can be matched based on a range of UDP port numbers
n
MQC can also be used to implement a QoS mechanism for all traffic in which case classification will put all packets into one class
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-11
Configuring Class Maps router(config)#
class-map [{match-all | match-any}] name name
• Enter the class-map configuration mode • Specify the matching strategy • Match-all is the default matching strategy router(config-cmap)#
match condition
• Use at least one condition to match packets router(config-cmap)#
description description
• It is recommended to use descriptions in large and complex configuration • The description has no operational meaning © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-13
Use the class-map global configuration command to create a class map and enter the class map configuration mode. A class map is identified by a case-sensitive name; therefore, all subsequent references to the class map must use exactly the same name. At least one match command should be used within the class-map configuration mode (match none is the default). The description command is used for documenting a comment about the class-map.
8-12
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Class Maps router(config-cmap)#
rename new-name
• Complex class-maps can easily be renamed by using the rename class-map command • All references to the class map are also renamed
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-14
Large implementations may use a number of class maps and there are many references to the class maps. Renaming a class map would normally require a change to all references to the class map as well. The rename command can be used to rename class maps and all references to it.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-13
Class Map Example
class-map class-map match-any match-any match match access-group access-group match match access-group access-group class-map class-map match-all match-all match match access-group access-group match match access-group access-group
Test1 Test1 101 102 Test2 Test2 101 102
• This example simply illustrates how classmaps are configured • Class-maps on their own have no function © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-15
The example shows two class maps with two conditions:
8-14
n
Class map Test1 matches all packets that are permitted by at least one of the access lists
n
Class map Test2 matches only those packets that are permitted by both access lists
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting Class Maps router#
show class-map [class-map]
• Lists all class-maps or the selected class-map Router#show Router#show class-map class-map Class Class Map Map match-all match-all Test2 Test2 (id (id 0) 0) Match access-group access-group 101 101 Match access-group access-group 102 102 Class Class Map Map match-any match-any Test1 (id 1) Match access-group access-group 101 101 Match access-group access-group 102 102 Router# Router#
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-16
n
The show class-map command lists all class maps with their match statements
n
The show class-map command with a name of a class map displays the configuration of the selected class map
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-15
Summary The Modular QoS CLI (MQC) is used to separate the classification from the QoS service policy. A unified classification tool can be used by multiple different QoS mechanisms. The classification is configured using class maps, which are used within policy maps to apply QoS mechanisms to classes.
Review Questions Answer the following questions:
8-16
n
What are the benefits of the Modular QoS CLI?
n
Which two matching strategies do class maps support?
n
Which classification options do class maps support?
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Classification Options Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe and configure classification using access lists
n
Describe and configure classification using the IP precedence
n
Describe and configure classification using the DSCP
n
Describe and configure classification using the QoS group
n
Describe and configure classification using the MPLS experimental bits
n
Describe and configure classification based on the input interface
n
Describe and configure classification based on the source MAC address
n
Describe and configure classification based on the destination MAC address
n
Describe and configure classification based on IEEE 802.1Q/ISL CoS
n
Describe and configure classification using another class map, negation or any keyword
n
Describe and configure classification based on the Frame Relay DE bit
n
Describe and configure classification based on RTP port
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-17
Classification Using Access Lists • Access lists are the oldest classification tool that has been used with QoS mechanisms • Class Maps support all types of access lists • Class Maps are multi protocol • Class Maps can use named access lists and numbered access lists (in the range from 1 to 2699) for all protocols
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-21
Access lists were originally used for filtering of inbound or outbound packets on interfaces. They were later reused for filtering of routing updates and also for classification with early QoS tools (for example, Priority Queuing, Custom Queuing and Traffic Shaping). Access lists are still one of the most powerful classification tools. Class maps can use any type of access list (not only IP access lists). Access lists, on the other hand, also have a drawback. Compared to other classification tools they are one of the most CPU-intensive. For this reason it is not recommended that access lists for classification be used on high-speed links where they could severely impact performance of routers. Access lists are typically used on low-speed links at network edges where packets are classified and marked (for example, with IP precedence). Classification in the core is done based on the IP precedence value.
8-18
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using Access Lists Router(config-cmap)#
match access-group {number | name name name}
• Select an access list to be used for classification class-map class-map Telnet Telnet match match access-group access-group 100 !! class-map class-map IPX_Printers IPX_Printers match match access-group access-group IPX !! access-list access-list 100 100 permit permit tcp tcp any any any any eq 23 access-list access-list 100 100 permit permit tcp tcp any any eq eq 23 23 any any !! ipx ipx access-list extended IPX permit permit netbios any any !! Keep All Graphics Inside This Box © 2001, Cisco Systems, Inc.
www.cisco.com
Course acronym 2.0—Chapter#-22
Use the match access-group command to attach an access list to a class-map. The example in the figure shows how numbered or named access list can be used for classification.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-19
Configuring Classification Using IP Precedence router(config-cmap)#
match ip precedence precedence [prec [prec [prec]]]
• Select up to four IP precedence values or names • All packets marked with one of the selected IP precedence values are matched by this class map IP Precedence Value 0 1 2 3 4 5 6 7 © 2001, Cisco Systems, Inc.
IP Precedence Name routine priority immediate flash flash-override critical internet network
class-map class-map match match ip ip !! class-map class-map match match ip ip !! class-map class-map match match ip ip !! class-map class-map match match ip ip !!
VoIP precedence precedence 55 Gold precedence precedence 33 44 Silver precedence precedence 11 22 Bronze precedence precedence routine routine
IP QoS - Modular QoS CLI Classification-23
A much faster method of classification is by matching the IP precedence. Up to four IP precedence values or names can be used to classify packets based on the IP precedence field in the IP header. The figure contains a mapping between IP precedence values and names. The running configuration, however, only shows IP precedence values (not names).
8-20
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using DSCP router(config-cmap)#
match ip dscp dscp [dscp ...]
• Select up to eight DSCP values or names • All packets marked with one of the selected DSCP values are matched by this class map DSCP Value
DSCP Class Name
DSCP Value
DSCP Class Name
0 1 2 3 4 5 6 7 46
default cs1 cs2 cs3 cs4 cs5 cs6 cs7 ef
10 12 14 18 20 22 26 28 30 34 36 38
af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43
(000000) (001000) (010000) (011000) (100000) (101000) (110000) (111000) (101110)
© 2001, Cisco Systems, Inc.
(001010) (001100) (001110) (010010) (010100) (010110) (011010) (011100) (011110) (100010) (100100) (100110)
IP QoS - Modular QoS CLI Classification-24
IP packets can also be classified based on the IP DSCP field. A QoS design can be based on IP precedence marking or DSCP marking. DSCP marking can include backward compatibility with IP precedence by using the Class Selector (CS) values (most significant three bits of the DSCP value). A sample design that includes backward compatibility would use the following values to mark packets belonging to class Gold, which is guaranteed Assured Forwarding (AF) Per-hop Behavior (PHB): n
af11 marks low-drop packets
n
af12 marks medium-drop packets
n
af13 marks high-drop packets
n
cs4 marks low-drop packets (for backward compatibility with IP precedence 4)
n
cs3 marks high-drop packets (for backward compatibility with IP precedence 5)
A sample configuration on the next page shows implementation of a similar design.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-21
Configuring Classification Using DSCP class-map class-map match ip !! class-map class-map match match ip ip !! class-map class-map match match ip ip !! class-map class-map match ip !! class-map class-map match ip ip !!
Voice Voice dscp ef Gold Gold dscp dscp af11 af11 af12 af12 af13 af13 cs3 cs3 cs4 cs4 Silver Silver dscp dscp af21 af21 af22 af22 af23 af23 cs1 cs1 cs2 cs2 Bronze Bronze dscp af31 af32 af33 Best-effort Best-effort dscp dscp default default
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-25
The figure illustrates implementation of a design with five classes: n
Voice, which is identified by DSCP value ef, which looks like IP precedence value 5 in non-DSCP compliant devices.
n
Gold, which is identified by DSCP values af11, af12 and af13. The class is also identified by IP precedence values 3 and 4.
n
Silver, which is identified by DSCP values af21, af22 and af23. The class is also identified by IP precedence values 1 and 2.
n
Bronze , which is identified by DSCP values af31, af32 and af33.
n
Best Effort, which is identified by the default DSCP value that is equal to the default IP precedence value (0).
From a non-DSCP compliant device the design looks slightly different: n
Voice—IP precedence 5
n
Gold—IP precedence 3 and 4
n
Silver—IP precedence 1 and 2
n
Best Effort—IP precedence 0
A DSCP-compliant device treats packets marked by a non-DSCP compliant device according to the design. A non-DSCP compliant device does not treat packets marked by a DSCP-compliant device correctly: n
8-22
AF1 (001xx0) looks like IP precedence 1. Therefore, class Gold appears as class Silver in a non-DSCP compliant device.
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
n
AF2 (010xx0) looks like IP precedence 2. Therefore, class Silver correctly appears as class Silver in a non-DSCP compliant device.
n
AF3 (011xx0) looks like IP precedence 3. Therefore, class Bronze appears as class Gold in a non-DSCP compliant device.
n
EF (101110) looks like IP precedence 5, which is also used for voice in a nonDSCP compliant device.
As can be seen from the example it is very important to understand the impact of DSCP on non-DSCP compliant devices. A DiffServ-based QoS design should include the impact of DSCP on parts of the networks where all routers are not DSCP compliant. The example shows that a network core, if upgraded to support DSCP, can correctly handle packets classified by edge devices that have not yet been upgraded.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-23
Configuring Classification Using QoS Group router(config-cmap)#
match ip qos-group qos-group qos-group qos-group
• Select the QoS group identifying the class • Allowed values are from 0 to 99 • All packets marked with the QoS group value are matched by this class map • The QoS group is a prameter local to the router; it has to be set by some other QoS mechanism (CAR, PBR, CB-Marking, CBPolicing, QPPB) class-map class-map QoS1 QoS1 match match qos-group qos-group 1 !! class-map class-map QoS2 QoS2 match match qos-group qos-group 2 !! © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-26
A QoS group is another marker with support for a large number of classes. Up to 100 classes can be configured by using the QoS group parameter. The main drawback of QoS-group marking is that it has to be performed on every hop since this parameter is not part of any header. The QoS group is an internal parameter in the router and it is lost the moment a packet is sent. The QoS group parameter can be used in situations where one parameter can be seen on input, but not on output where another parameter has to be set. For example: n
Match MPLS experimental bits on input and set QoS group based on the value
n
Match QoS group on output and set IP DSCP based on the value
Matching on QoS group can also be used in combination with QoS Policy Propagation through BGP (QPPB) where up to 100 classes are propagated by BGP and marked by QoS group values on all BGP-enabled routers. Class maps are then used to match on QoS group values.
8-24
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using MPLS experimental bits router(config-cmap)#
match mpls experimental exp [exp ...]
• Select up to eight MPLS experimental values • Allowed values are from 0 to 7 • All MPLS labeled packets marked with the selected MPLS experimental bits are matched by this class map class-map class-map MPLS1 MPLS1 match match mpls mpls experimental experimental 33 4 ! class-map class-map MPLS2 MPLS2 match match mpls mpls experimental experimental 11 2 !
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-27
Class maps can also be used in MPLS-enabled networks where all packets are labeled. There are three experimental bits in the label header that are currently being used for IP precedence. When an IP packet is labeled, the IP precedence value is copied into MPLS experimental bits. A transparent design can be created where class maps can match on both the IP precedence value and the MPLS experimental bits: class-map match-any Voice match ip precedence 5 match mpls experimental 5 ! class-map match-any Gold match ip precedence 3 4 match mpls experimental 3 4 ! class-map match-any Silver match ip precedence 1 2 match mpls experimental 1 2 ! class-map Best-effort match ip precedence 0 match mpls experimental 0 !
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-25
Configuring Classification Using Input Interface router(config-cmap)#
match input-interface intf
• All packets received through the selected input interface are matched by this class map class-map -any Ethernets class-map match match-any match match input-interface input-interface Ethernet0/0 Ethernet0/0 match match input-interface input-interface Ethernet0/1 Ethernet0/1 !! class-map -any FastEthernets class-map match match-any FastEthernets match match input-interface input-interface FastEthernet1/0 FastEthernet1/0 match match input-interface input-interface FastEthernet1/1 FastEthernet1/1 !! class-map -any Serials class-map match match-any Serials match match input-interface input-interface Serial2/0 Serial2/0 match match input-interface input-interface Serial2/1 Serial2/1 match match input-interface input-interface Serial2/2 Serial2/2 match input-interface Serial2/3 match input-interface Serial2/3 !! © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-28
A packet can also be classified based on the input interface.
8-26
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using MAC Addresses router(config-cmap)#
match source-address mac mac-address • Classifies packets based on the source MAC address • This classification option can only be used on interfaces using MAC addresses (e.g. Ethernet, FastEthernet) router(config-cmap)#
match destination-address mac mac mac-address • Classifies packets based on the destination MAC address • This classification option can only be used on interfaces using MAC addresses (e.g. Ethernet, FastEthernet) class-map class-map RTR1_dst RTR1_dst match match destination-address destination-address mac mac 00f0.64e2.2860 00f0.64e2.2860 !! class-map class-map RTR2_src RTR2_src match source-address mac mac 00f0.64e2.3321 00f0.64e2.3321 !! © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-29
Classification can be done based on source or destination MAC addresses. This type of classification is only possible on interfaces that use MAC addresses (for example, Ethernet or FastEthernet). It is especially useful in situations where packets from a certain device have to be matched but the device does not have a static IP address (for example, DHCPderived IP address) or it has too many IP addresses.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-27
Configuring Classification Using 802.1q or ISL CoS/Priority bits router(config-cmap)#
match cos cos cos [cos [cos [cos ]]]
• Select up to four CoS/Priority values • Allowed values are 0 to 7 • This classification option can only be used on interfaces using 802.1Q or ISL encapsulation class-map class-map Strict-priority Strict-priority match match cos cos 5 !! class-map class-map High-priority High-priority match match cos cos 44 6 7 !! class-map class-map Low-priority Low-priority match match cos cos 00 11 2 3 !! © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-30
Routers can also match on the three Class of Service bits in 802.1Q header or Priority bits in the ISL header. These bits can be used in a LAN-switched environment to provide differentiated quality of service.
8-28
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using Special Options router(config-cmap)#
match not condition
• The “not” keyword inverts the condition router(config-cmap)#
match class-map class-map
• One class map can use another class map for classification • Nested class maps allow generic template class maps to be used in other class maps router(config-cmap)#
match any
• The “any” keyword can be used to match all packets
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-31
There are some additional options that give extra power to class maps: n
Any condition can be negated by inserting the keyword not
n
A class map can use another class map to match packets
n
The any keyword can be used to match all packets.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-29
Configuring Classification Using Special Options class-map class-map Well-known-services Well-known-services match match access-group access-group 100 !! Class-map Class-map Unknown-services Unknown-services match match not not class-map class-map Well-known-services !! Class-map Class-map All-services All-services match match any any !! access-list access-list 100 100 permit permit tcp tcp any any any any lt lt 1024 access-list access-list 100 100 permit permit tcp tcp any any lt lt 1024 1024 any
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-32
The example shows three class maps:
8-30
n
Class map Well-known-services uses an access list to match all the packets with the source or destination port number lower than 1024.
n
Class map Unknown-services uses the first class map but negates the result. The same could be achieved by using the same access list with a negation.
n
Class map All-services actually matches all the packets.
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using Frame Relay DE Bit router(config-cmap)#
match fr-de
• Use this command to match all frames with the Frame Relay DE bit set class-map class-map FR_Out_of_Contract FR_Out_of_Contract match match fr-de !! class-map class-map FR_Within_Contract FR_Within_Contract match match not not fr-de fr-de !!
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-33
Class maps used on Frame Relay interfaces can classify packets based on the setting of the Discard Eligibility (DE) bit. The example illustrates how to classify packets that have the DE bit se (match fr-de) and those that do not (match not fr-de).
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-31
Configuring Classification Using a UDP Port Range router(config-cmap)#
match ip rtp starting-port port-range • Use this command to implement classification equal to IP RTP Prioritization • All UDP packets with source or destination port numbers within the specified range are matched • Range is between the starting-port (values from 2000 to 65535) and the sum of the starting-port and the port-range (values from 0 to 16383) • The command should be used in combination with Class-based Lowlatency Queuing to implement RTP Prioritization using the Modular QoS CLI class-map class-map RTP match match ip ip rtp rtp 16384 16384 16383 ! © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-34
IP RTP Prioritization was introduced to provide low-latency queuing in combination with Weighted Fair Queuing (WFQ). The match ip rtp command can be used to match packets in the same way as with IP RTP prioritization. It should also be combined with Class-based Low-latency Queuing (CB-LLQ) to generate a similar result as IP RTP Prioritization.
8-32
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Summary Class maps are used within service policies to classify packets. Class maps support the following classification options: n
Access lists
n
IP precedence
n
DSCP
n
QoS group
n
MPLS experimental bits
n
Input interface
n
Source MAC address
n
Destination MAC address
n
IEEE 802.1Q/ISL CoS or Priority bits
n
Frame Relay DE bit
n
RTP port
Review Questions Answer the following questions: n
Which classification options are available using class maps?
n
What command is used to configure classification?
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-33
Network Based Application Recognition (NBAR) Objectives Upon completion of this lesson, you will be able to perform the following tasks:
8-34
n
Describe and configure NBAR
n
Describe and configure classification of FTP and TFTP
n
Describe and configure complex classification of HTTP sessions
n
Monitor and troubleshoot class maps
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Network-based Application Recognition (NBAR) • The IntServ model uses RSVP to signal QoS requirements including application definition • The DiffServ model relies on the network to recognize applications • Recognizing simple applications is possible by matching on the static source or destination TCP/UDP port numbers • Some applications use multiple sessions and dynamic port numbers © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-38
The two IETF standards that describe guidelines and protocols used to implement quality of service in IP networks are: n
Integrated Services model
n
Differentiated Services model
The Integrated Services model uses the Resource Reservation Protocol (RSVP), which signals the network with the QoS requirements for a specific flow. Part of the request contains information that helps network devices recognize packets belonging to the flow. The Differentiated Services model, however, relies on the network to be able to recognize packets belonging to traffic classes that require the same quality of service. If there is a need to classify a certain protocol it is usually done by using an access list where packets are matched based on the source or destination TCP or UDP port numbers. A problem arises when trying to classify packets belonging to applications that use multiple sessions and dynamically negotiate TCP or UDP port numbers.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-35
8-36
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
NBAR Capabilities • NBAR was introduced to enable recognition of applications using dynamic port numbers (e.g. FTP, Exchange, SQL*net) • NBAR supports a number of applications that use static port numbers (e.g. Telnet) • NBAR also allows recognition of sessions based on higher-layer information (e.g. HTTP by URL, Host or MIME, Citrix by application)
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-39
NBAR can be used to recognize packets belonging to different types of applications: n
Static applications establish sessions to well known TCP or UDP destination port numbers. Such applications used to be classified by using access lists.
n
Dynamic applications use multiple sessions, which use dynamic TCP or UDP port numbers. Typically, there is a control session to a well-know port number and the other sessions are established to destination port numbers negotiated through the control sessions. NBAR inspects the port number exchange through the control session.
n
Some non-IP protocols can also be recognized by NBAR.
n
NBAR also has the capability to inspect some applications for other information and classify based on that information. For example, NBAR can classify HTTP sessions based on the requested URL, included MIME (Multipurpose Internet Mail Extensions) type or hostname.
The following table lists the non-TCP and non-UDP protocols supported by NBAR: Protocol
Protocol ID
Description
EGP GRE ICMP IPINIP IPSec
Network protocol IP IP IP IP IP
8 47 1 4 50, 51
EIGRP
IP
88
Exterior Gateway Protocol Generic Routing Encapsulation Internet Control Message Protocol IP in IP IP Encapsulating Security Payload/Authentication Header Enhanced Interior Gateway Routing Protocol
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-37
8-38
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
NBAR Support for Static Protocols • NBAR supports a number of applications that are recognized based on a well known destination port number • Such applications were previously matched by using extended IP access lists
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-40
Although access lists can also be used for this purpose, NBAR is easier to configure and can provide classification statistics that are not available when using access lists. The following table contains the static IP protocols supported by NBAR: Protocol BGP CU-SeeMe
Transport protocol TCP/UDP TCP/UDP
CU-SeeMe DHCP/ BOOTP
UDP UDP
DNS Finger Gopher HTTP HTTPS IMAP IRC Kerberos L2TP LDAP MS-PPTP
TCP/UDP TCP TCP/UDP TCP TCP TCP/UDP TCP/UDP TCP/UDP UDP TCP/UDP TCP
MS- SQLServer
TCP
NetBIOS NetBIOS NFS NNTP
TCP UDP TCP/UDP TCP/UDP
Copyright 2001, Cisco Systems, Inc.
TCP or UDP port 179 7648, 7649 24032 67, 68
Description Border Gateway Protocol Desktop videoconferencing
Desktop video conferencing Dynamic Host Configuration Protocol/ Bootstrap Protocol 53 Domain Name System 79 Finger user information protocol 70 Internet Gopher Protocol 80 Hypertext Transfer Protocol 443 Secured HTTP 143, 220 Internet Message Access Protocol 194 Internet Relay Chat 88, 749 Kerberos Network Authentication Service 1701 L2F/L2TP tunnel 389 Lightweight Directory Access Protocol 1723 Microsoft Point-to-Point Tunneling Protocol for VPN 1433 Microsoft SQL Server Desktop Videoconferencing 137, 139 NetBIOS over IP (MS Windows) 137, 138 NetBIOS over IP (MS Windows) 2049 Network File System 119 Network News Transfer Protocol IP QoS—Modular QoS CLI Classification
8-39
Protocol
8-40
Notes Novadigm
Transport protocol TCP/UDP TCP/UDP
NTP PCAnywhere
TCP/UDP TCP
PCAnywhere POP3 Printer RIP RSVP SFTP SHTTP SIMAP SIRC SLDAP SNNTP SMTP SNMP SOCKS SPOP3 SSH STELNET Syslog Telnet X Windows
UDP TCP/UDP TCP/UDP UDP UDP TCP TCP TCP/UDP TCP/UDP TCP/UDP TCP/UDP TCP TCP/UDP TCP TCP/UDP TCP TCP UDP TCP TCP
IP QoS—Modular QoS CLI Classification
TCP or UDP port 1352 34603465 123 5631, 65301 22, 5632 110 515 520 1698,17 990 443 585, 993 994 636 563 25 161, 162 1080 995 22 992 514 23 60006003
Description Lotus Notes Novadigm Enterprise Desktop Manager (EDM) Network Time Protocol Symantec PCAnywhere Symantec PCAnywhere Post Office Protocol Printer Routing Information Protocol Resource Reservation Protocol Secure FTP Secure HTTP Secure IMAP Secure IRC Secure LDAP Secure NNTP Simple Mail Transfer Protocol Simple Network Management Protocol Firewall security protocol Secure POP3 Secured Shell Secure Telnet System Logging Utility Telnet Protocol X11, X Windows
Copyright 2001, Cisco Systems, Inc.
NBAR Support for Dynamic Protocols • NBAR is primarily used to recognize applications that use multiple sessions and dynamic port numbers – Such applications usually start with a control session on a well-known port number – Additional ports are negotiated through the control session
• NBAR inspects the negotiation of additional ports • Most of these applications could previously not be matched by any mechanism © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-41
The following table lists the dynamic (or stateful) protocols supported by NBAR: Stateful protocol Transport protocol FTP TCP Exchange TCP HTTP TCP Netshow TCP/UDP Realaudio TCP/UDP r-commands TCP StreamWorks UDP SQL*NET TCP/UDP SunRPC TCP/UDP TFTP UDP VDOLive TCP/UDP
Description File Transfer Protocol MS-RPC for Exchange HTTP with URL, MIME, or Host classification Microsoft Netshow RealAudio Streaming Protocol rsh, rlogin, rexec Xing Technology Stream Works audio and video SQL*NET for Oracle Sun Remote Procedure Call Trivial File Transfer Protocol VDOLive Streaming Video
Use the match protocol ? command to display the list of supported protocols with the Cisco IOS version you are using.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-41
Packet Description Language Module • An external Packet Description Language Module (PDLM) can be loaded at run time to extend the NBAR list of recognized protocols • PDLMs can also be used to enhance an existing protocol recognition capability • PDLMs allow NBAR to recognize new protocols without requiring a new IOS image or a router reload
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-42
New features are usually added to new versions of the Cisco IOS software. NBAR is the first mechanism that supports dynamic upgrades without having to change the IOS version or restart a router. Packet Description Language Modules (PDLMs) contain the rules used by NBAR to recognize an application and can be used to bring new or changed functionality to NBAR.
8-42
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring NBAR router(config-cmap)#
match protocol protocol
• Use the protocol keyword and the name of the protocol to match • Static protocols are recognized based on the wellknown destination port number • Dynamic protocols are recognized by inspecting the session
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-43
When configuring NBAR the administrator does not need to understand the way a certain protocol works. The configuration simply requires the administrator to enter the name of the protocol (static or stateful).
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-43
Configuring NBAR router(config)#
ip nbar pdlm pdlm-file pdlm-file
• Enter the location of the Packet Description Language Module file to extend the NBAR capabilities of the router • The file name is in the URL format (e.g. flash://citrix.pdlm) router(config)# ip nbar port-map protocol protocol {tcp | udp} new-port [new-port ...]
• Specify an additional port for a well-known protocol • Up to 16 additional port numbers can be specified
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-44
Use the ip nbar pdlm command to configure the routers with the new functionality brought by the PDLM file. The pdlm-file parameter should be in the URL format and can point to the flash where the IOS is stored (for example, flash://nbar.pdlm). The file can also be located on a TFTP server (for example, tftp://10.1.1.1/nbar.pdlm). Some protocols (static or stateful) can use additional TCP or UDP ports. Use the ip nbar port-map command to extend the NBAR functionality for well-known protocols to new port numbers.
8-44
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring NBAR for HTTP router(config-cmap)#
match protocol http url url • Recognizes the HTTP GET packets containing the URL, and then matches all packets that are part of the HTTP GET request • Include only the portion of the URL following the address or hostname in the match statement router(config-cmap)#
match protocol http host hostname • Performs a regular expression match on the host field contents inside an HTTP GET packet and classifies all packets from that host router(config-cmap)#
match protocol protocol http http mime mime mime-type • Select the mime-type to be matched • Matches a packet containing the MIME-type and all subsequent packets until the next HTTP transaction © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-45
NBAR has enhanced classification capabilities for HTTP. It can classify packets belonging to HTTP flows based on: n
URL portion after the hostname which appears in the GET request of the HTTP session
n
Hostname specified in the GET request
n
MIME type specifying the type of object in the HTTP response
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-45
NBAR for FTP Case Study class-map FTP match protocol ftp
class-map FTP match protocol ftp
Open control session to well-known port 21 GET file; use port 1050 Open data session to negotiated port 1050 Sending file
• FTP control sessions can be recognized based on the wellknown port number 21 • FTP data sessions may be recognized by the well-known source port number 20 • Not all implementations of FTP use port 20 • NBAR recognizes FTP data sessions by inspecting the FTP control session © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-46
The figure illustrates the process of a file download using FTP. FTP sessions use the well-known TCP port number 21 to open a control session. A new session is opened to transfer a file. The client in the example tells the server to open a data session to TCP port 1050. Although the server should use the well-known source port 20 for the data session, which would simplify classification of FTP, many implementations of FTP use random source port numbers. NBAR inspects the communication between the client and the server to learn about dynamically negotiated port numbers (1050 in the example). NBAR is then able to classify all packets (control and data) as FTP packets.
8-46
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
NBAR for TFTP Case Study class-map FTP match protocol tftp
class-map FTP match protocol tftp
Send first packet to port 69, source port 1060 GET file Send packet to port 1060, source port 1035 Sending file Send packet to port 1035, source port 1060 Acknowledge Send packet to port 1060, source port 1035 Sending file
• TFTP uses UDP for transport • The first packet uses a well-known destination port number 69 and a random source port (>1023) • The receiver responds to the received source port and uses a new source port for its packets (>1023) • The session from there on uses those port numbers © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-47
TFTP is another file transfer protocol (a trivial one), which is not trivial to classify. TFTP uses UDP to transfer files. Step 1
The first TFPT packet (sent from the client to the server) uses a random source port number and the well-known destination port number 69. This is the only information that can be used to recognize TFTP.
Step 2
A router configured for NBAR recognizes port 69 but remembers the source port (1060 in the example).
Step 3
The server responds by sending a packet to the client where its source port number is also random (1035 in the example). The router can, however, recognize this as part of a TFTP session because it previously recorded the client’s source port number (now the destination port number 1060).
Step 4
All subsequent packets use this pair of port numbers (1060<->1035).
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-47
NBAR for HTTP Case Study #1 ip nbar port-map http tcp 80 8080 ! class-map HTTP match protocol http
ip nbar port-map http tcp 80 8080 ! class-map HTTP match protocol http
Open HTTP session to port 80 GET page Open HTTP session to port 8080 GET page
• HTTP is a static protocol using a well-known port number 80 • Some web servers are using HTTP on other ports • Use the “ip nbar port-map” command to inform the router that other ports are also used for HTTP © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-48
The example illustrates a simple classification of all HTTP sessions. HTTP sessions using the default well-known port number 80 are simple to classify (it is a static protocol). HTTP is often used on other port numbers. The example shows the usage of the ip nbar port-map command to also enable HTTP recognition on port 8080.
8-48
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
NBAR for HTTP Case Study #2 ip nbar port-map http tcp 80 8080 ! class-map HTTP match protocol http url *xxx.(jpg|gif)
Open HTTP session to port 80 GET /images/xxx.gif Open HTTP session to port 8080 GET /images/xxx.jpg
• The class map matches all HTTP requests that contain either xxx.gif or xxx.jpg • It does so on both ports: 80 and 8080
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-49
Classification of HTTP by URL, host, or Multipurpose Internet Mail Extension (MIME) type, is an example of subport classification. Step 1
NBAR classifies HTTP traffic by text within the URL or host fields of a GET request using regular expression matching. NBAR uses the UNIX filename specification as the basis for the URL or host specification format.
Step 2
The NBAR engine converts the specified match string into a regular expression.
Step 3
NBAR recognizes HTTP GET packet(s) containing the URL and classifies all packets that are sent to the source of the HTTP GET request. The example shows a class-map that classifies only those HTTP sessions that request files with filenames ending in xxx.gif or xxx.jpg. The allowed regular expressions include the following special characters: Special character * ? | (|) []
Copyright 2001, Cisco Systems, Inc.
Description Match any zero or more characters in this position. Match any one character in this position. Match one of a choice of characters. Match one of a choice of characters in a range. For example, foo.(gif | jpg) matches either foo.gif or foo.jpg. Match any character in the range specified, or one of the special characters. For example, [0-9] is all of the digits. [*] is the "*" and [[] is the "[" character.
IP QoS—Modular QoS CLI Classification
8-49
NBAR for HTTP Case Study #3 ip nbar port-map http tcp 80 8080 ! class-map HTTP match protocol http mime *jpeg
Open HTTP session to port 80 GET /html/pictures.html Open HTTP session to port 8080 GET /html/pictures.html
• The class map matches all HTTP requests containing MIME type that contains jpeg (e.g. image/jpeg) • It does so on both ports: 80 and 8080
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-50
This example shows how HTTP sessions can also be filtered based on the MIME type.
8-50
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Summary Network-based Application Recognition (NBAR) is a tool used primarily to classify packets belonging to applications using dynamically assigned TCP or UDP port numbers. Additionally, NBAR can classify packets (or flows) on application layer information (for example, HTTP can be classified based on URL, hostname or MIME contents).
Review Questions Answer the following questions: n
What is NBAR used for?
n
What types of applications can NBAR recognize?
n
How can support for recognizing new applications be included into existing IOS versions?
n
What additional classification options are available for HTTP?
n
Which special characters are available with regular expressions for matching HTTP flows?
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-51
Summary After completing this module, you should be able to perform the following tasks:
8-52
n
Describe the classification part of the Modular QoS CLI
n
Describe and configure all currently supported classification options within the MQC
n
Understand Network-based Application Recognition (NBAR)
n
Monitor and troubleshoot class maps
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Introduction to Modular QoS CLI Question: What are the benefits of the Modular QoS CLI? Answer: Template-based configuration; new classification options can be used with any MQC-based QoS mechanism. Question: Which two matching strategies do class maps support? Answer: When using multiple match commands in one class map a logical “or” is configured using the match-any keyword and a logical “and” is configured using the match-all keyword. Question: Which classification options do class maps support? Answer: Class maps support classification using: access lists, IP Precedence value, IP DSCP value, QoS group number, MPLS experimental bits, protocol (including NBAR) etc.
Classification Options Question: Which classification options are available using class maps? Answer: Class maps support classification using: access lists, IP Precedence value, IP DSCP value, QoS group number, MPLS experimental bits, protocol (including NBAR) etc. Question: What command is used to configure classification? Answer: The match command is used in the class-map configuration mode to specify the classification parameters.
Network Based Application Recognition (NBAR) Question: What is NBAR used for? Answer: NBAR is primarily used to recognize sessions that dynamically negotiate TCP or UDP port numbers. Question: What types of applications can NBAR recognize? Answer: NBAR can recognize static protocols, dynamic protocols and sessions based on higher-layer information. Question: How can support for recognizing new applications be included into existing IOS versions? Answer: By using Packet Language Description Modules (PDLMs) to include new or changed functionality into existing Cisco IOS. Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-53
Question: What additional classification options are available for HTTP? Answer: Classification based on URL, hostname or MIME type. Question: Which special characters are available with regular expressions for matching HTTP flows?
Answer: The special characters include:
8-54
IP QoS—Modular QoS CLI Classification
–
“*” to match any sequence of characters
–
“?” to match any single character
–
“|” to match the expression on the left or the expression on the right
–
“[]” to match a character from the specified range
–
“()” to group a number of characters
Copyright 2001, Cisco Systems, Inc.
9
Modular QoS CLI Service Policy
Overview This module describes the policy part of the Modular QoS CLI (MQC). The module describes all the mechanisms that are currently supported by the MQC. As well, the module describes the class-based approach to the marking, shaping, policing, dropping and/or scheduling of IP packets using the modular QoS CLI.
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe the policy part of the Modular QoS CLI
n
Configure packet marking with modular CLI
n
Configure policing and shaping with modular CLI
n
Configure class-based WFQ with modular CLI
n
Configure congestion avoidance mechanisms (WRED) with modular CLI
n
Configure low-latency queuing
n
Monitor and troubleshoot policy maps
Service Policy Overview This lesson introduces the part of the MQC that is used to enable QoS mechanisms for classified traffic.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
9-2
n
Describe and configure policy maps.
n
List all the QoS mechanisms currently available in the MQC.
n
Monitor and troubleshoot policy maps.
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Service Policy • One aspect of modularity of the MQC is the configuration part • MQC is split into two modules: – Configuration of classification – Configuration of service policies
• Classification is configured by using class maps • Service Policy is configured by using policy maps
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-5
The Cisco IOS Modular QoS CLI (MQC) is the new, unified method of QoS mechanism configuration in Cisco IOS. MQC separates classification and QoS mechanism configuration by separating the configuration tasks into: n
Configuration of class-maps, which define the classification of traffic
n
Configuration of service policies, which define how QoS mechanisms are applied to traffic classes
This creates a flexible environment for the modular configuration of many QoS features, and significantly reduces overhead and the possibility of errors because configuration information is not unnecessarily duplicated.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-3
Modular QoS CLI Classification
Service Policy
Class 1?
CB-WFQ
Class 2?
CB-LLQ
Service Policy implements per-hop behaviors (PHBs) for all traffic classes Supported mechanisms: • CB-WFQ • CB-LLQ • CB-Policing
Class N?
CB-Policing
• CB-Shaping • CB-Marking
• Up to 256 classes can be used within one service policy © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-6
The service policy is used to configure QoS mechanisms, which may be applied to classes. The QoS mechanisms implement local per-hop behaviors (PHBs) for attached traffic classes. The QoS system, which implements PHB configured via the MQC, is the Class-Based Weighted Fair Queuing system, which integrates many QoS features in a single system, configured via a common (MQC) interface. A service policy can have up to 256 classes used within it and attached to an interface. Class-based Weighted Fair Queuing and Class-based Low-latency Queuing are an exception – only 64 classes can be used with one service policy.
9-4
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
PHB Mechanisms • MQC Supports the following QoS mechanisms: – Class-based Weighted Fair Queuing (CB-WFQ) to guarantee bandwidth – Class-based Low-latency Queuing (CB-LLQ) to guarantee bandwidth and low-latency – Class-based Policing (CB-Policing) to limit traffic rate by dropping excess traffic – Class-based Shaping (CB-Shaping) to limit traffic rate by delaying excess traffic – Class-based Marking (CB-Marking) to mark packets © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy -7
The MQC configures the CB-WFQ system, which in turn implements the following QoS functions: n
Class-based Weighted Fair Queuing, which is used to guarantee bandwidth within the CB-WFQ system
n
Class-based Low-latency Queuing, which is used to guarantee bandwidth and provide low latency to time-critical traffic
n
Class-based Policing, which performs rate limiting by traffic policing
n
Class-based Shaping, which performs rate limiting by traffic shaping
n
Class-based Marking, which performs packet and frame marking
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-5
Configuring Policy Maps Router(config)#
policy-map name • Enter policy-map configuration mode • Policy maps are identified by a case-sensitive name Router(config-pmap)#
class class-map • Enter the per-class policy configuration mode by using the name of a previously configured class-map • Use the name “class-default” to configure the policy for the default class Router(config-pmap)#
class class-map condition • Optionally you can define a new class-map by entering the condition after the name of the new class map • Class map will use the match-any strategy © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy -8
Service policies are configured using the policy-map command. Up to 256 classes can be used within one policy-map using the class command with the name of a preconfigured class-map. A non-existent class can also be used within the policy-map configuration mode if the match condition is specified after the name of the class. The running configuration will reflect such a configuration by using the match any strategy and inserting a full class-map configuration. The following table shows starting and resulting configuration modes for the classmap, policy-map and class commands: Starting configuration mode
Command
Configuration mode
Router(config)#
class-map
Router(config-cmap)#
Router(config)#
policy-map
Router(config-pmap)#
Router(config-pmap)#
class
Router(config-pmap-c)#
All traffic that is not classified by any of the class-maps used within the policy map is part of the default class class-default. This class has no QoS guarantees by default. The default cla ss, when used on output, can use one FIFO queue of flow-based WFQ. The default class is part of every policy-map even if not configured.
9-6
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring Policy Maps Router(config-pmap)#
description description • It is recommended to use descriptions in large and complex configurations • The description has no operational meaning Router(config-pmap)#
rename policy-map • Complex policy-maps can be renamed by using the rename policy-map command • All references to the policy map are also renamed Router(config-pmap-c)#
• Per-class service policies are configured within the per-class policymap configuration mode © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy -9
Policy maps, like class maps, should use descriptions in large QoS implementations where a large number of different policy maps are used. Renaming a policy map would normally require the renaming of all the references to the policy map. Using the rename command simplifies the renaming process by automatically renaming all references. The remainder of this module focuses on the various QoS mechanisms that are configured per-class within the policy-map configuration mode (config-pmap-c).
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-7
Configuring Policy Maps Router(config-if)#
service-policy {input | output} policy-map
• Attaches the specified service policy map to the input or output interface • The interface should be in the default queuing mode prior to using this command if it is used on output class-map class-map HTTP HTTP match match protocol protocol http !! policy-map policy-map PM PM class class HTTP HTTP bandwidth bandwidth 2000 2000 class class-default bandwidth bandwidth 6000 6000 !! © 2001, Cisco Systems, Inc.
interface interface Serial0/0 Serial0/0 service-policy service-policy output output PM PM !!
IP QoS Modular QoS CLI Service Policy-10
The last configuration step when configuring QoS mechanisms using the Modular QoS CLI, is to attach a policy map to the inbound or outbound packets, using the service-policy command. The router immediately verifies the correctness of parameters used in the policy map. If there is a mistake in the policy-map configuration, the router will display a message explaining what is wrong with the policy map. The sample configuration shows how a policy map is used to separate HTTP from other traffic. HTTP is guaranteed 2Mbps. All other traffic belongs to the default class and is guaranteed 6Mbps.
9-8
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Attaching Policy Maps to ATM PVCs Router(config-subif)#
service-policy {input | output} policy-map
• Service policies can be attached to an ATM (sub)interface • Using service policies on the main interface and subinterfaces at the same time is not supported in the distributed (VIP-based) version Router(config-if-atm-vc)#
service-policy {input | output} policy-map
• Service policies can also be attached to an ATM PVC interface interface atm atm 5/0/0.1 5/0/0.1 point-to-point point-to-point service-policy service-policy output output PM1 PM1 !! interface atm 5/0/0.2 point-to-point interface atm 5/0/0.2 point-to-point pvc pvc 1/40 1/40 service-policy service-policy output output PM2 PM2 !! © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-11
Service policies can be applied to interfaces, subinterfaces or individual ATM virtual circuits. Refer to the “IP QoS – IP over ATM” module for a more detailed description of MQC usage on ATM interfaces.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-9
Attaching Policy Maps to Frame Relay Interfaces Router(config-subif)#
service-policy {input | output} policy-map
• Service policy can be attached to an interface and/or to a subinterface • Service policy attached to a subinterface can not include CB-WFQ or CB-LLQ except in the distributed (VIP-based) version • Using service policies on the main interface and subinterfaces at the same time is not supported in the distributed (VIP-based) version
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-12
Service policies can also be used on Frame Relay interfaces or subinterfaces.
9-10
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Attaching Policy Maps to Frame Relay PVCs Router(config-map-class)#
service-policy {input | output} policy-map • Service policy can be attached to a Frame Relay map class class-map class-map Voice Voice match match protocol protocol vofr vofr !! policy-map policy-map LLQ class class Voice Voice priority priority 100 !! interface interface Serial0/0 Serial0/0 encapsulation -relay encapsulation frame frame-relay !! interface interface Serial0/0.1 Serial0/0.1 point-to-point point-to-point frame-relay frame-relay class class Voice !! map-class map-class frame-relay frame-relay Voice Voice service-policy service-policy output LLQ !! © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-13
A Frame Relay map class is needed when attaching a policy map to an individual virtual circuit. The sample configuration illustrates how per-VC Low-latency queuing can be configured on Frame Relay virtual circuits.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-11
Policy Map Example class-map class-map match-all match-all Test1 Test1 match protocol protocol http match match access-group access-group 100 100 class-map class-map match-any match-any Test2 Test2 match match protocol protocol http match match access-group access-group 101 101 !! policy-map policy-map Test class Test1 bandwidth 100 100 class Test2 bandwidth 200 200 class Test3 access-group 100 bandwidth 300 300 !! access-list access-list 100 permit permit tcp tcp any any host host 10.1.1.1 10.1.1.1 access-list access-list 101 permit permit tcp tcp any any host host 10.1.1.2 10.1.1.2
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-14
The example shows the configuration of a policy map using three classes. The first two classes were separately configured using the class-map command. The third class was configured “on the fly” by specifying the match condition after the name of the class. Class Test1 has two match conditions evaluated in the match-all strategy. Classes Test2 and Test3 use the match-any strategy.
9-12
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting Policy Maps Router#
show policy-map [policy-map] Router#show Router#show policy-map policy-map Policy Map Test Class Test1 Test1 Weighted Fair Queueing Queueing Bandwidth Bandwidth 100 100 (kbps) (kbps) Class Test2 Test2 Weighted Fair Queueing Queueing Bandwidth Bandwidth 200 200 (kbps) (kbps) Class Test3 Test3 Weighted Fair Queueing Queueing Bandwidth Bandwidth 300 300 (kbps) (kbps)
© 2001, Cisco Systems, Inc.
Max Max Threshold Threshold 64 64 (packets) (packets)
Max Max Threshold Threshold 64 64 (packets) (packets)
Max Max Threshold Threshold 64 64 (packets) (packets)
IP QoS Modular QoS CLI Service Policy-15
The show policy-map command can be used to verify the configuration of a policy map.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-13
Monitoring and Troubleshooting Policy Maps Router#
show policy-map interface [intf] {input | output} Router #show policy -map interface Router#show policy-map interface FastEthernet0/0 FastEthernet0/0 output output FastEthernet0/0 FastEthernet0/0 Service-policy Service-policy output: output: Test Test (1101) (1101) Class-map: Class-map: Test1 Test1 (match-all) (match-all) (1103/3) (1103/3) 00 packets, packets, 00 bytes bytes 55 minute offered rate 0 bps, minute offered rate bps, drop rate 0 bps Match: Match: access-group access-group 101 101 (1107) (1107) Match: Match: access-group access-group 102 102 (1111) (1111) Match: Match: protocol protocol http http (1115) (1115) Weighted Weighted Fair Fair Queueing Queueing Output Output Queue: Queue: Conversation 265 Bandwidth 100 Bandwidth 100 (kbps) (kbps) Max Max Threshold Threshold 64 64 (packets) (packets) (pkts (pkts matched/bytes matched/bytes matched) matched) 0/0 0/0 (depth/total (depth/total drops/no-buffer drops/no-buffer drops) drops) 0/0/0 0/0/0 ... ... Class-map: Class-map: class-default class -default (match-any) (match-any) (1143/0) (1143/0) 25 25 packets, packets, 19310 19310 bytes bytes 55 minute minute offered offered rate rate 1000 1000 bps, bps, drop drop rate rate 00 bps bps Match: Match: any any (1147) (1147) © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-16
The show policy-map command also displays live information if the interface keyword is used. The sample output shows the parameters and statistics of the policy map attached to outbound traffic on interface FastEthernet0/0.
9-14
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Summary All QoS mechanisms using the Modular QoS CLI (MQC) are configured using the following three commands: n
Class-map global configuration command to configure classification
n
Policy-map global configuration command to create a service policy
n
Class command in the policy-map configuration mode to attach QoS mechanisms to a class
The MQC supports the following QoS mechanisms: n
Class-based Weighted Fair Queuing
n
Class-based Low-latency Queuing
n
Class-based Weighted Random Early Detection
n
Class-based Policing
n
Class-based Shaping
n
Class-based Marking
Lesson Review 1. What are the benefits of using MQC? 2. How many classes can be used for one service policy?
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-15
Class-based Weighted Fair Queuing Overview This lesson describes the enhanced queuing mechanism in Cisco IOS using the Modular QoS CLI.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
9-16
n
Describe Class-based Weighted Fair Queuing (CB-WFQ)
n
Configure CB-WFQ
n
Monitor and troubleshoot CB-WFQ
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Weighted Fair Queuing • Class-based Weighted Fair Queuing (CB-WFQ) is a mechanism that is used to guaranetee bandwidth to classes • CB-WFQ extends the standard WFQ functionality to provide support for user-defined traffic classes – Classes are based on user-defined match criteria – Packets satisfying the match criteria for a class constitute the traffic for that class
• A queue is reserved for each class, and traffic belonging to a class is directed to that class's queue
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-21
CBWFQ extends the standard WFQ functionality to provide support for userdefined traffic classes. For CBWFQ, the user defines the traffic classes based on match criteria including protocols, access control lists (ACLs), and input interfaces. Packets satisfying the match criteria for a class constitute the traffic for that class. A queue is reserved for each class, and traffic belonging to a class is directed to that class's queue. Once a class has been defined according to its match criteria, you can assign it characteristics. To characterize a class, you assign it bandwidth, weight, and maximum packet limit. The bandwidth assigned to a class is the minimum bandwidth delivered to the class during congestion. To characterize a class, you also specify the queue limit for that class, which is the maximum number of packets allowed to accumulate in the class's queue. Packets belonging to a class are subject to the bandwidth and queue limits that characterize the class. After a queue has reached its configured queue limit, enqueuing of additional packets to the class causes tail drop or packet drop to take effect, depending on how the class policy is configured.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-17
CB-WFQ Forwarded Packets CB-WFQ
Class 1?
Tail-drop
Queue 1
Class 2?
Tail-drop
Queue 2
Hardware Queuing System CB-WFQ Scheduler
Class-default?
Tail-drop
Hardware Q
Interface
Default Queue
• Up to 64 classes (class maps) and one default class © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-22
CB-WFQ uses up to 64 class maps to classify traffic into their corresponding FIFO queues. Tail-drop is the default dropping scheme of CB-WFQ although it can be combined with WRED. The CB-WFQ scheduler is used to guarantee bandwidth based on the configured weights.
9-18
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ Classification • Classification uses class-maps • Availability of certain classification options depends on the Cisco IOS version • Some classification options depend on type of interface and encapsulation where service policy is used • For example: – Matching on Frame Relay DE bits can only be used on interfaces with Frame Relay encapsulation – Matching on MPLS experimental bits has no effect if MPLS is not enabled – Matching on ISL Priority bits has no effect if ISL is not used
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-23
Any classification option can be used depending on the availability in the Cisco IOS version and the support on the selected interface and encapsulation.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-19
CB-WFQ Insertion Policy • Each queue has a maximum number of packets that it can hold (queue size) • The default maximum queue size is 64 • After a packet is classified to one of the queues, the router will enqueue the packet if the queue limit has not been reached (taildrop within each class) • WRED can be used in combination with CBWFQ to prevent congestion of the class
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-24
CB-WFQ reserves 64 FIFO queues in the WFQ system. The default queue limit is 64 (tail-drop) and can be configured with WRED (random drop).
9-20
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ Scheduling • CB-WFQ guarantees bandwidth according to weights assigned to traffic classes • Weights can be defined by specifying: – Bandwidth (in kbps) – Percentage of bandwidth (percentage of configured interface bandwidth) – Percentage of available bandwidth
• One service policy can not have mixed types of weights • The “show interface” command can be used to display the available bandwidth © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-25
The configuration of bandwidth guarantees can be done using one of the following commands: n
The bandwidth command allocates a fixed amount of bandwidth by specifying the amount in kilobits per second (kbps). The reserved bandwidth is subtracted from the available bandwidth of the interface where the service policy is used. The allocated bandwidth must also be within the default or configured reservable limit (75% by default).
n
The bandwidth percent command can be used to allocate a percentage of the default or configured bandwidth of an interface. The default bandwidth usually equals the maximum speed of an interface. Sometimes it actually reflects the real speed of an interface (for example: Ethernet or FastEthernet). The default value can be replaced by using the bandwidth interface command. It is recommended that the bandwidth reflect the real speed of the link. The allocated bandwidth is subtracted from the available bandwidth of the interface where the service policy is used.
n
The bandwidth remaining percent command can be used to allocate a portion of the available bandwidth. The allocated bandwidth is not subtracted from the available bandwidth of the interface where the service policy is used.
A single service policy cannot mix different bandwidth commands.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-21
Available Bandwidth • Available bandwidth is calculated according to the following formula: Configured using the interface “bandwidth” command
Configured using the interface max-reserved -bandwidth command 75% is the default value
BWavail = BW * MaxReservable – SUM(all fixed guarantees)
Sum of all fixed guarantees using CB-WFQ, CB-LLQ, IP RTP Prioritization
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-26
The available bandwidth displayed by the show interface command is calculated by subtracting all fixed bandwidth reservations from 75% of the default or configured bandwidth of an interface.
9-22
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Available Bandwidth Example 1 • Ethernet interface uses default bandwidth 10000 (kbps) and WFQ BWavail = BW * MaxReservable – SUM(all fixed guarantees) BWavail = 10000 kbps * 75% – 0 kbps = 7500 kbps Router#show Router#show interface interface Ethernet Ethernet 0/0 0/0 Ethernet0/0 Ethernet0/0 is is up, up, line line protocol protocol is is up up Hardware is AmdP2, address is 00b0.64e2.2860 ( (bia Hardware is bia 00b0.64e2.2860) 00b0.64e2.2860) Internet address is 192.168.20.1 255.255.255.0 Internet MTU MTU 1500 1500 bytes, bytes, BW BW 10000 10000 Kbit, Kbit, DLY DLY 1000 1000 usec, usec, reliability reliability 255/255, 255/255, txload txload 1/255, 1/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation ARPA, ARPA, loopback loopback not not set set Keepalive set (10 sec) Keepalive ARP ARP type: type: ARPA, ARPA, ARP ARP Timeout Timeout 04:00:00 04:00:00 Last Last input input 00:00:04, 00:00:04, output output 00:00:08, 00:00:08, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input rops: 0 Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total Total output output ddrops: 0 Queueing Queueing strategy: strategy: weighted weighted fair fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations Conversations 0/0/256 0/0/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 7500 kilobits/sec ... ... © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-27
The figure illustrates a situation where there are no fixed guarantees on the interface. The show interface command confirms that there are 7.5 Mbps of bandwidth available (only 75% of 10Mbps is reservable by default).
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-23
Available Bandwidth Example 2 • Ethernet interface uses default bandwidth 10000 (kbps) with WFQ • Maximum Reservable bandwidth is set to 50% • IP RTP Prioritization is used to guarantee 1 Mbps to VoIP BWavail = BW * MaxReservable – SUM(all fixed guarantees) BWavail = 10000 kbps * 50% – 1000 kbps = 4000 kbps
interface Ethernet0/0 ip address 192.168.20.1 255.255.255.0 half-duplex max-reserved-bandwidth 50 fair-queue ip rtp priority 16384 16383 1000
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-28
After enabling IP RTP Prioritization with 1Mbps of guaranteed bandwidth and reducing the reservable limit to 50% there are only 4Mbps left. The IP RTP Priority feature provides a strict priority queueing scheme that allows delay-sensitive data such as voic e to be dequeued and sent before packets in other queues are dequeued. This feature can be used with either WFQ or CBWFQ on the same outgoing interface. In either case, traffic matching the range of UDP ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; packets in the priority queue are always serviced first.
9-24
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Available Bandwidth Example 2 Router#show Router#show interface interface Ethernet0/0 Ethernet0/0 Ethernet0/0 Ethernet0/0 is up, line line protocol protocol is up up Hardware Hardware is is AmdP2, AmdP2, address address is is 00b0.64e2.2860 00b0.64e2.2860 (bia (bia 00b0.64e2.2860) 00b0.64e2.2860) Internet Internet address address is is 192.168.20.1 192.168.20.1 255.255.255.0 255.255.255.0 MTU MTU 1500 1500 bytes, bytes, BW BW 10000 10000 Kbit, Kbit, DLY DLY 1000 1000 usec, usec, reliability reliability 255/255, 255/255, txload txload 1/255, 1/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation ARPA, ARPA, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) ARP ARP type: type: ARPA, ARPA, ARP ARP Timeout Timeout 04:00:00 04:00:00 Last input 00:00:04, Last input 00:00:04, output output 00:00:06, 00:00:06, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total output drops: d rops: 0 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 0/1000/64/0 0/1000/64/0 (size/max (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 0/1/256 0/1/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 4000 4000 kilobits/sec kilobits/sec ... ...
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-29
The show interface command confirms the calculation of available bandwidth for Example 2.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-25
Configuring CB-WFQ Router(config-pmap-c)#
bandwidth bandwidth
• Allocate a fixed amount of bandwidth to a class • Set the value in kbps Router(config-pmap-c)#
bandwidth percent percent
• Allocate a percentage of bandwidth to a class • The configured (or default) interface bandwidth is used to calculate the guaranteed bandwidth Router(config-pmap-c)#
bandwidth remaining remaining percent percent percent
• Allocate a percentage of available bandwidth to a class
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-30
Bandwidth guarantee is configured in the cla ss policy-map configuration mode (config-pmap-c). All classes belonging to one policy map should use the same type of bandwidth guarantee (fixed in kbps, in percentage of interface bandwidth, in percentage of available bandwidth).
9-26
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring CB-WFQ Router(config-pmap-c)#
queue-limit queue-limit
• Set the maximum number of packets this queue can hold • The default maximum is 64 • Sets the discard threshold in the “class-default” if flow-based WFQ is used
Router(config-pmap-c)#
fair-queue [dynamic-queues]
• The “class-default” class can be configured to use flow-based WFQ • WFQ can be configured with 16 to 4096 dynamic queues
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-31
The default queue limit of 64 packets can be changed using the queue-limit command. It is recommended not to change the default value. The default class can be selected by specifying the class-default name of the class. The default class supports two types of queuing: one FIFO queue (Default) or a Flow-based WFQ system. Both types can be combined with WRED. FIFO queue can also get a bandwidth guarantee. The following example shows the configuration of FIFO queuing within the default class. The default class is also guaranteed 1 Mbps of bandwidth and the maximum queue size is limited to 40 packets. policy-map A class A bandwidth 1000 class class-default bandwidth 1000 queue-limit 40 This next example shows the configuration of WFQ queuing within the default class. The number of dynamic queues is set to 1024 and the discard threshold is set to 50. policy-map A class A bandwidth 1000 class class-default fair-queue 1024 queue-limit 50
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-27
9-28
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ Example 1 policy-map policy-map Policy1 Policy1 class class Class1 Class1 bandwidth 2000 2000 class class Class2 Class2 bandwidth 2000 2000 ! interface FastEthernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 duplex duplex auto speed speed 10 10 max-reserved-bandwidth max-reserved-bandwidth 80 80 service-policy service-policy output Policy1 ip ip rtp rtp priority priority 16384 16384 16383 16383 1000 1000 ! BWavail = 10000 kbps * 80% - (2000+2000+1000) kbps = 3000 kbps © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-32
The sample configuration shows how CB-WFQ is used to guarantee 2Mbps to each of the two classes. The FastEthernet interface (in Ethernet mode) allows up to 80% of the interface bandwidth (10Mbps) to be reserved. IP RTP Prioritization together with the two classes consumes 5Mbps. The available bandwidth, therefore, is 3Mbps.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-29
CB-WFQ Example 2 policy-map policy-map Policy1 Policy1 class class Class1 Class1 bandwidth percent percent 20 20 class class Class2 Class2 bandwidth percent percent 20 20 ! interface FastEthernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 duplex duplex auto speed speed 10 10 max-reserved-bandwidth max-reserved-bandwidth 80 80 service-policy service-policy output Policy1 ip ip rtp rtp priority priority 16384 16384 16383 16383 1000 1000 ! BWavail = 10000 kbps * 80% - (10000*(20%+20%)+1000) kbps = 3000 kbps © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-33
This implementation is equal to CB-WFQ Example 1. The main benefit of using the percentage keyword is that this policy map can easily be used on another interface with a different link speed (bandwidth).
9-30
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ Examples 1 and 2 Router#show Router#show interface interface fastethernet fastethernet 0/0 0/0 FastEthernet0/0 FastEthernet0/0 is up, line line protocol protocol is is up up Hardware Hardware is is AmdFE, AmdFE, address address is is 0030.8546.aa00 0030.8546.aa00 (bia (bia 0030.8546.aa00) 0030.8546.aa00) Internet Internet address address is is 10.1.1.1 10.1.1.1/24 /24 MTU MTU 1500 1500 bytes, BW BW 10000 10000 Kbit, Kbit, DLY DLY 1000 1000 usec, usec, reliability reliability 255/255, 255/255, txload txload 1/255, 1/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation ARPA, ARPA, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) Half-duplex, Half-duplex, 10Mb/s, 10Mb/s, 100BaseTX/FX 100BaseTX/FX ARP type: ARPA, ARP ARP type: ARPA, ARP Timeout Timeout 04:00:00 04:00:00 Last Last input input 00:00:00, 00:00:00, output output 00:00:09, 00:00:09, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total output drops: d rops: 0 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 0/1000/64/0 0/1000/64/0 (size/max (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 0/1/256 0/1/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 2/2 2/2 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 3000 3000 kilobits/sec kilobits/sec ... ...
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-34
The show interface command confirms the calc ulation of available bandwidth on the previous CB-WFQ examples.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-31
CB-WFQ Example 3 policy-map policy-map Policy1 Policy1 class class Class1 Class1 bandwidth remaining remaining percent 20 20 class class Class2 Class2 bandwidth remaining remaining percent 20 20 ! interface FastEthernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 duplex duplex auto speed speed 10 10 max-reserved-bandwidth max-reserved-bandwidth 80 80 service-policy service-policy output Policy1 ip ip rtp rtp priority priority 16384 16384 16383 16383 1000 1000 ! BWavail = 10000 kbps * 80% - 1000 kbps = 7000 kbps © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-35
Example 3 shows how the available bandwidth can be distributed among the classes configured with the bandwidth remaining percent command. The reservation does not affect the calculation of available bandwidth (it is not a fixed guarantee).
The bandwidth remaining percent command allows you to allocate bandwidth as a relative percentage of the total bandwidth available on the interface. This command allows you to specify the relative percentage of the bandwidth to be allocated to the classes of traffic. In this example, 20 percent of the available bandwidth is allocated to Class1 and 20 percent to Class2. Essentially, you are specifying the ratio of the bandwidth to be allocated to the traffic class. The sum of the numbers used to indicate this ratio cannot exceed 100 percent. This way, you need not know the total amount of bandwidth available, just the relative percentage you want to allocate for each traffic class. Each traffic class gets a minimum bandwidth as a relative percentage of the remaining bandwidth. The remaining bandwidth is the bandwidth available after the priority queue, if present, is given its required bandwidth, and after any Resource Reservation Protocol (RSVP) flows are given their requested bandwidth.
9-32
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ Example 3 Router#show Router#show interface interface fastethernet fastethernet 0/0 0/0 FastEthernet0/0 FastEthernet0/0 is up, line line protocol protocol is is up up Hardware Hardware is is AmdFE, AmdFE, address address is is 0030.8546.aa00 0030.8546.aa00 (bia (bia 0030.8546.aa00) 0030.8546.aa00) Internet Internet address address is is 10.1.1.1 10.1.1.1/24 /24 MTU MTU 1500 1500 bytes, bytes, BW BW 10000 10000 Kbit, Kbit, DLY DLY 1000 1000 usec, usec, reliability reliability 255/255, 255/255, txload txload 1/255, 1/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation ARPA, ARPA, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) Half-duplex, Half-duplex, 10Mb/s, 10Mb/s, 100BaseTX/FX 100BaseTX/FX ARP type: ARPA, ARP ARP type: ARPA, ARP Timeout Timeout 04:00:00 04:00:00 Last Last input input 00:00:00, 00:00:00, output output 00:00:03, 00:00:03, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total output drops: d rops: 0 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 0/1000/64/0 0/1000/64/0 (size/max (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 0/1/256 0/1/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 2/2 2/2 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 7000 7000 kilobits/sec kilobits/sec ... ...
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-36
The show interface command confirms the calculation of available bandwidth for Example 3.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-33
Monitoring and Troubleshooting CB-WFQ Router#
show policy-map interface [intf]
• Displays parameters and statistics of CB-WFQ Router#show -map interface Router#show policy policy-map interface FastEthernet0/0 FastEthernet0/0 Service-policy Service-policy output: Policy1 Class-map: Class-map: Class1 Class1 (match-any) (match-any) 00 packets, packets, 00 bytes bytes 55 minute minute offered offered rate rate 0 bps, bps, drop rate 0 bps Match: Match: any any Weighted Weighted Fair Fair Queueing Queueing Output Output Queue: Queue: Conversation 265 Bandwidth Bandwidth remaining remaining 20 20 (%) (%) Max Max Threshold Threshold 64 64 (packets) (packets) (pkts (pkts matched/bytes matched/bytes matched) matched) 0/0 0/0 (depth/total (depth/total drops/no-buffer drops/no-buffer drops) drops) 0/0/0 0/0/0 Class-map: Class-map: class-default class -default (match-any) (match-any) 42 packets, 4439 bytes 42 packets, 4439 bytes 55 minute minute offered offered rate rate 0 0 bps, bps, drop drop rate rate 0 0 bps bps Match: Match: any any
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-37
The show policy-map interface command displays all service policies applied to the interface. Among the settings, policing parameters and statistics are displayed.
9-34
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting CB-WFQ Router#
show queueing fair
• Displays queuing parameters on interfaces Router#show Router#show queueing queueing fair fair Current Current fair fair queue queue configuration: configuration: Interface Interface FastEthernet0/0 FastEthernet0/0 Serial0/0 Serial0/0 Serial0/1 Serial0/1
Discard Discard threshold threshold 64 64 64 64 64 64
CB-WFQ reserves 64 queues in the WFQ system
© 2001, Cisco Systems, Inc.
Dynamic Dynamic queues queues 256 256 32 32 32 32
Reserved Reserved queues queues 64 64 00 00
Link Link queues queues 88 88 88
Prio Priority rity queues queu es 11 11 11
One queue is reserved for IP RTP Prioritization
IP QoS Modular QoS CLI Service Policy-38
The show queueing fair command displays all interfaces using Weighted Fair Queuing. The FastEthernet interface show there are 64 reserved queues (for CB-WFQ). One queue is used for IP RTP prioritization. The discard threshold is the number of packets than have to be in the queuing system to start dropping packets in the longest queue. The number of dynamic queues specifies how many queues are used in the default class if flow-based WFQ is used. WFQ reserves 8 queues (link queues) for PAK_Priority packets (link-level messages and keepalives, routing protocol hello messages and keepalives etc.).
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-35
Monitoring and Troubleshooting CB-dWFQ Router#
show queueing interface [intf]
• Displays queuing parameters on a specific VIP-based interface c7500#show c7500#show queueing queueing interface interface serial serial 5/1/0 5/1/0 Interface -based fair Interface Serial5/1/0 Serial5/1/0 queueing queueing strategy: strategy: VIP VIP-based fair queueing queueing Serial5/1/0 Serial5/1/0 queue queue size size 00 pkts pkts output output 0, 0, wfq wfq drops drops 0, nobuffer nobuffer drops drops 00 WFQ: WFQ: aggregate aggregate queue queue limit limit 00 max max available available buffers buffers 00 Class Class 0: 0: weight weight 50 50 limit limit 250 250 qsize qsize 00 pkts pkts output output 00 drops drops 0 0 Class Class 23: 23: weight weight 30 30 limit limit 150 150 qsize qsize 00 pkts pkts output output 00 drops drops 00 Class Class 24: 24: weight weight 20 20 limit limit 100 100 qsize qsize 00 pkts pkts output output 00 drops drops 00
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-39
The show queueing interface command can be used to display the parameters and statistics of distributed Weighted Fair Queuing (dWFQ) on Cisco 7x00 series routers using Versatile Interface Processors (VIPs).
9-36
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Summary Class-based Weighted Fair Queuing (CB-WFQ) is a queuing mechanism that can provide bandwidth guarantees for up to 64 classes on one interface. Bandwidth guarantees can be configured by specifying: n
A fixed guarantee in kbps
n
A fixed guarantee in a percentage of interface bandwidth
n
A dynamic guarantee by specifying a percentage of available bandwidth
Lesson Review 1. What type of guarantee does CB-WFQ provide? 2. Which DiffServ PHB can be implemented using CB-WFQ? 3. What configuration steps are needed to configure CB-WFQ?
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-37
Class-based WRED Overview This lesson describes the WRED feature and shows how and where it can be used in the MQC.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
9-38
n
Describe Class-based Weighted Random Early Detection (CB-WRED)
n
Configure CB-WRED
n
Monitor and troubleshoot CB-WRED
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based WRED • Class-based WRED can be used in combination with CB-WFQ • Using CB-WFQ with WRED allows the implementation of DiffServ’s Assured Forwarding PHB • Class-based configuration of WRED is identical to standalone WRED • Flow-based WRED is not available with the Modular QoS CLI
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-44
Congestion avoidance techniques monitor the network interface load in an effort to anticipate and avoid congestion at common network bottlenecks. Congestion avoidance is achieved through packet dropping using more complex techniques. Traditionally, Cisco IOS used standalone RED and WRED mechanisms, as described in the A_QoS_CongestAvoid module, to avoid congestion on an interface. Those mechanisms can perform a differentiated drop based on the IP precedence or DSCP-value. The Class-Based Weighted Fair Queueing (CB-WFQ) system supports the use of WRED inside the queueing system, therefore implementing Class-based WRED. Each class is queued in its separate queue, and has a queue limit, performing taildrop by default. WRED can be configured as the preferred dropping method in a queue, implementing a differentiated drop based on traffic class and further on the IP precedence or DSCP value. Note
The combination of CB-WFQ with WRED on a single device is currently the only way to implement the DiffServ’s Assured Forwarding Per-Hop Behavior (AF PFB) using Cisco IOS software.
The class-based configuration of WRED is analogous to standalone WRED configuration. Flow-based WRED (FRED) is not available within the CB-WFQ queueing system and the Cisco IOS MQC.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-39
RED Profile Drop Probability
No drop
Random drop
Full drop
100%
Maximum Drop Probability
10% 20
Minimum Threshold
40
Average Queue Size
Maximum Threshold
• WRED starts randomly dropping packets when the average queue size is above the minimum threshold © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-45
RED is currently the primary congestion avoidance method used on router interfaces. Random Early Detection is a dropping mechanism that randomly drops packets before a queue is full. The dropping strategy is based primarily on the average queue length. When the average queue gets longer (fuller), RED will be more likely to drop an incoming packet than when the queue is shorter. Because RED drops packets randomly, it has no per-flow intelligence. The rationale behind this is that an aggressive flow will represent most of the arriving traffic. Therefore it is more probable that RED will drop a packet of an aggressive session. RED therefore punishes more aggressive sessions with higher statistical probability, and is able to somewhat selectively slow down the most significant cause of congestion. Directing one TCP session at a time to slow down allows for the full utilization of the bandwidth, rather than a utilization that manifests itself as crests and troughs of traffic. As a result, the TCP global synchronization is much less likely to occur, and TCP can utilize the bandwidth more efficiently. The average queue size also decreases significantly, because the possibility of the queue filling up is very small. This is due to very aggressive dropping in the event of traffic bursts, when the queue is already quite full. RED distributes losses over time and maintains normally low queue depth while absorbing spikes. RED can also utilize IP precedence or DSCP bits in packets to establish different drop profiles for different classes of traffic. The probability of a packet being dropped is based on three configurable parameters: n
9-40
Minimum threshold: When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
linearly as the average queue size increases, until the average queue size reaches the maximum threshold. n
Maximum threshold: When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.
n
Mark probability denominator: This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
These parameters define the RED profile, which implements the packet dropping strategy, which is based on the average queue length.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-41
RED Modes • RED has three modes: – No drop: when the average queue size is between 0 and the minimum threshold – Random drop: when the average queue size is between the minimum and the maximum threshold – Full drop (tail-drop): when the average queue size is at maximum threshold or above
• Random drop should prevent congestion (prevent tail-drops)
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-46
RED has three dropping modes, based on the average queue size:
9-42
n
When the average queue size is between 0 and the configured minimum threshold, no drops occur and all packets are queued.
n
When the average queue size is between the configured minimum threshold, and the configured maximum threshold, random drop occurs. Random drop is linearly proportional to the average queue length. The maximum probability of drop (when the queue is almost completely full) is 10% in Cisco IOS software if the default settings are used.
n
When the average queue size is at maximum or higher than the maximum threshold, RED performs full (tail) drop in the queue. This event is unlikely, because RED should slow down TCP traffic ahead of the congestion. If a lot of non-TCP traffic is present, RED cannot effectively drop traffic to reduce congestion, and tail-drops are likely to occur.
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
WRED Building Blocks Calculate Average Queue Size
IP packet
Queue Full?
WRED
IP precedence or DSCP
Select WRED Profile
© 2001, Cisco Systems, Inc.
Min. threshold Max. threshold Max prob. denom.
No
Current Queue Size FIFO Queue
Yes
Random Drop
Tail Drop
IP QoS Modular QoS CLI Service Policy-47
The figure shows how WRED is implemented, and what parameters influence WRED dropping decisions. The WRED algorithm is constantly updated with the calculated average queue size, which is based on the recent history of queue sizes. The configured WRED profiles define the dropping thresholds (and therefore the WRED probability slopes). When a packet arrives at the output queue, the IP precedence or the DSCP-value is used to select the correct WRED profile for the packet, and the packet is passed to WRED to perform a drop/enqueue decision. Based on the profile and the average queue size, WRED calculates the probability for dropping the current packet and then either drops it or passes it to the output queue. If the queue is already full, the packet is tail-dropped. Otherwise, it is eventually transmitted out on the interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-43
Weighted Random Early Detection • WRED uses a different RED profile for each weight • Each profile is identified by: – minimum threshold – maximum threshold – maximum drop probability
• Weight can be – IP precedence (8 profiles) – DSCP (64 profiles)
• WRED drops less important packets more aggressively than more important packets © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-48
Weighted Random Early Detection (WRED) combines RED with IP Precedence or DSCP and does packet drops based on IP Precedence or DSCP markings. WRED can selectively discard lower priority traffic when the interface begins to get congested and provide differentiated performance characteristics for different classes of service. WRED can also be configured so that non-weighted RED behavior is achieved.
9-44
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
WRED Profiles Drop Probability 100%
10% 10
20
40
Average Queue Size
• WRED profiles can be manually set • WRED has 8 default value sets for IP precedence based WRED • WRED has 64 default value sets for DSCP based WRED © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-49
The figure shows two WRED profiles, used with traffic of different QoS classes. One class has a much lower minimum and maximum threshold, and traffic of that class will be dropped much earlier and more aggressively, and will ultimately be tail dropped early, when heavy congestion occurs. The other class has a higher minimum and maximum threshold. Therefore dropping occurs later and is less likely to occur. These two classes maintain differentiated levels of service in the event of congestion. To avoid the need for setting all WRED parameters in a router, 8 default values are already defined for precedence-based WRED, and 64 DiffServ-aligned values are defined for DSCP-based WRED. Therefore, the default settings should suffice in the vast majority of deployments.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-45
IP Precedence and Class Selector Profiles Drop Probability
100%
10% IP precedence
0
20
1 2 3 4 5 6 7 RSVP 22 24 26 28 31 33 35 37 40
© 2001, Cisco Systems, Inc.
Average Queue Size
IP QoS Modular QoS CLI Service Policy-50
The Class selector range of DSCP values is used for backward compatibility with IP precedence. The same WRED profiles are applied to equal IP precedence and Class selector values:
9-46
IP precedence
DSCP (Class selector)
(three bits)
(six bits)
0
Default (0)
20
1
cs1 (8)
22
2
cs2 (16)
24
3
cs3 (24)
26
4
cs4 (32)
28
5
cs5 (40)
31
6
cs6 (48)
33
7
cs7 (56)
35
RSVP
RSVP
37
IP QoS Modular QoS CLI Service Policy
Default minimum threshold
Copyright 2001, Cisco Systems, Inc.
DSCP-based WRED (Expedited Forwarding) Drop Probability
100%
10%
EF
20
36 40
© 2001, Cisco Systems, Inc.
Average Queue Size
IP QoS Modular QoS CLI Service Policy-51
For the Expedited Forwarding DiffServ traffic class, WRED configures itself by default so that the minimum threshold is very high, thus increasing the probability of no drops being applied to that traffic class. EF-traffic is therefore expected to be dropped very late, compared to other traffic classes, and is therefore prioritized in the event of congestion. DSCP (six bits) EF (101110)
Copyright 2001, Cisco Systems, Inc.
Default minimum threshold 36
IP QoS Modular QoS CLI Service Policy
9-47
DSCP-based WRED (Assured Forwarding) Drop Probability
100%
AF Low Drop AF Medium Drop AF High Drop
10%
20 24
28 32
© 2001, Cisco Systems, Inc.
40
Average Queue Size
IP QoS Modular QoS CLI Service Policy-52
For the Assured Forwarding DiffServ traffic class, WRED configures itself by default, for three different profiles, depending on the Drop Preference DSCP marking bits. AF-traffic should therefore be classified into the three possible classes based on the application sensitivity to dropping. WRED implements a congestion avoidance PHB in agreement with the initial classification. DROP Precedence
Class #1
Class #2
Class #3
Class #4
Low Drop Prec
(AF11) 001010 (AF12) 001100 (AF13) 001110
(AF21) 010010 (AF22) 010100 (AF23) 010110
(AF31) 011010 (AF32) 011100 (AF33) 011110
(AF41) 100010 (AF42) 100100 (AF43) 100110
Medium Drop Prec High Drop Prec
9-48
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring WRED Router(config-pmap-c)#
random-detect
• Enables IP precedence based WRED in the selected class within the service policy configuration mode • Default service profile is used
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-53
The random-detect command is used to enable WRED on an interface. By default, WRED is IP precedence-based, using eight default WRED profiles. Within the CB-WFQ system, WRED is used to perform per-queue drop in the class queues. Therefore, each class queue has its own WRED method, which can be further weighed based on the IP precedence or DSCP-value. Each queue can therefore be configured with a separate dropping policy, to implement different drop policies for every class of traffic.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-49
Changing WRED Profile Router(config-pmap-c)#
random-detect precedence precedence min-threshold max-threshold mark-prob-denominator
• Changes RED profile for specified IP precedence value • Packet drop probability at maximum threshold is 1 / mark-prob-denominator • Non-weighted RED is achieved by using the same RED profile for all precedence values
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-54
In the example in the figure, WRED is enabled with default values, and then the values are changed for each IP Precedence level. The configured values are the same as for Random Early Detection, and are: n
Minimum threshold - When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold.
n
Maximum threshold - When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.
n
Mark probability denominator - This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
It is interesting to note, that the maximum probability of drop at the maximum threshold can be expressed as 1/mark-prob-denominator. The maximum drop probability is 10%, if default settings are used which have a mark probability denominator value of 10. If required, RED can be configured as a special case of WRED, by assigning the same profile to all eight IP precedence values.
9-50
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Changing WRED Sensitivity to Bursts Router(config-pmap-c)#
random-detect exponential-weighting-constant n
Qavg ( t + 1) = Qavg (t ) ⋅ (1 − 2 − n ) + Qt ⋅ 2 − n New average queue size
Previous average queue size
Current queue size
• WRED takes the average queue size to determine the current WRED mode (no drop, random drop, full drop) • High values of N allow short bursts • Low values of N make WRED more burst-sensitive • Default value (9) should be used in most scenarios • Average output queue size with N=9 is average t+1 = average t * 0.998 + queue_sizet * 0.002 © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-55
WRED does not calculate the drop probability using the current queue length, but rather uses the average queue length. The average queue length is constantly recalculated using two terms: the previously calculated average queue size and the current queue size. An exponential weighting constant N influences the calculation by weighing the two terms, therefore influencing how the average queue size follows the current queue size, in the following way: n
A low value of N makes the current queue size more significant in the new average size calculation, therefore more sensitive to bursts
n
A high value of N makes the previous average queue size more significant in the new average seize calculation, so that bursts influence the new value to a smaller degree.
The default value is 9 and should suffice for most scenarios, except perhaps those involving extremely high-speed interfaces (e.g. OC12), where it can be increased slightly (to about 12) to allow more bursts.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-51
Configuring DSCP-based WRED Router(config-pmap-c)#
random-detect {prec-based | dscp-based}
• Selects WRED mode • Precedence-based WRED is the default mode • DSCP-based uses 64 profiles
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-56
The random-detect dscp-based command is used to enable DSCP-based WRED on an interface, using the 64 default DSCP-based WRED profiles.
9-52
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Changing the WRED Profile Router(config-pmap-c)#
random-detect precedence precedence min-threshold max-threshold mark-prob-denominator
• Changes RED profile for specified IP precedence value • Packet drop probability at maximum threshold is 1 / mark-prob-denominator • Non-weighted RED is achieved by using the same RED profile for all precedence values
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-54
The DSCP-weighted WRED profiles can be changed, using the known three WRED parameters. The mask-prob-denominator defines the packet drop probability at the WRED maximum threshold. The maximum drop probability is 10%, if default settings are used which have a mark probability denominator value of 10. Normally, the DSCP-weighed profiles should be left at their default settings, because those settings are appropriate for most situations, if the traffic is classified according to the DiffServ service specification.
Copyright 2001, Cisco Systems, Inc.
IP prcecdence
Default minimum threshold
0
20
1
22
2
24
3
26
4
28
5
31
6
33
7
35
RSVP
37
IP QoS Modular QoS CLI Service Policy
9-53
9-54
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ with WRED Example 1 • Enable CB-WFQ to prioritize traffic according to the following requirements: – Class Gold is marked with IP precedence values 3 and 4 (3 is high drop, 4 is low drop) and should get 30% of interface bandwidth – Class Silver is marked with IP precedence values 1 and 2 (1 is high drop, 2 is low drop) and should get 20% of interface bandwidth – All other traffic should be per -flow fair-queued
• Use differentiated WRED to prevent congestion in all three classes (try to set up your own WRED profiles for Gold and Silver) © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-58
The first CB-WFQ with WRED example focuses on a network, which provides three different service levels for three traffic classes n
The Gold class, marked with IP precedence values of 3 and 4 (3 is used for high drop, and 4 is used for low drop within the service class) should get 30% of an interface bandwidth
n
The Silver class, marked with IP precedence values of 1 and 2 (1 being highdrop, and 2 being low-drop service) should get 20% of the interface bandwidth.
n
Best effort traffic should get the remaining bandwidth share, and should be fair-queued.
To enforce this service policy, a router will use CB-WFQ to perform bandwidth sharing, and WRED within service classes to perform differentiated drop.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-55
CB-WFQ with WRED Example 1 class-map class-map Gold Gold match 3 4 match ip ip precedence precedence 3 4 !! class-map class-map Silver Silver match match ip precedence 1 2 !! policy-map policy-map Policy1 Policy1 class class Gold Gold bandwidth bandwidth percent percent 30 30 random-detect random-detect random-detect random-detect precedence precedence random-detect random-detect precedence precedence class class Silver Silver bandwidth bandwidth percent percent 20 20 random-detect random-detect random-detect random-detect precedence precedence random-detect random-detect precedence precedence class class class-default class-default fair-queue fair-queue random-detect random-detect !! © 2001, Cisco Systems, Inc.
3 20 40 10 4 30 40 10
1 15 35 10 2 20 35 10
IP QoS Modular QoS CLI Service Policy-59
The figure shows a configuration implementing the example service policie s. The traffic is classified based on the precedence bits, and all non-contract traffic is classified into the default class.
9-56
n
The Gold class is guaranteed at least 30 percent of bandwidth, with a custom WRED profile, which establishes a low-drop and a high-drop per-hop behavior.
n
The Silver class is guaranteed at least 20 percent of bandwidth, is configured with somewhat lower WRED drop thresholds, and is therefore more likely to be dropped than the Gold class in the event of interface congestion.
n
All other traffic is part of the default class, is fair-queued, with default WRED parameters.
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ with WRED Example 2 • Use the QoS design from the previous example • Implement it using DSCP: – Class “Gold” is using AF1 – Class “Silver” is using AF2
• Make sure the new configurations still conform to the design and implementation from the previous example
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-60
CB-WFQ with WRED Example 1 was implemented using a CoS based on the precedence bit. In this example, the same policy is configured, but DSCP-based CoS classification and QoS services are used. Remember that the DiffServ model itself provides defined traffic classes and their associated PHB. DiffServ-based classification is used in this example.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-57
CB-WFQ with WRED Example 2 class-map class-map Gold Gold match match ip ip dscp dscp af11 af11 af12 af12 af13 af13 cs3 cs3 cs4 cs4 !! class-map class-map Silver Silver match match ip dscp dscp af21 af21 af22 af22 af23 af23 cs1 cs1 cs2 cs2 !! policy-map policy-map Policy1 Policy1 class class Gold Gold bandwidth bandwidth percent percent 30 30 random-detect -based random-detect dscp dscp-based random-detect random-detect dscp dscp af11 af11 30 30 40 40 10 10 random-detect random-detect dscp dscp af12 af12 25 25 40 40 10 10 random-detect random-detect dscp dscp af13 af13 20 20 40 40 10 10 random-detect random-detect dscp dscp cs3 cs3 20 20 40 40 10 10 random-detect random-detect dscp cs4 30 40 10
© 2001, Cisco Systems, Inc.
class class Silver Silver bandwidth bandwidth percent percent 20 20 random-detect -based random-detect dscp dscp-based random-detect random-detect dscp dscp af11 af11 25 25 35 35 10 10 random-detect random-detect dscp dscp af12 af12 20 20 35 35 10 10 random-detect random-detect dscp dscp af13 af13 15 15 35 35 10 10 random-detect random-detect dscp dscp cs3 cs3 15 15 35 35 10 10 random-detect random-detect dscp dscp cs4 cs4 25 25 35 35 10 10 class class class-default class-default fair-queue fair-queue random-detect -based random-detect dscp dscp-based !!
IP QoS Modular QoS CLI Service Policy-61
The configuration example shows how traffic classification is performed using DSCP-based classes, representing the Gold class as the AF1 class, and using the AF2 class as the Silver class. WRED DSCP-based parameters are sent reflecting the class-dependent drop strategy.
9-58
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting CB-WRED Router#show -map interface Router#show policy policy-map interface fastEthernet fastEthernet 0/0 0/0 FastEthernet0/0 FastEthernet0/0 Service-policy Service-policy output: Policy1 Class-map: Class-map: Gold (match-all) (match -all) 00 packets, packets, 00 bytes bytes 55 minute offered minute offered rate rate 0 bps, bps, drop rate 0 bps Match: Match: ip ip precedence precedence 33 44 Match: Match: ip ip dscp dscp 10 10 12 12 14 14 24 24 32 32 Weighted Weighted Fair Fair Queueing Queueing Output Output Queue: Queue: Conversation Conversation 265 265 Bandwidth Bandwidth 30 30 (%) (%) Bandwidth 3000 (kbps) Bandwidth 3000 (kbps) (pkts (pkts matched/bytes matched/bytes matched) matched) 0/0 0/0 (depth/total (depth/total drops/no-buffer drops/no-buffer drops) drops) 0/0/0 0/0/0 exponential exponential weight: weight: 99 mean queue depth: 0 mean queue depth: 0 Dscp Dscp (Prec) (Prec) 0(0) 0(0) 11 22 33
Random Random drop drop pkts/bytes pkts/bytes 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0
Tail drop pkts/bytes pkts/bytes 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0
Minimum Maximum Mark threshold threshold threshold threshold probability probability 20 40 1/10 20 40 1/10 22 40 1/10 22 40 1/10 24 40 1/10 24 40 1/10 26 40 1/10 26 40 1/10
... ... © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-62
The show policy-map interface command shows the service policy applied to an interface, including all WRED parameters implementing the dropping policy on that interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-59
Summary n
WRED can be used inside the Cisco IOS CB-WFQ, configured via the MQC
n
WRED can be applied per-service policy
n
All WRED parameters are inherited from the traditional Cisco IOS WRED implementation
Lesson Review 1. How does WRED supplement CB-WFQ? 2. Can WRED be combined with flow-based WFQ in the default class? 3. Which two operational modes does WRED support? 4. How many profiles does WRED support?
9-60
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Low-latency Queuing Overview This lesson describes the Low-latency Queueing (LLQ) feature within the CBWFQ system.
Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe Class-based Low-latency Queuing (CB-LLQ)
n
Configure CB-LLQ
n
Monitor and troubleshoot CB-LLQ
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-61
Class-based Low-latency Queuing • VoIP or other multimedia applications should not be fair-queued with other data • IP RTP Prioritization has a number of drawbacks: – It is not selective enough (filters only on UDP port range) – It does not support TCP or other protocols – You can only specify overall high-priority traffic rate
• Class-based Low-latency Queuing (CB-LLQ) removes most of the drawbacks of IP RTP Prioritization © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-67
While Weighed Fair Queuing (WFQ) provides a fair share of bandwidth to every flow, and provides fair scheduling of its queues, it cannot provide guaranteed bandwidth and low delay to select applications. Voice traffic, for example, may still compete with other aggressive flows in the WFQ queuing system, which lacks priority scheduling for time-critical traffic classes. IP RTP Prioritization is one Cisco IOS feature designed to guarantee priority of voice traffic. However, because it only can only prioritize pure RTP traffic (IP RTP Prioritization uses a UDP port range heuristic to distinguish RTP from the rest of the traffic), and lacks flexibility in policing, it does not present a via ble solution when multiple non-RTP time-critical applications are deployed in the network. Class-based Low-latency Queueing (CB-LLQ) is a method, used within the CBWFQ framework, which can prioritize traffic flows with the flexibility of the Cisco IOS MQC interface.
9-62
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Low-Latency Queueing Queuing and Scheduling Forwarder
Class Priority
Yes
BW Policing
Yes
BW Policing
Yes
Flow queue (FIFO)
Yes
Priority queue (FIFO)
No
Class Priority No
Class N?
WFQ Scheduling
No
Class Default?
© 2001, Cisco Systems, Inc.
WFQ/FIFO
IP QoS Modular QoS CLI Service Policy -68
When CB-WFQ is configured as the queueing system, it creates a number of queues, into which it classifies traffic classes. These queues are then scheduled with a WFQ-like scheduler, which can guarantee bandwidth to each class. If Class-based Low-latency Queuing is used within the CB-WFQ system, it creates additional, priority queues in the WFQ system, which are serviced by a strict priority scheduler. Any class of traffic can therefore be attached to a service policy, which uses priority scheduling, and hence can be prioritized over other classes.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-63
CB-LLQ Scheduling • High-priority classes are guaranteed: – Low-latency propagation of packets – Bandwidth
• High-priority classes are also policed – they can not exceed the guaranteed bandwidth
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-69
The CB-LLQ priority scheduler guarantees both low-latency propagation of packets and bandwidth to high-priority classes. Low-latency is achieved by expediting traffic using a priority schedule r. Bandwidth is also guaranteed by the nature of priority scheduling, but is policed to a user-configurable value. Policing of priority queues also prevents the priority scheduler from monopolizing the CBWFQ scheduler and starving non-priority classes, like legacy Priority Queuing does.
9-64
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring CB-LLQ Router(config-pmap-c)#
priority bandwidth
• Allocate a fixed amount of bandwidth (in kbps) to a class and ensure expedited forwarding • Traffic exceeding the specified bandwidth is dropped Router(config-pmap-c)#
priority percent percent
• Allocate a percentage of configured or default interface bandwidth to a class and ensure expedited forwarding • Traffic exceeding the specified bandwidth is dropped
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-70
Configured by the priority command, LLQ enables the use of a single priority queue within CBWFQ at the class level, allowing the user to direct traffic belonging to a class to the CBWFQ priority queue. To enqueue class traffic to the priority queue, configure the priority command for the class after the named class is specified within a policy map. Classes to which the priority command is applied are considered priority classes. One or more classes can be given priority status within a policy map. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is enqueued to the same, single, priority queue. The bandwidth and percent options allocate a fixed amount of bandwidth (in kbps) to the priority class, using absolute or relative bandwidth respectively. The priority queue is policed using this bandwidth parameter and all exceeding packets are dropped. Keep the following guidelines in mind when using the priority command: n
Layer 2 encapsulations are accounted for in the amount of bandwidth specified with the priority command. However, ensure a bandwidth is configured that has room for cell-tax overhead and possible jitter introduced by the routers in the voice path.
n
Use the priority command for VoIP on serial links and ATM PVCs. It does not support VoIP over Frame Relay links.
n
Use the priority command in conjunction with the set command. You cannot use the priority command in conjunction with any other command, including the random-detect, queue-limit, and bandwidth commands.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-65
n
9-66
You can configure the priority command in multiple classes, but you should only use it for voice-like, constant bit rate (CBR) traffic. If the traffic is not CBR, you must configure a large enough bandwidth parameter to absorb the data bursts.
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-LLQ Example class-map class-map VoIP VoIP match match ip ip precedence precedence 55 !! class-map class-map Gold Gold match match ip precedence 3 4 !! class-map class-map Silver Silver match 1 2 match ip ip precedence precedence 1 2 !! policy-map policy-map Policy1 Policy1 class class VoIP priority priority percent percent 10 10 class class Gold Gold bandwidth bandwidth percent percent 30 30 random-detect random-detect class class Silver bandwidth bandwidth percent percent 20 20 random-detect random-detect class class class-default class-default fair-queue fair-queue random-detect random-detect !! © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-71
This figure shows a configuration example, where the VoIP traffic class, classified by the IP precedence of 1, is queued in a priority queue within the CB-WFQ system. The priority class received priority scheduling compared to other classes’ queues, and is guaranteed, but limited to 10 percent of bandwidth.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-67
Monitoring and Troubleshooting CB-LLQ Router#show Router#show policy-map policy-map interface interface fastethernet fastethernet 0/0 0/0 FastEthernet0/0 FastEthernet0/0 Service-policy Service-policy output: output: LLQ LLQ Class-map: -any) Class-map: LLQ LLQ (match (match-any) 00 packets, packets, 0 0 bytes bytes 55 minute bps minute offered offered rate rate 0 0 bps, bps, drop drop rate rate 0 0 bps Match: Match: any Weighted Weighted Fair Fair Queueing Queueing Strict Strict Priority Priority Output Output Queue: Conversation 264 Bandwidth Bandwidth 1000 1000 (kbps) (kbps) Burst Burst 25000 25000 (Bytes) (Bytes) (pkts (pkts matched/bytes matched/bytes matched) matched) 0/0 0/0 (total (total drops/bytes drops/bytes drops) drops) 0/0 0/0 Class-map: -default (match -any) Class-map: class class-default (match-any) 00 packets, packets, 0 bytes 55 minute bps minute offered offered rate rate 0 0 bps, bps, drop drop rate rate 0 0 bps Match: Match: any any
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-72
The show policy-map interface command shows the service policy settings on an interface. The priority scheduling method is listed, if enabled.
9-68
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Summary n
CB-LLQ guarantees priority scheduling with guaranteed bandwidth on an interface
n
CB-LLQ is integrated with CB-WFQ and configured via the Cisco IOS MQC
n
CB-LLQ is more flexible than IP RTP Prioritization
Lesson Review 1. What advantages does CB-LLQ have over IP RTP Prioritization? 2. What guarantees does CB-LLQ provide?
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-69
Class-based Policing Overview This lesson section describes the Class-based Policing mechanism used within the CB-WFQ system. The lesson also compares Class-based Policing implementation with the standalone CAR mechanism.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
9-70
n
Describe Class-based Policing
n
Configure CB-Policing
n
Monitor and troubleshoot CB-Policing
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Policing • Class-based Policing is used to limit a traffic class to a configured bit rate • It uses a Token Bucket model to measure the arrival rate of packets • Class-based Policing is an improved version of the Committed Access Rate (CAR) mechanism • Class-based Policing is configured using the Modular QoS CLI
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-77
Class-based Policing allows the servic e provider to rate-limit traffic in and out of the router interfaces to a configured bit rate, thereby enabling various forms of ingress and egress rate-limiting in a network. Class-based policing is implemented within the CB-WFQ queueing method, and configured via the Cisco IOS MQC. Like Committed Access Rate (CAR), Class-based Policing simply rate-limits traffic according to a simple “forward or drop” policy, according to the configuration. Class-based policing also uses a token-bucket metering mechanism, similar to CAR, but with some modification and added flexibility.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-71
How do Routers Measure Traffic Rate Bandwidth
Link bandwidth Exceeding traffic Rate limit Conforming Traffic Time
• Routers use the Token Bucket mathematical model to keep track of packet arrival rate • The Token Bucket model is used whenever a new packet is processed • The return value is conform or exceed © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-78
In order to perform rate limiting, routers must meter (or measure) traffic rates through its interfaces. To enforce a rate limit, metered traffic is said to: n
Conform to the rate limit, if the rate of traffic is below the configured rate limit
n
Exceed the rate limit, if the rate of traffic is above the configured rate limit
The metering is usually performed with an abstract mathematical model called a token bucket, which is used when processing each packet. The token bucket can calculate whether the current packet conforms or exceeds the configured rate limit on an interface.
9-72
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Token Bucket
700
500 bytes
© 2001, Cisco Systems, Inc.
Conform Action
500 bytes
IP QoS Modular QoS CLI Service Policy-79
The token bucket is a mathematical model used in a device that regulates the data flow. The model has two basic ingredients: n
Tokens, where each token represents the permission to send a fixed number of bits into the network
n
The bucket, which has the capacity to hold a specified amount of tokens
Tokens are put into the bucket at a certain rate by the operating system. Each incoming packet, if forwarded, takes tokens from the bucket, representing the packet’s size. If not enough tokens are available in the bucket to send the packet, the policer discards the packet. If the bucket fills to capacity, newly arriving tokens are discarded, and discarded tokens are not available to future packets. The figure shows a token bucket, with the current capacity of 700 bytes. When a 500-byte packet arrives at the interface, its size is compared to the bucket capacity (in bytes). The packet conforms to the rate limit (500 bytes < 700 bytes), the packet is forwarded, and 500 bytes worth of tokens are removed from the bucket.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-73
Token Bucket
200
300 bytes
Exceed Action
s byte 300
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-80
When the next packet arrives immediately after the first packet, and because no new tokens have been added to the bucket (which is done periodically), there are not enough tokens in the bucket to represent the current packet. The current packet therefore exceeds the rate limit and is dropped.
9-74
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Token Bucket Be
Bc of tokens is added every Tc [ms]
Link BW
Link Utilization Bc
Bc
Bc
Bc
Bc
Bc
2*Tc
3*Tc
4*Tc
5*Tc
Tc = Bc / CIR Tc
Average BW (CIR)
Time
Be
• Bc is normal burst size (specifies sustained rate) • Be is excess burst size (specifies length of burst)
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-81
Token bucket implementations usually rely on three parameters: CIR, Bc and Be. CIR is the Committed Information Rate (also called the committed rate), which represents the long-term average rate of traffic. Bc is known as the burst capacity. Be is known as the excess burst capacity. Tc is a time interval constant. In the token bucket metaphor, tokens are put into the bucket at a certain rate, which is Bc tokens every Tc seconds. The bucket itself has a specified capacity. If the bucket fills to capacity (Bc + Be), newly arriving tokens are discarded. Each token is permission for the source to send a certain number of bits into the network. To send a packet, the regulator must remove, from the bucket, the number of tokens equal in representation to the packet size. For example, if 8000 bytes worth of tokens are placed in the bucket every 125 milliseconds, the router can steadily transmit 8000 bytes every 125 milliseconds, if traffic constantly arrives at the router. If there is no traffic at all, 8000 bytes per 125 milliseconds get accumulated in the bucket, up to the maximum size (Bc+Be). One second’s accumulation therefore collects 64000 bytes worth of tokens, which can be transmitted immediately in the case of a burst. The upper limit, Bc+Be, defines the maximum amount of data, which can be transmitted in a single burst, at the line rate. A token bucket permits burstiness but bounds it. It guarantees that the burstiness is bounded so that the flow will never send faster than the token bucket's capacity. This means, that in the long-term, the transmission rate will not exceed the established rate at which tokens are placed in the bucket (the committed rate).
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-75
Class-based Policing • CAR uses one single token bucket to determine if a packet conforms to or exceeds the bit-rate policy • CB-Policing uses one or two token buckets to determine if a packet: – Conforms – is within the average bit rate – Exceeds – exceeds the average bit rate but is within the allowed excess burst – Violates – exceeds both the average bit rate and the allowed excess burst (optional)
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-82
When CAR is in effect, its metering code uses a single token bucket, and is able to determine whether incoming traffic conforms or exceeds the configured rate-limit. Class-based Policing introduces a two-token-bucket scheme in the policer. Using two token buckets, traffic can: n
Conform to the rate limit, when it is within the average bit rate
n
Exceed the rate limit, when it exceeds the average bit rate, but does not exceed the allowed excess burst
n
Violate the rate limit, when it exceeds both the average rate and the excess bursts.
The double token bucket method is explained later in the lesson.
9-76
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Policing Actions • CB-Policing can execute three different actions (conform, exceed or violate) • Each action can be one of the following: – Transmit – Drop – Set IP Precedence and transmit – Set IP DSCP and transmit – Set QoS group and transmit – Set MPLS experimental bits and transmit – Set Frame Relay DE bit and transmit – Set ATM CLP bit and transmit © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-83
Based on the current packet conforming, exceeding, or violating the rate limit, an action can be taken by the policer. The CB-WFQ policer supports the following actions: n
Transmit—the packet is transmitted
n
Drop—the packet is dropped
n
Set precedence (or DSCP value) and transmit: the IP Precedence (ToS) or DSCP bits in the packet header are rewritten. The packet is then transmitted. This action can be used to either color (set precedence) or recolor (modify existing packet precedence) the packet.
n
Set QoS group and transmit: the QoS group can be set and then used only locally within the router. The QoS group can be used in later QoS mechanisms and performed in the same router, such as CB-WFQ. The packet is then transmitted.
n
Set MPLS experimental bits and transmit: the MPLS experimental bits can be set. The packet is then transmitted. These are usually used to signal QoS parameters in a MPLS cloud.
n
Set Frame Relay DE bit and transmit: the Frame Relay Discard Eligibility (DE) bit is set in the Layer-2 (Frame Relay) header and the packet is transmitted. This setting can be used to mark excessive or violating traffic (which should be dropped with preference on Layer-2 switches) at the edge of a Frame Relay network.
n
Set ATM CLP bit and transmit: the ATM Cell Loss Priority (CLP) bit is set in the Layer-2 (ATM) header and the packet is transmitted. This setting
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-77
can be used to mark excessive or violating traffic (which should be dropped with preference on Layer-2 switches) at the edge of an ATM network.
9-78
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Single Token Bucket with Class-based Policing
700
500 bytes
BE
Conform Action
• Packet conforms to the policy if the size of the packet is less or equal to the number of tokens in the TB © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-84
Class-based Policing can use a single or double token bucket method as the metering mechanism. The one token bucket algorithm is used when the violateaction option is not specified in the police MQC command. If one token bucket is used, the meter can only differentiate between conforming and exceeding traffic. Therefore, in a simple single token bucket algorithm, a packet conforms to the line rate, if the size of the packet is less or equal to the number of tokens in the token bucket. The actual metering algorithm used by CB-Policing is somewhat different from a pure token bucket, described above, and used by CAR. With CAR, the token bucket is refilled at periodic intervals (Tc) with a fixed number of tokens (Bc). Class-based policing employs a different method, which calculates the bucket size and adds tokens on every processed packet. The Class-based policing works in the following manner: n
The token bucket is initially set to the full size (the full size is the number of bytes specified as the normal burst size or Bc)
n
When a packet of size B bytes arrives at time t the following actions occur: –
Tokens are updated in the conform bucket. If the previous arrival of the packet was at t1 and the current time is t, the bucket is updated with (t-t1) worth of bits based on the token arrival rate. The perpacket token arrival rate is calculated as: (time between consecutive packets * policer rate)/8 bytes
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-79
9-80
–
If the number of bytes in the conform bucket - B is greater than or equal to 0, the packet conforms and the conform action is taken on the packet. If the packet conforms, B bytes are removed from the conform bucket and the conform action is completed for the packet.
–
If the number of bytes in the conform bucket - B is less than 0, the exceed action is taken.
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Single Token Bucket with Class-based Policing
200
300 bytes
BE
Exceed Action
• Packet exceeds the policy if the size of the packet is more than the number of tokens in the TB © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-85
When a packet size is more than the available number of tokens in a TB, the packet exceeds the rate limit. Again, this is a simplified algorithm for a pure token bucket. Class-based policing uses a slightly different algorithm, which was described previously.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-81
Double Token Bucket with Class-based Policing
700
500 bytes
BC
400
BE
Conform Action
• Packet conforms to the policy if the size of the packet is less or equal to the number of tokens in the first TB © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-86
Cisco IOS Class-based policing uses a double token bucket metering method, when the violate action is specified in the police MQC command. One bucket is used to meter conforming traffic (the conform bucket), and is of size BC. The other bucket is used to meter exceeding traffic, and is of size BE. The conform bucket is initially full (the full size is the number of bytes specified as the normal burst size, BC). The exceed bucket is also initially full (the full exceed bucket size is the number of bytes specified in the maximum burst size, BE). The tokens for both the conform and exceed token buckets are updated based on the token arrival rate (or CIR). In simple terms, with the double token bucket system, an incoming packet conforms to the rate limit, if the conform bucket has enough tokens for the size of the packet. Looking into the details of the algorithm, the actual processing which occurs is as follows: n
A packet of size B bytes arrives at time t
n
Tokens are updated in the conform bucket. If the previous arrival of the packet was at t1 and the current arrival of the packet is at t, the bucket is updated with t-t1 worth of bits based on the token arrival rate. The refill tokens are placed in the conform bucket. If the tokens overflow the conform bucket, the overflow tokens are placed in the exceed bucket. The token arrival rate is calculated as follows: (time between packets<which is equal to t-t1> * policer rate)/8 bytes
9-82
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
n
If the number of bytes in the conform bucket - B is greater than or equal to 0, the packet conforms and the conform action is taken on the packet. If the packet conforms, B bytes are removed from the conform bucket and the conform action is taken. The exceed bucket is unaffected in this scenario.
n
If the number of bytes in the conform bucket - B is less than 0, the excess token bucket is checked for bytes by the packet. If the number of bytes in the exceed bucket - B is greater than or equal to 0, the exceed action is taken and B bytes are removed from the exceed token bucket. No bytes are removed from the conform bucket.
n
If the number of bytes in the exceed bucket - B is less than 0, the packet violates and the violate action is taken. The action is complete for the packet.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-83
Double Token Bucket with Class-based Policing
200
300 bytes
BC
400
BE
Exceed Action
• Packet exceeds the policy if the size of the packet is more than the number of tokens in the first TB and less or equal to the number of tokens in the second TB © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-87
If looking at the double token bucket in a simplified way, an incoming packet would exceed the rate limit, if the conform bucket does not have enough tokens for the size of the packet, but the exceed bucket does. For a detailed insight, consult the previously laid-out algorithm.
9-84
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Double Token Bucket with Class-based Policing
200
400 bytes
BC
100
BE
Violate Action
• Packet violates the policy if the size of the packet is more than the number of tokens in the first and the second TB © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-88
In simple terms, the double token bucket system means that an incoming packet violates the rate limit, if neither the conform nor the exceed buckets have enough tokens for the size of the packet. For a detailed insight, consult the previously laid-out algorithm
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-85
Refilling the Token Buckets Add tokens at the configured bit rate
BC
Excess spills over into the second token bucket
TB1
TB2
BE
• The number of tokens that have to be added is actually calculated every time a new packet has to be processed:
TB1 = min(B C, TB1 + (Tnow -TLastPacket) * BitRate / 8) New size of the token bucket © 2001, Cisco Systems, Inc.
Previous size of the token bucket
Time now [seconds]
Time of the last packet [seconds]
IP QoS Modular QoS CLI Service Policy -89
The detailed token bucket algorithms are somewhat different from the classic token bucket algorithms used by CAR and GTS. Token refilling is done per packet, which can considerably smooth out rate limiting, because there is no fixed interval (Tc) for bucket refills. Instead, the calculation TB1_after = min(BC, TB1_before + (Tnow -TLastPacket ) * BitRate / 8) where TB1 is the token bucket size, BC is the maximum conform token bucket size, Tnow is the current time, TLastPacket is the time of arrival of the previous packet, and the BitRate is the CIR of the rate limit, defines the new size of the conform bucket, and is calculated for each incoming packet. If the number of tokens exceeds the size of the conform bucket (BC), excess tokens spill over and fill the second (exceed) bucket. If the exceed bucket overflows with tokens, those tokens are lost. The new token bucket size, therefore, equals to the BC (Conform Bucket Size) or the “Previous bucket size + added tokens since the last packet was transmitted”, which ever is smaller.
9-86
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring Class-based Policing Router(config-pmap-c)#
police avg-rate [BCC [BEE]] [conform-action [action] [exceed-action [action] [violate-action [action]]]] • avg-rate – traffic rate in bps (8.000 to 200.000.000) • BC – normal burst sets the size of the first token bucket in bytes (default is 1500 or avg-rate/32; whatever is higher) • BE – excess burst sets the size of the second token bucket in bytes (equals BC if not configured) • action – can be: • • • • • • • •
transmit (default conform action) drop (default exceed and violate action) set-prec-transmit ip-precedence set-dscp-transmit dscp set-qos-transmit qos-group set-mpls-exp-transmit mple-exp set frde-transmit set-clp-transmit
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-90
The police MQC command defines policing parameters for a traffic class. The avg-rate parameter defines the policed average traffic rate (CIR), the BC and BE define the double token bucket sizes, and the action defines an action for conforming, exceeding, and optionally violating traffic.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-87
Class-based Policing Example
• The customer can locate his server at service provider premises (switched LAN) • CB-Policing is used to limit the amount of traffic the web server can generate (more flexible perbandwidth pricing) • Unknown traffic is rate-limited to 64 kbps to allow remote configuration of new servers © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-91
This example uses Class-based Polic ing to perform rate-limiting of end-station traffic. The example setting is a hosting-farm, where a service provider needs to limit the amount of traffic a web-server can send towards its clients. All traffic from a particular server will be rate-limited according to a contract, and 64 kbps of bandwidth will be reserved for unknown traffic, such as future provisioning and configuration of new servers in the farm.
9-88
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Policing Example class-map class-map www.acme.com www.acme.com match match source-address source-address mac mac 000d.dddf.0480 000d.dddf.0480 !! class-map class-map www.void.com www.void.com match match source-address source-address mac mac 000d.dddc.ad21 000d.dddc.ad21 !! policy-map policy-map ServerFarm class www.acme.com police police 128000 128000 conform-action conform-action transmit transmit exceed-action exceed-action drop class www.void.com police police 256000 256000 conform-action conform-action transmit transmit exceed-action exceed-action drop class class-default police 64000 !! interface interface FastEthernet FastEthernet 0/0 service-policy input ServerFarm !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-92
The configuration example shows three configured traffic classes, two based on upstream MAC addresses, and one on the default traffic class. Traffic from particular servers is policed to a fixed bandwidth, and exceeding traffic is dropped. If Bc and Be are not specified within the police command, the default value will be used.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-89
Monitoring and Troubleshooting CB-Policing Router #show policy Router#show policy interface interface fastethernet fastethernet 0/0 0/0 FastEthernet0/0 FastEthernet0/0 Service-policy input: ServerFarm (1207) Service-policy input: ServerFarm (1207) Class-map: Class-map: www.acme.com www.acme.com (match-all) (match-all) (1209/6) (1209/6) 00 packets, packets, 00 bytes bytes 55 minute minute offered offered rate rate 0 bps, bps, drop rate 0 bps Match: Match: ip ip precedence precedence 44 (1213) (1213) Match: Match: source-address source-address mac mac 000D.DDDF.0480 000D.DDDF.0480 (1217) (1217) police: police: 128000 128000 bps, bps, 4000 4000 limit, limit, 4000 4000 extended extended limit limit conformed conformed 00 packets, packets, 00 bytes; bytes; action: action: transmit transmit exceeded exceeded 00 packets, packets, 00 bytes; bytes; action: action: drop drop conformed 0 bps, exceed 0 bps violate 0 conformed 0 bps, exceed 0 bps violate 0 bps bps ... ... Class-map: Class-map: class-default class -default (match-any) (match-any) (1229/0) (1229/0) 00 packets, packets, 00 bytes bytes 55 minute offered rate 0 bps, drop rate 0 bps minute offered rate bps, Match: Match: any any (1233) (1233) police: police: 64000 64000 bps, bps, 2000 limit, 2000 extended limit conformed conformed 00 packets, packets, 00 bytes; bytes; action: action: transmit transmit exceeded exceeded 00 packets, packets, 00 bytes; bytes; action: action: drop drop conformed 0 bps, exceed 0 bps violate 0 conformed 0 bps, exceed 0 bps violate 0 bps bps ... ...
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-93
The show policy-map interface command displays all service policies applied to the interface. Among the settings, policing parameters and statistics are displayed. For the www.acme.com class, the CIR was set to 128000 bps, the BC defaults to 128000/32 or 4000 bytes and BE defaults to BC or 4000 bytes also.
9-90
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Summary n
Like CAR, Class-based Policing provides rate limiting of traffic
n
Class-based policing is integrated with CB-WFQ
n
Class-based policing uses a modified double token bucket mechanism for metering
Lesson Review 1. What do CAR and Class-based Policing do? 2. What are the main differences between CAR and Class-based Policing? 3. What marking options does Class-based Policing support? 4. What actions does do Class-based Policing support?
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-91
Class-based Shaping Overview This lesson describes the Class-based Shaping mechanism. The lesson also compares the Class-based Shaping implementation with the standalone GTS mechanism.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
9-92
n
Describe Class-based Shaping
n
Configure CB-Shaping
n
Monitor and troubleshoot CB-Shaping
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Shaping • Use of Class-based Shaping is similar to that of Class-based Policing • CB-Shaping is used to rate-limit packets • Delays exceeding packets rather than dropping them • Has no marking capabilities • CB-Shaping is a version of Generic Traffic Shaping (GTS) using the Modular QoS CLI
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-98
Class-based Shaping, like Class-based Policing, is used to rate-limit traffic within the CB-WFQ queueing system. Class-based Shaping works by metering the traffic rate and delaying excessive packets until they conform to the configured shaped rate. Class-based Shaping is very similar to Generic Traffic Shaping (GTS), but is implemented as a part of the CB-WFQ system and is configured via the Cisco IOS MQC. Like GTS, Class-based Shaping has no packet marking capability.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-93
CB-Shaping CB-Shaping
Check shaping queue N
Add tokens
Token Bucket
BC+BE
Enough Tokens?
Tokens
No
Do nothing
Yes
Packet size Shaping Queue N
packet
Forward
Queue N
• Router periodically updates the token bucket (every TC ) and checks if any packets can be forwarded to the main queue • T C = BC / BitRate © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-99
CB-Shaping uses the basic token bucket mechanism, where BC tokens are added at every TC time interval. If enough tokens are present in the bucket when a packet arrives, the packet is immediately forwarded. Otherwise, the packet is delayed in the shaping queue, until enough tokens are available. The router periodically checks the shaping queue by doing the following: 1. Add BC of tokens to the token bucket. 2. Check if there are enough tokens to forward a packet from the shaping queue to the main class queue. The size of the first packet in the shaping queue must be smaller or equal to the number of tokens in the token bucket. Repeat this step until there is no longer enough tokens to forward a packet or the shaping queue is empty. 3. If there are not enough tokens the router stops processing the shaping queue for another period of TC.
9-94
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Refilling the Token Bucket • CB-Shaping has two shaping methods: – Shaping to the configured average rate (adds B C tokens every TC) – Shaping to the peak rate (adds BC+B E tokens every TC)
• Average rate is forwarding packets at the configured average rate with allowed bursting up to B E when there are extra tokens available • Peak rate is forwarding packets at the peak rate which is calculated using this formula: PeakRate = AvgRate * (1+BE/BC) © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-100
Class-based Shaping can be configured in two different ways: n
Shaping to the average rate, which uses the normal token bucket refilling method, adding BC tokens every TC time interval
n
Shaping to the peak rate, which adds BC+BE tokens every TC time interval
Shaping to the average rate behaves like standard GTS; it establishes a long-term average rate, with bursts of up to BE allowed, when enough tokens are in the bucket. Shaping to the peak rate sends traffic at the peak rate, which is defined as the average rate, multiplied by (1+BE/BC). This translates to sending packets at the average rate of the excess burst size all the time, which may result in dropping in the WAN cloud.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-95
Configuring CB-Shaping Router(config-pmap-c)#
shape {average | peak} bit-rate [BCC [BEE]]
• BC and BE can be omitted to let the router select the optimal values Router(config-pmap-c)#
shape max-buffers queue-limit
• Set the maximum number of packets that can be stored in the shaping queue
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-101
The shape average and shape peak commands configure average and peak shaping respectively within the CB-WFQ system. The shape max-buffers command specifies the maximum size of the shaping queue. The shaping queue delays packets until they conform to the shaping rate. If the shaping queue is full, packets are tail-dropped.
9-96
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-Shaping Frame Relay Adaptation Router(config-pmap-c)#
shape adaptive mir-rate
• Adapts the shaping rate when BECN bits are received • Each BECN bit causes the shaping rate to be reduced to three quarters of the previous rate but not below the min-rate • This command has effect only if used on Frame Relay interfaces Router(config-pmap-c)#
shape shape fecn-adapt fecn-adapt
• Responds to FECN bits by creating test frames in the opposite direction with the BECN bit set © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-102
Class-based Shaping is able to respond to Layer-2 congestion by reducing its shaping rate to three-quarters of the current rate, until the Layer-2 network recovers from congestion. When BECN flags are no longer received, the rate is slowly ramped up again to the original shaping rate. This is also a lower limit of rate reduction, which bounds the reduction process so that at least some throughput is maintained. The BECN-integrating functionality is performed on a per subinterface (DLCI) basis. The shape adaptive command configures the Class-based Shaping system to adapt the shaping rate to BECN indications, as described above. The min-rate parameter specifies the minimum shaping rate allowed. However, if the congestion was caused by simplex traffic (such as a multicast video stream) or by an aggressive TCP connection, it is expected that the reverse traffic (frames flowing from the receiver to the sender, marked with the BECN bit) might come by less frequently than required to feed the integration. So the receiving DTE (the receiving router) can help matters when it receives a message with FECN set by first checking to see if it has any data, and if it does not, originating a message with BECN set. This message might be a Q.922 TEST RESPONSE message, which would, by virtue of its message type, be understood to be a message to discard and not reply to. This feature is called FECN-to-BECN propagation. The shape fecn-adapt command configures the Class-based Shaping system to respond to FECN-marked frames with BECN TEST frames.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-97
CB-Shaping Example class-map class-map Shape Shape match match access-group access-group 123 123 !! policy-map policy-map ShapeAvg S hapeAvg class Shape Shape shape shape average 16000 16000 1024 1024 2048 !! policy-map policy-map ShapePeak S hapePeak class Shape Shape shape shape peak peak 16000 16000 1024 2048 !! interface interface Serial0/0 Serial0/0 service-policy service-policy output ShapeAvg !! interface interface Serial0/1 Serial0/1 service-policy service-policy output ShapePeak !! access-list access-list 123 permit udp any any
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-103
This figure shows an example configuration for Class-based Shaping. All UDP traffic is classified into one class, which is shaped differently on two interfaces. On the Serial0/0 interface, all UDP traffic is shaped to the average rate, while on the Serial0/1 interface, all UDP traffic is shaped to the peak rate.
9-98
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting CB-Shaping Router#show -map interface Router#show policy policy-map interface Serial0/0 Serial0/0 Service-policy Service-policy output: output: ShapeAvg Class-map: Class-map: Shape Shape (match-all) (match-all) 782 782 packets, packets, 728824 728824 bytes bytes 55 minute offered minute offered rate rate 24000 24000 bps, bps, drop drop rate rate 22000 22000 Match: Match: access-group access -group 123 123 Traffic Traffic Shaping Target Byte Sustain Excess Interval Target Byte Rate Limit bits/int Rate bits/int bits/int bits/int (ms) (ms) 16000 384 1024 2048 64 16000 384 1024 2048 64 Queue Queue Depth Depth 64 64
Packets Packets
Bytes Bytes
135 135
125820 125820
Packets Packets Delayed Delayed 134 134
bps bps
Increment Increment Adapt Adapt (bytes) Active (bytes) Active 128 -128
Bytes Bytes Delayed Delayed 124888 124888
Shapin Shapingg Active Active yes yes
Class-map: -default (match -any) Class-map: class class-default (match-any) 99 packets, packets, 3234 3234 bytes bytes 55 minute minute offered offered rate rate 0 bps, drop rate 0 bps Match: Match: any © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-104
The show policy-map interface command displays all service policies applied to the interface. Among the settings, shaping parameters and statistics are displayed.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-99
Summary n
Class-based Shaping rate-limits traffic by delaying it in a shaping queue
n
Class-based Shaping meters traffic like GTS, using a single token bucket
n
Class-based Shaping is integrated into the CB-WFQ queuing system, configured via the Cisco IOS MQC
Lesson Review 1. What are the main differences between CB-Policing and CB-Shaping? 2. What two shaping methods does CB-Shaping support?
9-100
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Marking Overview This lesson describes the Class-based Marking capability of the Cisco IOS Modular QoS CLI (MQC).
Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe Class-based Marking
n
Configure CB-Marking
n
Monitor and troubleshoot CB-Marking
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-101
Class-based Marking • Class-based Marking is an additional tool available with the Modular QoS CLI that allows static per-class marking of packets • It can be used to mark inbound or outbound packets • It can be combined with any other QoS feature on output • It can be combined with CB-Policing on input
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-109
Marking packets or frames lets you set information in the Layer 2, 3, or 4 headers, or even set information within the payload of a packet, so the packet or frame can be identified and distinguished from other packets or frames. The CB-WFQ queuing system provides packet marking capabilities, using Classbased Marking, which is configured within the Cisco IOS MQC feature. It is perhaps the most flexible IOS marking tool, extending the marking functionality of CAR and policy routing. Class-based Marking can be used on input or output of interfaces, as a part of an input or an output service policy. On input, Class-based Marking can be combined with Class-based Policing, and on output, with any other CB-WFQ QoS feature.
9-102
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Marking • Packets can be marked with one of the following markers: – IP Precedence – IP DSCP – QoS Group – MPLS Experimental bits – IEEE 802.1Q or ISL CoS/Priority bits – Frame Relay DE bit – ATM CLP bit
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-110
Class-based Marking supports the following markers: n
IP precedence
n
IP DSCP value
n
QoS group
n
MPLS experimental bits
n
ATM CLP bit
n
Frame Relay DE bit
n
IEEE 802.1Q or ISL CoS/priority bits
Class-based marking can be combined with other mechanisms available in the Modular QoS CLI.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-103
Configuring IP Precedence Marking Router(config-pmap-c)#
set ip precedence ip-precedence • Mark IP packets with the specified IP precedence value • IP precedence can be set using a value (0 to 7) or a corresponding name (e.g. routine, priority, immediate) policy-map policy-map SetPrec SetPrec class class Class1 Class1 set ip precedence priority class class Class2 Class2 set set ip ip precedence precedence flash flash class class Class3 Class3 set ip precedence 5 !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-111
IP precedence is encoded into the three high-order bits of the ToS field in the IP header. It supports eight classes of which two are reserved and should not be used for user-defined classes (IP precedence 6 and 7). IP precedence 0 is the default value and is usually used for the best-effort class. The set ip precedence command marks packets of a class with the specified precedence value.
9-104
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring IP DSCP Marking Router(config-pmap-c)#
set ip dscp dscp • Mark IP packets with the specified DSCP value • DSCP can be set using a value (0 to 63) or a corresponding name (e.g af11, af12, af13, af21, ef, cs1, default) policy-map policy-map SetDSCP SetDSCP class class Class1 Class1 set ip dscp af11 class class Class2 Class2 set ip dscp af21 class class Class3 Class3 set ip dscp ef !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-112
DiffServ is a new model that supercedes, and is backward compatible with, IP Precedence. DiffServ uses 6 prioritization bits, which permits classification of up to 64 values (0-63). A DiffServ value is called a Differentiated Services Code Point (DSCP). The set ip dscp command is used to mark packets of a class with a DSCP value.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-105
Configuring QoS Group Marking Router(config-pmap-c)#
set qos-group qos-group
• Mark packets with the specified QoS group value (0 to 99) policy-map policy-map SetQoS SetQoS class class Class1 Class1 set qos-group 1 class class Class2 Class2 set qos-group 2 class class Class3 Class3 set qos-group 3 !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-113
Class-based Marking can mark packets with the QoS group value. The QoS group is a parameter that is local to the router where it is set. It is not part of any header. It is usually set on an input interface and later examined (matched) on output interfaces. Once the packet is transmitted, the QoS-group information is lost, and the next router must reclassify and mark the packet. QoS group supports up to 100 distinct values (classes). The set qos-group command is used to set the QoS group value to a packet inside a router. Values from 0 to 99 can be used to mark packets.
9-106
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring MPLS Marking Router(config-pmap-c)#
set mpls experimental exp-bits
• Mark labeled packets with the specified value (0 to 7) • MPLS marking can only be used on input policy-map policy-map SetMPLS SetMPLS class class Class1 Class1 qos-group qos-group set mpls mpls experimental experimental class class Class2 Class2 qos-group qos-group set mpls mpls experimental experimental class class Class3 Class3 qos-group qos-group set mpls mpls experimental experimental !!
© 2001, Cisco Systems, Inc.
11 11 22 22 22 33
IP QoS Modular QoS CLI Service Policy-114
Cisco IOS also supports marking of MPLS frames, which is used to set MPLS CoS parameters. The three EXP(erimetal) bits inside the MPLS label are used, and the set mpls experimental command is used within the MQS to mark MPLS frames with CoS information. Values from 0 to 7 can be used to mark MPLS frames.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-107
Configuring LAN Marking Router(config-pmap-c)#
set cos cos • Mark frames with the specified value (0 to 7) • The value applies to the Class of Service bits with the IEEE 802.1Q encapsulation or Priority bits with the ISL encapsulation • The command can only be used on output LAN interfaces that are using one of the two mentioned encapsulations policy-map policy-map SetCoS SetCoS class class Class1 Class1 set cos 1 class class Class2 Class2 set cos 2 class class Class3 Class3 set cos 3 !! © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-115
The IEEE 802.1p standard specifies a standard for delivering QoS in local area networks (LANs). Packets are marked with three CoS bits, where CoS values range from zero for low-priority to seven for high-priority. CoS can only be applied on trunks, because only there is an encapsulation available with space for the bits: n
Inter-Switch Link (ISL) frame headers have a 1-byte User field that carries the CoS value in the three least significant bits.
n
IEEE 802.1p and 802.1q frame headers have a 2-byte Tag Control Information field that carries the CoS value in the three most significant bits, which are called the User Priority bits.
Other frame types cannot carry CoS values. In general, Layer 2 switches can examine, use, or alter MAC layer markings, not IP precedence or DSCP settings, since those are Layer 3. Layer 2 markings are generally applied on egress trunk ports.
9-108
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring Frame Relay DE Marking Router(config-pmap-c)#
set fr-de • Mark packets with the Frame Relay Discard Eligibility (DE) bit value 1 • Do not use the command to mark frames with the default value 0 • The command can only be used on output Frame Relay interfaces policy-map policy-map SetFR SetFR class class Class1 Class1 set fr-de fr-de class class Class2 Class2 class class Class3 Class3 set fr-de fr-de !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-116
The user can specify which Frame Relay packets have low priority or low time sensitivity and will be the first to be dropped when a Frame Relay switch is congested. The mechanism that allows a Frame Relay switch to identify such packets is the discard eligible (DE) bit. This bit is set for all packets of a class with the set fr-de command. This feature requires that the Frame Relay network be able to interpret the DE bit. Some networks take no action when the DE bit is set. Other networks use the DE bit to determine which packets to discard. The most desirable interpretation is to use the DE bit to determine which packets should be dropped first and also which packets have lower time sensitivity.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-109
Configuring ATM CLP Marking Router(config-pmap-c)#
set atm-clp • Mark cells of packets with the ATM Cell Loss Priority (CLP) bit value 1 • Do not use the command to mark cells with the default value 0 • The command can only be used on output ATM interfaces policy-map policy-map SetATM SetATM class class Class1 Class1 set atm-clp atm-clp class class Class2 Class2 class class Class3 Class3 set atm-clp atm-clp !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-117
The ATM CLP Setting feature somewhat allows users to extend their IP QoS policies into an ATM network by setting the ATM CLP bit in ATM cells based on the IP Precedence value of the packets being sent. As congestion occurs in the ATM network, cells with the CLP bit set are more likely to be dropped, resulting in improved network performance for high priority traffic and applications. The set atm-clp command marks packets of a class with the ATM CLP bit as a part of an input or output policy.
9-110
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting CB-Marking Router #show policy -map interface Router#show policy-map interface serial serial 0/0 0/0 Serial0/0 Serial0/0 Service-policy Service-policy input: input: SetMPLS SetMPLS (1837) (1837) Class-map: Class-map: Class1 Class1 (match-any) (match-any) (1839/12) (1839/12) 00 packets, packets, 00 bytes bytes 30 30 second second offered offered rate rate 00 bps, bps, drop drop rate rate 00 bps bps Match: Match: qos-group qos-group 11 (1843) (1843) 00 packets, packets, 0 0 bytes bytes 30 30 second second rate rate 00 bps bps QoS QoS Set Set mpls mpls experimental experimental 11 Class-map: Class-map: Class2 Class2 (match-any) (match-any) (1847/13) (1847/13) 00 packets, packets, 00 bytes bytes 30 30 second second offered offered rate rate 00 bps, bps, drop drop rate rate 00 bps bps Match: Match: qos-group qos-group 22 (1851) (1851) 00 packets, packets, 0 0 bytes bytes 30 30 second second rate rate 00 bps bps QoS Set QoS Set mpls mpls experimental experimental 22 ... ...
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-118
The show policy-map interface command displays all service policies applied to the interface. Among the settings, marking parameters and statistics are displayed.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-111
MQC Compatibility Matrix CB QoS mechanism
Configuration command
Supported directions
Can be combined with the following Class--based mechanisms Class
WFQ
bandwidth
output
WRED, Shaping, Policing, Marking
LLQ LLQ WRED Policing Shaping Marking
priority random--detect random police shape set
output output input/output input/output output input/output input/output
Shaping, Policing, Marking WFQ, LLQ WRED, Shaping, WFQ, LLQ, Marking WRED, Policing, WFQ, WFQ, LLQ, LLQ, Marking Marking WRED, Policing, Shaping, WFQ, LLQ
Output
Classify
Mark
Police
Input
Classify
Mark
Police
© 2001, Cisco Systems, Inc.
Shape
WRED
Queue
Schedule
Forward
IP QoS Modular QoS CLI Service Policy-119
The figure shows the compatibility matrix of all QoS mechanisms within the CB-WFQ system that can be configured via the Cisco IOS MQC. Supported combinations of features are shown, as well as their processing sequence, and applicability on input and output interfaces.
9-112
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Summary n
Class-based Marking is the most flexible Cisco IOS marking tool
n
Class-based Marking is implemented as a part of the CB-WFQ system
n
Class-based Marking supports marking of IP packets and a variety of Layer-2 frames
Lesson Review 1. Which parameters can be set using CB-Marking? 2. Can CB-Marking be used on input? 3. Can CB-Marking be combined with any other QoS mechanisms?
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-113
Summary After completing this module, you should be able to perform the following tasks:
9-114
n
Describe the policy part of the Modular QoS CLI
n
Configure packet marking with modular CLI
n
Configure policing and shaping with modular CLI
n
Configure class-based WFQ with modular CLI
n
Configure congestion avoidance mechanisms (WRED) with modular CLI
n
Configure low-latency queuing
n
Monitor and troubleshoot policy maps
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Service Policy Question: What are the benefits of using MQC? Answer: Template-based configuration; new classification options can be used with any MQC-based QoS mechanism. Question: How many classes can be used for one service policy? Answer: The MQC allows up to 256 classes to be defined. One service policy can use any number of classes. CB-WFQ is limited to 64 classes.
Class-based We ighted Fair Queuing Question: What type of guarantee does CB-WFQ provide? Answer: CB-WFQ provides bandwidth guarantees. Question: Which DiffServ PHB can be implemented using CB-WFQ? Answer: Assured Forwarding (AF) PHB can be implemented using CB-WFQ. Question: What configuration steps are needed to configure CB-WFQ? Answer: a. Create class maps for all classes that require individual bandwidth guarantees b. Create a policy map and specify the bandwidth for each class c. Apply the policy map to one or more interfaces where the same policy is needed
Class-based WRED Question: How does WRED supplement CB-WFQ? Answer: WRED is used to prevent congestion within a class queue. Question: Can WRED be combined with flow-based WFQ in the default class? Answer: Yes. Question: Which two operational modes does WRED support? Answer: IP-precedence-based and DSCP-based. Question: How many profiles does WRED support? Answer: 8 profiles for IP-precedence-based WRED and 64 profiles for DSCPbased WRED. Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-115
Class-based Low-latency Queuing Question: What advantages does CB-LLQ have over IP RTP Prioritization? Answer: CB-LLQ can use any classification supported by class maps. IP RTP Prioritization can only classify based on a range of UDP port numbers. Question: What guarantees does CB-LLQ provide? Answer: CB-LLQ provides a bandwidth guarantee and minimum-delay forwarding of packets.
Class-based Policing Question: What do CAR and Class-based Policing do? Answer: CAR and Class-based policing are primarily used to limit the rate of a traffic cla ss by dropping excess packets.
Question: What are the main differences between CAR and Class-based Policing? Answer: Class-based Policing uses the MQC and supports three different actions (confirm, exceed and violate).
Question: What marking options does Class-based Policing support? Answer: IP precedence, DSCP, MPLS experimental bits, QoS group, Frame Relay DE bit, ATM CLP bit.
Question: What actions does do Class-based Policing support? Answer: CB-Policing supports the following actions: transmit, drop and set (marker). A different action can be used depending on whether a packet conforms, exceeds or violates the policy.
Class-based Shaping Question: What are the main differences between CB-Policing and CB-Shaping? Answer: CB-Shaping polices bandwidth by delaying exceeding packets instead of dropping them. Question: What two shaping methods does CB-Shaping support? Answer: CB-Shaping supports shaping to average or peak rate.
Class-based Marking
Question: Which parameters can be set using CB-Marking? Answer: CB-Marking can mark packets with the following markers: IP Precedence, IP DSCP, QoS Group, MPLS Experimental bits, IEEE 802.1Q or ISL CoS/Priority bits, Frame Relay DE bit, ATM CLP bit 9-116
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Question: Can CB-Marking be used on input? Answer: Yes. Question: Can CB-Marking be combined with any other QoS mechanisms? Answer: Yes. CB-Marking can be combined with WRED, Policing, Shaping, WFQ, LLQ.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-117
10
IP over ATM
Overview This module focuses on IP QoS mechanisms that can be used on ATM interfaces. It includes the following topics: n
Introduction to IP over ATM
n
Per-VC WRED
n
VC Bundling
n
Per-VC CB-WFQ
n
RSVP to SVC Mapping
Objectives Upon completion of this module, you will be able to perform the following tasks: n
List the requirements of IP QoS in combination with ATM QoS
n
Describe the hardware and software requirements for advanced IP QoS mechanisms on ATM interfaces
n
Describe per-VC queuing
n
Describe and configure per-VC WRED
n
Describe and configure VC bundling
n
Describe and configure per-VC CB-WFQ
n
Describe RSVP to SVC mapping
n
Monitor and troubleshoot IP QoS on ATM interfaces
Introduction to IP over ATM Objectives Upon completion of this lesson, you will be able to perform the following tasks:
10-2
IP QoS IP over ATM
n
Describe the QoS-related problems when using ATM networks
n
Describe the hardware and software requirements for advanced IP QoS mechanisms on ATM interfaces
n
Describe per-VC queuing
Copyright 2001, Cisco Systems, Inc.
IP vs. ATM Technology comparison IP
ATM
• Connectionless
• Connection oriented
• Per-packet QoS (IP precedence)
• Per-connection (virtual circuit) QoS
• Small number of service classes
• Large number of QoS traffic classes (CBR, VBR, UBR, ABR)
• IP precedence or DSCP does not encode service parameters
© 2001, Cisco Systems, Inc.
• Rich traffic parameters (PCR, MCR, SCR ...) specified for each VC
IP QoS IP over ATM-5
The Internet Protocol (IP) is a routed protocol that is used to transmit data in packets. It uses the best-effort delivery for individual packets without any flow control. Transmission Control Protocol (TCP) is used with IP to provide a connection-oriented service. Asynchronous Transfer Mode (ATM), on the other hand, provides connections between endpoints in the ATM network. The connections are called virtual circuits (VCs). IP’s default best effort service can be supplemented by differentiated quality of service based on IP precedence or DSCP marking. A QoS solution using IP precedence is limited to 8 classes, 2 of which are reserved and 1 should be used for the default best-effort class. A QoS solution using DSCP scales up to 64 classes. ATM provides a wider range of services: n
Constant Bit Rate (CBR) is useful for delay-sensitive applications such as voice. This service provides bandwidth and delay guarantees.
n
Variable Bit Rate—Real Time (VBR-RT) is useful for burstier delay-sensitive applications. This service provides bandwidth and delay guarantees.
n
Variable Bit Rate—Non Real Time (VBR-NRT) is useful for bursty traffic. This service provides bandwidth guarantees.
n
Available Bit Rate (ABR) is useful for best-effort traffic that is allowed more bandwidth, when available or configured. This service provides bandwidth guarantees and access to extra bandwidth.
n
Unspecified Bit Rate is useful for the real best effort where there are no guarantees.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-3
IP’s IP precedence or DSCP are only used to mark packets. They do not include any service parameters. Servic e parameters depend on the QoS mechanism being deployed. ATM’s services also include various per-connection service parameters, such as: n
Sustained Cell Rate (SCR) for CBR, VBR and ABR services
n
Minimum Cell Rate (MIR) for ABR
n
Peak Cell Rate (PCR) for VBR, ABR and UBR services
n
Maximum Burst Size (MBS)
Both IP and ATM can implement Quality of Service (QoS). The decision on which technology to use for quality of service should be based on a number of factors, such as: n
Availability of ATM
n
Interaction between ATM and IP
n
Scalability options of the technology
n
Performance limitations
This module introduces the possibilities of combining IP QoS with ATM.
10-4
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Integrating IP and ATM • Overlay model (ATM forum) – ATM VC’s are manually established between pairs of devices – IP packets are sent across these VC’s – ATM switches are not IP aware
• Peer model (MPLS) – ATM switches are IP aware on control (but not data) plane – ATM VC’s are established on-demand based on IP routing tables
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-6
There are two main approaches to integration of IP with/over ATM: n
The traditional way (overlay model) is to use individual permanent virtual circuits (PVC) to establish point-to-point adjacencies between IP routers. IP routing protocols are used to provide reachability across a network of ATM connections. ATM has no knowledge of IP and cannot use IP information to optimize its links.
n
The newer approach (MPLS) is to make ATM switches IP aware. ATM switches run an IP routing protocol to establish virtual circuits.
This module focuses on the QoS available with traditional permanent and switched virtual circuits (PVCs and SVCs). The IP QoS- IP over MPLS module discusses QoS possibilities when using the peer model.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-5
IP QoS and ATM • Routers can be interconnected over an ATM backbone using different ATM services: – UBR – congestion management is virtually impossible because routers are allowed to transmit packets at line speed – VBR – congestion management is easier, but it requires conservative setting of transmit rates – CBR – similar to VBR from IP perspective – ABR – pushes congestion back to the source, requires dynamic adjustment to available bandwidth
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-7
Achieving good quality of service for IP classes greatly depends on the type of ATM network and services used.
10-6
IP QoS IP over ATM
n
Using UBR, prevents routers from detecting congestion in the network. It is therefore difficult to manage congestion based on IP precedence or DSCP. The reason for this is because all packet drops happen on the congested link somewhere in the ATM network.
n
VBR makes it easier to push congestion back to the source where it can be managed by routers.
n
CBR is typically used for non-bursty delay sensitive traffic. It is therefore more important to prevent congestion by correctly provisioning the class that is using CBR.
n
ABR is a good solution where bandwidth can be utilized to the maximum without having many drops in the ATM network.
Copyright 2001, Cisco Systems, Inc.
UBR Virtual Circuits Random CLP marking
No congestion Router allowed to send at full speed
Unintelligent drops based on CLP
Congestion
• Solution: – Set CLP on the router based on IP information to minimize the effect of cell drops © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-8
A solution using UBR can be improved in terms of IP QoS, by marking less important packets with the CLP bit for congestion control. In case of congestion, the ATM switches will drop the less important packets to give more bandwidth for the higher-priority packets. The ATM FORUM also calls the UBR service category a “best effort” service, which requires neither tightly constrained delay nor delay variation. In fact, UBR provides no specific quality of service or guarantee throughput whatsoever. This traffic is therefore “at risk” since the network provides no performance guarantees for UBR traffic. The Internet and Local Area Networks are examples of this type of “best effort” delivery performance. Examples of this are LAN emulation (LANE), IP over ATM, and non-mission-critical traffic. This solution is fairly limited, since it allows for only two classes on the IP layer where congestion should be managed.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-7
VBR Virtual Circuits Congestion!
Router is sending at configured rate
Unintelligent random drops
Congestion is possible
• Solution: – Set CLP on the router based on IP information – Use available IP QoS mechanisms to manage congestion at the source © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-9
A solution using VBR is better at providing feedback to routers sending cells into the ATM network. Congestion will occur on a router’s virtual circuit, where it can be managed by using the QoS mechanisms available in the Cisco IOS software. CLP marking can be used for less-important packets or for those packets above the Sustained Cell Rate (SCR) to improve the chances for higher-priority packets when congestion occurs in the ATM network. The rt-VBR service category supports time-sensitive applications, which also requires constrained delay and delay variation requirements, but which transmit at a time varying rate constrained to a PCR, SCR, and MBS define a traffic contract in terms of the worst-case source traffic pattern for which the network guarantees a specified QOS. Examples of such bursty, delay-variation-sensitive sources are voice and variable -bit-rate video. The nrt-VBR service category supports applications that have no constraints on delay and delay variations, but which still have variable -rate, bursty traffic characteristics. This class of application expects a low Cell Loss Ratio (CLR). The traffic contract is the same as that for rt-VBR. Applications include packet data transfers, terminal sessions, and file transfers. Networks may statistically multiplex these VBR sources effectively.
10-8
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
CBR and ABR Virtual Circuits Congestion!
Router is sending at configured rate.
• Solution: – Use available IP QoS mechanism to handle congestion at the source © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-10
CBR virtual circuits, are used for delay-sensitive traffic. This traffic should not experience congestion due to keeping the quality of data being transmitted. If congestion occurs, it can be managed by the IP layer using the IP QoS mechanisms on the router’s ATM interface. The CBR service category supports real-time applications requiring a fixed amount of capacity defined by the PCR. CBR supports tightly constrained variations in delay. Example applications are voice, constant-bit-rate video, and Circuit Emulation Services (CES). Normally, networks must allocate the peak rate to these types of source. The ABR service category works in cooperation with sources that can change their transmission rate in response to rate-based network feedback used in the context of closed-loop flow control. The aim of ABR service is to dynamically provide access to capacity currently not in use by other service categories to users who can adjust their transmission rate in response to feedback. In exchange for this cooperation by the user, the network provides a service with very low loss. Applications specify a maximum transmit-rate (PCR_ and the minimum required rate, called the Minimum Cell Rate (MCR). ABR service does not provide bounded delay variation; hence real-time applications are for ABR are LAN interconnection, high-performance file transfers, database archival, non-timesensitive traffic, and web browsing.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-9
Congestion Management in ATM Networks • Congestion management on routers should be performed on a per-VC basis • Design options: – Make sure there is no congestion in the ATM network (ABR, CBR, VBR) and use IP QoS mechanisms at the source (CB-WFQ, WRED) – Mark less important packets with the CLP bit in case there is congestion in the ATM network (CBPolicing, CB-Marking) – Use multiple parallel (per-CoS) virtual circuits with ATM QoS (VC Bundling)
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-11
This module discusses three different approaches to designing QoS in IP networks on ATM:
10-10
IP QoS IP over ATM
1.
Using IP QoS mechanisms to ensure there is no congestion in the AMT network
2.
Using ATM QoS mechanisms with IP precedence used for classification (VC Bundling)
3.
Combining both IP and ATM QoS mechanisms
Copyright 2001, Cisco Systems, Inc.
Per-VC Queuing VIP Memory
ATM Port Adapter
Frame queue VC 1/50
Cell queue VC 1/50
Frame queue VC 1/64
Cell queue VC 1/64
Frame queue VC 1/76
Cell queue VC 1/76
Frame queue VC 1/39
Cell queue VC 1/39
ATM interface VC 1/50 VC 1/64 VC 1/76 VC 1/39
ATM hardware shaping
Per-VC queuing with per-VC congestion management
• Per-VC queuing is required in order to handle congestion on per-VC basis • Per-VC queuing prevents head-of-line blocking by slow virtual circuits © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-12
One of the most important parts of implementing QoS is to make ATM virtual circuits appear as physical interfaces on routers; that is, each VC must have its own queue (per-VC queuing). Per-VC queuing prevents one congested VC from slowing down other VCs (head-of-line blocking). Per-VC queuing can then be supplemented by various IP QoS mechanisms, such as: n
WRED
n
CAR
n
CB-WFQ
n
CB-LLQ
n
CB-Policing
n
CB-Shaping
n
CB-Marking
CB-Marking and CB-Policing can also be used to set the CLP bit.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-11
Summary The following steps have to be taken prior to the designing of a QoS solution for IP over ATM: n
Implement Per-VC queuing (to prevent head-of-line blocking and allow for IP QoS mechanisms to be implemented on individual virtual circuits)
n
Decide on the technology that will be used to implement QoS
Review Questions Answer the following questions: 1. What are the main differences between IP and ATM? 2. Which QoS services does ATM support? 3. How should congestion be handled when an ATM backbone is used? 4. Why is per-VC queuing so important?
10-12
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-VC WRED Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe per-VC WRED
n
Configure per-VC WRED
n
Monitor and troubleshoot per-VC WRED
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-13
Per-VC WRED • Single ATM VC is established over an ATM cloud between a pair of routers – ABR, VBR, UBR or CBR – Using UBR will not result in proper operation, as there is no ATM shaping in UBR
• All IP traffic toward a next-hop router is forwarded across a single ATM VC • Congestion is managed entirely on the IP layer using WRED on each individual ATM VC, resulting in differentiated IP services
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-17
A simple addition to best-effort service on ATM interfaces is Weighted Random Early Detection (WRED). WRED is most efficient when the majority of the traffic is TCP (TCP reacts to random drops and slows down the transmission rate). With other protocols, packet sources may not respond or may resend dropped packets at the same rate. Thus, dropping packets does not decrease congestion. WRED treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP traffic is more likely to be dropped than IP traffic UBR would probably result in congestion somewhere in the ATM network, thus preventing any intelligent congestion management on the IP layer. Any other ATM service (CBR, VBR or ABR) will push congestion back to the source where WRED can be used to drop packets based on the IP precedence or DSCP value.
10-14
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-VC WRED : Intelligent IP Packet Discard Traffic Shaping
Threshold Exceeded VIP2-50
PA-A3-XX VC1 VC2
VC3
Per-VC WRED: Intelligent Discard © 2001, Cisco Systems, Inc.
Per-VC Queues
No discard on PA
IP QoS IP over ATM-18
Per-VC queuing requires an Enhanced ATM Port Adapter that support up to 4096 cell queues. Each virtual circuit is assigned a queue and the ATM scheduler forwards cells according to the ATM service and shaping parameters. The router (or VIP on Cisco 7x00 series routers) also assigns one queue per virtual circuit. Cell departure is shaped if ABR, VBR or CBR services are used, thus causing congestion in the frame queue if packet arrival is greater than the shaping rate in ATM. Per-VC WRED can be used to manage congestion within individual queues (classes).
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-15
Configuring Configuring Per-VC WRED • The following configuration steps are needed to enable per-VC WRED: – Create a Random-Detect-Group template with a WRED profile – Apply the WRED template to an ATM interface or to individual ATM VCs – Verify and monitor the operation of per-VC WRED
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-19
Applying WRED to individual VCs is slightly different than applying WRED to interfaces. A Random Detect Group must be created if non-default WRED profiles need to be used on VCs. Standard WRED parameters (per-precedence minimum threshold, maximum threshold and maximum drop probability) are set in the random-detect-group configuration mode.
10-16
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Create and configure RED-group Router(config)# random-detect-group name name
• Creates a WRED template Router(cfg-red-group)# exponential-weighting-constant exponential-weighting-constant exp
• Defines WRED weighting constant • Default: 9 Router(cfg-red-group)# precedence precedence IP-prec min-threshold max-threshold max-threshold prob-denominator
• Defines RED profile for specified precedence • Default: as with per-interface WRED © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-20
The random-detect-group global configuration command creates a WRED profile and enters the red-group configuration mode. WRED per-precedence profiles are configured in the red-group configuration mode, using similar commands as with per-interface WRED, except the commands are not preceded by the random-detect keyword. Any class (IP precedence) can be configured with a RED profile different from the default by using the precedence command in the red-group configuration mode: n
Minimum threshold—When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold.
n
Maximum threshold—When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.
n
Mark probability denominator—This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
WRED does not calculate the drop probability using the current queue length, but instead uses the average queue length. The average queue length is constantly recalculated, using two terms: n
The previously calculated average queue size
n
The current queue size
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-17
An exponential weighting constant N influences the calculation by weighing the two terms. It therefore influences how the average queue size follows the current queue size, in the following way: n
A low value of N makes the current queue size more significant in the new average size calculation, therefore allowing larger bursts
n
A high value of N makes the previous average queue size more significant in the new average size calculation, so that bursts influence the new value to a smaller degree
The default value is 9 and should suffice for most scenarios, except perhaps those involving extremely high-speed interfaces (such as OC12), where it can be increased slightly (to about 12) to allow more bursts. Note
10-18
IP QoS IP over ATM
The default WRED parameter values are based on the best available data. Cisco recommends that you do not change the parameters from their default values unless you have determined that your applications will benefit from the changed values.
Copyright 2001, Cisco Systems, Inc.
Apply WRED group to an ATM PVC Router(config-if-atm-vc)#
random-detect random-detect [attach [attach random-detect-group] random-detect-group]
• Enables WRED on a PVC using the selected WRED profile • Default WRED parameters are used if the group name is omitted or refers to non-existent group • Default: no WRED is used on the ATM PVC
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-21
The last step in the configuration of per-VC WRED is to attach a random-detectgroup to a virtual circuit. The random-detect command is used in the VC configuration mode to enable WRED. If no random-detect-group is specified WRED will use the default WRED profiles.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-19
Monitoring and Troubleshooting Per-VC WRED Router# show show queueing random-detect random-detect [interface [interface intf [vc vpi vci vci ]] ]]
• Displays WRED parameters for an ATM (sub)interface or for individual VC
Router# show show queueing interface interface interface [vc vpi vpi vci] vci]
• Displays interface queues or individual per-VC queue
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-22
The show queuing random-detect command display WRED parameters and statistics for a specific interface or virtual circuit. There is only a single queue into which packets from all IP precedences are placed after dropping has taken place. The show queuing interface command displays per-VC queue parameters and statistics. The “Queuing strategy” reported by the command lists “random early detection (RED)” as the queuing mechanism. The default minimum thresholds are spaced evenly between half and the entire maximum threshold. Thresholds are specified in terms of packet count.
10-20
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
WRED Case Study • WRED is applied to a ATM PVCs in a network with the following IP precedence definitions IP prec. 0 1 2 3 4 5 6 7
Meaning High-loss best-effort traffic Low-loss best-effort traffic Premium traffic outside of the contract Premium traffic in the contract Unused Voice-over-IP Routing protocol traffic Routing protocol traffic
• WRED queue length is 100 packets for PVCs with SCR > 10 Mbps and 40 packets for slower PVCs
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-23
The case study shows a QoS design where packets are classified into three user classes: n
Best-effort class
n
Premium class
n
Voice class
The Best-effort and Premium classes use two IP precedence values to mark high-drop (out-of-contract) traffic and low-drop (within contract) traffic. IP precedence values 6 and 7 are reserved for control messages (for example, routing protocols) and should not be used for user traffic. The design lists these two additional requirements: n
Virtual circuits faster than 10Mbps should have queues that can hold up to 100 packets
n
Slower virtual circuits can store up to 40 packets in the queue
All virtual circuits should manage congestion by using WRED.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-21
Packet Discard Probability
Case Study WRED Profile
VoIP
Precedence 3
Routing
Precedence 1
0.1
Precedence 2 Precedence 0
RSVP
37
35
30
25
20
15
10
© 2001, Cisco Systems, Inc.
Average Queue Size
IP QoS IP over ATM-24
The figure illustrates the WRED parameters that should be implemented for fast and slow virtual circuits. The minimum and maximum thresholds should reflect a different maximum queue size for fast VCs (100 instead of 40). High drop Best-effort and Premium packets start being dropped when the average queue size reaches 10 or 15 respectively (25 or 37 on fast VCs). If the queue still grows the low-drop Best-effort packets start being dropped when the queue size reaches 20 (50 on fast VCs). High drop packets, of course, are more aggressively dropped than low-drop packets. Control packets, VoIP packets and packets of RSVP flows are only dropped in extreme situations when the average queue size is close to the maximum (40 for slow VCs and 100 for fast VCs).
10-22
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Router Configuration • Step #1 - configure WRED profile for slow PVCs random-detect-group random-detect-group slow-wred-profile slow-wred-profile precedence 0 10 25 10 precedence 1 20 40 10 precedence 2 15 25 10 precedence 3 25 40 10 precedence 1 10 10 precedence 44 precedence 5 35 40 10 precedence 6 30 40 10 precedence 7 30 40 10
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-25
The figure shows the configuration of WRED profiles used for slow VCs.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-23
Router Configuration • Step #2 - configure WRED profile for fast PVCs random-detect-group random-detect-group fast-wred-profile fast-wred-profile precedence 25 precedence 00 25 62 62 10 10 precedence 50 precedence 11 50 100 100 10 10 precedence 37 precedence 22 37 62 62 10 10 precedence 62 precedence 33 62 100 100 10 10 precedence 87 precedence 55 87 100 100 10 10 precedence 1 10 10 precedence 44 precedence 75 precedence 66 75 100 100 10 10 precedence 75 precedence 77 75 100 100 10 10
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-26
The figure shows the configuration of WRED profiles used for fast VCs. Note
10-24
IP QoS IP over ATM
This configuration simply uses scaled thresholds to support up to 100 packets in the queue.
Copyright 2001, Cisco Systems, Inc.
Router Configuration • Step #3 - Apply WRED profile on various PVCs interface interface ATM11/0/0 ATM11/0/0 ip address 17.1.0.1 17.1.0.1 255.255.255.0 255.255.255.0 atm pvc pvc 50 0 50 aal5snap 25000 50000 10 inarp inarp random-detect random-detect fast-wred-profile fast-wred-profile !! interface interface ATM11/0/0.100 ATM11/0/0.100 point-to-point ip address 17.1.1.1 255.255.255.252 atm pvc pvc 100 100 0 100 aal5snap 17000 34000 10 inarp inarp random-detect random-detect fast-wred-profile fast-wred-profile !! interface interface ATM11/0/0.101 ATM11/0/0.101 point-to-point ip address 17.1.1.5 255.255.255.252 atm atm pvc 101 101 55 101 101 aal5snap aal5snap 2000 2000 4000 4000 10 10 inarp random-detect random-detect slow-wred-profile slow-wred-profile
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-27
The figure shows the configuration of three virtual circuits. Two are using the WRED profile for fast VCs and the third is using the WRED profile for slow VCs.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-25
Summary Weighted Random Early Detection (WRED) is one of the IP QoS mechanisms that can be applied to individual virtual circuits. A Random Detect Group is used to configure a WRED profile that is attached to individual VCs using the random-detect command in the VC configuration mode.
Review Questions Answer the following questions: 1. What are the benefits of per-VC WRED? 2. What are the configuration steps needed to enable per-VC WRED?
10-26
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Bundling Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe VC bundling
n
Configure VC bundling
n
Monitor and troubleshoot VC bundling
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-27
VC Bundling • VC Bundling is a solution where ATM QoS mechanisms are used • Classes of Service are identified by IP precedence • Each VC uses an ATM service based on the requirements of the class • Routers automatically map packets in VCs based on their IP precedence value • Multiple parallel VCs are needed for each IP adjacency © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-32
VC Bundling is a solution where the task of providing differentiated quality of service is offloaded to the ATM switches. Classes are identified by using IP precedence values. The routers then perform classification based on IP precedence values. Up to eight parallel virtual circuits can be used for one IP adjacency. Appropriate ATM services are used for each IP precedence value, depending on the QoS requirements and provisioning. An IP precedence value or a range of IP precedence values are mapped to one virtual circuit. Non-contiguous IP precedence ranges are not supported.
10-28
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Bundling Case Study ATM VC ATM VC type Control VC (routing updates) VBR Voice CBR VPN traffic VBR Premium Internet traffic VBR Best-effort Internet traffic ABR
IP prec. 6-7 5 4 2-3 0-1
Control (routing) Voice VPN traffic Premium Internet Best-effort Internet
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-33
The figure illustrates a case study where there are four user classes and one class for control traffic. Routers perform classification based on IP precedence values: n
IP precedence 6 and 7 traffic is forwarded through the Control VC
n
IP precedence 5 traffic is forwarded through the Voice VC
n
IP precedence 4 traffic is forwarded through the VPN VC
n
IP precedence 2 and 3 traffic is forwarded through the Premium VC
n
IP precedence 0 and 1 traffic is forwarded through the Best-effort VC
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-29
VC Bundling Routing Adjacency
Routing protocol packets are exchanged over control VC as they are sent with IP precedence 6 Control (routing) Voice VPN traffic Premium Internet Each VC has its own HW queue in the Best-effort Internet router, managed with WRED Whole bundle is treated as one routing adjacency and is covered by a single ATM map
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-34
All five classes are separated in the ATM network and receive different quality of service. Routers have to perform per-VC queuing to prevent head-of-line blocking. All five virtual circuits, though, appear as one single point-to-point link on the IP layer.
10-30
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Provisioning • VCs are dimensioned based on expected load for the precedence(s) level transported on that VC • More isolation between classes • At the expense of – less statistical multiplexing, – more complex provisioning/engineering
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-35
VC Bundling provides an efficient utilization of QoS capabilities provided by ATM. IP classes are effectively isolated by being transported over different virtual circuits. The drawbacks of this approach are: n
Less statistical multiplexing. One class cannot use another class’s bandwidth (unless ABR is used).
n
More complex provisioning. Each IP adjacency, which normally requires one point-to-point virtual circuit, now requires multiple virtual circuits of different types and QoS.
As much as IP QoS is simplified to classification and marking using IP precedence, ATM QoS is more complex because there are up to eight times more virtual circuits to be configured.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-31
VC Bundle Management • Integrity of each individual VC is verified with end-to-end OAM cells
Control (routing) Voice VPN traffic Premium Internet Best-effort Internet
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-36
Most Layer-2 technologies include some type of link management. Keepalive frames are typically used as a last resort to determine if end-to-end connectivity works. For example: n
HDLC and PPP use link-level keepalive frames to determine if the link is operational.
n
Frame Relay uses keepalive frames to determine if the link between a router and a switch is operational. Frame Relay can also have end-to-end keepalive messages to determine if the virtual circuit is operational.
n
ATM uses two types of Operation Administration and Maintenance (OAM) cells to determine if link-level and end-to-end connectivity works.
VC bundling is more complex since there are multiple parallel virtual circuits used for one single IP adjacency. The question is: what should happen if only one VC goes down?
10-32
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Bundle Management
Control (routing) Voice VPN traffic
Best-effort Internet Two ways of handling loss of VC in the bundle: • The whole bundle is declared down • Traffic from the lost VC is bumped onto another VC • IP routing model does not allow the traffic for a single precedence value to be rerouted over another path © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-37
There are two possible ways of handling lost VCs: n
All VCs are declared inactive
n
The traffic for the lost VC is rerouted onto another VC within the same bundle
IP forwarding decisions are based solely on the destination address and cannot reroute packets based on their IP precedence values.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-33
VC Bumping • VC bumping = possibility for a traffic mapped to VC X to be forwarded onto another VC Y, in case of failure of X • Traffic can be bumped based on implicit or explicit rules • Individual VC or a group of VCs can be protected
Keep All Graphics Inside This Box © 2001, Cisco Systems, Inc.
10-34
IP QoS IP over ATM
www.cisco.com
Course acronym 2.0 —Chapter#-38
n
VC bumping is one approach to handling lost VCs. If one of the VCs goes down the traffic from that VC is forwarded through another VC in the same bundle.
n
Implicit bumping is the default behavior where packets are forwarded through the first available VC of a lower IP precedence value.
n
Explicit bumping requires manual configuration where the IP precedence of a backup VC is set.
Copyright 2001, Cisco Systems, Inc.
Implicit Bumping
Control (routing) Voice VPN traffic
Best-effort Internet
• Traffic from the lost VC is bumped onto the VC carrying traffic with the next lower precedence © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-39
The figure illustrates how routers automatically reroute Premium traffic to the first VC with a lower IP precedence value (Best-effort in the example).
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-35
Reject Bumping
Voice
Rejects bumping
VPN traffic Premium Internet Best-effort Internet
• Problem: Control traffic shall not be bumped onto voice VC (implicit rule) • Solution #1: Voice VC can reject bumping, bumped traffic goes to next lower VC © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-40
Some virtual circuits can be configured to reject bumped traffic. The figure illustrates how the Voice VC rejects bumped traffic (mixing delay sensitive, well-provisioned traffic with other types of packets is not desired and should be prevented). Implicit bumping searches down the “ladder” for the first available VC (it has to be operational and accept bumped traffic).
10-36
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Explicit Bumping
Bump explicitely to precedence 0
Voice VPN traffic Premium Internet Best-effort Internet
• Problem: Control traffic shall not be bumped onto voice VC (implicit rule) • Solution #2: Specify explicitely onto which VC the traffic will be bumped © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-41
Another approach is to explicitly set the backup VC. The Control VC in the figure was configured to use the Best-effort VC as backup.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-37
Bundle Failure Scenarios When a bundle is declared down, no traffic is forwarded out of the bundle, even if some VCs are still up (routing) Control Voice VPN traffic Premium Internet Whole bundle is lost
Precedence 0 traffic cannot be implicitly bumped
• Problem: under default settings, the whole bundle is declared down if the lowest-precedence VC is lost • Solution: be sure that the lowest-precedence VC is always bumped via explicit bumping rule © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-42
In this figure the VC used for IP precedence 0 does not have a lower-precedence VC to be used as backup. It is recommended to use explicit bumping for this VC.
10-38
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Protected VC
Control (routing) Voice VC is protected VC
VPN traffic Premium Internet Whole bundle is lost
Best-effort Internet
• Problem: voice traffic shall not be bumped onto data VC • Solution: failure of protected VC brings down the whole bundle, IP routing will find alternate path © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-43
Some VCs have special QoS requirements that cannot be accommodated by any other VC. The Voice VC in the figure cannot be bumped to any other VC because the voice quality would no longer meet the requirements. It is better to declare the entire bundle down and let the IP routing protocol find another path where guarantees can be met. Classes that under no circumstances should be mixed with other classes should reject bumped traffic (if a higher-precedence VC fails) and be protected (if their VC fails).
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-39
Protected group
Control (routing) Voice
Whole bundle is lost
All VCs in the protected group are lost
• Problem: if most of the VC’s are lost, it does not make sense to bump traffic onto low-volume VC’s • Solution: failure of all VC’s in a protected group will bring down the bundle © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-44
One group of VCs can be protected in a way where the bundle is declared down but only if all of the VCs in the group fail.
10-40
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Bumping – Final Details • If the VC which carries the bumped traffic fails, the traffic will follow the bumping rules specified for that VC • Traffic is restored to the original VC when that VC becomes operational
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-45
To summarize bumping: n
Default implicit bumping is used to find the first-lower precedence VC that accepts bumped traffic and is operational.
n
Explicit bumping can be used to select the backup VC. If the backup VC is down, that VC’s rules are used to find the backup of the backup VC.
n
Individual VCs can be configured to reject bumped traffic. Bumped traffic will skip such VCs.
n
An individual VC can be protected. If a protected VC fails the entire bundle is declared down.
n
A collection of VCs can belong to a protected group. If all VCs in the protected group fail the entire bundle is declared down.
Traffic is restored to the original VC the moment it becomes operational.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-41
Configuring VC Bundling • Configuration steps: – Configure ATM interface – Configure VC bundle – Configure individual VC in the bundle – Optionally use VC-class object as VC parameter template
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-46
The following configuration steps are needed to enable VC Bundling:
10-42
Step 1
Configure interface-wide parameters on an ATM interface
Step 2
Create a VC bundle
Step 3
Create up to eight VCs as members of the bundle
Step 4
Optionally, use the VC-class object as a template for bundle or VC configuration
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Bundle Parameters • Parameters configurable on the VC bundle or vc-class applied to the bundle – Layer-3 ATM maps – Encapsulation – Broadcast propagation – ATM Inverse ARP – OAM management – Global bumping rules
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-47
The figure lists the parameters that can be set on a bundle or a vc-class template. Individual member VCs inherits the parameters if they are not overridden in the VC configuration.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-43
Individual VC Parameters • Parameters configurable on individual VC in the bundle (or vc-class) – IP precedence mapping – VC protection mode – VC bumping rules – ATM VC mode and ATM QoS parameters – WRED group
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-48
Individual VC parameters can be inherited from a vc-class configured on the bundle, the bundle, or a vc-class configured on the VC. Parameters configured on the VC override all inherited parameters.
10-44
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Configuring Bundle-wide VC Class Router(config)#
class-vc class-vc vc-class-name vc-class-name oam-bundle oam-bundle [manage] [frequency] [frequency] bump bump {implicit {implicit | explicit precedence-level precedence-level | traffic} encapsulation encapsulation atm-encap atm-encap protocol protocol atm-map-parameters … [no] [no] broadcast broadcast inarp inarp timeout timeout
• Configures all parameters that can be specified on an ATM VC bundle in a VC class
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-49
Use the class-vc global configuration command to create a template used to configure common parameters on ATM interfaces, bundles or individual virtual circuits. VC classes can contain ATM specific configuration commands as well as commands used for VC Bundle management.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-45
Configuring ATM VC Bundle Router(config-if)#
bundle bundle bundle-name bundle-name class class vc-class-name vc-class-name oam-bundle oam-bundle [manage] [frequency] [frequency] bump bump {implicit {implicit || explicit explicit precedence-level precedence-level || traffic} traffic} encapsulation encapsulation atm-encap atm-encap protocol protocol atm-map-parameters … [no] [no] broadcast broadcast inarp inarp timeout timeout
• Configures ATM VC bundle • If a vc-class is applied to the bundle, the bundle inherits parameters specified in the vc-class • Individual parameters specified in the vc-class can be overwritten by bundle configuration commands © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-50
Use the bundle interface command to enter the bundle configuration mode. Parameters specific to this bundle should be configured on the bundle. Parameters that are common to multiple bundles should be configured in a template (VC class) and attached to the bundle using the class-bundle command. The command used to attach VC class templates differs, depending on which configuration mode is used:
10-46
IP QoS IP over ATM
n
The class-int interface command is used to attach a VC class to an interface
n
The class-bundle command is used to attach a VC class to a bundle
n
The class-vc command is used to attach a VC class to a virtual circuit
Copyright 2001, Cisco Systems, Inc.
Configuring OAM Management in the Bundle Router(config-atm-vc)#
oam-bundle oam-bundle [manage] [frequency] [frequency]
• Enables VC management with end-to-end OAM cells • Cells are sent but the bundle is not managed if the manage keyword is omitted • The frequency parameter specifies the cell generation rate in seconds Router(config-atm-vc)#
oam oam retry up-count up-count down-count down-count retry-frequency retry-frequency
• Specifies the OAM management-related thresholds • The up-count and down-count parameters specify the number of consecutive cells that have to be received (or lost) before the VC is declared up or down • The frequency parameter specifies the cell send frequency during VC state change verification © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-51
To enable end-to-end F5 Operation, Administration and Maintenance (OAM) loopback cell generation and OAM management for a virtual circuit (VC) class that can be applied to a VC bundle, use the oam-bundle vc-class configuration command. To enable end-to-end F5 OAM loopback cell generation and OAM management for all VC members of a bundle, use the oam-bundle bundle configuration command. If the manage keyword is omitted, loopback cells are sent but the bundle is not managed. The frequency parameter specifies the number of seconds between sending OAM loopback cells. Values range from 0 to 600 seconds. To configure parameters related to OAM management for an ATM PVC, SVC, or VC class, use the oam retry command in the appropriate command mode. The up-count parameter specifies the number of consecutive end-to-end F5 OAM loopback cell responses that must be received in order to change a PVC connection state to up. The down-count parameter specifies the number of consecutive end-to-end F5 OAM loopback cell responses that are not received in order to change a PVC state to down. The retry-frequency parameter specifies the frequency (in seconds) that the end-to-end F5 OAM loopback cells are transmitted when a change in the UP/DOWN state of a PVC is being verified. For example, if a PVC is up and a loopback cell response is not received after the frequency (in seconds) specified using the oam-pvc command, then loopback cells are sent at the retry-frequency to verify whether or not the PVC is down. Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-47
Configuring Traffic Bumping Router(config-atm-vc)#
bump bump implicit implicit
• Configures implicit bumping rules for the bundle or individual VC in the bundle • If the VC fails, the traffic is bumped to the VC carrying lower-precedence traffic Router(config-atm-vc)#
bump bump explicit explicit precedence precedence
• Configures explicit bumping rules for the bundle or individual VC in the bundle • If the VC fails, the traffic is bumped to the VC currently carrying packets with specified IP precedence © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-52
The bump implicit command, depending on the mode, applies implicit bumping rules, which is also the default, to a single VC bundle member (bundle -vc mode) or all VCs in the bundle (bundle mode). The (default) implicit bumping rule stipulates that bumped traffic is to be carried by a VC with a lower precedence. The bump implicit command specifies the IP precedence level to which traffic on a VC (bundle -vc mode) will be bumped when the VC goes down. It specifies a single number as the value of the precedence-level argument.
10-48
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Configuring Traffic Bumping Router(config-atm-vc)#
no no bump bump traffic traffic
• Prevents the VC (or all VCs in a bundle) from accepting bumped traffic Router(config-atm-vc)#
bump bump traffic traffic
• Allows the VC (or all VCs in a bundle) to accept bumped traffic
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-53
Use the no bump traffic command to reject bumped traffic on the configured VC. Use the bump traffic command to restore the default behavior.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-49
Configuring VC-wide VC Class Router(config)#
class-vc class-vc vc-class-name vc-class-name precedence precedence [other | range ] bump bump {implicit {implicit | explicit precedence-level precedence-level | traffic} protect protect {group {group | vc } ubr ubr || ubr+ ubr+ || vbr-nrt vbr-nrt atm-qos-parameters random-detect random-detect [attach group-name]
• Configures all parameters that can be specified on an ATM VC within the bundle in a VC class
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-54
Use the class-vc global configuration command to create a VC template. Interface, VC or bundle specific parameters can be set within the VC class.
10-50
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Configuring ATM VC in a Bundle Bundle Router(config-if)# bundle bundle-name pvc pvc name name [vpi/]vci class vc-class-name vc-class-name precedence precedence [other [other || range range ] bump {implicit {implicit || explicit explicit precedence-level precedence-level | traffic} protect {group | vc} ubr ubr || ubr+ ubr+ || vbr-nrt vbr-nrt atm-qos-parameters random-detect random-detect [attach group-name] group-name]
• Configures individual VC in an ATM VC bundle • If a vc-class is applied to the VC, the VC inherits parameters specified in the vc-class • Individual parameters specified in the vc-class can be overwritten by bundle configuration commands • Unspecified VC parameters are inherited from the bundle or from the ATM interface © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-55
Use the bundle command in the ATM interface or subinterface configuration mode. From within the bundle configuration mode the characteristics and attributes of the bundle and its members, such as the encapsulation type for all virtual circuits (VCs) in the bundle, the bundle management parameters and the service type, can be configured. Attributes and parameters that are configured in the bundle configuration mode are applied to all virtual circuit (VC) members of the bundle. VCs in a VC bundle are subject to the following configuration inheritance guidelines (listed in order of next highest precedence): 1. VC configuration in bundle -vc mode 2. Bundle configuration in bundle mode 3. Subinterface configuration in subinterface mode
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-51
Map IP Precedence to an ATM VC Router(config-atm-vc)#
precedence precedence [other [other || range range ]]
• Maps packets with specified range of IP precedence into the configured ATM VC • All the unmapped IP precedence values are mapped to the VC specifying “other” • Default: VC accepts all unspecified IP traffic
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-56
Assignment of precedence levels to VC bundle members provides the ability to create a differentiated service, because the IP Precedence levels can be distributed over the different VC bundle members. A single precedence level, or a range of levels to each discrete VC in the bundle, can be mapped, thereby enabling VCs in the bundle to carry packets marked with different precedence levels. Alternatively, a VC can be configured with the precedence other command to indicate that it can carry traffic marked with precedence levels not specifically configured for it. Only one VC in the bundle can be configured with the precedence other command to carry all precedence levels not specified. This VC is considered the default.
10-52
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Protection Router(config-atm-vc)#
protect protect {{ group group || vc vc }}
• Configures the VC to be part of protected group or to be individually protected • Bundle is declared down if all VCs in the protected group are lost or if any individually-protected VC is lost • Only one protected group can be configured in a bundle • Default: VC is not protected
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-57
Use the protect vc command to protect a virtual circuit. Use the protect group command to make the VC a member of the protected group. When a protected VC goes down, it takes the bundle down. When all members of a protected group go down, the bundle goes down.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-53
VC Inheritance Rules • VC parameters are inherited in the following order – Parameters specified on individual VC – Parameters in the VC class applied to the individual VC – Parameters specified on the bundle to which the VC belongs – Parameters specified in the VC class applied to the bundle – Parameters specified on an interface or subinterface
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-58
The figure shows the inheritance rules for parameters set on interfaces, bundles, VC classes or individual VCs. The parameters configured on individual VCs override all inherited values.
10-54
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
ATM VC Bundle Case Study • IP traffic is transported across an international ATM PVC with the following IP precedence values Precedence 0-1 2-3 4 5 6,7
Meaning Best-effort Internet traffic Premium Internet traffic VPN traffic VoIP traffic Routing protocols
• Voice traffic, VPN traffic and Premium Internet traffic shall be transported across dedicated PVCs for easier provisioning
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-59
The figure illustrates a case study where there are four user classes and one class for control traffic. Routers perform classification based on IP precedence values: n
IP precedence 6 and 7 traffic is forwarded through the Control VC
n
IP precedence 5 traffic is forwarded through the Voice VC
n
IP precedence 4 traffic is forwarded through the VPN VC
n
IP precedence 2 and 3 traffic is forwarded through the Premium VC
n
IP precedence 0 and 1 traffic is forwarded through the Best-effort VC
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-55
Case Study Step 1: Bundle Design • Precedence 5 traffic (VoIP) is transported over a separate VC, no bumping is possible • Precedence 2-3 traffic (Premium Internet) is transported over a separate VC, can be bumped onto the best-effort VC • Precedence 4 traffic (VPN) is transported over a separate VC, can be bumped onto best -effort VC • Control traffic is transported over a separate VC, can be bumped onto the best-effort VC • Best-effort VC can be bumped onto Premium Internet VC • WRED has to be deployed on all VCs to prevent bumped best-effort traffic from congesting the VC © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-60
Per-VC WRED is the only IP QoS mechanism that will be used on the routers to manage congestion.
10-56
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Router Configuration • Case study step 2: configuring VC classes vc-class vc-class best_effort best_effort precedence other bump bump explicitly explicitly 22 protect group !! vc-class vc-class premium precedence precedence 2-3 2-3 bump implicitly protect group !! vc-class vc-class bundle encapsulation aal5snap broadcast protocol ip ip inarp inarp oam-bundle oam-bundle manage 3 © 2001, Cisco Systems, Inc.
vc-class vc-class vpn precedence precedence 44 bump explicitly explicitly 00 protect group !! vc-class vc-class voip voip precedence precedence 55 no bump traffic protect vc !! vc-class vc-class control precedence precedence 6-7 6-7 bump explicitly explicitly 00 protect group
IP QoS IP over ATM-61
The first part of the implementation shows the templates (VC classes) that will be used for individual virtual circuits (classes) and one for the bundle.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-57
Router Configuration • Case study step 3: configuring the WRED profile Guaranteed_BW PVC random-detect-group random-detect-group guaranteed_bw_pvc guaranteed_bw_pvc precedence precedence 00 20 20 40 40 10 precedence 25 precedence 11 25 40 40 10 precedence 35 precedence 22 35 40 40 10 precedence 30 precedence 66 30 40 40 10 precedence 30 precedence 77 30 40 40 10
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-62
A random-detect-group is created for the virtual circuits that need non-default WRED profiles.
10-58
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Router Configuration • Case study step 4: configure the bundle and individual PVC interface interface ATM ATM 5/1/0.22 5/1/0.22 point-to-point point -to-point ip ip address address 216.23.45.5 216.23.45.5 255.255.255.252 255.255.255.252 bundle bundle SanFrancisco SanFrancisco class class bundle pvc-bundle pvc-bundle SF-control SF-control 2266 class class control vbr-nrt vbr-nrt 1000 1000 1000 1000 pvc-bundle pvc-bundle SF-voip SF-voip 25 25 class class voip voip vbr vbr 2000 2000 2000 2000 pvc-bundle pvc-bundle SF-vpn SF-vpn 24 class vpn class vpn vbr-nrt vbr-nrt 4000 4000 4000 4000 pvc-bundle pvc-bundle SF-guaranteed SF-guaranteed 22 class class guaranteed_bw guaranteed_bw random-detect random -detect attach attach guaranteed_bw_pvc guaranteed_bw_pvc vbr-nrt vbr-nrt 8000 8000 8000 8000 pvc-bundle pvc-bundle SF-best-effort SF-best-effort 23 23 class class best_effort best_effort random-detect random -detect © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-63
The figure shows the configuration of the bundle with five individual VCs. Each VC is configured with the PVC type and parameters. All other configuration parameters are inherited from the VC classes attached to individual VCs and the VC class attached to the bundle.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-59
Summary VC Bundling is a solution where the task of providing differentiated quality of service is offloaded to ATM switches. Classes are identified by using IP precedence values, then the routers perform classification based on IP precedence values. Up to eight parallel virtual circuits can be used for one IP adjacency. Appropriate ATM services are used for each IP precedence value, depending on the QoS requirements and provisioning. A range of IP precedence values or a single IP precedence value are mapped to one virtual circuit. Non-contiguous IP precedence ranges are not supported.
Review Questions Answer the following questions: 1. How does VC Bundling classify IP packets? 2. Which QoS mechanisms are used when using VC Bundling? 3. How many parallel VCs can be used for one IP adjacency? 4. How many IP precedence values can map into one VC?
10-60
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-VC CB-WFQ Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe per-VC CB-WFQ
n
Configure per-VC CB-WFQ
n
Monitor and troubleshoot per-VC CB-WFQ
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-61
Per-VC CB-WFQ • Class-based Weighted Fair Queuing (CB-WFQ) can be used on ATM interfaces • QoS service policies can be applied to: – An interface – A subinterface – An individual virtual circuit
• Supported service policies are: – – – – –
CB-WFQ including WRED CB-LLQ CB-Marking including setting of ATM CLP bit CB-Shaping CB-Policing including setting of ATM CLP bit
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-68
Per-VC queuing can be supplemented by using the Modular QoS CLI (MQC). ATM PVCs can be combined with any QoS mechanism available with the MQC: n
CB-WFQ for bandwidth management
n
CB-LLQ for delay management
n
CB-Marking
n
CB-Shaping
n
CB-Policing
CB-Marking and CB-Policing also include the capability to mark cells with the Cell Loss Priority (CLP) bit.
10-62
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-interface Per-interface CB-WFQ PVC 0/50
Subinterface ATM1/0/0.1
PVC 0/51 Interface ATM1/0/0
CB-WFQ
PVC 0/52 PVC 0/53 PVC 0/54
Subinterface ATM1/0/0.2
• CB-WFQ can be applied to an entire interface class-map class-map HTTP HTTP match match http http !! policy-map policy-map LimitHTTP LimitHTTP class class HTTP HTTP police police 256000 256000 conform conform transmit transmit exceed exceed set-clp-transmit set-clp-transmit !! interface interface ATM5/0/0 ATM5/0/0 service-policy service-policy output output LimitHTTP LimitHTTP !! © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-69
The figure illustrates an ATM interface with two configured subinterfaces. The first subinterface uses two ATM PVCs, the second subinterface uses three ATM PVCs. A service policy can be applied to an entire ATM interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-63
Per-subinterface CB-WFQ Subinterface ATM1/0/0.1
PVC 0/50
CB-WFQ
PVC 0/51 Interface ATM1/0/0
PVC 0/52 PVC 0/53
CB-WFQ
PVC 0/54
Subinterface ATM1/0/0.2
• CB-WFQ can be applied to subinterfaces class-map class-map CorporateTraffic CorporateTraffic match -group 100 match access access-group 100 !! policy-map policy-map Smart Smart class class CorporateTraffic CorporateTraffic bandwidth bandwidth 10000 10000 class class class-default class-default set set atm-clp atm-clp !!
© 2001, Cisco Systems, Inc.
interface interface ATM5/0/0.1 ATM5/0/0.1 point-to-point point-to-point service-policy service-policy output output Smart Smart pvc pvc Core Core 0/51 0/51 vbr-nrt vbr-nrt 10000 10000 2000 !!
IP QoS IP over ATM-70
A service policy can also be applied to individual ATM subinterfaces.
10-64
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-interface Per-interface CB-WFQ CB-WFQ
PVC 0/50
CB-WFQ
PVC 0/51
CB-WFQ
PVC 0/52
CB-WFQ
PVC 0/53
CB-WFQ
PVC 0/54
Subinterface ATM1/0/0.1
Interface ATM1/0/0
Subinterface ATM1/0/0.2
• CB-WFQ can be applied to an individual virtual circuit
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-71
The highest QoS granularity is achieved by attaching service policies to individual virtual circuits.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-65
Per-interface Per-interface CB-WFQ Configuration Example class-map class-map MatchCorporate MatchCorporate match -group 100 match access access-group 100 !! policy-map policy-map MARK MARK class class MatchCorporate MatchCorporate police -action set-clp-transmit police 2000000 conform-action conform-action transmit transmit exceed exceed-action set-clp-transmit !! interface interface ATM5/0/0 ATM5/0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 service-policy service-policy output output MARK MARK pvc pvc 0/50 0/50 vbr-nrt vbr-nrt 500 500 400 400 1000 1000 inarp inarp 11 broadcast broadcast !! access-list access-list 100 100 permit permit ip ip 10.0.0.0 10.0.0.0 0.255.255.255 0.255.255.255 10.0.0.0 10.0.0.0 0.255.255.255 0.255.255.255
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-72
The example shows how a service policy is used in simple ATM configurations where the main interface is used to establish IP adjacency. The service policy is attached directly to the interface.
10-66
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-VC CB-WFQ Configuration Example class-map class-map MatchCorporate MatchCorporate match -group 100 match access access-group 100 !! policy-map policy-map MARK MARK class class MatchCorporate MatchCorporate police -action set-clp-transmit police 2000000 conform-action conform-action transmit transmit exceed exceed-action set-clp-transmit !! interface interface ATM5/0/0 ATM5/0/0 no no ip ip address address !! interface interface ATM5/0/0.1 ATM5/0/0.1 point-to-point point-to-point ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 pvc pvc 0/50 0/50 vbr-nrt vbr-nrt 500 500 400 400 1000 1000 inarp inarp 11 service-policy service-policy output output MARK MARK broadcast broadcast !! access-list access-list 100 100 permit permit ip ip 10.0.0.0 10.0.0.0 0.255.255.255 0.255.255.255 10.0.0.0 10.0.0.0 0.255.255.255 0.255.255.255
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-73
The more common alternative to configuring ATM is to use subinterfaces. A service policy can be attached to the subinterface or a virtual circuit.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-67
Monitoring and Troubleshooting Per-interface Per-interface CB-WFQ Router#
show policy-map interface ATM-interface
• Displays the Service Policy parameters and statistics for the selected interface or subinterface Router#show Router#show policy policy interface interface atm atm 5/0/0.1 5/0/0.1 ATM5/0/0.1 ATM5/0/0.1 Service-policy Service-policy output: output: Smart Smart (1755) (1755) Class-map: Class-map: CorporateTraffic CorporateTraffic (match-all) (match -all) (1757/42) (1757/42) 00 packets, packets, 00 bytes bytes 55 minute minute offered offered rate rate 0 0 bps, bps, drop drop rate rate 0 0 bps bps Match: Match: access-group access-group 100 100 (1761) (1761) queue size 0, queue limit 2500 queue size 0, queue limit 2500 packets packets output output 0, 0, packet drops 0 tail/random tail/random drops drops 0, 0, no no buffer buffer drops drops 0, 0, other other drops drops 00 Bandwidth: Bandwidth: kbps kbps 10000, 10000, weight weight 29 29 ... ...
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-74
Use the show policy-map interface command to display the parameters and statistics of input and output policies attached to interfaces. This command displays information about all classification options and the attached QoS mechanisms.
10-68
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting Per-VC CB-WFQ Router#
show queueing interface ATM-interface [vc [VPI/]VCI]
• Displays CB-WFQ parameters and statistics for the selected interface, subinterface or VC Router#show Router#show queueing queueing interface interface atm5/0 atm5/0 Interface Interface ATM5/0 ATM5/0 VC VC 0/5 0/5 Queueing Queueing strategy: strategy: fifo fifo Output Output queue queue 0/40, 0/40, 00 drops drops per per VC VC Interface Interface ATM6/0 ATM6/0 VC VC 0/16 0/16 Queueing strategy: fifo Queueing strategy: fifo Output Output queue queue 0/40, 0/40, 00 drops drops per per VC VC Interface Interface ATM6/0 VC 0/50 Queueing Queueing strategy: strategy: weighted weighted fair fair Total Total output output drops drops per per VC: VC: 00 Output queue: 0/512/64/0 (size/max Output queue: 0/512/64/0 (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 0/1/32 0/1/32 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 225 225 kilobits/sec kilobits/sec
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-75
Use the show queueing exec command to list all, or selected, configured queuing strategies.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-69
Summary Per-VC CB-WFQ allows the usage of the same QoS mechanisms as any other technology using single physical interfaces. The same configuration steps are needed to create a service policy. The policy can then be attached to an interface, subinterface or an individual VC. CB-Policing and CB-Marking also support the setting of the ATM CLP bit.
Review Questions Answer the following question: 1. Where can CB-WFQ be attached on ATM interfaces?
10-70
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
RSVP to SVC Mapping Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe RSVP to SVC mapping
n
Configure RSVP to SVC mapping
n
Monitor and troubleshoot RSVP to SVC mapping
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-71
RSVP to SVC Mapping • RSVP-enabled flows have bandwidth and delay requirements • Pass-through RSVP could affect the quality of service in case an ATM interface or PVC is congested • RSVP-enabled flows can get their own VCs and queues to prevent congestion affecting these flows • RSVP reservations are mapped to SVCs
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-80
The RSVP-ATM QoS Interworking feature provides support for Controlled Load Service using RSVP over an ATM core network. This feature requires the ability to signal for establishment of switched virtual circuits (SVCs) across the ATM cloud in response to RSVP reservation request messages. To meet this requirement, RSVP over ATM supports mapping of RSVP sessions to ATM SVCs.
10-72
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
RSVP to SVC Mapping
SVC RSVP
RSVP
• RSVP triggers SVC creation • ATM SVC parameters are calculated from the parameters in the RSVP reservation request
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-81
Traditionally, RSVP has been coupled with WFQ. WFQ provides bandwidth guarantees to RSVP and gives RSVP visibility to all packets visible to it. This visibility allows RSVP to identify and mark packets pertinent to it. The RSVP-ATM QoS Interworking feature provides the capability to decouple RSVP from WFQ, and instead associate it with ATM SVCs to handle reservation request messages (and provide bandwidth guarantees), and NetFlow to make packets visible to RSVP.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-73
ATM SVC Parameters Cell 1 ATM Header
AAL5SNAP Header
5
5
Cell 2 IP Header
Voice Data
43
Sustained Cell Rate
Cell overhead
ATM Header
Voice Data
5
48 Data Link Encapsulation overhead AAL5SNAP has 5 bytes of overhead
SCR = BW RSVP . (53/48) . (MPS + DLE + UCO)/MPS Bandwidth requested by RSVP
Unused
Unused Cell Overhead
Minimum IP packet size
• Peak Cell Rate uses the same formula except it is based on the line rate or the configured peak cell rate © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-82
To ensure correspondence between RSVP and ATM SVC values, the software algorithmically maps the rate and burst size parameters in the RSVP service parameters to the ATM Sustained Cell Rate (SCR) and Maximum Burst Size (MBS). For the Peak Cell Rate (PCR), it uses the value that is configured or it defaults to the line rate. The figure illustrates the formula used to calculate the ATM service parameters from the RSVP service parameters. RSVP does not include the Layer-2 overhead, which is difficult to calculate for ATM. Layer-3 packets are first framed (AAL5SNAP header is prepended) and then segmented in 48-byte cells. Each cell has an additional 5 bytes of overhead.
10-74
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
RSVP to SVC Mapping Optional QoS • RSVP can mark conforming and exceeding packets with different IP precedence or ToS values • Per-VC WRED can be used for differentiated dropping
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-83
In addition to RSVP mapping into SVCs, individual virtual circuits can use IP precedence or ToS marking and WRED for congestion management.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-75
Configuring RSVP to SVC Mapping • The following configuration steps are needed to enable RSVP to SVC mapping: – Enable RSVP – Enable SVC creation – Optionally enable RSVP-based marking and WRED – Verify and monitor RSVP/ATM
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-84
The RSVP-ATM QoS Interworking feature allows the following tasks to be performed:
10-76
IP QoS IP over ATM
n
Enable RSVP by specifying the total amount of bandwidth that can be reserved by RSVP sessions and a maximum amount of bandwidth one session can reserve.
n
Configure an interface or subinterface to dynamically create SVCs in response to RSVP reservation request messages. To ensure defined QoS, these SVCs are established having QoS profiles consistent with the mapped RSVP flow specifications.
n
Optionally, attach distributed Weighted Random Early Detection (dWRED) group definitions to the Enhanced ATM port adapter (PA-A3) interface to support the per-VC dWRED drop policy. Use of per-VC dWRED ensures that, if packets must be dropped, then best-effort packets are dropped first and not those that conform to the appropriate QoS determined by the token bucket of RSVP.
n
Optionally, configure the IP Precedence and ToS values to be used for packets that conform to or exceed QoS profiles. As part of its input processing, RSVP uses the values specified to set the ToS and IP Precedence bits on incoming packets. If per-VC DWRED is configured, it then uses the ToS and IP Precedence bit settings on the output interface of the same router in determining which packets to drop. Also, interfaces on downstream routers use these settings in processing packets.
Copyright 2001, Cisco Systems, Inc.
Enabling RSVP Router(config-if)#
ip rsvp bandwidth reservable-bw max-flow-bw
• Enables RSVP reservation on an interface or subinterface • The reservable-bw parameters specifies the total maximum amount of bandwidth that can be reserved by RSVP flows • The max-flow-bw parameter specifies the maximum amount of bandwidth a single flow can reserve
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-85
The ip rsvp bandwidth interface command is used to enable RSVP on an interface. The interface and per-flow maximum reservable bandwidth limits have to be configured. Note
Copyright 2001, Cisco Systems, Inc.
RSVP cannot reserve more than 75% of the default or configured interface bandwidth.
IP QoS IP over ATM
10-77
Enabling Creation of SVCs Router(config-if)#
ip rsvp svc-required
• Enables creation of SVC for RSVP reservation • ATM QoS parameters are determined by using the parameters in the RSVP request Router(config-if)#
ip ip rsvp rsvp atm-peak-rate-limit atm-peak-rate-limit limit limit
• Sets the peak cell rate for all new SVC • Uses the line rate as the default
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-86
Use the ip rsvp svc-required interface configuration command to enable the creation of a Switched Virtual Circuit (SVC) to service any new Resource Reservation Protocol (RSVP) reservation made on the ATM interface or subinterface. Use the ip rsvp atm-peak-rate-limit interface configuration command to set a limit on the Peak Cell Rate (PCR) of reservations for all newly created Resource Reservation Protocol (RSVP) switched virtual circuits (SVCs) established on the ATM interface or any of its subinterfaces. The PCR, if it is not configured, defaults to the line rate.
10-78
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
RSVP-based Marking and WRED Router(config-if)#
ip rsvp precedence {conform | exceed} precedence precedence
• Packets conforming to the reserved bandwidth are marked with conform precedence • Packets exceeding the reserved bandwidth are marked with exceed precedence • NetFlow has to be enabled Router(config-if)#
random-detect attach random-detect-group random-detect-group
• Enables per-VC WRED • Uses the WRED profiles specified in the WRED group randomdetect-group • CEF switching is required © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-87
Packets in an RSVP reserved path are divided into two classes: those that conform to the reservation service parameters and those that correspond to a reservation but exceed, or are outside, the reservation service parameters. The ip rsvp precedence interface command allows the IP Precedence values to be set to be applied to packets belonging to these two classes. The IP Precedence value for at least one class of traffic must be set when this command is used. A single instance of the command can be used to specify values for both classes, in which case the conform and exceed keywords can be specified in either order. As part of its input processing, RSVP uses the ip rsvp precedence command to set the IP Precedence bits on conforming and nonconforming packets. If per-VC dWRED is configured, the system uses the IP Precedence and ToS bit settings on the output interface in its packet drop process. The IP Precedence setting of a packet can also be used by interfaces on downstream routers. Execution of the ip rsvp precedence command causes IP Precedence values for all preexisting reservations on the interface to be modified. RSVP receives packets from the underlying forwarding mechanism. Therefore, before the ip rsvp precedence command is used to set IP Precedence, one of the following features is required: n
Weighted Fair Queuing (WFQ) must be enabled on the interface
n
RSVP switched virtual circuits (SVCs) must be used in combination with NetFlow
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-79
RSVP to SVC Mapping Example interface interface ATM2/1/0 ATM2/1/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 ip ip rsvp rsvp bandwidth bandwidth 10000 10000 10000 10000 ip ip rsvp rsvp svc-required svc-required ip route-cache flow ip route-cache flow ip 0 ip rsvp rsvp precedence precedence conform conform 5 5 exceed exceed 0 atm atm pvc pvc 11 00 55 qsaal qsaal atm atm pvc pvc 22 0 16 16 ilmi ilmi atm atm esi-address esi-address 111111111151.00 111111111151.00 pvc pvc pvc12 pvc12 0/51 0/51 inarp inarp 55 broadcast broadcast !!
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-88
The sample configuration shows that up to 10Mbps can be reserved by RSVP sessions. RSVP sessions trigger establishment of SVCs and marks conforming packets with IP precedence 5.
10-80
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting RSVP to SVC Mapping Router#
show ip rsvp interface [intf]
• Displays RSVP-related interface information Router#show Router#show ip ip rsvp rsvp interface interface interface allocated interface allocated i/f i/f max max Et4/0 0M 7M Et4/0 0M 7M AT5/0/0 0M 10M AT5/0/0 0M 10M Se5/1/0 0M 192K Se5/1/0 0M 192K
flow flow max max pct pct UDP UDP 5M 00 00 5M 1M 00 00 1M 192K 00 00 192K
IP IP 00 00 00
UDP_IP UDP_IP 00 00 00
UDP UDP M/C M/C 00 00 00
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-89
Use the show ip rsvp interface command to display RSVP parameters and statistics for all RSVP-enabled interfaces. Field interface allocate i/f max flow max pct UDP IP UDP_IP
Copyright 2001, Cisco Systems, Inc.
Description Interface name. Current allocation budget. Maximum allocatable bandwidth. Largest single flow allocatable on this interface. Percent of bandwidth utilized. Number of neighbors sending User Datagram Protocol (UDP)-encapsulated RSVP. Number of neighbors sending IP-encapsulated RSVP. Number of neighbors sending both UDP- and IP-encapsulated RSVP.
IP QoS IP over ATM
10-81
Summary RSVP flows can be provided guarantees either by using a queuing mechanism that supports per-flow queuing (for example, WFQ of CB-WFQ) or it can use dedicated per-flow Switched Virtual Circuits (SVCs) when entering an ATM backbone. Each RSVP flow triggers a generation of a SVC. The SVC inherits service parameters from the RSVP service parameters (modified to account for Layer-2 overhead).
Review Questions Answer the following questions: 1. How does RSVP benefit from using SVCs? 2. What are the necessary configuration steps to enable RSVP-to-SVC?
10-82
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Summary After completing this module, you should be able to perform the following tasks: n
List the requirements of IP QoS in combination with ATM QoS
n
Describe the hardware and software requirements for advanced IP QoS mechanisms on ATM interfaces
n
Describe per-VC queuing
n
Describe and configure per-VC WRED
n
Describe and configure VC bundling
n
Describe and configure per-VC CB-WFQ
n
Describe RSVP to SVC mapping
n
Monitor and troubleshoot IP QoS on ATM interfaces
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-83
Review Questions and Answers Introduction to IP over ATM Question: What are the main differences between IP and ATM? IP is connectionless, ATM is connection oriented IP applies QoS per packet, ATM per virtual circuit IP supports a smaller number of traffic classes (IP precedence, DSCP) and does not include any services by default ATM supports a larger number of traffic classes but has a fixed number of services (xBR) Answer: Which QoS services does ATM support? CBR, VBR, ABR and UBR Question: How should congestion be handled when an ATM backbone is used? Congestion should be pushed back to the ingress into the ATM network to allow IP-based congestion management. Answer: Why is per-VC queuing so important? Per-VC queuing prevents head-of-line blocking and allows per-VC congestion management.
Per-VC WRED Question: What are the benefits of per-VC WRED? Answer: Per-VC WRED allows differentiated congestion avoidance on per-VC basis.
Question: What are the configuration steps needed to enable per-VC WRED? Answer: Per-VC WRED requires the configuration of WRED profiles (random detect groups) which are then attached to individual VCs.
VC Bundling Question: How does VC Bundling classify IP packets? Answer: VC Bundling classifies IP packets based on the IP precedence value. Question: Which QoS mechanisms are used when using VC Bundling? Answer: A QoS design can rely on the ATM QoS or supplement it by using per-VC WRED or CB-WFQ. Question: How many parallel VCs can be used for one IP adjacency? 10-84
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Answer: Up to 8 parallel VCs can be used for one point-to-point IP adjacency. Question: How many IP precedence values can map into one VC? Answer: Up to 8 consecutive IP precedence values can map into one VC.
Per-VC CB-WFQ Question: Where can CB-WFQ be attached on ATM interfaces? Answer: CB-WFQ can be used on per-interface, per-subinterface or per-VC basis.
RSVP to SVC Mapping Question: How does RSVP benefit from using SVCs? Answer: RSVP-based flows can get their QoS resources by using dedicated SVCs with the appropriate ATM QoS parameters derived from the RSVP requests. Question: What are the necessary configuration steps to enable RSVP-to-SVC? Answer: Enable RSVP throughout the network and then enable SVC creation for RSVP flows on ATM interfaces n
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-85
IP over MPLS
Overview This module focuses on the IP QoS mechanisms available in combination with Multiprotocol Label Switching (MPLS).
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe and configure QoS Mechanisms in Frame-mode MPLS networks
n
Describe and configure QoS Mechanisms in Cell-mode MPLS networks
MPLS Introduction Objectives Upon completion of this lesson, you will be able to perform the following tasks:
23-2
n
Describe basic features of MPLS
n
Describe Frame-mode MPLS
n
Describe Cell-mode MPLS
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Basic MPLS Concepts • Multi-protocol Label Switching (MPLS) is a new forwarding mechanism in which packets are forwarded based on labels • Labels may correspond to IP destination networks (equal to traditional IP forwarding) • Labels can also correspond to other parameters (QoS, source address, ...) • MPLS was designed to support forwarding of other protocols as well
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Multi-protocol Label Switching (MPLS) is a switching mechanism that uses labels (numbers) to forward packets. Labels usually correspond to layer-3 destination addresses (equal to destinationbased routing). Labels can also correspond to other parameters (QoS, source address, etc.). MPLS was designed to support other protocols as well. Label switching is performed regardless of the layer-3 protocol.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-3
MPLS Example 10.1.1.1
10.1.1.1
L=3
Label removal and routing lookup L=3
5 L=
Routing lookup and label assignment 10.0.0.0/8 à L=5 Label swapping L=5 à L=3
• Only edge routers must perform a routing lookup. • Core routers switch packets based on simple label lookups and swap labels. © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The example in the figure illustrates a situation where the intermediary router does not have to perform a time-consuming routing lookup. Instead this router simply swaps a label with another label (5 is replaced by 3) and forwards the packet based on the received label (5). In larger networks, the result of MPLS labeling is that only the edge routers perform a routing lookup. All the core routers forward packets based on the labels.
23-4
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS vs. IP-over-ATM 10.1.1.1
L=17
L=3
L=5
10.1.1.1
Layer-2 devices run a layer-3 routing protocol and establish virtual circuits dynamically based on layer-3 information
• Layer-2 devices are IP-aware and run a routing protocol • There is no need to manually establish virtual circuits • MPLS provides a virtual full-mesh topology © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The example in the figure shows how MPLS is used in ATM networks to provide optimal routing across layer-2 ATM switches. In order for MPLS to work with ATM switches, the switches must be layer-3 aware (ATM switches must run a layer-3 routing protocol). Another benefit of this setup is that there is no longer a need to manually establish virtual circuits. ATM switches automatically create a full mesh of virtual circuits based on layer-3 routing information.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-5
Traffic Engineering with MPLS Primary OC-192 link
Large site A
Large site B
Secondary OC-48 link
Small site C
• Traffic can be forwarded based on other parameters (QoS, source, ...) • Load sharing across unequal paths can be achieved © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
MPLS also supports traffic engineering. Traffic engineered tunnels can be created based on a traffic analysis to provide load balancing across unequal paths. Multiple traffic engineering tunnels can lead to the same destination but can use different paths. Traditional IP forwarding would force all traffic to use the same path based on the destination-based forwarding decision. Traffic engineering determines the path at the source based on additional parameters (available resources and constraints in the network).
23-6
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Architecture • MPLS has two major components: • Control plane – exchanges layer-3 routing information and labels • Data plane – forwards packets based on labels
• Control plane contains complex mechanisms to exchange routing information (OSPF, EIGRP, IS-IS, BGP,...) and labels (TDP, LDP, BGP, RSVP, ...) • Control plane maintains the contents of the label switching table (label forwarding information base or LFIB) • Data plane has a simple forwarding engine
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
To better understand the inner workings of MPLS, its two major components should be clarified: n
Control plane, which takes care of the routing information exchange and the label exchange between adjacent devices
n
Data plane, which takes care of forwarding either based on destination addresses or labels.
There is a large number of different routing protocols such as OSPF, IGRP, EIGRP, IS-IS, RIP, BGP, etc. that can be used in the control plane. The control plane also requires protocols such as TDP (MPLS), LDP (MPLS), BGP (MPLS/VPNs), RSVP (Traffic Engineering), CR-LDP (Traffic Engineering), etc. to exchange labels. The data plane however, is a simple label-based forwarding engine that is independent of the type of routing protocol or label exchange protocol. A Label Forwarding Information Base (LFIB) is used to forward packets based on labels. The LFIB table is populated by the control plane.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-7
MPLS Architecture Control plane OSPF: 10.0.0.0/8
LDP: 10.0.0.0/8 Label 17
OSPF
LDP
OSPF: 10.0.0.0/8
LDP: 10.0.0.0/8 Label 4
Data plane Labeled packet Label 17
LFIB 4à17
Labeled packet Label 4
• Router’s functionality is divided into two major parts: control plane and data plane © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
A simple MPLS-enabled network implements destination-based forwarding that uses labels to make forwarding decisions. A layer-3 routing protocol is still needed to propagate layer-3 routing information. A label exchange mechanism is simply an add-on to propagate labels that are used for layer-3 destinations. The example in the figure illustrates the two components of the control plane: n
OSPF that receives and forwards IP network 10.0.0.0/8, and places that prefix into the routing table.
n
LDP that receives label 17 to be used for packets with a destination address 10.x.x.x. A local label 4 is generated and sent to upstream neighbors so these neighbors can label packets with the appropriate label. LDP inserts an entry into the Data Plane’s LFIB table where label 4 is mapped to label 17.
The data plane then forwards all packets with label 4 through the appropriate interfaces and replaces the label with label 17.
23-8
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Modes of Operation • MPLS technology is designed to be Layer-1 and Layer-2 independent • MPLS uses a 32-bit label field which is inserted between Layer-2 and Layer-3 headers (frame mode) • MPLS over ATM uses the ATM header as the label (cell mode)
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
MPLS is designed for use on virtually any media and layer-2 encapsulation. Most layer-2 encapsulations are frame-based and MPLS simply inserts a 32-bit label between the layer-2 and layer-3 headers (“frame-mode” MPLS). ATM is a special case where fixed-length cells are used and a label cannot be inserted on every cell. MPLS uses the VPI/VCI fields in the ATM header as a label (“cell-mode” MPLS).
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-9
Label Format LABEL 0
EXP S 19 20
22 23 24
TTL 31
MPLS uses a 32-bit label field that contains the following information: • 20-bit label • 3-bit experimental field • 1-bit bottom-of-stack indicator • 8-bit time-to-live field (TTL)
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
A 32-bit label contains the following fields:
23-10
n
20-bit label: the actual label
n
3-bit experimental field: used to define a class of service (i.e. IP precedence)
n
Bottom-of-stack bit: MPLS allows multiple labels to be inserted; this bit is used to determine if this is the last label in the packet
n
8-bit time-to-live (TTL) field: has the same purpose as the TTL field in the IP header
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Frame Mode MPLS Frame header Layer 2
IP header
Payload
Layer 3
Routing lookup and label assignment
Frame header Layer 2
Label
IP header
Layer 2½
Payload
Layer 3
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The example in the figure shows an edge router that receives a normal IP packet. The router then performs the following actions: n
A routing lookup to determine the outgoing interface
n
A label is assigned and inserted between layer-2 frame header and layer-3 packet header if the outgoing interface is enabled for MPLS and a next-hop label for the destination exists
n
The labeled packet is sent
Other routers in the core simply forward the packet based on the label.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-11
Cell mode MPLS Frame header
IP header
Layer 2
Frame header Layer 2
Payload
Layer 3
Label
IP header
Layer 2½
Payload
Layer 3
VPI/VCI fields are used for label switching
Cell 1
ATM header
AAL5 header
Layer 2
Cell 2
ATM header
© 2001, Cisco Systems, Inc.
Label Layer 2½
IP header
Payload
Layer 3
Payload
IP QoS IP over MPLS
Cell-mode MPLS uses the ATM header’s VPI/VCI fields to make forwarding decisions while the 32-bit label is still preserved in the frame but not used in the ATM network. The original label is only present in the first cell of a packet.
23-12
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Label Switch Router MPLS Domain 10.1.1.1
20.1.1.1
Edge LSR
L=3
L=5
L=31
L=43
10.1.1.1
20.1.1.1
LSR
• Label Switch Router (LSR) primarily forwards labeled packets (label swapping) • Edge LSR primarily labels IP packets and forwards them into the MPLS domain, or removes labels and forwards IP packets out of the MPLS domain © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Before proceeding with a detailed description of MPLS, some of the terminology that is used in this course is presented: n
Label Switch Router (LSR): a device that primarily forwards packets based on labels.
n
Edge LSR: a device that primarily labels packets or removes labels.
LSRs and Edge LSRs are usually devices that are capable of doing both label switching and IP routing. Their names are based on their position in an MPLS domain. Routers that have all interfaces enabled for MPLS are called LSRs because they mostly forward labeled packets. Routers that have some interfaces that are not enabled for MPLS are usually at the edge of an MPLS domain (autonomous system). These routers also forward packets based on IP destination addresses and label them if the outgoing interface is enabled for MPLS.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-13
ATM Label Switch Router MPLS Domain 10.1.1.1
20.1.1.1
L=1/3
L=1/3
L=1/3
L=1/5
L=1/5
L=1/5
L=1/6 L=1/6
L=1/6
L=1/9 L=1/9
L=1/9
ATM Edge LSR
10.1.1.1
20.1.1.1
ATM LSR
• ATM LSR can only forward cells • ATM Edge LSR segments packets into cells and forwards them into an MPLS ATM domain, or reassembles cells into packets and forwards them out of an MPLS ATM domain © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Label Switch Routers that perform cell-mode MPLS are called:
23-14
n
ATM LSR if they are ATM switches. All interfaces are enabled for MPLS and forwarding is done based only on labels.
n
ATM Edge LSR if they are routers connected to an MPLS-enabled ATM network.
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Architecture of LSRs LSRs, regardless of the type, perform the following three functions: • Exchange routing information • Exchange labels • Forward packets (LSRs and edge LSRs) or cells (ATM LSRs and ATM edge LSRs)
The first two functions are part of the control plane The last function is part of the data plane © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
LSRs of all types must perform the following functions: n
Exchange layer-3 routing information (ATM LSRs must also exchange layer-3 routing information)
n
Exchange labels
n
Forward packets or cells
Frame-mode and cell-mode MPLS use a different data plane: n
Frame-mode MPLS forwards packets based on the 32-bit label
n
Cell-mode MPLS forwards packets based on labels encoded into the VPI/VCI fields in the ATM header
The control plane performs the following functions: n
Exchange routing information regardless of the type of LSR;
n
Exchange labels according to the type of MPLS (frame-mode or cell-mode);
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-15
Architecture of LSRs LSR Exchange of routing information
Control plane Routing protocol IP routing table
Exchange of labels
Incoming labeled packets
Label distribution protocol
Data plane Label forwarding table
Outgoing labeled packets
LSRs primarily forward labeled packets or cells (ATM LSRs) © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The primary function of an LSR is to forward labeled packets. Therefore, every LSR needs a layer-3 routing protocol (OSPF, EIGRP, IS-IS, etc.) and a label exchange protocol (LDP, TDP, etc.). The label exchange protocol populates the LFIB table in the data plane that is used to forward labeled packets. Note
23-16
LSRs may not be able to forward unlabeled packets either because they are ATM LSRs, or they do not have all the routing information.
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Architecture of Edge LSRs Edge LSR Exchange of routing information
Control plane Routing protocol IP routing table
Exchange of labels
Incoming IP packets Incoming labeled packets
Label distribution protocol
Data plane IP forwarding table Label forwarding table
Outgoing IP packets Outgoing labeled packets
Note: ATM edge LSRs can only forward cells © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Edge LSRs also forward IP packets based on their IP destination addresses and optionally label them if a label exists. The following combinations are possible: n
A received IP packet is forwarded based on the IP destination address and sent as an IP packet.
n
A received IP packet is forwarded based on the IP destination address and sent as a labeled packet.
n
A received labele d packet is forwarded based on the label; the label is changed and the packet is sent.
The following scenarios are possible if the network is misconfigured: n
A received labeled packet is dropped if the label is not found in the LFIB table even if the IP destination exists in the FIB table.
n
A received IP packet is dropped if the destination is not found in the FIB table even if there is a label-switched path available for the destination.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-17
Summary MPLS architecture is divided into two parts: n
Control plane that takes care of routing information and label propagation.
n
Data plane that takes care of the forwarding of packets.
MPLS has two modes: n
Frame-mode MPLS that is used on all frame-based media.
n
Cell-mode MPLS that is used in MPLS-enabled ATM networks.
MPLS networks use the following devices: n
Label Switch Router (LSR) to forward packets based on a 32-bit label
n
Edge LSR to forward labeled packets or label IP packets or remove labels.
n
ATM LSRs to forward cells based on labels encoded into the VPI/VCI fields in the ATM header.
n
ATM Edge LSRs that segment labeled or unlabeled packets into ATM cells where a label is encoded into VPI/VCI fields in the ATM header.
Review Questions 1. What are the main benefits of MPLS? 2. How is an MPLS label encoded into IP packets? 3. How are labels propagated?
23-18
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Frame-mode MPLS Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe the QoS possibilities in networks using Frame-mode MPLS
n
Use MQC to implement QoS with Frame-mode MPLS
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-19
MPLS QoS • MPLS uses labels to make a forwarding decision • The MPLS label is inserted between Layer-2 (frame) and Layer-3 (IP packet) headers • All Layer-3 information becomes invisible to routers in an MPLS domain • Classification in MPLS-enabled networks can be performed on: • MPLS experimental bits • MPLS labels (future enhancement)
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Frame-mode MPLS uses 32-bit labels primarily to make a forwarding decision. Three bits in the label are used for experimental purposes. When an IP packet enters an MPLS domain a label is inserted between the frame and the IP header. The MPLS experimental bits can be used for classification and marking purposes when implementing QoS in an MPLS domain. Future enhancements will allow multiple labels to be used to describe the quality of service.
23-20
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Label Assignment Frame Header
IP
Payload
IP precedece
MPLS exp
Frame Header
LABEL
IP
Payload
• An MPLS label has a three-bit experimental field • Cisco routers automatically copy IP precedence bits into the MPLS experimental bits • The Modular QoS CLI can be used to classify labeled packets based on their MPLS experimental bits © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The figure illustrates the default behavior of Cisco routers. IP precedence is automatically copied from the IP header into MPLS label’s experimental bits. The modular QoS CLI can be used to classify labeled packets based on MPLS experimental bits as well as mark labeled packets with MPLS experimental-bit values.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-21
MPLS-aware QoS Mechanisms • The following QoS mechanisms are MPLS aware: - Weighted Random Early Detection (WRED): MPLS experimental bits are used as weight in the same manner as IP precedence - Committed Access Rate (CAR): marking of MPLS experimental bits - Class-Based Policing: marking of MPLS experimental bits - Class-based Marking: marking of MPLS experimental bits
• If classification is performed based on MPLS experimental bits, other MQC QoS mechanisms can also be used
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The figure lists the QoS mechanisms that can interact with MPLS-specific information: n
WRED performs random drops based on MPLS experimental values.
n
CAR can mark labeled packets with MPLS experimental values. Conforming and exceeding packets can be marked with different MPLS experimental values.
n
Class-based Policing can mark labeled packets with MPLS experimental values. Conforming, exceeding and violating packets can be marked with different MPLS experimental values.
n
Class-based Marking can statically mark labele d packets with an MPLS experimental value.
Other QoS mechanisms (for example: CB-WFQ, CB-LLQ) can be used in combination with classification that is based on the value of the MPLS experimental bits.
23-22
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Configuring CB-WFQ for MPLS Router(config-cmap)#
match mpls experimental exp
• Classifies packets based on MPLS experimental bits class-map class-map match-any match-any Gold Gold match match ip ip precedence precedence 33 44 match match mpls mpls experimental experimental 33 44 !! class-map class-map match-any match-any Silver Silver match match ip ip precedence precedence 11 22 match match mpls mpls experimental experimental 11 22 !! policy-map policy -map IP+MPLS class class Gold bandwidth bandwidth 3000 class class Silver Silver bandwidth bandwidth 1000 1000 !! Interface Interface Ethernet0/0 Ethernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 mpls mpls ip ip service-policy output service-policy output IP+MPLS IP+MPLS !! © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Classification based on MPLS experimental bits is performed by using the match mpls experimental command in the class-map configuration mode. Up to eight values can be used within one class map. The sample configuration shows a generic class map using the match-any classification strategy to classify IP packets and labeled packets with the same IP precedence or MPLS experimental value.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-23
CAR Diagram Meter Meter
Conforms? Conforms?
Conform or exceed marking value
Transmit? Transmit?
Yes
Forward or Enqueue
No Mark? Mark? Set Set IP IP prec? prec? Set Set DSCP? DSCP? Set Set MPLS MPLS exp? exp? Set Set QoS QoS grp? grp?
Continue? Continue? Yes
Yes
Yes
Yes
Set Set IP IP Precedence Precedence Set Set DSCP DSCP
Yes
Go to Next CAR command
No Drop Drop
Set SetMPLS MPLSExperimental Experimental Set Set QoS QoS Group Group
• Marking depends on whether the packet conforms to or exceeds the policy © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Committed Access Rate (CAR) can be used to differentially mark packets based on the arrival rate of packets within the selected class. If a packet conforms (is within contract) it is marked with one value, if it exceeds it is marked with a different value. CAR also supports recursive processing of packets. One packet can be processed by multiple rate-limit commands.
23-24
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Configuring Configuring CAR for MPLS Router(config-if)# rate-limit {input | output} {access-group rate-limit rate-limit acl} acl} rate B CC BBEE conform-act {set-mpls-exp-transmit exp exp | set-mpls-exp-continue set-mpls-exp-continue exp} exp} exceed-act exceed-act {set-mpls-exp-transmit {set-mpls-exp-transmit exp | set-mpls-exp-continue exp}
• CAR can mark MPLS packets based on their arrival rate • CAR supports recursive processing of rate-limit commands • CAR supports classification based on MPLS experimental bit values by using rate-limit access list • Both conform and exceed actions support other actions: transmit, continue, drop, set-prec-transmit, set-prec-continue, … interface interface Serial0/0 Serial0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.252 255.255.255.252 rate-limit rate-limit input 64000 2000 2000 2000 conform conform set set-mpls-exp-tr -mpls-exp-tr 55 exceed exceed setsetmpls -exp-tr 0 mpls-exp-tr 0 rate-limit rate-limit output output 64000 64000 2000 2000 2000 2000 conform conform set-mpls-exp-tr set-mpls-exp-tr 55 exceed exceed set setmpls -exp-tr 00 mpls-exp-tr !!
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
CAR also supports a special rate-limit access list that can match labeled packets based on their MPLS experimental values. The action options include the two that can set MPLS experimental values: n
set-mpls-exp-continue: sets the MPLS experimental bits (0 to 7) and evaluates the next rate-limit command.
n
set-mpls-exp-transmit: set the MPLS experimental bits (0 to 7) and transmits the packet.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-25
Configuring CAR for MPLS Router(config)# access-list access-list rate-limit rate-limit acl {exp | mask mask mask} mask}
• The acl index must be between 200 and 299 to select the rate limit access list for MPLS experimental bits • Rate limit access lists can be used to match on one or more MPLS experimental values • Set one value (exp) to be matched or use the mask option to match on more values • Each access list can have only one line interface interface Serial0/0 Serial0/0 rate-limit rate-limit output access-group access-group rate-limit 200 64000 64000 2000 2000 2000 conform conform transmit transmit exceed exceed drop drop rate-limit rate-limit input input access-group access-group rate-limit rate-limit 201 201 64000 64000 2000 2000 2000 2000 conform conform setsetmpls-exp-tr mpls-exp-tr 00 exceed exceed set-mpls-exp-tr set-mpls-exp-tr 00 !! access-list access-list rate-limit rate-limit 200 200 22 access-list access-list rate-limit rate-limit 201 201 mask mask FE !! © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Special rate-limit access lists allow high-performance classification based on the following parameters: n
IP precedence value if the number of the access list is in the range from 1 to 99
n
MAC address if the number of the access list is in the range from 100 to 199
n
MPLS experimental bits if the number of the access list is in the range from 200 to 299
A rate limit access list can have only one line. A single MPLS experimental value can be matched by setting the exp value. Multiple values can be matched by using the mask keyword and applying a mask in hex. This mask is an 8 bit value where each bit corresponds to one experimental value 0 through 7. The low order bit corresponds to value 0 and the high-order bit corresponds to value 7. Setting the bit value to 1 indicates that the corresponding experimental value is a match; setting the value to 0 indicates that the corresponding value is not a match. A combination of bits in the mask can be used to match on any number of MPLS experimental values. For example, to match an experimental value of 0, the mask would be 01 (0000 0001 binary). To match a value of 5, the mask would be 20 (0010 0000 binary). The second rate-limit command in the sample configuration above uses the mask FE (1111 1110 binary) to match all MPLS experimental values except value 0.
23-26
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
CB-Policing • CB-Policing is similar to CAR except: - It uses the Modular QoS CLI for classification - It supports three different actions (conform, exceed and violate) - It does not support recursive processing of packets
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Class-based Policing is used for the same purpose as CAR. CB-Policing differs from CAR in the following ways: n
The Modular QoS CLI is used to classify packets.
n
It can use two token buckets to determine whether a packet conforms to, exceeds or violates the policy.
n
It does not support recursive processing of packets (the continue option is not available).
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-27
Configuring Configuring CB-Policing for MPLS Router(config-pmap-c)#
police avg-rate [BCC [BE]] [conform-action [conform-action [action] [exceed-action [action] [action] [violate-action [action]]]] [action]]]]
• avg-rate – traffic rate in bps (8.000 to 200.000.000) • BC – normal burst size dimensions the first token bucket in bytes (default is 1500 or avg-rate/32; whatever is higher) • BE – excess burst size dimensions the second token bucket in bytes (equals BC if not configured) • action – can be: -
transmit (default conform action) drop (default exceed and violate action) set-prec-transmit ip-precedence set-dscp-transmit dscp set-qos-transmit qos-group set-mpls-exp-transmit mple-exp set frde-transmit set-clp-transmit
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The figure shows that one of several actions can be used to mark labeled packets with an MPLS experimental value. Three different values can be used within a single class depending on whether a packet conforms to, exceeds or violates the policy.
23-28
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
CB Marking • Class-based Marking can be used to mark labeled packets by setting the MPLS experimental bits • MPLS experimental bits can currently only be set on input • DSCP should be translated to IP precedence prior to entry into an MPLS domain
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Class-based Marking can use the classification options available in the Modular QoS CLI and statically mark classes with the MPLS experimental values. Implementation limitations should be considered when translating between any pair of parameters on MPLS domain borders (DSCP to MPLS, IP precedence to MPLS). MPLS marking is currently only supported on input. Inbound IP packets can be directly marked with MPLS experimental values. Using the QoS group parameter is necessary when translating MPLS experimental values back to IP precedence or DSCP (for example: MPLS to QoS group translation on input and QoS group to DSCP translation on output). This functionality and these limitations may change with new IOS versions.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-29
Configuring MPLS Marking Router(config-pmap-c)#
set mpls experimental exp-bits
• Mark labeled packets with the specified value (0 to 7) • MPLS marking can only be used on input policy-map policy-map SetMPLS SetMPLS class class Class1 Class1 qos-group qos-group set mpls mpls experimental experimental class class Class2 Class2 qos-group qos-group set mpls mpls experimental experimental class class Class3 Class3 qos-group qos-group set mpls mpls experimental experimental !!
© 2001, Cisco Systems, Inc.
11 11 22 22 22 33
IP QoS IP over MPLS
Use the set mpls experimental command in the policy-map class configuration mode to mark inbound packets with MPLS experimental values. The sample configuration shows how a QoS group parameter can be translated into MPLS experimental bits.
23-30
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Translation Case Study IP Domain MPLS Domain
• IP domain is using the DiffServ model: -
EF – Class Premium AF1 – Class Gold AF2 – Class Silver Default – Best effort class
• Translate IP DSCP values to and from MPLS experimental bits to achieve a similar result in the MPLS domain © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The QoS design in the case study uses DSCP to mark packets. Four classes must also be managed in the MPLS domain. A translation between DSCP and MPLS is needed to implement a similar QoS solution in the MPLS domain. Although standard DSCP values for AF classes seamlessly map to IP precedence values for backward compatibility it is sometimes necessary to manually translate markers between DSCP an IP precedence or DSCP and MPLS. For example: n
n
A QoS design based on IP precedence is using two IP precedence values to mark packets belonging to one class: -
Class Premium is marked with IP precedence 5 and is guaranteed low latency
-
Class Gold is using IP precedence 4 for conforming (low-drop) packets and IP precedence 3 for exceeding (high-drop) packets
-
Class Silver is using IP precedence 2 for conforming (low-drop) packets and IP precedence 1 for exceeding (high-drop) packets
-
Best effort traffic is marked with IP precedence 0
When migrating to DSCP-based implementation it is necessary to still support the old QoS design until the entire network is migrated to support DSCP.
The case study shows how this translation can be done manually. If the original IP-precedence-based design did not use multiple IP precedence values per class there should be no need to configure the translation manually. All class-maps, however, should include class selectors in their match options to support backward compatibility with IP precedence: n
Copyright 1999, Cisco Systems, Inc.
Matching packets for AF1 requires af11, af12, af13 and cs1 to be matched
Release Date: 2/1/99
23-31
n
Matching packets for AF2 requires af21, af22, af23 and cs2 to be matched
n
Matching packets for AF3 requires af31, af32, af33 and cs3 to be matched
n
Matching packets for AF4 requires af41, af42, af43 and cs4 to be matched
n
Matching packets for EF requires ef and cs5 to be matched
The solution shown on the following pages illustrates how default behavior can be changed by manually configuring the translation between IP precedence (MPLS experimental bits) and the DSCP.
23-32
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Translation Case Study Design DSCP
IP precedence QoS group
IP Domain
© 2001, Cisco Systems, Inc.
MPLS exp MPLS Domain
IP DSCP
MPLE experimental
EF AF1 low-drop AF1 medium-drop AF1 high-drop AF2 low-drop AF2 medium-drop AF2 high-drop Default
5 4 4 3 2 2 1 0 IP QoS IP over MPLS
The figure illustrates how DSCP values should be mapped to IP precedence or MPLS experimental values. Some information is lost because low-drop and medium-drop packets of AF1 and AF2 are marked as one low-drop class in the MPLS domain. The case study shows how some information about the conforming and exceeding packets within one class can be retained when entering a non-DSCP part of the network (either because routers do not support DSCP or because MPLS experimental bits are used to select Class of Service). The figure illustrates the translation from three drop probability levels on the DSCP layer into two drop probability level in the IP precedence (MPLS experimental) layer. Using this design further limits the network to only use two classes for AF PHB.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-33
MPLS Translation Case Study Implementation IP precedence DSCP IP Domain class-map class-map EF EF match match ip ip dscp dscp ef ef class-map class-map AF1LD AF1LD match match ip ip dscp dscp af11 af11 af12 af12 class-map class-map AF1HD AF1HD match match ip ip dscp dscp af13 af13 !! policy-map policy-map DSCP2prec DSCP2prec class class EF EF set set ip ip precedence precedence 55 class class AF1LD AF1LD set set ip ip precedence precedence 44 class class AF1HD AF1HD set set ip ip precedence precedence 33 !! © 2001, Cisco Systems, Inc.
MPLS exp MPLS Domain
interface interface Serial5/1/0 Serial5/1/0 service-policy service-policy input DSCP2prec !!
IP QoS IP over MPLS
The first part of the configuration shows how DSCP is translated to IP precedence on ingress into the MPLS network. IP precedence is then automatically copied into MPLS experimental bits. The default DSCP value equals the default IP precedence value and does not need to be translated. The EF class does not need to be translated either because the EF value (101110) is copied as IP precedence into the MPLS experimental field (101), which equals 5. The configuration for AF2 is not shown in the figure.
23-34
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Translation Case Study Implementation QoS group DSCP
MPLS exp
IP Domain class-map class-map match-any match-any MPLS5 MPLS5 match match mpls exp 5 match match ip ip precedence precedence 5 5 class-map class-map match-any match-any MPLS4 MPLS4 match match mpls mpls exp exp 4 match match ip precedence 4 class-map class-map match-any match-any MPLS3 MPLS3 match match mpls mpls exp exp 3 match match ip ip precedence precedence 3 3 !! policy-map MPLS2QoS policy-map class class MPLS5 set set qos-group qos-group 5 class class MPLS4 set set qos-group qos-group 4 4 class class MPLS3 MPLS3 set set qos-group qos-group 3 © 2001, Cisco Systems, Inc.
MPLS Domain class-map class-map QoS5 QoS5 match match qos-group qos-group 55 class-map class-map QoS4 QoS4 match match qos-group qos-group 44 class-map class-map QoS3 QoS3 match match qos-group qos-group 33 !! policy-map policy-map QoS2DSCP class class QoS5 QoS5 set set ip ip dscp dscp ef ef class QoS4 class QoS4 set set ip dscp dscp af12 af12 class class QoS3 QoS3 set set ip dscp dscp af13 af13 !!
interface interface Serial5/1/1 Serial5/1/1 service-policy service-policy input input MPLS2QoS MPLS2QoS !! interface interface Serial5/1/0 Serial5/1/0 service-policy service-policy output output QoS2DSCP QoS2DSCP
IP QoS IP over MPLS
The remainder of the configuration is used to translate MPLS experimental values back into DSCP. The class-maps are configured to process IP packets (very likely due to penultimate hop popping) or labeled packets. Low-drop packets are translated into medium-drop packets in the DiffServ domain.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-35
Summary Frame-mode MPLS allows most IP QoS mechanisms to be used. The three MPLS experimental bits are used in the same way as IP precedence. IP precedence is actually copied into MPLS experimental bits.
Review Questions 1. Which MPLS parameter is used for classification and marking? 2. What is the default value of the MPLS experimental bits? 3. Which QoS mechanisms can be used to set MPLS experimental bits?
23-36
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Cell-mode MPLS Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe QoS features available with Cell-mode MPLS
n
Implement QoS on interfaces using Cell-mode MPLS
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-37
Cell-mode MPLS QoS • Classes are encoded with MPLS experimental bits • Cell-mode MPLS uses the VPI/VCI fields as labels for forwarding • ATM switches are not capable of looking into the frame-mode label where the experimental bits are • QoS is implemented using up to four parallel virtual circuits (label-switched paths)
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
ATM is a Layer-2 technology that does not use frames to transmit Layer-3 packets. Packets are fragmented into fixed-length cells. Cell-mode MPLS makes use of the ATM header to encode labels into VPI/VCI fields. These fields are only used to make a forwarding decision. QoS cannot be achieved using MPLS experimental bits because: n
They are only propagated in the first cell of a packet.
n
ATM switches do not look into the payload of cells.
QoS is therefore achieved using multiple labels (up to four).
23-38
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Cell-mode MPLS
Cell-mode MPLS Frame-mode MPLS Native IP
• IP precedence used in IP domain is automatically translated into MPLS experimental bits • MPLS experimental bits are optionally translated into up to four parallel virtual circuits (label-switched paths) © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The figure illustrates how IP packets can be propagated over a native IP network (no MPLS and no ATM or with ATM PVCs), a frame-based MPLS network and a cell-based MPLS network. QoS is retained when IP packets enter a frame-based MPLS network by copying the IP precedence bits into MPLS experimental bits. When labeled packets enter a cell-based MPLS network, QoS is retained by forwarding the packet through one of four VCs, which are based on the value of MPLS experimental bits.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-39
Configuring Multi-VC Router(config-if)#
mpls atm multi-vc
• The command enables Multi-VC operation of cell-mode MPLS • Eight MPLS experimental values are mapped to four virtual circuits • The class is determined by the two least significant MPLS experimental bits • Default mapping is similar to classification of distributed ToS-based WFQ • Default mapping can be replaced using the cos-map command
© 2001, Cisco Systems, Inc.
MPLS exp VC 0 1 2 3 4 5 6 7
Available Standard Premium Control Available Standard Premium Control
IP QoS IP over MPLS
Cell-mode MPLS uses one single VC for each IP destination. Use the mpls atm multi-vc interface command to enable routers to request up to four VCs for each IP destination. Classification is based on the low-order two bits of the MPLS experimental field (like ToS-based dWFQ). The table in the figure shows the default mapping of MPLS values into four VCs: available, standard, premium and control. Default mapping can be changed using the mpls cos-map and mpls prefix-map commands.
23-40
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Configuring CoS Mapping Router(config)#
mpls mpls cos-map number
• Create a CoS map • Allowed values are from 1 to 255 Router(config-mpls-cos-map)#
class class {available | control | premium | standard}
• Assigns a class to one of four virtual circuits • Class values can be in the range from 0 to 3 Router(config)#
mpls mpls prefix-map pfmap access-list acl cos-map cos-map
• Uses CoS map cos-map for all destinations permitted by access list acl © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
A CoS map must be configured to change the default behavior of the translation of MPLS experimental values into one of four virtual circuits (available, standard, premium and control). Classes are identified by the two low-order bits of the MPLS experimental field. Use the mpls prefix-map command to bind a cos-map to all destinations permitted by the acl access list. Note
Copyright 1999, Cisco Systems, Inc.
Most MPLS-related commands are available with the starting keyword mpls or the older tag-switching version. Furthermore, using the mpls keyword results in the command being automatically translated into the tag-switching version for compatibility with older IOS versions.
Release Date: 2/1/99
23-41
Configuration Example tag-switching prefix-map 10 access-list 100 cos-map cos-map 10 tag-switching prefix-map 11 access-list 101 cos-map cos-map 10 tag-switching prefix-map 21 access-list access-list 32 cos-map 34 34 ! tag-switching cos-map cos-map 10 10 class class 00 available class class 1 standard class class 22 premium premium class class 33 control control ! interface interface ATM1/0.1 ATM1/0.1 mpls ip ip unnumbered unnumbered Loopback0 Loopback0 no no ip ip mroute-cache mroute-cache mpls mpls atm atm multi-vc multi-vc mpls mpls ip ! access-list 100 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The sample configuration shows that all traffic to network 10.0.0.0/8 uses four parallel VCs. MPLS experimental bits are mapped using cos-map 10. Note that only prefix map 10 is properly configured. Prefix map 11 does not have the corresponding access list and prefix map 21 is missing the CoS map as well.
23-42
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Monitoring and Troubleshooting Cell-mode MPLS Router#
show mpls cos-map [cos-map]
• Lists all configured CoS maps Router#show Router#show mpls mpls cos-map 10 cos-map class tag-VC cos-map 10 tag-VC 33 control control 22 premium premium 11 standard standard 00 available available Router# Router#
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Use the show mpls cos-map command to verify the parameters assigned to a cos-map.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-43
Monitoring and Troubleshooting Cell-mode MPLS Router#
show mpls prefix-map [prefix-map]
• Lists all configured prefix maps Router#show Router#show mpls mpls prefix-map prefix-map prefix-map prefix-map 10 10 access-list access-list 100 100 cos-map cos-map 10 10 prefix-map prefix-map 11 11 access-list access-list 101 101 cos-map cos-map 10 10 Warning: Warning: In prefix-map prefix -map 11, 11, acl acl 101 101 is is not not configured configured prefix-map prefix-map 21 21 access-list access-list 32 32 cos-map cos-map 34 Warning: Warning: In prefix-map prefix -map 21, 21, acl acl 32 32 and and cos-map cos-map 34 34 are are not not configured configured Router# Router#
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Use the show mpls prefix-map command to display one or all configured prefix maps with their corresponding access lists and cos-maps. Using this command helps determine if there is a component missing:
23-44
n
Access list 101 is not configured for prefix map 11
n
Prefix map 21 is missing both the access list and the CoS map
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Summary Cell-mode MPLS uses up to four virtual circuits to achieve differentiated quality of service. Packets are classified based on the two low-order bits of the MPLS experimental field.
Review Questions 1. How is differentia ted QoS implemented on MPLS-enabled ATM interfaces? 2. What information is used for classification in cell-mode MPLS?
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-45
Summary After completing this module, you should be able to perform the following tasks:
23-46
n
Describe and configure QoS Mechanisms in Frame-mode MPLS networks
n
Describe and configure QoS Mechanisms in Cell-mode MPLS networks
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Review Questions and Answers MPLS Introduction Question: What are the main benefits of MPLS? Answer: Simplified BGP designs, support for MPLS-based VPNs. Question: How is an MPLS label encoded into IP packets? Answer: A 32-bit label header is inserted in front of the IP header. Question: How are labels propagated? Answer: Labels are propagated between adjacent routers using TDP or LDP.
Frame-mode MPLS Question: Which MPLS parameter is used for classification and marking? Answer: The MPLS experimental bits are used to classify and mark labeled packets. Question: What is the default value of the MPLS experimental bits? Answer: Cisco routers copy the IP precedence bits into MPLS experimental bits. Question: Which QoS mechanisms can be used to set MPLS experimental bits? Answer: CAR, Class-based Policing and Class-based Marking.
Cell-mode MPLS Question: How is differentiated QoS implemented on MPLS-enabled ATM interfaces? Answers: By using up to 4 VCs (labels) for each destination. Question: What information is used for classification in cell-mode MPLS? Answers: Classification is performed based on the two low-order IP precedence bits.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-47
Overview The module presents a thorough overview of quality of service models and mechanisms as implemented in complex service provider and enterprise networks. It includes the following topics: n
Introduction to IP Quality of Service
n
Integrated Services Model
n
Differentiated Services Model
n
Building Blocks of IP QoS Mechanisms
n
Enterprise Network Case Study
n
Service Provider Case Study
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe the need for IP QoS
n
Describe the Integrated Services model
n
Describe the Differentiated Services model
n
Describe the building blocks of IP QoS mechanisms (classification, marking, metering, policing, shaping, dropping, forwarding, queuing)
n
List the IP QoS mechanisms available in the Cisco IOS
n
Describe what QoS features are supported by different IP QoS mechanisms
Introduction to IP Quality of Service Objectives Upon completion of this lesson, you will be able to perform the following tasks:
2
IP QoS Introduction
n
Describe different types of applications and services that have special resource requirements
n
List the network components that affect the throughput, delay and jitter in IP networks
n
List the benefits of deploying QoS mechanisms in IP networks
n
List QoS mechanisms available in Cisco IOS
n
Describe typical enterprise and service provider networks and their QoS-related requirements
Copyright 2001, Cisco Systems, Inc.
Why IP QoS? • Application X is slow! • Video broadcast occasionally stalls! • Phone calls over IP are no better than over satellite! • Phone calls have really bad voice quality! • ATM (the money-dispensing-type) are nonresponsive! • ...
© 2001, Cisco Systems, Inc.
IP QoS Introduction-5
The purpose of this module is to determine the following: n
What is, or might be, missing in today’s IP networks?
n
What can IP Quality of Service (QoS) do to help solve the problem?
A decade ago when the Internet was still in its early stages there was not much available. Most users were using Gopher to find information and FTP to retrieve it. The Internet was something new and exciting and no one was really bothered by the fact that it was slow. Today, however, the Internet is serving a large population of all walks of life. The Internet has also grown in its service offering. Users are using the Internet to view static or dynamic information, transmit voice and video, shop, play etc. Along with these new applications of the Internet come some demands on the service(s) it provides: n
Some applications are slow
n
Video broadcast or conferencing may have bad picture quality or appear jerky
n
Voice sessions may have bad voice quality or periods of silence
n
Critical transactions may take too long (too many seconds)
n
Bulk transfers take too long (too many hours)
This module focuses on most common quality-related problems people encounter in IP networks.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
3
Because ... • Application X is slow! (not enough BANDWIDTH) • Video broadcast occasionally stalls! (DELAY temporarily increases – JITTER) • Phone calls over IP are no better than over satellite! (too much DELAY) • Phone calls have really bad voice quality! (too many phone calls – ADMISSION CONTROL) • ATM (the money-dispensing-type) are non responsive! (too many DROPs) • ...
© 2001, Cisco Systems, Inc.
IP QoS Introduction-6
Quality of Service is usually identified by the following parameters:
4
IP QoS Introduction
n
Amount of bandwidth available to a certain application or user
n
Average delay experienced by IP packets on end-to-end or link basis
n
Jitter that affects applications that transmit packets at a certain fixed rate and expect to receive them at approximately the same rate (for example, voice and video)
n
Drops of packets when a link is congested can severely impact fragile applications
n
Admission control which prevents too many sessions from congesting links and causing degradation in quality of service (for example, voice sessions)
Copyright 2001, Cisco Systems, Inc.
What Causes ... • Lack of bandwidth – multiple flows are contesting for a limited amount of bandwidth • Too much delay – packets have to traverse many network devices and links that add up to the overall delay • Variable delay – sometimes there is a lot of other traffic which results in more delay • Drops – packets have to be dropped when a link is congested
© 2001, Cisco Systems, Inc.
IP QoS Introduction-7
If the network is empty any application should get enough bandwidth, acceptable low and fixed delay and not experience any drops. The reality, however, is that there are multiple users or applications using the network at the same time.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
5
Available Bandwidth
IP
IP
256 kbps 10 Mbps
IP
IP
512 kbps 100 Mbps
BW max = min(10M, 256k, 512k, 100M)=256kbps BW avail = BWmax /Flows • Maximum available bandwidth equals the bandwidth of the weakest link • Multiple flows are contesting for the same bandwidth resulting in much less bandwidth being available to one single application. © 2001, Cisco Systems, Inc.
IP QoS Introduction-8
The example above illustrates an empty network with four hops between a server and a client. Each hop is using different media with a different bandwidth. The maximum available bandwidth is equal to the bandwidth of the slowest link. The calculation of the available bandwidth, however, is much more complex in cases where there are multiple flows traversing the network. The calculation of the available bandwidth in the illustration is a rough approximation.
6
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
End-to-end Delay
IP
IP
Propagation delay (P1) Processing and queuing delay (Q1)
Propagation delay (P2) Processing and queuing delay (Q2)
IP
IP
Propagation delay (P3)
Propagation delay (P4)
Processing and queuing delay (Q3)
Delay = P1 + Q1 + P2 + Q2 + P3 + Q3 + P4 = X ms
• End-to-end delay equals a sum of all propagation, processing and queuing delays in the path • Propagation delay is fixed, processing and queuing delays are unpredictable in best-effort networks © 2001, Cisco Systems, Inc.
IP QoS Introduction-9
The figure illustrates the impact a network has on the end-to-end delay of packets going from one end to the other. Each hop in the network adds to the overall delay because of the following two factors: 1. Propagation (serialization) delay of the media that, for the most part, depends solely on the bandwidth. 2. Processing and queuing delays within a router, which can be caused by a wide variety of conditions. Ping (ICMP echoes and replies) can be used to measure the round-trip time of IP packets in a network. There are other tools available to periodically measure responsiveness of a network.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
7
Processing and Queuing Delay
IP
IP
Processing Delay
IP
bandwidth
Forwarding
IP
Queuing Delay Propagation Delay
• Processing Delay is the time it takes for a router to take the packet from an input interface and put it into the output queue of the output interface. • Queuing Delay is the time a packets resides in the output queue of a router. • Propagation or Serialization Delay is the time it takes to transmit a packet.
© 2001, Cisco Systems, Inc.
n
8
IP QoS Introduction
IP QoS Introduction-10
Processing Delay is the time it takes for a router to take the packet from an input interface and put it into the output queue of the output interface. The processing delay depends on various factors, such as: –
CPU speed
–
CPU utilization
–
IP switching mode
–
Router architecture
–
Configured features on both input and output interface
n
Queuing Delay is the time a packet resides in the output queue of a router. It depends on the number and sizes of packets already in the queue and on the bandwidth of the interface. It also depends on the queuing mechanism.
n
Propagation or Serialization Delay is the time it takes to transmit a packet. It usually only depends on the bandwidth of the interface. CSMA/CD media may add slightly more delay due to the increased probability of collisions when an interface is nearing congestion.
Copyright 2001, Cisco Systems, Inc.
Packet Loss
Forwarding
IP
IP
IP
IP
IP
Tail-drop
• Tail-drops occur when the output queue is full. These are the most common drops which happen when a link is congested. • There are also many other types of drops that are not as common and may require a hardware upgrade (input drop, ignore, overrun, no buffer, ...). These drops are usually a result of router congestion. © 2001, Cisco Systems, Inc.
IP QoS Introduction-11
The usual packet loss occurs when routers run out of buffer space for a particular interface (output queue). The figure illustrates a full output queue of an interface, which causes newly arriving packets to be dropped. The term used for such drops is simply “output drop” or “tail-drop” (packets are dropped at the tail of the queue). Routers might also drop packets for other (less common) reasons, for example: n
Input queue drop - main CPU is congested and cannot process packets (the input queue is full)
n
Ignore - router ran out of buffer space
n
Overrun - CPU is congested and cannot assign a free buffer to the new packet
n
Frame errors (CRC, runt, giant)—hardware-detected error in a frame
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
9
How to Increase Available Bandwidth? TCP Header Compression RTP Header Compression cTCP data
Compress the Headers IP
TCP
Fancy FIFO queuing queuing
data Compress the Payload
Compressed packet
Stacker Predictor
Priority Queuing (PQ) Custom Queuing (CQ) Modified Deficit Round Robin (MDRR) Class-based Weighted Fair Queing (CB-WFQ)
• Upgrade the link. The best solution but also the most expensive. • Take some bandwidth from less important applications. • Compress the payload of layer-2 frames. • Compress the header of IP packets. © 2001, Cisco Systems, Inc.
IP QoS Introduction-12
There are several approaches to solving a problem of insufficient bandwidth:
10
IP QoS Introduction
n
The best approach is to increase the link capacity to accommodate all applications and users with some extra bandwidth to spare. This solution sounds simple enough but in the real world it brings a high cost in terms of the money and time it takes to implement. Very often there are also technological limitations to upgrading to a higher bandwidth.
n
Another option is to classify traffic into QoS classes and prioritize it according to importance (business-critical traffic should get enough bandwidth, voice should get enough bandwidth and prioritized forwarding and the least important traffic should get the remaining bandwidth). There are a wide variety of mechanisms available in the Cisco IOS that provide bandwidth guarantees, for example: –
Priority or Custom Queuing
–
Modified Deficit Round Robin (on Cisco 12000 series routers)
–
Distributed ToS-based and QoS-group-based Weighted Fair Queuing (on Cisco 7x00 series routers)
–
Class-based Weighted Fair Queuing
n
Optimizing link usage by compressing the payload of frames (virtually) increases the link bandwidth. Compression, on the other hand, also increases delay due to complexity of compression algorithms. Using hardware compression can accelerate the compression of packet payloads. Stacker and Predictor are two compression algorithms available in Cisco IOS.
n
Another link efficiency mechanism is header compression. This mechanism is especially effective in networks where most packets carry small amounts of
Copyright 2001, Cisco Systems, Inc.
data (payload-to-header ratio is small). Typical examples of header compression are TCP Header Compression and RTP Header Compression.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
11
How to Reduce Delay? TCP Header Compression RTP Header Compression cRTP data
Compress the Headers IP
UDP RTP
Fancy FIFO queuing queuing
data
Compress the Payload
Compressed packet
Stacker Predictor
Priority Queuing (PQ) Custom Queuing (CQ) Strict Priority MDRR IP RTP prioritization Class-based Low-latency Queuing (CB-LLQ)
• Upgrade the link. The best solution but also the most expensive. • Forward the important packets first. • Compress the payload of layer-2 frames (it takes time). • Compress the header of IP packets. © 2001, Cisco Systems, Inc.
IP QoS Introduction-13
Assuming that a router is powerful enough to make a forwarding decision in a negligible time it can be said that most of the processing, queuing delay and propagation delay is influenced by the following factors: n
Average length of the queue
n
Average length of packets in the queue
n
Link bandwidth
There are several approaches to accelerate packet dispatching of delay-sensitive flows:
12
IP QoS Introduction
n
Increase link capacity. Enough bandwidth causes queues to shrink, making sure packets do not have to wait long before they can be transmitted. Additionally, more bandwidth reduces serialization time. On the other hand, this might be an unrealistic approach due to the costs associated with the upgrade.
n
A more cost-effective approach is to enable a queuing mechanism that can give priority to delay-sensitive packets by forwarding them ahead of other packets. There are a wide variety of queuing mechanisms available in Cisco IOS that have pre-emptive queuing capabilities, for example: –
Priority Queuing
–
Custom Queuing
–
Strict-priority or Alternate Priority queuing within the Modified Deficit Round Robin (on Cisco 12000 series routers)
–
IP RTP prioritization
–
Class-based Low-latency Queuing
Copyright 2001, Cisco Systems, Inc.
n
Payload compression reduces the size of packets and, therefore, virtually increases link bandwidth. Additionally, compressed packets are smaller and need less time to be transmitted. On the other hand, compression uses complex algorithms that take time and add to the delay. This approach is, therefore, not used to provide low-delay propagation of packets.
n
Header compression on the other hand is not as CPU-intensive and can be used in combination with other mechanisms to reduce delay. It is especially useful for voice packets that have a bad payload-to-header ratio, which is improved by reducing the header of the packet (RTP header compression).
By minimizing delay, jitter is also reduced (delay is more predictable).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
13
How to Prevent Packet Loss?
Weighted Random Early Detection (WRED)
IP
data
Dropper
Fancy FIFO queuing queuing
Custom Queuing (CQ) Modified Deficit Round Robin (MDRR) Class -based Weighted Fair Queuing (CB-WFQ)
• Upgrade the link. The best solution but also the most expensive. • Guarantee enough bandwidth to sensitive packets. • Prevent congestion by randomly dropping less important packets before congestion occurs © 2001, Cisco Systems, Inc.
IP QoS Introduction-14
Packet loss is usually a result of congestion on an interface. Most applications that use TCP experience slow down due to TCP adjusting to the network’s resources (dropped TCP segments cause TCP sessions to reduce their window sizes). There are some other applications that do not use TCP and cannot handle drops (fragile flows). The following approaches can be taken to prevent drops of sensitive applications: n
Increased link capacity to ease or prevent congestion.
n
Guarantee enough bandwidth and increase buffer space to accommodate bursts of fragile applications. There are several mechanisms available in Cisco IOS that can guarantee bandwidth and/or provide prioritized forwarding to dropsensitive applications, for example:
n
–
Priority Queuing
–
Custom Queuing
–
Modified Deficit Round Robin (on Cisco 12000 series routers)
–
IP RTP prioritization
–
Class-based Weighted Fair Queuing
–
Class-based Low-latency Queuing
Prevent congestion by dropping other packets before congestion occurs. Weighted Random Early Detection can be used to start dropping other packets before congestion occurs.
There are some other mechanisms that can also be used to prevent congestion: n
14
IP QoS Introduction
Traffic Shaping delays packets instead of dropping them (Generic Traffic Shaping, Frame Relay Traffic Shaping and Class-based Shaping). Copyright 2001, Cisco Systems, Inc.
n
Traffic Policing can limit the rate of less important packets to provide better service to drop-sensitive packets (Committed Access Rate and Class-based Policing).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
15
Which Applications Have Which QoS Requirements? Throughput
Delay
Loss Loss
Jitter
Interactive (e.g. Telnet)
Low
Low
Low
Not Important
Batch (e.g. FTP)
High High
Not Important
Low
Not Important
Fragile (e.g. SNA)
Low
Low
None
Not Important
Voice
Low
Low and Predictable
Low
Low
Video
High High
Low and Predictable
Low
Low
• Enterprise networks are typically focused on providing QoS to applications © 2001, Cisco Systems, Inc.
IP QoS Introduction-15
When QoS is considered in a network implementation, important applications and their QoS requirements have to be identified. The figure illustrates a table of different types of applications with the corresponding QoS requirements (throughput or bandwidth, delay, loss and jitter). Once the applications are identified and prioritized it must be decided which QoS mechanisms are to be put in place. The approach to provide QoS to applications is usually used in Enterprise Networks where important (business-critical) applications are easy to identify. Most applications can be classified based on TCP or UDP port numbers. Some applications use dynamic port numbers that, somewhat, makes classification more difficult. Cisco IOS supports Network-based Application Recognition (NBAR), which can be used for such application.
16
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Which Services can be Implemented in a Network? Throughput
Delay
Loss Loss
Jitter
Gold
Guaranteed
Low
Low
Low
Silver Silver
Guaranteed
No Guarantee
No Guarantee
No Guarantee
Bronze
Guaranteed Limitted
No Guarantee
No Guarantee
No Guarantee
Best Effort
No Guarantee
No Guarantee
No Guarantee
No Guarantee
. . ..
. . ..
. . ..
. . ..
...
• Service provider networks typically offer services based on source and destination addresses © 2001, Cisco Systems, Inc.
IP QoS Introduction-16
Service providers, on the other hand, are there to provide connectivity to customers. They typically are not concerned with the applications that customers are using. They are, however, interested in providing different levels of services to customers. Some customers are willing to pay more for their connectivity to the Internet, providing they obtain some guarantees. The figure illustrates one of the many different approaches to defining services. In reality, each service provider creates its own list of services according to market research and competitive needs. Cisco IOS is simply the tool used to implement those services.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
17
How can QoS be Applied? • Best effort – no QoS is applied to packets (default behavior) • Integrated Services model – applications signal to the network that they require special QoS • Differentiated Services model – the network recognizes classes that requires special QoS
© 2001, Cisco Systems, Inc.
IP QoS Introduction-17
By investigating the history of the Internet it can be divided into three QoS-related periods: n
Best-effort. The Internet was designed for best-effort, no-guarantee delivery of packets. This behavior is still predominant in today’s Internet.
n
Integrated Services model. Introduced to supplement the best-effort delivery by setting aside some bandwidth for applications that require bandwidth and delay guarantees. The Integrated Services model expects applications to signal their requirements to the network. Resource Reservation Protocol (RSVP) is used to signal QoS requirements to the network.
n
Differentiated Services model. Added to provide more scalability in providing QoS to IP packets. The main difference is that the network recognizes packets (no signaling is needed) and provides the appropriate services to them.
Today’s IP networks can use all three models at the same time.
18
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Summary IP Quality of Service is used to improve performance of IP networks. Quality of Service can be measured based on available bandwidth, end-to-end delay, packet loss and jitter. Different QoS mechanisms can be used to provide a predictable service. There are many different types of QoS mechanisms available in the Cisco IOS: n
Queuing mechanisms: Priority Queuing (PQ), Custom Queuing (CQ), Weighted Fair Queuing (WFQ) with its distributed versions, IP RTP Prioritization, Modified Deficit Round Robin (MDRR), Class-based Weighted Fair Queuing (CB-WFQ) and Class-based Low-latency Queuing (CB-LLQ)
n
Traffic Shaping mechanisms: Generic Traffic Shaping (GTS), Frame Relay Traffic Shaping (FRTS) and Class-based Shaping
n
Traffic Policing mechanisms: Committed Access Rate (CAR) and Classbased Policing
n
Dropping mechanisms: Weighted Random Early Detection (WRED)
n
Link Efficiency mechanisms: Stacker, Predictor, TCP Header Compression and RTP Header Compression
n
Signaling mechanism: Resource Reservation Protocol (RSVP)
Review Questions Answer the following questions: n
What are the relevant parameters that define the quality of service?
n
What can be done to give more bandwidth to an application?
n
What can be done to reduce delay?
n
What can be done to prevent packet loss?
n
Name the three QoS models?
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
19
Integrated Services Model Objectives Upon completion of this lesson, you will be able to perform the following tasks:
20
IP QoS Introduction
n
Describe the IntServ model
n
List the key benefits and drawbacks of the IntServ model
n
List some implementations that are based on the IntServ model
n
Describe the need for Common Open Policy Service (COPS)
Copyright 2001, Cisco Systems, Inc.
Integrated Services • The Internet was initially based on a besteffort packet delivery service • Today's Internet carries many more different applications than 20 years ago • Some applications have special bandwidth and/or delay requirements • The Integrated Services model (RFC1633) was introduced to guarantee a predictable behavior of the network for these applications
© 2001, Cisco Systems, Inc.
IP QoS Introduction-22
The Internet Engineering Task Force (IETF) is responsible for standardization of the Internet and most of the protocols used in the Internet. When faced with a challenge, vendors introduce their own solutions. However, the IETF is there to create standards that allow different vendor’s equipment to interoperate. One of the challenges in the past was to introduce Quality of Service into the best-effort driven Internet. The Integrated Services (IntServ) model was proposed as standard with Resource Reservation Protocol (RSVP) as the mechanism used to signal QoS requirements to the network. The IntServ model is described in the RFC 1633 (http://www.ietf.org/rfc/rfc1633.txt). The use of RSVP for Integrated Services is described in RFC 2210 (http://www.ie tf.org/rfc/rfc2210.txt).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
21
IntServ Building Blocks Local Admission Control request
request
reserve
Policy Enforcement Point (PEP) request
reserve
Local Admission Control request
reserve
reply
request
reserve
Remote Admission Control
Policy Decision Point (PDP)
• Resource Reservation is used to identify an application (flow) and signal if there are enough available resources for it • Admission Control is used to determine if the application (flow) can get the requested resources © 2001, Cisco Systems, Inc.
IP QoS Introduction-23
The IntServ model itself describes the application of QoS in IP networks. Additional standards were developed to cover the exact protocols used to implement Quality of Service: n
Resource Reservation is implemented using the Resource Reservation Protocol (RSVP)
n
Admission Control is either implemented locally on the routers or offloaded to central servers
Common Open Policy Service (COPS) is another IETF standard that defines a protocol that can be used for policy exchange between network devices (Policy Enforcement Point or PEP) and policy servers (Policy Decision Point or PDP). An additional standard was added to integrate RSVP with COPS. The COPS (Common Open Policy Service) Protocol is defined in RFC 2748 (http://www.rfc-editor.org/rfc/rfc2748.txt). COPS usage for RSVP is defined in RFC 2749 (http://www.rfc-editor.org/rfc/rfc2749.txt).
22
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Reservation and Admission Protocols • The resource ReSerVation Protocol (RSVP) was developed to communicate resource needs between hosts and network devices (RFC 2205-2215) • Common Open Policy Service (COPS) was developed to offload admission control to a central policy server (RFC 2748-2753)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-24
Following is a list of some of the IETF standards (RFCs) that describe RSVP, COPS, the IntServ model and applications: n
Resource ReSerVation Protocol (RSVP), Version 1, Functional Specification (http://www.ietf.org/rfc/rfc2205.txt)
n
RSVP Management Information Base using SMIv2 (http://www.ietf.org/rfc/rfc2206.txt)
n
RSVP Extensions for IPSEC Data Flows (http://www.ietf.org/rfc/rfc2207.txt)
n
Resource ReSerVation Protocol (RSVP), Version 1, Applicability Statement, Some Guidelines on Deployment (http://www.ietf.org/rfc/rfc2208.txt)
n
Resource ReSerVation Protocol (RSVP), Version 1, Message Processing Rules (http://www.ietf.org/rfc/rfc2209.txt)
n
The Use of RSVP with IETF Integrated Services (http://www.ietf.org/rfc/rfc2210.txt)
n
Specification of the Controlled-Load Network Element Service (http://www.ietf.org/rfc/rfc2211.txt)
n
Specification of Guaranteed Quality of Service (http://www.ietf.org/rfc/rfc2212.txt)
n
Integrated Services Management Information Base using SMIv2 (http://www.ietf.org/rfc/rfc2213.txt)
n
Integrated Services Management Information Base, Guaranteed Service Extensions using SMIv2 (http://www.ietf.org/rfc/rfc2214.txt)
n
General Characterization Parameters for Integrated Service Network Elements (http://www.ietf.org/rfc/rfc2215.txt)
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
23
24
IP QoS Introduction
n
The COPS (Common Open Policy Service) Protocol (http://www.ietf.org/rfc/rfc2748.txt)
n
COPS usage for RSVP (http://www.ietf.org/rfc/rfc2749.txt)
n
RSVP Extensions for Policy Control (http://www.ietf.org/rfc/rfc2750.txt)
n
Signaled Preemption Priority Policy Element (http://www.ietf.org/rfc/rfc2751.txt)
n
Identity Representation for RSVP (http://www.ietf.org/rfc/rfc2752.txt)
n
A Framework for Policy-based Admission Control (http://www.ie tf.org/rfc/rfc2753.txt)
n
SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks (http://www.ietf.org/rfc/rfc2814.txt)
n
Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients (http://www.ietf.org/rfc/rfc2940.txt)
n
COPS Usage for Policy Provisioning (COPS-PR) (http://www.ietf.org/rfc/rfc3084.txt)
Copyright 2001, Cisco Systems, Inc.
RSVP-enabled Applications • RSVP is typically used by applications carrying voice or video over IP networks (initiated by a host) • RSVP with extensions is also used by MPLS Traffic Engineering to establish MPLS/TE tunnels (initiated by a router)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-25
RSVP, as a resource reservation protocol, was designed for use by end devices in networks (for example, personal computers and servers). It is a protocol that has to be supported by an application that requires network resources and needs guarantees. n
Typical examples of applications that would benefit from RSVP are voice sessions that require a small amount of bandwidth with low-delay propagation.
n
Cisco routers that act as voice gateways can use RSVP to request resources (controlled-load and guaranteed-delay).
n
Cisco routers that use Multiprotocol Label Switching (MPLS) Traffic Engineering (MPLS/TE) use RSVP with extensions to reserve bandwidth and set up MPLS/TE tunnels through MPLS and RSVP enabled networks.
n
Cisco Soft Phone or Microsoft NetMeeting are Windows applications that use RSVP to get resources for their VoIP sessions.
There are an increasing number of applications that use RSVP to request QoS guarantees from a network.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
25
IntServ Implementation Options RSVP
1) Explicit RSVP on each network node
Class of Service or Best Effort 2) RSVP ‘pass -through’ and CoS transport - map RSVP to CoS at network edge - pass -through RSVP request to egress 3) RSVP at network edges and ‘pass -through’ with - best-effort forwarding in the core (if there is enough bandwidth in the core)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-26
The figure illustrates three options available when implementing QoS mechanisms via RSVP in a network. 1. The first option is to simply enable RSVP on all interfaces of all the routers in the network. This approach is mainly used in enterprise networks that have more predictable RSVP flows (in terms of quantity and direction because they typically use hub-and-spoke topology). Large service provider networks are less inclined to use RSVP throughout their networks either because RSVP would require too many concurrent reservations on a single interface or because the routers are not capable of providing guarantees to individual flows on high-bandwidth interfaces. 2. An alternative option is to use RSVP on network edges where there is typically less bandwidth per interface and congestion is more likely. The edgeto-core routers (for example, access or distribution layer routers) mark RSVP flows with IP markers, which can then be used in a DiffServ enabled core— the Differentiated Services model is covered in the next lesson). 3. Another option is to use RSVP on network edges and rely on best-effort delivery in a non-congested core.
26
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Explicit RSVP Transport IntServ End-to-End RSVP
All Routers • WFQ applied per flow based on RSVP requests
© 2001, Cisco Systems, Inc.
IP QoS Introduction-27
In the first scenario, each router in the network processes RSVP messages and keeps track of the special resource needs for each individual RSVP flow. Weighted Fair Queuing (WFQ) can be used in the backbone to provide resource allocation on a flow-by-flow basis. One concern with this approach is that RSVP is resource intensive on backbone routers - in terms of the amount of signaling and the amount of special information that they need to keep on each RSVP flow. A second issue is that WFQ is a very CPU-intensive algorithm and does not run at high speed on today’s routers. In the backbone, high speed is a mandatory requirement.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
27
RSVP Pass-Through IntServ - DiffServ Integration RSVP
RSVP
Precedence Classifier
Premium Standard
WRED
• RSVP protocol sent on to destination • WFQ applied to manage egress flow
Ingress Router • RSVP protocol Mapped to classes Passed through to egress
Egress Router
Backbone • WRED applied based on class
© 2001, Cisco Systems, Inc.
IP QoS Introduction-28
An alternative to enabling RSVP end-to-end is to use RSVP as a means to signal special requirements between the customer and the ISP edge, but not to use it in the backbone. In this model, packets are mapped on RSVP flows into special service classes which give each class preferential treatment in the core of the network when congestion occurs. This avoids the scalability problem of end-to-end RSVP, since these flows are processed between the end station and the network edge and not in the middle of the backbone. By using WRED on routers, instead of WFQ, much higher speeds can be supported. Alternatively, Class-based WFQ can be used on moderate-speed links to provide better control of bandwidth allocation. The third option is not to use RSVP in the core and rely on best-effort delivery if the core is not congested. Lastly, mapping classes of service to ATM is more straightforward than mapping RSVP directly to ATM. This concept may accelerate the ability of ISPs to offer an RSVP service and enable new application areas.
28
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
IntServ Support in IOS • RSVP and Weighted Fair Queuing supported since ’95 • RSVP signaling for VoIP calls supported on all VoIP platforms • IOS supports hop-by-hop and pass-through RSVP • RSVP-to-DSCP (DiffServ Code Point) mapping (RSVP proxy) in 12.1T
© 2001, Cisco Systems, Inc.
IP QoS Introduction-29
Both RSVP and WFQ have been available for some time and can be used on all low-end platforms and on high-end platforms that are typically used to concentrate customer networks. Newer RSVP mechanisms include: n
Mapping of RSVP to DSCP (the Differentiated Services model with the details of the DiffServ Code point is covered in the next lesson).
n
Mapping of RSVP to ATM SVCs (this technology is covered in the “IP QoS IP over ATM” module).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
29
Benefits and Drawbacks of the IntServ Model + RSVP benefits: • Explicit resource admission control (end to end) • Per-request policy admission control (authorization object, policy object) • Signaling of dynamic port numbers (for example, H.323)
–RSVP drawbacks: • Continuous signaling due to stateless architecture • Not scalable
© 2001, Cisco Systems, Inc.
IP QoS Introduction-30
The main benefits of RSVP are: n
It signals QoS requests per individual flow. The network can then provide guarantees to these individual flows. The problem of this is that it does not scale to large networks because of the large numbers of concurrent RSVP flows.
n
It informs network devices of flow parameters (IP addresses and port numbers). Some applications use dynamic port numbers, which can be difficult for network devices to recognize. NBAR is a mechanism that has been introduced to supplement RSVP for applications that use dynamic port numbers but do not use RSVP.
It supports admission control that allows a network to reject (or down-grade) new RSVP sessions if one of the interfaces in the path has reached the limit (all reservable bandwidth is booked). The main drawbacks of RSVP are:
30
IP QoS Introduction
n
Continuous signaling due to stateless operation of RSVP.
n
RSVP is not scalable to large networks where per-flow guarantees would have to be made to thousands of flows.
Copyright 2001, Cisco Systems, Inc.
Common Open Policy Service • Common Open Policy Service (COPS) provides the following benefits when used with RSVP: – Centralized management of services – Centralized admission control and authorization of RSVP flows
• RSVP-based QoS solutions become more scalable
© 2001, Cisco Systems, Inc.
IP QoS Introduction-31
The Common Open Policy Service (COPS) is an add-on to RSVP. It can be used to offload certain tasks from network devices to a central server. The result is that the configuration of individual devices is more standardized (template-based) and all individual parameters are managed from a centralized location. In addition, COPS supports admission control of individual flows (the network device determines the available resources and the central server authorizes the flow).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
31
Summary The Integrated Services (IntServ) model was introduced to allow vendors of routers to add interoperable QoS mechanisms to their best-effort packet forwarding. Resource Reservation Protocol (RSVP) is used by end-devices to signal QoS requirements to the network. Common Open Policy Service (COPS) is used to offload policy management to central servers.
Review Questions Answer the following questions:
32
IP QoS Introduction
n
What are the two building blocks of the Integrated Services model?
n
Which protocol is used to signal QoS requirements to the network?
Copyright 2001, Cisco Systems, Inc.
Differentiated Services Model Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe the DiffServ model
n
List the key benefits of the DiffServ model compared to the IntServ model
n
Describe the purpose of the DS field in IP headers
n
Describe the interoperability between DSCP-based and IP-precedence-based devices in a network
n
Describe the Expedited Forwarding service
n
Describe the Assured Forwarding service
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
33
Differentiated Services Model • Differentiated Services model describes services associated with traffic classes • Complex traffic classification and conditioning is performed at network edge resulting in a per-packet Differentiated Services Code Point (DSCP). • No per-flow/per-application state in the core • Core only performs simple ‘per-hop behavior's’ on traffic aggregates • Goal is Scalability © 2001, Cisco Systems, Inc.
IP QoS Introduction-36
The Differentiated Services (DiffServ) model describes services associated with traffic classes. Traffic classes are identified by the value of the DiffServ Code Point (DSCP replaces IP precedence in the ToS field of the IP header). The main goals of the DiffServ model are to provide scalability and a similar level of QoS to the IntServ model, without having to do it on a per-flow basis. The network simply identifies a class (not application) and applies the appropriate perhop behavior (QoS mechanism). The DiffServ model and associated standards are described in the following IETF standardization documents (RFCs):
34
IP QoS Introduction
n
An Architecture for Differentiated Services (http://www.ietf.org/rfc/rfc2475.txt)
n
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (http://www.ietf.org/rfc/rfc2474.txt)
n
Assured Forwarding per-hop behavior (PHB) Group (http://www.ietf.org/rfc/rfc2597.txt)
n
An Expedited Forwarding per-hop behavior (PHB) (http://www.ietf.org/rfc/rfc2598.txt)
Copyright 2001, Cisco Systems, Inc.
Additional Requirements • Wide variety of services and provisioning policies • Decouple service and application in use • No application modification • No hop-by-hop signaling • Interoperability with non-DS-compliant nodes • Incremental deployment
© 2001, Cisco Systems, Inc.
IP QoS Introduction-37
The DiffServ model describes services and allows for more user-defined services to be used in a DiffServ-enabled network. Services are provided to classes. A class can be identified as a single application or, as in most cases, it can be identified based on source or destination IP address. The idea is for the network to recognize a class without having to receive any request from applications. This allows the QoS mechanisms to be applied to other applications that do not have the RSVP functionality, which is the case for 99% of applications that use IP. The introduction of the DiffServ Code Point (DSCP) replaces the IP precedence but maintains interoperability with non-DS compliant devices (those that still use IP precedence). Because of this backward-compatibility DiffServ can be gradually deployed in large networks.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
35
DiffServ Elements • The service defines QoS requirements and guarantees provided to a traffic aggregate; • The conditioning functions and per-hop behaviors are used to realize services; • The DS field value (DS code point) is used to mark packets to select a per-hop behavior • Per-hop Behavior (PHB) is realized using a particular QoS mechanism • Provisioning is used to allocate resources to traffic classes
© 2001, Cisco Systems, Inc.
IP QoS Introduction-38
A traffic aggregate is a collection of all flows that require the same service. A service is implemented using different QoS mechanisms (a QoS mechanism implements a per-hop behavior). The DiffServ field (DS fie ld) is the former 8-bit Type of Service field. The main difference is that the DSCP supports more classes (64) than IP precedence (8). The most important part of designing QoS is to provision services as explained on the next page.
36
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Why is Provisioning Important? • QoS does not create bandwidth! • QoS manages bandwidth usage among multiple classes • QoS gives better service to a wellprovisioned class with respect to another class
© 2001, Cisco Systems, Inc.
IP QoS Introduction-39
Provisioning requires a thorough network analysis to determine parameters for services that are being deployed in the network. The result of provisioning is the allocation of bandwidth among all classes in times of congestion. Services are implemented by defining per-hop behavior (PHB) properties. PHBs are implemented by using the available QoS mechanisms in networks devices.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
37
Topological Terminology DS interior node
DS Egress Boundary node
DS Ingress Boundary node
Boundary link
Upstream DS domain
Downstream DS domain DS region
Traffic Stream = set of flows Behaviour Aggregate (flows with the same DSCP)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-40
A DS domain consists of DS boundary nodes and DS interior nodes. DS boundary nodes interconnect the DS domain to other DS or non-DS-capable domains. While DS interior nodes only connect to other DS interior or boundary nodes within the same DS domain. Both DS boundary nodes and interior nodes must be able to apply the appropriate PHB to packets based on the DS code point; otherwise unpredictable behaviour may result. DS boundary nodes act both as a DS ingress node and as a DS egress node for traffic traversing the network in different directions. Traffic enters a DS domain at a DS ingress node and leaves a DS domain at a DS egress node. A DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms to any Traffic Conditioning Agreement (TCA) between it and the other domain to which the ingress node is connected. A DS egress node may perform traffic conditioning functions on traffic forwarded to a directly connected peering domain, depending on the details of the TCA between the two domains. A differentiated services region (DS Region) is a set of one or more contiguous DS domains. DS regions are capable of supporting differentiated services along paths that span the domains within the region. The DS domains in a DS region may support different PHB groups internally and different code point-PHB mappings. However, to permit services that span across the domains, the peering DS domains must each establish a peering Service Level Agreement (SLA) that defines (either explicitly or implicitly) a TCA. The TCA specifies how transit traffic from one DS domain to another is conditioned at the boundary between the two DS domains. It is possible that several DS domains within a DS region may adopt a common service provisioning policy and may support a common set of PHB groups and
38
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
code point mappings. This eliminates the need for traffic conditioning between those DS domains.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
39
Traffic Terminology • Flow: a single instance of an application-toapplication flow of packets which is identified by source address, source port, destination address, destination port and protocol id. • Traffic stream: an administratively significant set of one or more flows which traverse a path segment. A traffic stream may consist of a set of active flows which are selected by a particular classifier. • Traffic profile: a description of the temporal properties of a traffic stream such as average and peak rate and burst size.
© 2001, Cisco Systems, Inc.
IP QoS Introduction-41
The terminology used throughout the course includes the following:
40
IP QoS Introduction
n
Flow (or microflow) is a sequence of packets identified by source and destination IP addresses, protocol identifier (for example, TCP and UDP) and source and destination port numbers.
n
Traffic stream is a collection of flows with a common set of parameters (for example, the same port number and the same source and destination network).
n
Traffic profile specifies typical properties of a traffic stream (average rate and burstiness). Provisioning should be performed based on traffic profiles and the importance of traffic streams.
Copyright 2001, Cisco Systems, Inc.
Traffic Terminology • Behavior Aggregate (BA) is a collection of packets with the same DS code point crossing a link in a particular direction. • Per-Hop Behavior (queuing in a node) externally observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate. • PHB Mechanism: a specific algorithm or operation (e.g., queuing discipline) that is implemented in a node to realize a set of one or more per-hop behaviors. © 2001, Cisco Systems, Inc.
IP QoS Introduction-42
Other important terms used throughout the course are: n
Behavior Aggregate (BA) identifies packets marked with the same DSCP
n
Per-hop Behavior (PHB) is applied to each BA according to the QoS policy
n
PHB mechanism is the actual QoS mechanism that satisfies PHB specification
Other terms can be found in RFC 2475, which defines the Differentiated Services model (http://www.ie tf.org/rfc/rfc2475.txt).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
41
Packet Header Terminology
DSCP field: 6bits
Unused: 2bits
Former ToS byte = new DS field
• DS code point: a specific value of the DSCP portion of the DS field, used to select a PHB (Per-Hop Behavior; forwarding and queuing method) • DS field: the IPv4 header ToS octet or the IPv6 Traffic Class octet when interpreted in conformance with the definition given in RFC2474. The bits of the DSCP field encode the DS code point, while the remaining bits are currently unused. © 2001, Cisco Systems, Inc.
IP QoS Introduction-43
The DiffServ model uses the DS field in the IP header to mark packets according to their classification into Behavior Aggregates (BAs). The DS field occupies the same eight bits of the IP header that were previously used for the Type of Service (ToS) field. There are three IETF standards describing the purpose of those eight bits: n
RFC 791 includes specification of the ToS field where the high-order three bits are used for IP precedence. The other bits are used for delay, throughput, reliability and cost.
n
RFC 1812 modifies the meaning of the ToS field by removing any meaning from the five low-order bits (those bits should all be zero).
n
RFC 2474 replaces the ToS field with the DS field where the six high-order bits are used for the DiffServ Code Point (DSCP). The remaining two bits are currently not used.
Each DSCP value identifies a Behavior Aggregate (BA). Each BA is assigned a per-hop behavior (PHB). Each PHB is implemented using the appropriate QoS mechanism or a set of QoS mechanisms.
42
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
DSCP Encoding • Three pools: – “xxxxx0”
Standard Action
– “xxxx11”
Experimental/Local Use
– “xxxx01”
EXP/LU (possible std action)
• Default DSCP: “000000” • Default PHB: FIFO, tail-drop
© 2001, Cisco Systems, Inc.
IP QoS Introduction-44
Unlike IP precedence, which lacked any standard definitions of values and corresponding PHBs, the DSCP has half of its value range reserved for standard defined PHBs. The low-order bit of the DSCP identifies whether the DSCP value identifies a standard action (PHB) or a user-defined action. The second bit could, potentially, (in the future) also be used to identify additional standard actions. The default value of DSCP is 0. The associated PHB is FIFO service with a tail-drop. FIFO queuing is discussed in the “IP QoS – Queuing mechanisms module”. The default DSCP value seamlessly maps to the default IP precedence value, which is also 0 according to RFC 1812.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
43
DSCP Usage DS Code point selects per-hop behavior (PHB) throughout the network • Default PHB • Class Selector (IP precedence) PHB • Expedited Forwarding (EF) PHB • Assured Forwarding (AF) PHB
© 2001, Cisco Systems, Inc.
IP QoS Introduction-45
The following per-hop behaviors are defined by IETF standards: n
Default PHB – used for best-effort service
n
Class Selector PHB – used for backward compatibility with non-DS compliant devices (RFC 1812 compliant devices and, optionally, RFC 791 compliant devices)
n
Expedited Forwarding PHB – used for low-delay service
n
Assured Forwarding PHB – used for guaranteed bandwidth service
The Default PHB and the Class Selector PHB are described in RFC 2474 (http://www.ietf.org/rfc/rfc2474.txt), Expedited Forwarding PHB is described in RFC 2598 (http://www.ietf.org/rfc/rfc2598.txt) and Assured Forwarding in RFC 2597 (http://www.ietf.org/rfc/rfc2597.txt).
44
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Backward Compatibility Using the Class Selector • Non-DS compliant node: node that does not interpret the DSCP correctly or that does not support all the standardized PHB’s • Legacy node: a non-DS compliant node that interprets IPv4 ToS such as defined by RFC791 and RFC1812. • DSCP is backward compatible with IP Precedence (Class Selector Code point, RFC 1812) but not with the ToS byte definition from RFC 791 (“DTR” bits)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-46
The history of the eight bits in question (ToS field alias DS field) can be divided into three periods according to the RFCs describing the purpose of those bits: RFC 791 RFC 791 defines the Type of Service field with the following components: n
Bits seven, six and five are used for IP precedence
n
Bit four is used for delay (0 = Normal Delay, 1 = Low Delay)
n
Bit three is used for throughput (0 = Normal Throughput, 1 = High Throughput)
n
Bit two is used for reliability (0 = Normal Reliability, 1 = High Reliability)
n
Bits one and zero are not used and should be zero (bit one was later applied a meaning of monetary-cost by RFC 1349; this RFC also replaces individual bits with a four-bit ToS value to allow more types of services)
RFC 1812 RFC 1812 loosens the strict representation of the ToS field (obsole tes RFC 795). RFC 2474 RFC 2474 replaces the ToS field with the DS field where a range of eight values (Class Selector) is used for backward compatibility with IP precedence. There is no compatibility with the delay, throughput, reliability and monetary-cost bits.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
45
Class Selector Code Point • Compatibility with current IP precedence usage (RFC 1812) • “xxx000” DS code points • Differentiates probability of timely forwarding (PTF) – PTF (xyz000) >= PTF(abc000) if xyz > abc
© 2001, Cisco Systems, Inc.
IP QoS Introduction-47
RFC 1812 simply prioritizes packets according to the precedence value. The PHB is defined as the probability of timely forwarding. Packets with higher IP precedence should (on the average) be forwarded in less time than packets with lower IP precedence. RFC 2474 adopts this set of PHBs and values by creating the Class Selector PHB group. Class Selector can be identified by the low-order three bits of the DSCP or low-order five bits of the DS field: all bits are zero.
46
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Expedited Forwarding • Expedited Forwarding (EF) PHB: – Ensures a minimum departure rate – Guarantees bandwidth – the class is guaranteed an amount of bandwidth with prioritized forwarding – Polices bandwidth – the class is not allowed to exceed the guaranteed amount (excess traffic is dropped) • DSCP value: “101110”; looks like IP precedence 5 to non-DS compliant devices
© 2001, Cisco Systems, Inc.
IP QoS Introduction-48
The Expedited Forwarding PHB is identified based on the following parameters: n
Ensures a minimum departure rate to provide the lowest possible delay to delay-sensitive applications
n
Guarantees bandwidth to prevent starvation of the application if there are multiple applications using Expedited Forwarding PHB
n
Polices bandwidth to prevent starvation of other applications or classes that are not using this PHB
n
Packets requiring Expedited Forwarding should be marked with DSCP binary value “101110” (46 or 0x2E)
Non-DS compliant devices will regard EF DSCP value as IP precedence 5 (101), which is the highest user-definable IP precedence and is typically used for delay-sensitive traffic such as Voice over IP.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
47
IOS EF PHB Implementations • Priority Queuing • IP RTP Prioritization • Class-based Low-latency Queuing (CB-LLQ) • Strict Priority queuing within Modified Deficit Round Robin (MDRR) on GSR
© 2001, Cisco Systems, Inc.
IP QoS Introduction-49
Expedited Forwarding PHB can be implemented on Cisco routers using several different QoS mechanisms:
48
IP QoS Introduction
n
Routers running older Cisco IOS versions can use Priority Queuing (PQ) and put delay-sensitive traffic into a “high” priority queue. Priority Queuing, however, does not fully comply with the specification of the EF PHB – it does not have the capability to police the bandwidth used by the EF class.
n
IP RTP Prioritization can be used in combination with Weighted Fair Queuing (WFQ) or Class-based Weighted Fair Queuing (CB-WFQ). IP RTP Prioritization provides expedited forwarding with bandwidth guarantee and bandwidth policing.
n
Class-based Low-latency Queuing (CB-LLQ) is a mechanism similar to IP RTP Prioritization. It is the preferred mechanism for implementing EF PHB.
n
Strict Priority within Modified Deficit Round Robin (MDRR) on the Cisco 12000 series routers provides low-latency queuing but does not police bandwidth. Alternate Priority MDRR prevents starvation of other classes but it does not police bandwidth of the EF class.
Copyright 2001, Cisco Systems, Inc.
Assured Forwarding • Assured Forwarding (AF) PHB: –Guarantees bandwidth –Allows access to extra bandwidth if available • Four standard classes (af1, af2, af3 and af4) • DSCP value range: “aaadd0” where “aaa” is a binary value of the class and “dd” is drop probability
© 2001, Cisco Systems, Inc.
IP QoS Introduction-50
The Assured Forwarding PHB is identified based on the following parameters: n
Guarantees a certain amount of bandwidth to an AF class
n
Allows access to extra bandwidth, if available
n
Packets requiring AF PHB should be marked with DSCP value “aaadd0” where “aaa” is the number of the class and “dd” is the drop probability
There are four standard-defined AF classes. Each class should be treated independently and have bandwidth allocated based on the QoS policy.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
49
AF Encoding Class AF1 AF2 AF3 AF4
Value 001dd0 010dd0 011dd0 100dd0
Drop
Value
Probability (dd) Low
01
Medium
10
High
11
• Each AF class uses three DSCP values • Each AF class is independently forwarded with its guaranteed bandwidth • Differentiated RED is used within each class to prevent congestion within the class © 2001, Cisco Systems, Inc.
IP QoS Introduction-51
As the figure illustrates there are three DSCP values assigned to each of the four AF classes. Assured Forwarding class AF class 1
AF class 2
AF class 3
AF class 4
50
IP QoS Introduction
Drop Probability Low Medium High Low Medium High Low Medium High Low Medium High
DSCP value 001 01 0 001 10 0 001 11 0 010 01 0 010 10 0 010 11 0 011 01 0 011 10 0 011 11 0 100 01 0 100 10 0 100 11 0
Copyright 2001, Cisco Systems, Inc.
AF PHB Definition • A DS node MUST allocate a configurable, minimum amount of forwarding resources (buffer space and bandwidth) per AF class • Excess resources may be allocated between non-idle classes. The manner must be specified. • Reordering of IP packets of the same flow is not allowed if they belong to the same AF class
© 2001, Cisco Systems, Inc.
IP QoS Introduction-52
An AF implementation must attempt to minimize long-term congestion within each class, while allowing short-term congestion resulting from bursts. This requires an active queue management algorithm. An example of such an algorithm is Weighted Random Early Detection (WRED). The AF specification does not define the use of a particular algorithm, but does require that several properties hold. An AF implementation must detect and respond to long-term congestion within each cla ss by dropping packets, while handling short-term congestion (packet bursts) by queuing packets. This implies the presence of a smoothing or filtering function that monitors the instantaneous congestion level and computes a smoothed congestion level. The dropping algorithm uses this smoothed congestion level to determine when packets should be discarded. The dropping algorithm must treat all packets within a single class and precedence level identically. This implies that, for any given smoothed congestion level, the discard rate of a particular microflow's packets within a single precedence level will be proportional to that flow's percentage of the total amount of traffic passing through that precedence level. The congestion indication feedback to the end nodes, and thus the level of packet discard at each drop precedence in relation to congestion, must be gradual rather than abrupt. This allows the overall system to reach a stable operating point. WRED uses two (configurable) smoothed congestion level thresholds. When the smoothed congestion level is below the first threshold, no packets of the relevant drop precedence are discarded. When the smoothed congestion level is between the first and the second threshold, packets are discarded with linearly increasing probability, ranging from zero to a configurable value reached just prior to the second threshold. When the smoothed congestion level is above the second
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
51
threshold, packets of the relevant drop precedence are discarded with 100% probability. To allow the AF PHB to be used in many different operating environments, the dropping algorithm control parameters must be independently configurable for each packet drop precedence and for each AF class. Within the limits above, this specification allows for a range of packet discard behaviours.
52
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
AF PHB Implementation • CBWFQ (4 classes) with WRED within each class • (M)DRR with WRED within each class • Optionally Custom Queuing (does not support differentiated dropping)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-53
As with Expedited Forwarding there are multiple QoS mechanisms in the Cisco IOS that can accommodate some or all of the requirements of Assured Forwarding PHB: n
The preferred implementation is to use the Class-based Weighted Fair Queuing (CB-WFQ) with four classes (four independent queues) and Weighted Random Early Detection (WRED) within each queue.
n
A similar solution can be provided on the Cisco 12000 series routers by using the Modified Deficit Round Robin (MDRR) queuing with WRED in each queue. The AF PHB can also be implemented using the old-fashioned IP precedence. The only restriction is the number of available IP precedence values.
n
Example 1:
n
n
Four classes but no differentiated dropping:
n
AF1—IP precedence 1
n
AF2—IP precedence 2
n
AF3—IP precedence 3
n
AF4—IP precedence 4
Example 2: n
Two classes with differentiated dropping (two drop precedence values):
n
AF1—IP precedence 1 for high-drop, IP precedence 2 for low-drop
n
AF1—IP precedence 3 for high-drop, IP precedence 4 for low-drop
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
53
54
IP QoS Introduction
n
In both examples IP precedence 0 can be used for a best-effort class and IP precedence 5 for an EF class.
n
A similar solution as shown in Example 1 is also possible with Custom Queuing, except it has no support for differentiated dropping and DSCP. A workaround is possible if access-lists are used to match the DSCP value (direct matching of DSCP available only in IOS 12.1 and above) with a combination of IP precedence and ToS value.
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Describe the DiffServ model
n
List the key benefits of the DiffServ model compared to the IntServ model
n
Describe the purpose of the DS field in IP headers
n
Describe the interoperability between DSCP-based and IP-precedence-based devices in a network
n
Describe the Expedited Forwarding service
n
Describe the Assured Forwarding service
Review Questions Answer the following questions: n
What are the benefits of the DiffServ model compared to the IntServ model?
n
What is a DiffServ Code Point?
n
Name the standard PHBs?
n
How was backward compatibility with IP precedence achieved?
n
Describe the PHB of Assured Forwarding.
n
Describe the PHB of Expedited Forwarding.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
55
Building Blocks of IP QoS Mechanisms Objectives Upon completion of this lesson, you will be able to perform the following tasks:
56
IP QoS Introduction
n
Describe different classification options in IP networks
n
Describe different marking options in IP networks
n
List the mechanisms that are capable of measuring the rate of traffic
n
List the mechanisms that are used for traffic conditioning, shaping and avoiding congestion
n
List the forwarding mechanisms available in Cisco IOS
n
List the queuing mechanisms available in Cisco IOS
Copyright 2001, Cisco Systems, Inc.
Router Functions Defragmentation Decompression (payload, header) Source -based qos-label/precedence setting Destination-based qos-label/precedence setting Rate -limiting Class -based marking Policy-based-routing ...
Input I/O
Input Processing
Rate -limiting Random dropping Shaping Compression (payload, header) Fragmentation Queuing and scheduling ...
Forwarding
Output Processing
Output I/O
Process switching Fast/optimum switching Netflow switching CEF switching
• Depending on the configuration, a router may perform a number of actions prior to forwarding a packet (input processing) • Depending on the configuration, a router may perform a number of actions prior to enqueuing a packet in the hardware queue (output processing) © 2001, Cisco Systems, Inc.
IP QoS Introduction-58
Basic router function takes packets received on the input interface, makes a forwarding decision and transmits the packet out through the output interface. Today’s routers, however, can do much more than that. The figure lists a small subset of features that affect packet processing on input or output interfaces. Following is a list of some of the features available with Cisco routers: n
Payload compression (Stacker, Predictor)
n
Header compression (TCP and RTP header compression)
n
BGP-policy marking (CEF-based marking or QoS Policy propagation through BGP)
n
Traffic Policing (CAR, CB Policing)
n
Traffic Shaping (GTS, FRTS, CB-Shaping)
n
Class-based marking
n
Encryption (CET or IPsec)
n
WRED
n
Policy-based Routing
n
Accounting (IP accounting, NetFlow accounting)
n
Filtering (access lists)
n
Reverse-path checking
n
Address and port translation (NAT, PAT)
n
Stateful filtering (firewalling)
n
Web-cache redirection
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
57
58
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
IP QoS Actions • Classification – Each class-oriented QoS mechanism has to support some type of classification (access lists, route maps, class maps, etc.) • Metering – Some mechanisms measure the rate of traffic to enforce a certain policy (e.g. rate limiting, shaping, scheduling, etc.) • Dropping – Some mechanisms are used to drop packets (e.g. random early detection) • Policing – Some mechanisms are used to enforce a rate limit based on the metering (excess traffic is dropped) • Shaping – Some mechanisms are used to enforce a rate limit based on the metering (excess traffic is delayed) © 2001, Cisco Systems, Inc.
IP QoS Introduction-59
IP QoS mechanisms can perform different types of actions. All QoS mechanisms can be divided into the following QoS actions: n
Classification – most QoS mechanisms support multiple classes. There are different classification tools available with different QoS mechanisms (for example, access lists, route maps, class maps and rate-limit access lists). Some QoS mechanisms have the capability to match directly on certain parameters. For example: –
CAR (QoS group and DSCP)
–
WRED (IP precedence)
–
ToS-based dWFQ (IP precedence)
–
QoS-group-based dWFQ (QoS group)
–
WFQ (flow parameters)
–
PQ and CQ (interface, packet size and protocol)
n
Some mechanisms require the information about traffic rate of classes (for example, CAR, GTS, FRTS, CB-Shaping, CB-Policing, CB-WFQ, CB-LLQ, MDRR and IP RTP Prioritization).
n
Some mechanisms are used for dropping purposes. They utilize a dropping scheme different from the usual tail-drop. WRED is an example of such mechanism.
n
Some mechanisms are used to limit traffic rate by dropping excess traffic (CAR and CB-Policing).
n
Some mechanisms are used to limit traffic rate by delaying excess traffic (GTS, FRTS and CB-Shaping).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
59
60
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
IP QoS Actions • Marking – Some mechanisms have the capability to mark packets based on classification and/or metering (e.g. CAR, class-based marking, etc.) • Queuing – Each interface has to have a queuing mechanism • Forwarding – There are several supported forwarding mechanisms (process switching, fast switching, CEF switching, etc.)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-60
n
Some mechanisms have the capability to mark packets with different types of markers (IP precedence, DSCP, QoS group, MPLS experimental bits, ATM CLP bit, Frame Relay DE bit and 802.1q or ISL priority/cos bits)
n
Some mechanisms are used for queuing on output interfaces (for example, FIFO, PQ, CQ, WFQ, dWFQ, ToS-based dWFQ, QoS-group-based dWFQ, CB-WFQ, IP RTP Prioritization and MDRR)
n
Cisco IOS also has different types of forwarding mechanisms (Process Switching, Fast Switching, Optimum Switching, Silicon Switching, Autonomous Switching, NetFlow Switching, Cisco Express Forwarding and Policy-based routing)
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
61
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Queuing
Shaping Dropping
Scheduling Dropping
• Most traditional QoS mechanisms include extensive built-in classifiers – – – – –
Committed Access Rate (CAR) QoS Policy Propagation via BGP (QPPB) Route-maps Queuing mechanisms ...
• Modular QoS CLI (first implemented in 12.0(5)T) separates classifier from other actions – Includes all traditional classifiers + Network Based Application Recognition (NBAR) © 2001, Cisco Systems, Inc.
IP QoS Introduction-61
Most QoS mechanisms include several different classification options. The following table lists some QoS mechanisms with the corresponding classification options. QoS Mechanism
Classification options
Committed Access Rate (CAR)
Access list Rate limit access list QoS-group DSCP
QoS Policy Propagation through BGP (QPPB)
Route map
Policy-based routing
Route map
Generic Traffic Shaping
Access list
Priority Queuing and Custom Queuing
Access list Packet size Input interface Protocol
All mechanisms available using the Class map which can use: another class modular QoS CLI (CB-WFQ, CB-LLQ, map, access list, protocol (including CB-Shaping, CB-Policing, CB-Marking) NBAR), input interface, source or destination MAC address, IP precedence, DSCP, QoS group, MPLS experimental bits, etc.)
62
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Queuing
Shaping Dropping
Scheduling Dropping
• Token Bucket model is used for metering – – – – – – – –
Committed Access Rate (CAR) Generic Traffic Shaping (GTS) Frame Relay Traffic Shaping (FRTS) Class-based Weighted Fair Queuing (CB-WFQ) Class-based Low Latency Queuing (CB-LLQ) Class-based Policing Class-based Shaping IP RTP Prioritization
© 2001, Cisco Systems, Inc.
IP QoS Introduction-62
The figure lists QoS mechanisms in the Cisco IOS that have the capability to measure the rate of traffic by using the Token Bucket model.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
63
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
• Marker is used to set: – – – – – – –
IP precedence DSCP QoS group MPLS experimental bits Frame Relay DE bit ATM CLP bit IEEE 802.1Q or ISL CoS
Conditioner
Queuing
Shaping Dropping
Scheduling Dropping
• Marking mechanisms: – Comitted Access Rate (CAR) – QoS Policy Propagation through BGP (QPPB) – Policy-based Routing (PBR) – Class-based Marking
© 2001, Cisco Systems, Inc.
IP QoS Introduction-63
The figure lists markers that can be set using Cisco routers and the queuing mechanisms that have marking capabilities. The following table lists all the mechanisms that have marking capabilities and the markers that are supported by those mechanisms.
64
IP QoS Introduction
QoS Mechanism
Available markers
Committed Access Rate (CAR)
IP precedence DSCP QoS group MPLS experimental bits
QoS Policy Propagation through BGP (QPPB)
IP precedence QoS group
Policy-based Routing (PBR)
IP precedence QoS group
Class-based Marking
IP precedence DSCP QoS group MPLS experimental bits ATM CLP bit Frame Relay DE bit 802.1Q/ISL cos/priority
Copyright 2001, Cisco Systems, Inc.
Comparison of Markers Marker Marker
Preservation
Value range
IP precedence
Throught a network
8 values, 2 reserved (0 to 7)
DSCP
Throught a network
64 values, 32 are standard (0 to 63)
QoS group group
Local to a router
100 values (0 to 99)
MPLS experimental experimental bits bits
Throughout an MPLS network (optionally throughout throughout an entire IP network)
8 values
Frame Relay DE bit
Throughout a Frame Relay network
2 values (0 or 1)
ATM CLP bit
Throughout an ATM network
2 values (0 or 1)
IEEE 802.1Q or or ISL ISL CoS CoS
Throughout a LAN switched network
8 values (0 to 7)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-64
The figure describes the differences between markers in terms of preservation of the marker and a value range. Markers can: n
Be local to the router (the QoS group is not part of a packet or frame; it is a piece of information attached to a packet while it is stored in the router’s memory)
n
Have a limited range due to layer-2 technology that they use (ATM CLP, FR DE, 802.1q/ISL cos/priority, MPLS exp bits)
n
Have an unlimited range (IP precedence, DSCP)
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
65
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Queuing
Shaping Dropping
Scheduling Dropping
• Shaping mechanisms: – Generic Traffic Shaping (GTS) – Frame Relay Traffic Shaping (FRTS) – Class-based Shaping – Hardware shaping on ATM VC
© 2001, Cisco Systems, Inc.
IP QoS Introduction-65
The figure lists four mechanisms that are used for traffic shaping purposes. All of these mechanisms are implemented in software (Cisco IOS) except for ATM shaping which is implemented in hardware. Traffic shaping is used to limit the departure rate of packets, frames or cells by delaying them if they exceed the contractual rate. A token bucket model is used to measure the arrival rate and determine when packets can be forwarded.
66
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Queuing
Shaping Dropping
Scheduling Dropping
• Dropping mechanisms – Committed Access Rate (CAR) and Class-based Policing can drop packets that exceed the contractual rate – Weighted Random Early Detection (WRED) can randomly drop packets when an interface is nearing congestion © 2001, Cisco Systems, Inc.
IP QoS Introduction-66
Another way of enforcing rate limits is to drop excess traffic. Committed Access Rate (CAR) and Class-based Policing can be used for this purpose. Weighted Random Early Detection (WRED) is a congestion-avoidance mechanism that randomly drops packets when interfaces are nearing congestion.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
67
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Forwarding
Shaping Dropping
Queuing Scheduling Dropping
• Cisco Express Forwarding (CEF) is recommended from IOS 12.0 • Some QoS features work only in combination with CEF
© 2001, Cisco Systems, Inc.
IP QoS Introduction-67
The Cisco IOS supports a large number of different forwarding mechanisms (depending on the platform and the IOS version). From the QoS perspective it can be said that: n
Most newer mechanisms require Cisco Express Forwarding (CEF)
n
Some older mechanisms do not work with CEF (Process or Fast switching is required)
Some other forwarding mechanisms available in the Cisco IOS include:
68
IP QoS Introduction
n
Process switching, which is the oldest forwarding mechanisms available since the first releases of Cisco IOS.
n
Fast switching, which is the first optimization of forwarding. It uses a cache to store most used destinations and it is performed in the interrupt code to improve performance.
n
Optimum switching, which is a further optimized version of fast switching on high-end routers.
n
NetFlow switching, which forwards packets by recognizing and caching flow information.
Copyright 2001, Cisco Systems, Inc.
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Forwarding
Shaping Dropping
Queuing Scheduling Dropping
• Traditional queuing mechanisms – FIFO, Priority Queuing (PQ), Custom Queuing (CQ)
• Weighted Fair Queuing (WFQ) family – WFQ, dWFQ, CoS-based dWFQ, QoS-group dWFQ
• Advanced queuing mechanisms – Class-based WFQ, Class-based LLQ © 2001, Cisco Systems, Inc.
IP QoS Introduction-68
The last mechanism that handles packets in the IOS is the queuing mechanism. The figure lists most of the queuing mechanisms.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
69
DiffServ Mechanisms in IOS Meter
Inbound traffic stream
Classifier
Marker
Conditioner
Forwarding
Shaping Dropping
Queuing Scheduling Dropping
• Tail drop on queue congestion • WFQ has an improved tail-drop scheme • WRED randomly drops packets when nearing congestion
© 2001, Cisco Systems, Inc.
IP QoS Introduction-69
All queuing mechanisms include a drop policy. Most mechanisms use a simple taildrop scheme (the last packet to arrive is dropped if there is no room in the queue). Weighted Fair Queuing (WFQ) uses a more intelligent dropping scheme, which is discussed in the “IP QoS – Queuing mechanisms” module. Some queuing mechanisms also include the Weighted Random Early Detection (WRED) to prevent congestion in their queues.
70
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Describe different classification options in IP networks
n
Describe different marking options in IP networks
n
List the mechanisms that are capable of measuring the rate of traffic
n
List the mechanisms that are used for traffic conditioning, shaping and avoiding congestion
n
List the forwarding mechanisms available in the Cisco IOS
n
List the queuing mechanisms available in the Cisco IOS
Review Questions Answer the following questions: n
Name the QoS building blocks.
n
What is the purpose of classification?
n
What is the purpose of marking?
n
Which markers do you know?
n
Which mechanisms can classify and mark packets?
n
Which mechanisms have the ability to measure the rate of traffic?
n
Which forwarding mechanisms do you know?
n
Which queuing mechanisms do you know?
n
How, when and where do routers drop packets?
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
71
Enterprise Network Case Study Objectives Upon completion of this lesson, you will be able to perform the following tasks:
72
IP QoS Introduction
n
Describe a typical structure of an enterprise network
n
Describe the need for QoS in enterprise networks
n
List typical QoS requirements in enterprise networks
n
List the QoS mechanisms that are typically used in enterprise networks
Copyright 2001, Cisco Systems, Inc.
Traditional Enterprise Networks Core (central sites and data centres)
X.25 (ancient), Frame Relay (old), ATM (newer)
Distribution (regional centres)
X.25 (ancient), Frame Relay (old), ATM (newer)
Access (branch offices)
• Traditional enterprise network use a hub-and-spoke topology • Redundant connections are used to improve resilience • Partial mesh can be used between the core sites and the distribution sites © 2001, Cisco Systems, Inc.
IP QoS Introduction-74
This lesson describes typical Enterprise Networks to show the topology and technologies involved in such networks. Designing IP QoS networks largely depends on the topology and QoS requirements. The figure illustrates a three-layered network: 1. The core interconnects the data center(s) with the distribution-layer routers. 2. The distribution layer routers concentrate links towards a number of accesslayer routers. 3. The access-layer routers connect branch offices to the network. Most traffic in enterprise networks goes between branches and the data center.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
73
Modern Enterprise Networks Core (central sites and data centres)
MPLS/VPN (new)
Access (branch offices)
• Modern enterprise network use a full mesh topology provided by an MPLS/VPN backbone • Redundant connections to the backbone can be used to improve resilience • The MPLS/VPN backbone uses redundant connections and a partial mesh to improve resilience © 2001, Cisco Systems, Inc.
IP QoS Introduction-75
Modern enterprise networks can use MPLS/VPN backbones to get a virtual full mesh even though most traffic still goes between the data center and the branches. Implementing QoS in such environments requires QoS guarantees from the service provider and provisioning in the enterprise part of the network.
74
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
QoS in Enterprise Networks • Typical enterprise networks have a large number of different applications • Some applications are business-critical and require some guarantees (bandwidth, delay) • The network should provide enough resources to these business-critical applications • Applications are usually identified based on TCP or UDP port numbers
© 2001, Cisco Systems, Inc.
IP QoS Introduction-76
Enterprise networks are typically concerned with providing differentiated QoS to applications. Applications can be classified based on TCP or UDP port numbers and marked with IP precedence or DSCP at network edges. The network should guarantee resources to all business-critical applications (classes).
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
75
Case Study • Typical line speeds – Core - Distribution – Distribution - Branch
< 2 Mbps 64 kbps - 256 kbps
• Typical protocols – SNA, NetBIOS, Desktop protocols (IPX), Some TCP/IP, Voice, Multimedia
• Typical QoS requirements – SNA and voice are high priority – Guaranteed bandwidth for some application – Rest of the traffic is best-effort © 2001, Cisco Systems, Inc.
IP QoS Introduction-77
The figure shows a case study where relatively low bandwidths are used which calls for QoS to manage bandwidth according to the needs of the enterprise.
76
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Case Study Implementation #1 • Core - Distribution – Custom queuing
• Distribution - Branch – Priority queuing or – Custom Queuing with a priority queue
• Options – Traffic shaping – Adaptation to Frame Relay congestion notification
© 2001, Cisco Systems, Inc.
IP QoS Introduction-78
The figure lists mechanisms that could be used to accommodate the need of the enterprise. This solution would normally be used in networks where an old IOS version is being used and an upgrade is not an option (due to the cost of getting newer IOS versions, memory upgrade, flash upgrade, etc.). The listed mechanisms (Priority Queuing and Custom Queuing) have been available since Cisco IOS version 10.0.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
77
Case Study Implementation #2 • Core - Distribution – Class-based Weighted Fair Queuing (CB-WFQ) – Class-based Low Latency Queuing (CB-LLQ)
• Distribution - Branch – Class-based Weighted Fair Queuing (CB-WFQ) – Class-based Low Latency Queuing (CB-LLQ)
• Options – Class-based Shaping – Adaptation to Frame Relay congestion notification – Class-based Policing – Weighted Random Early Detection (WRED) © 2001, Cisco Systems, Inc.
IP QoS Introduction-79
This figure shows a solution using advanced mechanisms to provide better control of bandwidth usage. This solution requires newer Cisco IOS software versions (12.1 or 12.2, depending on the details of the implementation).
78
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Describe a typical structure of an enterprise network
n
Describe the need for QoS in enterprise networks
n
List typical QoS requirements in enterprise networks
n
List the QoS mechanisms that are typically used in enterprise networks
Review Questions Answer the following questions: n
What is the typical enterprise network topology?
n
How is resilience achieved?
n
Based on which information do typical enterprise networks apply QoS?
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
79
Service Provider Case Study Objectives Upon completion of this lesson, you will be able to perform the following tasks:
80
IP QoS Introduction
n
Describe a typical structure of a service provider network
n
Describe the need for QoS in service provider networks
n
List typical QoS requirements in service provider networks
n
List the QoS mechanisms that can be used in service provider networks
Copyright 2001, Cisco Systems, Inc.
Typical Service Provider Networks
Core
ATM, SONET/SDH, DPT, GE, ...
Partial mesh Rings
ATM, SONET/SDH, DPT, GE, ...
Redundant connections Rings
Distribution (regional POPs)
Frame Relay, ATM, Leased line (analog, TDM), dial-up (PSTN, ISDN, GSM), xDSL, (fast)ethernet, ...
Single connections Optional redundant connections Dial backup
Access (customers)
• • • •
Typical service provider networks use a high -speed partially-meshed core (backbone) Regional POPs use two or more connections to the core There may be another layer of smaller POPs connected to distribution-layer POPs Customers are usually connected to the service provide via a single point-to-point link (a secondary link or a dial line can be used to improve resilience)
© 2001, Cisco Systems, Inc.
IP QoS Introduction-84
As the figure illustrates, Service Provider networks significantly differ from typical enterprise networks. Enterprise Networks are used as a tool to support the enterprise whereas with Service Providers the network is the business itself. Enterprise networks are concerned with providing quality to business-critical applications and Service Providers tend to broaden their service offering by introducing QoS.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
81
QoS in Service Provider Networks Networks • Service providers extend their service offerings by introducing quality • Customers can get bandwidth guarantees (like CIR in Frame Relay) • Customers can get delay guarantees (like CBR in ATM) • Customers can get preferential treatment in case of congestion (Olympic service) • QoS mechanisms have to be deployed where congestion is likely (usually at network edge) • Customer’s traffic is identified based on source or destination IP addresses © 2001, Cisco Systems, Inc.
IP QoS Introduction-85
Service Providers want to offer customers more than plain connectivity. Service Providers want to establish differentiated levels of service for customers with incremental pricing and SLA agreements. The customer should not only shop around among a number of service providers that offer connectivity to the Internet or provide MPLS/VPNs, but also have a menu of services they can choose from. Some customers are satisfied with the best-effort service; some want certain service guarantees.
82
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Case Study A service provider wants to offer gold, silver, bronze and premium services • Premium gets 40% of available bandwidth with a low-delay guarantee • Gold gets 30% of available bandwidth • Silver gets 20% of available bandwidth • Bronze gets 10% of available bandwidth
© 2001, Cisco Systems, Inc.
IP QoS Introduction-86
The case study shows an example of a Service Provider which offers differentiated service levels where customers can choose the type of service they want and are willing to pay for. The service provider offers four services. Each of the services is basically a virtual service-provider network using a common infrastructure. The Premium service is guaranteed the most bandwidth and low-delay propagation of packets. Each of the following services is guaranteed less bandwidth. Premium customers will benefit most in times of congestion, whereas Bronze customers will only receive 10 percent of any link’s bandwidth.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
83
Case Study Implementation • Class-based Weighted Fair Queuing (CBWFQ) on slow to moderate-speed links • Class-based Low Latency Queuing (CB-LLQ) on slow to moderate-speed links • Weighted Random Early Detection (WRED) on fast links
© 2001, Cisco Systems, Inc.
IP QoS Introduction-87
Service Provider networks would generally use newer Cisco IOS software and can therefore deploy the latest available mechanisms. The case study is implemented using CB-WFQ in combination with WRED and CB-LLQ at networks edges (between access and distribution layer). WRED can be used on high-speed links (on core links).
84
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Describe a typical structure of a service provider network
n
Describe the need for QoS in service provider networks
n
List typical QoS requirements in service provider networks
n
List the QoS mechanisms that can be used in service provider networks
Review Questions Answer the following questions: n
What is the typical topology of service provider networks?
n
How is resilience achieved?
n
Based on which information do typical service provider networks apply QoS?
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
85
Summary After completing this module, you should be able to perform the following tasks:
86
IP QoS Introduction
n
Describe the need for IP QoS
n
Describe the Integrated Services model
n
Describe the Differentiated Services model
n
Describe the building blocks of IP QoS mechanisms (classification, marking, metering, policing, shaping, dropping, forwarding and queuing)
n
List the IP QoS mechanisms available in the Cisco IOS
n
Describe what QoS features are supported by different IP QoS mechanisms
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Introduction to IP Quality of Service Question: What are the relevant parameters that define the quality of service? Answer: Throughput (bandwidth), delay and jitter. Question: What can be done to give more bandwidth to an application? Answer: An application can get more throughput by increasing the bandwidth of the links in the path and/or using a QoS mechanism to guarantee bandwidth when the application has to contend with other flows. Payload and header compression also virtually increase the available bandwidth by reducing the overhead. Question: What can be done to reduce delay? Answer: Delay can be reduced by increasing the bandwidth of the links in the path and/or using a queuing mechanism that ensures minimum queuing delay for delaysensitive applications. Header compression will also help by reducing the serialization delay of small packets on low-speed links. Payload compression would have a similar result but it increases the delay because of the complexity of the compression algorithm. Question: What can be done to prevent packet loss? Answer: Packet loss can also be prevented by providing enough bandwidth. Alternatively a differentiated dropping mechanism can be used to drop packets of less important flows to prevent drops of high-priority flows. Another option is to use a queuing mechanism to guarantee enough bandwidth to high-priority flows. Question: Name the three QoS models? Answer: Best effort, Integrated services and Differentiated services.
Integrated Services Model Question: What are the two building blocks of the Integrated Services model? Answer: Resource reservation and admission control. Question: Which protocol is used to signal QoS requirements to the network? Answer: Resource reservation protocol (RSVP) is used to reserve network resources for applications.
Differentiated Services Model Question: What are the benefits of the DiffServ model compared to the IntServ model? Answer: DiffServ provides more scalable QoS solutions by applying QoS mechanisms (per-hop behavior) to traffic classes instead of individual applications. The DiffServ model does not require any signaling mechanism thus allowing QoS provisioning to non-RSVP applications. Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
87
Questions: What is a DiffServ Code Point? Answer: The DSCP is used to mark IP packets. It occupies the high-order 6 bits of the DiffServ field (former ToS field). Questions: Name the standard PHBs? Answer: Expedited Forwarding (EF), Assured Forwarding (AF) and Class Selector (CS). Questions: How was backward compatibility with IP precedence achieved? Answer: Backward compatibility is provided by using the DSCP values that map into IP precedence values that are typically used to achieve a similar goal: EF maps into IP precedence 5, AF1 maps into IP precedence 1, AF2 maps into IP precedence 2, AF3 maps into IP precedence 3, AF4 maps into IP precedence 4, the default DSCP maps into the default IP precedence 0. Questions: Describe the PHB of Assured Forwarding. Answer: AF PHB provides a bandwidth guarantee to a traffic class with the possibility to use more bandwidth if it is available. Questions: Describe the PHB of Expedited Forwarding. Answer: EF PHB provides a bandwidth guarantee to a traffic class and it ensures a minimum queuing delay. The traffic class is also limited to the provisioned bandwidth.
88
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Building Blocks of IP QoS Mechanisms Review Questions Answer the following questions: Name the QoS building blocks.
n
Classification, marking, metering, dropping, policing, shaping and queuing. What is the purpose of classification?
n
Classification is used to assign packets to traffic classes with different QoS requirements (behavior aggregates). What is the purpose of marking?
n
Marking is used to allow simplified classification on other devices in the network. Which markers do you know?
n
IP precedence, DSCP, MPLS experimental bits, QoS group, Frame Relay DE bit, ATM CLP bit, 802.1q CoS bits, ISL priority bits. Which mechanisms can classify and mark
n
packets? Policy-based Routing (PBR) Committed Access Rate (CAR) QoS Policy Propagation through BGP (QPPB) Class-based Policing Class-based Marking Which mechanisms have the ability to measure
n
the rate of traffic? Committed Access Rate (CAR) Generic Traffic Shaping (GTS) Frame Relay Traffic Shaping (FRTS) Class-based Weighted Fair Queuing (CB-WFQ) Class-based Low Latency Queuing (CB-LLQ) Class-based Policing Class-based Shaping IP RTP Prioritization n
Which forwarding mechanisms do you know? Process Switching, Fast Switching, Optimum Switching, NetFlow Switching, CEF switching …
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
89
n
Which queuing mechanisms do you know? FIFO, Priority Queuing (PQ), Custom Queuing (CQ), WFQ, dWFQ, CoS-based dWFQ, QoS-group dWFQ, Class-based WFQ, Class-based LLQ
n
How, when and where do routers drop packets? Routers typically drop packets when an output interface is congested. The output queue fills up and the newly arriving packets have to be dropped (tail drop).
90
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Enterprise Network Case Study Review Questions Answer the following questions: What is the typical enterprise network topology?
n
Enterprise networks typically use the hub-and-spoke topology. How is resilience achieved?
n
Resilience is achieved by using redundant links. Based on which information do typical enterprise
n
networks apply QoS? Enterprise networks typically provide QoS to applications. Applications are typically identified based on the TCP or UDP port numbers.
Copyright 2001, Cisco Systems, Inc.
IP QoS Introduction
91
Service Provider Case Study Review Questions Answer the following questions: What is the typical topology of service provider
n
networks? Typical service provider networks use a partially meshed core with a redundant hub-and-spoke topology for the POPs. n
How is resilience achieved? Resilience is achieved by using partial mesh (core) and redundant links (distribution, access).
n
Based on which information do typical service provider networks apply QoS? Service providers typically apply QoS to customer traffic. Customer traffic is identified based on source or destination IP addresses.
92
IP QoS Introduction
Copyright 2001, Cisco Systems, Inc.
Classification and Marking
Overview This module describes the mechanisms that are used to classify and mark IP packets. This module builds on the knowledge acquired from the introductory module where classification and marking is discussed. Theoretical knowledge is supplemented by detailing Policy-based routing (PBR) and QoS Policy Propagation through BGP (QPPB) mechanisms.
Objectives Upon completion of this module, you will be able to: n
Describe Policy-based routing and how it is used to classify and mark IP packets
n
Describe QoS Policy Propagation through BGP and how it is used to classify and mark IP packets
n
List other mechanisms that also support classification and marking capabilities (Committed Access Rate, Class-based Policing and Class-based Marking)
Traffic Classification and Marking Classification • Most QoS mechanisms in the Cisco IOS include some type of classification • Some mechanisms classify packets automatically, some require manual configuration
Marking • Only a small number of mechanisms also include a marking capability
© 2001, Cisco Systems, Inc.
Classification and Marking-3
This module focuses on the QoS mechanisms that are used for classification and marking purposes only. Most QoS mechanisms include some type of classification but only a small number of mechanisms also include marking capability. Classification is the term used for identifying a Behavior Aggregate to which a packet belongs. A Behavior Aggregate is a collection of flows requiring the same quality of service. Marking is the term used for coloring packets by applying a class-identifying value to one of the following markers: IP precedence, DSCP, QoS group (value is local to a router), MPLS experimental bits (can be used only in MPLS-enabled networks), ATM CLP bit (value can be used only within ATM networks), Frame Relay DE bit (value can be used only within Frame Relay networks), IEEE 802.1q or ISL cos/priority bits (value can be used on within LAN-switched networks).
2-2
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Traffic Classification and Marking • This module describes the two mechanisms that are used for classification and marking only: – Policy-based Routing (PBR) – QoS Policy Propagation through BGP (QPPB)
• Other classification and/or marking mechanisms are described in other QoS modules
© 2001, Cisco Systems, Inc.
Classification and Marking-4
This module describes the two QoS mechanisms that are used purely for classification and marking purposes: n
Policy-based Routing (PBR)
n
QoS Policy Propagation through BGP (QPPB)
There are other QoS mechanisms that also support classification and marking: n
Committed Access Rate (CAR) – this mechanism is described in the “IP QoS – Traffic Shaping and Policing” module
n
Class-based Policing (CB-Policing) – this mechanism is described in the “IP QoS – Modular QoS CLI (Chapter 2)” module
n
Class-based Marking (CB-Marking) – this mechanism is described in the “IP QoS – Modular QoS CLI (Chapter 2)” module
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-3
Policy-based Routing Objectives Upon completion of this lesson, you will be able to:
2-4
n
Describe Policy Based Routing (PBR)
n
Configure PBR on Cisco routers
n
Monitor and troubleshoot PBR
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Policy-based Routing • Policy-based Routing (PBR) is a mechanism that can be used to bypass the default destination-based forwarding functionality of routers • PBR is implemented using a route map where match commands are used to classify packets and set commands are used to process packets • Route maps are applied to interfaces for processing of inbound packets (forwarding and/or marking) © 2001, Cisco Systems, Inc.
Classification and Marking-7
The primary function of Policy-based Routing (PBR) is to bypass the destination-based forwarding functionality of routers by using a route map to make a forwarding decision based on other information. One additional feature of Policy Based Routing is the ability to modify IP packets by marking them with IP precedence or QoS group.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-5
PBR “match” and “set” Options
Match on: • Standard and extended access lists • Length of packets (min,max)
Set: • Output interface (bypass the routing table) • Next-hop address (bypass the routing table) • ToS field (QoS marking) • IP precedence (QoS marking) • QoS group (QoS marking)
IP Input interface
Output interface
PBR has two primary applications: • Implementation of more complex routing paradigms than a simple destination-based forwarding • Classification and marking of packets for QoS purposes © 2001, Cisco Systems, Inc.
Classification and Marking-8
PBR classifies packets based on standard or extended access lists, the length of packets and the incoming router interface (a route map is applied to an input interface). The route map sets the following parameters: n
Output interface: force the router to forward packets to an interface even if it would not provide for optimal routing
n
Next-hop address: to make a forwarding decision by using a different next-hop address than the one determined by the routing table
n
ToS value: the ToS value in this case applies to bits 4,3,2 and 1 of the ToS field
n
IP precedence: three-bit field used to identify a class of service
n
QoS group: the local parameter with an expanded value range
The first two parameters (output interface and next-hop address) are used to bypass the default destination-based routing. The other three parameters are used for QoS purposes (ToS value is less commonly used).
2-6
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
PBR Capabilities PBR can only classify and mark inbound or locallyoriginated packets
Meter
Inbound or Locally-originated
Classifier
Marker
Dropper
Forwarding Outbound
Meter
Classifier
© 2001, Cisco Systems, Inc.
Marker
Shaper Dropper
Queuing
Classification and Marking-9
The figure illustrates the “full” QoS building-block scheme showing that PBR works only on input and that it supports only classification and marking. The “Forwarding” box could be colored as well since PBR can be used to make a forwarding decision. PBR contains no mechanism for metering or dropping of data packets.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-7
Configuring Classification and Marking Using PBR • Create a route map • Apply the route map to an incoming interface and/or • Apply the route map to locally originated traffic • Monitor and debug policy routing
© 2001, Cisco Systems, Inc.
Classification and Marking -10
Configuring PBR involves the following steps:
2-8
n
Creating a route map where the match statement is used to match with the source or destination IP address or with any other parameter that can be matched by an access list (standard or extended). It can also match packets based on their size.
n
Applying the route-map to: n
An input interface to process inbound packets on that interface or
n
To locally originated packets
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Route Map Rules Router(config)#
route-map
Classification and Marking -11
A brief refresher about route maps: n
Route maps can have one or more statements. A route map, or a set of route-map statements with the same name is identified by a case-sensitive name .
n
Individual route-map statements are identified by their name and sequence number. When packets are processed by a route map they are evaluated in the order specified by sequence numbers.
n
A route map is basically made to be a filtering mechanism. When used for PBR:
n
Copyright 2001, Cisco Systems, Inc.
n
permit means “do whatever the set commands says”
n
deny means “do not do anything”
When a packet is matched by one of the route-map statements it is processed by that statement and the processing of the packet ends. Ordering route-map statements correctly is therefore necessary.
IP QoS Classification and Marking
2-9
PBR Classification Router(config-route-map)#
match ip address <#acl>
• Classify using a standard access list against the source address • Classify using an extended access list against the source and/or destination address, source and/or destination TCP/UDP port, IP precedence, DSCP, ToS Router(config-route-map)#
match length <min> <max>
• Classify using a range of packet lengths that will be matched by the route map statement
© 2001, Cisco Systems, Inc.
Classification and Marking -12
Route maps have a number of match options but only two can be used for policybased routing purposes:
2-10
n
match ip address is used to examine the packet’s headers with a standard or an extended access list
n
match length is used to mach packets based on their length
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
PBR Marking Router(config-route-map)#
set ip precedence <precedence> • Set the specified IP precedence to packets matched by the route map • IP precedence supports 8 classes, two are reserved (6 and 7) Router(config-route-map)#
set ip qos-group
set ip tos
Classification and Marking -13
The following marking options are available with route maps: n
IP precedence
n
QoS group
n
ToS value (the four bits below IP precedence in the ToS field) used for Delay, Throughput, Reliability and Monetary Cost
IP precedence is encoded into the three high-order bits of the ToS field in the IP header. It supports eight classes of which two are reserved and should not be used for user-defined classes (IP precedence 6 and 7). Ip precedence 0 is the default value and is usually used for the best-effort class. QoS group has one major advantage over IP precedence and one major drawback: n
QoS group supports up to 100 classes. Values 0 to 99 can be used to mark packets.
n
QoS group is a parameter that is local to the router where it is set. It is not part of any header. It is usually set on input interface and later examined (matched) on output interfaces. Once the packet is transmitted, the QoS-group information is lost, and the next router must reclassify and mark the packet.
ToS value is encoded into bits 4,3,2 and 1 of the ToS field (according to older RFCs 791 and 1349). This value was made obsolete by the introduction of the DiffServ Code Point, which does not take into account compatibility with these bits.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-11
Applying a Route Map Router(config-if)#
ip policy-map
• Specifies the route map used to set QoS and other policy-routing parameters for packets received through the specified interface Router(config)#
ip local policy-map
• Specifies the route map used to set QoS and other policy-routing parameters for packets generated by the router
© 2001, Cisco Systems, Inc.
Classification and Marking -14
Once a route map is configured it must be applied to either packets coming into the router through an interface or to packets being generated by the router. The first command (ip policy-map) is used for forwarded packets. The second command (ip local policy-map) is used for packets generated by a router and is typically used for tunneling packets (e.g. DLSw) Note
2-12
IP QoS Classification and Marking
Policy-based routing is a mechanism that puts interfaces into Process Switching mode. This will significantly degrade performance. PBR has been available in the fast-switching path since Cisco IOS version 11.3. The ip route-cache policy command can be used on an interface to enable caching for PBR. This command has been available since Cisco IOS software version 12.0.
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting PBR Router#
show route-map
• Displays the route map and number of packets and bytes matched by each statement Router#
debug ip policy
• Displays all packets matched by policy routing routemaps
© 2001, Cisco Systems, Inc.
Classification and Marking -15
The show route-map command is used to display the route map with its match and set options. The debug ip policy command is used to display all packets being processed by PBR. The show ip policy command is used to see a list of all interfaces that are enabled for PBR. The output also displays the corresponding route maps. The show ip local policy command is used to display the configured parameters for local PBR with a number of packets and bytes that have been policy-routed by the local PBR.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-13
Monitoring and Debugging Policy Routing Router#show Router#show route-map route-map CPE CPE route-map route-map CPE, CPE, permit, permit, sequence sequence 10 Match Match clauses: ip address address (access-lists): (access-lists): 199 Set clauses: clauses: ip precedence precedence flash-override flash-override Policy routing matches: 3418 packets, 412108 bytes route-map route-map CPE, CPE, permit, permit, sequence sequence 20 Match Match clauses: ip address address (access-lists): (access-lists): MatchPing MatchPing Set clauses: clauses: ip precedence precedence priority priority Policy Policy routing routing matches: matches: 82 82 packets, packets, 31045 31045 bytes bytes Router#show Router#show access-list access-list MatchPing MatchPing Extended Extended IP IP access access list MatchPing MatchPing permit icmp any any echo (25 matches) Router# Router# © 2001, Cisco Systems, Inc.
Classification and Marking -16
The figure shows a sample output of the show route-map and show access-list commands.
2-14
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Monitoring and Debugging Policy-based Routing Router#debug Router#debug ip ip policy policy Policy Policy routing routing debugging debugging is is on on Router#ping Router#ping 192.168.1.1 192.168.1.1 Type Type escape escape sequence sequence to to abort. abort. Sending Sending 5, 5, 100-byte 100 -byte ICMP ICMP Echos Echos to to 192.168.1.1, 192.168.1.1, timeout timeout is is 22 seconds: seconds: !!!!! !!!!! Success Success rate rate is is 100 100 percent percent (5/5), (5/5), round-trip round -trip min/avg/max min/avg/max == 28/31/32 28/31/32 ms ms Router# Router# 2d02h: 2d02h: IP: IP: s=192.168.1.2 s=192.168.1.2 (local), (local), d=192.168.1.1, d=192.168.1.1, len len 100, 100, policy policy match match 2d02h: 2d02h: IP: IP: route route map map CPE, CPE, item item 20, 20, permit permit ... ...
© 2001, Cisco Systems, Inc.
Classification and Marking -17
The debug ip policy command is similar to the debug ip packet except that the debug ip policy only displays policy-routed packets. This command should be used with caution as it may produce too much output.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-15
IP Precedence Marking Case Study #1 • Branch office of a bank has two LANs connected to an access router • Ethernet0 is the front office with the real time transactions • Ethernet1 is the back office with non-real time transactions (like e-mail)
• The network provides different services to two classes: • Business traffic (marked with IP precedence 2) • Other traffic (marked with IP precedence 0)
• Packets coming from Ethernet 0 should be classified and marked as Business traffic • Packets coming from Ethernet 1 should be classified and marked as Other traffic © 2001, Cisco Systems, Inc.
Classification and Marking -18
The case study involves a bank branch office where a single router connects two LANs to the corporate network via one serial interface. This case study focuses on the classification and marking part of a larger QoS solution, which includes other QoS mechanisms.
2-16
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Case #1- Solution Mark all traffic with precedence 2 E0
Mark all traffic with precedence 0 WAN core
interface interface ethernet ethernet 0 ip policy-map policy-map set-prec-2 set-prec-2 Core E1 !! interface ethernet ethernet 1 Branch interface policy-map set-prec-0 set-prec-0 office ip policy-map !! route-map route-map set-prec-2 set-prec-2 permit permit 10 10 set ip ip precedence 2 !! route-map route-map set-prec-0 set-prec-0 permit permit 10 10 set ip ip precedence 0
© 2001, Cisco Systems, Inc.
Classification and Marking -19
Policy-based routing can be used to mark packets with IP precedence values. All packets from Ethernet 0 are marked with IP precedence 2. Since matching is applied to all packets no “match” command is needed in the route map. The other route map is applied to the other Ethernet interface and it marks packets with IP precedence 0.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-17
IP Precedence Marking Case Study #2 • Branch office of a bank has one LAN connected to an access router • The network provides different services to three classes: • Transaction traffic (marked with IP precedence 2) • Business traffic (marked with IP precedence 1) • Other traffic (marked with IP precedence 0)
• TN3270 should be marked as Transaction traffic • Internal HTTP should be marked as Business traffic • All other traffic should be marked as Other traffic
© 2001, Cisco Systems, Inc.
Classification and Marking -20
The second case study is more complicated because classification is not done based on the input interface. Instead, classification if performed based on application (TCP or UDP port numbers).
2-18
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Case #2 - Solution
E0
WAN core
Core
interface interface eth eth 0 0
Mark Mark IP IP precedence: precedence: Telnet Telnet = 22 Corporate Corporate Web Web == 1 everything everything else else == 0
ip ip policy-map policy-map set-prec set-prec Branch !! office route-map set-prec route-map set-prec permit permit
10 10 match match ip ip address address CorporateWebTraffic CorporateWebTraffic set set ip precedence 11 route-map route-map set-prec set-prec permit permit 20 20 match match ip ip address address TN3270 TN3270 set set ip precedence 22 route-map route-map set-prec set-prec permit permit 30 30 set set ip precedence 00 !! ip ip access-list access-list extended extended CorporateWebTraffic CorporateWebTraffic permit permit tcp tcp any any 10.1.1.0 10.1.1.0 0.0.0.255 0.0.0.255 eq eq www www ip ip access-list access-list extended extended TN3270 TN3270 permit permit tcp tcp any any any any eq eq telnet telnet
© 2001, Cisco Systems, Inc.
Classification and Marking -21
A route map is created with three statements, one for each application: n
The first statement uses an access list to identify corporate web traffic (destination port 80). IP precedence 1 is applied to these packets.
n
The second statement uses another access list to identify outbound telnet sessions. IP precedence 2 is applied to these packets.
n
The last statement sets IP precedence 0 to all other packets.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-19
Route Map - Review • Policy routing with route maps can classify and mark IP packets based on a wide variety of conditions • No metering, shaping or dropping is possible • Performance depends on the IOS version – Policy routing is fast -switched in 11.3 and 12.0 – (d)CEF or Net Flow-switched in 12.0(3)T
© 2001, Cisco Systems, Inc.
Classification and Marking -22
Policy-based Routing features:
2-20
n
Static classification and marking (no metering, shaping, policing or dropping is possible).
n
PBR has performance limitations due to implementation (complex access lists can degrade performance, sub-optimal order of statements can also degrade performance due to sequential processing) and the IOS version (newer IOS versions support fast-switched operation of PBR).
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Summary Policy based routing is used for two purposes: n
Bypassing the traditional destination-based forwarding
n
Marking of IP packets with Ip precedence or QoS group
n
What are the applications of Policy-based Routing?
n
What configuration tool is used to implement PBR?
n
How can PBR be applied to IP traffic?
n
Describe the classification options with PBR.
n
Describe the marking options with PBR.
Lesson Review
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-21
QoS Policy Propagation through BGP (QPPB) Objectives Upon completion of this lesson, you will be able to:
2-22
n
Describe the QPPB mechanism
n
Configure the QPPB mechanism on Cisco routers
n
Monitor and troubleshoot QPPB
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
IP QoS Policy Propagation Through BGP (QPPB) • QPPB uses BGP attributes to advertise class of service to other routers in the network • BGP Communities are usually used to propagate class of service information bound to IP networks • Packet classification policy can be propagated via BGP without having to use complex access lists at each of a large number of border (edge) routers • A route map is used to translate BGP information (e.g. BGP Community value) into IP precedence or QoS group
© 2001, Cisco Systems, Inc.
Classification and Marking -27
QoS Policy Propagation through BGP is a mechanism that can be split into two parts: n
Policy propagation via BGP, where a QoS policy is encoded into a BGP attribute. BGP Communities are typically used to encode a QoS policy.
n
Marking of packets with IP precedence or QoS group based on the QoS policy learned via BGP.
BGP Policy is usually set on ingress routers (ingress for route propagation, egress for packet forwarding) in an Autonomous System. BGP then carries the information to other routers in the AS and translates (using a route map) this information into IP precedence or QoS group. Marking is then enabled on perinterface basis.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-23
QPPB Capabilities QPPB can only classify and mark inbound packets
Meter
Inbound or Locally-originated
Classifier
Marker
Dropper
Forwarding Outbound
Meter
Classifier
© 2001, Cisco Systems, Inc.
Marker
Shaper Dropper
Queuing
Classification and Marking -28
Similar to PBR, QPPB also supports classification and marking only on the input interface.
2-24
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
BGP Marking Meter Inbound traffic stream
Classifier
Marker
Dropper
1. Propagate the class of service by encoding it into BGP attributes: • • • •
BGP communities, AS paths, IP prefixes or any other BGP attribute
2. Translate the selected BGP attribute into either: • IP precedence or • QoS group
3. Enable Cisco Express Forwarding (CEF) and packet marking on interfaces © 2001, Cisco Systems, Inc.
Classification and Marking -29
QoS policy can be applied to source or destination IP addresses or networks. When BGP entries are inserted into the routing table a route map is used to translate a certain BGP parameter or attribute into IP precedence or QoS group. Packet marking is then enabled on input interfaces.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-25
Cisco Express Forwarding Review • The two main components of CEF operation – Forwarding Information Base – Adjacency Tables
• CEF was first introduced on the following platforms: – Cisco 7x00 series in 11.1CC – All RISC-based platforms in IOS 12.0
• QPPB is only supported on high-end routers (Cisco 7x00 and above)
© 2001, Cisco Systems, Inc.
Classification and Marking -30
QPPB has the following requirements:
2-26
n
Cisco Express Forwarding (CEF)
n
A high end platform (Cisco 7x000 routers)
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Review: Standard IP Switching BGP table
IP routing table
Switching cache
ARP cache
Address 10.0.0.0 ...
Protocol BGP conn.
Address 10.0.0.0 ...
IP address 1.2.3.4 ...
© 2001, Cisco Systems, Inc.
Prefix /8 ...
Address 10.0.0.0 1.2.3.0
Prefix /8 ...
AS-Path 42 13 ...
Prefix /8 /24
Next hop 1.2.3.4 ...
Next-hop 1.2.3.4 ---
Communities 37:12 ...
Other attr. ...
Outgoing interface --Ethernet 0
L2 header MAC header ...
MAC address 0c.00.11.22.33.44 ... Classification and Marking -31
The figure illustrates how BGP routing information is used on routers that are configured with the default switching operation: n
A BGP entry is inserted into the main routing table (the network points to the BGP next-hop address.
n
A recursive routing lookup is needed when the first packet arrives. After the output interface is identified, a cache entry is generated. Multi-access media requires additional information from the ARP cache.
n
The subsequent packets are forwarded using the fast-switching cache.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-27
Review: CEF Switching BGP table
IP routing table
FIB table (CEF cache)
Address 10.0.0.0 ...
Protocol BGP OSPF conn.
Address 10.0.0.0 ...
IP address Adjacency 1.5.4.1 table ...
Prefix /8 ...
Address 10.0.0.0 1.2.3.0 1.5.4.0
Prefix /8 ...
AS-Path 42 13 ...
Prefix /8 /24 /24
Next hop 1.2.3.4 ...
Next-hop 1.2.3.4 1.5.4.1 ---
Communities 37:12 ...
Other attr. ...
Outgoing interface --Ethernet 0 Ethernet 0
Adjacency pointer 1.5.4.1 ...
Layer 2 header MAC header ...
ARP cache IP address MAC address 1.5.4.1 0c.00.11.22.33.44 ... ...
© 2001, Cisco Systems, Inc.
Classification and Marking -32
CEF switching is different from the default operation in the following ways:
2-28
n
CEF switching cache (the FIB table and the adjacency table) reflects the information from the main routing table. Changes in the FIB table are not triggered by packets but by changes in the main routing table itself.
n
The CEF switching cache is split into two tables: n
Forwarding Information Base (FIB) which contains all networks that are taken from the routing table. Those entries point to directly accessible next-hops. Adjacency pointers are used to get information about these next-hops from the Adjacency table
n
Adjacency table contains a list of directly connected neighboring IP devices. A layer-2 header is created in advance to accelerate the encapsulation process.
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
CEF Switching with QoS Packet Marking BGP table
IP routing table
FIB table (CEF cache)
Address 10.0.0.0 ...
Protocol BGP OSPF conn.
Address 10.0.0.0 ...
IP address Adjacency 1.5.4.1 table ...
Prefix /8 ...
Address 10.0.0.0 1.2.3.0 1.5.4.0
Prefix /8 ...
AS-Path 42 13 ...
Prefix /8 /24 /24
Next hop 1.2.3.4 ...
Next-hop 1.2.3.4 1.5.4.1 ---
Adjacency pointer 1.5.4.1 ...
Layer 2 header MAC header ...
Communities Other attr. 37:12 BGP table... map ...
Outgoing interface Precedence QoS group --3 7 Ethernet 0 ----Ethernet 0 -----
Precedence QoS group 3 7 ... ... ARP cache IP address MAC address 1.5.4.1 0c.00.11.22.33.44 ... ...
© 2001, Cisco Systems, Inc.
Classification and Marking -33
When using CEF for packet marking a table map is used in the BGP configuration mode to process routes inserted into the routing table. A route map (used as a table map in BGP) can translate any BGP parameter or attribute into IP precedence or QoS group. This information is then passed on to the FIB table. Once packet marking is enabled the router will perform two CEF lookups: n
The first lookup is used to mark packets
n
The second lookup is used to make a forwarding decision
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-29
QPPB Configuration Tasks • Create a route map to set IP precedence or QoS group • Apply the route map to BGP routes transferred to main IP routing table • Enable per-interface packet marking
© 2001, Cisco Systems, Inc.
Classification and Marking -34
Before configuring routers to support QPPB, a QoS design, which must include the following, is needed: n
BGP attribute used to encode class of service (BGP Communities are usually used)
n
Marker (when using QPPB only IP precedence or QoS group can be used)
The following configuration steps are necessary on routers that perform packet marking:
2-30
n
Enable CEF
n
Create a route map that translates a BGP attribute into IP precedence or QoS group
n
Apply the route map to process BGP routes before they are entered into the main routing table.
n
Enable per interface marking.
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Setting IP Precedence or QoS Group in the IP Routing Table Router(config-router)#
table-map
• Specifies the route map used to set additional routing table attributes Router(config)#
route-map
• Specifies IP precedence and QoS group values in the routing table/FIB table entry
© 2001, Cisco Systems, Inc.
Classification and Marking -35
Use the table -map command in the BGP configuration mode to populate the main routing table with the class of service information. A route map can “tag” networks with IP precedence, QoS group or both.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-31
Enable Per-interface Packet Marking Router(config-if)#
bgp-policy source ip-prec-map
• Applied to packets received through this interface • Uses FIB to map packet source IP address to IP precedence • Rewrites IP precedence in the packet Router(config-if)#
bgp-policy source ip-qos-map
• Applied to packets received through this interface • Uses FIB to map packet source IP address to QoS group • QoS group attached to the incoming packet © 2001, Cisco Systems, Inc.
Classification and Marking -36
Once the FIB table contains the class of service information (IP precedence or QoS group), marking can be configured on input interfaces. CEF-based marking is performed based on the following:
2-32
n
Find the source address (taken from the packet being marked) in the FIB table and mark it with the IP precedence value attached to the address/network. Use the bgp-policy source ip-prec-map interface command to mark the packet.
n
Find the source address (taken from the packet being marked) in the FIB table and mark it with the QoS group value attached to the address/network. Use the bgp-policy source ip-qos-map interface command to mark the packet.
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Enable Per-interface Packet Marking Router(config-if)#
bgp-policy destination ip-prec-map
• Applied to packets received through this interface • Uses FIB to map packet destination IP address to IP precedence • Rewrites IP precedence in the packet Router(config-if)#
bgp-policy destination ip-qos-map
• Applied to packets received through this interface • Uses FIB to map packet destination IP address to QoS group • QoS group attached to the incoming packet © 2001, Cisco Systems, Inc.
Classification and Marking -37
n
Find the destination address (taken from the packet being marked) in the FIB table and mark it with the IP precedence value attached to the address/network. Use the bgp-policy destination ip-qos-map interface command to mark the packet.
n
Find the destination address (taken from the packet being marked) in the FIB table and mark it with the QoS group value attached to the address/network. Use the bgp-policy destination ip-qos-map interface command to mark the packet.
All four commands can be attached to the same interface (although not recommended) and they are processed in the following order: n
Source-based IP precedence marking
n
Source-based QoS group marking
n
Destination-based IP precedence marking (overrides source-based marking)
n
Destination-based QoS group marking (overrides source-based marking)
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-33
Case Study
WAN core NAP router
NAP router
POP router
AS 24
AS 12
Customer (AS 73)
Create an end-to-end IP QoS solution in a Service Provider network: • Customer in AS 73 is a Premium customer • All packets to and from AS 73 shall be sent with precedence flash © 2001, Cisco Systems, Inc.
Classification and Marking -38
This case study shows how customer networks can be marked with a BGP community identifying a class of service, which is then propagated throughout the Autonomous System 12 and used on edge routers to classify and mark packets towards the customer networks with IP precedence flash (IP precedence 3). Each IP precedence value is also identified by a name:
2-34
IP QoS Classification and Marking
IP precedence value
IP precedence name
0
Routine
1
Priority
2
Immediate
3
Flash
4
Flash-override
5
Critical
6
Internet
7
Network
Copyright 2001, Cisco Systems, Inc.
Step #1 Distribute QoS functions
WAN core NAP router
NAP router
AS 24
POP router
AS 12
Customer (AS 73)
packets for AS73 marked with precedence flash packets from serial interface marked with precedence flash © 2001, Cisco Systems, Inc.
Classification and Marking -39
To achieve the same level of quality in both directions the packets going to and coming from the customer network must first be classified and marked. Classification and marking of packets coming from the customer network is trivial: n
PBR without a match statement is used on the interface connection from the customer network to the ISP’s network.
n
Another option is to use other mechanisms such as Committed Access Rate (CAR), Class-based Policing or Class-based Marking.
Classifying and marking packets going to the customer network is a more difficult task because: n
Classifying and marking must be performed on all edge routers.
n
Classifying and marking requires the identification of the customer network. Using PBR, CAR, CB-Policing or CB-Marking does not scale because it involves the use of access lists (this is especially difficult if customer networks are dynamically learned via BGP).
QPPB is the only scalable mechanism that can classify and mark packets based on their source or destination IP address.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-35
Step #2 Select QoS mechanisms
WAN core NAP router
NAP router
POP router
AS 24
AS 12
Customer (AS 73)
CEF-based marking packets for AS73 marked with precedence flash
PBR on interface
packets from serial interface marked with precedence flash © 2001, Cisco Systems, Inc.
Classification and Marking -40
The case study will employ PBR to do the marking of outbound packets (from the customer perspective). QPPB will be used to mark inbound packets on remote edge (border) routers.
2-36
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Step #3 - Design Individual QoS Mechanisms Mark BGP routes from AS 73 with special community (12:17) Configure community propagation
WAN core NAP router
AS 24
NAP router
POP router
Customer ASSet 12 FIB table (AS 73) on based
BGP community Configure CEF packet marking for packets coming from adjacent AS © 2001, Cisco Systems, Inc.
Classification and Marking -41
Customers networks are tagged with BGP Community 12:17 and sent to all internal BGP neighbors. Edge routers use a table map to translate BGP Community 12:17 into IP precedence 3. Destination-based precedence marking is enabled on interfaces connecting the AS to other ASs.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-37
Mark Routes Coming From AS 73
WAN core NAP router
NAP router
AS 24
POP router
AS 12
Customer (AS 73)
router bgp 12 neighbor 1.2.3.4 remote-as 73 neighbor 1.2.3.4 route-map Premium in ! route-map Premium permit 10 set community 12:17 additive
© 2001, Cisco Systems, Inc.
Classification and Marking -42
The figure illustrates how a route map is used to process inbound BGP routing updates coming from the customer’s AS 73. The BGP community attribute 12:17 is added to the routing updates.
2-38
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Configure Community Propagation
WAN core NAP router
NAP router
AS 24
POP router
AS 12
Customer (AS 73)
router bgp 12 neighbor 2.3.4.5 remote-as 12 neighbor 2.3.4.5 send-community
© 2001, Cisco Systems, Inc.
Classification and Marking -43
BGP Community propagation is not enabled by default. It is, therefore, necessary to use the send-community option on all internal BGP sessions to allow BGP Communities to be propagated throughout the autonomous system.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-39
Set FIB Table Based on BGP Community
WAN core NAP router
AS 24
© 2001, Cisco Systems, Inc.
NAP router
POP router
router bgp 12 Customer table-map PremiumCheck AS 12 (AS 73) ! route-map PremiumCheck permit 10 match community 17 set ip precedence flash ! route-map PremiumCheck permit 20 set ip precedence 0 ! ip community-list 17 permit 12:17
Classification and Marking -44
The edge routers use route maps to translate BGP Community values into appropriate IP precedence values. The figure illustrates how all routes carrying BGP community 12:17 are tagged with IP precedence 3 in the routing table and the FIB table. All other networks are tagged with IP precedence 0. Note
2-40
IP QoS Classification and Marking
Setting IP precedence 0 on all packets not specifically matched by a table map is also a security feature because it prevents IP precedence spoofing. Anyone trying to use a high IP precedence value (e.g. 6 or 7) will be remarked with IP precedence 0 and get the best-effort service.
Copyright 2001, Cisco Systems, Inc.
Configure CEF Packet Marking
WAN core NAP router
AS 24
NAP router
POP router
AS 12
Customer (AS 73)
ip cef ! interface hssi 0/0 bgp-policy destination ip-prec-map !
© 2001, Cisco Systems, Inc.
Classification and Marking -45
The last configuration step is to enable CEF-based marking on border interfaces. The case study requires that all packets going to (destination-based marking) the customer’s network be marked with IP precedence 3. QPPB marking is only available in combination with CEF switching. The global ip cef command enables CEF switching on all interfaces that support CEF.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-41
IP QoS and BGP Interaction Review • IP QoS features work independently of BGP routing • BGP is used only to propagate policies for source or destination IP prefixes through the network • QPPB works only on high-end platforms
© 2001, Cisco Systems, Inc.
Classification and Marking -46
Although QPPB support is only available on high-end routers there is no limitation when it comes to tagging BGP routes. Only marking routers have to support QPPB: all other routers simply have to support BGP.
2-42
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Summary QPPB is a mechanism that is used to implement more scalable QoS solutions. It uses BGP to propagate QoS policy information and CEF to mark packets with IP precedence or QoS group.
Lesson Review n
Why is QPPB needed?
n
How is QoS policy propagated through a network?
n
How are QoS traffic classes defined by QPPB?
n
Which IP forwarding mechanisms support QPPB?
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-43
Other QoS Mechanisms with Classification and Marking Capability Objectives Upon completion of this lesson, you will be able to:
2-44
n
Explain how most QoS mechanisms support some type of classification
n
Name CAR, CB-Policing and CB-Marking as mechanisms that support classification and marking
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Classification • Most QoS mechanisms include some type of classification • Some mechanisms have automatic classification (e.g. WFQ, WRED, ...) • Some mechanisms require manual configuration of classification (e.g. CQ, PQ, CB-WFQ, ...)
© 2001, Cisco Systems, Inc.
Classification and Marking -51
Most QoS mechanisms include some type of classification: n
Some mechanisms classify packets automatically. Weighted Fair Queuing (WFQ), for instance, classifies packets into flows. Weighted Random Early Detection (WRED) classifies packets based on their IP precedence values, etc.
n
Other mechanisms require manual configuration of classification.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-45
Marking The following mechanism (in addition to PBR and QPPB) contain classification and marking capability : • Committed Access Rate (CAR) • Class-based Policing • Class-based Marking
© 2001, Cisco Systems, Inc.
Classification and Marking -52
Only a few remaining mechanisms have marking capabilities: n
Committed Access Rate (CAR), which is used for traffic policing
n
Class-based Policing, which is also used for traffic policing
n
Class-based Marking, which is used for classification and marking purposes only. It may however be combined with other mechanisms available with the Modular QoS CLI
CAR and Class-based Policing are discussed in detail in the “IP QoS – Traffic Shaping and Policing” module. Class-based Marking is discussed in detail in the “IP QoS – Modular QoS CLI (Service Policy)” module. This module includes a high-level overview of these QoS mechanisms.
2-46
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Committed Access Rate (CAR) • CAR is a mechanism used for traffic policing • CAR uses a token bucket model to measure the rate of traffic and (optionally) drop excess traffic • CAR can also be used to mark packets with: – – – –
IP precedence DiffServ Code Point (DSCP) MPLS experimental bits QoS group
• CAR can mark packets with different values depending on whether they conform or exceed the specified policy
© 2001, Cisco Systems, Inc.
Classification and Marking -53
CAR is a mechanism used to limit the traffic rate of a class and optionally mark packets with one of the following markers: n
IP precedence
n
DSCP
n
MPLS experimental bits
n
QoS group
CAR can also mark packets with two different values depending on whether they: n
Conform to the policy (packet is within the contractual bit-rate)
n
Exceed the policy (packet is over the contractual bit-rate)
Conforming and exceeding packets can be marked with different values.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-47
Class-based Policing • Class-based Policing is similar to CAR except it is implemented using the modular QoS CLI • CB-Policing uses two token buckets to determine if packets conform, exceed or violate the QoS policy • CB-Policing can also be used to mark packets with: – – – – – –
IP precedence DiffServ Code Point (DSCP) MPLS experimental bits QoS group ATM CLP bit Frame Relay DE bit
• CB-Policing can mark packets with different values depending on whether they conform, exceed or violate the policy © 2001, Cisco Systems, Inc.
Classification and Marking -54
Class-based Policing (CB-Policing) is a mechanism similar to CAR with the following main differences: n
Modular QoS CLI is used to implement CB-Policing on Cisco routers
n
CB-Policing supports more marking options than Committed Access Rate
n
CB-Policing uses two token buckets to identify not just conforming and exceeding packets but also violating packets.
Class-based policing can mark packets with three different values depending on whether they conform, exceed or violate the policy. Class-based Marking can mark packets with the following markers:
2-48
n
IP precedence
n
DSCP
n
MPLS experimental bits
n
QoS group
n
ATM CLP bit
n
Frame Relay DE bit
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Class-based Marking • Class-based Marking is used to classify and mark packets • This mechanism uses the modular QoS CLI where classes are manually configured • Class-based Marking can mark packets with the following markers: – – – – – – –
IP precedence DSCP MPLS experimental bits QoS group ATM CLP bit Frame Relay DE bit IEEE 802.1Q or ISL’s CoS
© 2001, Cisco Systems, Inc.
Classification and Marking -55
Class-based Marking is also implemented using the Modular QoS CLI. It supports the following markers: n
IP precedence
n
DSCP
n
MPLS experimental bits
n
QoS group
n
ATM CLP bit
n
Frame Relay DE bit
n
IEEE 802.1Q or ISL cos/priority bits
Class-based marking can be combined with other mechanisms available in the Modular QoS CLI.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-49
Summary The following mechanisms are used for classification and marking purposes: n
Policy-based Routing (PBR)
n
QoS Policy Propagation through BGP (QPPB)
n
Committed Access Rate (CAR)
n
Class-based Policing
n
Class-based Marking
PBR is a mechanism that was primarily intended for bypassing the destinationbased forwarding and marking packets with IP precedence or QoS group. QPPB is a mechanism that can also be used to mark packets with IP precedence or QoS group. Its main advantage is scalability.
Lesson Review
2-50
n
Which mechanisms in IOS support classification and marking of packets?
n
Which fields or parameters can be used to mark packets in Cisco IOS?
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Summary After completing this module, you should be able to perform the following tasks: n
Describe Policy-based routing and how it is used to classify and mark IP packets
n
Describe QoS Policy Propagation through BGP and how it is used to classify and mark IP packets
n
List other mechanisms that also support classification and marking capabilities (Committed Access Rate, Class-based Marking)
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-51
Review
Questions and Answers Policy-based Routing Question: What are the applications of Policy-based Routing? Answer: PBR is used to bypass the destination-based forwarding or to classify and mark packets. Question: What configuration tool is used to implement PBR? Answer: Route maps are used to implement PBR. Question: How can PBR be applied to IP traffic? Answer: PBR can be applied to input packets or packets originated by the router. Question: Describe the classification options with PBR. Answer: PBR’s classification options include standard and extended access lists as well as packet size based classification. PBR can also classify based on the input interface because it is used on per-interface basis. Question: Describe the marking options with PBR. Answer: PBR can set the next-hop address or output interface to bypass the default destination based forwarding. PBR can also mark packets with the following options: ToS bits, IP precedence or QoS group.
QoS Policy Propagation through BGP (QPPB)
Question: Why is QPPB needed? Answer: QPPB can propagate a QoS class of service information throughout an autonomous system. This allows more scalable QoS designs where classification is performed on one router and automatically propagated to all other routers in the AS.
Question: How is QoS policy propagated through a network? Answer: BGP is used to propagate the CoS by encoding it into any available BGP attribute.
Question: How are QoS traffic classes defined by QPPB? Answer: QPPB is limited to assigning IP networks to traffic classes. Question: Which IP forwarding mechanisms support QPPB? Answer: QPPB requires CEF switching to mark packets with IP precedence or QoS group.
2-52
IP QoS Classification and Marking
Copyright 2001, Cisco Systems, Inc.
Other QoS Mechanisms with Classification and Marking Capability
Question: Which mechanisms in IOS support classification and marking of packets?
Answer: Policy-based Routing (PBR) Committed Access Rate (CAR) QoS Policy Propagation through BGP (QPPB) Class-based Policing Class based Marking
Question: Which fields or parameters can be used to mark packets in Cisco IOS? Answer: IP precedence, DSCP, MPLS experimental bits, QoS group, Frame Relay DE bit, ATM CLP bit, 802.1q CoS bits, ISL priority bits.
Copyright 2001, Cisco Systems, Inc.
IP QoS Classification and Marking
2-53
Queuing Mechanisms
Overview This module describes the queuing mechanisms that can be used on output interfaces. It includes the following topics: n
Queuing Overview
n
FIFO Queuing
n
Priority Queuing
n
Custom Queuing
n
Weighted Fair Queuing
n
Distributed Weighted Fair Queuing
n
Modified Deficit Round-robin
n
IP RTP Prioritization
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe and configure FIFO Queuing (FQ)
n
Describe and configure Priority Queuing (PQ)
n
Describe and configure Custom Queuing (CQ)
n
Describe and configure basic Weighted Fair Queuing (WFQ), distributed WFQ, ToS-based distributed WFQ and QoS-group-based distributed WFQ
n
Describe and configure Modified Weighted Round-robin (MDRR) queuing
n
Describe and configure IP RTP Prioritization
Queuing Overview Objectives Upon completion of this lesson, you will be able to perform the following tasks:
3-2
Queuing Mechanisms
n
Understand how queuing works on Cisco routers
n
List the most used queuing mechanisms
Copyright 2001, Cisco Systems, Inc.
Queuing in Cisco IOS • Cisco routers running Cisco IOS have a number of different queuing mechanisms • This module focuses on the following: – First In First Out (FIFO) – Priority Queuing (PQ) – Custom Queuing (CQ) – Weighted Fair Queuing (WFQ) with the different distributed versions – Modified Deficit Round Robin (MDRR) – IP RTP Prioritization • These mechnisms are implemented as software queues © 2001, Cisco Systems, Inc.
Queuing Mechanisms -5
The lesson discusses how output queuing mechanisms are implemented on Cisco routers running Cisco IOS. It discusses most of the queuing mechanisms in detail, except Class-based Weighted Fair Queuing and Class-based Low-latency Queuing, which are discussed in the “IP QoS – Modular QoS CLI (Chapter 2)” module.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-3
Output Interface Queue Structure
Forwarder
Software Queuing System
Any supported queuing mechanism
Hardware Queue (TxQ)
Output Interface
Always FIFO
• Each Interface has its hardware and software queuing system • The hardware queuing system always uses FIFO queuing (Transmission queue or TxQ) • The software queuing system can be selected and configured depending on the platform and Cisco IOS version © 2001, Cisco Systems, Inc.
Queuing Mechanisms -6
Queuing on routers is necessary to accommodate bursts when the arrival rate of packets is greater than the departure rate due to one of the following two reasons: n
Input interface is faster than the output interface
n
Output interface is receiving packets coming in from multiple other interfaces
Initial implementations of queuing used a single FIFO (first-in first-out or first-come first-serve queuing) strategy. More complex queuing mechanisms were introduced when special requirements need routers to differentiate between packets of different importance. Queuing was split into two parts: n
The hardware queue that still uses FIFO strategy, which is necessary for the interface drivers to transmit packets one by one. The hardware queue is sometimes referred to as the transmit queue or TxQ.
n
The software queue that schedules packets into the hardware queue based on the QoS requirements
Listed on the previous graphic are some of the available software queuing strategies with their goals:
3-4
Queuing Mechanisms
n
FIFO: no differentiation of packets (true fairness but no guarantees)
n
Priority Queuing (PQ): strict prioritizing of packets
n
Custom Queuing (CQ): service (bandwidth) guaranteed to up to 16 classes
n
Weighted Fair Queuing (WFQ) and Distributed WFQ: service (bandwidth) guarantee to individual flows
n
Distributed ToS-based WFQ: service (bandwidth) guaranteed to up to 4 classes
Copyright 2001, Cisco Systems, Inc.
n
Distributed QoS-group-based WFQ: service (bandwidth) guaranteed to up to 100 classes
n
Modified Deficit Round-robin (MDRR): service (bandwidth) guaranteed to up to 8 classes; low-delay guarantee if Strict or Alternate Priority is used
n
IP RTP Prioritization: low-delay guarantee
Most queuing mechanisms depend on the availability on different platforms and Cisco IOS versions. For example: n
MDRR is only available on Cisco 12000 series routers (GSR)
n
Distributed ToS-based and QoS-group-based WFQ are only available on Cisco 7x00 series routers with Versatile Interface Processors (VIP)
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-5
Bypassing the Software Queue
Software Queue Empty?
No
Yes
Hardware Queue Full?
Hardware Queue (TxQ)
No
Yes
Software Queuing System
• When a packet is being forwarded the router will bypass the software queue if:
– the software queue is empty and – the hardware queue is not full © 2001, Cisco Systems, Inc.
Queuing Mechanisms -7
The implementation of software queuing was optimized for periods when the interface is not congested. The software queuing system is bypassed whenever there is no packet in the software queue and there is room in the hardware queue. The software queue is, therefore, only used when data must wait to be placed into the hardware queue.
3-6
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Hardware Queue (TxQ) Size • Routers determine the length of the hardware queue based on the configured bandwidth of the interface • Long TxQ may result in poor performance of the software queue • Short TxQ may result in a large number of interrupts which causes high CPU utilization and low link utilization
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -8
The double queuing strategy (software and hardware queue) has its impacts on the result of overall queuing: n
Software queue is used for a certain reason. If the hardware queue is too long it will contain a large number of packets scheduled in the FIFO fashion. This is probably against the QoS design that required a certain complex software queuing system (for example, Custom Queuing).
So why use the hardware queue at all? Or why not just set its length to one? That would force all packets to go through the software queue and be scheduled one by one to the interface for transmission. This approach has the following drawbacks: n
Each time a packet is transmitted, the interface driver interrupts the CPU and requests more packets to be delivered into its hardware queue. Some queuing mechanisms have complex scheduling that takes time to deliver more packets. The interface does not send anything during that time (link utilization is decreased) if the hardware queue is empty because its maximum size is one.
n
The CPU schedules packets one by one instead of many at the same time (in the same interrupt interval). This increases the CPU utilization.
Choosing the appropriate length of the hardware queue is very important. The default TxQ size is determined by the IOS based on the bandwidth of the media and should be fine for most queuing implementations. Faster interfaces have longer hardware queues because they produce less delay. Slower interfaces have shorter hardware queues to prevent too much delay in the worst-case scenario where the entire hardware queue is full of MTU-sized packets.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-7
Queuing Components Forwarded Packets Software Queuing System Class 1?
Add/Drop
Queue 1
Class 2?
Add/Drop
Queue 2
Hardware Queuing System Scheduler
Class n?
Add/Drop
Hardware Q
Interface
Queue n
• Each queuing mechanism has three main components that define it: – Classification (selecting the class) – Insertion policy (determining whether a packet can be enqueued) – Service policy (scheduling packets to be put into the hardware queue) © 2001, Cisco Systems, Inc.
Queuing Mechanisms -9
The figure illustrates the actions that have to be taken before a packet can be transmitted: n
Most queuing mechanisms include classification of packets.
n
Once a packet is classifie d, a router has to determine whether it can put the packet into the queue or it has to drop the packet. Most queuing mechanisms will drop a packet only if the corresponding queue is full (tail-drop). Some mechanisms use a more intelligent dropping scheme (Weighted Fair Queuing) or a random dropping scheme (Weighted Random Early Detection).
n
If the packet is allowed to be enqueued it will be put into the FIFO queue for that particular class.
n
Packets are then taken from the individual per-class queues and put into the hardware queue.
Queuing systems differ in the following ways:
3-8
Queuing Mechanisms
n
Classification options: some mechanisms classify packets automatically (for example, WFQ), while other mechanisms require manual configuration of classification (for example, PQ or CQ).
n
Insertion policy: most queuing mechanisms use the tail-dropping scheme.
n
Scheduling policy: this is the most important part of every queuing mechanism because it determines the order in which the packets will leave the router.
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Understand how queuing works on Cisco routers
n
List the most used queuing mechanisms
Review Questions Answer the following questions: n
Which queuing mechanisms do Cisco routers support?
n
When is a software queuing mechanisms not used?
n
How does TxQ length affect the software queuing system?
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-9
FIFO Queuing Objectives Upon completion of this lesson, you will be able to perform the following tasks:
3-10
Queuing Mechanisms
n
Describe FIFO queuing
n
Describe the drawbacks of FIFO queuing
n
Configure FIFO queuing on Cisco routers
n
Monitor and troubleshoot FIFO queuing
Copyright 2001, Cisco Systems, Inc.
FIFO Queuing Forwarded Packets FIFO Queuing System
All in one queue
Tail-drop
Queue 1
Hardware Queuing System FIFO Scheduler
Hardware Q
Interface
Routers serve packets in the first-come first-serve fashion FIFO uses one single queue
All packets are classified into one class
Newly arriving packets are dropped if the queue is full
• Software FIFO queue is basically an extension to the hardware FIFO queue © 2001, Cisco Systems, Inc.
Queuing Mechanisms-14
FIFO queuing has no classification because all packets belong to the same class. Packets are dropped when the output queue is full (tail-drop). The scheduler services packets in the order they arrived. Software FIFO queue is basically an extension of the hardware FIFO queue.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-11
Benefits and Drawbacks of FIFO Queuing + Benefits • Simple and fast (one single queue with a simple scheduling mechanism) • Supported on all platforms • Supported in all switching paths • Supported in all IOS versions
– Drawbacks • Unfair allocation of bandwidth among multiple flows • Causes starvation (aggressive flows can monopolize links) • Causes jitter (bursts or packet trains temporarily fill the queue) © 2001, Cisco Systems, Inc.
Queuing Mechanisms-15
FIFO queuing might be regarded as the fairest queuing mechanism but it has a long list of drawbacks: n
FIFO does not fairly allocate bandwidth among multiple flows. Some flows receive more bandwidth because they use larger packets or send more packets.
n
FIFO is extremely unfair when an aggressive flow is contesting with a fragile flow. Aggressive flows send a large number of packets, many of which are dropped. Fragile flows send a modest amount of packets and most of them are dropped because the queue is always full due to the aggressive flow. This type of behavior is called starvation.
n
Short or long bursts cause a FIFO queue to fill. Packets entering an almost full queue have to wait a long time before they can be transmitted. Another time, the queue might be empty causing packets of the same flow to experience almost no delay. Variation in delay is called jitter.
In spite of all the drawbacks FIFO is still the most used queuing mechanism because of the following benefits:
3-12
Queuing Mechanisms
n
It is simple and fast. Most high-end routers with fast interfaces are not really challenged by the drawbacks mentioned earlier. Furthermore, routers are not capable of complex classification and scheduling when they have to process a large number of packets per second. FIFO is, therefore, the most suitable queuing mechanisms on these platforms.
n
It is supported on all platforms.
n
It is supported in all IOS versions.
Copyright 2001, Cisco Systems, Inc.
Configuring FIFO Queuing Router(config-if)#
no fair-queue fair-queue
• FIFO queuing is enabled by default on all interfaces that have a default bandwidth of more than 2Mbsp • Weighted Fair Queuing is enabled if the bandwidth is less than 2Mbps • Disable WFQ to enable FIFO on interfaces that have less than 2Mbps of bandwidth
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-16
Cisco routers have two default queuing mechanisms: n
All interfaces with the default bandwidth above 2Mbps use FIFO queuing. No configuration is necessary on such interfaces.
n
All interfaces with the default bandwidth below 2Mbps use Weighted Fair Queuing (WFQ). The no fair-queue command must be used to disable WFQ and enable FIFO.
There is no special command that specifically enables FIFO.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-13
Configuring FIFO Queuing Router(config-if)#
hold-queue
• FIFO queuing allows a maximum of 40 packets to be stored in the output queue • This command can be used to increase or decrease the maximum number of buffered packets • A large value can be set to support longer bursts (less drops, more buffer usage) • A small value can be set to prevent bursts (more drops)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-17
One of the considerations when using FIFO queuing is the maximum burst size. Routers allow (by default) up to 40 packets to be in the output queue. Shortening the queue causes more drops, especially for bursty sessions. Lengthening the queue allows more packets to be enqueued. A long queue should be used to allow bursts without drops. The hold-queue command is used to set the maximum number of packets in the output queue.
3-14
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
FIFO Example The Ethernet interface has a default bandwidth of 10Mbps. FIFO is the default queuing and it does not need to be configured.
interface interface Ethernet0/0 ip ip address address 1.1.1.1 1.1.1.1 255.0.0.0 255.0.0.0 !! interface interface Serial0/0 Serial0/0 ip ip address address 2.2.2.2 2.2.2.2 255.0.0.0 255.0.0.0 no no fair-queue fair-queue hold-queue hold-queue 50 50 out out !!
© 2001, Cisco Systems, Inc.
The serial interface (A/S) has a default bandwidth of 128 kbps. WFQ is the default queuing and it has to be disabled to enable FIFO queuing. Up to 50 frames are allowed to be enqueued before the router will start tail-dropping newely arriving packets.
Queuing Mechanisms-18
The example shows how FIFO can be enabled on an interface that uses WFQ by default. The serial interface in question has the default bandwidth of 128 kbps (below 2 Mbps). The ethernet interface has the default bandwidth of 10 Mbps (above 2 Mbps) and requires no configuration. The maximum output queue size was also slightly increased from the default 40 to 50.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-15
Monitoring and Troubleshooting FIFO Router#
show interface interface [
• The command displays information about the selected interface(s) Router#show Router#show interface interface Serial0/0 Serial0/0 The queue is currently empty ( 0/50). Serial0/0 Serial0/0 is is up, up, line line protocol protocol is is up up There can be a maximum of 50 frames in the Hardware Hardware is PowerQUICC Serial queue (0/50). Internet Internet address is 1.1.1.1/8 MTU MTU 1500 1500 bytes, bytes, BW BW 128 128 Kbit, Kbit, DLY DLY 20000 20000 usec, usec, reliability reliability 255/255, 255/255, txload txload 1/255, 1/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation HDLC, HDLC, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) FIFO queuing is enabled Last Last input input 00:00:02, 00:00:02, output 00:00:04, output hang neveron an interface with the default bandwidth of Last Last clearing clearing of "show "show interface" interface" counters never 128kbps. Queueing Queueing strategy: strategy: fifo fifo Output Output queue queue 0/50, 0/50, 00 drops; drops; input input queue queue 0/75, 0 drops 55 minute minute input input rate rate 00 bits/sec, bits/sec, 00 packets/sec packets/sec 55 minute 0 bits/sec, bits/sec, 0 0 packets/sec packets/sec minute output output rate rate 0 …… © 2001, Cisco Systems, Inc.
Queuing Mechanisms-19
FIFO queuing is not supported by a large arsenal of show and debug commands. The show interface command can be used to determine the queuing strategy of an interface and to display the following statistics:
3-16
Queuing Mechanisms
n
The current queue size (buffer usage)
n
The maximum queue size (default 40 or whatever is configured with the hold-queue out command)
Copyright 2001, Cisco Systems, Inc.
Summary FIFO queuing is the oldest queuing mechanism in the Cisco IOS. It is used on fast interfaces because of its simplicity and speed. FIFO produces undesirable behavior on congested (low-speed) interfaces that manifest itself as: n
Unfair allocation of bandwidth
n
Starvation of less-aggressive flows
n
Delay
n
Jitter
FIFO is the default queuing mechanism on all interfaces that have the default bandwidth of more than 2 Mbps. FIFO queuing can be enabled on interfaces with the default bandwidth of 2 Mbps or less by disabling WFQ.
Review Questions Answer the following questions: n
Why is FIFO the fastest queuing mechanism?
n
Describe the classification and scheduling of FIFO queuing.
n
List the drawbacks of FIFO queuing.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-17
Priority Queuing Objectives Upon completion of this lesson, you will be able to perform the following tasks:
3-18
Queuing Mechanisms
n
Describe Priority Queuing
n
Describe the benefits and drawbacks of Priority Queuing
n
Configure Priority Queuing on Cisco routers
n
Monitor and troubleshoot Priority Queuing
Copyright 2001, Cisco Systems, Inc.
Priority Queuing Forwarded Packets Priority Queuing System
High?
Tail-drop
Queue 1
Medium?
Tail-drop
Queue 2
Hardware Queuing System Pre-emptive Scheduler
Normal?
Tail-drop
Queue 3
Low?
Tail-drop
Queue 4
Hardware Q
Interface
• Priority Queuing (PQ) uses four FIFO queues © 2001, Cisco Systems, Inc.
Queuing Mechanisms-24
Priority Queuing (PQ) is one of the first mechanisms that allowed classification of packets into multiple classes. Scheduling is done in strict priority. PQ can classify packets into one of the four queues: n
High queue
n
Medium queue
n
Normal queue (the default queue)
n
Low queue
Scheduling prefers packets in the same order. Each class uses one FIFO queue, where packets are dropped if a queue is full.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-19
Priority Queuing Classification • Priority Queuing classification for IP supports the following options: – Source interface – IP access list (standard and extended) – Packet size (greater or smaller than specified) – Fragments – TCP source or destination port numbers – UDP source or destination port numbers
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-25
Priority Queuing can classify IP packets with the following tools:
3-20
Queuing Mechanisms
n
Direct matching on the source interface.
n
Standard or extended IP Access list. Extended IP access lists support matching on the following parameters: –
Source IP address
–
Destination IP address
–
Source TCP or UDP port number or port range
–
Destination TCP or UDP port number or port range
–
IP precedence (high-order three bits of the ToS field)
–
DSCP (high-order six bits of the ToS field)
–
ToS value (bits one through four of the ToS field)
–
Fragments
–
TCP flags (ACK, SYN, RST, URG, PSH)
n
Direct matching of TCP or UDP source and destination port numbers.
n
Direct matching of fragments.
n
Direct matching of packets based on their size.
Copyright 2001, Cisco Systems, Inc.
Priority Queuing Classification • Priority Queuing also supports classification of other protocols with the following options: – Protocol-specific access list (if available for the specified protocol) – Packet size (greater or smaller than specified) • Some of the supported protocols are: – IPX – CLNS – DECNET – AppleTalk – VINES – DLSw
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-26
Priority Queuing is a multi-protocol QoS mechanism because it supports classification tools for other (non-IP) protocols. The figure lists the match options for some of the supported Layer-3 protocols as well as other higher-layer protocols. Although other protocols are supported, the classification options are not as powerful as with IP. Most protocols can use their corresponding access lists to classify packets. Matching on packet size is also available with all supported protocols.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-21
Priority Queuing Insertion Policy • Each queue has a maximum number of packets that it can hold (queue size). • After a packet is classified to one of the following queues the router will enqueue the packet if the queue limit has not been reached (tail-drop within each class).
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-27
Priority Queuing is basically a collection of four parallel FIFO queues. Each queue suffers from all FIFO problems isolated to the class (unfair, starvation, delay, jitter). Each queue uses the tail-drop scheme when the queue is full. Each of the four queues can be configured with the maximum number of packets that it can hold.
3-22
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Priority Queuing Scheduling
Packet in HIGH queue? Yes
No
Packet in MEDIUM queue? Yes
No
Packet in NORMAL queue? Yes
No
Packet in LOW queue? Yes
© 2001, Cisco Systems, Inc.
No
Dispatch Packet And start checking the HIGH queue again
Hardware Q
Queuing Mechanisms-28
Priority Queuing uses strict priority scheduling. As long as there are packets in the high queue no other queue will be served. If the high queue is empty the router starts serving the medium queue. Congestion in any of the queues, except the low queue, causes a different type of starvation. A congested higher-priority queue causes all lower-priority queues to starve (class starvation).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-23
Benefits and Drawbacks of Priority Queuing + Benefits • Provides low-delay propagation to high-priority packets • Supported on most platforms • Supported in all IOS versions (above 10.0)
– Drawbacks • All drawbacks of FIFO queuing within a single class • Starvation of lower -priority classes when higherpriority classes are congested • Manual configuration of classification on every hop
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-29
As mentioned previously, Priority Queuing suffers from the same drawbacks as FIFO queuing, except it is localized to four classes. Each class can experience starvation, delay and jitter if one or more flows in the class cause congestion. Furthermore, one higher-priority queue can cause all other queues to starve if it is congested. Priority Queuing requires manual configuration of classification. The main benefit of PQ is that it enables the user to create a class that is used for applications that require low delay (high queue).
3-24
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Priority Queuing • Configure priority lists –Configure classification –Select a queue –Set maximum queue size • Apply the priority list to outbound traffic on an interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-30
The configuration of Priority Queuing can be split into the following four steps: 1. Classify data into four classes 2. Assign a queue to each class 3. Set the maximum queue size (if the default is not appropriate) 4. Apply the priority queuing system to one or more interfaces
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-25
Priority Queuing Classification Router(config)# priority-list list-number list-number protocol protocol-name {high|medium|normal|low} queue-keyword keyword-value
• Selects the queue based on layer-3 protocol • Additional classification (queue-keyword): – fragment (IP packets with non-zero fragment offset) – gt/lt <size>: based on packet size (including L2 frame) – list
Queuing Mechanisms -31
The first three configuration steps are achieved using the priority-list command. A Priority Queuing system is identified with a common number (list-number). Priority Queuing supports the following direct classification options of IP packets: 1. Match fragments 2. Match packets based on their size 3. Match packets based on their source or destination TCP/UDP port number A far more powerful classification tool is an access list (standard or extended).
3-26
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Priority Queuing Classification Router(config)# priority-list list-number interface intf {high|medium|normal|low} {high|medium|normal|low}
• Classifies the packet based on incoming interface Router(config)# priority-list list-number default default {high|medium|normal|low}
• Classifies all unclassified packets in a default queue
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-32
Additionally, PQ supports classification based on source interface. By default, all traffic not specifically classified goes into the normal queue. This behavior can be changed by using the priority-list default command. Note
The priority-list commands are evaluated in the order they were entered. This is especially important when overlapping classification is configured for separate queues. For example: Line 1: all IP traffic goes into the high priority queue Line 2: all TCP traffic goes into the medium queue The medium queue in this example would never g et any packets because it appears second in the configuration and it is a subset of the first line.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-27
Priority Queuing Scheduling and Dropping Parameters Router(config)# priority-list list-number queue-limit high medium normal low low
• Specifies the maximum queue sizes of individual priority queues Router(config-if)# priority-group list
• Assigns Priority Queuing definition to an interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-33
Priority Queuing uses the following default maximum queue sizes for the four queues: n
High queue has a default queue limit of 20
n
Medium queue has a default queue limit of 40
n
Normal queue has a default queue limit of 60
n
Low queue has a default queue limit of 80
The last configuration step is to apply a priority-list to an interface. Use the priority-group command with a corresponding priority-list number to enable Priority Queuing on an interface.
3-28
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Sample PQ Configuration
E0
WAN core
E1
interface interface serial0 serial0 Branch priority-group priority-group 1
Core
office priority-list priority-list priority-list priority-list priority-list priority-list priority-list priority-list
1 1 1 1
protocol protocol ip high list 101 interface interface ethernet ethernet 00 medium medium default normal queue-limit 20 40 60 80
access-list access-list 101 101 permit permit tcp tcp any any any any eq 23
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-34
The figure illustrates a simple example where outbound traffic is classified into the following three classes: 1. All outbound telnet sessions (access list 101) are using the high priority queue 2. All traffic coming into the router via interface Ethernet 0 is forwarded through the medium queue 3. All other traffic is using the default normal queue
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-29
Monitoring Priority Queuing Router# show interface interface interface
• Displays information and statistics about queuing on interface Router# show queueing [priority|custom|fair|random-detect] interface
• Displays queuing parameters on interfaces Router# show queue queue interface interface
• Displays queue contents © 2001, Cisco Systems, Inc.
Queuing Mechanisms-35
The show interface command can be used to determine the queuing strategy of an interface. If the queuing strategy is PQ some statistics are also displayed. The show queueing priority command can be used to display all non-default parameters of priority lists. Note
3-30
Queuing Mechanisms
To use the show queueing command, you must enter at least the first six characters to differentiate the command (show queuei vs. show queue).
Copyright 2001, Cisco Systems, Inc.
Show Interface Router#show Router#show interface interface serial serial 1/0 1/0 Serial1/0 Serial1/0 is is up, up, line line protocol protocol is is up up Hardware Hardware is is M4T M4T Internet Internet address address is is 20.0.0.1/8 20.0.0.1/8 MTU MTU 1500 1500 bytes, bytes, BW BW 19 19 Kbit, Kbit, DLY DLY 20000 20000 usec, usec, rely rely 255/255, 255/255, load load 93/255 93/255 Encapsulation Encapsulation HDLC, HDLC, crc crc 16, 16, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) Last Last input input 00:00:00, 00:00:00, output output 00:00:00, 00:00:00, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0 0/75/0 (size/max/drops); (size/max/drops); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: priority-list priority-list 11 Output Output queue queue (queue (queue priority: priority: size/max/drops): size/max/drops): high: high: 0/20/0, 0/20/0, medium: medium: 0/40/0, 0/40/0, normal: normal: 0/60/0, 0/60/0, low: low: 0/80/0 0/80/0 55 minute minute input input rate rate 18000 18000 bits/sec, bits/sec, 88 packets/sec packets/sec 55 minute minute output output rate rate 7000 7000 bits/sec, bits/sec, 88 packets/sec packets/sec …… rest rest ignored ignored ... ...
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-36
The show interface command displays the parameters and the statistics of all four priority queues. The first parameter is the current size of the queue, the second is the maximum allowed size of the queue and the third parameter is the number of drops since the last clearing of counters.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-31
Show Queuing Priority
Router#show Router#show queueing queueing priority Current Current priority priority queue queue configuration: configuration: List List 11 11
Queue Args Args high protocol ip list 101 high medium medium interface interface Ethernet6/0
• The “show queueing priority” command displays only the non-default parameters
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-37
The show queueing priority command lists all non-default parameters. The figure shows the two parameters: n
All packets permitted by access list 101 go into the high queue
n
All packets coming from interface Ethernet6/0 go into the medium queue
The commands that set default parameters are not displayed, either in the running configuration or by using this command.
3-32
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Summary Priority Queuing uses four FIFO queues. Strict priority queuing is used. Starvation within a single class or starvation of lower-priority classes is possible when one flow congests a higher-priority queue. Priority queuing can be used to guarantee all the bandwidth and low-delay propagation.
Review Questions Answer the following questions: n
When would you use priority queuing?
n
What are the benefits and drawbacks of priority queuing?
n
How many classes does priority queuing support?
n
How does priority queuing schedule packets?
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-33
Custom Queuing Objectives Upon completion of this lesson, you will be able to perform the following tasks:
3-34
Queuing Mechanisms
n
Describe Custom Queuing
n
Describe the benefits and drawbacks of Custom Queuing
n
Configure Custom Queuing on Cisco routers
n
Monitor and troubleshoot Custom Queuing
Copyright 2001, Cisco Systems, Inc.
Custom Queuing Forwarded Packets Custom Queuing System
Class 1?
Tail-drop
Queue 1
Class 2?
Tail-drop
Queue 2
Hardware Queuing System Round Robin Scheduler
Class 16?
Tail-drop
Hardware Q
Interface
Queue 16
• Custom Queuing (CQ) uses 16 FIFO queues for user defined traffic classes © 2001, Cisco Systems, Inc.
Queuing Mechanisms-42
Custom Queuing (CQ) is similar to Priority Queuing in the way it is configured and in the supported classification options. The scheduling, however, is completely different. CQ uses up to 16 queues that can be used for user-defined classes. The classification options are identical to those of Priority Queuing. The scheduling mechanism uses the round-robin service where each queue is allowed to forward a certain number of bytes (not packets). Tail-drop is still used within each individual queue.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-35
Custom Queuing Classification • Custom Queuing classification for IP supports the following options: – Source interface – IP access list (standard and extended) – Packet size (greater or smaller than specified) – Fragments – TCP source or destination port numbers – UDP source or destination port numbers • Custom Queuing classification is identical to that of Priority Queuing
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-43
Custom Queuing (similar to Priority Queuing) can classify IP packets with the following tools:
3-36
Queuing Mechanisms
n
Direct matching on the source interface.
n
Standard or extended IP Access list. Extended IP access lists support matching on the following parameters: –
Source IP address
–
Destination IP address
–
Source TCP or UDP port number or port range
–
Destination TCP or UDP port number or port range
–
IP precedence (high-order three bits of the ToS field)
–
DSCP (high-order six bits of the ToS field)
–
ToS value (bits one through four of the ToS field)
–
Fragments
–
TCP flags (ACK, SYN, RST, URG, PSH)
n
Direct matching of TCP or UDP source and destination port numbers.
n
Direct matching of fragments.
n
Direct matching of packets based on their size.
Copyright 2001, Cisco Systems, Inc.
Custom Queuing Insertion Policy • Each queue has a maximum number of packets that it can hold (queue size). • After a packet is classified to one of the following queues the router will enqueue the packet if the queue limit has not been reached (tail-drop within each class).
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-44
Once the packet is classified a router has to determine if the packet can be enqueued. The packet is dropped if the queue is full. Each queue, unless configured otherwise, can buffer up to 20 packets before the first packet is dropped.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-37
Custom Queuing Scheduling No Packet in Queue N?
No
Next Queue (increase N)
Yes
Is Queue N over the threshold?
Yes
Dispatch Packet
Hardware Q
• Custom Queuing uses round-robin service policy • Each queue is allowed to forward a configurable amount of bytes (threshold) in one round © 2001, Cisco Systems, Inc.
Queuing Mechanisms-45
Custom Queuing uses round-robin scheduling, where each queue gets some service (bandwidth). Each queue is configured with the number of bytes (byte-count) it can send in one round. The last packet is always sent, even if the total amount of bytes sent in one round is above the limit (byte-count). The router then starts processing the next queue.
3-38
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Custom Queuing Scheduling Parameters 1500
1499
1500
Threshold (byte-count) = 3000 Up to 4499 bytes can be forwarded in one round in the worst case
• The threshold (byte count) parameter specifies the lower boundary on how many bytes the system allows to be delivered from a given queue during a particular cycle • The router is allowed to send the entire packet even if the sum of all bytes is more than the threshold © 2001, Cisco Systems, Inc.
Queuing Mechanisms-46
The figure illustrates the worst case scenario where the following parameters were used to implement Custom Queuing on an interface: n
MTU of the interface is 1500 bytes
n
Byte-count is 3000 (twice the MTU)
The example shows how the router first sent two packets with a total size of 2999 bytes. Since this is still within the limit (3000) the router can send the next packet (MTU-sized). The result was that the queue received almost 50% more bandwidth in this round than it should. This is one of the drawbacks of Custom Queuing – it does not allocate bandwidth accurately.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-39
CQ Design Guideline • Configure the amount to remove from a queue in each round to configure the proportional “weight” of the queue • Amounts to remove should approximate a small multiple of the interface’s MTU • Ratio between largest and smallest queue should be a small positive integer, not more than 10:1
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-47
The limit or weight of the queue is configured in bytes. The accuracy of Custom Queuing depends on the weight (byte-count) and the MTU. If the ratio between the byte-count and the MTU is too small CQ will not allocate bandwidth accurately. If the ratio between the byte-count and the MTU is too large CQ will cause long delays. This problem is discussed in detail on the next two pages.
3-40
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Delay vs. Bandwidth Allocation Queue 1 5999
4500 Queue 2 4499
3000
Round Robin Scheduler
64 kbps MTU=1500
Queue 3 2999
1500
BW BW (Queue 1) == bc1/(bc1+bc2+bc3) bc1/(bc1+bc2+bc3) == 4500/9000 == 50% Delay Delay (Queue (Queue 1) 1) = (bc2+bc3)/Bandwidth = 562ms
Worst-case Worst-case Delay Delay (Queue (Queue 1) = ((bc2+1499) +(bc3+1499))/Bandwidth +(bc3+1499))/Bandwidth == 937ms
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-48
The figure illustrates sample calculations of bandwidth guarantees and the maximum delay. The time it takes to complete a round depends on the bandwidth of the interface, the MTU size and the sum of all queue byte-counts. The case study parameters are: n
The first queue uses a byte-count of 4500 (three times the MTU)—5999 bytes can be sent in the worst case
n
The second queue uses a byte-count of 3000 (two times the MTU)—4499 bytes can be sent in the worst case
n
The third queue uses byte-count 1500 (MTU)—2999 bytes can be sent in the worst case
The first calculation shows that the first queue should receive approximately 50% of the bandwidth. The second calculation shows the round-robin delay of 562ms for Queue 1 when all classes are congested. The third calculation shows the round-robin delay of 937ms for Queue 1 when all classes are congested and manage to send the maximum number of bytes (byte-count + MTU - 1) in one round. Although this worst case is very unlikely it is also unlikely that classes will use the exact configured maximum.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-41
Worst-case Delay • MTU=1500, byte-count (4500, 3000, 1500) Max(delay)=(5999+4499)*8/64000=1312 ms • MTU=1000, byte-count (4500, 3000, 1500) Max(delay)=(5499+3999)*8/64000=1187 ms • MTU=250, byte-count (450, 300, 150) Max(delay)=(699+549)*8/64000=156 ms Expected delay=(500+500)*8/64000=125 ms Custom queuing is not appropriate for lowdelay environment. Changing MTU and bytecounts might be a workaround.
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-49
The figure shows several calculations where the worst-case maximum delay was reduced by reducing both the MTU and the byte-counts. Note
3-42
Queuing Mechanisms
The calculation merely shows the impact the MTU and the byte-count have on the delay. Lowering the MTU is not a recommended solution because it potentially increases the CPU utilization of the router due to fragmentation of packets.
Copyright 2001, Cisco Systems, Inc.
Benefits and Drawbacks of Custom Queuing + Benefits • Guarantees throughput to traffic classes (prevents starvation between traffic classes) • Supported on most platforms • Supported in all IOS versions (above 10.0)
– Drawbacks • • • •
All drawbacks of FIFO queuing within a single class Manual configuration of classification on every hop Not accurate bandwidth allocation High jitter due to implementation of scheduling
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-50
In addition to all the benefits and drawbacks of Priority Queuing, Custom Queuing can also guarantee bandwidth to up to 16 classes. Custom Queuing can cause all queues to experience delay due to the implementation of scheduling (one round can take a long time).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-43
Custom Queuing Classification Router(config)# queue-list list-number protocol protocol-name protocol-name queue-number queue-number queue-keyword keyword-value
• Classifies the packet into a custom queue based on protocol and other protocol-specific criteria • Selection criteria identical to priority queuing Router(config)# queue-list list-number interface incoming-intf queue-number queue-number
• Classifies the packet into a custom queue based on incoming interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-51
Custom queuing uses the same classification options as Priority Queuing. Instead of using names queues are numbered (1 to 16).
3-44
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Custom Queuing Classification Router(config)# queue-list list-number default default queue-number
• Classifies all unclassified packets into a default queue Router(config-if)# custom-queue list-number
• Starts custom queuing on an interface and assigns specified CQ definition to the interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-52
All traffic that is not specifically classified is put into Queue 1. n
Use the queue -list default command to change the default queue.
n
Use the custom-queue interface command to apply a queue-list to an interface.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-45
Custom Queuing Scheduling Parameters Router(config)# queue-list list queue queue queue-number byte-count bc
• Specifies the lower boundary on how many bytes the system allows to be delivered from a given queue during one round-robin cycle Default: 1500 bytes Router(config)# queue-list list queue queue queue-number limit limit
• Specifies the maximum number of packets in a queue • Incoming packets are tail-dropped if the limit is exceeded © 2001, Cisco Systems, Inc.
3-46
Queuing Mechanisms
Queuing Mechanisms-53
n
Use the byte-count option to change the default weight of a queue (default equals MTU size)
n
Use the limit option to change the number of packets that a queue can hold (default is 20)
Copyright 2001, Cisco Systems, Inc.
Custom Queuing with Preemptive Queues Forwarded Packets Custom Queuing has queue 0 for system and link-level messages which use pre-emptive scheduling
Custom Queuing System Class 0?
Tail-drop
Queue 0
Class 1?
Tail-drop
Queue 1
Class 2?
Tail-drop
Queue 2
Hardware Queuing System Pre -emptive Scheduler
Hardware Q
Intf
Round Robin Scheduler
Class 16?
© 2001, Cisco Systems, Inc.
Tail-drop
Queue 16
Queue 1 is the lowest custom queue that is serviced by the round robin scheduler
Queuing Mechanisms-54
Custom queuing has another queue—Queue 0. This queue is used for system packets (routing protocols, link-level messages). This queue is not served by the round-robin scheduler. Instead, a strict priority scheduler is used to prioritize packets from this queue.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-47
Custom Queuing with Preemptive Queues Forwarded Packets Custom Queuing System Class 0?
Tail-drop
Queue 0
Class 1?
Tail-drop
Queue 1
Class 2?
Tail-drop
Queue 2
Custom queues can be configured to use the pre -emptive scheduler
Hardware Queuing System Pre -emptive Scheduler
Round Robin Scheduler
Class 16?
© 2001, Cisco Systems, Inc.
Tail-drop
Hardware Q
Intf
Queue 2 is now the lowest custom queue that is serviced by the round robin scheduler
Queue 16
Queuing Mechanisms-55
The strict priority scheduler can be extended to other queues that are normally served by the round-robin scheduler. The figure illustrates how Queue 1 was moved into the priority-scheduled part of the Custom Queuing system. The delimiter can be set to any queue by specifying the lowest custom queue (Queue 2 in this example). In fact, Custom Queuing can be turned into Priority Queuing with 17 queues if Queue 16 is selected as the lowest custom queue.
3-48
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Custom Queuing Scheduling Parameters Router(config)# queue-list list-number lowest-custom queue-number queue-number
• Set the lowest queue to be treated as custom queue • Queues below the specified queue are pre-emptive priority queues (Q1 having highest priority) • Queue 0 is always treated as pre-emptive – System and link-level messages are classified in Q0 by default
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-56
Use the lowest-custom option to achieve the following: n
All queues from Queue 0 to the queue before the one specified in the command use priority queuing (Queue 0 has the highest priority)
n
All queues from the one specified in the command to Queue 16 use the round-robin scheduler
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-49
Custom Queuing Example
E0
WAN core
E1
Branch office
interface interface serial 1/0 1/0 Core custom-queue-list 5 !! queue-list queue-list 55 protocol protocol ip ip 11 list list 101 101 queue-list queue-list 5 queue 1 limit 40 queue-list queue-list 5 lowest-custom lowest-custom 22 queue-list queue-list 5 interface interface ethernet ethernet 0/0 0/0 22 queue-list queue-list 55 queue queue 22 byte-count byte-count 3000 queue-list queue-list 5 protocol ip 3 queue-list queue-list 55 queue queue 33 byte-count byte-count 5000 queue-list queue-list 5 default default 4 !! access-list access-list 101 permit permit ip any any precedence precedence 5
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-57
The figure shows a sample configuration where four queues are used:
3-50
Queuing Mechanisms
n
Queue 1 is used for delay-sensitive applications (marked with IP precedence 5). It uses the strict priority scheduler.
n
Queue 2 is used for all packets coming from interface Ethernet0/0.
n
Queue 3 is used for all IP packets that do not end in one of the first two queues.
n
Queue 4 is used for all other traffic.
Copyright 2001, Cisco Systems, Inc.
Custom Queuing - Show Interface Router#show Router#show interface interface serial serial 1/0 1/0 Serial1/0 Serial1/0 is is up, up, line line protocol protocol is is up up Hardware Hardware is is M4T M4T Internet Internet address address is is 20.0.0.1/8 20.0.0.1/8 MTU MTU 1500 1500 bytes, bytes, BW BW 19 19 Kbit, Kbit, DLY DLY 20000 20000 usec, usec, rely rely 255/255, 255/255, load load 107/255 107/255 Encapsulation Encapsulation HDLC, HDLC, crc crc 16, 16, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) Last Last input input 00:00:00, 00:00:00, output output 00:00:00, 00:00:00, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0 0/75/0 (size/max/drops); (size/max/drops); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: custom-list custom-list 55 Output Output queues: queues: (queue (queue #: #: size/max/drops) size/max/drops) 0: 0: 0/20/0 0/20/0 1: 1: 0/40/0 0/40/0 2: 2: 0/20/0 0/20/0 3: 3: 0/20/0 0/20/0 4: 4: 0/20/0 0/20/0 5: 5: 0/20/0 0/20/0 6: 6: 0/20/0 0/20/0 7: 7: 0/20/0 0/20/0 8: 8: 0/20/0 0/20/0 9: 9: 0/20/0 0/20/0 10: 10: 0/20/0 0/20/0 11: 11: 0/20/0 0/20/0 12: 12: 0/20/0 0/20/0 13: 13: 0/20/0 0/20/0 14: 14: 0/20/0 0/20/0 15: 15: 0/20/0 0/20/0 16: 16: 0/20/0 0/20/0 …… rest rest ignored ignored ... ...
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-58
The show interface command is used to determine the queuing strategy of an interface. If custom queuing is used on an interface the following information is also displayed: n
The number of the queue-list
n
Statistics for each of the 17 queues:
Copyright 2001, Cisco Systems, Inc.
–
Current size
–
Maximum size
–
Total number of drops since the last clearing of counters
Queuing Mechanisms
3-51
Show Queueing Custom Router#show Router#show queueing queueing custom Current Current custom custom queue queue configuration: List List 55 55 55 55 55
Queue 33 11 22 11 22
Args Args default default protocol protocol ip ip list 101 interface interface Ethernet0/0 byte-count byte-count 3000 limit 40 byte-count byte-count 5000
• The “show queueing custom” command displays only the non-default parameters © 2001, Cisco Systems, Inc.
Queuing Mechanisms-59
The show queueing custom command can be used to display all non-default parameters of Custom Queuing.
3-52
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Summary Custom Queuing introduces a scheduler that can guarantee bandwidth to 16 classes. In addition to the round-robin scheduling between 16 classes, a number of classes can be switched to priority scheduling.
Review Questions Answer the following questions: n
When would you use custom queuing?
n
What are the benefits and drawbacks of custom queuing?
n
How many classes does custom queuing support?
n
How does custom queuing schedule packets?
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-53
Weighted Fair Queuing Objectives Upon completion of this lesson, you will be able to perform the following tasks:
3-54
Queuing Mechanisms
n
Describe WFQ
n
Describe the benefits and drawbacks of WFQ
n
Configure WFQ on Cisco routers
n
Monitor and troubleshoot WFQ
Copyright 2001, Cisco Systems, Inc.
Weighted Fair Queuing • Queuing algorithm should fairly share the bandwidth among flows by: – reducing response time for interactive flows by scheduling them to the front of the queue – preventing high volume conversations from monopolizing an interface • Implementation: Messages are sorted into conversations (flows) and transmitted by the order of the last bit crossing its channel • Unfairness is reinstated by introducing “weight” (IP precedence) to give proportionately more bandwidth to flows with higher weight
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-64
Weighted Fair Queuing (WFQ) was introduced as a solution to the problems of the following queuing mechanisms: n
FIFO queuing causes starvation, delay and jitter
n
PQ causes starvation of other lower-priority classes and suffers from all FIFO problems within each of the four queues
n
CQ causes long delays and also suffers from all FIFO problems within each of the 16 queues
The idea of WFQ is to: n
Have a dedicated queue for each flow (no starvation, delay or jitter within the queue)
n
Fairly and accurately allocate bandwidth among all flows (minimum scheduling delay, guaranteed service)
n
Use IP precedence as weight when allocating bandwidth
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-55
Weighted Fair Queuing Forwarded Packets Weighted Fair Queuing System
Flow 1?
WFQ-drop
Queue 1
Flow 2?
WFQ-drop
Queue 2
Hardware Queuing System WFQ Scheduler
Flow N?
WFQ-drop
Hardware Q
Interface
Queue N
• WFQ uses per-flow FIFO queues © 2001, Cisco Systems, Inc.
3-56
Queuing Mechanisms
Queuing Mechanisms-65
n
WFQ uses automatic classification. Manually defined classes are not supported.
n
WFQ dropping is not a simple tail-drop. WFQ drops packets of the most aggressive flows.
n
WFQ scheduler is a simulation of a TDM system (time-division multiplexer). The bandwidth is equally distributed to all active flows.
Copyright 2001, Cisco Systems, Inc.
Weighted Fair Queuing Implementations • Implementation parameters –Queuing platform: central CPU or VIP –Classification mechanism –Weighted fairness • Modified Tail-Drop within each queue
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-66
WFQ is supported on most Cisco routers as well as Versatile Interface Processors (VIP). The implementation on the VIP slightly differs from the one discussed in this lesson. n
Classification identifies a flow and assigns a queue to the flow
n
Weight is used for scheduling to give proportionately more bandwidth to flows with a higher IP precedence
n
Tail-dropping scheme is improved to drop packets of the most aggressive flows
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-57
WFQ Classification IP
TCP
Src. Dst. Proto. Addr. Addr.
ToS
Payload
Src. Port
Dst. Port
Hash Algorithm
WFQ Classification uses the following parameters: • source IP address • destination IP address • source TCP or UDP port • destination TCP or UDP port • transport protocol • type of service (ToS) field A hash algorithm is used to produce the index of the queue where the packet is enqueued
#queue (Index of the queue)
• Packets of the same flow end up in the same queue • ToS field is the only parameter that might change causing packets of the same flow to end up in different queues © 2001, Cisco Systems, Inc.
Queuing Mechanisms-67
WFQ classification has to identify individual flows (the term conversation is also used to signify flows). A flow is identified based on the following information taken from the IP header and the TCP or UDP headers: n
Source IP address
n
Destination IP address
n
Protocol number (identifying TCP or UDP)
n
Type of Service Field
n
Source TCP/UDP port number
n
Destination TCP/UDP port number
All these parameters are usually fixed for a single flow, although there are some exceptions: n
A QoS design could mark packets with different IP precedence values even if they belong to the same flow. This kind of behavior should be avoided when using WFQ.
n
Some applications change port numbers (for example, TFTP).
If packets of the same flow do not have the same parameters (for example, a different ToS field) the packets can end up in different queues and reordering can occur. The parameters are used as input for a hash algorithm that produces a fixed-length number that is used as the index of the queue.
3-58
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
WFQ Classification Details • Fixed number of per-flow queues is configured • A hash function is used to translate flow parameters into queue number • System packets (8 queues) and RSVP flows (if configured) are mapped into separate queues • Two or more flows could map into the same queue, resulting in lower per-flow bandwidth • Important: the number of queues configured has to be larger than the expected number of flows
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-68
WFQ uses a fixed number of queues. The hash function is used to assign a queue to a flow. There are eight additional queues for system packets and optionally up to 1000 queues for RSVP flows. WFQ uses 256 queues by default. The number of queues can be configured in the range between 16 and 4096 (the number must be a power of 2). If there are a large number of concurrent flows it is very likely that two flows could end up in the same queue. It is recommended to have several times as many queues as there are flows (on the average). This may not be possible in larger environments where the number of concurrent flows is in thousands. The probability of two flows ending up in the same flow could be calculated using the following formula:
P =1−
Queues
Flows
Queues! ⋅ ( Queues − Flows)!
The following table lists the probability values for 3 sizes of the WFQ system (64, 128 and 256 queues), with the number of concurrent flows from 5 to 40. Flows 5 10 15 20 25 30 35 40
Copyright 2001, Cisco Systems, Inc.
64 queues 15% 52% 83% 96% 100% 100% 100% 100%
128 queues 8% 30% 57% 79% 92% 98% 99% 100%
256 queues 4% 16% 34% 53% 70% 83% 91% 96%
Queuing Mechanisms
3-59
WFQ Insertion and Drop Policy • WFQ has two modes of dropping: –Early dropping when the congestion discard threshold (CDT) is reached –Aggressive dropping when the hold-queue limit (HQO) is reached • WFQ always drops packets of the most aggressive flow
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-69
WFQ uses two parameters that affect the dropping of packets.
3-60
Queuing Mechanisms
n
The congestive discard threshold (CDT) is used to start dropping packets of the most aggressive flow, even before the hold-queue limit is reached.
n
The hold-queue limit defines the total maximum number of packets that can be in the WFQ system at any time.
Copyright 2001, Cisco Systems, Inc.
WFQ Insertion and Drop Policy N-th packet
N>HQO?
No
Yes Worst Finish Time?
No
Enqueue packet
Yes
Yes
No Drop the packet with the worst finish time (old) and enqueue the N-th packet (new)
N>CDT?
Worst Finish Time?
No
Yes Old
New
• HQO (hold-queue out limit) is the max . number of packets that the WFQ system can hold • CDT (congestive discard threshold) is the threshold when WFQ starts dropping packets of the most aggressive flow • N is the number of packets in the WFQ system when the N -th packet arrives
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-70
The figure illustrates the dropping scheme of WFQ. The process can be split into the following steps: Step 1
Drop the new packet if the WFQ system is full (hold-queue limit reached) and the new packet has the worst finish time (the last in the entire system).
Step 2
Drop the packet with the worst finish time in the WFQ system if the system is full. Enqueue the new packet.
Step 3
Drop the new packet if the queue, where the packet should be enqueued, is the longest (not in packets but in the finish time of the new packet) and there are more packets in the WFQ system than the CDT.
Step 4
Otherwise enqueue the new packet.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-61
Case Study • WFQ system can hold a maximum of ten packets (hold-queue limit) • Early dropping (of aggressive flows) should start when there are eight packets (congestive discard threshold) in the WFQ system
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-71
The following case study is used to describe how packets are dropped in different situations. The WFQ system was reduced to a modest hold-queue limit of ten and a congestive discard threshold of eight.
3-62
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Case Study Interface Congestion
• Absolute maximum (HQO=10) exceeded, new packet is the last in the TDM system and is dropped
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-72
There are already ten packets in the WFQ system. The new packet would be the eleventh and also the last in the entire WFQ system. The packet is dropped.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-63
Case Study Interface Congestion
• Absolute maximum exceeded (HQO=10), new packet is not the last in the TDM system, last packet is dropped
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-73
In this example there are also ten packets in the system when the eleventh packet arrives. The new packet, if enqueued, would not be the last in the system. The packet is therefore allowed to be enqueued and the last packet in the system is deleted.
3-64
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Case Study Flow Congestion
• CDT exceeded (CDT=8), new packet would be the last in the TDM system and is dropped
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-74
This example illustrates how WFQ can drop packets even if the WFQ system is still within the hold-queue limit. The system, however, is above the CDT limit. In this case a packet can be dropped if it is the last in the system.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-65
Case Study Flow Congestion
• CDT exceeded (CDT=8), new packet would not be the last. Packet is enqueued
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-75
This example is different from the previous one in that the new packet would not be the last in the WFQ system. The packet can be enqueued and no other packet is dropped.
3-66
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Drop Mechanism within WFQ Exceptions • Packet classified into an empty sub-queue is never dropped • The packet precedence has no effect on the dropping scheme
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-76
There is an exception to the CDT rule —if the WFQ system is above the CDT limit, and the new packet would be the last in the system, the packet is still enqueued if the flow queue is empty. The dropping strategy is not directly influenced by IP precedence.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-67
WFQ Scheduling • Each packet is tagged with its Finish time in a virtual TDM system • The scheduler selects the packets with the earliest finish time tag (thus the packet that leaves the virtual TDM the earliest) • Reference: “On the Efficient Implementation of Fair Queuing", Keshav, Berkeley, 1994
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-77
The length of queues (for scheduling purposes) is not in packets but in the time it would take to transmit all the packets in the queue. The following pages discuss the WFQ scheduling issue in detail. The end result is that WFQ adapts to the number of active flows (queues) and allocates equal amounts of bandwidth to each flow (queue). The side effect is that flows with small packets (usually interactive flows) get a much better servic e because they do not need a lot of bandwidth. They, however, need low-delay, which they get because small packets have a low finish time.
3-68
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Fair Queuing Finish Time Calculation If Flow Flow FF Active, Active, Then FT(Pk+1 k+1) = FT(Pkk) + Size(Pk+1 k+1) Otherwise FT(P0) = Now + Size(P0) FT(A1)=0+100 A1[100]
FT(B1)=50+300 B1[300]
FT(B2)=350+300
FT(A2)=100+20
A2[20]
FT(A3)=120+10 B2[300]
A3[10]
t
100
70 60 50
0
Hence the resulting scheduling is:
B2
B1
© 2001, Cisco Systems, Inc.
A3 A2
A1 Queuing Mechanisms-78
The figure illustrates how two queues (Queue A and Queue B) are contesting for link bandwidth. For this example, assume the time units are in milliseconds and time T (value 0 is used in the figure) is the starting point. Queue A is receiving packets in the following order and the following times: n
Packet A1 arrives at time T + 0ms and would require 100ms to be transmitted
n
Packet A2 arrives at time T + 60ms (the input interface is obviously faster than the output interface because the arrival time of packet A2 is before the finish time of packet A1) and would require 20 ms to be transmitted
n
Packet A3 arrives at time T + 60ms (the input interface is obviously much faster than the output interface) and would require 10 ms to be transmitted
Queue B is receiving packets in the following order and the following times: n
Packet B1 arrives at time T + 50ms and would require 300ms to be transmitted
n
Packet B2 arrives at time T + 100ms and would also require 300ms to be transmitted
The finish time of packets in Queue A are: n
Packet A1 has a finish time which is the sum of the current time (because the queue was empty at the time of arrival) and the time it takes to transmit this packet (100ms): FTA1 = 0ms + 100ms = 100ms
n
Packet A2 has a finish time which is the sum of the finish time of the last packet in Queue A (Packet A1) and the time it would take to transmit this packet (20ms): FTA2 = 100ms + 20ms = 120ms
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-69
n
Packet A3 has a finish time which is the sum of the finish time of the last packet in Queue A (Packet A2) and the time it would take to transmit this packet (20ms): FTA3 = 120ms + 10ms = 130ms
The finish time of packets in queue B are: n
Packet B1 has a finish time which is the sum of the current time (because the queue was empty at the time of arrival) and the time it takes to transmit this packet (300ms): FTB1 = 50ms + 300ms = 350ms
n
Packet B2 has a finish time which is the sum of the finish time of the last packet in Queue B (Packet B1) and the time it would take to transmit this packet (300ms): FTB2 = 350ms + 300ms = 650ms
The packets are scheduled into the hardware queue (TxQ) in the ascending order of finish times: 1. A1 (100ms) 2. A2 (120ms) 3. A3 (130ms) 4. B1 (350ms) 5. B2 (650ms) The following remarks should be noted in conclusion of the case study:
3-70
Queuing Mechanisms
n
WFQ prevents reordering of packets within a single flow (conversation)
n
Small packets are automatically preferred over large packets
Copyright 2001, Cisco Systems, Inc.
Weight in WFQ Scheduling WFQ system (real size packets) 2
Flow with P=001
1
3
Flow with P=000
2
1 Precedence-1 packets appear half the real size
Virtual Packet Size = Real Packet Size / (IP precedence + 1)
WFQ system (virtual size packets) 4
Flow with P=001
3 3
Flow with P=000
2 2
1 Precedence -1 flow gets twice as much bandwidth as precedence -0 flow
1
Hardware FIFO Queue 3 © 2001, Cisco Systems, Inc.
3
2
2
1
1 Queuing Mechanisms-79
This figure introduces the weight into the finish time calculation. The time it takes to transmit the packet is divided by IP precedence increased by one (to prevent division by zero). The WFQ implementation in Cisco routers was optimized in the following way: n
The real time it takes to transmit the packet is not relevant. The packet size can be used instead because it is proportional to the transmit time.
n
The packet size is not divided by IP precedence (division is a CPU-intensive operation). Instead, the size is multiplied by a fixed value (one multiplication value for each IP precedence value).
Packets with IP precedence one appear half the size they really are. The result is that these packets receive twice as much bandwidth as packets with IP precedence zero.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-71
Weighted Fair Queuing Finish Time Calculation Finish Time is adjusted based on IP precedence of the packet
If Flow F Active, Then FT(Pk+1) = FT(Pk) + Size(P Size(P k+1 k+1)/(IPPrec+1) Otherwise FT(P00) = Now + Size(P0)/(IPPrec+1) IOS implementation scales the finish time to allow integer arithmetic
If Flow F Active, Then FT(Pk+1) = FT(Pk) + Size(P Size(P k+1 k+1)*4096/(IPPrec+1) Otherwise FT(P00) = Now + Size(P0)*4096/(IPPrec+1) RSVP packets and high-priority internal packets (PAK-Priority) have special weights (4 and 128) © 2001, Cisco Systems, Inc.
Queuing Mechanisms-80
The first formula in the figure is the first optimisation where the finish time is really the sum of packet sizes divided by an increased IP precedence value. The second formula shows further optimisation where, instead of dividing, the packet size is multiplied by 4096/(IP precedence + 1). A value for each IP precedence is stored in a table and it does not have to be calculated for each packet. Packets belonging to RSVP flows and system packets have special low weights that guarantee them more bandwidth. Note
3-72
Queuing Mechanisms
Cisco IOS versions after 12.0(5)T use a new formula where the weight is calculated on the following formula: Weight = 32384 / (IP precedence +1)
Copyright 2001, Cisco Systems, Inc.
IP Precedence to Weight Mapping IP Precednece 0
Weight 4096
1 3
2048 1365 1024
4
819
5
682 585 512
2
6 7 32 (virtual IP precedence) 1024 (virtual IP precedence)
128 (PAC-Priority) 4 (RSVP)
• RSVP packets and high-priority internal packets (PAK-Priority) have special weights (4 and 128) • Lower weight makes packets appear smaller (preffered) © 2001, Cisco Systems, Inc.
Queuing Mechanisms-81
The table above shows the mapping between IP precedence values and WFQ weights. Note
According to the new formula for weight in Cisco IOS versions after 12.0(5)T the following values are used: IP precedence 0 IP precedence 1 IP precedence 2 IP precedence 3 IP precedence 4 IP precedence 5 IP precedence 6 IP precedence 7
Copyright 2001, Cisco Systems, Inc.
weight 32384 weight 16192 weight 10794 weight 8096 weight 6476 weight 5397 weight 4626 weight 4048
Queuing Mechanisms
3-73
Weighted Fair Queuing Voice and Data integration • WAN link speed • Voice requirements
128 kbps 30 kbps
• VoIP is precedence 5 (counts as 6 data sessions) • 1 VoIP session, 5 data sessions – voice gets up to 6/(6+5)*128 = 69 kbps (enough)
• 1 VoIP session, 20 data sessions – voice gets up to 6/(6+20)*128 = 29 kbps (problem)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-82
The case study above is concerned with the propagation of voice packets across a 128 kbps link without using RSVP. Assume that VoIP is using G.729 codec that uses approximately 30 kbps of bandwidth (including RTP, UDP, IP and frame headers). All voice packets are marked with IP precedence 5. n
The first calculation is where a voice session is contesting for available bandwidth with 5 precedence-0 data sessions. WFQ would guarantee 69 kbps to the voice session.
n
The second calculation is where the same voice session is contesting for available bandwidth with 20 precedence-0 data sessions. WFQ would now guarantee only 29 kbps to the voice session.
The conclusion is that, although WFQ can give a much better service to flows with small packets or high IP precedence value, it is not an exact tool that can guarantee a fixed amount of bandwidth.
3-74
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Benefits and Drawbacks of Weighted Fair Queuing + Benefits • Simple configuration (classification does not have to be configured) • Guarantees throughput to all flows • Drops packets of most aggressive flows • Supported on most platforms • Supported in all IOS versions (above 11.0)
– Drawbacks • • • • •
All drawbacks of FIFO queuing within a single queue Multiple flows can end up in one queue Does not support the configuration of classification Can not provide fixed bandwidth guarantees Performance limitations due to complex classification and scheduling mechanisms
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-83
The main benefits of WFQ are: n
Simple configuration (no manual classification is necessary)
n
Drops packets of the most aggressive flows
The main drawbacks are: n
It is not always possible to have one flow per queue
n
Does not allow manual classification
n
It cannot provide fixed guarantees
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-75
Weighted Fair Queuing Configuration Router(config-intf)# fair-queue [cdt [dynamic-queues [reservable-queues]]]
• congestive-discard-threshold (CDT) –Number of messages allowed in the WFQ system before the router starts dropping new packets for the longest queue. –The value can be in the range from 1 to 4096 (default is 64)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-84
WFQ is automatically enabled on all interfaces that have a default bandwidth of less than 2 Mbps. Use the fair-queue command to enable WFQ on interfaces where it is not enabled by default or was previously disabled. The CDT value can be changed from the default 64.
3-76
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Weighted Fair Queuing Configuration Router(config-intf)# fair-queue [cdt [dynamic-queues [reservable-queues]]]
• dynamic-queues – Number of dynamic queues used for best-effort conversations (values are: 16, 32, 64, 128, 256, 512, 1024, 2048, and 4096 - the default is 256) • reservable-queues – Number of reservable queues used for reserved conversations in the range 0 to 1000 (used for interfaces configured for features such as RSVP the default is 0)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-85
The number of dynamic queues can also be changed from the default number of 256 queues. The maximum number of reservable queues should be set when RSVP requires guarantees for the reserved bandwidth.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-77
Weighted Fair Queuing Additional Parameters Router(config-if)# hold-queue max-limit out
• Specifies the maximum number of packets that can be in all output queues on the interface at any time • The default value for WFQ is 1000 • Under special circumstances WFQ can consume a lot of buffers which may require lowering this limit
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-86
The same hold-queue command that can be used with FIFO queuing can also be used with WFQ. The default hold-queue limit with WFQ is 1,000 packets. The WFQ system will generally never reach the hold-queue limit because the CDT limit starts dropping packets of aggressive flows. Under special circumstances it would be possible to fill the WFQ system. For example, a denial-of-service attack that floods the interface with a large number of packets (each different) could fill all queues at the same rate.
3-78
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Fair Queuing Defaults • Fair Queuing is enabled by default on – physical interfaces whose bandwidth is less than or equal to 2.048 Mbps – interfaces configured for Multilink PPP
• Fair Queuing is disabled – if you enable the autonomous or silicon switching engine mechanisms – for any sequenced encapsulation: X.25, SDLC, LAPB, reliable PPP
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-87
The figure explains the default behavior of WFQ. As mentioned previously, WFQ is automatically enable d on all interfaces slower than 2Mbps. WFQ is also required on interfaces using Multilink PPP. WFQ cannot be used if reordering of frames is not allowed due to sequence numbering of Layer-2 frames or if the switching path does not support WFQ.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-79
Monitoring and Troubleshooting WFQ Router# show interface interface interface interface
• Displays interface delays including the activated queuing mechanism with the summary information Router# show queue interface
• Displays detailed information about the WFQ system of the selected interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-88
The same show commands can be used as with other queuing mechanisms:
3-80
Queuing Mechanisms
n
show interface
n
show queue
n
show queueing
Copyright 2001, Cisco Systems, Inc.
Show Interface Router#show Router#show interface interface serial serial 1/0 1/0 Hardware Hardware is is M4T M4T Internet Internet address address is is 20.0.0.1/8 20.0.0.1/8 MTU MTU 1500 1500 bytes, bytes, BW BW 19 19 Kbit, Kbit, DLY DLY 20000 20000 usec, usec, rely rely 255/255, 255/255, load load 147/255 147/255 Encapsulation Encapsulation HDLC, HDLC, crc crc 16, 16, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) Last Last input input 00:00:00, 00:00:00, output output 00:00:00, 00:00:00, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0 0/75/0 (size/max/drops); (size/max/drops); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 0/1000/64/0 0/1000/64/0 (size/max (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 0/4/256 0/4/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) 55 minute minute input input rate rate 18000 18000 bits/sec, bits/sec, 88 packets/sec packets/sec 55 minute minute output output rate rate 11000 11000 bits/sec, bits/sec, 99 packets/sec packets/sec …… rest rest deleted deleted ... ...
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-89
The show interface command can be used to determine the queuing strategy. The summary statistics are also displayed. The sample output in the figure shows that there are currently no packets in the WFQ system that allows up to 1,000 packets (hold-queue limit) with CDT 64. WFQ is using 256 queues. The maximum number of concurrent conversations (active queues) was 4.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-81
Show Queue
Router#show Router#show queue queue serial serial 1/0 1/0 Input Input queue: queue: 0/75/0 0/75/0 (size/max/drops); (size/max/drops); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 2/1000/64/0 2/1000/64/0 (size/max (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 2/4/256 2/4/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) (depth/weight/discards/tail (depth/weight/discards/tail drops/interleaves) drops/interleaves) 1/4096/0/0/0 1/4096/0/0/0 Conversation Conversation 124, 124, linktype: linktype: ip, ip, length: length: 580 580 source: source: 193.77.3.244, 193.77.3.244, destination: destination: 20.0.0.2, 20.0.0.2, id: id: 0x0166, 0x0166, ttl: ttl: 254, 254, TOS: TOS: 00 prot: prot: 6, 6, source source port port 23, 23, destination destination port port 11033 11033 (depth/weight/discards/tail (depth/weight/discards/tail drops/interleaves) drops/interleaves) 1/4096/0/0/0 1/4096/0/0/0 Conversation Conversation 127, 127, linktype: linktype: ip, ip, length: length: 585 585 source: source: 193.77.4.111 193.77.4.111 destination: destination: 40.0.0.2, 40.0.0.2, id: id: 0x020D, 0x020D, ttl: ttl: 252, 252, TOS: TOS: 00 prot: prot: 6, 6, source source port port 23, 23, destination destination port port 11013 11013
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-90
The show queue command also displays the flow (conversation) statistics:
3-82
Queuing Mechanisms
n
Queue depth is the number of packets in the queue
n
Weight is 4096/(IP precedence + 1) or 32384/(IP precedence + 1), depending on the Cisco IOS version
n
Discards is the number of drops due to the CDT limit
n
Tail drops is the number of drops due to the hold-queue limit
Copyright 2001, Cisco Systems, Inc.
Queuing comparison
Weighted Fair Queuing
Priority Queuing
Custom Queuing
No queue lists
4 queues
16 queues
Low volume traffic given priority Conversation dispatching
High priority queue serviced first Packet-by-packet dispatching
Round-robin service
Interactive traffic gets priority
Critical traffic gets through
Proportional allocation of bandwidth
Works well on speeds up to 2 Mbps
Designed for low-bandwidth links
Designed for medium-speed links
Enabled by default
Must configure
Must configure
Threshold dispatching
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-91
The table shows the main differences between WFQ, PQ and CQ.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-83
Summary The goal of WFQ is to: n
Perform queuing on a per-flow basis
n
Guarantee service to all flows
n
Share bandwidth fairly
n
Prioritize traffic by giving higher-priority flows proportionately more bandwidth
n
Prioritize low-volume (interactive) traffic
Review Questions Answer the following questions:
3-84
Queuing Mechanisms
n
How does WFQ classify packets?
n
When does WFQ drop packets?
n
How does WFQ schedule packets?
Copyright 2001, Cisco Systems, Inc.
Distributed Weighted Fair Queuing Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe and configure dWFQ
n
Describe and configure ToS-based dWFQ
n
Describe and configure QoS-group-based dWFQ
n
Monitor and troubleshoot WFQ
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-85
Distributed WFQ • The term “distributed” is primarily used for features available on Versatile Interface Processors (VIP) on Cisco 7x00 routers • Cisco IOS supports the following four versions of dWFQ: – Flow-based dWFQ – ToS-based dWFQ – QoS-group-based dWFQ – Distributed Class-based WFQ • This lesson focuses on the first three versions of dWFQ
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-96
The distributed versions of Weighted Fair Queuing are implemented on Cisco 7x00 series routers with Versatile Interface Processors (VIPs). There are four different versions of distributed WFQ, three of which are discussed in this module: n
Flow-based dWFQ or simply dWFQ
n
ToS-based dWFQ
n
QoS-group-based dWFQ or QoS-based dWFQ
VIP is basically a router within a router. It has its own processor and its own (different) version of the IOS. Most features implemented on VIPs have different functionality than those available on the Route Switch Processor (RSP).
3-86
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Flow-based dWFQ Forwarded Packets Flow-based dWFQ System
Flow 1?
WFQ-drop
Queue 1
Flow 2?
WFQ-drop
Queue 2
Hardware Queuing System WFQ Scheduler
Flow N?
WFQ-drop
Hardware Q
Interface
Queue N
• Flow-based dWFQ looks the same as RSP/LE WFQ, but ... © 2001, Cisco Systems, Inc.
Queuing Mechanisms-97
The structure of Distributed Flow-based WFQ (dWFQ) is similar to that discussed in the previous lesson. There are, however, some differences.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-87
Flow-based dWFQ Classification IP
TCP
Src. Dst. Proto. Addr. Addr.
Payload
Src. Port
WFQ Classification uses the following parameters: • source IP address • destination IP address • source TCP or UDP port • destination TCP or UDP port • transport protocol
Dst. Port
A hash algorithm is used to produce the index of the queue where the packet is enqueued
Hash Algorithm
#queue (9-bit index of the queue)
• The number of queues is 512 (not tunable) • ToS is not used for classification (except in IOS version 11.1CC) © 2001, Cisco Systems, Inc.
Queuing Mechanisms-98
Classification identifies flows but it does not use the ToS field. It uses all the other parameters that identify a flow (conversation): n
Source IP address
n
Destination IP address
n
Protocol number (identifying TCP or UDP)
n
Source TCP/UDP port number
n
Destination TCP/UDP port number
The number of queues is 512 and cannot be changed.
3-88
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
dWFQ Insertion and Drop Policy • dWFQ drops packets when both the individual queue limit (IQL) and aggregate queue limit (AQL) are reached • dWFQ is not as strict with aggressive flows as non-distributed WFQ • This insertion and drop policy is the same for all three versions of dWFQ (flow-based, ToSbased and QoS-group-based)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-99
The dropping scheme of dWFQ is similar to that of non-distributed WFQ, except that it is not as strict with aggressive flows. The same dropping policy is used for all three versions of dWFQ (Flow-based dWFQ, ToS-based dWFQ and QoS-group-based dWFQ).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-89
dWFQ Insertion and Drop Policy N-th packet
M>QL?
No
Yes
N>AQL?
No
Enqueue packet
Yes
M>IQL?
No
Yes
• QL (queue limit) is the maximum number of packets the selected que ue can hold • AQL (aggregate queue limit) is the max. number of packets that the dWFQ system can hold • IQL (individual queue limit) is the max. number of packets that an individual queue a congested dWFQ system can hold • N is the number of packets in the dWFQ system when the N -th packet arrives • M is the number of packets in the queue to which the packet is cl assified © 2001, Cisco Systems, Inc.
Queuing Mechanisms-100
When a new packet is to be inserted into one of the queues the router follows these rules: 1. Enqueue the packet if the WFQ system is within the aggregate queue limit 2. Enqueue the packet if the queue is within the individual queue limit 3. Otherwise, drop the packet
3-90
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Flow-based dWFQ Scheduling Flow-based dWFQ System Queue 1
Queue 2
dWFQ Scheduler (Calendar Queuing)
Packets are scheduled (ordered) in advance for faster transfer to the hardware queue Hardware Queuing System
Calendar Queue
Hardware Q
Interface
Queue N
• Uses Calendar Queuing (optimized version of scheduling based on finish time, more jitter) • Weight (IP precedence) is NOT used for scheduling purposes (pure Fair Queuing) © 2001, Cisco Systems, Inc.
Queuing Mechanisms -101
The scheduler uses the same finish time calculation except it does not include the weight. It is a pure Fair Queuing mechanism. The scheduler was also optimized for performance (Calendar Queuing).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-91
Configuring Flow-based dWFQ Router(config-if)# fair-queue fair-queue
• The command enables dWFQ on an interface connected to a VIP2-40 or newer interface processor • For all other interfaces, this command enables RSPbased WFQ • Can be configured on interfaces but not on subinterfaces • dWFQ is not supported on Fast EtherChannel, tunnel, or other logical or virtual interfaces (MPPP)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -102
Using the fair-queue interface command enables dWFQ if the following requirements are met:
3-92
Queuing Mechanisms
n
Interface is on a VIP2-40 or newer
n
Distributed CEF is enabled
Copyright 2001, Cisco Systems, Inc.
Configuring Flow-based dWFQ Router(config)# fair-queue aggregate-limit aggregate-limit aggregate-packets
• The total number of packets in all output queues before some packets may be dropped Router(config)# fair-queue individual-limit individual-packets
• The maximum individual per-flow queue size during periods of congestion • Defaults: aggregate-limit depends on the transmission rate and the available buffer space on the VIP; individual-limit is half of the aggregate-limit • Don’t change the defaults unless necessary © 2001, Cisco Systems, Inc.
Queuing Mechanisms -103
Use these two commands to change the default limits that govern the dropping of packets when individual queues and the WFQ system are congested.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-93
Flow-based dWFQ Example interface interface FastEthernet FastEthernet 1/1/0 ip ip address address 80.0.2.70 80.0.2.70 255.255.255.0 255.255.255.0 fair-queue fair-queue fair-queue fair-queue aggregate-limit aggregate-limit 200 200 fair-queue fair-queue individual-limit individual-limit 30 30 !!
• dWFQ on a FastEthernet interface • dWFQ system should not contain more than 200 packets • No queue should accept new packets when the dWFQ system is congested and the queue is longer than 30 packets © 2001, Cisco Systems, Inc.
Queuing Mechanisms -104
The example illustrates how dWFQ was implemented on a FastEthernet interface.
3-94
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Show Interface Router#show Router#show interfaces interfaces FastEthernet1/1/0 FastEthernet1/1/0 FastEthernet1/1/0 FastEthernet1/1/0 is is up, up, line line protocol protocol is is up up Hardware Hardware is is cyBus cyBus FastEthernet FastEthernet Interface, Interface, address address is is 0007.f618.4448 0007.f618.4448 Description: Description: pkt pkt input input i/f i/f for for WRL WRL tests tests (to (to pagent) pagent) Internet Internet address address is is 80.0.2.70/24 80.0.2.70/24 MTU MTU 1500 1500 bytes, bytes, BW BW 100000 100000 Kbit, Kbit, DLY DLY 100 100 usec, usec, rely rely 255/255, 255/255, load load 1/255 1/255 Encapsulation Encapsulation ARPA, ARPA, loopback loopback not not set, set, keepalive keepalive not not set, set, 100BaseTX/FX 100BaseTX/FX ARP ARP type: type: ARPA, ARPA, ARP ARP Timeout Timeout 04:00:00 04:00:00 Last Last input input never, never, output output 01:11:01, 01:11:01, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters 01:12:31 01:12:31 Queueing Queueing strategy: strategy: VIP-based VIP-based fair fair queuing queuing Output Output queue queue 0/40, 0/40, 00 drops; drops; input input queue queue 0/75, 0/75, 00 drops drops 30 30 second second input input rate rate 00 bits/sec, bits/sec, 00 packets/sec packets/sec 30 30 second second output output rate rate 00 bits/sec, bits/sec, 00 packets/sec packets/sec …… rest rest deleted deleted ... ...
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -105
The usual show interface command reveals that VIP-based fair queuing is enabled (dWFQ). Some other show commands used with other queuing mechanisms do not display any valuable information (RSP regards this interface as FIFO).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-95
Show Interface Fair-queue
Router#show Router#show interface interface fastethernet fastethernet 1/1/0 fair fair FastEthernet FastEthernet 1/1/0 1/1/0 queue size 0 pkts pkts output output 0, 0, wfq drops 0, nobuffer nobuffer drops drops 0 WFQ: WFQ: aggregate aggregate queue queue limit limit 200 individual individual queue queue limit limit 30 max available buffers 0
• Displays dWFQ statistics
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -106
This command can be used to display some statistics about dWFQ.
3-96
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Benefits and Drawbacks of Flowbased dWFQ + Benefits • Automatic classification • High performance
– Drawbacks • Does not support the configuration of classification • Does not use IP precedence as weight • Only supported on Cisco 7x00 series routers with VIP 2-40 or newer
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -107
The distributed version of WFQ has one advantage over normal WFQ: better performance. The main drawbacks include: n
Lack of tuning capability
n
Not weighted
n
Only supported on VIPs
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-97
ToS-based dWFQ Forwarded Packets ToS -based dWFQ System
Class 1?
WFQ-drop
Queue 1
Class 2?
WFQ-drop
Queue 2
Hardware Queuing System dWFQ Scheduler
Class 3?
WFQ-drop
Queue 3
Class 4?
WFQ-drop
Queue 4
Hardware Q
Interface
• ToS-based dWFQ has four classes © 2001, Cisco Systems, Inc.
Queuing Mechanisms -108
The ToS-based dWFQ differs from Flow-based dWFQ in the following ways:
3-98
Queuing Mechanisms
n
Classification is done based on the two low-order IP precedence bits
n
Scheduling is configurable by setting weights manually
n
Four queues are used
Copyright 2001, Cisco Systems, Inc.
ToS-based dWFQ Classification IP
Payload ToS -based dWFQ Classification uses the two low -order IP precedence bits to classify packets
IP Prec. XXX 00000
#queue (2-bit index of the queue)
Queue 1
IP precedence 0 and 4
Queue 2 Queue 3
1 and 5 2 and 6
Queue 4
3 and 7
• The number of queues is 4 (fixed) • Classification is based on the two low-order IP precedence bits © 2001, Cisco Systems, Inc.
Queuing Mechanisms -109
The classification uses the two low-order IP precedence bits. The result of classification is that: n
Packets with IP precedence values 0 and 4 are classified into Queue 0
n
Packets with IP precedence values 1 and 5 are classified into Queue 1
n
Packets with IP precedence values 2 and 6 are classified into Queue 2
n
Packets with IP precedence values 3 and 7 are classified into Queue 3
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-99
ToS-based dWFQ Scheduling • One weight per class configured as a % –Sum of all weights must be =< 99 –Some bandwidth needed for Class 0 • Tail-Drop within each queue • First release: 11.1cc, 12.0
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-110
Weights that determine how much bandwidth is guaranteed to each class are configured in percentage points. Weights can be assigned to Queues 1¸ 2 and 3. Queue 0 gets the rest of the bandwidth.
3-100
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring ToS-based dWFQ Router(config-intf)# fair-queue tos
• Enables ToS-based distributed WFQ Router(config-intf)# fair-queue tos num num weight weight weight
tos number - 2 low order precedence bits (only classes 1, 2 and 3 can be configured with weight; class 0 takes the remaining bandwidth) weight - percentage of the output link bandwidth allocated to this class (the sum for all classes cannot exceed 99) Defaults: unclassified traffic is assigned to class 0; class 1 - 20, class 2 - 30, class 3 - 40 class 0 has the remaining weight (100%-W1-W2-W3); default 10 © 2001, Cisco Systems, Inc.
Queuing Mechanisms -111
ToS-based dWFQ is enabled using the fair-queue tos interface command. Note
Copyright 2001, Cisco Systems, Inc.
Distributed CEF has to be enabled prior to using this command.
Queuing Mechanisms
3-101
Configuring ToS-based dWFQ Router(config-if)# fair-queue tos tos num limit class-packets
• Configures maximum number of packets allowed in the selected queue • If not configured, the default is individual-limit • If queue limit is not configured it is set to the number of available buffers multiplited by weight Router(config-if)# fair-queue fair-queue individual-limit individual-limit individual-packet individual-packet
• If individual limit is not configured it is set to one quarter of the number of available buffers Router(config-if)# fair-queue aggregate-limit aggregate-packets
• If aggregate limit is not configured is set to the number of availble buffers
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-112
These three optional commands can be used to control individual queue sizes. The default behavior is:
3-102
Queuing Mechanisms
n
Aggregate queue limit equals maximum available buffers
n
Individual queue limit equals one quarter of maximum available buffers
n
Per-queue limit equals maximum available buffers multiplied by weight
Copyright 2001, Cisco Systems, Inc.
ToS-based WFQ Configuration Example interface interface Hssi0/0/0 Hssi0/0/0 ip address 188.1.3.70 255.255.255.0 fair-queue tos tos fair-queue tos tos 1 weight weight 20 fair-queue tos tos 1 limit 27 fair-queue tos tos 2 weight weight 30 fair-queue tos tos 2 limit 27 fair-queue tos tos 3 weight weight 40 fair-queue tos tos 3 limit 27 !!
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -113
The example shows how ToS-based dWFQ is configured on VIP-based interfaces.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-103
Show Interface Fair-queue
Router#show interfaces fair-queue fair-queue Hssi0/0/0 Hssi0/0/0 queue queue size size 00 pkts pkts output output 947, 947, wfq wfq drops drops 0, nobuffer drops 0 WFQ: WFQ: aggregate aggregate queue queue limit limit 386 386 individual individual queue queue limit limit 96 96 max available available buffers buffers 386 386 Class Class Class Class Class Class Class Class
© 2001, Cisco Systems, Inc.
0: 0: 1: 1: 2: 2: 3: 3:
weight weight weight weight weight weight weight weight
10 10 20 20 30 30 40 40
limit limit limit limit limit limit limit limit
20 27 27 27
qsize qsize qsize qsize qsize qsize qsize qsize
00 00 00 00
pkts pkts pkts pkts pkts pkts pkts pkts
output output output output output output output output
947 947 drops drops 00 00 drops drops 00 00 drops drops 00 00 drops drops 00
Queuing Mechanisms -114
The show interface fair-queue command can be issued to display parameters and statistics for VIP-based interfaces.
3-104
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Benefits and Drawbacks of ToSbased dWFQ + Benefits • Automatic classification • Guarantees throughput to all classes • High performance
– Drawbacks • All drawbacks of FIFO queuing within a single class • Does not support the configuration of classification • Only four classes are supported • Unusual interpretation of IP precedence (high-priority packets with IP precedence 6 and 7 share queues with lower-priority packets with IP precedence 2 and 3) • Only supported on Cisco 7x00 series routers with VIP 2-40 or newer © 2001, Cisco Systems, Inc.
Queuing Mechanisms -115
The ToS-based dWFQ represents the first class-oriented queuing mechanism available on VIPs. The main drawbacks of this queuing mechanism are that it: n
Supports only four classes
n
Mixes packets of different IP precedence values
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-105
QoS-group-based dWFQ Forwarded Packets QoS-group-based dWFQ System
Class 1?
WFQ-drop
Queue 1
Class 2?
WFQ-drop
Queue 2
Hardware Queuing System dWFQ Scheduler
Class 100?
WFQ-drop
Hardware Q
Interface
Queue 100
• QoS-group-based dWFQ supports 100 classes © 2001, Cisco Systems, Inc.
Queuing Mechanisms -116
QoS-group-based dWFQ was introduced to provide a solution to ToS-based dWFQ drawbacks:
3-106
Queuing Mechanisms
n
4 classes are upgraded to 100 classes
n
Classification is more flexible (any other parameter can be translated into the QoS group number)
Copyright 2001, Cisco Systems, Inc.
QoS-group-based dWFQ Classification Packet Buffer
Buffer Header
Frame Header
IP Header
Payload
QoS group
• The number of queues is 100 • Classification is based on the QoS group parameter • The parameter is local to the router and it has to be set by some other QoS mechanism: – Policy-based Routing (PBR) – Committed Access Rate (CAR) – QoS Policy Propagation through BGP (QPPB) – Class-based Marking – Class-based Policing © 2001, Cisco Systems, Inc.
Queuing Mechanisms -117
Classification is performed using the QoS group parameter to select one of the 100 queues. The QoS group parameter is local to the router so it has to be set on every hop using one of the QoS mechanisms that supports marking: n
Policy-based Routing (PBR)
n
QoS Policy Propagation through BGP(QPPB)
n
Committed Access Rate (CAR)
n
Class-based Policing
n
Class-based Marking
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-107
QoS-group-based dWFQ Scheduling • Scheduling is identical to that of ToS-based dWFQ • One weight per class configured as a % –Sum of all weights must be =< 99 –Some bandwidth needed for Class 0 • Tail-Drop within each queue
© 2001, Cisco Systems, Inc.
Queuing Mechanisms-118
Scheduling and configuration of scheduling and dropping is identical to that of ToSbased dWFQ. The only difference is that there are up to 100 queues to configure.
3-108
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring QoS-group-based dWFQ Router(config-intf)# fair-queue qos-group qos-group
• Enables ToS-based distributed WFQ Router(config-intf)# fair-queue qos-group qos-group num weight weight
qos-group number - classes 1 through 99 can be configured with weight; class 0 takes the remaining bandwidth weight - percentage of the output link bandwidth allocated to this class (the sum for all classes cannot exceed 99) Defaults: unclassified traffic is assigned to class 0; class 1 - 20, class 2 - 30, class 3 - 40 class 0 has the remaining weight (100%-W1-W2-W3); default 10 © 2001, Cisco Systems, Inc.
Queuing Mechanisms -119
Replacing ToS-based dWFQ involves using only the fair-queue qos-group interface command. All existing fair-queue tos commands are replaced with fair-queue qos-group commands. Note
Copyright 2001, Cisco Systems, Inc.
Replacing ToS-based dWFQ with QoS-group-based dWFQ causes all packets to go into Queue 0 because classification is no longer perform ed based on IP precedence value. Some additional configuration steps are necessary.
Queuing Mechanisms
3-109
Configuring QoS-group-based dWFQ Router(config-intf)# fair-queue qos-group qos-group num limit class-packets
• Configures individual queue depth – class-packets - maximum number of packets allowed in the queue for the class during periods of congestion
• If not configured, the default is individual-limit, which is half of the aggregate queue limit Router(config-intf)# fair-queue fair-queue aggregate-limit aggregate-packets aggregate-packets fair-queue fair-queue individual-limit individual-packet
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -120
These commands have the same meaning as with ToS-based dWFQ.
3-110
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
QoS-group-based dWFQ Example • QoS-group-based dWFQ can be used to implement mapping of different parameters into QoS group: – Assume another mechanism has been configured to translate QoS class information into QoS group (e.g. QPPB) – Use QoS-group-based dWFQ output queuing
• Example: – allocate 10% to class 1 traffic allocate 30% to class 2 traffic allocate 60% to other traffic
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -121
The case study involves using three queues. Classification and marking is performed using QPPB where the QoS group is set based on some BGP information (for example, BGP community attribute).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-111
QoS-group based WFQ Configuration Example interface interface FastEthernet1/0/0 FastEthernet1/0/0 bgp-policy bgp-policy destination destination ip-qos-map ip-qos-map !! ... ... !! interface interface Hssi0/0/0 Hssi0/0/0 ip ip address address 188.1.3.70 188.1.3.70 255.255.255.0 255.255.255.0 bgp-policy bgp-policy destination destination ip-prec-map ip-prec-map fair-queue fair-queue qos-group qos-group fair-queue fair-queue aggregate-limit aggregate-limit 60 fair-queue fair-queue qos-group qos-group 1 weight weight 10 fair-queue fair-queue qos-group qos-group 2 weight weight 30 fair-queue fair-queue qos-group qos-group 2 limit limit 27 27 !!
© 2001, Cisco Systems, Inc.
3-112
Queuing Mechanisms
Queuing Mechanisms -122
Copyright 2001, Cisco Systems, Inc.
Monitoring QoS-group-based dWFQ Router#show Router#show interfaces interfaces fair-queue fair-queue Hssi0/0/0 Hssi0/0/0 queue queue size size 00 pkts pkts output output 4, 4, wfq wfq drops drops 0, 0, nobuffer nobuffer drops drops 00 WFQ: WFQ: aggregate aggregate queue queue limit limit 60 60 individual individual queue queue limit limit 96 96 max max available available buffers buffers 386 386 Class Class 0: 0: weight weight 60 60 limit limit 231 231 qsize qsize 00 pkts pkts output output 44 drops drops 00 Class Class 1: 1: weight weight 10 10 limit limit 38 38 qsize qsize 00 pkts pkts output output 00 drops drops 00 Class Class 2: 2: weight weight 30 30 limit limit 27 27 qsize qsize 00 pkts pkts output output 00 drops drops 00
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -123
The show interface fair-queue command only displays information for queues with a weight higher than zero.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-113
Benefits and Drawbacks of QoSgroup-based dWFQ + Benefits • Guarantees throughput to all classes • A large number of classes (100) • High performance
– Drawbacks • All drawbacks of FIFO queuing within a single class • Requires other QoS mechanisms to set QoS group • Only supported on Cisco 7x00 series routers with VIP 2-40 or newer
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -124
QoS-group-based dWFQ is the first high-performance class-oriented queuing mechanism. Its main drawback is that it is only available on Cisco 7x00 series routers with VIPs.
3-114
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
dWFQ Summary Classification
Classes
Weighted
Implementation
Fairnes
WFQ
Per-flow
16 to 4096
Yes (IP precedence)
RSP/LE
dWFQ
Per-flow
512
No
VIP
ToS dWFQ
IP precedence
4
Manual
VIP
QoS dWFQ
QoS group
100
Manual
VIP
CB-WFQ*
Manual
64
Manual
RSP/LE/VIP
* Class-based WFQ is covered in the “Modular QoS CLI” module © 2001, Cisco Systems, Inc.
Queuing Mechanisms -125
The figure illustrates the comparison of all versions of Weighted Fair Queuing. n
Traditional WFQ is only available on low-end (LE) routers and the Route Switch Processor (RSP) of Cisco 7x00 series routers
n
All three distributed versions are only available on VIP-based interfaces of Cisco 7x00 series routers
Class-based WFQ is now available on low-end routers, the RSP and on the VIP (distributed)
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-115
Summary There are five versions of WFQ: n
Flow-based WFQ (non-distributed, per-flow queuing)
n
Flow-based dWFQ (not weighted, per-flow queuing, fixed number of queues)
n
ToS-based dWFQ (four queues, limited classification options)
n
QoS-group-based dWFQ (up to 100 queues, requires marking on every hop)
n
CB-WFQ
Review Questions Answer the following questions:
3-116
Queuing Mechanisms
n
Which distributed Weighted Fair Queuing mechanisms do you know?
n
What are the main differences between dWFQ versions?
n
What platforms support dWFQ?
Copyright 2001, Cisco Systems, Inc.
Modified Deficit Round-robin Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe MDRR queuing
n
Describe the benefits and drawbacks of MDRR queuing
n
Configure MDRR queuing on Cisco GSR routers
n
Monitor and troubleshoot MDRR
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-117
Modified Deficit Round Robin • Deficit Round Robin (DRR) is a class-based queuing mechanism available on Cisco GSR routers • MDRR supports 8 classes • Low-latency queuing is introduced in the Modified Deficit Round Robin (MDRR)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -130
Modified Deficit Round-robin (MDRR) is a class-oriented queuing mechanism available on Cisco 12000 series routers (GSR). It supports eight classes, one of which can be used for low-delay propagation.
3-118
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
MDRR Architecture Forwarded Packets Modified Deficit Round Robin
Class 1?
Tail -drop WRED
VOQ 1
Class 2?
Tail -drop WRED
VOQ 2 MDRR Scheduler
Class 8?
Tail -drop WRED
Hardware Queuing System or Crossbar Switching Fabric
Interface
VOQ 8
• MDRR supports 8 classes (8 RR queues, one can be high-priority) • MDRR is implemented on the receive side (in front of the Crossbar Switching Matrix) and on the transmit side (in front of an interface) © 2001, Cisco Systems, Inc.
Queuing Mechanisms -131
MDRR classifies packets based on IP precedence value. Each queue can be configured to support WRED. MDRR can be implemented on output to interfaces (as in all other queuing mechanisms) or in front of the GSR’s Crossbar Switching Matrix.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-119
MDRR Features • Deficit Round Robin (DRR) is using eight Virtual Output Queues (VOQ) to prevent head-of-line blocking • DRR can use Weighted Random Early Detection (WRED) within each class to prevent congestion within the class • Modified DRR (MDRR) can have one high priority queue for delay-sensitive traffic being serviced in either of the two supported modes: – Strict priority – Alternate priority
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -132
DRR was the first implementation that was later improved by allowing one queue to be high priority.
3-120
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
MDRR Classification IP precedence 0 VOQ 0 IP precedence 1
VOQ 1
VOQ 2
IP precedence 7
VOQ 7
• MDRR supports classification of any IP precedence into any of the 8 virtual output queues • One of the 8 queues can be used as low-latency queue © 2001, Cisco Systems, Inc.
Queuing Mechanisms -133
Classification is done using IP precedence to put packets into one of the eight Virtual Output Queues (VOQ). One of these queues can be configured as high priority.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-121
MDRR Insertion and Drop Policy
Tail-drop or WRED
Virtual Output Queue
• MDRR uses a traditional tail-drop scheme if a queue is congested • MDRR can also use Weighted Random Early Detection (WRED) to prevent congestion
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -134
Each queue uses the tail-drop scheme unless it is configured with WRED.
3-122
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
DRR Scheduling Each queue can transmit a configured amount of bytes in one round: MTU + (weight-1)*512 VOQ 0 VOQ 1
Round Robin Scheduler
VOQ 7
• Service policy for one queue in one round: 1. Add MTU+(Weight-1)*512 tokens to the token bucket. 2. Transmit packets until tokens are used up or the queue is empty. 3. Reset the token bucket to 0 if the queue is empty. Otherwise remember the deficit (how much more tokens were used than available). 4. Start serving the next queue. © 2001, Cisco Systems, Inc.
Queuing Mechanisms -135
The scheduling of DRR is similar to that of Custom Queuing, except it is more accurate. DRR remembers the number of bytes it sent above the threshold in the previous round (deficit).
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-123
MDRR Scheduling with Strict Priority Queue LL Queue VOQ 0 VOQ 1
Str ict Qu Priori t eui ng y
The Strict Priority Low-latency Queue is not limitted by the Token Bucket mechanism
Round Robin Scheduler
VOQ 7
• Service policy for MDRR with Strict Priority: 1. Transmit packets from the Strict Priority Low-latency Queue until the queue is empty. 2. Serve the next-in-line round robin queue. 3. Start serving the Low-latency queue again.
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -136
MDRR can schedule one queue ahead of all the others if it is configured as a Strict Priority queue. This queue can be used for delay-sensitive applications (for example, voice). The problem of this solution is that it can cause other queues to starve if the high priority queue is congested.
3-124
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
MDRR Scheduling with Alternate Priority Queue LL Queue VOQ 0 VOQ 1
Alt er Pr nate Qu iority eui ng
The Alternate Priority Queue is using the Token Bucket to limit the amount of bytes it can transmit in one round
Round Robin Scheduler
VOQ 7
• Service policy for MDRR with Alternate Priority: 1. Transmit packets from the Alternate Priority Low-latency Queue until the tokens are used up or the queue is empty. 2. Serve the next-in-line round robin queue 3. Start serving the Low-latency queue again.
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -137
The high priority queue can be set to Alternate Priority mode where all other queues still get service, even if the high-priority queue is congested. The high priority queue, however, experiences slightly more delay because it has to wait for the currently served queue to reach its threshold or be emptied.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-125
Benefits and Drawbacks of MDRR + Benefits • Accurate bandwidth allocation (takes into account the deficit from the previous round as opposed to Custom Queuing) • Prevents head-of-line blocking in front of the crossbar switching fabric • Supports low-latency queuing (strict priority and alternate priority) • High performance
– Drawbacks • Limited classification tools (only IP precedence) • Limited number of classes (only 8) • Only supported on Cisco 12000 series routers (GSR)
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -138
MDRR is a high performance queuing mechanism that supports eight classes and allocates bandwidth according to configured weights. It also supports one queue for low-delay propagation of packets.
3-126
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Interface MDRR Router(config)# cos-queue-group cos-queue-group-name cos-queue-group-name
• Create a queue group template and enter COS queue group configuration mode Router(config-cos-que)# precedence precedence queue {queue-number|low-latency} {queue-number|low-latency}
• Map IP precedence to a queue Router(config-cos-que)# queue queue-number weight
• Set weight of a queue
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -139
Configuration of MDRR requires a cos-queue -group to be configured first. All MDRR configuration is performed in the cos-queue -group configuration mode. The first step is to map an IP precedence value to one of the eight queues. Each queue can be configured with a weight that determines the number of bytes that can be transmitted in one round.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-127
Configuring Interface MDRR Router(config-cos-que)# queue low-latency {alternate-priority weight|strict-priority}
• Specify the type of low-latency queue Router(config-if)#
tx-cos cos-queue-group-name
• Associate a COS queue group name with the transmit queues on an interface
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -140
One of the queues can be turned into a high priority queue. The type of queue is determined by the alternate-priority or strict-priority keywords. The last step is to apply the cos-queue-group to an output interface.
3-128
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Receive MDRR Router(config)# slot-table-cos slot-table-name
• Define a slot table name and enter slot table configuration mode Router(config-slot-cos)# destination slot slot {slot-number|all} {slot-number|all} cos-queue-group-name
• Define destination slot parameters for this slot table name Router(config)# rx-cos-slot line-card-number cos-queue-group-name
• Link a slot-table-cos template to a line card
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -141
MDRR can also be applied to traffic leaving the line card through the Crossbar Switching Matrix. A slot-table -cos has to be configured where the destination line cards are specified using the destination slot command. The slot table is then applied to one or more line cards using the rx-cos-slot command.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-129
MDRR Example interface interface POS3/0 POS3/0 ip address 1.0.0.1 255.0.0.0 tx-cos tx-cos C4template C4template !! cos-queue-group cos-queue-group C4template precedence 0 queue 0 precedence 1 queue 1 precedence 2 queue 1 precedence 3 queue 2 precedence 4 queue 2 precedence 5 queue low-latency precedence 6 queue 3 precedence 7 queue 3 queue 0 10 10 queue 1 20 20 queue 2 40 40 queue queue low-latency low-latency alternate-priority alternate-priority 80 80 exit exit !! © 2001, Cisco Systems, Inc.
Queuing Mechanisms -142
The example illustrates a sample configuration of MDRR applied to traffic leaving the POS interface.
3-130
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting MDRR Router#
show cos statistics • Display MDRR statistics Router#show Router#show cos statistics Slot Slot 33 ----------------------------Dest Dest slot slot 55 cos-queue-group: cos-queue-group: C7template C7template ... ... Queue Queue Lengths Lengths To To Fabric Fabric Queues Queues (DRR (DRR configured) configured) C7template Queue Average High Queue Average High Water Water Mark Mark 00 712.000 5562.000 712.000 5562.000 11 702.000 7716.000 702.000 7716.000 22 702.000 11540.000 702.000 11540.000 33 753.000 14368.000 753.000 14368.000 44 0.000 0.000 0.000 0.000 55 0.000 0.000 0.000 0.000 66 0.000 0.000 0.000 0.000 Low latency 0.000 0.000 Low latency 0.000 0.000 ... ...
Weight Weight 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -143
The show cos statistics can be used to display results of MDRR.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-131
Summary MDRR is a class-oriented queuing mechanism available on the Cisco 1200 series routers. It allows bandwidth guarantees to eight classes and low-delay propagation to one class. MDRR can be applied to outbound traffic or traffic leaving a line card through the Crossbar Switching Matrix.
Review Questions Answer the following questions:
3-132
Queuing Mechanisms
n
Describe the scheduling mechanism of MDRR.
n
Which two types of low-latency queuing does MDRR support?
n
What are the benefits and drawbacks of MDRR?
n
Where can MDRR be applied?
Copyright 2001, Cisco Systems, Inc.
IP RTP Prioritization Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe IP RTP prioritization
n
Describe the benefits and drawbacks of IP RTP prioritization
n
Configure IP RTP prioritization on Cisco routers
n
Monitor and troubleshoot IP RTP Prioritization
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-133
IP RTP Prioritization • IP RTP Prioritization provides low-latency queuing when used in combination with WFQ or CB-WFQ • It can only be used with UDP traffic with predictable port numbers • It is usually used for VoIP traffic • IP RTP Prioritization is limited to prevent starvation of other traffic
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -148
IP RTP Prioritization is an add-on to WFQ to support low-delay propagation of packets. It can be used for UDP traffic only. IP RTP Prioritization also polices the high priority traffic to prevent starvation of other queues.
3-134
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
IP RTP Prioritization Forwarded Packets High Priority?
Weighted Fair Queuing System Flow 1?
WFQ-drop
Queue 1
Flow 2?
WFQ-drop
Queue 2
Hardware Queuing System
WFQ Scheduler
Flow N?
WFQ-drop
RTP Scheduler
Hardware Q
Interface
Queue N
• IP RTP prioritization adds one high-priority queue to WFQ © 2001, Cisco Systems, Inc.
Queuing Mechanisms -149
IP RTP Prioritization supports one high priority queue. Packets from this queue are scheduled ahead of other packets as long as they are within the configured rate. Excess packets are dropped.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-135
IP RTP Priority Classification Forwarded Packets
IP
UDP
Payload UDP Destination port
UDP port In range? No
Yes
RTP Queue
WFQ Queuing System
• IP RTP Prioritization classifies packets based on the UDP port number • Classification is specified by a range of UDP port numbers © 2001, Cisco Systems, Inc.
Queuing Mechanisms -150
IP RTP Prioritization classifies packets based on UDP port numbers. If the destination UDP port is within the configured range it is enqueued into the high priority queue.
3-136
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
IP RTP Priority Insertion and Drop Policy Classified Packets
Token Bucket
Packet within Contract?
Yes
RTP Queue
No
• IP RTP Prioritization limits the amount of high-priority traffic • Excess traffic is dropped © 2001, Cisco Systems, Inc.
Queuing Mechanisms -151
Packets that exceed the policy are dropped. A token Bucket model is used to measure the arrival rate of packets into this queue.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-137
Benefits and Drawbacks of IP RTP Prioritization + Benefits • Adds low-latency queuing to WFQ and CBWFQ • Prevents starvation of other traffic
– Drawbacks • Poor classification options • Obsoleted by Class-based Low-latency Queuing
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -152
The main benefit of IP RTP Prioritization is that it allows low-latency propagation when using WFQ. The main drawback is that it has limited classification capabilities (UDP port range only). IP RTP Prioritization was made obsolete by the introduction of Class-based Low Latency Queuing (discussed in the “IP QoS - Modular QoS CLI” module).
3-138
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring IP RTP Prioritization Router(config-if)# ip rtp priority priority starting-port port-range port-range bandwidth bandwidth
• Creates a separate priority queue for VoIP packets and specifies maximum bandwidth available to voice traffic • Maximum bandwidth shall always be slightly larger than actually required bandwidth due to jitter in the network and the Layer-2 overhead • Only UDP packets with a destination port number in the configured range are classified into this queue Router(config-if)# max-reserved-bandwidth percent
• Specifies the maximum bandwidth percentage that can be allocated to class-based WFQ and priority RTP traffic • The remaining bandwidth is available to flow-classified best-effort traffic and control packets • Default: 75% of the interface bandwidth can be reserved © 2001, Cisco Systems, Inc.
Queuing Mechanisms-153
Configuration of IP RTP Prioritization requires using the ip rtp priority command where the following parameters have to be specified: n
Starting UDP port number
n
UDP port range (added to the starting port number)
n
Maximum and guaranteed bandwidth
If the requested bandwidth is less than 75% of the bandwidth configured on the interface, the command will fail. Reservable bandwidth can be increased by using the max-reserved-bandwidth interface command.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-139
IP RTP Prioritization Example interface interface Serial0/0 Serial0/0 bandwidth bandwidth 128 ip ip address address 10.0.0.1 10.0.0.1 255.255.255.252 encapsulation ppp ppp fair-queue fair-queue ip ip rtp priority 16384 16383 50 50 !!
Up to 75% of configured bandwidth is reservable.
BWavail = BW * 0.75 - BWRTP
Router#show Router#show queue queue serial0/0 serial0/0 Input Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total Total output output dr drops: ops: 00 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations Conversations 0/1/256 0/1/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 46 46 kilobits/sec kilobits/sec Router# Router#
© 2001, Cisco Systems, Inc.
Queuing Mechanisms -154
The sample configuration shows how 50 kbps of bandwidth is guaranteed for RTP traffic. The show queue command shows there is only 46 kbps of bandwidth (128 kbps • 75% -50 kbps = 46 kbps) remaining for WFQ.
3-140
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Summary IP RTP Prioritization adds low-latency queuing capability to WFQ. It can only classify packets into one queue based on the UDP port range.
Review Questions Answer the following questions: n
When would you use IP RTP prioritization?
n
What are the drawbacks of IP RTP prioritization?
n
How many high-priority queues does IP RTP prioritization support?
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-141
Summary After completing this module, you should be able to perform the following tasks:
3-142
Queuing Mechanisms
n
Describe and configure FIFO Queuing (FQ)
n
Describe and configure Priority Queuing (PQ)
n
Describe and configure Custom Queuing (CQ)
n
Describe and configure basic Weighted Fair Queuing (WFQ), distributed WFQ, ToS-based distributed WFQ and QoS-group-based distributed WFQ
n
Describe and configure Modified Weighted Round-robin (MDRR) queuing
n
Describe and configure IP RTP Prioritization
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Queuing Overview Question: Which queuing mechanisms do Cisco routers support? Answer: First In First Out (FIFO), Priority Queuing (PQ), Custom Queuing (CQ), Weighted Fair Queuing (WFQ) with the different distributed versions, Modified Deficit Round Robin (MDRR), IP RTP Prioritization, Class-based WFQ and Class-based Low-latency Queuing. Question: When is a software queuing mechanisms not used? Answer: Routers bypass the software queue (hold queue) if it is empty and there is room in the hardware queue (TxQ). Question: How does TxQ length affect the software queuing system? Answer: A long TxQ can cause FIFO drawbacks; a short TxQ can cause high CPU utilization and low link utilization.
FIFO Queuing Question: Why is FIFO the fastest queuing mechanism? Answer: It has no classification and the simplest scheduling mechanism. Question: Describe the classification and scheduling of FIFO queuing. Answer: FIFO has only one queue and all packets are enqueued into this queue. Scheduling takes packets out of the queue in the order they arrived (first come first serve). Question: List the drawbacks of FIFO queuing. Answer: FIFO queuing can cause starvation and jitter.
Priority Queuing Question: When would you use priority queuing? Answer: To provide minimum-delay forwarding for delay-sensitive packets. Question: What are the benefits and drawbacks of priority queuing? Answer: PQ has all the drawbacks of FIFO queuing within each class and in addition it can cause starvation of lower-priority classes. Question: How many classes does priority queuing support? Answer: PQ supports four classes. Question: How does priority queuing schedule packets? Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-143
Answer: PQ schedules packets in the priority order. Lower-priority packets are scheduled only when all higher-priority queues are empty.
Custom Queuing Question: When would you use custom queuing? Answer: CQ is used to guarantee bandwidth to traffic classes. Question: What are the benefits and drawbacks of custom queuing? Answer: CQ has all the drawbacks of FIFO queuing within each class. In addition CQ can cause jitter due to the implementation of scheduling. Question: How many classes does custom queuing support? Answer: CQ supports up to 16 classes. Question: How does custom queuing schedule packets? Answer: CQ uses weighted round robin scheduling to ensure that each class is serviced.
Weighted Fair Queuing Question: How does WFQ classify packets? Answer: WFQ classifies packets based on the flow information (source and destination IP addresses and TCP/UDP port numbers, protocol identifier and ToS field). Question: When does WFQ drop packets? Answer: WFQ drops packets of the longest queue when the number of packets in the queuing system reaches the CDT (congestive discard threshold). Question: How does WFQ schedule packets? Answer: WFQ schedules packets with the shortest finish time.
Distributed Weighted Fair Queuing Question: Which distributed Weighted Fair Queuing mechanisms do you know? Answer: Distributed WFQ versions: flow-based, ToS-based and QoS-groupbased. Question: What are the main differences between dWFQ versions? Answer: Distributed versions of WFQ differ primarily in the classification. Question: What platforms support dWFQ? Answer: Cisco 7x00 series routers with VIP-based interfaces support dWFQ. 3-144
Queuing Mechanisms
Copyright 2001, Cisco Systems, Inc.
Modified Deficit Round-robin Question: Describe the scheduling mechanism of MDRR. Answer: MDRR uses an improved implementation of round robin scheduling to provide more accurate allocation of bandwidth.
Question: Which two types of low-latency queuing does MDRR support? Answer: MDRR can use one queue for strict priority or alternate priority queuing. Question: What are the benefits and drawbacks of MDRR? Answer: MDRR is fast accurate and prevents head-of-line blocking in front of the crossbar switching matrix. MDRR only supports 8 queues and can only classify based on IP precedence.
Question: Where can MDRR be applied? Answer: MDRR can be used on output interfaces or in front of the crossbar switching matrix.
IP RTP Prioritization Question: When would you use IP RTP prioritization? Answer: To provide low-latency queuing with IOS versions that do not support CB-LLQ. Question: What are the drawbacks of IP RTP prioritization? Answer: Limited classification options (only one UDP port range is supported). Question: How many high-priority queues does IP RTP prioritization support? Answer: One per interface.
Copyright 2001, Cisco Systems, Inc.
Queuing Mechanisms
3-145
4
Traffic Shaping and Policing
Overview This module describes for the QoS mechanisms that are used to limit the available bandwidth to traffic classes. It discusses two options—traffic policing and traffic shaping. Committed Access Rate (CAR) is discussed as a mechanism to provide traffic policing. Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping (FRTS) are discussed as traffic shaping mechanisms. It includes the following topics: n
Traffic Shaping and Policing
n
Generic Traffic Shaping
n
Frame Relay Traffic Shaping
n
Committed Access Rate
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe and configure Generic Traffic Shaping (GTS)
n
Describe and configure Frame Relay Traffic Shaping (FRTS)
n
Describe and configure Committed Access Rate (CAR)
n
Identify other mechanisms that support traffic shaping and policing (Classbased Policing and Class-based Shaping)
Traffic Shaping and Policing Overview The lesson introduces mechanisms for traffic policing and traffic shaping. Committed Access Rate (CAR), Generic Traffic Shaping (GTS) and Frame Relay Traffic Shaping (FRTS) are introduced in this section.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
4-2
n
Describe the need for implementing traffic policing and shaping mechanisms
n
List traffic policing and shaping mechanisms available in Cisco IOS
n
Describe the benefits and drawbacks of traffic shaping and policing mechanisms
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Traffic Shaping and Policing Meter
Classifier
Marker
Dropper
Traffic stream
• Traffic Shaping and Policing mechanisms are used to rate-limit traffic classes • They have to be able to classify packets and meter their rate of arrival • Traffic Shaping delays excess packets to stay within the rate limit • Traffic Policing typically drops excess traffic to stay within the limit; alternatively it can remark excess traffic © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-5
Both shaping and policing mechanisms are used in a network to control the rate at which traffic is admitted into the network. Both mechanisms use classification, so they can differentiate traffic. They also use metering to measure the rate of traffic and compare it to the configured shaping or policing polic y. The difference between shaping and policing can be described in terms of their rate-limiting implementation: n
Shaping meters the traffic rate and delays excessive traffic so that it stays within the desired rate limit. With shaping, traffic bursts are smoothed out producing a steadier flow of data. Reducing traffic bursts helps reduce congestion in the core of the network.
n
Policing drops excess traffic in order to control traffic flow within specified limits. Policing does not introduce any delay to traffic that conforms to traffic policies. It can however, cause more TCP retransmissions, because traffic in excess of specified limits is dropped.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-3
Why Use Rate Limiting • To handle congestion at ingress to ATM/FR network with asymmetric link bandwidths • To limit access to resources when highspeed access is used but not desired • To limit certain applications or classes • To implement a virtual TDM system
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-6
Rate limiting is typically used to satisfy one of the following requirements:
4-4
n
Prevent and manage congestion in ATM and Frame Relay networks, where asymmetric bandwidths are used along the traffic path. This prevents the layer-2 network from dropping large amounts of traffic by differentiately dropping excess traffic at ingress to the ATM or Frame Relay networks based on Layer-3 information (for example: IP precedence, DSCP, access list, protocol type, etc.)
n
Limit the access rate on an interface when high-speed physical infrastructure is used in transport, but sub-rate access is desired.
n
Engineer bandwidth so that traffic rates to certain applications or classes of traffic follow a specified traffic -rate policy.
n
Implement a virtual TDM system, where an IP network is used, but has the bandwidth characteristics of a TDM system (that is, fixed maximum available bandwidth). Inbound and outbound policing can, for example, be used on one router to split a single point-to-point link into two or more virtual point-to-point links by assigning a portion of the bandwidth to each class, thus preventing any class from monopolizing the link in either direction.
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Typical Traffic Shaping or Policing Applications High-speed link
WAN
Output interface is not congested queuing and WRED do not work
Congestion in WAN network results in non-intelligent layer2 drops
256 kbps
128 kbps Server Farm
© 2001, Cisco Systems, Inc.
FastEthernet
64 kbps
Low-speed link
Limiting access to resources
Implementing a virtual TDM or Leased line over a single physical link on one side
Internet
IP QoS Traffic Shaping and Policing-7
The figure shows three possible applications of rate-limiting (shaping or policing) mechanisms. The first picture shows a Layer-2 WAN with unequal link bandwidths along a Layer-3 path. The ingress (left side) of the network has a highspeed link available into the Layer-2 backbone, which enables it to send traffic at a high rate. At the egress side, the sent traffic hits a low-speed link, and the Layer-2 network is forced to drop a large amount of traffic. If traffic were rate-limited at the ingress, optimal traffic flow occurs, resulting in minimal dropping by the Layer2 network. The second picture shows a hosting farm, which is accessible from the Internet via a shared link. Depending on the service contract, the hosting provider may offer different bandwidth guarantees to customers, and may want to limit the resources a particular server uses. Rate limiting can be used to divide the shared resource (upstream link) between many servers. The third example shows the option of implementing virtual leased lines over a Layer-3 infrastructure, where rate-limited reserved bandwidth is available over a shared link.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-5
Shaping vs. Policing • Benefits of Shaping – Shaping does not drop packets – Shaping supports interaction with Frame Relay congestion indication
• Benefits of Policing – Policing supports marking – Less buffer usage (shaping requires an additional queuing system)
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-8
A shaper typically delays excess traffic using a buffer, or mechanism, to hold packets and shape the flow when the data rate of the source is higher than expected. Traffic shaping smoothes traffic by storing traffic above the configured rate in a queue. Therefore, shaping increases buffer utilization on a router, but causes non-deterministic packet delays. Shaping can also interact with a Frame Relay network, adapting to indications of Layer-2 congestion in the WAN. A policer typically: n
Drops non-conforming traffic
n
Supports marking of traffic
n
Is more efficient in terms of memory utilization (no additional buffering of packets in needed)
n
Does not increase buffer usage
Both policing and shaping ensure that traffic does not exceed a bandwidth limit, but they have different impacts on the traffic:
4-6
n
Policing drops packets more often, generally causing more retransmissions of connection-oriented protocols
n
Shaping adds variable delay to traffic, possibly causing jitter
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
How do Routers Measure Traffic Rate Bandwidth
Link bandwidth Exceeding traffic Rate limit Conforming Traffic Time
• Routers use the Token Bucket mathematical model to keep track of packet arrival rate • The Token Bucket model is used whenever a new packet is processed • The return value is conform or exceed © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-9
In order to perform rate limiting, routers must meter (or measure) traffic rates through their interfaces. To enforce a rate limit, metered traffic is said to: n
Conform to the rate limit, if the rate of traffic is below or equal to the configured rate limit
n
Exceed the rate limit, if the rate of traffic is above the configured rate limit
The metering is usually performed with an abstract model called a token bucket, which is used when processing each packet. The token bucket can calculate whether the current packet conforms or exceeds the configured rate limit on an interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-7
Token Bucket
200 700
500 bytes
© 2001, Cisco Systems, Inc.
Conform Action
500 bytes
IP QoS Traffic Shaping and Policing -10
The token bucket is a mathematical model used in a device that regulates the data flow. The mode has two basic components: n
Tokens: where each token represents the permission to send a fixed number of bits into the network
n
The bucket: which has the capacity to hold a specified amount of tokens
Tokens are put into the bucket at a certain rate by the operating system. Each incoming packet, if forwarded, takes tokens from the bucket, representing the packet’s size. If the bucket fills to capacity, newly arriving tokens are discarded. Discarded tokens are not available to future packets. If there are not enough tokens in the bucket to send the packet, the regulator may: n
Wait for enough tokens to accumulate in the bucket (traffic shaping)
n
Discard the packet (policing)
The figure shows a token bucket, with the current capacity of 700 bytes. When a 500-byte packet arrives at the interface, its size is compared to the bucket capacity (in bytes). The packet conforms to the rate limit (500 bytes < 700 bytes), and the packet is forwarded. 500 tokens are taken out of the token bucket leaving 200 tokens for the next packet.
4-8
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Token Bucket
200
300 bytes
Exceed Action
s byte 300
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -11
When the next packet arrives immediately after the first packet, and no new tokens have been added to the bucket (which is done periodically), the packet exceeds the rate limit. The packet size is greater than the current capacity of the bucket, and the exceed action is performed (drop in the case of pure policing, delay in the case of shaping).
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-9
Token Bucket Be
Bc of tokens is added every Tc [ms]
Link BW
Link Utilization Bc
Bc
Bc
Bc
Bc
Bc
2*Tc
3*Tc
4*Tc
5*Tc
Tc = Bc / CIR Tc
Average BW (CIR)
Time
Bc + B e
• Bc is normal burst size (specifies sustained rate) • Be is excess burst size (specifies length of burst)
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -12
Token bucket implementations usually rely on three parameters: CIR, Bc and Be. CIR is the Committed Information Rate (also called the committed rate, or the shaped rate). Bc is known as the burst capacity. Be is known as the excess burst capacity. Tc is an interval constant that represents time. A Bc of tokens are forwarded without constraint in every Tc interval. In the token bucket metaphor, tokens are put into the bucket at a certain rate, which is Bc tokens every Tc seconds. The bucket itself has a specified capacity. If the bucket fills to capacity (Bc + Be), it will overflow and therefore newly arriving tokens are discarded. Each token grants permission for a source to send a certain number of bits into the network. To send a packet, the regulator must remove, from the bucket, the number of tokens equal in representation to the packet size. For example, if 8000 bytes worth of tokens are placed in the bucket every 125 milliseconds, the router can steadily transmit 8000 bytes every 125 milliseconds, if traffic constantly arrives at the router. If there is no traffic at all, 8000 bytes per 125 milliseconds get accumulated in the bucket, up to the maximum size (Bc+Be). One second’s accumulation therefore collects 64000 bytes worth of tokens, which can be transmitted immediately in the case of a burst. The upper limit, Bc+Be, defines the maximum amount of data, which can be transmitted in a single burst, at the line rate. Note
4-10
Again, note that the token bucket mechanism used for traffic shaping has both a token bucket and a queue used to delay packets. If the token bucket did not have a data buffer, it would be a policer. For traffic shaping, packets that arrive that cannot be sent immediately (because there are not enough tokens in the bucket) are delayed in the data buffer.
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Although token bucket permits burstiness, traffic bursts are bound. This guarantee is made so that traffic flow will never send faster than the token bucket's capacity. In the long-term, this means that the transmission rate will not exceed the established rate at which tokens are placed in the bucket (the committed rate).
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-11
Traffic Shaping and Policing Mechanisms • Shaping Mechanisms: – Generic Traffic Shaping (GTS) – Frame Relay Traffic Shaping (FRTS) – Class-based Shaping
• Policing Mechanisms: – Committed Access Rate (CAR) – Class-based Policing
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -13
There are five token-bucket based rate-limiting methods available in Cisco IOS. Three methods are shaping mechanisms: n
Generic traffic shaping
n
Frame Relay traffic shaping
n
Class-based shaping
Two methods are policing mechanisms: n
Committed access rate
n
Class-based policing
All these methods are discussed next in specific sections.
4-12
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Summary After completing this lesson, you should be able to perform the following tasks: n
Describe the need for implementing traffic policing and shaping mechanisms
n
List traffic policing and shaping mechanisms available in Cisco IOS
n
Describe the benefits and drawbacks of traffic shaping and policing mechanisms
Lesson Review Answer the following questions: 1. How do shaping and policing mechanisms keep track of the traffic rate? 2. Which shaping mechanisms are available with the Cisco IOS software? 3. Which policing mechanisms are available with the Cisco IOS software? 4. What are the main differences between shaping and policing?
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-13
Generic Traffic Shaping Overview This lesson describes the Generic Traffic Shaping (GTS) mechanism.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
4-14
n
Describe the GTS mechanism
n
Describe the benefits and drawbacks of GTS
n
Configure GTS on Cisco routers
n
Monitor and troubleshoot GTS
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Generic Traffic Shaping Meter
Classifier Traffic stream
Marker
Shaper Dropper
• Can shape multiple classes (classification) • Can measure traffic rate of individual classes (metering) • Delays packets of exceeding classes (shaping) © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -18
Generic Traffic Shaping (GTS) shapes traffic by reducing the outbound traffic flow to avoid congestion. This is achieved by constraining traffic to a particular bit rate using the token bucket mechanism. GTS is applied on a per-interface basis and can use access lists to select the traffic to shape. It works with a variety of Layer-2 technologies, including Frame Relay, ATM, Switched Multi-megabit Data Service (SMDS) and Ethernet. As shown in the block diagram, GTS performs three basic functions: n
Classification of traffic, so that different traffic classes can have different policies applied to them
n
Metering, using a token-bucket mechanism, to distinguish between conforming and exceeding traffic
n
Shaping, using buffering, to delay exceeding traffic and shape it to the configured rate limit
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-15
GTS Building Blocks
Forwarder
Classifier
Yes
Shaping WFQ
No
No No
Classifier
Yes
Yes
No
Classifier
Shaping WFQ
Yes Yes
No
Shaping WFQ
Yes
No
© 2001, Cisco Systems, Inc.
Physical Interface queue(s) IP QoS Traffic Shaping and Policing -19
GTS is implemented as a queuing mechanism, where there are separate WFQ delay queues implemented for each traffic class. Each WFQ-queue delays packets until they conform to the rate-limit, and also schedules them according to the WFQ algorithm. Conforming traffic is then sent to the physical interface. Arriving packets are first classified into one of the shaping classes. Traffic not classified into any class is not shaped. Classification can be performed using access lists. Once a packet is classified into a shaping class, its size is compared to the amount of available token in the token bucket of that class. The packet is forwarded to the main interface queue if there are enough tokens. A number of tokens taken out of the token bucket is equal to the size of the packet (in bytes). If, on the other hand, there are not enough tokens to forward the packet, the packet is buffered in the WFQ system assigned to this shaping class. The router will then periodically replenish the token bucket and check if there are enough tokens to forward one or more packets out of the shaping queue. Packets are scheduled out of the shaping queue according to the WFQ scheduling algorithm.
4-16
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS Overview • GTS is multiprotocol • GTS uses WFQ as the shaping queue • GTS can be implemented in combination with any queuing mechanisms: – FIFO Queuing – Priority Queuing (PQ) – Custom Queuing (CQ) – Weighted Fair Queuing (WFQ)
• GTS works on output only
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -20
The GTS implementation in Cisco IOS supports multiple protocols and works on a variety of interface types. WFQ is used as the shaping delay queue, providing fair scheduling within a traffic class. Other queuing strategies (FIFO, PQ, CQ and WFQ) may be employed after GTS to provide traffic scheduling on the shaped traffic. Also, GTS only works at the output of an interface. GTS can be used to shape all outbound traffic on an interface or it can separately shape multiple classes. Classification is performed using any type of access list including all non-ip access lists.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-17
GTS Implementation Dispatches packets at configured rate
Shaping Queue (WFQ)
Dispatches packets at line rate
Dispatches packets at line rate
Software Queue
Hardware Queue
(FIFO, PQ, CQ, WFQ, ...)
(FIFO)
Bypass the software queue if it is empty and there is room in the hardware queue
• The software queue may have no function if the sum of all shaping rates is less than link bandwidth © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -21
Packet flow through GTS is implemented using three queues. The first, the shaping queue, is WFQ-based and shapes traffic according to the specified rate using a token bucket model. This queue dispatches packets to the software queue, which may be configured with other queuing mechanisms (PQ, CQ, WFQ or FIFO). If the software queue is empty, traffic is forwarded directly to the output hardware queue. GTS supports distributed implementation on VIP adapters. This offloads traffic shaping from the route switch processor (RSP) to the Versatile Interface Processor (VIP), and constructs all of the queues in VIP packet memory. Only IP traffic can be shaped with dWFQ. Another requirement is that dCEF switching must be enabled.
4-18
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Configuring GTS Router(config-if)#
traffic-shape rate bit-rate [burst-size [excessburst-size]]
• Enables traffic shaping of all outbound (sub)interface traffic • In IOS versions prior to 11.2(19) and 12.0(4), optimum switching is disabled on all interfaces if traffic shaping is enabled on any interface
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -22
To enable traffic shaping for outbound traffic on an interface, use the trafficshape rate interface configuration command. Of the parameters to be specified, bit-rate is the only mandatory one. The burst-size and excess-burst-size are optional. Generic traffic shaping can be used in all switching paths. Older Cisco IOS versions may use slower switching paths when GTS is in effect.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-19
Configuring GTS Router(config-if)#
traffic-shape rate bit-rate [burst-size [excessburst-size]]
• Bit rate – average traffic rate in bps (equivalent to Frame Relay CIR) • Burst size – amount of traffic sent in a measurement interval in bits (equivalent to Frame Relay Bc) Default value: 1/8 of bit rate
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-23
Bit rate (in bits per second) is configured as the average traffic rate to which the traffic should be shaped on the output of the interface. Burst size (in bits) can be configured to allow for varying levels of allowed burstiness. That is, traffic, which bursts over the average traffic rate, also conforms if it falls within the burst rate in an interval. By default, this is set to one eighth of the average traffic rate, which sets the Tc at one eighth of a second. This parameter is equivalent to the Frame Relay Bc parameter.
4-20
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Configuring GTS Router(config-if)#
traffic-shape rate bit-rate [burst-size [excessburst-size]]
• Excess-burst-size - amount of excess traffic that can be sent during the first burst in bps (equivalent to Frame Relay Be) Default value: no excess burst • Measurement interval (Tc) is computed from bit-rate and burst -size Tc smaller than 25 ms is rejected, Tc greater than 125 ms is reduced © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -24
The excess-burst-size parameter (in bits), equivalent to the Frame Relay Be parameter, defines the excess burst of traffic, which can still be sent through the first noticed burst. By default, there is no excess burst allowed. The Tc parameter defines the measurement interval, which is used in the operation of the token bucket. By default, it is directly computed from the bit rate and the burst size as Bc divided by the average bit rate. To ensure proper operation of shaping, those parameters are bounded to values between 25 and 125 ms.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-21
Configuring GTS Router(config-if)#
traffic-shape group access-list bit-rate [burst [excess-burst]] • Shapes outbound traffic matched by the specified access list • Several traffic-shape group commands can be configured on the same interface • The “traffic-shape rate“ and “traffic-shape group“ commands cannot be mixed on the same interface • Separate token bucket and shaping queue is maintained for each traffic-shape group command • Traffic not matching any access list is not shaped
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -25
Classification of traffic to be shaped is performed using access lists. To enable traffic shaping based on a specific access list for outbound traffic on an interface, use the traffic-shape group interface configuration command. The traffic-shape group command allows specification of one or more previously defined access lists to shape traffic on the interface. One traffic-shape group command must be specified for each access list on the interface. Cisco IOS uses separate token buckets and shaping queues for each class, as differentiated by the access list specification. Traffic not matching any access list bypasses traffic shaping and is immediately sent to the software or hardware interface queue. Use the traffic-shape rate command if no classification is needed and shaping should be applied to all traffic. Remember that the traffic-shape group command using an IP access list permitting all IP traffic is not equivalent to the traffic-shape rate command if non-IP traffic is present in the network.
4-22
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS Example #1 • ISP wants to sell a service in which a customer may use all of a E1 line for 30 seconds in a burst, but on a long term average is limited to 256 kbps • GTS parameters – bit-rate: 256000 - output rate is 256000 bps – burst-size: 32000 the number of bits sent in 125 msec – excess-burst-size: 61440000 = 2048000 * 30
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-26
In the first GTS example, an ISP wants to control the amount of traffic injected into the Frame Relay WAN by the customer. The SP service uses an E1 line as the access line, limits the customer to 256 Kbps on the average, but also permits bursts of up to thirty seconds at the E1 line rate. The parameters are calculated based on the service requirements. CIR (the average bit rate) is set at the specified average rate, the burst size is set to one eighth of the CIR (32000 bits), and the excess burst size reflects the allowed thirtysecond burst at full E1 line rate. The excess burst size was calculated using the following formula: 1. Each second of transmission at line-speed requires 2 Mbits 2. Thirty second burst therefore requires 30 x 2 Mbits 3. The excess burst size is 30 x 2048000 = 61440000 It takes thirty seconds to empty the token bucket. How long does it take to fill it up again? The token bucket is emptied at 2Mbps but it is replenished at 256kbps. It takes eight times as long to fill it as it does to empty it. Every thirty second burst would, therefore, require a four-minute silence on the line to accumulate tokens.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-23
GTS Example #1
WAN Core Customer interface interface ethernet ethernet0/0 0/0 traffic-shape traffic-shape rate rate 256000 256000 32000 32000 61440000 61440000 !! interface interface serial1/0 serial 1/0 traffic-shape traffic-shape rate rate 256000 256000 32000 32000 61440000 61440000
• Since ISP wants to control the total amount of load the configuration would be done on both the inbound and outbound interfaces © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-27
The figure shows the router configuration required to implement this service. All the output traffic is shaped, and the shaping needs to be configured on all customer edge sites, which will perform admission control using GTS.
4-24
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS Example #2
WAN Core Customer interface interface ethernet ethernet 0/0 0/0 traffic-shape traffic-shape group group 101 101 64000 64000 interface interface serial serial 1/0 1/0 traffic-shape traffic-shape group group 101 101 64000 64000 !! access-list access -list 101 101 permit permit tcp tcp any any any any eq eq www www
• The customer wants to be sure that Web traffic will never use more than 64 kbps © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-28
In the second example, a customer wants to limit web usage, so that web traffic never uses more than 64 Kbps on the access link. The router configuration is shown in the figure, using default parameters for traffic bursts. An access list defines web traffic as the only shaped traffic. All other traffic bypasses GTS and can use the full access line bandwidth.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-25
Monitoring GTS Router(config)#
show traffic-shape
• Displays current traffic shaping configuration MAX = (Bc + Be)/8
Router#show access I/F list Se3/3
CIR
Be
Bc = Tc * CIR
traffic-shape Target Byte Sustain Excess Interval Increment Adapt Rate Limit bits/int bits/int (ms) (bytes) Active 100000 2000 8000 8000 80 1000 -
Bc
Tc=Bc/CIR
do we listen to FECN/BECN?
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-29
The figure shows the results of the show traffic-shape command issued on a router that shapes traffic to 100kbps with Bc and Be set to 8000. To display the current traffic-shaping configuration, use the show traffic-shape command. To display the current traffic -shaping statistics, use the show trafficshape statistics command. Output of both the commands is detailed in the ensuing figures. Information displayed includes:
4-26
n
The rate that traffic is shaped to
n
The maximum number of bytes transmitted per internal interval
n
Configured sustained bits per interval
n
Configured excess bits in the first interval
n
Interval being used internally (may be smaller than the committed burst divided by the CIR)
n
Number of bytes that will be sustained per internal interval
n
If Frame Relay has FECN/BECN adaptation configured
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Monitoring GTS Router(config)#
show traffic-shape statistic
• Displays traffic shaping statistics Number of packets/bytes sent on the interface
Router#show traffic-shape traffic-shape statistic statistic Access Packets Bytes Access Queue Queue Packets Bytes I/F List Depth List Depth Se3/3 77 16091 16091 3733112 3733112
Depth of the associated WFQ queue for delayed packets
Packets Packets Delayed 414 414
Bytes Bytes Delayed 96048 96048
Shaping Shaping Active Active yes yes
Subset of the previous number of packets/bytes delayed via the WFQ queue
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-30
The show traffic-shape statistics command displays the statistics of traffic shaping for all the configured interfaces. Displayed in the output is: n
The interface where the traffic-shape rate or traffic-shape group command is used (traffic-shape rate command is used on interface serial3/3 in the example)
n
The associated access list if the traffic-shape group command is used
n
The number of packets currently in the shaping queue (queue depth)
n
The total number of packets that have been processed by the traffic-shape command since the last clearing of interface counters (16091 packets in the example)
n
The total number of bytes that have been processed by the traffic-shape command since the last clearing of interface counters (3733112 bytes in the example)
n
The total number of packets that have been delayed by the traffic-shape command since the last clearing of interface counters (414 packets in the example)
n
The total number of bytes that have been delayed by the traffic-shape command since the last clearing of interface counters (96048 bytes in the example)
n
If the queue depth is more than 0 than shaping is active
The expected result of traffic shaping is a high ratio between transmitted packets and delayed packets. Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-27
If the number of delayed packets is very high (compared to the total number of packets) then there are probably non-responsive aggressive flows being shaped and the queue depth could show high buffer utilization. If the number of delayed packets is zero then it is very likely that the access list does not match any traffic.
4-28
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Monitoring GTS Router(config)#
show traffic-shape queue
• Displays the shaping queue contents router#show router#show traffic-shape traffic-shape queue queue Traffic queued in shaping queue on Serial0 (depth/weight) 1/4096 Conversation 254, linktype: linktype: ip, ip, length: 232 source: source: 1.1.1.1, 1.1.1.1, destination: destination: 1.1.2.47, id: 0x0001, ttl: ttl: 208, 208, TOS: TOS: 00 prot: prot: 17, source source port port 11111, 11111, destination destination port port 22222 22222
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -31
The show traffic-shape queue command displays the contents of the shaping queue associated with an interface. This command can be used to determine the types of flows that are congesting the shaping queue. The command displays the parameters that are used for classification within WFQ: n
Source IP address
n
Destination IP address
n
Time to live (TTL)
n
Type of Service (ToS) field
n
Protocol ID
n
Source port number
n
Destination port number
The example shows that there is a non-responsive UDP flow (protocol 17) congesting the shaping queue.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-29
GTS on Frame Relay Interfaces • GTS can be implemented on any type of (sub)interface • GTS supports additional features when implemented on Frame Relay interfaces: – Adaptation to Frame Relay congestion notification – BECT-to-FECN reflection – FECN creation on congestion
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -32
GTS applies on a per-interface basis, can use access lists to select the traffic to shape, and works with a variety of Layer-2 technologies, including: n
Frame Relay
n
ATM
n
Switched Multi-megabit Data Service (SMDS)
n
Ethernet
On a Frame Relay subinterface, GTS can be set up to shape to a specified rate and to adapt dynamically to available bandwidth by integrating Frame Relay congestion signaling with GTS.
4-30
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Frame Relay Refresher • Frame Relay Explicit Congestion Notification – FECN (Forward Explicit Congestion Notification) – BECN (Backward Explicit Congestion Notification) – CLLM (Consolidated Link Layer Management)
• Implicit Congestion Notification – Network discards detected by end user at higher layers – DE (Discard Eligibility) bit
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -33
Frame Relay performs congestion notification to its Layer-2 endpoints by including congestion signaling inside the Layer-2 frame headers. n
The FECN, BECN and DE bits in the Q.922 header of the frame provide inband congestion signaling.
n
The Forward Explicit Congestion Notification (FECN) is bit set by a Frame Relay network to notify a device (FR DTE, which may be a router) that it should initiate congestion avoidance procedures.
n
The Backward Explicit Congestion Notification (BECN) is bit set by a Frame Relay network to notify a device (DTE) that it should initiate proper congestion avoidance procedures.
n
CLLM is an enhanced signaling method, used by Frame Relay switches, which expands on the FECN/BECN mechanism to improve congestion management.
n
The Discard Eligibility (DE) bit indicates that a frame may be discarded in preference to other frames, if congestion occurs, to maintain the committed quality of service within the network. Frames with the DE bit set are considered Be excess data.
Congestion notification may be explicit (honored by Layer-2 devices) or implicit (detected and honored by higher-layer protocols, not by the Layer-2 network). FECN/BECN and CLLM are explicit methods, while BE-setting is an implicit notification method.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-31
Frame Relay FECN/BECN Congestion Control Switch Switch monitors monitors all all transmit transmit queues queues for for congestion congestion
S e n d e r
Frame 1
No Congestion this Side Frame Frame 22
BECN
Frame 11
Frame Frame Relay Relay Switch
FECN
Congestion this Side Frame 2
R e c e i v e r
Same Virtual Circuit (VC)
• FR Switch detects congestion on output queue and informs: – The receiver by setting the FECN bit on forwarded frames – The source by setting the BECN bit on frames going in the opposite direction © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -34
A Frame Relay switch can explicitly report congestion in two directions: Forward and Backward. When a frame queue inside a switch is congested, the switch will generate congestion signals based on the FECN and BECN bits. If congestion occurs in a queue towards the main receiver of traffic, FECN signals are sent to the receiving Layer-2 endpoint and BECN signals are sent to the sending Layer-2 endpoint. FECN and BECN bits are not sent as separate frames, but are piggybacked inside data frames.
4-32
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS Frame Relay Congestion Adaptability • On a Frame Relay (sub)interface, GTS can adapt dynamically to available Frame Relay bandwidth by integrating BECN signals – The GTS bit rate is reduced when BECN packets are received to reduce the data flow through congested Frame Relay network – Adaptation is done on per (sub)interface basis – GTS bit rate is gradually increased when the congestion is no longer present (no BECN packets are received any more)
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -35
BECN is the flag that the sending DTE (router as a Frame Relay endpoint) is able to integrate to determine the congestion status of the Layer-2 WAN.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-33
GTS Frame Relay Congestion Adaptability Mechanisms • Bit-rate adaptation – Traffic shaping bit-rate is reduced when a packet with BECN bit is received in the Tc – Traffic shaping bit-rate is increased if no BECN bits were received in the Tc
• FECN to BECN propagation – A test packet with BECN bit set is sent to the sender if a packet with FECN bit set is received
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -36
The first adaptation mechanism is bit-rate adaptation. GTS is able to respond to Layer-2 congestion by reducing its shaping rate to three-quarters of the current rate, until the Layer-2 network recovers from congestion. When BECN flags are no longer received, the rate is slowly ramped up again to the original shaping rate. This is also a lower limit of rate reduction, which bounds the reduction process so that at least some throughput is maintained. The BECN-integrating functionality is performed on a per sub-interface (DLCI) basis. However, if the congestion was caused by simplex traffic (such as a multicast video stream) or by an aggressive TCP connection, it is expected that the reverse traffic (frames flowing from the receiver to the sender, marked with the BECN bit) might come by less frequently than required to feed the integration. So the receiving DTE (the receiving router) can help matters when it receives a message with FECN set by first checking to see if it has any data, and if it does not, originating a message with BECN set. This message might be a Q.922 TEST RESPONSE message, which would by virtue of its message type be understood to be a message to discard and not reply to. This feature is called FECN-to-BECN propagation.
4-34
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
An Example of BECN Integration becn INC added every Tc in the token Bucket
9000
BECN Integration 8000
becn 7000
6000
5000
Inc
4000
traffic-shape rate 64000 8000 8000 traffic-shape adaptive 32000
3000
2000
BECN received at Tc#1 and Tc#3
1000
Hypothesis: no idle traffic
0 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
time represented in units of Tc © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -37
The figure shows the shaped rate of a token bucket-based GTS responding to BECN packets it received. As mentioned, the rate is reduced to three-quarters of the previous rate for every Tc interval, which saw at least one BECN message received at the router. When no BECN messages are received in a Tc period, the shaped rate is brought up slowly, up one-sixteenth of the current rate.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-35
FECN to BECN Propagation
S e n d e r
FECN
Frame Relay Switch Switch
Congestion
BECN in Q.922Test
R e c e i v e r
If there is no reverse traffic, the switch is not able to set BECN in frames going back to sender
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -38
The other adaptation method, FECN-to-BECN propagation, configures a Frame Relay sub-interface to reflect received FECN bits as BECN in Q.922 TEST RESPONSE messages. This enables the sender to notice congestion in the Layer2 network, even if there is no data traffic flowing from the receiver back to the sender.
4-36
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Configuring Bit-rate Adaptation Router(config-if)#
traffic-shape adaptive [bit-rate]
• Configures Traffic Shaping Frame Relay bit-rate adaptation bit-rate - lowest bit-rate the traffic is shaped to in response to continuous BECN signals Default: 1/2 the specified traffic shaping rate • Traffic shaping has to be enabled
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -39
Frame Relay bit rate adaptation is configured using the traffic-shape adaptive command, which specifies the lower limit to which the shaped rate should be reduced in presence of incoming BECN signals. By default, this is half the configured sustained (committed) rate in GTS. The bit rate is configured in bits per second.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-37
Configuring FECN to BECN propagation Router(config-if)#
traffic-shape traffic-shape fecn-adapt
• Configures the router to send Frame Relay TEST message with BECN bit set in response to receiving a frame with FECN bit set • Can be used without adaptive traffic shaping Router(config-if)#
traffic-shape traffic-shape fecn-create fecn-create
• Sets FECN bit in all outgoing packets that have been delayed due to traffic shaping • Use for debugging/simulation only © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -40
The traffic-shape fecn-adapt command enables the FECN-to-BECN propagation. It can be used without adaptive GTS, as configured with the previous command. This feature should be used for testing purposes only. If the feature is combined with the adaptation feature it is very likely that the first delayed packet will cause the shaping to slow down to the minimum shaping rate. For example: 1. Router A (sender) sends a frame with a FECN bit because it had to delay a packet. 2. Router B (receiver) replies with the TEST frame with the BECN bit set 3. Router A (sender) reduces the shaping rate due to the received BECN causing even more delay and more packets with the FECN bit set.
4-38
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS Frame Relay Adaptation Design Conservative scenario • Set shaping rate to CIR • Set minimum rate to MIR (or 1/2 CIR)
Optimistic scenario • Set shaping rate to EIR • Set minimum rate to CIR
Realistic scenario • Set shaping rate to EIR • Set minimum rate to MIR (or 1/2 CIR)
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -41
To illustrate different possibilities of adaptation, consider the following three scenarios for using GTS over a Frame Relay circuit n
In a conservative scenario, where there should be minimal congestion and dropping, the shaping rate is set to the contracted Frame Relay CIR (Committed Information Rate) and the minimum rate of adaptation is set either to MIR (Minimum Information Rate) or half the CIR value. MIR depends on the provider’s over provisioning of the network and can be as low as one-tenth of the CIR. This configuration minimizes dropping, but does not allow excess bandwidth to be fully utilized.
n
In an optimistic scenario, the normal shaping rate may be set to the EIR (Excess Information Rate) and the minimum rate to the CIR. This configuration would probably cause too much dropping in a loaded Frame Relay network.
n
In a realistic scenario, utilizing most excess bandwidth can be achieved by setting the shaping rate to the EIR and the minimum adaptation rate to the MIR (or half the CIR). This would allow full advantage to be made of the Frame Relay network, if possible, and to adapt to a realistic level if congestion is indicated.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-39
GTS Frame Relay Adaptation Example
WAN Core Customer
interface interface serial 0/0 0/0 traffic-shape traffic-shape rate rate 64000 8000 8000 traffic-shape traffic-shape adaptive adaptive 48000 48000
• EIR = 64 kbps • CIR = 48 kbps • Assumption: Frame Relay network is usually not congested © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -42
This GTS shape rate adaptation example shows a configuration of GTS, where traffic is shaped to the EIR of 64 Kbps, with the adaptive floor being equal to CIR, which is contracted at 48 Kbps. No FECN-to-BECN propagation is configured. This example would work optimally only if the Frame Relay network is unlikely to get congested because setting the adaptive floor to the CIR cannot lower the shaping rate below the CIR. Lowering the rate below the contracted CIR may be necessary in most commercial Frame Relay networks.
4-40
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Summary n
GTS can be applied only on output interfaces
n
GTS performs traffic shaping or smoothing
n
GTS cannot mark or drop packets
n
GTS supports BECN and FECN in Frame Relay environments
n
GTS does not support cascaded policies
n
GTS does not provide managed discard
n
GTS cannot run in distributed mode
n
GTS supports only extended IP access lists
n
GTS supports RSVP as it uses WFQ
Lesson Review Answer the following questions: 1. What software queuing mechanisms are supported in combination with GTS? 2. Which queuing structure does GTS use? 3. What features does GTS include when used on Frame Relay interfaces?
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-41
Frame Relay Traffic Shaping Overview The section describes the Frame Relay Traffic Shaping (FRTS) mechanism.
Objectives Upon completion of this section, you will be able to perform the following tasks:
4-42
n
Describe the FRTS mechanism
n
Describe the benefits and drawbacks of FRTS
n
Compare the GTS and FRTS mechanisms
n
Configure FRTS on Cisco routers
n
Monitor and troubleshoot FRTS
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Frame Relay Traffic Shaping Meter
Classifier
Marker
Traffic stream
Shaper Dropper
• Can NOT shape multiple classes • Can be implemented on per-vc basis (classification) • Can measure traffic rate of individual virtual circuits (metering) • Delays packets of exceeding VC-s (shaping) • Dynamic Traffic Throttling on a Per-VC Basis (BECN or ForeSight) • Enhanced Queuing Support on a Per-VC Basis (PQ, CQ or WFQ) © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -48
Cisco has long provided support for FECN for DECnet and OSI, and BECN for SNA traffic using LLC2 encapsulation and DE bit support. FRTS builds upon this existing Frame Relay support with additional capabilities that improve the scalability and performance of a Frame Relay network, thereby increasing the density of VCs and improving response time. Frame Relay Traffic Shaping (FRTS) can eliminate bottlenecks in Frame Relay networks that have high-speed connections at the central site and low-speed connections at branch sites. Rate enforcement can be configured to limit the rate at which data is sent on the VC at the central site. Using FRTS, rate enforcement can be configured to either the CIR or some other defined value such as the excess information rate on a per-VC basis. The ability to allow the transmission speed used by the router to be controlled by criteria other than line speed (that is, by the CIR or the excess information rate) provides a mechanism for sharing media by multiple VCs. Bandwidth can be allocated per VC, creating a virtual time-division multiplexing (TDM) network. PQ, CQ and WFQ can also be defined at the VC or subinterface level. Using these queuing methods allows for finer granularity in prioritising and queuing of traffic, thus providing more control over the traffic flow on an individual VC. If CQ is combined with the per-VC queuing and rate enforcement capabilities, Frame Relay VCs are enabled to carry multiple traffic types, such as IP, SNA and IPX, with guaranteed bandwidth for each traffic type. Using information contained in the BECN-tagged packets received from the network, FRTS can also dynamically throttle traffic. With BECN-based throttling, packets are held in the buffers of the router to reduce the data flow from the router into the Frame Relay network. The throttling is done on a per-VC basis and Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-43
the transmission rate is adjusted based on the number of BECN-tagged packets received. With the Cisco FRTS feature, ATM ForeSight closed loop congestion control can be integrated to actively adapt to downstream congestion conditions.
4-44
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
FRTS Building Blocks
No classifier, shaping performed on individual VC
Forwarder + Frame Relay maps
Enough Tokens?
Enough Tokens?
Shaping Queue
No
No Yes
Shaping Queue
Yes Enough Tokens?
No
Shaping Queue
Yes
Traffic for VCs that are not shaped
© 2001, Cisco Systems, Inc.
Physical Interface queue(s)
IP QoS Traffic Shaping and Policing-48
In this block diagram, FRTS operation on a physical Frame Relay interface is shown. There is no global pre-classification of traffic, but packets are sent to their individual VCs instead. Shaping is then performed on a per-VC basis, with a separate shaping queue/token bucket for each VC. Packets coming out of their individual per-VC shapers are then sent to the physical interface queue (Tx queue/Tx ring).
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-45
FRTS Overview • FRTS is multiprotocol • FRTS can use one of the following queuing mechanisms as the shaping queue: – Priority Queuing (PQ) – Custom Queuing (CQ) – Weighted Fair Queuing (WFQ)
• FRTS can only be implemented in combination with WFQ on the interface • FRTS works on output only
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -50
FRTS is a shaping implementation that supports multiple protocols. Unlike GTS, which performs a WFQ-based scheduling on the entry of the shaper with an arbitrary scheduling mechanism on the physical interface, FRTS performs its operations the other way around. FRTS can use priority queuing, custom queuing, or weighed fair queuing as the scheduling method on the entry of the shaper. This allows for finer granularity in the prioritization and queuing of traffic and provides more control over the traffic flow on an individual VC. If CQ is combined with the per-VC queuing and rate enforcement capabilities, Frame Relay VCs are enabled to carry multiple traffic types, with bandwidth guaranteed for each traffic type. For example, if CQ is combined with the per-VC queuing and rate enforcement capabilities, FR VC’s can be enabled to carry IP, SNA and IPX traffic, with bandwidth guaranteed for each. At the physical interface itself (after the packet has been fancy queued and shaped) WFQ needs to be enabled in conjunction with FRTS. WFQ is currently the only supported interface scheduling method. FRTS can only be configured on the output of an interface.
4-46
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
GTS vs. FRTS Generic Traffic Shaping
Frame Relay Traffic Shaping
• Works on any (sub)interface
• Works only on Frame Relay
• Shapes traffic on (sub)interface basis
• Shapes traffic of individual virtual circuits
• Any physical interface queuing can be used
• Only WFQ can be used on physical interface
• Only WFQ can be used for shaping queue
• CQ, PQ or WFQ can be used in shaping queue
Generic Traffic Shaping is equivalent to Frame Relay Traffic Shaping when it’s configured on point-to-point Frame Relay subinterfaces
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -51
The figure compares GTS to FRTS, based on their main differences. Generic Traffic Shaping: n
Works on any (sub) interface type
n
Shapes traffic on that (sub)interface basis
n
Can use any physical interface queuing (FIFO, PQ, CQ or WFQ)
n
Only uses WFQ as the shaping queue (that is, on the input of the shaper)
In contrast, Frame Relay Traffic Shaping: n
Works only on Frame Relay (sub) interfaces
n
Shapes traffic inside individual FR Virtual Circuits
n
Only permits WFQ as the physical interface queuing method
n
Can use any queuing method as the shaping queue (that is, on the input of the shaper)
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-47
Configuring FRTS • Define the shaping parameters (map-class) – Token-bucket parameters – Frame Relay congestion adaptation – Shaping queue type
• Enable Frame Relay traffic shaping on physical interface • Apply the shaping definition – For all VCs on (sub)interface – For individual PVC/SVC
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -52
Enabling FRTS on an interface enables both traffic shaping and per-VC queuing on all the interface's PVCs and SVCs. Traffic shaping enables the router to control the circuit's output rate and, if configured, to react to congestion notification information. Queuing enables per-VC scheduling of traffic to be shaped. Configuring FRTS involves: Step 1
4-48
Defining the shaping parameters with the map-class command
Step 2
Enabling FRTS on the physical interface
Step 3
Applying the shaping parameters to all, or selected, VCs on that interface
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Creating a Map Class Router(config)#
map-class frame-relay name
• Creates a new Frame Relay map class or starts editing existing map-class • Map class names are case sensitive
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -53
The map-class frame -relay command defines the per-VC shaping and queuing parameters. A case-sensitive name must be assigned to each map class.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-49
Define Map-class Shaping Queue Router(config-map-class)#
frame-relay priority-group number
• Selects priority queuing as the shaping queue structure Router(config-map-class)#
frame-relay custom-queue-list number
• Selects custom queuing as the shaping queue structure Router(config-map-class)#
frame-relay frame-relay fair fair cdt max-queue rsvp-queues rsvp-queues max-buf max-buf
• Selects WFQ as the shaping queue structure • FRF.12 requires weighted fair queuing © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -54
Inside the map class, the frame-relay priority-group, frame-relay customqueue -list, and frame-relay fair keywords enable a queuing discipline of either priority, custom or weighed fair queuing, respectively. This queuing discipline is used for traffic departing on a VC, before shaping is applied to it. If FRF.12 payload compression is used, WFQ needs to be configured as the queuing discipline.
4-50
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Define Traffic Shaping Parameters Router(config-map-class)#
frame-relay [in|out] [in|out] cir cir bit-rate frame-relay [in|out] [in|out] bc bits frame-relay [in|out] be bits
• Specifies the shaping parameters in CIR/Bc/Be values • Tc is computed from CIR and Bc • Only outgoing values can be specified for FRTS Router(config-map-class)#
frame-relay traffic-rate traffic-rate average-rate peak-rate
• Specifies only the CIR and peak rate • Tc is specified by the router • Bc and Be are computed from Tc, average and peak rate
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -55
Per-VC traffic shaping parameters specify shaping behavior for the configured map class. Two configuration mechanisms are available: n
Specification of CIR, Bc and Be parameters of the per-VC token bucket
n
Specification of per-VC average rate and peak rate, where Bc and Be are computed from the default Tc, average rate and peak rate
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-51
Define Congestion Adaptation Mechanism Router(config-map-class)#
frame-relay adaptive-shaping adaptive-shaping becn|foresight becn|foresight
• Enables adaptive shaping for the Frame Relay map class • Congestion indication mechanism could be BECN or Foresight (CLLM) Router(config-map-class)#
frame-relay mincir rate
• Specifies the minimum bit rate for congestion adaptation algorithm
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -56
As part of the map class definition, either BECN or ForeSight are used as the congestion backward notification mechanism to which traffic shaping will adapt. The BECN adaptation feature is the same as with GTS, thus the router reacts to received BECN signals by reducing its shaping rate. The ForeSight adaptation feature uses the network traffic control software used in Cisco Frame Relay switches. When the ForeSight feature is enabled on the switch, the switch will periodically send out a ForeSight message based on the time value configured. The time interval can range from 40 to 5000 milliseconds. The ForeSight feature allows Cisco Frame Relay routers to process and react to ForeSight messages and adjust VC-level traffic shaping in a timely manner. Note
The ForeSight feature is only available in combination with Cisco WAN switches.
The difference between the BECN and ForeSight congestion notification methods is that BECN requires a user packet to be sent in the direction of the congested DLCI to convey the signal. The sending of user packets is not predictable and, therefore, is not reliable as a notification mechanism. Rather than wait for user packets to provide the congestion notification, timed periodic ForeSight messages guarantee that the router receives notification before congestion becomes a problem. Traffic can be slowed down in the direction of the congested DLCI.
4-52
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Define Dedicated Queue for VoFR Packets Router(config-map-class)#
frame-relay voice bandwidth bps queue depth
• Creates dedicated queue for VoFR packets • VoFR queue has priority over regular queues configured on the same VC • Specified bandwidth has to include L2 and VoFR overhead • Voice calls over Frame Relay will not be placed unless the voice queue is configured • Voice over FR call will be rejected if there is not enough bandwidth available in the voice queue
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -57
The frame-relay voice-bandwidth map-class command is used to configure how much bandwidth is reserved for voice over Frame Relay (VoFR) traffic, if used in the network. The router then creates a dedicated priority queue, used only for VoFR traffic. If not enough reserved voice bandwidth remains on the PVC, any new calls that are attempted will be rejected. When the amount of bandwidth to allocate to voice is calculated, the overall bandwidth calculation must include the voice packetization overhead and not just the raw compressed speech codec bandwidth.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-53
Enable FRTS on an Interface Router(config-if)#
frame-relay traffic-shaping
• Enables Frame Relay traffic shaping on a physical interface • No special queuing can be configured on the interface • Weighted Fair Queuing is used as the physical interface queuing mechanism regardless of interface bandwidth
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-57
After the map class is configured, traffic shaping must be applied to the physical interface. As mentioned, WFQ is the only supported mechanism on the physical interface running FRTS.
4-54
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Apply FRTS to a VC Router(config-if)#
frame-relay class map-class-name
• Applies the specified Frame Relay map class to all VCs configured on the specified (sub)interface Router(config-if)#
frame-relay interface-dlci interface-dlci DLCI DLCI class map-class-name
• Applies the specified Frame Relay map class only to the specified DLCI • Traffic for DLCIs that have no map class defined (on DLCI or on (sub)interface) is not shaped © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -59
Map class settings are then applied to all or specific VCs on an interface or subinterface. All VCs without shaping information are not shaped and only use the physical interface queuing discipline (WFQ).
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-55
Frame Relay Traffic Shaping Example
Customer
interface Serial1/1 frame-relay frame -relay traffic-shaping ! interface Serial1/1.1 point-to-point point-to-point frame-relay frame -relay 101 WAN interface-dlci 101 class class slow_vcs slow_vcs ! interface Serial1/1.2 point-to-point Core point-to-point frame-relay frame -relay interface-dlci 102 102 class class fast_vcs fast_vcs ! map-class map-class frame-relay frame-relay fast_vcs fast_vcs frame-relay frame -relay custom-queue-list custom-queue-list 11 frame-relay frame -relay traffic-rate 32000 64000 ! map-class map-class frame-relay frame-relay slow_vcs slow_vcs frame-relay frame -relay priority-group 1 frame-relay frame -relay traffic-rate 9600 9600 16000 16000
• Customer uses different policies and queuing mechanisms for each DLCI © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-59
The figure shows an FRTS configuration example, where two VCs are individually shaped with two map class parameter sets. In this example, two generic map classes are defined, one for generic fast VCs and the other for slow VCs. The fast VC map class uses custom queuing to allocate bandwidth within the shaped rate. The slow VC map class uses priority queuing to always forward mission-critical traffic, and then shape it to the required rate.
4-56
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Frame Relay QoS Autosense • Frame Relay QoS parameters are usually defined manually on the router • The same parameters are also carried in ELMI (CLLM) messages • QoS Autosense allows the router to learn the DLCI QoS parameters from the switch – ELMI must be configured on the router and the switch – Only Cisco Frame Relay switches are supported
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -61
When used in conjunction with traffic shaping, the router can respond to changes in the network dynamically. This optional feature allows the router to learn QoS parameters from the Cisco switch and use them for traffic shaping, configuration, or management purposes. Enhanced Local Management Interface (ELMI) also simplifies traffic shaping configuration on the router. Previously, users needed to configure traffic shaping rate enforcement values, possibly for every VC. Enabling ELMI reduces the chance of specifying inconsistent or incorrect values when configuring the router. It is not necessary to configure traffic shaping on the interface to enable ELMI. One option is to enable it to learn what values being used by the switch. If the router is required to respond to the QoS information received from the switch by adjusting the output rate, traffic shaping must be configured on the interface using the frame-relay traffic-shaping command in interface configuration mode.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-57
Configuring QoS Autosense Router(config-if)#
frame-relay qos-autosense
• Enable the Enhanced Local Management Interface feature • Allows QoS parameters (CIR, Bc, Be) to be passed by the switch to the router automatically in ELMI messages
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -62
The frame-relay qos-autosense command enables:
4-58
n
ELMI on the router
n
The router to learn QoS parameters from the switch over the ELMI protocol
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Monitoring Frame Relay Traffic Shaping • Show frame-relay PVC – Displays VC QoS and shaping parameters
• Show traffic-shape statistics – Displays GTS and FRTS statistics
• Show traffic-shape queue – Displays GTS and FRTS shaping queue contents
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -63
The listed show commands enable monitoring of per-VC QoS and general GTS parameters.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-59
Display PVC Information Router#
show frame-relay pvc
• Displays VC QoS and shaping parameters Router#show Router#show frame-relay frame-relay pvc pvc 20 20 PVC PVC Statistics Statistics for for interface interface Serial4/0 Serial4/0 (Frame (Frame Relay Relay DCE) DCE) DLCI DLCI == 20, 20, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.1 Serial4/0.1 input output in input pkts pkts 16963 16963 output pkts pkts 33632 33632 in bytes bytes 4669839 4669839 out dropped pkts in out bytes bytes 12442428 12442428 pkts 00 in FECN FECN pkts pkts 00 in out out in BECN BECN pkts pkts 00 out FECN FECN pkts pkts 00 out BECN BECN pkts pkts 00 in DE pkts 0 out DE pkts 0 in DE pkts 0 out DE pkts 0 out out out bcast bcast pkts pkts 31361 31361 out bcast bcast bytes bytes 9095644 9095644 Shaping Shaping adapts adapts to to BECN BECN pvc pvc create create time time 1w3d, 1w3d, last last time time pvc pvc status status changed changed 1w3d 1w3d cir bc be limit interval cir 64000 64000 bc 64000 64000 be 00 limit 1000 1000 interval 125 125 mincir 32000 byte increment 1000 BECN response yes mincir 32000 byte increment 1000 BECN response yes pkts bytes pkts bytes pkts 1103 1103 bytes 1632516 1632516 pkts delayed delayed 1091 1091 bytes delayed delayed 16287 16287 shaping shaping active active traffic traffic shaping shaping drops 1136 Current Current fair fair queue queue configuration: configuration: Discard Dynamic Reserved Discard Dynamic Reserved threshold queue threshold queue count count queue queue count count 64 16 00 64 16 Output Output queue queue size size 46/max 46/max total 50/drops 1136 © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-63
The show frame -relay pvc command displays information about individual FR PVC status and provides information about:
4-60
n
Configured CIR
n
Shaping
n
Queuing
n
Congestion adaptation
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Display Shaping Statistics Router#
show traffic-shape statistics
• Displays GTS and FRTS statistics Router#show Router#show traffic-shape traffic-shape statistics statistics Access Packets Access Queue Queue Packets I/F List Depth I/F List Depth Se4/0.1 50 1283 Se4/0.1 50 1283 Se4/0.2 00 14 Se4/0.2 14
Bytes Bytes 1903236 1903236 4060
Packets Packets Delayed Delayed 1271 1271 0
© 2001, Cisco Systems, Inc.
Bytes Bytes Delayed Delayed 1899472 1899472 0
Shaping Shaping Active Active yes yes no
IP QoS Traffic Shaping and Policing -65
The show traffic-shape statistics command displays the statistics of traffic shaping for all configured interfaces. In the output, the amount of delayed traffic, the shaping queue sizes and the amount of transmitted traffic is displayed. Displayed in the output is: n
The interface where the frame-relay taffic-shaping command is used
n
The number of packets currently in the shaping queue (queue depth)
n
The total number of packets that have been processed by the frame-relay taffic-shaping command since the last clearing of interface counters (16091 packets in the example)
n
The total number of bytes that have been processed by the frame-relay tafficshaping command since the last clearing of interface counters (3733112 bytes in the example)
n
The total number of packets that have been delayed by the frame-relay tafficshaping command since the last clearing of interface counters (414 packets in the example)
n
The total number of bytes that have been delayed by the frame-relay tafficshaping command since the last clearing of interface counters (96048 bytes in the example)
n
If the queue depth is more than 0 than shaping is active
The expected result of traffic shaping is a high ratio between transmitted packets and delayed packets.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-61
If the number of delayed packets is very high (compared to the total number of packets) then there are probably non-responsive aggressive flows being shaped and the queue depth could show high buffer utilization. If the number of delayed packets is zero then it is very likely that the access list does not match any traffic.
4-62
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Display Shaping Queue Information Router#
show traffic-shape queue
• Displays GTS and FRTS shaping queue contents Router#show Router#show traffic-shape traffic-shape queue queue Traffic Traffic queued queued in in shaping shaping queue queue on on Serial4/0.1 Serial4/0.1 dlci dlci 20 20 Queueing Queueing strategy: strategy: weighted weighted fair fair Queueing Queueing Stats: Stats: 46/50/64/1377 46/50/64/1377 (size/max (size/max total/threshold/drops) Conversations Conversations 1/2/16 1/2/16 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) (depth/weight/discards/tail (depth/weight/discards/tail drops/interleaves) drops/interleaves) 46/32384/1377/0/0 46/32384/1377/0 /0 Conversation Conversation 5, 5, linktype: linktype: ip, ip, length: length: 1504 1504 source: source: 193.77.3.1, 193.77.3.1, destination: destination: 193.77.3.1, 193.77.3.1, id: id: 0x00F4, 0x00F4, ttl: ttl: 255, 255, prot: prot: 1
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -66
The show traffic-shape queue command displays the queuing configuration of individual interfaces.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-63
Display Shaping Queue Information PE_2#show PE_2#show traffic-shape traffic-shape queue queue Traffic Traffic queued queued in in shaping shaping queue queue on on Serial4/0.1 Serial4/0.1 dlci dlci 20 20 Queueing Queueing strategy: strategy: priority-group priority-group 11 Queueing Queueing Stats: Stats: high 16/20/19 (queue/size/max total/drops) Packet Packet 1, 1, linktype: linktype: ip, ip, length: length: 1504, 1504, flags: flags: 0x10000048 source: source: 193.77.3.1, 193.77.3.1, destination: destination: 193.77.3.1, 193.77.3.1, id: id: 0x0141, 0x0141, ttl: ttl: 255, 255, prot: prot: 11 data: data: 0x0800 0x0800 0x9105 0x9105 0x2659 0x2659 0x1F89 0x1F89 0x0000 0x0000 0x0000 0x0000 0x3819 0x3819 0x223C 0x223C 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD Packet Packet 2, 2, linktype: linktype: ip, ip, length: length: 1504, 1504, flags: flags: 0x10000048 source: source: 193.77.3.1, 193.77.3.1, destination: destination: 193.77.3.1, 193.77.3.1, id: id: 0x0141, 0x0141, ttl: ttl: 255, prot: prot: 11 data: data: 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -67
The show traffic-shape queue command also displays the contents of the shaping queue associated with an interface. The example shows the contents of the high queue in the Priority Queuing system used as the shaping queue.
4-64
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Summary n
FRTS enables granular, per-VC queuing and shaping definition
n
FRTS can be applied only on output interfaces
n
FRTS enables per-VC queuing, which is performed before shaping
n
FRTS performs traffic shaping or smoothing within a VC
n
FRTS supports the same congestion adaptation mechanisms as GTS
Lesson Review Answer the following questions: 1. What are the main differences between GTS and FRTS? 2. Where can FRTS be used? 3. What classification options does FRTS have?
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-65
Committed Access Rate Overview The lesson describes the Committed Access Rate (CAR) mechanism.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
4-66
n
Describe the CAR mechanism
n
Describe the benefits and drawbacks of CAR
n
Describe the differences between CAR, GTS and FRTS
n
Configure CAR on Cisco routers
n
Monitor and troubleshoot CAR
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Committed Access Rate Meter Inbound or Outbound
Classifier
Marker
Dropper
• Primarily intended for rate limiting • Can be used on inbound and outbound traffic • Does not queue (delay) packets • Can also mark packets • Can be implemented for differentiated marking © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -72
Committed Access Rate (CAR) provides the capability to allow the service provider to rate-limit traffic in and out of router interfaces, thereby enabling various forms of ingress and egress rate-limiting in a network. CAR is a policing mechanism, not a queuing mechanism. Therefore it does not buffer or delay packets, which do or do not conform to the policy, but simply rate-limits them according to a simple “forward or drop” policy, according to the configuration. CAR also uses a token-bucket metering mechanism, similar to GTS, but without a delay queue. The CAR rate-limiting feature manages a network's access bandwidth policy by ensuring that traffic falling within specified rate parameters is sent, while dropping packets that exceed the acceptable amount of traffic or sending them with a different priority. CAR is often configured on interfaces at the edge of a network to limit traffic into or out of the network. CAR can also be used for packet marking. The operator can specify a policy that determines which packets should be assigned to which traffic class, and use CAR to implement the marking. The IP header already provides a mechanism to do this, namely the three precedence bits in the ‘type of service’ field in the IP header. CAR allows the setting of policies, based on information in the IP or TCP header such as IP address, application port, physical port or sub-interface, IP protocol, etc., to decide how the precedence bits should be marked or “colored.” Once marked, appropriate treatment can be given in the backbone to ensure that premium packets receive premium service in terms of bandwidth allocation, delay control, etc.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-67
Note
CAR can also be used to police (or “recolor”) precedence bits set externally to the network either by the customer or by a downstream service provider. Thus the network can decide to either accept or override external decisions.
CAR is implemented using the following abstract mechanisms:
4-68
n
The classifier, which differentiates traffic into multiple classes, which may be treated in a discriminate manner
n
The meter, which uses a token-bucket scheme to measure the rate of classified traffic
n
The marker, which can be used to mark or re-mark classified traffic (for example, with precedence or DSCP values)
n
The dropper, which may drop packets (in the rate-limiting scenario) according to the configured policy
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR on Input and Output Meter
Inbound
Classifier
Marker
Dropper
Forwarding Outbound
Meter
Classifier
Marker
Dropper
Queuing
• CAR on input is processed just before forwarding (most other QoS mechanisms are processed before CAR) • CAR on output is processed immediately after forwarding (most other QoS mechanisms are processed after CAR) © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -73
CAR can be configured on router input or output interfaces. When configured on the input side, CAR is usually processed last in a series of QoS mechanisms. Therefore, CAR rate-limiting and marking occurs just before the forwarding decision. On the output side, CAR is processed just after the forwarding decision. Therefore all output QoS mechanisms (queuing, WRED, etc.) are generally processed after CAR. VIP-based distributed CAR (dCAR) is a version of CAR that runs on the Versatile Interface Processor (VIP). It is supported on the Cisco 7500 routers with a VIP2-40 or later versatile interface processor. Distributed Cisco Express Forwarding (dCEF) switching must be enabled on any interface that uses dCAR, even when only output-based CAR is configured.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-69
CAR Implementation Dispatches packets at configured rate
CAR
Dispatches packets at line rate
Dispatches packets at line rate
Software Queue
Hardware Queue
(FIFO, PQ, CQ, WFQ, ...)
(FIFO)
Bypass the software queue if it is empty and there is room in the hardware queue
• The software queue may have no function if the sum of all CAR rates is less than link bandwidth © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -74
Whether configured on input or output, CAR has the option of managing throughput on a certain interface’s output. With the Cisco IOS queuing design, there are two output queues: n
A software queue, which may be configured for different queuing types (for example: FIFO, Priority Queuing, Custom Queuing, Weighted Fair Queuing)
n
A hardware interface queue, which is always FIFO and immediately used, if the software queue is empty
One possible implementation caveat arises when CAR is configured so that the aggregate policed bandwidth of output flows does not exceed the link bandwidth. In that case, the software queue is always empty and there is no queuing impact on traffic.
4-70
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Interface-wide CAR Diagram drop
Class Class 1? 1?
transmit
CAR CAR continue drop
Class Class 2? 2?
transmit
CAR CAR
Output Queue or Forward
continue
drop
Class n?
transmit
CAR CAR
• CAR has three different actions: – Transmit – Continue – Drop © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -75
The basic rate-limiting function of CAR does the following: n
Allows control of the maximum rate of traffic transmitted or received on an interface.
n
Provides the ability to define Layer-3 aggregate or granular rate limits and to specify traffic -handling policies when the traffic either conforms to or exceeds the specified rate limits.
n
Uses granular bandwidth rate limits to match a particular type of traffic based on precedence, MAC address, or other parameters.
When CAR is in effect, traffic is first classified and then undergoes CAR processing. CAR then meters the traffic and, based on the result of CAR metering, traffic either conforms or exceeds the configured policy. There are three possible basic actions on each packet, depending on it conforming or exceeding the policy: n
Transmit—the packet is sent.
n
Drop—the packet is discarded.
n
Continue—the packet is evaluated using the next rate policy in a chain of rate limits. If there is not another rate policy, the packet is sent.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-71
CAR Diagram Meter Meter
Conforms? Conforms?
Yes / No
Transmit? Transmit?
Yes
Forward or Enqueue
No Mark? Mark? Set Set IP IP prec? prec? Set Set DSCP? DSCP? Set Set MPLS MPLS exp? exp? Set Set QoS QoS grp? grp?
Continue? Continue? Yes
Yes
Yes
Yes
Set SetIP IPPrecedence Precedence Set Set DSCP DSCP
Yes
Go to Next CAR command
No Drop? Drop?
Yes
Set Set MPLS MPLS Experimental Set Set QoS QoS Group Group
• Marking depends on whether the packet conforms to or exceeds the policy © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -76
As mentioned previously, CAR can also be used to mark or remark traffic as well as performing rate limiting. Depending on traffic conformance, the following marking/remarking actions can be performed within CAR processing:
4-72
n
Set precedence (or DSCP value) and transmit—the IP Precedence (ToS) or DSCP bits in the packet header are rewritten. The packet is then sent. This action can be used to either color (set precedence) or recolor (modify existing packet precedence) the packet.
n
Set MPLS experimental bits and transmit – the MPLS experimental bits can be set. These are usually used to signal QoS parameters in a MPLS cloud.
n
Set QoS group and transmit—the QoS group can be set. It is only used locally within the router. The QoS group can be used in later QoS mechanisms and performed in the same router, such as CB-WFQ.
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Configuring CAR Router(config-if)# rate-limit {input | output} [access-group [rate-limit] #acl | qos-group number | dscp dscp dscp] mean-rate B cc Bee conform-action { drop || transmit transmit || continue continue || set-prec-transmit value | set-prec-continue set-prec-continue value value | set-qos-transmit value | set-qos-continue value set-dscp-transmit value | set-dscp-continue set-dscp-continue value value | set-mpls-transmit value | set-mpls-continue value value } exceed-action {{ drop | transmit | continue | set-prec-transmit value | set-prec-continue set-prec-continue value value | set-qos-transmit value | set-qos-continue value set-dscp-transmit value | set-dscp-continue set-dscp-continue value value | set-mpls-transmit value | set-mpls-continue value value }
• Specifies all four conditioner elements for a particular traffic class • Repeat this command for different classes of traffic • If a match is not found, the default action is to transmit © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -77
To configure CAR and Distributed CAR (dCAR) policies, use the rate-limit interface configuration command. The figure illustrates all the command options which are discussed in detail on the following pages. A single CAR rate policy includes information about the rate limit, conform actions and exceed actions. Each interface can have multiple CAR rate policies corresponding to different types of traffic. For example, low priority traffic may be limited to a lower rate than high priority traffic. When there are multiple rate policies, the router examines each policy in the order entered until the packet matches. If no match is found, the default action is to transmit. Rate policies can be independent: each rate policy deals with a different type of traffic. Alternatively, rate policies can be cascading: a packet may be compared to multiple different rate policies in succession. Cascading of rate policies allows a series of rate limits to be applied to packets to specify more granular policies. For example, the total traffic on an access link can be rate limited to a specified subrate bandwidth, and then the World Wide Web traffic on the same link can be limited to a given proportion of the subrate limit. CAR can be configured to match packets against an ordered sequence of policies until an applicable rate limit is encountered—that is, rate limiting several MAC addresses with different bandwidth allocations at an exchange point. Up to a 100 rate polic ies can be configured on a subinterface. The CAR action may be one of the following: n
Continue: evaluate the next rate-limit command
n
Drop: drop the packet
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-73
4-74
n
Set-prec-continue new-prec: set the IP Precedence and evaluate the next rate-limit command
n
Set-prec-transmit new-prec: set the IP Precedence and send the packet
n
Set-dscp-continue new-prec: set the DSCP value and evaluate the next ratelimit command
n
Set-dscp-transmit new-prec: set the DSCP value and send the packet
n
Set-mpls-continue new-prec: set the MPLS experimental bits and evaluate the next rate-limit command
n
Set-mpls-transmit new-prec: set the MPLS experimental bits and send the packet
n
Transmit: send the packet
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR Classification Router(config-if)#
rate-limit {input | output} [access-group [rate-limit] [access-group [rate-limit] #acl | qos-group number number | dscp dscp] ...
• IP packets are classified: – based on their direction (input or output)
• Optional classification based on: – numbered IP access list (standard or extended) – IP precedence rate-limit access list – MAC address rate-limit access list – QoS-group set by a previous conditioner in the same node – DSCP © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-77
CAR classifies traffic using many IOS-based classification mechanisms. The most basic classification is to first specify whether inbound or outbound traffic on the interface is being policed. Then, additional more granular specification can further classify traffic that needs to be policed separately.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-75
Null CAR Classifier Router(config-if)#
rate-limit {input | output} ...
• Selects packets in ingress or egress direction that have not been classified with any previous rate-limit commands on this interface • Usually used as the last rate-limit command on an interface
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -78
The null CAR classifier is in effect when no additional classifiers are present, apart from the input or output application of the rate-limiting rule. This can be used either as a default rate-limiting class (used as the last rate-limit command on the interface to classify packets, not classified by any previous rules), or, if only global policy is applied to an interface, classifying all traffic into one group (that is, policing to a specified aggregate input rate).
4-76
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR Classifier Based on IP Access List Router(config-if)#
rate-limit {input | output} access-group number ...
• Classifies packets received over an interface with the IP access list • Classification based on IP precedence can be done with IP access list Router(config)# access-list access-list acl-index acl-index {deny {deny | permit} permit} source [source-wildcard] access-list access-list acl-index acl-index {deny {deny | permit} permit} protocol source sourcewildcard destination destination-wildcard [precedence precedence] [tos tos] [dscp dscp] [log]
• Configures an IP access list to be used as packet classifier © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -80
The basic classification of traffic is based on extended IP access lists, which describe traffic based on Layer-3 and Layer-4 parameters, such as source and destination IP addresses, protocols and port numbers. Normal IOS access control lists are used and then applied to the interface rate-limit command. As IOS access lists can filter on IP precedence, access-list based classification can also classify traffic solely on IP precedence. Such an approach is not recommended if only precedence-based classification is desired, as there is a more efficient mechanism present.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-77
CAR Classifier Based on IP Precedence Router(config-if)#
rate-limit {input | output} access-group rate-limit number ...
• The IP precedence classifier uses rate-limit access lists from 1 to 99 to match on IP precedence values
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -81
To classify incoming or outgoing traffic based solely on IP precedence, rate-limit access lists can be used. Rate-limit access lists match only on the precedence bits in the IP header, and can perform precedence matching with a wildcard specification.
4-78
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
IP Precedence-based Rate-limit Access List Router(config)#
access-list rate-limit rate-limit acl-index precedence precedence
• ACL index is between 1 and 99 • Matches packets with specified IP precedence • Only one line is allowed in the access list Router(config)#
access-list rate-limit rate-limit acl-index mask precedence-mask
• ACL index is between 1 and 99 • Matches packets that match any precedence value specified in the mask • Precedence mask has one bit for each precedence value (bit 0 = precedence 0) © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -82
To configure classification rules on the IP precedence value, use the access-list rate-limit global configuration command. The CAR process then treats packets with different IP precedence differently. Use the mask keyword to assign multiple IP precedence values to the same rate-limit list. The ACL indices for precedencebased classification range from 1 to 99.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-79
CAR Classifier Based on Upstream MAC Address Router(config-if)#
rate-limit {input | output} access-group rate-limit number ...
• The upstream MAC address classifier uses rate-limit access lists from 100 to 199 to match on the MAC address of upstream router or host
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -83
Rate-limit access lists are also used to classify traffic based on the upstream MAC address. That is, for output-based CAR, traffic is classified on the destination MAC address, and for input-based CAR, traffic is classified using the source MAC address. MAC-based classification is particularly useful at ISP peering points, where a multi-access LAN network connects ISP border routers. MAC-based classification can classify traffic based on their upstream neighbor (another ISP border router) and on their QoS peering policy with other providers.
4-80
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
MAC Address Rate-limit Access List Router(config)#
access-list rate-limit acl-index mac-address
• ACL index is between 100 and 199 • Matches packets received from upstream neighbor with specified MAC address • Only MAC address is allowed in the access list (each upstream neighbor requires a different ratelimit statement)
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -84
To configure classification rules on the upstream MAC value, use the access-list rate-limit global configuration command. The CAR process then treats packets with different upstream (source or destination) MAC addresses differently. The ACL indices for precedence-based classification range from 100 to 199.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-81
QoS-group CAR classifier Router(config-if)#
rate-limit {input | output} qos-group number ...
• Selects IP packets already marked in this node with specified QoS group • QoS group marking could be done through: – Policy-based routing – CEF marking based on QPPB – Inbound rate-limit on another interface – Inbound Class-based Marking on another interface
• Available only on high-end platforms
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -85
The operator may also classify traffic based on their QoS group value. The QoS group is a tag, which may be assigned to each packet during the forwarding process, and is local to the router. The QoS group may be set: n
By some marking mechanism in the same router, such as policy routing, inbound rate-limiting on another interface, or inbound class-based marking on another interface.
n
By QPPB (QoS Policy Propagation through BGP), which distributes centrally administered QoS group values to routers over BGP sessions. The routers automatically mark traffic based on the QPPB-learned policy during the CEF forwarding process.
The QoS-group-based classification and marking is generally available only on high-end router platforms.
4-82
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
DSCP-based CAR Classifier Router(config-if)#
rate-limit {input | output} dscp dscp ...
• Selects IP packets marked with the specified DiffServ Code Point • DSCP marking could be done through: – Rate-limit on another interface or router – Class-based Marking on another interface or router
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -86
In a DiffServ-based model, the whole DSCP value can be used as the packet classifier. The marking of the DSCP value is accomplished through class-based marking or rate limiting on another interface or router.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-83
CAR Meter Router(config-if)#
rate-limit {input | output} [access-group [access-group [rate-limit] [rate-limit] number | qos-group number | dscp dscp] mean-rate Bc Bee ...
• The rate-limit meter measure the contract compliance of traffic class selected with classifier • Modified token-bucket algorithm is used – mean-rate specifies average traffic rate – B c specifies the normal burst size – B e specifies the excess burst size
• Token-bucket size is defined by Be alone © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -87
The CAR metering mechanism uses a modified token bucket scheme, which decides whether a packet conforms or exceeds the contracted rate. CAR is configured with three parameters: n
Mean rate specifies the average traffic rate which traffic should be policed to (analogous to committed rate with GTS). This is the long-term sustained throughput through the CAR policing mechanism.
n
Bc specifies the normal burst size, which is the amount of tokens added periodically to the token bucket.
n
Be specifies the excess burst size, which equals the size of the bucket in the CAR implementation. This is the maximum burst size that can be sent by the token bucket at one time, at the access line rate.
If CAR is used as a pure policer, packets exceeding the contracted rate are dropped.
4-84
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR Actions • CAR actions can be split into two sub-actions: – Marking action – Processing action
• Marking actions support the setting of: – – – –
IP precedence DSCP MPLS experimental bits QoS group
• Processing actions: – Transmit – packet is transmitted – Continue – packet is also processed by the next “rate-limit” command – Drop – packet is dropped © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -88
CAR actions can be divided into marking and processing actions. The marking actions support the setting of QoS signaling values inside the packet header (precedence, DSCP, MPLS experimental) or locally to the router (QoS group). The processing actions define the basic action of a single CAR rule. Those actions may be to transmit (forward) the packet immediately, drop the packet, or continue with the evaluation of the next CAR rule. Each CAR rate limit statement is checked sequentially for a match. When a match is found, the CAR meter (the token bucket), if there is one, is evaluated. If the action is a “continue” action, the policer will go to the next rate-limit on the list to find a subsequent match. If a match is found the traffic is subjected to the next applicable rate-limit. If an end of rate-limit list is encountered without finding a match or “continue” action, the default behavior is to transmit.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-85
CAR Actions • Processing actions “transmit”, “continue” and “drop” can be used as stand-alone actions • Processing actions “transmit” and “continue” can be combined with marking actions (set-mark_actionproc_action): – – – – – – – –
set-prec-transmit set-qos-transmit set-mpls-transmit set-dscp-transmit set-prec-continue set-qos-continue set-mpls-continue set-dscp-continue
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -89
The three processing actions can be used stand-alone to enforce a pure ratelimiting functionality. Alternatively, the “transmit” and “continue” actions can be, and often are, combined with marking actions, whic h enable further differentiation of the traffic.
4-86
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR Actions • Conforming and exceeding packets can be configured with different actions • There are three typicall usages of CAR: – Pure rate limiting • Transmit conforming packets • Drop exceecing packets
– Differentiated marking • Transmit conforming packets with marker value x (e.g IP precedence 3) • Transmit exceeding packets with marker value y (e.g IP precedence 2)
– Pure marking • Transmit confirming and exceeding packets with the same marker value
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -90
Based on the “conform” or “exceed” results of the CAR meter, three CAR configuration philosophies are usually used: n
Use only the “transmit” and “drop” actions—effectively enabling only local rate limiting on an interface.
n
Use all processing actions, and additionally mark traffic based on its conformance of exceeding the configured rate limit. For example, conforming traffic may be colored with one marker value (precedence, DSCP, QoS, etc.), and exceeding traffic with another value. This differentiation may be used locally or elsewhere in the network to differentiate between in-contract (conforming) traffic and out-of-contract (exceeding) traffic.
n
Transmit all traffic and use only the marking actions to color traffic with a marker value.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-87
Displaying CAR Parameters and Statistics Router#
show interfaces intf rate-limit
• Displays CAR parameters and statistics Router#show Router#show interfaces interfaces serial serial 0/0 0/0 rate-limit rate-limit Serial0 Serial0 Input Input matches: matches: qos-group qos-group 4 params: params: 128000 128000 bps, bps, 64000 64000 limit, limit, 128000 128000 extended extended limit limit conformed conformed 00 packets, packets, 00 bytes; bytes; action: action: transmit transmit exceeded exceeded 0 0 packets, packets, 00 bytes; bytes; action: action: set-prec-transmit set-prec-transmit 0 0 last last packet: packet: 421250660ms 421250660ms ago, current current burst: burst: 00 bytes bytes last last cleared cleared 00:00:59 00:00:59 ago, ago, conformed conformed 00 bps, bps, exceeded exceeded 00 bps bps Output Output matches: matches: access-group access -group 181 181 params: limit params: 8000 8000 bps, bps, 8000 8000 limit, limit, 16000 16000 extended extended limit conformed -prec-transmit 33 conformed 19 19 packets, packets, 21576 21576 bytes; bytes; action: action: set set-prec-transmit exceeded exceeded 5 packets, packets, 7520 bytes; action: drop last last packet: packet: 145344ms 145344ms ago, ago, current current burst: burst: 11552 11552 bytes bytes last last cleared cleared 00:03:01 00:03:01 ago, ago, conformed conformed 00 bps, bps, exceeded exceeded 00 bps bps © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -91
To display information about the Committed Access Rate (CAR) for an interface, use the show interfaces rate-limit EXEC command. Information retrieved by the show interface rate limit command includes:
4-88
n
Packets that match this rate limit
n
Parameters for this rate limit (as configured by the rate-limit command)
n
Average rate
n
Normal burst size
n
Excess burst size
n
Number of packets that have conformed to the rate limit
n
Conform action
n
Number of packets that have exceeded the rate limit
n
Exceed action
n
Time since the last packet
n
Instantaneous burst size at the current time
n
Time since the burst counter was reset
n
Rate of conforming traffic
n
Rate of exceeding traffic
n
Rate limits applicable to packets sent out by the interface
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Display Rate-limit Access Lists Router(config)#
show access-lists rate-limit
• List rate-limit access lists Router#show Router#show access-lists access-lists rate-limit rate-limit Rate-limit Rate-limit access access list list 10 10 1 Rate-limit Rate-limit access access list list 11 11 mask 81 Rate-limit Rate-limit access access list list 120 120 4000.1234.ABCD
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -92
To display information about rate-limit access lists, use the show access-lists rate-limit EXEC command. Information displayed includes: n
Whether the access list is precedence-based or MAC address-based
n
What the IP precedence and IP precedence mask for packets in this rate-limit access list are or what the MAC address for packets in this rate-limit access list are
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-89
CAR – Limiting Example #1 • A service provider connects all its customers via 2 Mbps physical leased lines (or ADSL links) and uses CAR to limit the actual amount of traffic the user can send or receive • In addition several differentiated services could be provided based on customers needs
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -92
The first CAR case study shows a service provider, which uses a unified infrastructure to connect all customers to an IP backbone. 2 Mbps leased lines or ADSL links are used to connect customers to a POP. CAR is used to limit the actual traffic rate to a lower value, as specified by the customer contract. CAR can be used to offer differentiated, easy to upgrade services in this scenario, as throughput is not limited by physical infrastructure, but rather by the traffic policing by the ISP.
4-90
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR – Limiting Example #1 interface serial 0/0 rate-limit input 256000 4000 96000 conform-action transmit exceed-action drop rate-limit output 256000 4000 96000 conform-action transmit exceed-action drop
Customer
2M bps
2 Mbps
Internet NAP
Customer bps 2M
ISP
Customer
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-93
In the configuration example, CAR is applied on the input and output of a customer interface on the provider edge router. Traffic is policed to 256 Kbps on input and output, with some bursting allowed. All exceeding traffic is dropped at the provider edge. The result of the configuration is that traffic to and from the customer is limited to the average rate of approximately 256kbps (256000 in the configuration) with sustained bursts of approximately 32kbps (4kBps or 4000 in the configuration). Initial bursts at line speed can last up to 3 seconds because the token bucket can hold up to 96000 tokens (bytes) which equals 768000 bits (3 x 256000 bits).
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-91
CAR – Limiting and Marking Example #2 • Web traffic is limited to 512 Kbps and transmitted with higher precedence – Excess Web traffic is classified as regular traffic
• All other traffic is limited to 256 Kbps and transmitted with precedence 0 – Excess traffic is dropped – Burst size is 16000 bytes – Excess burst size is 24000 bytes
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -94
The second case study provides a differentiated service for a customer, where web traffic needs to be given more bandwidth compared to other traffic types. Web traffic is limited to 512 Kbps, and a higher precedence is set. Web traffic exceeding the configured rate limit is reclassified as regular traffic. Regular traffic is limited to 256 Kbps, and colored with a precedence value of 0. The same burst values are configured for web and all other traffic.
4-92
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR – Limiting and Marking Example #2 2 Mbps Internet
Customer
NAP
ISP
interface serial 0/0 rate-limit input access-group 101 512000 64000 128000 conform-action set-prec-transmit 1 exceed -action continue rate-limit input 256000 16000 24000 conform-action set-prec-transmit 0 exceed-action drop rate-limit output access -group 101 512000 64000 128000 conform-action set-prec-transmit 1 exceed -action continue rate-limit output 256000 16000 24000 conform-action set-prec-transmit 0 exceed-action drop ! access-list 101 permit tcp any any eq www access-list 101 permit tcp any eq www any © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -95
The configuration implements the policy outlined in the previous case study. Traffic is classified with extended access lists (to differentiate web traffic from other traffic), and CAR uses the access list to apply the correct policing to the traffic. Precedence values of 0 and 1 are set to signal preferential treatment of the webtraffic to other QoS mechanisms, such as queuing and WRED. The access list 101 identifies HTTP traffic using the default well-known port number 80 (“www” in the configuration) either as the source or destination port number in TCP segments. The conforming part of the class (up to 512 kbps) is marked with IP precedence 1. The exceeding part of the class is further evaluated by the next rate-limit command where it is limited together with the rest of the traffic (non-HTTP) to 256 kbps. The total throughput, therefore, will never exceed 768 kbps (512 kbps of conforming HTTP traffic + 256 kbps of exceeding HTTP traffic and all other traffic). WRED can be used in combination with CAR to provide differentiated congestion avoidance anywhere in the network.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-93
CAR – Limiting Example #3 • The customer can send or receive up to 128 Kbps of premium traffic – Premium traffic is marked with precedence 1 Excess premium traffic is dropped
• Non-premium (best-effort) traffic is not rate limited
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -96
In the third case study, an ISP’s customer can exchange up to 128 Kbps of premium traffic with the world. Premium traffic is marked with precedence 1 by the customer, and the ISP polices the traffic to 128 Kbps using CAR. Other traffic is not rate-limited.
4-94
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR – Limiting Example #3 interface serial 0/0 rate-limit input access -group rate-limit 13 128000 16000 48000 conform-action transmit exceed -action drop rate-limit output access-group rate -limit 13 128000 16000 48000 conform-action transmit exceed -action drop ! access-list rate-limit 13 1
Customer
2M bps
2 Mbps
Internet NAP
Customer bps 2M
ISP
Customer © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -97
The configuration shows traffic classification based on the packet precedence, classified by the rate-limit access list. CAR only polices premium traffic, and all other traffic has policing applied to it. The premium traffic, previously marked with IP precedence 1, is classified using the rate-limit access list 13. The premium traffic is strictly policed to 128kbps where all excess traffic is dropped. All other traffic is not policed.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-95
CAR – Precedence Spoofing Example #4
Customer
interface serial 0/0 rate-limit input access-group rate-limit 1 64000 8000 8000 conform-action drop exceed-action drop ! access-list rate-limit 1 mask FE Internet
2M bps
2 Mbps NAP
Customer bps 2M
ISP
Customer
• If a customer is trying to spoof a service provider with high-precedence traffic, the traffic is dropped – Drop all non-precedence-0 traffic received from a customer © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -98
This case study shows a possible solution for preventing precedence spoofing for best-effort customers. The customer may only send traffic with the precedence value of 0. The CAR policing rule matches all non-zero-precedence traffic and drops it unconditionally. The CAR metering parameters can be arbitrarily set to any value. The rate-limit access list in this example is using the mask option to match multiple IP precedence values. Each bit in the mask corresponds to one IP precedence value. The mask FE (11111110 binary) in the example matches all packets with IP precedence values between 1 and 7. The rate-limit command drops all packets that do not have IP precedence 0.
4-96
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR – Limiting Example #5 • Application: Web server collocation – The customer can locate his server at service provider premises (switched LAN) – CAR is used to limit the amount of traffic the web server can generate – Unknown traffic is rate-limited to 64 kbps to allow remote configuration of new servers
• Alternate application: central site in an enterprise network
© 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing -99
The fifth case study application uses web hosting as the example of QoS application. The SP hosts a web-farm and wants to police traffic going to and from specific servers. CAR is used, with MAC-based classification, to differentiate traffic to or from different servers. A default policing statement allows some traffic through to allow management protocols to run to yet unprovisioned servers. This application can also be used to manage traffic flows to centralized servers in enterprise networks.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-97
CAR – Limiting Example #5
Server
Core network LAN switch Server
Server
© 2001, Cisco Systems, Inc.
Distribution Router
interface FastEthernet 0/0 rate-limit input access-group rate -limit 100 10000000 100000 100000 conform-action transmit exceed-action drop rate-limit output access-group rate-limit 100 10000000 100000 100000 conform-action transmit exceed-action drop rate-limit input 64000 8000 24000 conform-action transmit exceed-action drop rate-limit output 64000 8000 24000 conform-action transmit exceed-action drop ! access-list rate-limit 100 00ae.0123.abcd ! Server MAC address
IP QoS Traffic Shaping and Policing-100
The figure shows the configuration used to police traffic going to a specific server. MAC-based rate-limit ACLs are used, which filter based on the upstream server MAC address. The special rate-limit access list is used to identify traffic from a web server which may have multiple IP addresses. The traffic is limited to Ethernet speed even if the underlying interface is using another type of media (for example: FastEthernet). In the event that a customer changes the interface card (MAC address changes) on the server, he can still get limited access to the server (64kbps) for administrative purposes. The MAC-based rate-limit access list has to be modified to reflect the new MAC address being used by the server.
4-98
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
CAR – Marking Example #6
WAN Core Customer interface ethernet 0/0 rate-limit input 10000000 8000 8000 conform-action set-prec-transmit 2 exceed-action drop ! interface ethernet 0/1 rate-limit input 10000000 8000 8000 conform-action set-prec-transmit 0 exceed-action drop !
• CAR can be used purely for marking purposes © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-101
In this example, CAR is used purely for marking purposes. All traffic from one customer (attached to the ethernet0/0 interface) is rate-limited to the line rate and CAR marks all incoming packets with a configured precedence. Another customer is connected to the same router, also rate-limited to the line rate, and marked with a lower precedence. The bit rate in the rate-limit command should be higher or equal to the physical bandwidth of the interface to implement marking without any rate limiting. Another option is to use the same action for both conforming and exceeding traffic.
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-99
CAR – Marking Example #7 Customer WAN Core interface ethernet 0/0 rate-limit input access-group 101 10000000 8000 8000 conform-action set -prec-transmit 2 exceed-action drop rate-limit input access-group 102 10000000 8000 8000 conform-action set -prec-transmit 1 exceed-action drop rate-limit input 10000000 8000 8000 conform-action set -prec-transmit 0 exceed-action drop ! access-list 101 permit tcp any any eq telnet access-list 102 permit tcp any any eq www © 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing-102
This configuration extends the possibilities of the previous example, using application-specific marking. CAR is used to mark telnet traffic with a higher precedence and web-traffic with a lower precedence. All other traffic is marked with precedence zero. Note
There is no true policed rate limiting in this example, as traffic is rate -limited to the line rate.
The first rate-limit command identifies inbound telnet sessions (access list 101) and marks them with IP precedence 2 without limiting it. The second rate-limit command identifies inbound HTTP sessions (access list 102) and marks them with IP precedence 1 without limiting it. The third rate-limit command marks all other packets (no access list is used) with IP precedence 0 without limiting it.
4-100
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Summary n
CAR can be applied on input and output interfaces
n
CAR performs no buffering or shaping
n
CAR can mark packets
n
In Frame Relay, CAR has no support for BECN or FECN
n
Cascaded policies can be applied
n
CAR provides managed discard between the normal burst and extended burst parameters
n
CAR can run in distributed mode (on 7500 VIP)
n
CAR can apply access lists based on ToS bits/MAC address and IP extended access lists
n
CAR is not RSVP aware
Lesson Review Answer the following questions: 1. What classification options does CAR support? 2. What are the main differences between CAR and traffic shaping? 3. Where can CAR be implemented?
Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-101
Summary
4-102
n
GTS/FRTS perform traffic shaping or smoothing
n
GTS/FRTS cannot mark or drop packets
n
GTS/FRTS can intelligently adapt to Layer-2 congestion
n
GTS/FRTS do not support cascaded policies
n
GTS/FRTS do not provide managed discard
n
CAR performs no buffering or shaping
n
CAR can mark packets
n
In Frame Relay, CAR has no support for BECN or FECN
n
Cascaded policies can be applied in CAR
n
Both GTS and CAR can run in distributed mode
n
CAR is not RSVP aware, while GTS is
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Traffic Shaping and Policing Question: How do shaping and policing mechanisms keep track of the traffic rate? Answer: Both mechanisms use a token bucket as a rate measurement method. Question: Which shaping mechanisms are available with the Cisco IOS software? Answer: Cisco IOS supports Generic Traffic Shaping, Frame Relay Traffic Shaping, and Class-based Shaping. Question: Which policing mechanisms are available with the Cisco IOS software? Answer: Cisco IOS supports Committed Access Rate (CAR) and Class-based Policing. Question: What are the main differences between shaping and policing? Answer: To stay within the configured rate, shaping delays excessive traffic while policing drops excessive traffic.
Generic Traffic Shaping Question: What software queuing mechanisms are supported in combination with GTS? Answer: Any software queuing method (FIFO, priority queuing, custom queuing, WFQ, CB-WFQ) is supported on an interface in combination with GTS. Question: Which queuing structure does GTS use? Answer: GTS uses WFQ as the shaping queue. Question: What features does GTS include when used on Frame Relay interfaces? Answer: GTS can adapt its rate to Frame Relay congestion signaling, and propagate FECN signals to BECN signals, sent towards the sender on the Frame Relay network.
Frame Relay Traffic Shaping Question: What are the main differences between GTS and FRTS? Answer: FRTS shapes traffic of individual Frame Relay VCs. Also, the shaping queue of FRTS is configurable and can be any of the software queuing mechanisms. Copyright 2001, Cisco Systems, Inc.
IP QoS Traffic Shaping and Policing
4-103
Question: Where can FRTS be used? Answer: FRTS can only be used on Frame Relay interfaces. Question: What classification options does FRTS have? Answer: None, FRTS shapes all traffic on a Frame Relay VC.
Committed Access Rate Question: What classification options does CAR support? Answer: CAR supports Access Control Lists (ACLs), rate-limit ACLs, DSCP value, and QoS-group as its classifiers. Question: What are the main differences between CAR and traffic shaping? Answer: CAR never delays excess traffic, but can drop or transmit it. CAR also supports marking of conforming and exceeding traffic, and supports nested classification and policing. CAR can also be used both on input and output of interfaces, while traffic shaping can only be used on output. Question: Where can CAR be implemented? Answer: CAR can be implemented on input or output of interfaces.
4-104
IP QoS Traffic Shaping and Policing
Copyright 2001, Cisco Systems, Inc.
5
Congestion Avoidance
Overview This module describes the problems of congested networks. It introduces Random Early Detection (RED), WRED, and Flow-based WRED as mechanisms to prevent congestion on router interfaces.
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe Random Early Detection (RED)
n
Describe and configure Weighted Random Early Detection (WRED)
n
Describe and configure Flow-based WRED
Random Early Detection Overview The section describes the need for congestion avoidance in nearly-congested networks and explains the benefits of using RED on congested links.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
5-2
Congestion Avoidance
n
Explain the need for congestion avoidance mechanisms.
n
Explain how RED works and how it can prevent congestion.
n
Describe the benefits and drawbacks of RED.
Copyright 2001, Cisco Systems, Inc.
Router Interface Congestion • Router interfaces congest when the output queue is full –Additional incoming packets are dropped –Dropped packets may cause significant application performance degradation –By default, routers perform tail-drop –Tail-drop has significant drawbacks –WFQ, if configured, has a more intelligent dropping scheme
© 2001, Cisco Systems, Inc.
Congestion Avoidance-5
When an interface on a router cannot transmit a packet immediately, the packet is queued, either in an interface Tx ring, or the interface output hold queue, depending on the switching path used. Packets are then taken out of the queue and eventually transmitted on the interface. If the arrival rate of packets to the output interface exceeds the router’s capability to buffer and forward traffic, the queues increase to their maximum length and the interface becomes congested. Tail drop is the router’s default queuing response to congestion. When the output queue is full and tail drop is in effect, all packets trying to enter (at the tail of) the queue are dropped until the congestion is eliminated and the queue is no longer full. Congestion avoidance techniques monitor network traffic loads in an effort to anticipate and avoid congestion at common network bottleneck points. Congestion avoidance is achieved through packet dropping using more complex techniques than simple tail-drop. As mentioned, tail drop is the default queuing response to congestion. Tail drop treats all traffic equally and does not differentiate between classes of service. Weighted fair queuing, if configured on an interface, has a more elaborate scheme for dropping traffic, as it is able to punish the most aggressive flows via its Congestion Discard Threshold (CDT)-based dropping algorithm. Unfortunately, WFQ does not scale to backbone speeds. WFQ dropping is discussed in detail in its associated module. This module introduces Random Early Detection (RED) and its scalable dropping method, which is suitable for low and high-speed networks.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-3
Tail-drop Flaws • Simple tail-drop has significant flaws –TCP synchronization –TCP starvation –High delay and jitter –No differentiated drop –Poor feedback to TCP
© 2001, Cisco Systems, Inc.
Congestion Avoidance-6
The simple tail-dropping scheme unfortunately does not work very well in environments with a large number of TCP flows or in environments in which selective dropping is deserved. Understanding of the interaction between TCP stack intelligence and dropping in the network is required to implement a more efficient and fair dropping scheme, especially in SP environments. Tail drop has the following shortcomings:
5-4
Congestion Avoidance
n
When congestion occurs, dropping affects most of the TCP sessions, which simultaneously back-off and then restart again. This causes inefficient link utilization at the congestion point (TCP global synchronization)
n
TCP starvation, where all buffers are temporarily seized by aggressive flows, and normal TCP flows experience buffer starvation.
n
Buffering at the point of congestion can introduce delay and jitter, as packets are stuck waiting in queues.
n
There is no differentiated drop mechanism, and therefore premium traffic is dropped in the same way as best-effort traffic.
n
Even in the event of a single TCP stream across an interface, the presence of other non-TCP traffic can congest the interface and TCP traffic will also be dropped. In this scenario, the feedback to the TCP protocol is very poor and therefore it cannot adapt properly to a congested network.
Copyright 2001, Cisco Systems, Inc.
TCP Synchronization
Average link utilization
Flow A Flow B Flow C
• Multiple TCP sessions start at different times • TCP window sizes are increased • Tail-drops cause many packets of many sessions to be dropped at the same time • TCP sessions restart at the same time (synchronized) © 2001, Cisco Systems, Inc.
Congestion Avoidance-7
A router can handle multiple concurrent TCP sessions. There is a high probability that when traffic exceeds the queue limit at all, it vastly exceeds the limit due to the bursty nature of packet networks. However, there is also a high probability that excessive traffic depth caused by packet bursts is temporary and that traffic does not stay excessively deep except at points where traffic flows merge, or at edge routers. If the receiving router drops all traffic that exceeds the queue limit, as is done by default (with tail drop), many TCP sessions then simultaneously go into slow start. Consequently, traffic temporarily slows down to the extreme and then all flows slow-start again. This activity creates a condition called global synchronization. Global synchronization occurs as waves of congestion crest only to be followed by troughs during which the transmission link is not fully utilized. Global synchronization of Transmission Control Protocol (TCP) hosts, for example, can occur because packets are dropped all at once. Global synchronization manifests when multiple TCP hosts reduce their transmission rates in response to packet dropping, then increase their transmission rates once again when the congestion is reduced. The most important point is that the waves of transmission known as global synchronization result in significant link under-utilization.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-5
TCP Starvation, Delay and Jitter Packets of aggressive flows
Packets of starving flows Prec. 3
TCP does not react well if multiple packets are dropped
Prec. 3
Prec. 3
Prec. 0
Prec. 3
Prec. 0
Prec. 0
Prec. 0
Queue
Delay Tail-drop does not look at IP precedence
Packets experience long delay if interface is constantly congested
• Constant high buffer usage (long queue) causes delay • More aggressive flows can cause other flows to starve • Variable buffer usage causes jitter • No differentiated dropping © 2001, Cisco Systems, Inc.
Congestion Avoidance-8
Another TCP-related phenomenon, which reduces optimal throughput of network applications is TCP starvation. When multiple flows are established over a router, some of these flows may be much more aggressive as compared to others. For instance, when a file transfer application’s TCP transmit window increases, it can send a number of large packets to its destination. The packets immediately fill the queue on the router, and other, less aggressive flows can be starved, because they are tail-dropped at the output interface. During periods of congestion, packets are queued up to the full queue length, which also causes increased delay for packets already in the queue. In addition, queuing, being a probabilistic mechanism, introduces unequal delays for packets of the same flow, producing jitter.
5-6
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Conclusion • Tail-drop should be avoided • Tail-drop can be avoided if congestion is prevented • Congestion can be prevented if TCP sessions (that still make up more than 80 percent of average Internet traffic) can be slowed down • TCP sessions can be slowed down if some packets are occasionally dropped • Therefore: packets should be dropped when interface is nearing congestion © 2001, Cisco Systems, Inc.
Congestion Avoidance-9
Based on the knowledge of TCP behavior during periods of congestion, it can be concluded that tail-drop is not the optimal mechanism for congestion avoidance and therefore should not be used. Instead, more intelligent congestion avoidance mechanisms should be used, which would slow down traffic before actual congestion occurs. IP traffic can be “slowed down” only for traffic using an adaptive transmission protocol, such as TCP. Dropping packets of a TCP session indicates to the sender that it should lower its transmission rate to adapt to changing network conditions. UDP, on the other hand, has no built-in adaptive mechanisms – it sends packets out at a rate specified by the application. About 80% of Internet traffic today is carried over the TCP protocol. If TCP packets of aggressive flows are intelligently dropped, those sessions will slow down and congestion will be avoided. Therefore, to prevent congestion, the output queues should not be allowed to get full, and TCP can be controlled via packet dropping. The new dropping mechanisms should drop packets before congestion occurs, and drop them in such a way that primarily influences aggressive traffic flows.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-7
Random Early Detection • Random Early Detection (RED) is a mechanism that randomly drops packets even before a queue is full • RED drops packets with an increasing probability • RED result: – TCP sessions slow down to the approximate rate of outputlink bandwidth – Average queue size is small (much less than the maximum queue size)
• IP precedence can be used to drop lower precedence packets more aggressively than higherprecedence packets
© 2001, Cisco Systems, Inc.
Congestion Avoidance -10
Random Early Detection is a dropping mechanism that randomly drops packets before a queue is full. The dropping strategy is based primarily on the average queue length - that is, when the average queue gets longer (fuller), RED will be more likely to drop an incoming packet than when the queue is shorter. Because RED drops packets randomly, it has no per-flow intelligence. The rationale behind this is that an aggressive flow will represent most of the arriving traffic, therefore it is more probable that RED will drop a packet of an aggressive session. RED therefore punishes more aggressive sessions with higher statistical probability, and is therefore able to somewhat selectively slow down the most significant cause of congestion. Directing one TCP session at a time to slow down allows for full utilization of the bandwidth, rather than utilization that manifests itself as crests and troughs of traffic. As a result, the TCP global synchronization is much less likely to occur, and TCP can utilize the bandwidth more efficiently. The average queue size also decreases significantly, as the possibility of the queue filling up is very small. This is due to very aggressive dropping in the event of traffic bursts, when the queue is already quite full. RED distributes losses over time and maintains normally low queue depth while absorbing spikes. RED can also utilize precedence/DSCP bits in packets to establish different drop profiles for different classes of traffic.
5-8
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
RED Profile Drop Probability
No drop
Random drop
Full drop
100%
Maximum Drop Probability
10% 20
Minimum Threshold
© 2001, Cisco Systems, Inc.
40
Average Queue Size
Maximum Threshold
Congestion Avoidance -11
The probability of a packet being dropped is based on three configurable parameters: n
Minimum threshold - When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold.
n
Maximum threshold - When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.
n
Mark probability denominator - This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
These parameters define the RED profile, which implements the packet dropping strategy, based on the average queue length.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-9
RED Modes • RED has three modes: – No drop – when the average queue size is between 0 and the minimum threshold – Random drop - when the average queue size is between the minimum and the maximum threshold – Full drop (tail-drop) – when the average queue size is at maximum threshold or above
• Random drop should prevent congestion (prevent tail-drops)
© 2001, Cisco Systems, Inc.
Congestion Avoidance -12
As seen in the previous figure, RED has three dropping modes, based on the average queue size:
5-10
Congestion Avoidance
n
When the average queue size is between 0 and the configured minimum threshold, no drops occur and all packets are queued.
n
When the average queue size is between the configured minimum threshold, and the configured maximum threshold, random drop occurs, which is linearly proportional to the average queue length. The maximum probability of drop (when the queue is almost completely full) is 15% in Cisco IOS software.
n
When the average queue size is at or higher than the maximum threshold, RED performs full (tail) drop in the queue. This event is unlikely, as RED should slow down TCP traffic ahead of congestion. If a lot of non-TCP traffic is present, RED cannot effectively drop traffic to reduce congestion, and taildrops are likely to occur.
Copyright 2001, Cisco Systems, Inc.
Before RED
Average link utilization
Flow A Flow B Flow C
• TCP synchronization prevents average link utilization close to the link bandwidth • Tail-drops cause TCP sessions to go into slow-start © 2001, Cisco Systems, Inc.
Congestion Avoidance -13
The figure shows TCP throughput behavior compared to link bandwidth in a scenario of congestion, and simple tail-dropping on a router. The global synchronization phenomenon causes all sessions to slow down when congestion occurs, as all sessions are penalized when tail-drop is used because it drops packets with no discrimination between individual flows. When all sessions slow down, the interface becomes uncongested, and all TCP sessions restart their transmission at roughly the same time. The interface quickly becomes congested again, causing tail-dropping, and all TCP sessions back off again. This behavior cycles constantly, resulting in a link that is always underutilized on the average.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-11
After RED
Average link utilization
Flow A Flow B Flow C
• Average link utilization is much closer to link bandwidth • Random drops cause TCP sessions to reduce window sizes © 2001, Cisco Systems, Inc.
Congestion Avoidance -14
The figure shows TCP throughput behavior compared to link bandwidth in a scenario of congestion, and RED configured on a router. RED randomly drops packets, influencing a small number of sessions at a time, before the interface reaches congestion. Overall throughput of sessions is increased, as well as average link utilization. Global synchronization is very unlikely to occur, as there is selective, but random dropping of adaptive traffic.
5-12
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Summary n
Tail-drop does not perform adequate congestion avoidance on router interfaces.
n
RED randomly drops packets before an interface is congested, punishing aggressive flows.
n
RED prevents interface congestion and prevents TCP global synchronization, but works well only in predominantly TCP-based environments.
Lesson Review 1. What are the main drawbacks of using tail-drop as a means of congestion control? 2. What does RED do to prevent TCP synchronization? 3. What are the three modes of RED?
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-13
Weighted Random Early Detection Overview The section describes the WRED mechanism available in Cisco IOS.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
5-14
Congestion Avoidance
n
Describe the Weighted Random Early Detection (WRED) mechanism
n
Configure WRED on Cisco routers
n
Monitor and troubleshoot WRED on Cisco routers
Copyright 2001, Cisco Systems, Inc.
Weighted Random Early Detection • WRED uses a different RED profile for each weight • Each profile is identified by: – minimum threshold – maximum threshold – maximum drop probability • Weight can be – IP precedence (8 profiles) – DSCP (64 profiles) • WRED drops less important packets more aggressively than more important packets
© 2001, Cisco Systems, Inc.
Congestion Avoidance -19
Weighted Random Early Detection (WRED) combines RED with IP Precedence or DSCPs and does packet drops based on IP Precedence or DSCP markings. As with RED, WRED monitors the average queue depth in the router and determines when to begin packet drops based on the queue depth. When the average queue depth crosses the user-specified “minimum threshold,” WRED begins to drop packets (both TCP and UDP) with a certain probability. If the average queue depth ever crosses the user-specified ”maximum threshold,” then WRED reverts to ”tail drop,” where all incoming packets might be dropped. The idea behind using WRED is to maintain the queue depth at a level somewhere between the minimum and maximum thresholds, and to implement different drop policies for different classes of traffic. WRED can selectively discard lower priority traffic when the interface becomes congested and provide differentiated performance characteristics for different classes of service. WRED can also be configured so that non-weighted RED behavior is achieved. For interfaces configured to use the Resource Reservation Protocol (RSVP), WRED chooses packets from other flows to drop rather than the RSVP flows. Also, IP Precedence or DSCPs govern which packets are dropped − traffic that is at a lower priority has a higher drop rate and therefore is more likely to be throttled back. WRED reduces the chances of tail drop by selectively dropping packets when the output interface begins to show signs of congestion. By dropping some packets early rather than waiting until the queue is full, WRED avoids dropping large numbers of packets at once and minimizes the chances of global synchronization. Thus, WRED maximizes the utilization of transmission lines. Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-15
In addition, WRED statistically drops more packets from large users than small ones. Therefore, traffic sources that generate the most traffic are more likely to be slowed down than traffic sources that generate little traffic. WRED avoids the global synchronization problems that occur when tail drop is used as the congestion avoidance mechanism. Global synchronization manifests when multiple TCP hosts simultaneously reduce their transmission rates in response to packet dropping, then increase their transmission rates again once the congestion is reduced. WRED is only useful when the bulk of the traffic is TCP traffic. With TCP, dropped packets indicate congestion, so the packet source reduces its transmission rate. With other protocols, packet sources might not respond or might re-send dropped packets at the same rate, and so dropping packets does not decrease congestion. WRED treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP traffic, in general, is more likely to be dropped than IP traffic. WRED should be used wherever there is a potential bottleneck (congested link), which could very well be an access/edge link. However, WRED is normally used in the core routers of a network rather than at the network’s edge. Edge routers assign IP Precedences to packets as they enter the network. WRED uses these precedences to determine how to treat different types of traffic. Note that WRED is not recommended for any voice queue, although it may be enabled on an interface carrying voice traffic. RED will not throttle back voice traffic, because it is UDP-based, and the network itself should not be designed to lose voice packets since lost voice packets result in reduced voice quality. WRED controls congestion by impacting other prioritized traffic, and avoiding congestion helps to ensure voice quality.
5-16
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
WRED Profiles Drop Probability 100%
10% 10
20
40
Average Queue Size
• WRED profiles can be manually set • WRED has 8 default value sets for IP precedence based WRED • WRED has 64 default value sets for DSCP based WRED
© 2001, Cisco Systems, Inc.
Congestion Avoidance -20
The figure shows two WRED profiles, used for traffic of different QoS classes. The RED class has a much lower minimum and maximum threshold. Traffic of that class will be dropped much earlier and more aggressively. When heavy congestion occurs, the RED class will ultimately be tail dropped. The BLUE class has a higher minimum and maximum thresholds, therefore dropping occurs later and is less likely, compared to the RED class. This maintains differentiated levels of service in the event of congestion. To avoid the need of setting all WRED parameters in a router, 8 default values are already defined for precedence-based WRED, and 64 DiffServ-aligned values are defined for DSCP-based WRED. Therefore, the default settings should suffice in the vast majority of deployments.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-17
IP Precedence and Class Selector Profiles Drop Probability
100%
10% IP precedence
0
20
© 2001, Cisco Systems, Inc.
1 2 3 4 5 6 7 RSVP 22 24 26 28 31 33 35 37 40
Average Queue Size
Congestion Avoidance -21
A Per-Hop Behavior (PHB) is the externally observable forwarding behavior applied at a DiffServ-compliant node to a DiffServ Behavior Aggregate (BA). With the ability of the system to mark packets according to DSCP setting, collections of packets − each with the same DSCP setting and sent in a particular direction − can be grouped into a DiffServ BA. Packets from multiple sources or applications can belong to the same DiffServ BA. In the Assured Forwarding PHB (as defined in RFC 2474,) WRED uses the Drop Preference (second digit of the AF number) to determine drop probability. This enables differentiated dropping of AF traffic classes, which have different drop preference.
5-18
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
DSCP-based WRED (Expedited Forwarding) Drop Probability
100%
10%
EF
20
© 2001, Cisco Systems, Inc.
36 40
Average Queue Size
Congestion Avoidance -22
The Expedited Forwarding PHB is identified based on the following parameters: n
Ensures a minimum departure rate to provide the lowest possible delay to delay-sensitive applications
n
Guarantees bandwidth to prevent starvation of the application if there are multiple applications using Expedited Forwarding PHB
n
Polices bandwidth to prevent starvation of other applications or classes that are not using this PHB
n
Packets requiring Expedited Forwarding should be marked with DSCP binary value “101110” (46 or 0x2E)
For the Expedited Forwarding DiffServ traffic class, WRED configures itself by default so that the minimum threshold is very high, increasing the probability of no drops being applied to that traffic class. EF-traffic is therefore expected to be dropped very late, compared to other traffic classes, in the event of congestion.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-19
DSCP-based WRED (Assured Forwarding) Drop Probability
100%
AF Low Drop AF Medium Drop AF High Drop
10%
20 24
28 32
© 2001, Cisco Systems, Inc.
40
Average Queue Size
Congestion Avoidance -23
The Assured Forwarding PHB is identified based on the following parameters: n
Guarantees a certain amount of bandwidth to an AF class
n
Allows access to extra bandwidth, if available
n
Packets requiring AF PHB should be marked with DSCP value “aaadd0” where “aaa” is the number of the class and “dd” is the drop probability or drop preference of the traffic class.
There are four standard-defined AF classes. Each class should be treated independently and have bandwidth allocated based on the QoS policy. For the Assured Forwarding DiffServ traffic class, WRED configures itself by default for three different profiles, depending on the Drop Preference DSCP marking bits. AF-traffic should therefore be classified into the three possible classes based on the application sensitivity to dropping. WRED implements a congestion avoidance PHB in agreement with the initial classification.
5-20
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
WRED Building Blocks Calculate Average Queue Size
IP packet
WRED
IP precedence or DSCP
Select WRED Profile
© 2001, Cisco Systems, Inc.
Min. threshold Max. threshold Max prob. denom.
Queue Full?
No
Current Queue Size FIFO Queue
Yes
Random Drop
Tail Drop
Congestion Avoidance -24
The figure shows how WRED is implemented, and the parameters that influence WRED dropping decisions. The WRED algorithm is constantly updated with the calculated average queue size, which is based on the recent history of queue sizes. The configured WRED profiles define the dropping thresholds (and therefore the WRED probability slopes). When a packet arrives at the output queue, the IP precedence of DSCP-value is used to select the correct WRED profile for the packet. The packet is then passed to WRED to perform a drop/enqueue decision. Based on the profile and the average queue size, WRED calculates the probability for dropping the current packet and either drops it or passes it to the output queue. If the queue is already full, the packet is tail-dropped. Otherwise, it is eventually transmitted out onto the interface.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-21
Configuring WRED and dWRED Router(config-if)# random-detect random-detect
• Enables IP precedence based WRED • Default service profile is used • Non-distributed WRED cannot be combined with fancy queuing - FIFO queuing has to be used • WRED can run distributed on VIP-based interfaces (dWRED) • dWRED can be combined with dWFQ © 2001, Cisco Systems, Inc.
Congestion Avoidance -25
The random-detect command is used to enable WRED on an interface. By default, WRED is precedence-based, using eight default WRED profiles. Used on VIP-based interfaces, this command enables distributed WRED (dWRED), where the VIP CPU performs WRED dropping. This can significantly increase router performance, when used in the context of distributed CEF switching, which is a prerequisite for dWRED functionality. Also, dWRED can be combined with dWFQ, enabling truly distributed queuing and congestion avoidance techniques, running independently from the central CPU. With centralized platforms, WRED, if configured, cannot be combined with other queuing methods (priority, custom, and weighted-fair queuing). Those methods use either tail-dropping or their own dropping methods. Therefore, WRED can only be configured with FIFO queuing on an interface. This is not a major issue, because WRED is usually applied in the network core, where there should be no queuing configured. WRED is suited for the network core as it has a relatively low performance impact on routers.
5-22
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Changing WRED profile Router(config-if)# random-detect precedence precedence precedence precedence min-threshold max-threshold mark-prob-denominator mark-prob-denominator
• Changes RED profile for specified IP precedence value • Packet drop probability at maximum threshold is 1 / mark-prob-denominator • Non-weighted RED is achieved by using the same RED profile for all precedence values © 2001, Cisco Systems, Inc.
Congestion Avoidance -26
In this example, WRED is enabled with default values, and then the values are changed for each IP Precedence level. The configured values, which are described above under Random Early Detection, are repeated here for convenience: n
Minimum threshold - When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold.
n
Maximum threshold - When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.
n
Mark probability denominator - This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
It is interesting to note, that the maximum probability of drop at the maximum threshold can be expressed as 1/mark-prob-denominator. The maximum drop probability is 10%, if default settings are used. If required, RED can be configured as a special case of WRED, by assigning the same profile to all eight precedence values.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-23
Changing WRED Sensitivity to Bursts Router(config-if)# random-detect exponential-weighting-constant n
Qavg ( t + 1) = Qavg (t ) ⋅ (1 − 2 − n ) + Qt ⋅ 2 − n New average queue size
Previous average queue size
Current queue size
• WRED takes the average queue size to determine the current WRED mode (no drop, random drop, full drop) • High values of N allow short bursts • Low values of N make WRED more burst-sensitive • Default value (9) should be used in most scenarios • Average output queue size with N=9 is average t+1 = average t * 0.998 + queue_sizet * 0.002 © 2001, Cisco Systems, Inc.
Congestion Avoidance -27
As mentioned previously, WRED does not calculate the drop probability using the current queue length, but rather uses the average queue length. The average queue length is constantly recalculated, using two terms: the previously calculated average queue size and the current queue size. An exponential weighting constant N influences the calculation by weighing the two terms, therefore influencing how the average queue size follows the current queue size, in the following way: n
A low value of N makes the current queue size more significant in the new average size calculation, therefore allowing larger bursts
n
A high value of N makes the previous average queue size more significant in the new average seize calculation, so that bursts influence the new value to a smaller degree.
The default value is 9 and should suffice for most scenarios, except perhaps those involving extremely high-speed interfaces (like OC12), where it can be increased slightly (to about 12) to allow more bursts.
5-24
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Configuring DSCP-based WRED Router(config-if)# random-detect random-detect {prec-based {prec-based || dscp-based} dscp-based}
• Selects WRED mode • Precedence-based WRED is the default mode • DSCP-based uses 64 profiles
© 2001, Cisco Systems, Inc.
Congestion Avoidance -28
The random-detect dscp-based command is used to enable DSCP-based WRED on an interface, using the 64 default DSCP-based WRED profiles.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-25
Changing WRED Profile Router(config-if)# random-detect dscp dscp dscp dscp min-threshold max-threshold mark-probdenominator denominator
• Changes RED profile for specified DSCP value • Packet drop probability at maximum threshold is 1 / mark-prob-denominator
© 2001, Cisco Systems, Inc.
Congestion Avoidance -29
The DSCP-weighted WRED profiles can be changed, again using the known three WRED parameters. The mask-prob-denominator defines the packet drop probability at the WRED maximum threshold. The maximum drop probability is 10%, if default settings are used. Normally, the DSCP-weighed profiles should be left at their default settings, as those settings are appropriate for most situations, if traffic is classified according to the DiffServ service specification.
5-26
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
WRED Case Study • WRED is applied to a core link in a network with the following IP precedence definitions IP prec.
© 2001, Cisco Systems, Inc.
Meaning
0
HighHigh-drop best effort traffic
1
LowLow -drop best best-effort traffic
2
Premium Premium traffic traffic outside outside of the contract
3
Premium Premium traffic traffic in in the the contract contract
4
Unused
5
VoiceVoice-overover -IP
6
Routing protocol traffic
7
Routing protocol protocol traffic traffic Congestion Avoidance -30
This WRED case study presents a network carrying traffic with eight different service levels, each assigned a precedence value, with which packets are marked. The figure shows the precedence to traffic -type mapping, where higher precedence values are assigned to more important traffic. Voice traffic, for example, is ranked just below essential routing protocol traffic, whereas other IP traffic is divided into premium and best-effort levels, also depending on dropsensitivity. Traffic is classified at the edge of the network, and WRED provides differentiated handling of traffic in the core, if core interfaces are nearing congestion. This information is used to build a custom WRED profile, based on the above policy. When congestion is about to occur, WRED will drop packets, preferring lower-precedence traffic, which is either drop-resistant or part of a best-effort service. Premium traffic should experience few drops, and voice and routing protocol traffic are unlikely to get dropped, because they are assigned a very high minimum dropping threshold. While it is not recommended to use WRED with voice traffic, this example aggregates many types of traffic, including voice, on a single access line. WRED is configured so that voice is unlikely to be dropped, and other aggressive flows are dropped first. Ideally, there would also be a separate voice queue configured, and voice traffic priority scheduled against other traffic.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-27
WRED Case Study Guidelines • Best-effort traffic should be dropped before premium traffic • Out-of-contract or high-drop best -effort traffic should be dropped very aggressively • Voice traffic should be dropped only under extreme congestion • Routing protocol traffic should be less dropresistant than VoIP (depends on the routing protocol and control over amount of VoIP traffic) • Configure WRED with default values on an interface first and tune the per -precedence parameters based on default values
© 2001, Cisco Systems, Inc.
Congestion Avoidance -31
The WRED dropping strategy for different traffic classes can be outlined as n
Best-effort traffic should be dropped before premium traffic.
n
Out-of-contract or high-drop best-effort traffic should be dropped very aggressively.
n
Voice traffic should be dropped only under extreme congestion.
n
Routing protocol traffic should be less drop-resistant than VoIP (depends on the routing protocol and control over amount of VoIP traffic).
To implement this dropping policy, WRED is configured with default parameters and then tuned to comply with the above policy.
5-28
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Packet Discard Probability
Sample WRED Profile
VoIP
Precedence 3
Routing
Precedence 1
0.1
Precedence 2 Precedence 0
RSVP
37
35
30
25
20
15
10
© 2001, Cisco Systems, Inc.
Average Queue Size
Congestion Avoidance -32
The figure presents the values chosen to tune WRED dropping according to the case study policy. Different precedence traffic will be assigned different minimum and maximum threshold values to reflect the relative dropping strategies outlined in the requirements. Note that the maximum drop probability is 10% (default) and the same for all precedence levels. This setting should not be changed in most implementations.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-29
WRED Configuration
interface interface Serial Serial 0/1/0 0/1/0 ip address address 200.200.14.250 200.200.14.250 255.255.255.252 255.255.255.252 random-detect random-detect precedence 0 10 10 25 25 10 10 random-detect precedence 1 20 20 35 35 10 10 random-detect precedence 2 15 15 25 25 10 10 random-detect precedence 3 25 25 35 35 10 10 random-detect precedence 2 11 precedence 44 11 random-detect precedence 5 35 35 40 40 10 10 random-detect precedence 6 30 30 40 40 10 10 random-detect precedence 7 30 30 40 40 10 10
© 2001, Cisco Systems, Inc.
Congestion Avoidance -33
This configuration excerpt shows the implementation of the dropping policy, illustrated by the case study. The threshold values reflect the values chosen in the previous figure. Note that precedence 4 is not used to mark traffic in the case study network, so the drop probability of precedence 4 traffic is 100% (1 divided by 1 times 100%).
5-30
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Monitoring WRED • Show interface – displays the queuing/dropping mechanism in use displays WRED parameters (VIP only)
• Show queueing – displays the RED profile for each interface
• Show queue – displays the interface output queue
• Show interface random-detect – displays RED statistics (VIP only)
© 2001, Cisco Systems, Inc.
Congestion Avoidance -34
The listed commands provide means to monitor WRED configuration and operation.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-31
Interface Parameters Router# show interface intf
• Displays interface parameters Router#show Router#show interface interface serial serial 1/0 1/0 Serial1/0 Serial1/0 is up, up, line line protocol protocol is up Hardware Hardware is is CD2430 CD2430 in in sync sync mode mode Internet Internet address address is is 192.168.1.2/30 192.168.1.2/30 MTU MTU 1500 1500 bytes, bytes, BW BW 128 128 Kbit, Kbit, DLY DLY 200 200 usec, usec, rely rely 255/255 255/255 ... ... Encapsulation Encapsulation HDLC, HDLC, loopback loopback not not set, set, keepalive keepalive set set (10 sec) Last Last input 00:00:07, output 00:00:07, output hang never Last Last clearing clearing of "show "show interface" interface" counters never Input Input queue: queue: 2/75/0 2/75/0 (size/max/drops); (size/max/drops); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: random random early early detection detection (WRED) (WRED) 55 minute minute input input rate rate 00 bits/sec, bits/sec, 00 packets/sec packets/sec 55 minute output rate 0 bits/sec, bits/sec, 0 packets/sec packets/sec 337102 337102 packets packets input, input, 27357987 27357987 bytes, bytes, 00 no no buffer buffer Received Received 265169 265169 broadcasts, broadcasts, 00 runts, runts, 00 giants, giants, 0 throttles throttles 00 input input errors, errors, 00 CRC, CRC, 00 frame, frame, 00 overrun, overrun, 00 ignored, ignored, 00 abo abort rt ... ... rest rest deleted deleted ... ...
© 2001, Cisco Systems, Inc.
Congestion Avoidance -35
The show interface command will display whether or not WRED is the preferred congestion avoidance mechanism on the interface.
5-32
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
WRED Parameters and Statistics Router# show queueing random-detect
• Displays per-interface parameters WRED statistics Router#show Router#show queueing queueing random-detect random-detect Current Current random-detect random -detect configuration: configuration: Serial1/0 Serial1/0 Queueing Queueing strategy: strategy: random random early early detection detection (WRED) (WRED) Exp-weight-constant: Exp-weight-constant: 99 (1/512) (1/512) Mean Mean queue queue depth: depth: 38 38 Class Class 00 11 22 33 44 55 66 77 rsvp rsvp © 2001, Cisco Systems, Inc.
Random drop drop 174 0 0 0 0 0 0 0 6 0 0 00
Tail drop drop 34 0 0 0 0 0 0 0 3 0 0 00
Minimum threshold threshold 20 22 22 24 24 26 28 31 33 35 35 37 37
Maximum threshold threshold 40 40 40 40 40 40 40 40 40 40 40 40 40
Mark probability probability 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 Congestion Avoidance -36
The show queuing command shows the configuration and statistics for configured WRED profiles.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-33
dWRED Parameters and Statistics Router#show Router#show interfaces interfaces random-detect random-detect FastEthernet1/0/0 FastEthernet1/0/0 queue queue size size 0 0 packets packets output output 29692, 29692, drops drops 00 WRED: WRED: queue queue average average 00 weight weight 1/512 Precedence Precedence 0: 0: 109 109 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 11 packets packets output, output, drops: drops: 00 random, random, 00 threshold threshold Precedence Precedence 1: 1: 122 122 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 (no (no traffic) traffic) Precedence Precedence 2: 2: 135 135 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 14845 14845 packets packets output, output, drops: drops: 0 random, random, 0 threshold threshold Precedence Precedence 3: 3: 148 148 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 (no (no traffic) traffic) Precedence Precedence 4: 4: 161 161 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 (no (no traffic) traffic) Precedence Precedence 5: 5: 174 174 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 (no (no traffic) traffic) Precedence Precedence 6: 6: 187 187 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 14846 14846 packets packets output, output, drops: drops: 0 random, random, 0 threshold threshold Precedence Precedence 7: 7: 200 200 min min threshold, threshold, 218 218 max max threshold, threshold, 1/10 1/10 (no (no traffic) traffic) © 2001, Cisco Systems, Inc.
ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight ma mark rk weight weight
Congestion Avoidance -37
The show interfaces random-detect command shows the dWRED profile configuration for the specified interface. Use this command to display dWRED statistics on interfaces performing distributed services.
5-34
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Queue Details Router# show queue queue intf
• Displays queue contents Router#show Router#show queue queue serial serial 1/0 1/0 Output Output queue queue for for Serial1/0 Serial1/0 is is 65/0 65/0 Packet Packet 1, 1, source: source: data: data:
linktype: linktype: ip, ip, length: length: 1504, 1504, flags: flags: 0x48 0x48 192.168.1.2, 192.168.1.2, destination: destination: 192.168.1.2, 192.168.1.2, id: id: 0x001A, 0x001A, ttl: ttl: 255, 255, prot: prot: 11 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD
Packet Packet 2, 2, linktype: linktype: ip, ip, length: length: 1504, 1504, flags: flags: 0x48 0x48 source: source: 192.168.1.2, 192.168.1.2, destination: destination: 192.168.1.2, 192.168.1.2, id: id: 0x001A, 0x001A, ttl: ttl: 255, 255, prot: prot: 11 data: data: 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD Packet Packet 3, 3, linktype: linktype: ip, ip, length: length: 1504, 1504, flags: flags: 0x48 0x48 source: source: 192.168.1.2, 192.168.1.2, destination: destination: 192.168.1.2, 192.168.1.2, id: id: 0x001A, 0x001A, ttl: ttl: 255, 255, prot: prot: 11 data: data: 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD 0xABCD ... ... rest rest deleted deleted ... ... © 2001, Cisco Systems, Inc.
Congestion Avoidance -38
The show queue command will display the output queue contents.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-35
WRED caveats and restrictions • Since the same policy is applied to all flows, a single non-adaptive flow can monopolize the buffer resources at an interface – RED is suitable when TCP represents at least 80% of the traffic – Non-TCP traffic should be rate-limited
• Non-distributed RED implementation is mutually exclusive with PQ, CQ and WFQ
© 2001, Cisco Systems, Inc.
Congestion Avoidance -39
WRED is very effective in achieving congestion avoidance, but only when at least 80% of traffic is based on the TCP protocol, which can quickly react to selective random drops in some of the sessions. If non-adaptive flows, using for example the UDP protocols, arrive at the interface, those flows do not react to WRED dropping, but can instead monopolize the interface (and its buffers). Such traffic should be rate-limited to enforce a steady traffic mix. Also, WRED cannot be used together with fancy queuing with centralized switching. dWRED and dWFQ can coexist, however, on most distributed applications, sometimes even implemented in interface (line card) hardware.
5-36
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Summary n
WRED uses precedence or DSCP-dependent dropping slopes to differentiate RED dropping for different classes of traffic.
n
WRED is configured on router interfaces and can run distributed on VIPbased interfaces.
Lesson Review 1. What are the key differences between RED and WRED? 2. What can be used as weight in WRED? 3. Which dropping modes does WRED have?
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-37
Flow-based Weighted Random Early Detection Overview The section describes the Flow-based WRED mechanism available in Cisco IOS.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
5-38
Congestion Avoidance
n
Describe the Flow-based WRED mechanism.
n
Describe the benefits of Flow-based RED over normal WRED.
n
Configure Flow-based WRED on Cisco routers.
n
Monitor and troubleshoot Flow-based WRED on Cisco routers.
Copyright 2001, Cisco Systems, Inc.
Flow-based WRED • WRED differentiates between packets of different priority • WRED does not differentiate between packets of different flows • Aggressive flows can monopolize the queue and cause other flows to starve • Flow-based WRED is used to keep track of flows • Flow-based WRED drops packets of aggressive flows ahead of other packets © 2001, Cisco Systems, Inc.
Congestion Avoidance -44
WRED relies on a measurement called the average queue length to determine when to drop packets. When the packet count of the average queue length is in the upper range, WRED begins dropping packets. At this point, WRED applies a nonzero drop probability to all packets that arrive on an interface, indiscriminate of the kinds of flows to which the packets belong. Therefore, normal WRED applies the same loss rate to all kinds of flows, adaptive and non-adaptive. Flow-based Weighted Random Early Detection (FRED) is a feature of WRED that forces WRED to afford greater fairness to all flows on an interface with regard to how packets are dropped. Flow-based WRED relies on these two main approaches to remedy the problem of unfair packet drop: n
It classifies incoming traffic into flows based on parameters such as destination and source addresses and ports.
n
It maintains state information about active flows, which are flows that have packets in the output queues.
Flow-based WRED uses this classification and state information to ensure that each flow does not consume more than its permitted share of the output buffer resources. Flow-based WRED determines which flows monopolize resources, and more heavily penalizes these flows. Here is how flow-based WRED ensures fairness among flows: it maintains a count of the number of active flows that exist through an output interface. Given the number of active flows and the output queue size, flow-based WRED determines the number of buffers available per flow. To allow for some burstiness, flow-based WRED scales the number of buffers available per flow by a configured factor and Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-39
allows each active flow to have a certain number of packets in the output queue. This scaling factor is common to all flows. The outcome of the scaled number of buffers becomes the per-flow limit. When a flow exceeds the per-flow limit, the probability that a packet from that flow will be dropped increases.
5-40
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Types of Flows • There are three types of flows –Robust flows - adapt to packet loss by slowing down (WRED is effective); consistent buffer usage –Fragile flows - cannot adapt to drops (WRED should not be used); low buffer usage –Non-adaptive flows - do not adapt to packet loss (WRED is not effective); high and constant buffer usage
© 2001, Cisco Systems, Inc.
Congestion Avoidance -45
Before you consider the advantages that flow-based WRED offers, it helps to think about how WRED (without flow-based WRED configured) affects different kinds of packet flows. Even before flow-based WRED classifies packet flows, flows can be thought of as belonging to one of these categories: n
Nonadaptive flows, which are flows that do not respond to congestion.
n
Robust flows, which on average have a uniform data rate and slow down in response to congestion.
n
Fragile flows, which, though congestion-aware, have fewer packets buffered at a gateway than do robust flows.
Because of its packet-drop behavior − that is, that all flows, even those with relatively fewer packets in the output queue, are susceptible to packet drop during periods of congestion − WRED tends toward a bias against fragile flows. Though fragile flows have fewer buffered packets, they are dropped at the same rate as packets of other flows.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-41
Flow-based WRED Objective • Per-active-flow loss rate that increases with the flow’s buffer usage –Robust: normal loss rate –Fragile: very light loss rate –Non-adaptive: very high loss rate
© 2001, Cisco Systems, Inc.
Congestion Avoidance -46
As FRED takes a flow’s buffer usage in consideration, it bases its dropping strategy on the amount of buffers used by active flows. The router therefore classifies flows based on their amount of buffer usage, and is able to penalize aggressive flows. All flows are characterized as robust flows, which can adapt to a normal loss rate; fragile flows, which need a very light loss rate; and non-adaptive flows, which can survive a very high loss rate. Therefore, FRED tries to identify non-adaptive flows and impose a higher drop rate onto them, compared to other, better-behaved flows.
5-42
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Flow-based WRED Building Blocks Calculate Average Per-flow Queue Size
WFQ Classifier (hash)
Scaling Factor Calculate Maximum Per-flow Queue Size
IP src&dst addr, PID TCP/UDP src&dst port IP packet
WRED
IP precedence or DSCP
Select WRED Profile
Min. threshold Max. Threshold Max prob. Denom.
Queue Full?
No
Current Number of Queue + Active Size Flows FIFO Queue
Yes
Random Drop
Tail Drop
© 2001, Cisco Systems, Inc.
Congestion Avoidance -47
This block diagram shows how FRED performs its dropping calculations based on the flow classification and queue sizes. An incoming packet is first classified into an active flow. A default WRED profile is chosen for the packet based on the precedence/DSCP value. FRED then determines the characteristics of the flow, by calculating the average per-flow buffer usage (average per-flow queue size) in the system, and based on it, the maximum per-flow queue size, using a scaling factor. By default, FRED computes the maximum per-flow queue size directly from the average queue per-flow queue size (the average size of queue used by flows in the router, calculated as the number of used buffers divided by the number of active flows), using a multiplicative factor of 4. If a flow uses more buffers than the maximum per-flow queue size, Cisco IOS deems the flow non-adaptive, and chooses a more aggressive RED profile for that flow, lowering the maximum threshold by half the difference between the current maximum and minimum threshold difference. In short, a flow is considered non-adaptive when its flow-depth is larger than the expected maximum due to burstiness, which depends on the scaling factor: average-flow-depth * (scaling factor) < flow-depth
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-43
Configuring Flow-based WRED Router(config-if)# random-detect random-detect flow flow
IOS IOS 12.0(3)T
• Configures Flow-based Weighted Random Early Detection on the specified interface • Disables distributed WRED on VIP-based interfaces • Disables all queuing and reverts to FIFO queuing
© 2001, Cisco Systems, Inc.
Congestion Avoidance -48
To enable flow-based WRED, use the random-detect flow interface configuration command. You must use this command to enable flow-based WRED before you can use the random-detect flow average-depth-factor and random-detect flow count commands to further configure the parameters of flow-based WRED.
5-44
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Tuning Flow-based WRED Router(config-if)# random-detect flow average-depth-factor scaling-factor scaling-factor
• Specifies the scaling factor used to compute maximum per-flow queue size from average perflow queue size • Default value is 4 Router(config-if)# random-detect flow flow count count number
• Specifies the maximum number of flows tracked by the flow-based WRED • Default value is 256 © 2001, Cisco Systems, Inc.
Congestion Avoidance -49
Two FRED tuning parameters, the random-detect flow average-depth-factor, and the random-detect flow count, are available to change the default behavior of FRED. The first parameter changes the multiplicative scaling factor used in calculating the maximum per-flow queue size, used to differentiate non-adaptive flows from adaptive and fragile flows. If there is a large number of low-bandwidth flows over an interface (resulting in a very low average per-flow queue size), the scaling factor could be increased to detect truly aggressive flows. The second parameter specifies the maximum amount of flows, tracked by FRED at any given instant (snapshot of the queue). This parameter may be increased to support an interface, carrying a large number of concurrent flows.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-45
Monitoring Flow-based WRED • All standard WRED commands – show interface – show queueing – show queue – show interface random-detect
• Displays flow parameters – show queueing random-detect
© 2001, Cisco Systems, Inc.
Congestion Avoidance -50
To monitor FRED, use the standard (W)RED monitoring commands.
5-46
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Displays Flow Parameters Router# show queueing random-detect CPE_1# show queueing CPE_1#show queueing random-detect random -detect Current Current random-detect random -detect configuration: configuration: Serial0 Serial0 Queueing strategy: Queueing strategy: random random early early detection detection (WRED) (WRED) Exp-weight-constant: Exp-weight -constant: 99 (1/512) (1/512) Mean Mean queue queue depth: depth: 00 Max Average Max flow flow count: count: 256 256 Average depth depth factor: factor: 44 Flows Flows (active/max (active/max active/max): active/max): 0/0/256 0/0/256 Class Class 00 11 22 33 44 55 66 77 rsvp rsvp
© 2001, Cisco Systems, Inc.
Random Random drop drop 00 00 00 00 00 00 00 00 00
Tail Minimum Maximum Mark Tail Minimum Maximum Mark drop drop threshold threshold threshold threshold probability probability 00 20 40 1/10 20 40 1/10 00 22 40 1/10 22 40 1/10 00 24 40 1/10 24 40 1/10 00 26 40 1/10 26 40 1/10 00 28 40 1/10 28 40 1/10 00 31 40 1/10 31 40 1/10 00 33 40 1/10 33 40 1/10 00 35 40 1/10 35 40 1/10 00 37 40 1/10 37 40 1/10
Congestion Avoidance -51
The show queuing command shows the configuration and statistics for configured WRED profiles, together with FRED parameters, such as the number of active flows in the queue, and the depth scaling factor.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-47
Benefits of Flow-based WRED • Ensures that flows that respond to WRED packet drops by backing off packet transmission are protected from flows that do not respond to WRED packet drops • Prohibits a single flow from monopolizing the buffer resources at an interface – Flow-based WRED punishes aggressive UDP flows
© 2001, Cisco Systems, Inc.
Congestion Avoidance -52
FRED therefore has substantial benefits compared to WRED, as it can also be used in environments that do not exhibit a predominantly TCP-based traffic mix. FRED enables differentiated dropping between fragile and non-adaptive flows, in which the loss rate is higher with non-adaptive flows. This is something that WRED is unable to do, because it drops packets without regard to flow buffer usage. Therefore, FRED protects fragile and adaptive flows from non-adaptive flows, which may, in the case of RED, monopolize router queues in their path.
5-48
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Drawbacks of Flow-based WRED • Flow-based WRED is not distributed • Works only in combination with FIFO queuing • Not predictable • Depends on host behavior for effectiveness
© 2001, Cisco Systems, Inc.
Congestion Avoidance -53
Since FRED does not yet run in a distributed mode, and only works in combination with FIFO queuing, its applications are limited. FRED is also not predictable in its operation, and somewhat depends on the behavior of endpoints, which must properly adapt their sending rate based on loss signals from the network.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-49
Summary n
Flow-based WRED differentiates flows and keeps state information about current flows in the output queue.
n
Flow-based WRED can penalize non-adaptive flows by dropping their packets more aggressively.
n
Flow-based WRED is configured on router interfaces
Lesson Review 1. What is the difference between WRED and Flow-based WRED? 2. How many queues does Flow-based WRED have? 3. What are the benefits and drawbacks of Flow-based WRED?
5-50
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Summary n
RED randomly drops packets before an interface is congested, punishing aggressive flows.
n
WRED uses precedence or DSCP-dependent dropping slopes to differentiate RED dropping for different classes of traffic.
n
WRED is configured on router interfaces and can run distributed on VIPbased interfaces.
n
Flow-based WRED differentiates flows and keeps state information about current flows in the output queue.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-51
Review
Questions and Answers Random Early Detection Question: What are the main drawbacks of using tail-drop as a means of congestion control? Answer: Tail drop causes global synchronization of TCP session, TCP starvations, and jitter. Question: What does RED do to prevent TCP synchronization? Answer: RED performs random dropping of packets, as the average queue length indicates a possible trend towards congestion. As aggressive flows usually have more packets in the queue compared to non-aggressive flows, random dropping punishes aggressive flows with higher probability by dropping their packets. Packet drops signal the aggressive TCP sender to slow down and adapt its sending rate. Question: What are the three modes of RED? Answer: RED has three queue management modes: no drop, when the average queue length is below the minimum threshold, random drop, when the average queue length is between the minimum and maximum thresholds and full drop, when the average queue length is above the maximum threshold.
Weighted Random Early Detection Question: What are the key differences between RED and WRED? Answer: WRED can perform differentiated dropping, taking IP precedence or
DSCP value into account. RED drops are based only on the average queue length and all packets share the same drop profile. Question: What can be used as weight in WRED? Answer: IP precedence or DSCP value can be used as the weight in WRED.
Question: Which dropping modes does WRED have? Answer: As is the case with RED, WRED has three queue management modes:
no drop, when the average queue length is below the minimum threshold, random drop, when the average queue length is between the minimum and maximum thresholds and full drop, when the average queue length is above the maximum threshold. With WRED different threshold values are used for each weight (IP precedence or DSCP) value, establishing differentiated dropping profiles.
Flow-based Weighted Random Early Detection 5-52
Congestion Avoidance
Copyright 2001, Cisco Systems, Inc.
Question: What is the difference between WRED and Flow-based WRED? Answer: Flow-based WRED is able to differentiate between different flows based on their buffer usage. Therefore, it is more precise than WRED when differentiating between different senders, and can more appropriately punish aggressive sessions. Question: How many queues does Flow-based WRED have? Answer: By default, Flow-based WRED maintains 256 flow queues. Question: What are the benefits and drawbacks of Flow-based WRED? Answer: Flow-based WRED has the potential to punish aggressive UDP sessions by freeing the queue resources early. It can not, however, lower their sending rate. Also, Flow-based WRED currently does not run distributed on the VIP.
Copyright 2001, Cisco Systems, Inc.
Congestion Avoidance
5-53
6
Link Efficiency Mechanisms
Overview The module describes one approach to handling congested links; compression. It discusses link efficiency mechanisms that either compress the payload of packets (Stacker and Predictor) or reduce packet overhead by compressing their headers (TCP and RTP header compression). It also discusses two different layer-2 link fragmentation mechanisms (PPP Multilink and Frame Relay Fragmentation).
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe and configure Stacker payload compression
n
Describe and configure Predictor payload compression
n
Describe and configure TCP header compression
n
Describe and configure RTP header compression
n
Describe and configure PPP Multilink with interleaving
n
Describe and configure Frame Relay Fragmentation
Payload Compression Overview This lesson describes two payload compression mechanisms. It describes the Stacker and Predictor mechanisms that can be used to reduce the size of data in packets or frames.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
6-2
n
Describe and configure Stacker compression
n
Describe and configure Predictor compression
n
Monitor and troubleshoot compression
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Payload Compression QoS does not create bandwidth. Payload compression does. Payload compression uses a compression algorithm to squeeze the payload of layer-2 frames Payload compression increases perceived throughput and decreases perceived latency
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms -5
While many mechanisms exist for optimizing throughput and reducing delay in network traffic within the QoS portfolio, QoS does not create bandwidth. QoS optimizes the use of existing resources, and enables the differentiation of traffic according to the operator policy. Payload compression does create additional bandwidth, because it squeezes packet payloads, and therefore increases the amount of data that can be sent through a transmission resource in a given time period. Payload compression is mostly performed on layer-2 frames and therefore compresses the entire layer-3 packet. Note that IP PCP (Payload Compression Protocol) is a fairly new technique for compressing payloads on layer 3, and can handle out-of-order data. The IP PCP compression method is not discusses in this lesson. As compression squeezes payloads, it both increases the perceived throughput, and decreases perceived latency in transmission, because smaller, packets (with compressed payloads) take less time to transmit (than the larger, uncompressed packets).
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-3
Compression Building Blocks Forwarder FH
Compression Algorithm
IP
Output Queue FH
Compression is a CPU-intensive task It adds to the overall delay experienced by IP packets.
cIP
Packets reduced in size take less time to transmit. More packets can be transmitted.
Compression reduces the size of the frame payload Entire IP packet is compressed Compression adds delay due to its complexity Serialization delay is reduced, overall latency might be reduced © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms -6
The figure shows a basic block diagram of a compression method. When a router forwards a packet, it is subjected to the layer-2 compression method after it has been encapsulated at the output. The compression method squeezes the payload of the layer-2 frame (the entire layer-3 packet), and transmits the packet on the interface. Layer-2 compression requires serialization of packet delivery, which means that packets must be received by the remote layer-2 station in the same order as they were sent. Compression is a CPU-intensive task and can add per-packet delay due to the application of the compression method to each frame. The transmission (serialization) delay, however, is reduced, because the resulting frame is smaller. Depending on the complexity of the payload compression algorithm, overall latency might be reduced, especially on low-speed links.
6-4
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Compression Results Link bandwidth 256 kbps
NO COMPRESSION
Delay=1 ms
Delay=8 ms
Throughput 256 kbps
Total Delay=9 ms
Link bandwidth 256 kbps
COMPRESSION COMPRESSION
Delay=10 ms
HARDWARE HARDWARE COMPRESSION COMPRESSION
Delay=4 ms
Throughput 500 kbps
Total Delay=14 ms
Link bandwidth 256 kbps
Delay=2 ms
Delay=4 ms
Throughput 500 kbps
Total Delay=6 ms
Compression increases throughput Compressions may increase delay © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms -7
The figure compares three throughput/latency scenarios on a point-to-point link. If no compression is used, the perceived throughput is limited by the link bandwidth, and the average delay is influenced only by the forwarding/buffering delay and the serialization (transmission) delay. If compression is enabled, the packet latency between the two hops is a function of forwarding delay, compression delay, and transmission delay. Even if the transmission delay is now shorter, the compression/decompression delay may increase the overall latency between the two hops. Throughput is generally increased and is limited by the effectiveness of the compression algorithm. If hardware-assisted compression is used, the compression/decompression delays may become insignificant compared to transmission and forwarding delays, and overall latency may decrease. Throughput is again limited by the effectiveness of the compression method and may be significantly higher than the link bandwidth limit.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-5
Compression Algorithms Cisco routers support the following compression algorithms: • STAC or Stacker (STAC Electronics or Hi/fn, Inc.) • MPPC (Microsoft Point-to-point Compression) • Predictor (public domain algorithm)
These algorithms differ in compression capabilities, CPU and memory utilization © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms -8
Cisco IOS supports three different compression algorithms used in layer-2 compression: STAC (or Stacker), Microsoft Point-to-Point Compression (MPPC), and predictor. These algorithms differ vastly in their compression efficiency, and in utilization of router resources.
6-6
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Stacker and MPPC Compression Stacker or STAC is a compression algorithm developed by STAC Electronics Stacker uses the LZ (Lempel-Ziv) algorithm that searches for redundant strings and replaces them with short tokens It builds a dictionary where token values are mapped to these strings MPPC is developed by Microsoft and also uses the LZ algorithm
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms -9
The STAC (or Stacker) algorithm is based on the well-known LZ (Lempel-Ziv) compression algorithm. The LZ (sometimes also called LZW) algorithm searches the byte stream for redundant strings, and replaces them with shorter dictionary tokens. The dictionary is built in real time, and there is no need to exchange the dictionary between the compression peers, because the dictionary is reconstructed from the data received by the remote peer. The MPPC method also uses the same LZ algorithm. The STAC and MPPC algorithms yield very good compression results, but are CPU-intensive.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-7
Predictor Compression Predictor is a public domain compression algorithm Predictor uses a hashed sequence of characters as an index into the compression dictionary The entry in the dictionary is compared to the next sequence of characters
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-10
The predictor is a simple, very fast, and CPU-friendly algorithm, but this algorithm yields a lower compression ratio. It is based on predicting the next byte-sequence in the stream based on a simple dictionary, which is rebuilt from the source or the compressed data without the need to exchange a dictionary between the peers.
6-8
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Stacker/MPPC vs. Predictor Stacker and MPPC are very CPU-intensive • • • • •
Good average compression ratio Slower Produces more delay Should be used on slower links Stacker has more tuning capabilities
Predictor requires more memory • • • •
Less efficient than Stacker or MPPC Faster, uses less CPU time Produces less delay Can be used on faster links
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-11
The STAC, MPPC, and predictor algorithms are usually used to perform layer-2 payload compression on point-to-point links between Cisco IOS routers. The STAC and MPPC methods are CPU-intensive. However these methods yield very good compression rates on the average, produce more compression/decompression delay in the router, and should be used on slower links if software compression is used. Predictor is a leaner and simpler algorithm, which can be deployed on faster links with software compression, and which introduces less delay in the packet path. However, predictor yields considerably lower compression ratios compared to the STAC algorithm.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-9
Compression and Layer-2 Encapsulation STAC
Predictor
MPPC
PPP
ü*
ü
ü
Frame Relay
ü*
O
O
HDLC
ü
O
O
LAPB
ü
ü
O
X.25
ü
O
O
* PPP and Frame Relay Stacker is also supported by hardware compression modules © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-12
The figure shows a comparison of different compression methods used by Cisco IOS to perform layer-2 payload compression. The STAC method is the most versatile, because it runs on any supported point-to-point layer-2 encapsulation. Predictor only supports PPP and LAPB, while MPPC only runs within PPP. Hardware-accelerated compression substantially increases compression throughput for CPU-intensive compression methods (such as STAC and MPPC, both based on the LZ algorithm) and is recommended when used on high-bandwidth links.
6-10
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Performance Compression performance depends on the following factors: • Router platform (CPU power) • Compression algorithm (Stacker, MPPC or Predictor) • Hardware compression support
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-13
Real-life compression performance depends on many factors, the most important being: n
Router CPU performance, if compression is performed in software. The router runs the compression algorithm for each packet on an interface, configured for compression.
n
The compression algorithm because there are large differences in the performance of the algorithm itself. Generally, CPU-intensive algorithms produce better compression ratios.
n
Hardware compression support offloads the task of compression from the CPU, which decreases forwarding latency and frees the CPU to perform other tasks.
n
Data compressibility, which influences both the compression ratio and sometimes the performance of the algorithm itself.
On average, Stacker and MPPC can yield up to 50% reduction in data size (a compression ratio of 2), when used on real network traffic. Predictor can theoretically achieve such a rate, if network traffic includes mostly predictive text data. In most networks, predictor compression ratio is much lower than Stacker’s, and usually in the 30-40% range of data size reduction (that is, compression ratios less than 1.8).
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-11
Configuring Stacker Interface configuration steps: • Select one of the supported layer-2 encapsulations (PPP, F/R, HDLC, LAPB or X.25) • Enable Stacker compression • Optionally select the ratio, force software based compression or enable distributed compression
Monitor compression © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-14
Stacker (STAC) compression is configured on interfaces with the appropriate supported encapsulation. The STAC method can be tuned, and software or hardware compression can be selected. After STAC has been enabled on an interface, Cisco IOS provides a means to monitor the compression ratios in real time.
6-12
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Stacker with PPP Encapsulation Router(config-if)# compress stac stac
• Enables STAC with default parameters Router(config-if)# compress stac stac distributed distributed
• Offloads compression to a VIP • Supported on VIP2-40 or newer Router(config-if)# compress stac stac ratio ratio {high {high || low low || medium} medium}
• Balance throughput with delay • Low compression ratio is the default
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-15
The compress stac command enables STAC compression on an interface with supported encapsulation. STAC can also run distributed on the VIP processor. The compress stac ratio command tunes STAC so that the compression ratio is traded for delay. For example, selecting a low compression ratio produces less CPU usage, while the high compression ratio performs better compression, but increases the CPU load and adds delay, which may decrease throughput. The recommended ratio depends on the type of network traffic and its sensitivity to delay. The rule of thumb is to start with the default low ratio, and try to increase the ratio and measure throughput. If observed compression ratios increase (as shown by the show compression command), but throughput actually decreases, the configured ratio should be lowered again.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-13
Configuring Stacker with Frame Relay Encapsulation Router(config-if)# frame-relay payload-compression payload-compression FRF9 FRF9 stac stac
• Enables STAC with default parameters Router(config-if)# frame-relay payload-compression payload-compression FRF9 FRF9 stac stac distributed distributed
• Offloads compression to a VIP • Supported on VIP2-40 or newer Router(config-if)# frame-relay payload-compression payload-compression FRF9 FRF9 stac stac ratio ratio {high {high || low} low}
• Balance throughput with delay • Low compression ratio is the default
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-16
Cisco IOS supports the native Frame Relay compression protocol according to the FRF.9 standard. The compression method used is equivalent to STAC compression. Also, the commands required to configure Frame Relay STAC compression are analogous to the command used to configure STAC with other supported encapsulations. This command should be used when using the default Frame Relay encapsulation over Frame Relay networks.
6-14
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Predictor or MPPC Router(config-if)# compress predictor predictor
• Enables Predictor compression Router(config-if)# compress mppc mppc [ignore-pfc] [ignore-pfc]
• Enables MPPC compression • Use the ignore-pfc option to ignore the protocol number negotiation
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-17
The compress predictor command configures predictor compression. No tuning parameters are available for this command. The compress mppc command configures MPPC compression, and is used mainly with Windows clients and when running a layer-2 tunneling session (for example, the Point-to-Point Tunneling Protocol (PPTP). The ignore -pfc keyword instructs the router to ignore the protocol field compression flag negotiated by LCP. For example, the uncompressed standard protocol field value for IP is 0x0021 and 0x21 when compression is enabled. When the ignore -pfc option is enabled, the router will continue to use the uncompressed value (0x0021). Using the ignore -pfc option is helpful for some asynchronous driver devices that use an uncompressed protocol field (0x0021), even though the pfc is negotiated between peers. If protocol rejects are displayed when the debug ppp negotiation command is enabled, setting the ignore -pfc option may remedy the problem.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-15
Hardware Compression Hardware compression is available using the following modules: • Compression Advanced Interface Module (CAIM) is a daughter-board module for Cisco 2600 series routers • Compression Service Adapter (CSA) module for Cisco 7x00 series routers • Compression Network Module (NM-COMPR2) for Cisco 3620 and Cisco 3640 series routers • AIM-COMPR4 is a daughter-board compression module for Cisco 3660 series routers © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-18
There are a number of hardware compression modules and daughter boards available for use in Cisco routers.
6-16
n
The Compression Advanced Interface Module (CAIM) is a daughter board that is placed in the AIM motherboard slot on Cisco 2600-series routers. It does not occupy any network interface slots, and accelerates the STAC and MPPC compression methods.
n
The Compression Service Adapter (CSA) is a port adapter for the Cisco 7x00 series routers. The CSA offloads the compression task from the main CPU or the VIP2 (using distributed compression). When used in the Cisco 7200-series router, the CSA can offload compression at any interface. If used on the VIP2, it offloads compression at the adjacent port adapter on the same VIP only.
n
The Compression Network Module is a network module for the Cisco 3600series routers. The Compression Network Module occupies a network module slot in the router, and can offload compression at any router interface.
n
The AIM-COMPR4 is a hardware-compression daughter board used in the Cisco 3660 router. The AIM-COMPR4 integrates with the router motherboard and does not occupy any network module slots in the chassis.
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuration Example interface interface Serial1/0 Serial1/0 encapsulation encapsulation ppp ppp compress compress stac !! interface interface Serial1/1 Serial1/1 encapsulation encapsulation ppp ppp compress compress stac stac caim caim 0 0 !! interface interface Serial1/2 Serial1/2 encapsulation encapsulation ppp ppp compress compress predictor predictor !! interface interface Serial1/2 Serial1/2 encapsulation -relay encapsulation frame frame-relay frame-relay frame-relay map map ip ip 1.1.1.1 1.1.1.1 102 102 broadcast broadcast ietf ietf !! interface interface Serial1/2.1 Serial1/2.1 point-to-point point-to-point frame-relay frame-relay interface-dlci interface-dlci 101 ietf frame-relay frame-relay payload-comp payload-comp FRF9 FRF9 stac stac !!
© 2001, Cisco Systems, Inc.
Software compression using the STAC algorithm Hardware compression using the STAC algorithm on the CAIM module (Cisco 2600 routers) Software compression using the Predictor algorithm
payload-compress payload-compress frf9 stac stac Software compression using the STAC algorithm
IP QoS Link Efficiency Mechanisms-19
The figure shows configuration examples that specify different compression configurations. In the example, the Serial1/0 interface uses software compression (this setting may automatically use hardware compression on high-end series). The Serial1/1 interface performs compression with the assistance of the CAIM (in a Cisco 2600-series router). Interfaces Serial1/2 and its Serial 1/2.1 sub-interface both use software STAC compression on the frame-relay level.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-17
Monitoring Compression Router#
show compression compression
• Displays compression statistics Router#show Router#show compression compression Serial5/1/0 Serial5/1/0 Software Software compression compression enabled enabled uncompressed uncompressed bytes bytes xmt/rcv xmt/rcv 21339/21339 21339/21339 compressed bytes compressed bytes xmt/rcv xmt/rcv 0/0 0/0 11 min min avg ratio xmt/rcv 2.110/2.110 55 min min avg avg ratio ratio xmt/rcv xmt/rcv 2.143/2.143 2.143/2.143 10 10 min min avg avg ratio ratio xmt/rcv xmt/rcv 2.143/2.143 2.143/2.143 no no bufs bufs xmt 0 no bufs rcv 0 resyncs resyncs 00 Additional Additional Stacker Stacker Stats: Stats: Transmit 00 Compressed Transmit bytes: bytes: Uncompressed Uncompressed == Compressed == Received 9953 Received bytes: bytes: Compressed Compressed == 9953 Uncompressed Uncompressed ==
© 2001, Cisco Systems, Inc.
9109 9109 00
IP QoS Link Efficiency Mechanisms-20
The show compression command displays per-interface compression statistics. The ratio shown in the output indicates the compression ratio (the ratio of uncompressed over the actual compressed byte stream size) on the input and the output of an interface.
6-18
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Summary n
Stacker and MPPC payload compression methods yield better compression ratios, is more CPU-intensive, and may introduce additional delay
n
The predictor payload compression method is faster, can be used in higherbandwidth scenarios, but generally yields lower average compression ratios
Lesson Review 1. What is the purpose of using payload compression? 2. List the payload compression algorithms than can be used. 3. What are some of the benefits and drawbacks of Stacker? 4. What are some of the benefits and drawbacks of Predictor?
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-19
Header Compression Overview This lesson describes the mechanisms that are used to reduce overhead on slow links by compressing IP and TCP headers in TCP header compression, or IP, UDP and RTP headers in RTP header compression.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
6-20
n
Describe and configure TCP header compression
n
Monitor and troubleshoot TCP header compression
n
Describe and configure RTP header compression
n
Monitor and troubleshoot RTP header compression
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Header Compression Header compression reduces the overhead by compressing packet and segment headers TCP Header compression compresses the IP and TCP headers RTP header compression compresses the IP, UDP and RTP headers Header compression is especially effective on slow links with interactive traffic or delay sensitive traffic (many short packets)
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-26
All compression methods are based on eliminating redundancy when sending the same or similar data over a transmission medium. One piece of data, which is often repeated, is the protocol header. In a flow, the header information of packets in the same flow does not change much over the lifetime of that flow. Therefore, most of header information could be sent only at the beginning of the session, stored in a dictionary, and then referenced in later packets by a short dictionary index. Two methods were standardized by the IETF (Internet Engineering Task Force) for use with IP protocols: n
TCP header compression (also known as the Van Jacobson or VJ header compression) is used to compress the packet TCP headers over slow links, thus considerably improving the interactive application performance.
n
RTP header compression is used to compress UDP and RTP headers, thus lowering the delay for transporting real-time data, such as voice and video over slower links.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-21
Header Compression Basics Compression is performed by eliminating static or predicable header information Session indices are used instead Only changing parameters in headers are still sent Header compression is enabled on a linkby-link basis
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-26
Header compression methods work by not transmitting repeated information in packet headers throughout a session. For a TCP session, such parameters are the IP header and the TCP port numbers. The two peers on a point-to-point layer-2 connection (such as a dial-up link) agree on session indices, which index a dictionary of packet headers. The dictionary is built at the start of every session, and is used for all subsequent (non-initial) packets. Only changing (non-constant) parameters in the headers are actually sent with the session index. It is important to note that header compression is performed on a link-by-link basis. Header compression cannot be performed across multiple routers, because routers need full Layer-3 header information to be able to route packets to the next hop.
6-22
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Header Compression Building Blocks Header Compression Algorithm
Forwarder FH
IP
L4 (L5)
payload
Output Queue FH
The header compression algorithm keeps track of flows and static parameters in headers
cH
payload
IP and higher-layer headers are compressed
Compression reduces the size of packet headers The payload is not changed © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-28
The figure shows a block diagram of a header compression method. The header compression algorithm tracks active transport-layer connections over an interface. After the packet has been forwarded, the header compression algorithm compresses the layer-3 and layer-4 headers within the frame, and replaces them with a session index from the session dictionary (table). The packet is then sent to the output queue, and transmitted to the remote peer. When the remote peer receives the packet, the header is decompressed using the local session table, and passed to the forwarding process.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-23
Header Compression Results NO COMPRESSION Link bandwidth 64 kbps Delay=1 ms
COMPRESSION COMPRESSION
Throughput 64 kbps
Delay=8 ms
Link bandwidth 64 kbps
Throughput 100 kbps
Delay=4 ms Delay=2 ms
Header compression increases throughput Header compressions reduces delay © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-29
By compressing the header, the layer-2 frame gets smaller and therefore more data is sent through a channel in a given time period. Also, the packet transmission time is smaller; therefore header compression both increases the throughput and reduces the overall delay of a transmission line.
6-24
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Header Compression Algorithms TCP Header Compression (RFC 1144) • Used to reduce the overhead of TCP segments • Most effective on slow links with a lot of TCP sessions with small payloads (for example, Telnet)
RTP Header Compression (RFC 1889) • Used to reduce delay and increase throughput for Real Time Protocol (RTP) • Improves voice quality • Most effective on slow links © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-30
The two header compression methods available in Cisco IOS are the TCP header compression (standardized by RFC 1144), and the RTP header compression (standardized by RFC 1889). TCP header compression is usually used to improve the interactive session response over low-speed links, where layer-3 and layer-4 headers represent a significant portion of the layer-2 frame. RTP header compression is used mostly on slow links, to reduce delay and increase throughput of an RTP-based application (usually voice traffic).
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-25
TCP Header Compression Most Internet Applications use TCP as the transport protocol Most of the information in the headers (IP and TCP) is static or predictable throughout the session IP (20 bytes) and TCP (20 bytes) use 40 bytes TCP Header Compression can squeeze these two headers into 3 to 5 bytes © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-31
With TCP header compression, the IP and TCP headers, which normally use 20 bytes each, is reduced to a session index, and the changing part of the header. With all optimizations, the combined header length of 40 bytes can be reduced to a 3 to 5-byte compressed header.
6-26
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
TCP Header Compression Case Study Link bandwidth is 64 kbps The link is used for a number of interactive TCP sessions PPP encapsulation is used Average packet size is 5 bytes Each segment has 46 bytes of overhead (PPP, IP and TCP headers) © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-32
This case study illustrates the benefits of TCP header compression on slow links. A 64 kbps link is used to transport a TCP-based application using PPP as the layer-2 framing protocol. For the case study application (telnet), the average packet payload size is 5 bytes. Since PPP has 6 bytes of frame header, the total header overhead is 6+20+20=46 bytes, counting the PPP, IP, and TCP headers.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-27
TCP Header Compression Case Study 6
20
PPP
IP
20 TCP
5
6
4
5
Telnet
PPP
cT
Telnet
46 5 Overhead = 46/(46+5) Overhead = 90% Delay = (46+5) / 64 kbps Delay = 6 ms IP packet Overhead Delay on size No comp. 64 kbps 10 82% 7 ms 50 48% 12 ms 100 32% 18 ms 500 8% 67 ms 1500 3% 189 ms © 2001, Cisco Systems, Inc.
10 5 Overhead = 10/(10+5) Overhead = 67% Delay = (10+5) / 64kbps Delay = 2 ms Overhead Comp. 50% 17% 9% 2% 1%
Delay on 64 kbps 2 ms 7 ms 13 ms 62 ms 184 ms IP QoS Link Efficiency Mechanisms-33
The figure shows the packet size before and after header compression. The IP and TCP headers are reduced to 4 bytes, resulting in 10 bytes of overall headers. The overhead is reduced from 90% to 67%, when small packets are used. Because of size reduction, the transmission delay decreases from 6 ms to 2 ms on the same link. The table in the figure shows how header compression impacts performance when different packet sizes are used. Header compression is most effective on small packets, used on slow links.
6-28
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring TCP Header Compression Router(config-if)#
ip tcp header-compression [passive]
• Enables TCP Header Compression on an interface using PPP or HDLC encapsulation • Use the passive option to enable TCP Header Compression only if initiated by the peer Router(config-if)#
frame-relay ip tcp header-compression [passive]
• Enables TCP Header Compression on an interface using Frame Relay encapsulation • Use the passive option to enable TCP Header Compression only if initiated by the peer © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-34
TCP header compression is configured with the ip tcp header-compression command. The passive option instructs the peer to use header compression only if the remote peer initiates header compression. This is often used in a dialup environment, where this option is enabled on the access server. On frame relay, the frame-relay ip tcp header-compression configures header compression with interfaces using pure frame relay encapsulation. In Cisco IOS, TCP header compression is now fast and CEF-switched. Up to 256 connections, which is also the default value, can be compressed over a point-topoint link.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-29
TCP Header Compression Example interface Serial0/0 ip address 10.2.1.2 255.255.255.252 encapsulation frame-relay frame-relay ip tcp header -compress !
interface Dialer1 ip address negotiated ip tcp header-compression !
Frame Relay
POTS / ISDN
RouterA
RouterC
RouterB interface Serial0 ip address 10.2.1.1 255.255.255.252 encapsulation frame-relay frame-relay ip tcp header -compression ! interface Virtual-template1 ip address 10.1.1.1 255.255.0.0 ip tcp header-compression passive ! © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-34
The figure shows an example configuration of three peers using TCP header compression. RouterC uses header compression on a dialer interface, connecting to the central access server (RouterB). The access server (RouterB) is configured to perform header compression only if the remote peer (RouterC) initiates it, and therefore supports peers using headercompression, and peers using plain layer-2 transmission. The access server (RouterB) connects to a remote site (RouterA) over framerelay. Both frame-relay endpoints (RouterA and RouterB) are configured to perform TCP header compression over the frame-relay link.
6-30
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Monitoring TCP Header Compression Router# show ip ip tcp tcp header-compression header-compression [interface]
• Displays TCP Header Compression statistics Router#show Router#show ip ip tcp tcp header-compression header-compression serial0/0 serial0/0 TCP/IP TCP/IP header header compression compression statistics: statistics: Interface Interface Serial0/0: Serial0/0: Rcvd: 24 total, 20 compressed, Rcvd: compressed, 0 errors errors 00 dropped, dropped, 00 buffer buffer copies, copies, 00 buffer buffer failures failures Sent: 24 Sent: 24 total, total, 20 20 compressed, compressed, 679 679 bytes bytes saved, saved, 249 249 bytes bytes sent sent 3.72 3.72 efficiency efficiency improvement improvement factor factor Connect: Connect: 255 255 rx slots, 255 tx tx slots, slots, 12 12 long long searches, searches, 44 misses misses 00 collisions collisions 83% 83% hit hit ratio, ratio, five five minute minute miss miss rate rate 00 misses/sec, misses/sec, 00 max
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-36
The show ip tcp header-compression command displays the statistics of TCP header compression on an interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-31
Monitoring TCP Header Compression Router# show frame-relay ip ip tcp tcp header-compression header-compression [interface]
• Displays TCP Header Compression statistics on frame-relay (sub)interfaces Router#show Router#show frame-relay frame-relay ip ip tcp tcp header-compression header-compression DLCI Link/Destination DLCI 100 100 Link/Destination info: info: point-to-point point -to-point dlci dlci Interface Interface Serial0/0: Serial0/0: Rcvd: 24 total, 23 compressed, Rcvd: compressed, 0 errors errors 00 dropped, dropped, 00 buffer buffer copies, copies, 00 buffer buffer failures failures Sent: 27 Sent: 27 total, total, 26 26 compressed, compressed, 864 864 bytes bytes saved, saved, 225 225 bytes bytes sent sent 4.84 4.84 efficiency efficiency improvement improvement factor factor Connect: 256 rx slots, 256 tx slots, Connect: 256 tx slots, 11 long searches, searches, 1 misses 0 collisions collisions 96% 96% hit hit ratio, ratio, five five minute minute miss miss rate rate 00 misses/sec, misses/sec, 00 max
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-37
The show frame -relay ip tcp header-compression command displays the statistics of TCP header compression on a Frame Relay interface.
6-32
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
RTP Header Compression Voice sessions use Real-time Transport Protocol (RTP) RTP uses UDP for transport Most of the information in the headers (IP, UDP and RTP) is static throughout the session IP (20 bytes), UDP (8 bytes) and RTP (12 bytes) use 40 bytes RTP header compression can squeeze these three headers into 3 to 5 bytes © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-37
Real-Time Protocol (RTP) is the Internet Standard (RFC 1889) protocol for the transport of real-time data. It is intended to provide end-to-end network transport functions for applications that support audio, video, or simulation data over multicast or unicast network services. RTP is used in most Voice over IP applications to transport packetized voice. RTP includes a data portion and a header portion. The data portion of RTP is a thin protocol that provides support for the real-time properties of applications, such as continuous media, and includes timing reconstruction, loss detection, and content identification. RTP contains a relatively large sized header. The 12 bytes of the RTP header, combined with 20 bytes of IP header (IPH) and 8 bytes of the User Datagram Protocol (UDP) header, create a 40-byte IP/UDP/RTP header. For compressed-payload audio applications, the RTP packet typically has a 20-byte to 160-byte payload. Given the size of the IP/UDP/RTP header combinations, it is inefficient to send the IP/UDP/RTP header without compressing it. To avoid the unnecessary consumption of available bandwidth, the RTP header compression feature (CRTP) is used on a link-by-link basis. CRTP can reduce the header from 40 bytes to a 3 to 5-byte header, which significantly reduces delay on slow links.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-33
RTP Header Compression Case Study Link bandwidth is 64 kbps The link is used for Voice over IP PPP encapsulation is used G.729 codec is used (8 kbps of voice data, 50 samples per second, 20 bytes per sample) Each segment has 46 bytes of overhead (PPP, IP, UDP and RTP headers)
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-39
This case study illustrates the benefits of RTP header compression on slow links. A 64 kbps link is used to transport Voice over IP using PPP as the layer-2 framing protocol. For the case study application (voice using the G.729 audio compression codec), the average payload size is 20 bytes. Since PPP has 6 bytes of frame header, the total header overhead is 6+20+20=46 bytes, counting the PPP, IP, UDP, and RTP headers.
6-34
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
RTP Header Compression Case Study 6
20
PPP
IP
46
8 12
20
UDP RTP
Voice
6
4
PPP
20
10
cR
20 Voice
20
Overhead = 46 / (46 + 20) = 70% Delay = (46 + 20) / 64 kbps = 8 ms BW = (46 + 20) * 50 * 8 = 26 kbps
Overhead = 10 / (10 + 20) = 33% Delay = (10 + 20) / 64kbps = 4 ms BW = (10 + 20) * 50 * 8 = 12 kbps
2 voice sessions / 64 kbps
5 voice sessions / 64 kbps
Codec
Voice Bandwidth G.711 64 kbps G.729 8 kbps
© 2001, Cisco Systems, Inc.
RTP Bandwidth 82 kbps 26 kbps
RTP Overhead 22% 61%
CRTP Bandwidth 68 kbps 12 kbps
CRTP Overhead 3% 33%
IP QoS Link Efficiency Mechanisms-40
The figure shows the packet size before and after header compression. The IP, UDP, and RTP headers are reduced to 4 bytes, resulting in 10 bytes of overall headers. The overhead is reduced from 70% to 33%, when small packets are used. Because of size reduction, the transmission delay decreases from 8 ms to 4 ms, and the bandwidth used to transport a single voice call (using the G.729 codec) is reduced from 26 to 12 kbps. The table in the figure shows how header compression impacts performance when a different audio codec is used. For the traditional G.711 voice codec, CRTP still optimizes its transmission over slow links. However, the difference is more obvious when using advanced, low-bandwidth codecs are used.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-35
Configuring RTP Header Compression Router(config-if)#
ip rtp header-compression [passive]
• Enables RTP Header Compression on an interface using PPP or HDLC encapsulation • Use the passive option to enable RTP Header Compression only if initiated by the peer Router(config-if)#
frame-relay ip rtp header-compression [passive]
• Enables RTP Header Compression on an interface using Frame Relay encapsulation • Use the passive option to enable RTP Header Compression only if initiated by the peer © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-41
RTP header compression is configured with the ip rtp header-compression command. The passive option instructs the peer to use RTP header compression only if the remote peer initiates RTP header compression. On frame relay, the frame-relay ip rtp header-compression configures header compression with interfaces using pure frame relay encapsulation. In Cisco IOS, RTP header compression is now fast and CEF-switched. If distributed CEF (dCEF) is configured, CRTP also runs in distributed mode. Up to 256 connections, which is also the default value, can be compressed over a pointto-point link.
6-36
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
RTP Header Compression Example interface Serial0/0 ip address 10.2.1.2 255.255.255.252 encapsulation frame-relay frame-relay ip rtp header-compression !
interface Serial0/0 ip address 10.1.1.2 255.255.255.252 encapsulation ppp ip rtp header-compression !
RouterB Frame Relay RouterA
RouterC TDM (leased line)
ip cef distributed ! interface Serial5/1/0 ip address 10.2.1.1 255.255.255.252 encapsulation frame-relay frame-relay ip rtp header-compression ! interface Serial5/1/1 ip address 10.1.1.1 255.255.0.0 encapsulation ppp ip rtp header-compression ! © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-41
The figure shows an example implementation of CRTP on a two-tiered scenario, where two sites (using routers Router A and RouterC) are interconnected over a TDM and Frame Relay network. Over the TDM network, a leased line carries all (including packetized voice) traffic. RTP header compression is used within the PPP session between RouterA and RouterB. Over the frame-relay network, the point-to-point Frame Relay channel between RouterB and RouterC uses CRTP over the native Frame Relay encapsulation.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-37
Monitoring RTP Header Compression Router# show ip ip rtp rtp header-compression header-compression [interface]
• Displays RTP Header Compression statistics Router#show Router#show ip ip rtp rtp header-compression header-compression serial0/0 serial0/0 RTP/UDP/IP RTP/UDP/IP header header compression compression statistics: statistics: Interface Interface Serial1: Rcvd: Rcvd: 00 total, total, 00 compressed, compressed, 00 errors errors 00 dropped, dropped, 00 buffer buffer copies, 0 buffer failures Sent: Sent: 430 total 429 compressed, 15122 15122 bytes bytes saved, saved, 139318 139318 bytes bytes sent sent 1.10 1.10 efficiency efficiency improvement improvement factor factor Connect: Connect: 16 rx slots, slots, 16 tx tx slots, slots, 1 long searches, 1 misses 99% 99% hit hit ratio, ratio, five five minute minute miss miss rate 0 misses/sec, 0 max.
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-43
The show ip rtp header-compression command displays the statistics of CRTP on an interface.
6-38
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Monitoring RTP Header Compression Router# show frame-relay ip ip tcp tcp header-compression header-compression [interface]
• Displays RTP Header Compression statistics on frame-relay (sub)interfaces Router#show Router#show frame-relay frame-relay ip ip tcp tcp header-compression header-compression DLCI DLCI 17 17 Link/Destination Link/Destination info: info: ip ip 165.3.3.2 165.3.3.2 Interface Interface Serial0: Serial0: Rcvd: 00 total, Rcvd: total, 00 compressed, compressed, 00 errors errors 00 dropped, dropped, 00 buffer buffer copies, copies, 00 buffer buffer failures failures Sent: 6000 Sent: 6000 total, total, 5998 5998 compressed, compressed, 227922 227922 bytes bytes saved, saved, 251918 251918 bytes bytes sent sent 1.90 1.90 efficiency efficiency improvement improvement factor factor Connect: 16 rx slots, 16 tx slots, 2 long searches, Connect: 16 rx slots, 16 tx slots, 2 long searches, 22 misses misses 99% 99% hit hit ratio, ratio, five five minute minute miss miss rate rate 00 misses/sec, misses/sec, 00 max
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-44
The show frame -relay ip rtp header-compression command displays the statistics of CRTP on a frame-relay interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-39
Summary n
TCP header compression optimizes performance of interactive TCP-based applications on slow links, by shrinking IP and TCP headers to 3-5 byte indices
n
RTP header compression optimizes performance of delay-sensitive RTP-based applications, such as voice, on slow links, by shrinking IP, UDP, and RTP headers to 3-5 byte indices
n
TCP and RTP header compression methods can be implemented with Cisco IOS software
Lesson Review 1. List the different header compression methods than can be used. 2. Where are header compression mechanisms most effective? 3. What type of traffic benefits most by using TCP Header Compression? 4. What type of traffic benefits most by using RTP Header Compression?
6-40
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Link Fragmentation and Interleaving Objectives This lesson describes the mechanism used to reduce the maximum size of PPP or Frame Relay frames. It also explains the interleaving of multiple frames of large packets with frames of small packets.
Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe Link Fragmentation and Interleaving (LFI)
n
Describe and configure Multilink PPP
n
Monitor and troubleshoot Multilink PPP
n
Describe and configure Frame Relay Fragmentation
n
Monitor and troubleshoot Frame Relay Fragmentation
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-41
Queuing and Serialization Delay 8ms
Empty Network
8ms
64 kbps Delay Variation Queuing Delay
Congested Network
8ms
184 ms
8ms
64 kbps
Problems: • Large delay due to slow link and MTU-sized packets • Jitter (variable delay) due to variable link utilization © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-49
When considering delay between two hops in a network, queuing delay in a router must be considered, because it may be comparable to, or even exceed the transmission delay on a line. In an empty network, an interactive or voice session experiences low or no queuing delay, because it does not compete with other applications on an interface output queue. Also, the small delay does not vary enough to produce considerable jitter on the receiving side. In a congested network, interactive data and voice applications compete in the router queue with other applications. Queuing mechanisms may prioritize voice traffic in the software queue, but the hardware queue (Tx ring) always uses a FIFO scheduling mechanism. Therefore, after packets of different applic ations leave the software queue, they will mix with other packets in the hardware queue, even if their software queue processing was expedited. Thus, a voice packet may be immediately sent to the hardware queue, where two large FTP packets may still be waiting for transmission. The voice packet must wait until the FTP packets are transmitted, thus producing a delay in the voice path. Because links are variably utilized, this delay varies with time and may produce unacceptable jitter in jitter-sensitive applications such as voice.
6-42
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Voice Reassembly Probability of arrival
Less delay More loss
Usable packets
More delay Less loss
Jitter
Unusable packets
Min. Delay
Avg. Delay
Delay
Playback Point (max. Acceptable Delay)
Jitter can be offset by more buffering More buffering causes even more delay which is not acceptable for two-way communication © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-49
Jitter can always be offset by more buffering on the receive side. However, more buffering produces more overall delay. This delay must not cross certain thresholds in delay-sensitive applications, such as packetized voice. The voice delay threshold (usually around 150 ms of one-way delay) represents the limit at which the quality of packetized voice telephony is still regarded as acceptable by end users.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-43
Voice Reassembly Probability of arrival
Less delay More loss
More delay Less loss
Usable packets
Jitter
Unusable packets
Min. Delay
Avg. Delay
Delay
Playback Point (max. Acceptable Delay)
The right solution is to reduce average delay © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-50
A better solution than adding additional buffering is to reduce the average delay along the packet path. This allows for more jitter before packets are deemed unusable by the voice reassembly on the receiving endpoint (IP telephone). Reduced average delay can be provided through link fragmentation and interleaving, by reducing delays on critical links in the packet path.
6-44
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Link Fragmentation and Interleaving Delay to large B2
A3
Fragmentation
A3
B1
A2
TxQ
A1
Interleaving
A3 A3 A3 A2 B3 A2 A2 A2 B2 A1 A1 A1 B1 A1
Reduce delay and jitter by fragmenting large frames and prioritizing small frames © 2001, Cisco Systems, Inc.
TxQ
Acceptable Delay
IP QoS Link Efficiency Mechanisms-52
Link fragmentation and interleaving (LFI) is a layer-2 technique, where all layer-2 frames are broken into small, equal-size fragments, and transmitted over the link in an interleaved fashion. The figure shows the interface hardware output queue, populated by frames of differing sizes; large and small. When fragmentation and interleaving is in effect, all frames waiting in the queuing system are fragmented, smaller frames are prioritized, and a mixture of fragments is sent over the link. Small frames may be scheduled behind larger frames in the WFQ system. LFI fragments all frames, and this reduces the queuing delay of small frames, as they are sent almost immediately. Link fragmentation therefore reduces delay and jitter by expediting transfer of smaller frames through the hardware queue.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-45
LFI with WFQ MTU=1500 WFQ
TxQ TxQ is sized in the number of packets
WFQ
TxQ MTU=1500, LFI MTU=160
Maximum delay caused by the TxQ is the number of packets multiplied by the time it takes to transmit the longest frame (usually MTU-sized)
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-52
The longest delay, used with the WFQ scheduling algorithm, is the product of the number of packets in the queue and the size of the maximum packet (to calculate the worst-case delay at any instant). Before LFI, the maximum possible size of a packet was limited by the interface MTU, which might be set to a value up to 1500 bytes on a serial line. LFI MTU is considerably smaller, because it reflects the maximum size of a fragment in a LFI implementation. For example, an LFI MTU of 160 bytes (which is commonly used) reduces the worst-case maximum delay to one tenth of the delay of a normal nonLFI-enabled link, because the next scheduled fragment now has to wait only until the previous fragment has been transmitted. Before using LFI, any packet had to wait until the whole previous frame has been transmitted, which might be up to the full MTU in size.
6-46
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Fragmentation Options Three types of LFI mechanisms are available: • Multilink PPP with Interleaving • FRF.11 Annex C specification for VoFR PVCs • FRF.12 specification for data PVCs
Using separate PVCs for voice and data can be used to interleave packets in ATM networks
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-53
There are three LFI mechanisms implemented in Cisco IOS: n
Multilink PPP with Interleaving is by far the most common and widely used form of LFI.
n
FRF.11 Annex C LFI is used with Voice over Frame Relay (VoFR).
n
FRF.12 Frame Relay LFI is used with Frame Relay data connections.
n
In an ATM network, using separate PVCs carrying voice and data can be used to interleave packets when they are output on an interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-47
Configuring MLP with Interleaving Configuration steps: • Enable Multilink PPP on an interface (using a Multilink Group interface) • Enable PPP Multilink interleaving on the Multilink interface • Specify maximum fragment size by setting the maximum delay on the Multilink interface
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-54
To configure Multilink PPP (MLP) with interleaving, the following configuration steps must be performed:
6-48
Step 1
First, enable multilink on an interface (using a multilink group interface).
Step 2
Second, in the multilink interface, enable interleaving within Multilink PPP.
Step 3
Third, in the multilink interface configuration, specify the maximum fragment size of MLP by specifying the maximum desired delay on the point-to-point link.
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring MLP with Interleaving Router(config-if)#
ppp multilink
• Enables Multilink PPP • Also requires WFQ or CB-WFQ to be enabled on the interface Router(config-if)#
ppp multilink interleave
• Enables interleaving of frames with fragments Router(config-if)#
ppp multilink multilink fragment-delay fragment-delay delay delay
• Configure maximum fragment delay in milliseconds • The router calculates the maximum fragment size from the bandwidth and the maximum fragment delay • Default is 30 ms © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-56
The ppp multilink command enables PPP multilink on an interface. This requires either Weighted Fair Queuing (WFQ) or CB-WFQ (Class-Based Weighted Fair Queuing) to be enabled on the same interface. The ppp multilink interleave command enables interleaving of fragments within the multilink connection. The ppp multilink fragment delay command specifies the maximum desired fragment delay for the interleaved multilink connection. The maximum fragment size is calculated from the interface bandwidth and the specified maximum delay. The default is set at 30 milliseconds. If dCEF is configured on a VIP interface, MLP with interleaving runs distributed on the VIP.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-49
MLP with Interleaving Example interface interface Multilink1 Multilink1 ip ip address 10.1.1.1 10.1.1.1 255.255.255.252 255.255.255.252 fair-queue fair-queue ppp ppp multilink multilink multilink-group multilink-group 1 ppp ppp multilink multilink fragment-delay 20 ppp ppp multilink multilink interleave interleave !! interface interface Serial0/0 Serial0/0 no no ip address address encapsulation encapsulation ppp ppp ppp multilink multilink multilink-group multilink-group 1 !!
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-56
The figure shows an example configuration of MLP with interleaving on a multilink group interface. A non-default maximum desired delay of 20 ms is configured.
6-50
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting MLP Interleaving Router# show interface interface [intf] [intf]
• Displays statistics including the number of interleaved frames Router #show interfaces Router#show interfaces multilink multilink 11 Multilink1 Multilink1 is is up, up, line line protocol protocol is is up up Hardware is multilink Hardware is multilink group group interface interface Internet Internet address address is is 172.22.130.1/30 172.22.130.1/30 MTU MTU 1500 1500 bytes, bytes, BW BW 64 64 Kbit, Kbit, DLY DLY 100000 100000 usec, usec, reliability reliability 255/255, 255/255, txload txload 27/255, 27/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation PPP, loopback loopback not not set set Keepalive set (10 sec) Keepalive set (10 sec) DTR DTR is is pulsed pulsed for 2 seconds on reset LCP LCP Open, Open, multilink multilink Open Open Open: Open: IPCP IPCP Last Last input input 00:00:03, 00:00:03, output output never, never, output output hang hang never never Last Last clearing clearing of "show interface" counters 6d00h Input Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total Total output output drops: drops: 00 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 0/1000/64/0/2441 0/1000/64/0/2441 (size/max (size/max total/threshold/drops/interleaves) total/threshold/drops/interleaves) Conversations Conversations 0/7/16 0/7/16 (active/max (active/max active/max active/max total) total) Reserved Conversations 0/0 (allocated/max Reserved Conversations 0/0 (allocated/max allocated) allocated) 55 minute minute input input rate rate 00 bits/sec, bits/sec, 00 packets/sec packets/sec 55 minute minute output output rate rate 7000 7000 bits/sec, bits/sec, 66 packets/sec packets/sec © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-59
The show interface command output includes MLP statistics information and indicates whether MLP Interleaving is enabled on the interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-51
Monitoring and Troubleshooting MLP Interleaving Router# debug ppp multilink multilink fragments
• Displays information about individual multilink fragments and interleaving events Router#debug Router#debug ppp ppp multilink multilink fragments fragments Multilink Multilink fragments fragments debugging debugging is is on on Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar Mar
17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17
20:03:08.995: -FS: II 20:03:08.995: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.015: -FS: II 20:03:09.015: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.035: -FS: II 20:03:09.035: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.075: Se0/0 MLP -FS: II 20:03:09.075: Se0/0 MLP-FS: 20:03:09.079: Se0/0 MLP -FS: II 20:03:09.079: Se0/0 MLP-FS: 20:03:09.091: -FS: II 20:03:09.091: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.099: -FS: II 20:03:09.099: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.103: 20:03:09.103: Mu1 Mu1 MLP: MLP: Packet Packet 20:03:09.107: Se0/0 MLP -FS: II 20:03:09.107: Se0/0 MLP-FS: 20:03:09.119: Se0/0 MLP -FS: 20:03:09.119: Se0/0 MLP-FS: II 20:03:09.123: 20:03:09.123: Mu1 Mu1 MLP: MLP: Packet Packet 20:03:09.131: 20:03:09.131: Mu1 Mu1 MLP: MLP: Packet Packet 20:03:09.135: -FS: II 20:03:09.135: Se0/0 Se0/0 MLP MLP-FS: 20:03:09.155: Se0/0 MLP -FS: 20:03:09.155: Se0/0 MLP-FS: II
© 2001, Cisco Systems, Inc.
seq seq C0004264 C0004264 size size 70 70 seq seq 80004265 80004265 size size 160 160 seq seq 4266 4266 size size 160 160 seq 4267 size 160 seq 4267 size 160 seq seq 40004268 40004268 size size 54 54 seq seq C0004269 C0004269 size size 70 70 seq seq C000426A C000426A size size 70 70 interleaved interleaved from queue 24 seq C000426B size 70 seq C000426B size 70 seq seq C000426C C000426C size size 70 70 interleaved interleaved from queue 24 interleaved 24 interleaved from from queue queue 24 seq seq C000426D C000426D size size 70 70 seq C000426E size 70 seq C000426E size 70
IP QoS Link Efficiency Mechanisms-60
The debug ppp multilink fragments command is a valuable troubleshooting tool when monitoring MLP operations. The command outputs the result of every fragmentation operation, indicating whether the interleave operation fragments packets into correct-sized fragments. This command should be used with extreme caution in a production environment, because of the amount of output created.
6-52
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Frame Relay Fragmentation FRF.11 Annex C specifies fragmentation of voice frames (VoFR): • Only frames with data payload type are fragmented • Voice bypasses the fragmentation engine regardless of frame size
FRF.12 specifies fragmentation of data frames: • Data frames that exceed the specified fragmentation size are fragmented • Smaller time -sensitive packets can be interleaved • VoIP packets do not get a special treatment
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-61
In Frame Relay networks, two fragmentation standards are available on layer-2 (within the Frame Relay encapsulation): n
When Voice over Frame Relay (FRF.11) and fragmentation are both configured on a PVC, Frame Relay fragments are transmitted in the FRF.11 Annex C format. This fragmentation method is used when FRF.11 voice traffic is transmitted on the PVC and uses the FRF.11 Annex C fragmentation standard. With FRF.11, all data packets contain fragmentation headers regardless of size. This form of fragmentation is not recommended for use with Voice over IP.
n
FRF.12 fragmentation is defined by the FRF.12 Implementation Agreement. The FRF.12 Implementation Agreement was developed to allow long data frames to be fragmented into smaller pieces and interleaved with real-time frames. In this way, real-time voice and non-real-time data frames are carried together on lower-speed links without causing excessive delay to the real-time traffic. As a result, FRF.12 is the recommended fragmentation to be used with VoIP.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-53
FRF.12 versus FRF.11 Annex-C Fragmentation FRF.11 Annex-C Fragmentation
FRF.12 Fragmentation
Used on DLCIs configured for VoFR Does not fragment voice packets regardless of what fragmentation size is configured Must be supported by platforms that support VoFR
Used on DLCIs carrying data traffic only (including VoIP) Fragments voice packets if the fragmentation size parameter is set to a value smaller than the voice packet size Predominantly used for VoIP – Must be supported only by Cisco IOS platforms that transport VoIP over slow speed WAN links
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-61
If a PVC is not configured for VoFR, it uses normal Frame Relay (FRF.3.1) data encapsulation. If fragmentation is turned on for this DLCI, it uses FRF.12 for the fragmentation headers. PVCs carrying VoIP use FRF.12 fragmentation because VoIP is a layer 3 technology that is transparent to layer 2 Frame Relay. VoIP and VoFR can be supported on different PVCs on the same interface, but not on the same PVC. FRF.12 fragments voice packets if the fragmentation size parameter is set to a value smaller than the voice packet size. FRF.11 Annex-C (VoFR) does not fragment voice packets regardless of what fragmentation size is configured. FRF.11 Annex-C needs only to be supported by platforms that support VoFR. Because FRF.12 is predominantly used for VoIP, it is important to use FRF.12 as a general feature on Cisco IOS platforms that transport VoIP over slow speed WAN links.
6-54
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Implementation Notes When Frame Relay fragmentation is configured, the following conditions and restrictions apply: • WFQ at the PVC level is the only queuing strategy that can be used. • FRTS must be configured to enable FR fragmentation • VoFR frames are never fragmented, regardless of size. • When using FRF.12 fragmentation, the VoIP packets will not include the FRF.12 header, provided the size of the VoIP packet is smaller than the fragment size configured. However, when using FRF.11 Annex C or Cisco proprietary fragmentations, VoIP packets will include the fragmentation header. • If fragments arrive out of sequence, packets are dropped © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-62
When deploying a solution using Fragmentation and Interleaving on a Frame Relay backbone, it is a good idea to be aware of the following key issues: n
At the PVC level, WFQ is the only permitted queuing strategy when used together with Frame Relay fragmentation
n
Frame Relay Traffic Shaping must be enable d together with Frame Relay Fragmentation
n
If native voice over Frame Relay (VoFR) is used, its frames are never fragmented
n
In VoIP applications, FRF.11 Annex C adds an additional fragmentation header to packets, while FRF.12 does not
n
If the Frame Relay network delivers fragments out of sequence, fragments are dropped and a lost frame results.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-55
Configuring Frame Relay Fragmentation (FRF.11 C) Router(config)#
map-class frame-relay name
• Enter Map Class configuration mode Router(config-map-class)#
frame-relay fragment size
• Set the maximum fragment size Router(config-map-class)#
frame-relay voice voice bandwidth bandwidth bps
• Set aside an amount of bandwidth for FRF.11 voice traffic (VoFR) © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-64
FRF.11 Annex C fragmentation is configured within the Frame Relay map class. The frame-relay fragment command sets the maximum fragment size. The frame-relay voice bandwidth command reserves an amount of bandwidth used only for FRF.11-encapsulated VoFR traffic.
6-56
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Configuring Frame Relay Fragmentation (FRF.11 C) Router(config-if)# | (config-subif)# | (config-fr-dlci)#
frame-relay class name name
• Apply the Frame Relay Map Class to an interface, subinterface or DLCI Router(config-fr-dlci)#
vofr
• Enable FRF.11 encapsulation Router(config-map-class)#
service-policy output name
• Use distributed Class-based Low Latency Queuing on Cisco 7500 routers to prioritize VoFR frames • Traditional WFQ can be used on all other platforms © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-65
On an interface, the frame-relay class command applies the map class to the interface, subinterface, or a DLCI. The vofr interface command changes the encapsulation on a DLCI to support only FRF.11 VoFR traffic. The service-policy output command, used within a map class, applies a QoS policy to the frame relay traffic class. Low Latency Queuing (configured within CB-WFQ) is recommended on a VoFR circuit.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-57
Configuring Frame Relay Fragmentation (FRF.12) Router(config)#
map-class frame-relay name
• Enter Map Class configuration mode Router(config-map-class)#
frame-relay fragment size
• Set the maximum fragment size Router(config-if)# | (config-subif)# | (config-fr-dlci)#
frame-relay class name name
• Apply the Frame Relay Map Class to an interface or subinterface © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-66
FRF.11 Annex C fragmentation is also configured within the Frame Relay map class. The frame-relay fragment command sets the maximum fragment size. On an interface, the frame-relay class command applies the map class to the interface, sub-interface, or a DLCI.
6-58
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Frame Relay Fragmentation FRF.11 C Example interface interface serial serial 0/0 0/0 encapsulation frame-relay frame-relay frame-relay traffic shaping !! interface interface serial serial 0/0.1 0/0.1 point-to-point point-to-point frame-relay frame-relay interface-dlci interface-dlci 100 100 vofr class class FRF11 FRF11 !! map-class map-class frame-relay frame-relay FRF11 FRF11 frame-relay frame-relay fragment fragment 160 160 frame-relay frame-relay cir cir 65536 65536 frame-relay frame-relay bc bc 2600 2600 frame-relay frame-relay fair-queue fair-queue !!
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-67
The figure shows a configuration example where FRF.11 Annex C fragmentation is applied to a VoFR circuit configured on the Serial0/0.1 interface. The maximum fragment size is set to 160 bytes.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-59
Frame Relay Fragmentation FRF.12 Example interface interface serial serial 0/0 0/0 encapsulation frame-relay frame-relay frame-relay traffic shaping !! interface interface serial serial 0/0.1 0/0.1 point-to-point point-to-point frame-relay frame-relay interface-dlci interface-dlci 100 100 class class FRF12 FRF12 !! map-class map-class frame-relay FRF12 frame-relay frame-relay fragment fragment 160 160 frame-relay frame-relay cir cir 65536 65536 frame-relay frame-relay bc bc 2600 2600 frame-relay frame-relay fair-queue fair-queue !!
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-68
The figure shows a configuration example where FRF.12 fragmentation is applied to a data Frame Relay circuit configured on the Serial0/0.1 interface. The maximum fragment size is also set to 160 bytes. This would be used in a VoIP over Frame Relay environment.
6-60
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting Frame Relay Fragmentation Router# show frame-relay pvc pvc [interface intf] [dlci]
• Displayst PVC parameters and statistics
The following values are possible: • VoFR – FRF.11 Annex C Relay DTE) • VoFR-cisco – Cisco Relay DTE) proprietary fragmentation STATIC, STATIC, INTERFACE INTERFACE• =end-to-end = Serial1 Serial1– FRF.12 fragmentation in in bytes bytes 1730 1730 in in FECN FECN pkts pkts 00 out out BECN BECN pkts pkts 00
Router# -relay pvc Router# show show frame frame-relay pvc interface interface serial serial 1 45 PVC PVC Statistics Statistics for for interface interface Serial1 Serial1 (Frame (Frame DLCI DLCI == 45, 45, DLCI DLCI USAGE USAGE == LOCAL, LOCAL, PVC PVC STATUS STATUS ==
input output input pkts pkts 85 85 output pkts pkts 289 289 out dropped out bytes bytes 6580 6580 dropped pkts pkts 11 11 in out in BECN BECN pkts pkts 00 out FECN FECN pkts pkts 00 in out in DE DE pkts pkts 00 out DE DE pkts pkts 00 out out out bcast bcast pkts pkts 00 out bcast bcast bytes bytes 00 pvc pvc create create time time 00:02:09, 00:02:09, last last time time pvc pvc status status changed changed 00:02:09 00:02:09 Service type VoFR Service type VoFR configured configured voice voice bandwidth bandwidth 25000, 25000, used used voice voice bandwidth bandwidth 22000 22000 fragment fragment fragment type type VoFR VoFR fragment size size 100 100 cir bc 1000 be limit 125 interval cir 20000 20000 bc 1000 be 00 interval 50 50 mincir 20000 byte increment 125 BECN mincir 20000 byte increment 125 BECN response response no no fragments 290 bytes 6613 fragments delayed 1 bytes fragments 290 bytes 6613 fragments delayed 1 bytes delayed delayed 33 33 shaping shaping inactive inactive ... ... © 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-69
The show frame -relay pvc command output includes settings related to either FRF.11 Annex C or FRF.12 fragmentation. The output shows the fragment size used on the Frame Relay PVC.
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-61
Monitoring and Troubleshooting Frame Relay Fragmentation Router# show frame-relay fragment fragment [interface intf] [dlci]
• Displayst PVC parameters and statistics Router#show Router#show frame-relay frame-relay fragment fragment interface dlci interface dlci frag-type frag-type Serial0 108 VoFR-cisco Serial0 108 VoFR-cisco Serial0 109 VoFR Serial0 109 VoFR Serial0 110 end-to-end Serial0 110 end-to-end
frag-size frag-size 100 100 100 100 100 100
in-frag in-frag 1261 0 0 0
out-frag out-frag 1298 243 0 0
dropped-frag dropped-frag 0 0 0 0
Router#show Router#show frame-relay frame-relay fragment fragment interface interface Serial1/0 Serial1/0 fragment-size fragment fragment-size 45 45 fragment type type end-to-end end-to-end in out in fragmented fragmented pkts pkts 00 out fragmented fragmented pkts pkts 00 in out in fragmented fragmented bytes bytes 0 0 out fragmented fragmented bytes bytes 00 in out -fragmented pkts in un-fragmented un-fragmented pkts pkts 00 out un un-fragmented pkts 00 in un-fragmented bytes 0 out un -fragmented in un-fragmented bytes 0 out un-fragmented bytes bytes 0 0 in out in assembled assembled pkts pkts 00 out pre-fragmented pre-fragmented pkts pkts 00 in out in assembled assembled bytes 0 out pre-fragmented pre-fragmented bytes bytes in out in dropped reassembling pkts pkts 00 out dropped dropped fragmenting fragmenting pkts pkts 00 in in timeouts timeouts 0 in out-of-sequence fragments 0 in out -of-sequence fragments 0 in in fragments fragments with with unexpected unexpected BB bit bit set set 00 out out interleaved interleaved packets packets 00
© 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms-70
The show frame -relay fragment command displays statistics of Frame Relay fragmentation methods. This output shows whether Frame Relay fragmentation is in effect and working as configured. The output also shows possible fragmentation timeouts, indicating that some fragments were lost in the Frame Relay network and could not be reassembled. If the number of timeouts is significant, this may indicate significant frame loss in the Frame Relay network.
6-62
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Summary n
Link fragmentation and interleaving methods reduce the average delay on a transmission line by fragmenting frames into small fragments and scheduling their transfer in an interleaved fashion
n
Multilink PPP with Interleaving is the preferred LFI method, used with the PPP protocol
n
FRF.11 C and FRF.12 are the preferred LFI methods, used in a Frame Relay environment
n
Multilink PPP with Interleaving, FRF.11 C, and FRF.12 methods are available in Cisco IOS
Lesson Review 1. List the different link fragmentation methods that can be used. 2. What mechanism is needed to implement link fragmentation with PPP encapsulation? 3. What are the differences between different Frame Relay link fragmentation mechanisms?
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-63
Summary
6-64
n
Stacker and MPPC payload compression methods yield better compression ratios, is more CPU-intensive, and may introduce additional delay
n
The Predictor payload compression is faster, can be used in higher-bandwidth scenarios, but generally yields lower average compression ratios
n
TCP header compression optimizes performance of interactive TCP-based applications on slow links, by shrinking IP and TCP headers to 3-5 byte indices
n
RTP header compression optimizes performance of delay-sensitive RTP-based applications, such as voice, on slow links, by shrinking IP, UDP, and RTP headers to 3-5 byte indices
n
Multilink PPP with Interleaving is the preferred LFI method, used with the PPP protocol
n
FRF.11 C and FRF.12 are the preferred LFI methods, used in a Frame Relay environment
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Payload Compression Question: What is the purpose of using payload compression? Answer: The purpose of payload compression is primarily to increase throughput of a link, and secondarily, to decrease propagation delay on a link. Question: List the payload compression algorithms than can be used. Answer: Cisco IOS supports Stacker, predictor, and MPPC algorithms to compress Layer-2 link data. Question: What are some of the benefits and drawbacks of Stacker? Answer: Stacker provides good compression ratios with most types of traffic and works on most Layer-2 encapsulations. On the downside, Stacker is very CPU intensive and may have throughput limitations and increase processing delay. Question: What are some of the benefits and drawbacks of Predictor? Answer: Predictor is very fast and works well on text-type traffic. Predictor does not yield very good compression ratios with all types of traffic, and supports only select encapsulations.
Header Compression List the different header compression methods than can be used. Where are header compression mechanisms most effective? What type of traffic benefits most by using TCP Header Compression? What type of traffic benefits most by using RTP Header Compression?
Link Fragmentation and Interleaving Question: List the different link fragmentation methods that can be used. Answer: Cisco IOS supports TCP and RTP header compression. Question: What mechanism is needed to implement link fragmentation with PPP encapsulation? Answer: PPP link fragmentation is implemented with PPP Multilink with Interleaving. Question: What are the differences between different Frame Relay link fragmentation mechanisms?
Copyright 2001, Cisco Systems, Inc.
IP QoS Link Efficiency Mechanisms
6-65
Answer: The FRF.11 Annex C method is used only to fragment Voice over Frame Relay (VoFR). The FRF.12 method is used only to fragment data over Frame Relay, including Voice over IP.
6-66
IP QoS Link Efficiency Mechanisms
Copyright 2001, Cisco Systems, Inc.
7
Signaling Mechanism
Overview The module describes RSVP as the signaling mechanism used in QoS enabled networks. The module builds on knowledge about the IntServ model with the addition of Common Open Policy Service (COPS) discussed in the introductory module.
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe Resource Reservation Protocol (RSVP).
n
Configure RSVP.
n
Describe and configure RSVP on shared media using Subnet Bandwidth Management (SBM).
n
Monitor and troubleshoot RSVP.
Resource Reservation Protocol (RSVP) Overview The section introduces Resource Reservation Protocol (RSVP) as the signaling mechanism in QoS-enabled networks using the Integrated Services model.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
7-2
n
Describe Resource Reservation Protocol (RSVP).
n
Configure RSVP.
n
Monitor and troubleshoot RSVP.
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Resource Reservation Protocol • RSVP is a protocol used to reserve resources in a path between a source and a destination • RSVP signals all network devices that a certain application needs certain QoS guarantees • RSVP requires applications to initiate the request • RSVP by itself does not provide any guarantees • An RSVP-interoperable QoS mechanism (WFQ, CBWFQ) must be used to implement guarantees according to RSVP reservations
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-5
RSVP is an Internet Engineering Task Force (IETF) signaling protocol, used to reserve bandwidth in a path between a source and a destination. In RSVP, the end-node (the application node) station reserves bandwidth for a flow along its path to a destination in a network. The user can supply the information about how much capacity to reserve. RSVP mechanisms enable real-time traffic to reserve bandwidth necessary for consistent latency. A video conferencing application can use settings in the router to propagate a request for a path with the required bandwidth and delay for video conferencing destinations. RSVP then signals all network devices along the path, and confirms or rejects the reservation. RSVP will check and repeat reservations at regular intervals. When RSVP is used, the routers sort and prioritize packets much as a statistical time-division multiplexer would sort and prioritize several signal sources that share a single channel. RSVP requires RSVP-aware applications, as signaling is performed by the endnode. In addition, RSVP does not provide any guarantees by itself. RSVP is the protocol used to communicate QoS requirements between the end-node and the layer-3 network, assessing the ability or inability of the network to support the requested level of service. RSVP is the signaling protocol underlying the IntServ QoS reference model. Together with appropriate QoS-enforcing mechanisms in the network, such as WFQ, it forms a foundation for implementation of IntServ-based services.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-3
End-to-end RSVP Local Admission Control
Local Admission Control request
reserve
request
reserve
Local Admission Control request
reserve
request
reserve
• All network devices have to be enabled for RSVP • Each network device determines whether it has enough resources
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-6
If end-to-end RSVP is desired in a network, all devices in the reservation path must be RSVP-enabled. When a device receives an RSVP message, it determines whether it has enough resources to satisfy the reservation request at the local level. There are two main RSVP messages used for signaling. When a reservation is needed, the sending client sends an RSVP PATH message into the network requesting a specific bandwidth to a specific destination (or multicast address, in the case of IP multicast application). The purpose of the PATH message is to discover all RSVP-enabled routers along the path from the sender to the receiver, and to create initial reservations. The PATH message is forwarded along the flow path and every intermediate RSVP-capable router adds its identification to the PATH message. When the receiving end-node receives the PATH message, it confirms the reservation by replying with an RSVP RESV message. The RESV message is forwarded back upstream towards the initial sender using the list of RSVP-enabled routers generated by the PATH message. If the RESV message successfully arrives at the initial sender, each hop in the end-to-end connection has reserved the appropriate resources and an end-to-end reservation is established. If the appropriate resources are not available, the reservation is refused and the application must default to traditional, best effort communications. RSVP keeps track of the soft state of reservations in routers. This soft state provides dynamic membership information, adapts to routing changes, and, as the number of flows increases, enables dynamic changes in reservations to meet those changing needs. RSVP reservations time out unless periodically refreshed by the communication endpoint, usually at 30-second intervals. The benefits of soft state behavior are:
7-4
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
n
Connectionless behavior − routers automatically adapt to route changes.
n
Timeliness − state changes propagate immediately, but only as far as needed.
n
n
Robustness − the method is self-correcting, because incorrect reservations will always time-out even in the most unexpected situations. Flexibility − provides easy dynamic reservation changes.
The cost of this approach is that it requires ongoing refresh processing for established states by the endpoints.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-5
Pass-through RSVP Local Admission Control
Local Admission Control request
reserve
Local Admission Control
request request
RSVP not enabled
reserve
request
request
reserve
reserve
reserve
Best-effort forwarding
• Part of the network may not support RSVP • Best-effort delivery is used in those parts
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-7
When a part of the network does not support RSVP, that is, when the RSVP messages are not processed by every intermediate hop between the two application endpoints, some other mechanism may be employed to try to meet the application requirements in the non-RSVP-enabled part of the network. One such possibility may be to perform only best-effort delivery between RSVP-enabled networks using an undersubscribed network in between. The PATH messages discover all RSVP-aware routers, and are forwarded as plain IP packets on nonRSVP-enabled hops. The RESV messages are then interpreted only by the RSVPaware hops, discovered via the PATH message.
7-6
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Pass-through RSVP with Class of Service Local Admission Control
Local Admission Control request
reserve
Local Admission Control
request request
RSVP not enabled
reserve
request
request
reserve
reserve
reserve
Mark RSVP flow with DSCP
Class-based guarantee
• Part of the network may not support RSVP • Mark RSVP flows with a Class-of-service marker (e.g. IP precedence or DSCP) • Make sure the core provides guarantees to the RSVP class © 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-8
Another option may be to apply class-of-service based delivery on a non-RSVPenabled part of the network. In that case, RSVP-based application traffic is marked with appropriate class markers (IP precedence or DSCP bits) at the entry to the non-RSVP-enabled part. The core network can then be engineered to provide special service to the RSVP class, using, for example, WFQ and WRED. IP precedence and DSCP are packet markers, located in the ToS byte of the IP header, which identify traffic classes on each hop in the network. IP precedence or DSCP bits are usually set at the network edge, where traffic is classified and marked, and the markers used to identify traffic classes in downstream network devices. Each device along the path may apply appropriate QoS mechanisms based on the packet marker, resulting in differentiated per-hop behaviour (PHB) for each class of traffic. The DiffServ model defines several standard PHBs, based on marking traffic with the DSCP header bits.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-7
RSVP Applications • RSVP is used for applications where bandwidth and delay related guarantees are necessary • Typical applications are: – Voice over IP (Cisco phones, Microsoft NetMeeting, ...) – MPLS Traffic Engineering
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-9
RSVP allows end systems to request QoS guarantees from the network. The need for network resource reservations differs for data traffic versus real-time traffic, as described in the following paragraphs: n
Data traffic seldom needs reserved bandwidth because internetworks provide datagram services for data traffic. This asynchronous packet switching may not need guarantees of service quality. End-to-end controls between data traffic senders and receivers help ensure adequate transmission of bursts of information.
n
Real-time traffic (that is, voice or video information) experiences problems when using datagram services. Because real-time traffic sends an almost constant flow of information, the network “pipes” must be consistent. Some guarantee must be provided that service between real-time hosts will not vary. Routers operating on a first-in, first-out (FIFO) basis risk unrecoverable disruption of the real-time information that is being sent.
Many network-aware applications today use RSVP for signaling. Some wellknown examples include Cisco IP telephones, Microsoft NetMeeting, and MPLS Traffic Engineering.
7-8
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Configuring Simple RSVP Router(config-if)#
ip rsvp rsvp bandwidth bandwidth [total-BW [per-flow-BW]]
• Set the amount of reservable bandwidth (total-BW) and the maximum per-flow reservable bandwidth (per-flow-BW) in kbps • Both default to 75% of the configured bandwidth • Total reservable bandwidth cannot exceed 75% of the configured bandwidth Router(config-if)#
bandwidth bandwidth
• Set the interface bandwidth in kbps • This value should reflect the real bandwidth of the link
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-10
Basic RSVP is configured by two interface commands. The ip rsvp bandwidth command sets the maximum total amount of reservable bandwidth on an interface. By default, it is configured to 75% of the configured bandwidth, which is also its maximum allowed value. A per-flow reservable bandwidth can also be configured, setting the maximum bandwidth a single flow can reserve over this interface. By default, it is also set to 75% of the configured bandwidth. Note
RSVP cannot be configured with VIP-distributed Cisco Express Forwarding (dCEF).
The bandwidth interface command sets the interface bandwidth and is used by routing protocols (to calculate costs) and by a variety of QoS mechanisms. With RSVP, this is used as the configured bandwidth parameter, referenced by the limits in the ip rsvp bandwidth command.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-9
Configuring Proxy RSVP Router(config)# ip ip rsvp rsvp sender sender session-IP sender-IP sender-IP protocol protocol dport dport sport sport src-hopsrc-hopIP IP src-intf bandwidth burst
• Simulates a host sending a PATH message • Generates a PATH message on behalf of a host or an application Router(config)# ip ip rsvp reservation reservation session-IP sender-IP protocol dport sport next-hop-IP next-hop-intf {ff {ff | se | wf} {rate | load} bw burst
• Simulates a host sending a RESV message • Generates a RESV message on behalf of a host or an application © 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-11
RSVP typically requires both host and network implementations, although Cisco IOS software provides an RSVP command line interface that allows you to statically set up RSVP reservations without host involvement. Use the ip rsvp sender command to make the router simulate that it is receiving RSVP PATH messages from an upstream host. The command can be used to proxy RSVP PATH messages for non-RSVP-capable senders. By including a local (loopback) previous hop address and previous hop interface, you can also use this command to proxy RSVP for the router you are configuring. To enable a router to simulate receiving and forwarding Resource Reservation Protocol (RSVP) RESV messages, use the ip rsvp reservation global configuration command. To disable this feature, use the no form of this command. Use this command to make the router simulate receiving RSVP RESV messages from a downstream host. This command can be used to proxy RSVP RESV messages for non-RSVP-capable receivers. By giving a local (loopback) next hop address and next hop interface, you can also use this command to proxy RSVP for the router you are configuring. Several different reservation types can be specified. For detailed reservation settings, consult the Cisco IOS documentation.
7-10
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
RSVP Admission Control • RSVP has two tasks: – Determine if there are enough available resources – Determine if the application in question is allowed access to these resources
• RSVP-enabled devices keep track of existing reservations locally • RSVP-enabled devices can offload the authorization part of admission control to central servers (COPS)
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-12
A RSVP-enabled router therefore needs to perform two tasks: n
The router needs to determine whether there are currently available resources, which can be used to satisfy the reservation request.
n
The router needs to be able to authorize an application to make the reservation request (admission control).
The first task can be performed by keeping track of existing reservations, and of total reservable capacity locally on each device. If a reservation request exceeds the locally available reservable resources, the reservation request is denied. Authorization of reservations could be performed locally, but such an approach would not scale to more than a few devices. Fortunately, there is a standardized, centralized framework for policy networking, which includes authorization within admission control. This framework is based on a set of services and protocols called the Common Open Policy Service (COPS).
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-11
Common Open Policy Service Local Admission Control request
request
reserve
Policy Enforcement Point (PEP) request
reserve
Local Admission Control request
reserve
reply
request
reserve
Remote Admission Control
Policy Decision Point (PDP)
• COPS allows a more centralized approach to building RSVP enabled networks (more scalable) • COPS provides additional control over who can reserve what © 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-13
Common Open Policy Service (COPS) is an open framework designed for management in policy networking. COPS provides a service to network devices and implements management protocols, which enable scalable provisioning of Quality of Service policies in a network. COPS is designed so that it provides a centrally managed, but distributed system for configuring network devices according to centralized policy decisions. In the case of RSVP, COPS provides centralized databases, which network devices query for reservation/admission control information. RSVP-enabled devices therefore need no locally stored configuration, but receive this information in realtime from the appropriate COPS server. COPS, therefore, scales QoS provisioning, and enables a device-independent QoS policy throughout the network. COPS defines the following types of policy services:
7-12
n
The Policy Enforcement Point (PEP) is the device that enforces network policy (a router performing RSVP admission control, a firewall filtering traffic).
n
The Policy Decision Point (PDP) is the device that stores policy information and makes it available to the PEP devices.
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Configuring RSVP for COPS ip rsvp policy local acl Process Locally?
ip rsvp policy local
Yes
Yes
Reject?
No
Reject Message Send an error message to the source
No ip rsvp policy local local-override
Default Local Policy?
Yes
Local Override?
No
No
Process Remotely?
Ask PDP
No
Default Remote Policy? No © 2001, Cisco Systems, Inc.
Yes
Reject?
Yes
No
Yes
Process Message Default Reject?
Yes
No IP QoS Signaling Mechanism-14
The figure shows the flowchart used to consult either the local policy settings, or the COPS service. Both the local policy and the COPS service can be used simultaneously on the same router. Individual COPS commands are also presented in the flowchart, next to the functions they enable. The admission process in policy networking proceeds as follows for locally processed messages: n
The router receives a PATH or RESV message and first tries to adjudicate it locally (that is, without referring to the policy server). If the router has been configured to adjudicate specific access control lists (ACLs) locally and the message matches one of those lists, the policy module of the router applies the operators with which it had been configured. Otherwise, policy processing continues.
n
For each message rejected by the operators, the router sends an error message to the sender and removes the PATH or RESV message from the database. If the message is not rejected, policy processing continues.
n
If the local override flag is set for this entry, the message is immediately accepted with the specified policy operators. Otherwise, policy processing continues.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-13
Configuring RSVP for COPS (cont.) Process Locally?
Yes
Reject?
No
Default Local Policy?
Yes
No
Yes
Local Override?
No ip rsvp policy cops acl servers
Yes
No
Process Remotely?
Ask PDP
No
Reject?
Yes
No
ip rsvp policy cops servers Default Remote Policy? No © 2001, Cisco Systems, Inc.
Reject Message Send an error message to the source
Yes
Process Message Default Reject? No
Yes ip rsvp policy default-reject
IP QoS Signaling Mechanism-15
If policy decisions are offloaded to a policy server, policy processing continues as follows: n
If the message does not match any ACL configured for local policy, the router applies the default local policy. However, if no default local policy has been configured, the message is directed toward remote policy processing.
n
If the router has been configured with specific ACLs against specific policy servers (more specifically, PDPs), and the message matches one of these ACLs, the router sends that message to the specific PDP for adjudication. Otherwise, policy processing continues.
n
If the PDP specifies a “reject” decision, the message is discarded and an error message is sent back to the sender, indicating this condition. If the PDP specifies an “accept” decision, the message is accepted and processed using normal RSVP processing rules.
n
If the message does not match any ACL configured for specific PDPs, the router applies the default PDP configuration. If a default COPS configuration has been entered, policy processing continues. Otherwise, the message is considered to be unmatched.
n
If the default policy decision for unmatched messages is to reject, the message is immediately discarded and an ERROR message is sent to the sender indicating this condition. Otherwise, the message is accepted and processed using normal RSVP processing rules.
Whenever a request for adjudication (of any sort) is sent to a PDP, a 30-second timer associated with the PATH or RESV message is started. If the timer runs out
7-14
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
before the PDP replies to the request, the PDP is assumed to be down and the request is given to the default policy.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-15
RSVP Example interface Serial0/0 bandwidth 128 ip address 10.10.3.33 255.255.255.252 encapsulation ppp fair-queue 64 256 10 ip rtp header-compression ip rsvp bandwidth 80
interface Serial0/0 bandwidth 256 ip address 10.5.8.65 255.255.255.252 encapsulation ppp fair-queue 64 256 20 ip rtp header-compression ip rsvp bandwidth 160
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-15
The figure shows a basic example of RSVP configuration in Cisco IOS routers. The two routers in the figure are both configured for RSVP, and both utilize WFQ to guarantee bandwidth to RSVP flows in RSVP-reserved queues. Different maximum reservable bandwidths are allocated, based on the real bandwidth of the link.
7-16
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
RSVP with COPS Example COPS (PEP)
COPS (PDP)
interface Serial0/0 bandwidth 2048 ip address 10.1.1.1 255.255.255.252 encapsulation ppp fair-queue 64 256 100 ip rsvp bandwidth 512 ! ip rsvp policy cops 100 servers 10.100.1.1 10.101.1.1 ip rsvp policy default-reject ip rsvp policy cops minimal ip rsvp policy cops timeout 600 ip rsvp policy cops report-all ! access-list 100 permit udp any any
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-16
This figure shows a COPS-enabled RSVP configuration. The RSVP interface configuration does not change, and COPS parameters are defined with the ip rsvp policy commands. In this example, the COPS PDP adjudicates all UDP traffic reservations.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-17
Monitoring and Troubleshooting RSVP Router#
show ip rsvp installed [detail]
• Lists installed reservations per interface Router#show Router#show ip ip rsvp rsvp installed installed RSVP:Ethernet2/1 RSVP:Ethernet2/1 BPS To From Protoc BPS To From Protoc Conversation Conversation 44K 145.20.0.202 145.10.0.201 UDP 44K 145.20.0.202 145.10.0.201 44K 145.20.0.202 145.10.0.201 UDP 44K 145.20.0.202 145.10.0.201 98K 145.20.0.202 145.10.0.201 UDP 98K 145.20.0.202 145.10.0.201 UDP 1K 145.20.0.202 145.10.0.201 UDP 1K 145.20.0.202 145.10.0.201 UDP RSVP:Serial3/0 RSVP:Serial3/0 has has no no installed installed reservations reservations
© 2001, Cisco Systems, Inc.
DPort DPort Sport Sport
Weight
1000 1001 1001 1002 1002 10 10
0 13 13 6 6 00
1000 1001 1001 1002 1002 10 10
264 264 266 266 265 265 264 264
IP QoS Signaling Mechanism-17
The show ip rsvp installed command shows all active conversations over an RSVP-enabled path, which has resource reservations installed. The actual reserved bandwidth is shown, along with the session parameters (endpoints and applications).
7-18
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting RSVP Router#
show ip rsvp installed [detail] [interface] Router#show Router#show ip ip rsvp rsvp installed installed detail detail RSVP:Ethernet2/1 RSVP:Ethernet2/1 has has the the following following installed installed reservations reservations RSVP RSVP Reservation. Reservation. Destination Destination is is 145.20.0.202, 145.20.0.202, Source Source is is 145.10.0.201, 145.10.0.201, Protocol Protocol is is UDP, UDP, Destination Destination port port is is 1000, 1000, Source Source port port is is 1000 1000 Reserved Reserved bandwidth:44K bandwidth:44K bits/sec, bits/sec, Maximum Maximum burst:1K burst:1K bytes, bytes, Peak Peak rate: rate: 44K 44K bits/sec bits/sec QoS 0 (PQ) QoS provider provider for for this this flow:WFQ. flow:WFQ. Conversation Conversation number:264. number:264. Weight: Weight:0 (PQ) Conversation supports 1 reservations Conversation supports 1 reservations Data Data given given reserved reserved service:316 service:316 packets packets (15800 (15800 bytes) bytes) Data Data given given best-effort best-effort service:0 service:0 packets packets (0 (0 bytes) bytes) Reserved Reserved traffic traffic classified classified for for 104 104 seconds seconds Long-term Long-term average average bitrate bitrate (bits/sec):1212 (bits/sec):1212 reserved, reserved, 0M 0M best-effort best-effort RSVP Reservation. Destination is 145.20.0.202, RSVP Reservation. Destination is 145.20.0.202, Source Source is is 145.10.0.201, 145.10.0.201, Protocol Protocol is is UDP, UDP, Destination Destination port port is is 1001, 1001, Source Source port port is is 1001 1001 Reserved Reserved bandwidth:44K bandwidth:44K bits/sec, bits/sec, Maximum Maximum burst:3K burst:3K bytes, bytes, Peak Peak rate: rate: 44K 44K bits/sec bits/sec QoS 13 QoS provider provider for for this this flow:WFQ. flow:WFQ. Conversation Conversation number:266. number:266. Weight: Weight:13 Conversation Conversation supports 1 reservations Data Data given given reserved reserved service:9 service:9 packets packets (450 (450 bytes) bytes) Data Data given given best-effort best-effort service:0 service:0 packets packets (0 (0 bytes) bytes) Reserved Reserved traffic traffic classified classified for for 107 107 seconds seconds Long-term Long-term average average bitrate bitrate (bits/sec):33 (bits/sec):33 reserved, reserved, 0M 0M best-effort best-effort ... ... © 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-18
The show ip rsvp installed detail command shows detailed information about active conversations currently installe d in the RSVP reservation table. Detailed timing and accounting for every conversation is displayed, together with the QoS mechanism used to provide service guarantees.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-19
Monitoring and Troubleshooting RSVP Router(config)#
show ip rsvp reservation [detail]
• List RSVP reservations
Router(config)#
show ip rsvp request [detail]
• List pending RSVP requests
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-19
The show ip rsvp reservation command lists all existing RSVP reservations over an interface. The show ip rsvp request command shows all pending RSVP requests that have no fixed reservation in place.
7-20
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting RSVP with COPS Router#
show ip rsvp policy [{cops | local} [acl]]
• Lists all policies Router#show Router#show ip ip rsvp rsvp policy policy cops cops COPS/RSVP COPS/RSVP settings: settings: Generate Generate reports for all decisions Do Do not not query query PDP PDP for for error error messages messages COPS/RSVP COPS/RSVP entry. entry. ACLs: ACLs: 100 100 PDPs: 10.100.1.1 10.101.1.1 PDPs: 10.100.1.1 10.101.1.1 Current Current state: state: Connected Connected Currently Currently connected connected to to PDP PDP 10.100.1.1, 10.100.1.1, port port 00 COPS/RSVP COPS/RSVP entry. entry. ACLs: ACLs: 101 101 PDPs: PDPs: 10.102.1.1 10.102.1.1 Current Current state: state: In In reconnect reconnect loop loop wait wait Reconnect Reconnect timer timer is is 960 960 seconds seconds
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-20
The show ip rsvp policy command shows the policy settings, whether the policy is locally defined or policy decisions are offloaded to the COPS server. The output shows associations between flow specifications and associated COPS servers, which perform admission control for those flows. This command is used to verify connectivity to COPS services and the associations between the local device and a COPS server.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-21
Monitoring and Troubleshooting RSVP with COPS Router#
show cops servers
• Lists all COPS servers Router#show Router#show cops cops servers servers COPS COPS SERVER: SERVER: Address: Address: 10.100.1.1. 10.100.1.1 . Port: Port: 3288. 3288. State: 0. Keepalive: 120 sec Number Number of of clients: clients: 1. 1. Number Number of of sessions: sessions: 1. 1. COPS COPS CLIENT: CLIENT: Client Client type: type: 1. 1.
© 2001, Cisco Systems, Inc.
State: State: 0. 0.
IP QoS Signaling Mechanism-21
The show cops servers command displays the state of all configured COPS servers.
7-22
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Summary n
RSVP enables end-stations to signal QoS requirements to the network.
n
RSVP does not provide any guarantees; router QoS mechanisms do.
n
RSVP does not necessarily require an end-to-end RSVP-aware path.
n
COPS provides scalable QoS provisioning.
Lesson Review 1. What is RSVP used for? 2. Does RSVP provide QoS guarantees? 3. What QoS mechanism should be used to provide QoS guarantees to RSVP reservations? 4. What are the benefits of using COPS with RSVP?
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-23
Subnet Bandwidth Management Overview This section describes a mechanism that is used on shared media where more complex reservation is required. SBM protocol is used between RSVP devices reachable over the same subnet.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
7-24
n
Describe Subnet Bandwidth Management (SBM).
n
Configure SBM.
n
Monitor and troubleshoot RSVP with SBM.
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Subnet Bandwidth Management • RSVP manages unidirectional reservation of resources • RSVP on shared media can result in oversubscription • SBM is an add-on to RSVP on shared media to prevent oversubscription
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-26
RSVP is used to manage reservation of resources unidirectionally, between Layer3 hops. On a shared medium, many Layer-3 hops can be active between many routers on the shared segment. The shared medium is shared between all routers, therefore the routers need to keep track about all routers’ usage of the shared medium, in order to maintain a consistent picture of available bandwidth on that medium. If routers were independently reserving bandwidth over a shared medium, oversubscription would occur if each router had full access to the medium bandwidth. Subnet Bandwidth Management (SBM) is an add-on to the RSVP protocol, which provides arbitration of bandwidth allocation on a shared medium to prevent RSVPcaused oversubscription. SBM specifies a signaling method and protocol for LANbased admission control for RSVP flows. SBM allows RSVP-enabled routers and Layer 2 and Layer 3 devices to support reservation of LAN resources for RSVPenabled data flows. The SBM signaling method is similar to that of RSVP itself.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-25
Without SBM Ethernet bandwidth 10Mbps 7.5 Mbps is reservable
Reserve 6 Mbps
Mbps rve 6 e s e R 6 Mbps booked 0 7.5 Mbps free 1.5
Ethernet Reserv e 7 Mb ps
Reserve 7 Mbps 7 Mbps booked 0 7.5 Mbps 512 kbps free
• Both routers are within the 75% reservable limit • Total reserved bandwidth is 13 Mbps (above Ethernet bandwidth) • Ethernet should be treated carefully because it is impossible to achieve 100% utilization (collisions; depending on implementation)
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-27
The figure shows a possible scenario of RSVP oversubscription on a shared segment. Both right-hand routers think of the Ethernet segment as a link with a bandwidth of 10 Mbps. Based on the 75% rule, by default 7.5 Mbps of that bandwidth is reservable. The upper router reserves 6 Mbps of the reservable bandwidth, and the bottom router reserves 7 Mbps of the reservable bandwidth. Obviously, the combined reserved bandwidth exceeds the Ethernet media bandwidth and results in an unwanted oversubscription.
7-26
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
With SBM
Reserve 6 Mbps Reserve 6 Mbps
e erv Res
bps 6M
6 Mbps booked 0 7.5 Mbps free 1.5 6 Mbps booked 0 7.5 Mbps free 1.5 One of the routers on the segment is elected to be the Designated Subnet Bandwidth Manager (DSBM) The shared media is effectively transformed into a star of point-to-point links
© 2001, Cisco Systems, Inc.
Re ser ve 6
Erro r
Mb ps
Reserve 7 Mbps 7 Mbps booked 0 7.5 Mbps 512 kbps free
IP QoS Signaling Mechanism-28
SBM’s solution to the problem is to introduce a Designated Subnet Bandwidth Manager (DSBM) router, which tracks all reservations over a shared segment. The DSBM is one of the existing subnet routers, designated to be the DSBM via an election process on the subnet. When a DSBM is used, the shared medium is effectively transformed into a virtual mesh of point-to-point links. When a DSBM client sends or forwards an RSVP PATH message over an interface attached to a managed segment, it sends the PATH message to the segment’s DSBM instead of to the RSVP session destination address, as is done in conventional RSVP processing. As part of its message processing procedure, the DSBM builds and maintains a PATH state for the session and notes the previous Layer 2/Layer 3 hop from which it received the PATH message. After processing the PATH message, the DSBM forwards it toward its destination address. n
The DSBM receives the RSVP reservation request (RSVP RESV) message and processes it in a manner similar to the way RSVP itself handles reservation request processing, basing the outcome on available bandwidth. The procedure is as follows:
n
If it cannot grant the request because of lack of resources, the DSBM returns a RESVERR message to the requester.
n
If sufficient resources are available and the DSBM can grant the reservation request, it forwards the RESV message toward the PHOP(s) using the local PATH state for the session.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-27
DSBM Election • DSBM is elected based on the DSBM priority • Each DSBM candidate advertises its priority in the range from 64 to 128 • The candidate with the highest priority is elected to be the DSBM • RSVP enabled devices can participate in Subnet Bandwidth Management without being DSBM candidates
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-29
On a LAN segment configured for SBM, a DSBM is elected based on each router’s DSBM-candidate priority. All RSVP messages of participating routers are sent to the DSBM to adjudicate the reservation requests. Such a LAN segment is called a managed segment in SBM terms. Of all SBM-enabled routers on a segment, some or all routers are DSBM candidates; that is, not all routers need to be configured as DSBM candidates to perform SBM-assisted RSVP. A DSBM is chosen among the candidates based on the configured DSBM priority, which ranges from 64 to 128, the latter being the highest priority.
7-28
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Configuring DSBM Router(config-if)#
ip rsvp dsbm candidate priority
• Configures the router to bid in the election of the DSBM • Default priority is 64
Router(config)#
ip rsvp rsvp dsbm dsbm non-resv-send-limit {burst | max-unit | minunit | peak | rate} value
• The NonResvSendLimit object specifies how much traffic can be sent onto a managed segment without a valid RSVP reservation • All values are unlimited by default
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-30
The ip rsvp dsbm candidate interface command specifies this router as a DSBM candidate on the attached LAN network. A priority used in the DSBM election process is assigned, the default being the lowest priority of 64. The ip rsvp dsbm non-resv-send-limit command limits the amount of traffic, which can be sent to a managed segment without an RSVP reservation. By default, any amount of traffic can be sent to the segment. This command should be used in a network, where RSVP is predominantly used for signaling to allow some non-RSVP traffic to transit shared LAN segments.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-29
SBM Example interface interface Ethernet0/0 Ethernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 ip ip rsvp rsvp bandwidth bandwidth 7500 7500 7500 7500 ip ip rsvp rsvp dsbm dsbm candidate 100 ip ip rsvp rsvp dsbm dsbm non-resv-send-limit rate 100 ip ip rsvp rsvp dsbm dsbm non-resv-send-limit non-resv-send-limit burst burst 1000 1000 ip ip rsvp rsvp dsbm dsbm non-resv-send-limit peak 100 !!
© 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-31
The figure shows an interface configuration example, where SBM is used to signal RSVP across a shared LAN segment. The local router is configured as a DSBM candidate, and RSVP with SBM is enabled using the ip rsvp bandwidth command. In this example, non-reserved traffic is limited to a mere 100 Kbps, with one-megabyte bursts allowed. Such an example configuration could be used in a fully RSVP-enabled network, where some bandwidth needs to be provisioned for network control (routing protocols, time management, and so forth).
7-30
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting SBM Router#
show ip sbm [detail] • Lists interfaces where SBM is active • The detailed option displays detailed information about local configuration and the DSBM configuration Router#show Router#show ip ip rsvp rsvp sbm sbm Interface DSBM DSBM Interface DSBM DSBM Addr Addr DSBM Priority Priority DSBM Candidate Candidate Et0/0 10.1.1.1 100 yes Et0/0 10.1.1.1 100 yes Et0/1 10.1.2.1 100 yes Et0/1 10.1.2.1 100 yes Router#show Router#show ip ip rsvp rsvp sbm sbm detail detail Interface:Ethernet 0/0 Interface:Ethernet0/0 Local Configuration Current Local Configuration Current DSBM DSBM IP IP IP Address:10.1.1.1 Address:10.1.1.1 IP Address:10.1.1.1 Address:10.1.1.1 DSBM II Am DSBM candidate:yes candidate:yes Am DSBM:yes DSBM:yes Priority:100 Priority: 100 Priority:100 Priority:100 Non Non Non Resv Resv Send Send Limit Limit Non Resv Resv Send Send Limit Limit Rate:100 Kbytes/sec Rate:100 Rate:100 Kbytes/sec Rate:100 Kbytes/sec Kbytes/sec Burst:1000 Burst:1000 Burst:1000 Kbytes Burst:1000 Kbytes Kbytes Peak:100 Peak:100 Peak:100 Kbytes/sec Kbytes/sec Peak:100 Kbytes/sec Kbytes/sec Min Min Min Unit:unlimited Unit:unlimited Min Unit:unlimited Unit:unlimited Max Max Max Unit:unlimited Unit:unlimited Max Unit:unlimited Unit:unlimited © 2001, Cisco Systems, Inc.
My My Priority Priority 100 100 100 100
IP QoS Signaling Mechanism-32
The show ip sbm command shows per-interface SBM parameters, displaying other SBM-enabled routers on the attached segment. The show ip sbm detail command also shows the non-reserved sending limits of discovered neighbors. In this output, all routers on the segment have the same DSBM priority. In that case, the tiebreaker is a router’s IP address on that segment, and the router with the highest IP address will win the election.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-31
Summary n
SBM enables RSVP to run over shared LAN segments.
n
DSBM routers provide shared LAN adjudication of RSVP-reservations.
n
SBM can limit the amount of non-RSVP traffic sent into a network.
Lesson Review 1. What is the purpose of Subnet Bandwidth Management? 2. How do routers on a common subnet communicate reservation requests? 3. What is a DSBM? 4. How do routers elect a DSBM?
7-32
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
Summary n
RSVP enables end-stations to signal QoS requirements to the network
n
RSVP does not provide any guarantees; router QoS mechanisms do.
n
SBM enables RSVP to run over shared LAN segments.
Copyright 2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism
7-33
Review Questions and Answers Resource Reservation Protocol (RSVP) Question: What is RSVP used for? Answer: RSVP is used by applications to signal their QoS requirements to the network and to set up reservations along the application path. Question: Does RSVP provide QoS guarantees? Answer: No, RSVP is only used for signaling. Per-hop mechanisms, such as WFQ, are used to guarantee a service level to a RSVP-enabled application. Question: What QoS mechanism should be used to provide QoS guarantees to RSVP reservations? Answer: Usually, WFQ and CB-WFQ are used to provide per-hop guarantees. Question: What are the benefits of using COPS with RSVP? Answer: Using COPS-compliant policy management software enables scaling of RSVP-enabled networks by offloading part of the admission control functions to a centralized database.
Subnet Bandwidth Management
Question: What is the purpose of Subnet Bandwidth Management? Answer: The purpose of SBM is to prevent oversubscription of a shared segment by introducing an arbiter, which keeps tracks of all reservations over a shared segment.
Question: How do routers on a common subnet communicate reservation requests? Answer: Routers communicate reservation requests by forwarding all RSVP messages to the arbiter (the DSBM).
Question: What is a DSBM? Answer: The DSBM (Designated Subnet Bandwidth Manager) is an elected layer3 device on a shared segment, which keeps tracks of all reservations.
Question: How do routers elect a DSBM? Answer: Routers elect a DSBM with a priority-based election system. Router IP address is the final tiebreaker.
7-34
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
8
Modular QoS CLI Classification
Overview This chapter focuses on the classification element of the modular QoS commandline interface. It includes the following topics: n
Introduction to Modular QoS CLI
n
Classification Options
n
Network Based Application Recognition (NBAR)
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe the classification element of the Modular QoS CLI
n
Describe and configure all currently supported classification options within the MQC
n
Understand Network-based Application Recognition (NBAR)
n
Monitor and troubleshoot class maps
Introduction to Modular QoS CLI Objectives Upon completion of this lesson, you will be able to perform the following tasks:
8-2
n
Describe the MQC concepts and structure
n
Configure class maps
n
Monitor and troubleshoot class maps
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Modular QoS CLI • The Modular QoS CLI (MQC) provides a modular approach to configuration of QoS mechanisms • Classification is configured separately from the QoS service policy • MQC also provides modularity to implementation of QoS mechanisms in the Cisco IOS: – New QoS mechanisms can reuse old classification options – New QoS classification options can also be used by older QoS mechanisms © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification -5
The Quality of Service mechanisms that have been added to the Cisco IOS all had their own set of classification options. For example: n
Committed Access Rate (CAR) can classify packets by using: –
Access lists
–
QoS group
–
DSCP
–
Rate limit access list
n
Traffic Shaping (GTS) can classify packets by using access lists
n
Priority Queuing (PQ) and Custom Queuing (CQ) can classify packets by using: –
Access lists
–
Packets size
–
Fragment
–
TCP or UDP port number
The Modular Quality of Service Command Line Interface (MQC) was introduced to allow any supported classification to be used with any QoS mechanism. The separation of classification from the QoS mechanism allows new IOS versions to introduce new QoS mechanisms and reuse all available classification options. On the other hand, old QoS mechanisms can benefit from new classification options. Another important benefit of the MQC is the reusability of configuration. MQC allows the same QoS policy to be applied to multiple interfaces. CAR, for example,
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-3
required entire configurations to be copy-pasted between interfaces and modifying configurations was tiresome. The Modular QoS CLI, therefore, is a consolidation of all the QoS mechanisms that have so far only been available as standalone mechanisms. This module focuses on the classification element of the Modular QoS CLI.
8-4
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Separation of Classification
packet
Classification
Traffic Policy
Class 1?
CB-WFQ
Class 2?
CB-LLQ
Class N?
CB-Policing
© 2001, Cisco Systems, Inc.
Interface or Forwarding
IP QoS - Modular QoS CLI Classification -6
Implementing QoS by using the MQC consists of three steps: Step 1
Configuring classification by using the class-map command
Step 2
Configuring traffic policy by associa ting the traffic class with one or more QOS features using the policy-map command
Step 3
Attaching the traffic policy to inbound or outbound traffic on interfaces, subinterfaces or virtual circuits by using the service-policy command Class maps are used to create classification templates that are later used in policy maps where QoS mechanisms are bound to classes. Routers can be configured with a large number of class maps (currently limited to 256). Each traffic policy, however, may support a limited number of classes (for example: Class-based Weighted Fair Queuing and Class-based Low-latency Queuing are limited to 64 classes). The figure illustrates an implementation where traffic is classified into N classes. Each class is handled by one or more QoS mechanisms (for example, Class-based Weighted Fair Queuing, Class-based Low-latency Queuing, Class-based Policing).
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-5
Class Maps • Each class is identified using a Class Map • Each Class Map is identified by a casesensitive name • Class maps can operate in two modes – Match All – all conditions have to succeed – Match Any – at least one condition must succeed
• The default mode is Match all
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification -7
A class map is created using the class-map global configuration command. Class maps are identified by case-sensitive names. Each class map contains one or more conditions that determine if the packet belongs to the class. There are two ways of processing conditions when there is more than one condition in a class map: n
Match all—all conditions have to be met to bind a packet to the class
n
Match any—at least one condition has to be met to bind the packet to the class
The default match strategy of class maps is “Match all”.
8-6
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Classification using Class Maps
Match all conditions?
Match all
Class Map name
Yes
Match
No
Match Mode? Match any
Yes Match at least one condition?
No
© 2001, Cisco Systems, Inc.
No Match
IP QoS - Modular QoS CLI Classification -8
The figure illustrates the full process of determining if a packet belongs to a class (match) or not (no match). The process goes through the list of conditions and: n
Returns a “match” result if one of the conditions is met and the match-any strategy is used
n
Returns a “match” result if all conditions are met and the match-all strategy is used
n
Otherwise it returns “no match”
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-7
Classification Using Match All Strategy Class Map name
Yes
No More Conditions?
Match
Match Yes Condition? No
No Match
• Match-all requires all conditions to return a positive answer • If one condition is not met the class map will return a “no match” result
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-9
The figure illustrates a simplified flowchart for the match-all strategy. The processing of a match-all class map can be divided into the following steps:
8-8
Step 1
Evaluate a condition
Step 2
Return a “no match” result and stop processing the class map if the condition is not met
Step 3
Go to Step 1 if there are more conditions
Step 4
Returns a “match” result
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Classification Using Match Any Strategy Class Map name
Match
Match Yes Condition? No
More Conditions?
No
No Match
Yes
• Match-any requires at least one condition to return a positive answer • If no condition is met the class map will return a “no match” result © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-10
The figure illustrates a simplified flowchart for the match-any strategy. The processing of a match-all class map can be divided into the following steps: Step 1
Evaluate a condition
Step 2
Return a “match” result and stop processing the class map if the condition is met
Step 3
Go to Step 1 if there are more conditions
Step 4
Return a “no match” result
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-9
Classification Options The main classification options include the following: • Access list (all access lists are available) • IP Precedence value • IP DSCP value • QoS group number • MPLS experimental bits • Protocol (including NBAR)
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-11
Class maps can classify packets by using the following classification tools:
8-10
n
Access lists for any protocol can be used within the class-map configuration mode. The Modular QoS CLI can be used for other protocols, not only IP.
n
IP packets can be classified directly by specifying IP precedence values.
n
IP packets can also be classified directly by specifying IP DSCP (differentiated services code point) values. DiffServ enabled networks can have up to 64 classes if DSCP is used to mark packets.
n
A QoS group parameter can be used to classify packets in situations where up to 100 classes are needed or the QoS group parameter is used as an intermediary marker (for example, MPLS to QoS group translation on input and QoS group to class translation on output).
n
Packets can also be matched based on the value in the experimental bits of the MPLS header of labeled packets.
n
Classification can be performed by identifying a Layer-3 or Layer-4 protocol. Advanced classification is also available by using the Network-based Application Recognition (NBAR) tool where dynamic protocols are identified by inspecting higher-layer information.
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Other Classification Options The other classification options include the following: • • • • • • • •
Using another Class Map Frame Relay DE bit IEEE 802.1Q/ISL CoS/Priority values Input interface Source MAC address Destination MAC address RTP (UDP) port range Any packet
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-12
There are many other classification options: n
Another class map can used to implement template-based configurations
n
Packets can be matched based on the underlying Frame Relay DE bit
n
Packets can be matched based on the information contained in the three Class of Service bits (when using IEEE 802.1Q encapsulation) or Priority bits (when using the ISL encapsulation)
n
Packets can be classified according to the input interface
n
Packets can be matched based on their source or destination MAC addresses
n
RTP (real-time protocol) packets can be matched based on a range of UDP port numbers
n
MQC can also be used to implement a QoS mechanism for all traffic in which case classification will put all packets into one class
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-11
Configuring Class Maps router(config)#
class-map [{match-all | match-any}] name name
• Enter the class-map configuration mode • Specify the matching strategy • Match-all is the default matching strategy router(config-cmap)#
match condition
• Use at least one condition to match packets router(config-cmap)#
description description
• It is recommended to use descriptions in large and complex configuration • The description has no operational meaning © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-13
Use the class-map global configuration command to create a class map and enter the class map configuration mode. A class map is identified by a case-sensitive name; therefore, all subsequent references to the class map must use exactly the same name. At least one match command should be used within the class-map configuration mode (match none is the default). The description command is used for documenting a comment about the class-map.
8-12
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Class Maps router(config-cmap)#
rename new-name
• Complex class-maps can easily be renamed by using the rename class-map command • All references to the class map are also renamed
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-14
Large implementations may use a number of class maps and there are many references to the class maps. Renaming a class map would normally require a change to all references to the class map as well. The rename command can be used to rename class maps and all references to it.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-13
Class Map Example
class-map class-map match-any match-any match match access-group access-group match match access-group access-group class-map class-map match-all match-all match match access-group access-group match match access-group access-group
Test1 Test1 101 102 Test2 Test2 101 102
• This example simply illustrates how classmaps are configured • Class-maps on their own have no function © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-15
The example shows two class maps with two conditions:
8-14
n
Class map Test1 matches all packets that are permitted by at least one of the access lists
n
Class map Test2 matches only those packets that are permitted by both access lists
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting Class Maps router#
show class-map [class-map]
• Lists all class-maps or the selected class-map Router#show Router#show class-map class-map Class Class Map Map match-all match-all Test2 Test2 (id (id 0) 0) Match access-group access-group 101 101 Match access-group access-group 102 102 Class Class Map Map match-any match-any Test1 (id 1) Match access-group access-group 101 101 Match access-group access-group 102 102 Router# Router#
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-16
n
The show class-map command lists all class maps with their match statements
n
The show class-map command with a name of a class map displays the configuration of the selected class map
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-15
Summary The Modular QoS CLI (MQC) is used to separate the classification from the QoS service policy. A unified classification tool can be used by multiple different QoS mechanisms. The classification is configured using class maps, which are used within policy maps to apply QoS mechanisms to classes.
Review Questions Answer the following questions:
8-16
n
What are the benefits of the Modular QoS CLI?
n
Which two matching strategies do class maps support?
n
Which classification options do class maps support?
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Classification Options Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe and configure classification using access lists
n
Describe and configure classification using the IP precedence
n
Describe and configure classification using the DSCP
n
Describe and configure classification using the QoS group
n
Describe and configure classification using the MPLS experimental bits
n
Describe and configure classification based on the input interface
n
Describe and configure classification based on the source MAC address
n
Describe and configure classification based on the destination MAC address
n
Describe and configure classification based on IEEE 802.1Q/ISL CoS
n
Describe and configure classification using another class map, negation or any keyword
n
Describe and configure classification based on the Frame Relay DE bit
n
Describe and configure classification based on RTP port
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-17
Classification Using Access Lists • Access lists are the oldest classification tool that has been used with QoS mechanisms • Class Maps support all types of access lists • Class Maps are multi protocol • Class Maps can use named access lists and numbered access lists (in the range from 1 to 2699) for all protocols
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-21
Access lists were originally used for filtering of inbound or outbound packets on interfaces. They were later reused for filtering of routing updates and also for classification with early QoS tools (for example, Priority Queuing, Custom Queuing and Traffic Shaping). Access lists are still one of the most powerful classification tools. Class maps can use any type of access list (not only IP access lists). Access lists, on the other hand, also have a drawback. Compared to other classification tools they are one of the most CPU-intensive. For this reason it is not recommended that access lists for classification be used on high-speed links where they could severely impact performance of routers. Access lists are typically used on low-speed links at network edges where packets are classified and marked (for example, with IP precedence). Classification in the core is done based on the IP precedence value.
8-18
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using Access Lists Router(config-cmap)#
match access-group {number | name name name}
• Select an access list to be used for classification class-map class-map Telnet Telnet match match access-group access-group 100 !! class-map class-map IPX_Printers IPX_Printers match match access-group access-group IPX !! access-list access-list 100 100 permit permit tcp tcp any any any any eq 23 access-list access-list 100 100 permit permit tcp tcp any any eq eq 23 23 any any !! ipx ipx access-list extended IPX permit permit netbios any any !! Keep All Graphics Inside This Box © 2001, Cisco Systems, Inc.
www.cisco.com
Course acronym 2.0—Chapter#-22
Use the match access-group command to attach an access list to a class-map. The example in the figure shows how numbered or named access list can be used for classification.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-19
Configuring Classification Using IP Precedence router(config-cmap)#
match ip precedence precedence [prec [prec [prec]]]
• Select up to four IP precedence values or names • All packets marked with one of the selected IP precedence values are matched by this class map IP Precedence Value 0 1 2 3 4 5 6 7 © 2001, Cisco Systems, Inc.
IP Precedence Name routine priority immediate flash flash-override critical internet network
class-map class-map match match ip ip !! class-map class-map match match ip ip !! class-map class-map match match ip ip !! class-map class-map match match ip ip !!
VoIP precedence precedence 55 Gold precedence precedence 33 44 Silver precedence precedence 11 22 Bronze precedence precedence routine routine
IP QoS - Modular QoS CLI Classification-23
A much faster method of classification is by matching the IP precedence. Up to four IP precedence values or names can be used to classify packets based on the IP precedence field in the IP header. The figure contains a mapping between IP precedence values and names. The running configuration, however, only shows IP precedence values (not names).
8-20
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using DSCP router(config-cmap)#
match ip dscp dscp [dscp ...]
• Select up to eight DSCP values or names • All packets marked with one of the selected DSCP values are matched by this class map DSCP Value
DSCP Class Name
DSCP Value
DSCP Class Name
0 1 2 3 4 5 6 7 46
default cs1 cs2 cs3 cs4 cs5 cs6 cs7 ef
10 12 14 18 20 22 26 28 30 34 36 38
af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43
(000000) (001000) (010000) (011000) (100000) (101000) (110000) (111000) (101110)
© 2001, Cisco Systems, Inc.
(001010) (001100) (001110) (010010) (010100) (010110) (011010) (011100) (011110) (100010) (100100) (100110)
IP QoS - Modular QoS CLI Classification-24
IP packets can also be classified based on the IP DSCP field. A QoS design can be based on IP precedence marking or DSCP marking. DSCP marking can include backward compatibility with IP precedence by using the Class Selector (CS) values (most significant three bits of the DSCP value). A sample design that includes backward compatibility would use the following values to mark packets belonging to class Gold, which is guaranteed Assured Forwarding (AF) Per-hop Behavior (PHB): n
af11 marks low-drop packets
n
af12 marks medium-drop packets
n
af13 marks high-drop packets
n
cs4 marks low-drop packets (for backward compatibility with IP precedence 4)
n
cs3 marks high-drop packets (for backward compatibility with IP precedence 5)
A sample configuration on the next page shows implementation of a similar design.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-21
Configuring Classification Using DSCP class-map class-map match ip !! class-map class-map match match ip ip !! class-map class-map match match ip ip !! class-map class-map match ip !! class-map class-map match ip ip !!
Voice Voice dscp ef Gold Gold dscp dscp af11 af11 af12 af12 af13 af13 cs3 cs3 cs4 cs4 Silver Silver dscp dscp af21 af21 af22 af22 af23 af23 cs1 cs1 cs2 cs2 Bronze Bronze dscp af31 af32 af33 Best-effort Best-effort dscp dscp default default
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-25
The figure illustrates implementation of a design with five classes: n
Voice, which is identified by DSCP value ef, which looks like IP precedence value 5 in non-DSCP compliant devices.
n
Gold, which is identified by DSCP values af11, af12 and af13. The class is also identified by IP precedence values 3 and 4.
n
Silver, which is identified by DSCP values af21, af22 and af23. The class is also identified by IP precedence values 1 and 2.
n
Bronze , which is identified by DSCP values af31, af32 and af33.
n
Best Effort, which is identified by the default DSCP value that is equal to the default IP precedence value (0).
From a non-DSCP compliant device the design looks slightly different: n
Voice—IP precedence 5
n
Gold—IP precedence 3 and 4
n
Silver—IP precedence 1 and 2
n
Best Effort—IP precedence 0
A DSCP-compliant device treats packets marked by a non-DSCP compliant device according to the design. A non-DSCP compliant device does not treat packets marked by a DSCP-compliant device correctly: n
8-22
AF1 (001xx0) looks like IP precedence 1. Therefore, class Gold appears as class Silver in a non-DSCP compliant device.
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
n
AF2 (010xx0) looks like IP precedence 2. Therefore, class Silver correctly appears as class Silver in a non-DSCP compliant device.
n
AF3 (011xx0) looks like IP precedence 3. Therefore, class Bronze appears as class Gold in a non-DSCP compliant device.
n
EF (101110) looks like IP precedence 5, which is also used for voice in a nonDSCP compliant device.
As can be seen from the example it is very important to understand the impact of DSCP on non-DSCP compliant devices. A DiffServ-based QoS design should include the impact of DSCP on parts of the networks where all routers are not DSCP compliant. The example shows that a network core, if upgraded to support DSCP, can correctly handle packets classified by edge devices that have not yet been upgraded.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-23
Configuring Classification Using QoS Group router(config-cmap)#
match ip qos-group qos-group qos-group qos-group
• Select the QoS group identifying the class • Allowed values are from 0 to 99 • All packets marked with the QoS group value are matched by this class map • The QoS group is a prameter local to the router; it has to be set by some other QoS mechanism (CAR, PBR, CB-Marking, CBPolicing, QPPB) class-map class-map QoS1 QoS1 match match qos-group qos-group 1 !! class-map class-map QoS2 QoS2 match match qos-group qos-group 2 !! © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-26
A QoS group is another marker with support for a large number of classes. Up to 100 classes can be configured by using the QoS group parameter. The main drawback of QoS-group marking is that it has to be performed on every hop since this parameter is not part of any header. The QoS group is an internal parameter in the router and it is lost the moment a packet is sent. The QoS group parameter can be used in situations where one parameter can be seen on input, but not on output where another parameter has to be set. For example: n
Match MPLS experimental bits on input and set QoS group based on the value
n
Match QoS group on output and set IP DSCP based on the value
Matching on QoS group can also be used in combination with QoS Policy Propagation through BGP (QPPB) where up to 100 classes are propagated by BGP and marked by QoS group values on all BGP-enabled routers. Class maps are then used to match on QoS group values.
8-24
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using MPLS experimental bits router(config-cmap)#
match mpls experimental exp [exp ...]
• Select up to eight MPLS experimental values • Allowed values are from 0 to 7 • All MPLS labeled packets marked with the selected MPLS experimental bits are matched by this class map class-map class-map MPLS1 MPLS1 match match mpls mpls experimental experimental 33 4 ! class-map class-map MPLS2 MPLS2 match match mpls mpls experimental experimental 11 2 !
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-27
Class maps can also be used in MPLS-enabled networks where all packets are labeled. There are three experimental bits in the label header that are currently being used for IP precedence. When an IP packet is labeled, the IP precedence value is copied into MPLS experimental bits. A transparent design can be created where class maps can match on both the IP precedence value and the MPLS experimental bits: class-map match-any Voice match ip precedence 5 match mpls experimental 5 ! class-map match-any Gold match ip precedence 3 4 match mpls experimental 3 4 ! class-map match-any Silver match ip precedence 1 2 match mpls experimental 1 2 ! class-map Best-effort match ip precedence 0 match mpls experimental 0 !
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-25
Configuring Classification Using Input Interface router(config-cmap)#
match input-interface intf
• All packets received through the selected input interface are matched by this class map class-map -any Ethernets class-map match match-any match match input-interface input-interface Ethernet0/0 Ethernet0/0 match match input-interface input-interface Ethernet0/1 Ethernet0/1 !! class-map -any FastEthernets class-map match match-any FastEthernets match match input-interface input-interface FastEthernet1/0 FastEthernet1/0 match match input-interface input-interface FastEthernet1/1 FastEthernet1/1 !! class-map -any Serials class-map match match-any Serials match match input-interface input-interface Serial2/0 Serial2/0 match match input-interface input-interface Serial2/1 Serial2/1 match match input-interface input-interface Serial2/2 Serial2/2 match input-interface Serial2/3 match input-interface Serial2/3 !! © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-28
A packet can also be classified based on the input interface.
8-26
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using MAC Addresses router(config-cmap)#
match source-address mac mac-address • Classifies packets based on the source MAC address • This classification option can only be used on interfaces using MAC addresses (e.g. Ethernet, FastEthernet) router(config-cmap)#
match destination-address mac mac mac-address • Classifies packets based on the destination MAC address • This classification option can only be used on interfaces using MAC addresses (e.g. Ethernet, FastEthernet) class-map class-map RTR1_dst RTR1_dst match match destination-address destination-address mac mac 00f0.64e2.2860 00f0.64e2.2860 !! class-map class-map RTR2_src RTR2_src match source-address mac mac 00f0.64e2.3321 00f0.64e2.3321 !! © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-29
Classification can be done based on source or destination MAC addresses. This type of classification is only possible on interfaces that use MAC addresses (for example, Ethernet or FastEthernet). It is especially useful in situations where packets from a certain device have to be matched but the device does not have a static IP address (for example, DHCPderived IP address) or it has too many IP addresses.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-27
Configuring Classification Using 802.1q or ISL CoS/Priority bits router(config-cmap)#
match cos cos cos [cos [cos [cos ]]]
• Select up to four CoS/Priority values • Allowed values are 0 to 7 • This classification option can only be used on interfaces using 802.1Q or ISL encapsulation class-map class-map Strict-priority Strict-priority match match cos cos 5 !! class-map class-map High-priority High-priority match match cos cos 44 6 7 !! class-map class-map Low-priority Low-priority match match cos cos 00 11 2 3 !! © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-30
Routers can also match on the three Class of Service bits in 802.1Q header or Priority bits in the ISL header. These bits can be used in a LAN-switched environment to provide differentiated quality of service.
8-28
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using Special Options router(config-cmap)#
match not condition
• The “not” keyword inverts the condition router(config-cmap)#
match class-map class-map
• One class map can use another class map for classification • Nested class maps allow generic template class maps to be used in other class maps router(config-cmap)#
match any
• The “any” keyword can be used to match all packets
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-31
There are some additional options that give extra power to class maps: n
Any condition can be negated by inserting the keyword not
n
A class map can use another class map to match packets
n
The any keyword can be used to match all packets.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-29
Configuring Classification Using Special Options class-map class-map Well-known-services Well-known-services match match access-group access-group 100 !! Class-map Class-map Unknown-services Unknown-services match match not not class-map class-map Well-known-services !! Class-map Class-map All-services All-services match match any any !! access-list access-list 100 100 permit permit tcp tcp any any any any lt lt 1024 access-list access-list 100 100 permit permit tcp tcp any any lt lt 1024 1024 any
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-32
The example shows three class maps:
8-30
n
Class map Well-known-services uses an access list to match all the packets with the source or destination port number lower than 1024.
n
Class map Unknown-services uses the first class map but negates the result. The same could be achieved by using the same access list with a negation.
n
Class map All-services actually matches all the packets.
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring Classification Using Frame Relay DE Bit router(config-cmap)#
match fr-de
• Use this command to match all frames with the Frame Relay DE bit set class-map class-map FR_Out_of_Contract FR_Out_of_Contract match match fr-de !! class-map class-map FR_Within_Contract FR_Within_Contract match match not not fr-de fr-de !!
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-33
Class maps used on Frame Relay interfaces can classify packets based on the setting of the Discard Eligibility (DE) bit. The example illustrates how to classify packets that have the DE bit se (match fr-de) and those that do not (match not fr-de).
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-31
Configuring Classification Using a UDP Port Range router(config-cmap)#
match ip rtp starting-port port-range • Use this command to implement classification equal to IP RTP Prioritization • All UDP packets with source or destination port numbers within the specified range are matched • Range is between the starting-port (values from 2000 to 65535) and the sum of the starting-port and the port-range (values from 0 to 16383) • The command should be used in combination with Class-based Lowlatency Queuing to implement RTP Prioritization using the Modular QoS CLI class-map class-map RTP match match ip ip rtp rtp 16384 16384 16383 ! © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-34
IP RTP Prioritization was introduced to provide low-latency queuing in combination with Weighted Fair Queuing (WFQ). The match ip rtp command can be used to match packets in the same way as with IP RTP prioritization. It should also be combined with Class-based Low-latency Queuing (CB-LLQ) to generate a similar result as IP RTP Prioritization.
8-32
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Summary Class maps are used within service policies to classify packets. Class maps support the following classification options: n
Access lists
n
IP precedence
n
DSCP
n
QoS group
n
MPLS experimental bits
n
Input interface
n
Source MAC address
n
Destination MAC address
n
IEEE 802.1Q/ISL CoS or Priority bits
n
Frame Relay DE bit
n
RTP port
Review Questions Answer the following questions: n
Which classification options are available using class maps?
n
What command is used to configure classification?
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-33
Network Based Application Recognition (NBAR) Objectives Upon completion of this lesson, you will be able to perform the following tasks:
8-34
n
Describe and configure NBAR
n
Describe and configure classification of FTP and TFTP
n
Describe and configure complex classification of HTTP sessions
n
Monitor and troubleshoot class maps
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Network-based Application Recognition (NBAR) • The IntServ model uses RSVP to signal QoS requirements including application definition • The DiffServ model relies on the network to recognize applications • Recognizing simple applications is possible by matching on the static source or destination TCP/UDP port numbers • Some applications use multiple sessions and dynamic port numbers © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-38
The two IETF standards that describe guidelines and protocols used to implement quality of service in IP networks are: n
Integrated Services model
n
Differentiated Services model
The Integrated Services model uses the Resource Reservation Protocol (RSVP), which signals the network with the QoS requirements for a specific flow. Part of the request contains information that helps network devices recognize packets belonging to the flow. The Differentiated Services model, however, relies on the network to be able to recognize packets belonging to traffic classes that require the same quality of service. If there is a need to classify a certain protocol it is usually done by using an access list where packets are matched based on the source or destination TCP or UDP port numbers. A problem arises when trying to classify packets belonging to applications that use multiple sessions and dynamically negotiate TCP or UDP port numbers.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-35
8-36
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
NBAR Capabilities • NBAR was introduced to enable recognition of applications using dynamic port numbers (e.g. FTP, Exchange, SQL*net) • NBAR supports a number of applications that use static port numbers (e.g. Telnet) • NBAR also allows recognition of sessions based on higher-layer information (e.g. HTTP by URL, Host or MIME, Citrix by application)
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-39
NBAR can be used to recognize packets belonging to different types of applications: n
Static applications establish sessions to well known TCP or UDP destination port numbers. Such applications used to be classified by using access lists.
n
Dynamic applications use multiple sessions, which use dynamic TCP or UDP port numbers. Typically, there is a control session to a well-know port number and the other sessions are established to destination port numbers negotiated through the control sessions. NBAR inspects the port number exchange through the control session.
n
Some non-IP protocols can also be recognized by NBAR.
n
NBAR also has the capability to inspect some applications for other information and classify based on that information. For example, NBAR can classify HTTP sessions based on the requested URL, included MIME (Multipurpose Internet Mail Extensions) type or hostname.
The following table lists the non-TCP and non-UDP protocols supported by NBAR: Protocol
Protocol ID
Description
EGP GRE ICMP IPINIP IPSec
Network protocol IP IP IP IP IP
8 47 1 4 50, 51
EIGRP
IP
88
Exterior Gateway Protocol Generic Routing Encapsulation Internet Control Message Protocol IP in IP IP Encapsulating Security Payload/Authentication Header Enhanced Interior Gateway Routing Protocol
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-37
8-38
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
NBAR Support for Static Protocols • NBAR supports a number of applications that are recognized based on a well known destination port number • Such applications were previously matched by using extended IP access lists
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-40
Although access lists can also be used for this purpose, NBAR is easier to configure and can provide classification statistics that are not available when using access lists. The following table contains the static IP protocols supported by NBAR: Protocol BGP CU-SeeMe
Transport protocol TCP/UDP TCP/UDP
CU-SeeMe DHCP/ BOOTP
UDP UDP
DNS Finger Gopher HTTP HTTPS IMAP IRC Kerberos L2TP LDAP MS-PPTP
TCP/UDP TCP TCP/UDP TCP TCP TCP/UDP TCP/UDP TCP/UDP UDP TCP/UDP TCP
MS- SQLServer
TCP
NetBIOS NetBIOS NFS NNTP
TCP UDP TCP/UDP TCP/UDP
Copyright 2001, Cisco Systems, Inc.
TCP or UDP port 179 7648, 7649 24032 67, 68
Description Border Gateway Protocol Desktop videoconferencing
Desktop video conferencing Dynamic Host Configuration Protocol/ Bootstrap Protocol 53 Domain Name System 79 Finger user information protocol 70 Internet Gopher Protocol 80 Hypertext Transfer Protocol 443 Secured HTTP 143, 220 Internet Message Access Protocol 194 Internet Relay Chat 88, 749 Kerberos Network Authentication Service 1701 L2F/L2TP tunnel 389 Lightweight Directory Access Protocol 1723 Microsoft Point-to-Point Tunneling Protocol for VPN 1433 Microsoft SQL Server Desktop Videoconferencing 137, 139 NetBIOS over IP (MS Windows) 137, 138 NetBIOS over IP (MS Windows) 2049 Network File System 119 Network News Transfer Protocol IP QoS—Modular QoS CLI Classification
8-39
Protocol
8-40
Notes Novadigm
Transport protocol TCP/UDP TCP/UDP
NTP PCAnywhere
TCP/UDP TCP
PCAnywhere POP3 Printer RIP RSVP SFTP SHTTP SIMAP SIRC SLDAP SNNTP SMTP SNMP SOCKS SPOP3 SSH STELNET Syslog Telnet X Windows
UDP TCP/UDP TCP/UDP UDP UDP TCP TCP TCP/UDP TCP/UDP TCP/UDP TCP/UDP TCP TCP/UDP TCP TCP/UDP TCP TCP UDP TCP TCP
IP QoS—Modular QoS CLI Classification
TCP or UDP port 1352 34603465 123 5631, 65301 22, 5632 110 515 520 1698,17 990 443 585, 993 994 636 563 25 161, 162 1080 995 22 992 514 23 60006003
Description Lotus Notes Novadigm Enterprise Desktop Manager (EDM) Network Time Protocol Symantec PCAnywhere Symantec PCAnywhere Post Office Protocol Printer Routing Information Protocol Resource Reservation Protocol Secure FTP Secure HTTP Secure IMAP Secure IRC Secure LDAP Secure NNTP Simple Mail Transfer Protocol Simple Network Management Protocol Firewall security protocol Secure POP3 Secured Shell Secure Telnet System Logging Utility Telnet Protocol X11, X Windows
Copyright 2001, Cisco Systems, Inc.
NBAR Support for Dynamic Protocols • NBAR is primarily used to recognize applications that use multiple sessions and dynamic port numbers – Such applications usually start with a control session on a well-known port number – Additional ports are negotiated through the control session
• NBAR inspects the negotiation of additional ports • Most of these applications could previously not be matched by any mechanism © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-41
The following table lists the dynamic (or stateful) protocols supported by NBAR: Stateful protocol Transport protocol FTP TCP Exchange TCP HTTP TCP Netshow TCP/UDP Realaudio TCP/UDP r-commands TCP StreamWorks UDP SQL*NET TCP/UDP SunRPC TCP/UDP TFTP UDP VDOLive TCP/UDP
Description File Transfer Protocol MS-RPC for Exchange HTTP with URL, MIME, or Host classification Microsoft Netshow RealAudio Streaming Protocol rsh, rlogin, rexec Xing Technology Stream Works audio and video SQL*NET for Oracle Sun Remote Procedure Call Trivial File Transfer Protocol VDOLive Streaming Video
Use the match protocol ? command to display the list of supported protocols with the Cisco IOS version you are using.
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-41
Packet Description Language Module • An external Packet Description Language Module (PDLM) can be loaded at run time to extend the NBAR list of recognized protocols • PDLMs can also be used to enhance an existing protocol recognition capability • PDLMs allow NBAR to recognize new protocols without requiring a new IOS image or a router reload
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-42
New features are usually added to new versions of the Cisco IOS software. NBAR is the first mechanism that supports dynamic upgrades without having to change the IOS version or restart a router. Packet Description Language Modules (PDLMs) contain the rules used by NBAR to recognize an application and can be used to bring new or changed functionality to NBAR.
8-42
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring NBAR router(config-cmap)#
match protocol protocol
• Use the protocol keyword and the name of the protocol to match • Static protocols are recognized based on the wellknown destination port number • Dynamic protocols are recognized by inspecting the session
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-43
When configuring NBAR the administrator does not need to understand the way a certain protocol works. The configuration simply requires the administrator to enter the name of the protocol (static or stateful).
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-43
Configuring NBAR router(config)#
ip nbar pdlm pdlm-file pdlm-file
• Enter the location of the Packet Description Language Module file to extend the NBAR capabilities of the router • The file name is in the URL format (e.g. flash://citrix.pdlm) router(config)# ip nbar port-map protocol protocol {tcp | udp} new-port [new-port ...]
• Specify an additional port for a well-known protocol • Up to 16 additional port numbers can be specified
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-44
Use the ip nbar pdlm command to configure the routers with the new functionality brought by the PDLM file. The pdlm-file parameter should be in the URL format and can point to the flash where the IOS is stored (for example, flash://nbar.pdlm). The file can also be located on a TFTP server (for example, tftp://10.1.1.1/nbar.pdlm). Some protocols (static or stateful) can use additional TCP or UDP ports. Use the ip nbar port-map command to extend the NBAR functionality for well-known protocols to new port numbers.
8-44
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Configuring NBAR for HTTP router(config-cmap)#
match protocol http url url • Recognizes the HTTP GET packets containing the URL, and then matches all packets that are part of the HTTP GET request • Include only the portion of the URL following the address or hostname in the match statement router(config-cmap)#
match protocol http host hostname • Performs a regular expression match on the host field contents inside an HTTP GET packet and classifies all packets from that host router(config-cmap)#
match protocol protocol http http mime mime mime-type • Select the mime-type to be matched • Matches a packet containing the MIME-type and all subsequent packets until the next HTTP transaction © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-45
NBAR has enhanced classification capabilities for HTTP. It can classify packets belonging to HTTP flows based on: n
URL portion after the hostname which appears in the GET request of the HTTP session
n
Hostname specified in the GET request
n
MIME type specifying the type of object in the HTTP response
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-45
NBAR for FTP Case Study class-map FTP match protocol ftp
class-map FTP match protocol ftp
Open control session to well-known port 21 GET file; use port 1050 Open data session to negotiated port 1050 Sending file
• FTP control sessions can be recognized based on the wellknown port number 21 • FTP data sessions may be recognized by the well-known source port number 20 • Not all implementations of FTP use port 20 • NBAR recognizes FTP data sessions by inspecting the FTP control session © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-46
The figure illustrates the process of a file download using FTP. FTP sessions use the well-known TCP port number 21 to open a control session. A new session is opened to transfer a file. The client in the example tells the server to open a data session to TCP port 1050. Although the server should use the well-known source port 20 for the data session, which would simplify classification of FTP, many implementations of FTP use random source port numbers. NBAR inspects the communication between the client and the server to learn about dynamically negotiated port numbers (1050 in the example). NBAR is then able to classify all packets (control and data) as FTP packets.
8-46
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
NBAR for TFTP Case Study class-map FTP match protocol tftp
class-map FTP match protocol tftp
Send first packet to port 69, source port 1060 GET file Send packet to port 1060, source port 1035 Sending file Send packet to port 1035, source port 1060 Acknowledge Send packet to port 1060, source port 1035 Sending file
• TFTP uses UDP for transport • The first packet uses a well-known destination port number 69 and a random source port (>1023) • The receiver responds to the received source port and uses a new source port for its packets (>1023) • The session from there on uses those port numbers © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-47
TFTP is another file transfer protocol (a trivial one), which is not trivial to classify. TFTP uses UDP to transfer files. Step 1
The first TFPT packet (sent from the client to the server) uses a random source port number and the well-known destination port number 69. This is the only information that can be used to recognize TFTP.
Step 2
A router configured for NBAR recognizes port 69 but remembers the source port (1060 in the example).
Step 3
The server responds by sending a packet to the client where its source port number is also random (1035 in the example). The router can, however, recognize this as part of a TFTP session because it previously recorded the client’s source port number (now the destination port number 1060).
Step 4
All subsequent packets use this pair of port numbers (1060<->1035).
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-47
NBAR for HTTP Case Study #1 ip nbar port-map http tcp 80 8080 ! class-map HTTP match protocol http
ip nbar port-map http tcp 80 8080 ! class-map HTTP match protocol http
Open HTTP session to port 80 GET page Open HTTP session to port 8080 GET page
• HTTP is a static protocol using a well-known port number 80 • Some web servers are using HTTP on other ports • Use the “ip nbar port-map” command to inform the router that other ports are also used for HTTP © 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-48
The example illustrates a simple classification of all HTTP sessions. HTTP sessions using the default well-known port number 80 are simple to classify (it is a static protocol). HTTP is often used on other port numbers. The example shows the usage of the ip nbar port-map command to also enable HTTP recognition on port 8080.
8-48
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
NBAR for HTTP Case Study #2 ip nbar port-map http tcp 80 8080 ! class-map HTTP match protocol http url *xxx.(jpg|gif)
Open HTTP session to port 80 GET /images/xxx.gif Open HTTP session to port 8080 GET /images/xxx.jpg
• The class map matches all HTTP requests that contain either xxx.gif or xxx.jpg • It does so on both ports: 80 and 8080
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-49
Classification of HTTP by URL, host, or Multipurpose Internet Mail Extension (MIME) type, is an example of subport classification. Step 1
NBAR classifies HTTP traffic by text within the URL or host fields of a GET request using regular expression matching. NBAR uses the UNIX filename specification as the basis for the URL or host specification format.
Step 2
The NBAR engine converts the specified match string into a regular expression.
Step 3
NBAR recognizes HTTP GET packet(s) containing the URL and classifies all packets that are sent to the source of the HTTP GET request. The example shows a class-map that classifies only those HTTP sessions that request files with filenames ending in xxx.gif or xxx.jpg. The allowed regular expressions include the following special characters: Special character * ? | (|) []
Copyright 2001, Cisco Systems, Inc.
Description Match any zero or more characters in this position. Match any one character in this position. Match one of a choice of characters. Match one of a choice of characters in a range. For example, foo.(gif | jpg) matches either foo.gif or foo.jpg. Match any character in the range specified, or one of the special characters. For example, [0-9] is all of the digits. [*] is the "*" and [[] is the "[" character.
IP QoS—Modular QoS CLI Classification
8-49
NBAR for HTTP Case Study #3 ip nbar port-map http tcp 80 8080 ! class-map HTTP match protocol http mime *jpeg
Open HTTP session to port 80 GET /html/pictures.html Open HTTP session to port 8080 GET /html/pictures.html
• The class map matches all HTTP requests containing MIME type that contains jpeg (e.g. image/jpeg) • It does so on both ports: 80 and 8080
© 2001, Cisco Systems, Inc.
IP QoS - Modular QoS CLI Classification-50
This example shows how HTTP sessions can also be filtered based on the MIME type.
8-50
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Summary Network-based Application Recognition (NBAR) is a tool used primarily to classify packets belonging to applications using dynamically assigned TCP or UDP port numbers. Additionally, NBAR can classify packets (or flows) on application layer information (for example, HTTP can be classified based on URL, hostname or MIME contents).
Review Questions Answer the following questions: n
What is NBAR used for?
n
What types of applications can NBAR recognize?
n
How can support for recognizing new applications be included into existing IOS versions?
n
What additional classification options are available for HTTP?
n
Which special characters are available with regular expressions for matching HTTP flows?
Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-51
Summary After completing this module, you should be able to perform the following tasks:
8-52
n
Describe the classification part of the Modular QoS CLI
n
Describe and configure all currently supported classification options within the MQC
n
Understand Network-based Application Recognition (NBAR)
n
Monitor and troubleshoot class maps
IP QoS—Modular QoS CLI Classification
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Introduction to Modular QoS CLI Question: What are the benefits of the Modular QoS CLI? Answer: Template-based configuration; new classification options can be used with any MQC-based QoS mechanism. Question: Which two matching strategies do class maps support? Answer: When using multiple match commands in one class map a logical “or” is configured using the match-any keyword and a logical “and” is configured using the match-all keyword. Question: Which classification options do class maps support? Answer: Class maps support classification using: access lists, IP Precedence value, IP DSCP value, QoS group number, MPLS experimental bits, protocol (including NBAR) etc.
Classification Options Question: Which classification options are available using class maps? Answer: Class maps support classification using: access lists, IP Precedence value, IP DSCP value, QoS group number, MPLS experimental bits, protocol (including NBAR) etc. Question: What command is used to configure classification? Answer: The match command is used in the class-map configuration mode to specify the classification parameters.
Network Based Application Recognition (NBAR) Question: What is NBAR used for? Answer: NBAR is primarily used to recognize sessions that dynamically negotiate TCP or UDP port numbers. Question: What types of applications can NBAR recognize? Answer: NBAR can recognize static protocols, dynamic protocols and sessions based on higher-layer information. Question: How can support for recognizing new applications be included into existing IOS versions? Answer: By using Packet Language Description Modules (PDLMs) to include new or changed functionality into existing Cisco IOS. Copyright 2001, Cisco Systems, Inc.
IP QoS—Modular QoS CLI Classification
8-53
Question: What additional classification options are available for HTTP? Answer: Classification based on URL, hostname or MIME type. Question: Which special characters are available with regular expressions for matching HTTP flows?
Answer: The special characters include:
8-54
IP QoS—Modular QoS CLI Classification
–
“*” to match any sequence of characters
–
“?” to match any single character
–
“|” to match the expression on the left or the expression on the right
–
“[]” to match a character from the specified range
–
“()” to group a number of characters
Copyright 2001, Cisco Systems, Inc.
9
Modular QoS CLI Service Policy
Overview This module describes the policy part of the Modular QoS CLI (MQC). The module describes all the mechanisms that are currently supported by the MQC. As well, the module describes the class-based approach to the marking, shaping, policing, dropping and/or scheduling of IP packets using the modular QoS CLI.
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe the policy part of the Modular QoS CLI
n
Configure packet marking with modular CLI
n
Configure policing and shaping with modular CLI
n
Configure class-based WFQ with modular CLI
n
Configure congestion avoidance mechanisms (WRED) with modular CLI
n
Configure low-latency queuing
n
Monitor and troubleshoot policy maps
Service Policy Overview This lesson introduces the part of the MQC that is used to enable QoS mechanisms for classified traffic.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
9-2
n
Describe and configure policy maps.
n
List all the QoS mechanisms currently available in the MQC.
n
Monitor and troubleshoot policy maps.
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Service Policy • One aspect of modularity of the MQC is the configuration part • MQC is split into two modules: – Configuration of classification – Configuration of service policies
• Classification is configured by using class maps • Service Policy is configured by using policy maps
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-5
The Cisco IOS Modular QoS CLI (MQC) is the new, unified method of QoS mechanism configuration in Cisco IOS. MQC separates classification and QoS mechanism configuration by separating the configuration tasks into: n
Configuration of class-maps, which define the classification of traffic
n
Configuration of service policies, which define how QoS mechanisms are applied to traffic classes
This creates a flexible environment for the modular configuration of many QoS features, and significantly reduces overhead and the possibility of errors because configuration information is not unnecessarily duplicated.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-3
Modular QoS CLI Classification
Service Policy
Class 1?
CB-WFQ
Class 2?
CB-LLQ
Service Policy implements per-hop behaviors (PHBs) for all traffic classes Supported mechanisms: • CB-WFQ • CB-LLQ • CB-Policing
Class N?
CB-Policing
• CB-Shaping • CB-Marking
• Up to 256 classes can be used within one service policy © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-6
The service policy is used to configure QoS mechanisms, which may be applied to classes. The QoS mechanisms implement local per-hop behaviors (PHBs) for attached traffic classes. The QoS system, which implements PHB configured via the MQC, is the Class-Based Weighted Fair Queuing system, which integrates many QoS features in a single system, configured via a common (MQC) interface. A service policy can have up to 256 classes used within it and attached to an interface. Class-based Weighted Fair Queuing and Class-based Low-latency Queuing are an exception – only 64 classes can be used with one service policy.
9-4
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
PHB Mechanisms • MQC Supports the following QoS mechanisms: – Class-based Weighted Fair Queuing (CB-WFQ) to guarantee bandwidth – Class-based Low-latency Queuing (CB-LLQ) to guarantee bandwidth and low-latency – Class-based Policing (CB-Policing) to limit traffic rate by dropping excess traffic – Class-based Shaping (CB-Shaping) to limit traffic rate by delaying excess traffic – Class-based Marking (CB-Marking) to mark packets © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy -7
The MQC configures the CB-WFQ system, which in turn implements the following QoS functions: n
Class-based Weighted Fair Queuing, which is used to guarantee bandwidth within the CB-WFQ system
n
Class-based Low-latency Queuing, which is used to guarantee bandwidth and provide low latency to time-critical traffic
n
Class-based Policing, which performs rate limiting by traffic policing
n
Class-based Shaping, which performs rate limiting by traffic shaping
n
Class-based Marking, which performs packet and frame marking
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-5
Configuring Policy Maps Router(config)#
policy-map name • Enter policy-map configuration mode • Policy maps are identified by a case-sensitive name Router(config-pmap)#
class class-map • Enter the per-class policy configuration mode by using the name of a previously configured class-map • Use the name “class-default” to configure the policy for the default class Router(config-pmap)#
class class-map condition • Optionally you can define a new class-map by entering the condition after the name of the new class map • Class map will use the match-any strategy © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy -8
Service policies are configured using the policy-map command. Up to 256 classes can be used within one policy-map using the class command with the name of a preconfigured class-map. A non-existent class can also be used within the policy-map configuration mode if the match condition is specified after the name of the class. The running configuration will reflect such a configuration by using the match any strategy and inserting a full class-map configuration. The following table shows starting and resulting configuration modes for the classmap, policy-map and class commands: Starting configuration mode
Command
Configuration mode
Router(config)#
class-map
Router(config-cmap)#
Router(config)#
policy-map
Router(config-pmap)#
Router(config-pmap)#
class
Router(config-pmap-c)#
All traffic that is not classified by any of the class-maps used within the policy map is part of the default class class-default. This class has no QoS guarantees by default. The default cla ss, when used on output, can use one FIFO queue of flow-based WFQ. The default class is part of every policy-map even if not configured.
9-6
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring Policy Maps Router(config-pmap)#
description description • It is recommended to use descriptions in large and complex configurations • The description has no operational meaning Router(config-pmap)#
rename policy-map • Complex policy-maps can be renamed by using the rename policy-map command • All references to the policy map are also renamed Router(config-pmap-c)#
IP QoS Modular QoS CLI Service Policy -9
Policy maps, like class maps, should use descriptions in large QoS implementations where a large number of different policy maps are used. Renaming a policy map would normally require the renaming of all the references to the policy map. Using the rename command simplifies the renaming process by automatically renaming all references. The remainder of this module focuses on the various QoS mechanisms that are configured per-class within the policy-map configuration mode (config-pmap-c).
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-7
Configuring Policy Maps Router(config-if)#
service-policy {input | output} policy-map
• Attaches the specified service policy map to the input or output interface • The interface should be in the default queuing mode prior to using this command if it is used on output class-map class-map HTTP HTTP match match protocol protocol http !! policy-map policy-map PM PM class class HTTP HTTP bandwidth bandwidth 2000 2000 class class-default bandwidth bandwidth 6000 6000 !! © 2001, Cisco Systems, Inc.
interface interface Serial0/0 Serial0/0 service-policy service-policy output output PM PM !!
IP QoS Modular QoS CLI Service Policy-10
The last configuration step when configuring QoS mechanisms using the Modular QoS CLI, is to attach a policy map to the inbound or outbound packets, using the service-policy command. The router immediately verifies the correctness of parameters used in the policy map. If there is a mistake in the policy-map configuration, the router will display a message explaining what is wrong with the policy map. The sample configuration shows how a policy map is used to separate HTTP from other traffic. HTTP is guaranteed 2Mbps. All other traffic belongs to the default class and is guaranteed 6Mbps.
9-8
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Attaching Policy Maps to ATM PVCs Router(config-subif)#
service-policy {input | output} policy-map
• Service policies can be attached to an ATM (sub)interface • Using service policies on the main interface and subinterfaces at the same time is not supported in the distributed (VIP-based) version Router(config-if-atm-vc)#
service-policy {input | output} policy-map
• Service policies can also be attached to an ATM PVC interface interface atm atm 5/0/0.1 5/0/0.1 point-to-point point-to-point service-policy service-policy output output PM1 PM1 !! interface atm 5/0/0.2 point-to-point interface atm 5/0/0.2 point-to-point pvc pvc 1/40 1/40 service-policy service-policy output output PM2 PM2 !! © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-11
Service policies can be applied to interfaces, subinterfaces or individual ATM virtual circuits. Refer to the “IP QoS – IP over ATM” module for a more detailed description of MQC usage on ATM interfaces.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-9
Attaching Policy Maps to Frame Relay Interfaces Router(config-subif)#
service-policy {input | output} policy-map
• Service policy can be attached to an interface and/or to a subinterface • Service policy attached to a subinterface can not include CB-WFQ or CB-LLQ except in the distributed (VIP-based) version • Using service policies on the main interface and subinterfaces at the same time is not supported in the distributed (VIP-based) version
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-12
Service policies can also be used on Frame Relay interfaces or subinterfaces.
9-10
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Attaching Policy Maps to Frame Relay PVCs Router(config-map-class)#
service-policy {input | output} policy-map • Service policy can be attached to a Frame Relay map class class-map class-map Voice Voice match match protocol protocol vofr vofr !! policy-map policy-map LLQ class class Voice Voice priority priority 100 !! interface interface Serial0/0 Serial0/0 encapsulation -relay encapsulation frame frame-relay !! interface interface Serial0/0.1 Serial0/0.1 point-to-point point-to-point frame-relay frame-relay class class Voice !! map-class map-class frame-relay frame-relay Voice Voice service-policy service-policy output LLQ !! © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-13
A Frame Relay map class is needed when attaching a policy map to an individual virtual circuit. The sample configuration illustrates how per-VC Low-latency queuing can be configured on Frame Relay virtual circuits.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-11
Policy Map Example class-map class-map match-all match-all Test1 Test1 match protocol protocol http match match access-group access-group 100 100 class-map class-map match-any match-any Test2 Test2 match match protocol protocol http match match access-group access-group 101 101 !! policy-map policy-map Test class Test1 bandwidth 100 100 class Test2 bandwidth 200 200 class Test3 access-group 100 bandwidth 300 300 !! access-list access-list 100 permit permit tcp tcp any any host host 10.1.1.1 10.1.1.1 access-list access-list 101 permit permit tcp tcp any any host host 10.1.1.2 10.1.1.2
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-14
The example shows the configuration of a policy map using three classes. The first two classes were separately configured using the class-map command. The third class was configured “on the fly” by specifying the match condition after the name of the class. Class Test1 has two match conditions evaluated in the match-all strategy. Classes Test2 and Test3 use the match-any strategy.
9-12
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting Policy Maps Router#
show policy-map [policy-map] Router#show Router#show policy-map policy-map Policy Map Test Class Test1 Test1 Weighted Fair Queueing Queueing Bandwidth Bandwidth 100 100 (kbps) (kbps) Class Test2 Test2 Weighted Fair Queueing Queueing Bandwidth Bandwidth 200 200 (kbps) (kbps) Class Test3 Test3 Weighted Fair Queueing Queueing Bandwidth Bandwidth 300 300 (kbps) (kbps)
© 2001, Cisco Systems, Inc.
Max Max Threshold Threshold 64 64 (packets) (packets)
Max Max Threshold Threshold 64 64 (packets) (packets)
Max Max Threshold Threshold 64 64 (packets) (packets)
IP QoS Modular QoS CLI Service Policy-15
The show policy-map command can be used to verify the configuration of a policy map.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-13
Monitoring and Troubleshooting Policy Maps Router#
show policy-map interface [intf] {input | output} Router #show policy -map interface Router#show policy-map interface FastEthernet0/0 FastEthernet0/0 output output FastEthernet0/0 FastEthernet0/0 Service-policy Service-policy output: output: Test Test (1101) (1101) Class-map: Class-map: Test1 Test1 (match-all) (match-all) (1103/3) (1103/3) 00 packets, packets, 00 bytes bytes 55 minute offered rate 0 bps, minute offered rate bps, drop rate 0 bps Match: Match: access-group access-group 101 101 (1107) (1107) Match: Match: access-group access-group 102 102 (1111) (1111) Match: Match: protocol protocol http http (1115) (1115) Weighted Weighted Fair Fair Queueing Queueing Output Output Queue: Queue: Conversation 265 Bandwidth 100 Bandwidth 100 (kbps) (kbps) Max Max Threshold Threshold 64 64 (packets) (packets) (pkts (pkts matched/bytes matched/bytes matched) matched) 0/0 0/0 (depth/total (depth/total drops/no-buffer drops/no-buffer drops) drops) 0/0/0 0/0/0 ... ... Class-map: Class-map: class-default class -default (match-any) (match-any) (1143/0) (1143/0) 25 25 packets, packets, 19310 19310 bytes bytes 55 minute minute offered offered rate rate 1000 1000 bps, bps, drop drop rate rate 00 bps bps Match: Match: any any (1147) (1147) © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-16
The show policy-map command also displays live information if the interface keyword is used. The sample output shows the parameters and statistics of the policy map attached to outbound traffic on interface FastEthernet0/0.
9-14
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Summary All QoS mechanisms using the Modular QoS CLI (MQC) are configured using the following three commands: n
Class-map global configuration command to configure classification
n
Policy-map global configuration command to create a service policy
n
Class command in the policy-map configuration mode to attach QoS mechanisms to a class
The MQC supports the following QoS mechanisms: n
Class-based Weighted Fair Queuing
n
Class-based Low-latency Queuing
n
Class-based Weighted Random Early Detection
n
Class-based Policing
n
Class-based Shaping
n
Class-based Marking
Lesson Review 1. What are the benefits of using MQC? 2. How many classes can be used for one service policy?
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-15
Class-based Weighted Fair Queuing Overview This lesson describes the enhanced queuing mechanism in Cisco IOS using the Modular QoS CLI.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
9-16
n
Describe Class-based Weighted Fair Queuing (CB-WFQ)
n
Configure CB-WFQ
n
Monitor and troubleshoot CB-WFQ
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Weighted Fair Queuing • Class-based Weighted Fair Queuing (CB-WFQ) is a mechanism that is used to guaranetee bandwidth to classes • CB-WFQ extends the standard WFQ functionality to provide support for user-defined traffic classes – Classes are based on user-defined match criteria – Packets satisfying the match criteria for a class constitute the traffic for that class
• A queue is reserved for each class, and traffic belonging to a class is directed to that class's queue
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-21
CBWFQ extends the standard WFQ functionality to provide support for userdefined traffic classes. For CBWFQ, the user defines the traffic classes based on match criteria including protocols, access control lists (ACLs), and input interfaces. Packets satisfying the match criteria for a class constitute the traffic for that class. A queue is reserved for each class, and traffic belonging to a class is directed to that class's queue. Once a class has been defined according to its match criteria, you can assign it characteristics. To characterize a class, you assign it bandwidth, weight, and maximum packet limit. The bandwidth assigned to a class is the minimum bandwidth delivered to the class during congestion. To characterize a class, you also specify the queue limit for that class, which is the maximum number of packets allowed to accumulate in the class's queue. Packets belonging to a class are subject to the bandwidth and queue limits that characterize the class. After a queue has reached its configured queue limit, enqueuing of additional packets to the class causes tail drop or packet drop to take effect, depending on how the class policy is configured.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-17
CB-WFQ Forwarded Packets CB-WFQ
Class 1?
Tail-drop
Queue 1
Class 2?
Tail-drop
Queue 2
Hardware Queuing System CB-WFQ Scheduler
Class-default?
Tail-drop
Hardware Q
Interface
Default Queue
• Up to 64 classes (class maps) and one default class © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-22
CB-WFQ uses up to 64 class maps to classify traffic into their corresponding FIFO queues. Tail-drop is the default dropping scheme of CB-WFQ although it can be combined with WRED. The CB-WFQ scheduler is used to guarantee bandwidth based on the configured weights.
9-18
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ Classification • Classification uses class-maps • Availability of certain classification options depends on the Cisco IOS version • Some classification options depend on type of interface and encapsulation where service policy is used • For example: – Matching on Frame Relay DE bits can only be used on interfaces with Frame Relay encapsulation – Matching on MPLS experimental bits has no effect if MPLS is not enabled – Matching on ISL Priority bits has no effect if ISL is not used
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-23
Any classification option can be used depending on the availability in the Cisco IOS version and the support on the selected interface and encapsulation.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-19
CB-WFQ Insertion Policy • Each queue has a maximum number of packets that it can hold (queue size) • The default maximum queue size is 64 • After a packet is classified to one of the queues, the router will enqueue the packet if the queue limit has not been reached (taildrop within each class) • WRED can be used in combination with CBWFQ to prevent congestion of the class
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-24
CB-WFQ reserves 64 FIFO queues in the WFQ system. The default queue limit is 64 (tail-drop) and can be configured with WRED (random drop).
9-20
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ Scheduling • CB-WFQ guarantees bandwidth according to weights assigned to traffic classes • Weights can be defined by specifying: – Bandwidth (in kbps) – Percentage of bandwidth (percentage of configured interface bandwidth) – Percentage of available bandwidth
• One service policy can not have mixed types of weights • The “show interface” command can be used to display the available bandwidth © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-25
The configuration of bandwidth guarantees can be done using one of the following commands: n
The bandwidth command allocates a fixed amount of bandwidth by specifying the amount in kilobits per second (kbps). The reserved bandwidth is subtracted from the available bandwidth of the interface where the service policy is used. The allocated bandwidth must also be within the default or configured reservable limit (75% by default).
n
The bandwidth percent command can be used to allocate a percentage of the default or configured bandwidth of an interface. The default bandwidth usually equals the maximum speed of an interface. Sometimes it actually reflects the real speed of an interface (for example: Ethernet or FastEthernet). The default value can be replaced by using the bandwidth interface command. It is recommended that the bandwidth reflect the real speed of the link. The allocated bandwidth is subtracted from the available bandwidth of the interface where the service policy is used.
n
The bandwidth remaining percent command can be used to allocate a portion of the available bandwidth. The allocated bandwidth is not subtracted from the available bandwidth of the interface where the service policy is used.
A single service policy cannot mix different bandwidth commands.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-21
Available Bandwidth • Available bandwidth is calculated according to the following formula: Configured using the interface “bandwidth” command
Configured using the interface max-reserved -bandwidth command 75% is the default value
BWavail = BW * MaxReservable – SUM(all fixed guarantees)
Sum of all fixed guarantees using CB-WFQ, CB-LLQ, IP RTP Prioritization
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-26
The available bandwidth displayed by the show interface command is calculated by subtracting all fixed bandwidth reservations from 75% of the default or configured bandwidth of an interface.
9-22
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Available Bandwidth Example 1 • Ethernet interface uses default bandwidth 10000 (kbps) and WFQ BWavail = BW * MaxReservable – SUM(all fixed guarantees) BWavail = 10000 kbps * 75% – 0 kbps = 7500 kbps Router#show Router#show interface interface Ethernet Ethernet 0/0 0/0 Ethernet0/0 Ethernet0/0 is is up, up, line line protocol protocol is is up up Hardware is AmdP2, address is 00b0.64e2.2860 ( (bia Hardware is bia 00b0.64e2.2860) 00b0.64e2.2860) Internet address is 192.168.20.1 255.255.255.0 Internet MTU MTU 1500 1500 bytes, bytes, BW BW 10000 10000 Kbit, Kbit, DLY DLY 1000 1000 usec, usec, reliability reliability 255/255, 255/255, txload txload 1/255, 1/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation ARPA, ARPA, loopback loopback not not set set Keepalive set (10 sec) Keepalive ARP ARP type: type: ARPA, ARPA, ARP ARP Timeout Timeout 04:00:00 04:00:00 Last Last input input 00:00:04, 00:00:04, output output 00:00:08, 00:00:08, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input rops: 0 Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total Total output output ddrops: 0 Queueing Queueing strategy: strategy: weighted weighted fair fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations Conversations 0/0/256 0/0/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 7500 kilobits/sec ... ... © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-27
The figure illustrates a situation where there are no fixed guarantees on the interface. The show interface command confirms that there are 7.5 Mbps of bandwidth available (only 75% of 10Mbps is reservable by default).
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-23
Available Bandwidth Example 2 • Ethernet interface uses default bandwidth 10000 (kbps) with WFQ • Maximum Reservable bandwidth is set to 50% • IP RTP Prioritization is used to guarantee 1 Mbps to VoIP BWavail = BW * MaxReservable – SUM(all fixed guarantees) BWavail = 10000 kbps * 50% – 1000 kbps = 4000 kbps
interface Ethernet0/0 ip address 192.168.20.1 255.255.255.0 half-duplex max-reserved-bandwidth 50 fair-queue ip rtp priority 16384 16383 1000
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-28
After enabling IP RTP Prioritization with 1Mbps of guaranteed bandwidth and reducing the reservable limit to 50% there are only 4Mbps left. The IP RTP Priority feature provides a strict priority queueing scheme that allows delay-sensitive data such as voic e to be dequeued and sent before packets in other queues are dequeued. This feature can be used with either WFQ or CBWFQ on the same outgoing interface. In either case, traffic matching the range of UDP ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; packets in the priority queue are always serviced first.
9-24
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Available Bandwidth Example 2 Router#show Router#show interface interface Ethernet0/0 Ethernet0/0 Ethernet0/0 Ethernet0/0 is up, line line protocol protocol is up up Hardware Hardware is is AmdP2, AmdP2, address address is is 00b0.64e2.2860 00b0.64e2.2860 (bia (bia 00b0.64e2.2860) 00b0.64e2.2860) Internet Internet address address is is 192.168.20.1 192.168.20.1 255.255.255.0 255.255.255.0 MTU MTU 1500 1500 bytes, bytes, BW BW 10000 10000 Kbit, Kbit, DLY DLY 1000 1000 usec, usec, reliability reliability 255/255, 255/255, txload txload 1/255, 1/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation ARPA, ARPA, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) ARP ARP type: type: ARPA, ARPA, ARP ARP Timeout Timeout 04:00:00 04:00:00 Last input 00:00:04, Last input 00:00:04, output output 00:00:06, 00:00:06, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total output drops: d rops: 0 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 0/1000/64/0 0/1000/64/0 (size/max (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 0/1/256 0/1/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 4000 4000 kilobits/sec kilobits/sec ... ...
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-29
The show interface command confirms the calculation of available bandwidth for Example 2.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-25
Configuring CB-WFQ Router(config-pmap-c)#
bandwidth bandwidth
• Allocate a fixed amount of bandwidth to a class • Set the value in kbps Router(config-pmap-c)#
bandwidth percent percent
• Allocate a percentage of bandwidth to a class • The configured (or default) interface bandwidth is used to calculate the guaranteed bandwidth Router(config-pmap-c)#
bandwidth remaining remaining percent percent percent
• Allocate a percentage of available bandwidth to a class
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-30
Bandwidth guarantee is configured in the cla ss policy-map configuration mode (config-pmap-c). All classes belonging to one policy map should use the same type of bandwidth guarantee (fixed in kbps, in percentage of interface bandwidth, in percentage of available bandwidth).
9-26
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring CB-WFQ Router(config-pmap-c)#
queue-limit queue-limit
• Set the maximum number of packets this queue can hold • The default maximum is 64 • Sets the discard threshold in the “class-default” if flow-based WFQ is used
Router(config-pmap-c)#
fair-queue [dynamic-queues]
• The “class-default” class can be configured to use flow-based WFQ • WFQ can be configured with 16 to 4096 dynamic queues
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-31
The default queue limit of 64 packets can be changed using the queue-limit command. It is recommended not to change the default value. The default class can be selected by specifying the class-default name of the class. The default class supports two types of queuing: one FIFO queue (Default) or a Flow-based WFQ system. Both types can be combined with WRED. FIFO queue can also get a bandwidth guarantee. The following example shows the configuration of FIFO queuing within the default class. The default class is also guaranteed 1 Mbps of bandwidth and the maximum queue size is limited to 40 packets. policy-map A class A bandwidth 1000 class class-default bandwidth 1000 queue-limit 40 This next example shows the configuration of WFQ queuing within the default class. The number of dynamic queues is set to 1024 and the discard threshold is set to 50. policy-map A class A bandwidth 1000 class class-default fair-queue 1024 queue-limit 50
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-27
9-28
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ Example 1 policy-map policy-map Policy1 Policy1 class class Class1 Class1 bandwidth 2000 2000 class class Class2 Class2 bandwidth 2000 2000 ! interface FastEthernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 duplex duplex auto speed speed 10 10 max-reserved-bandwidth max-reserved-bandwidth 80 80 service-policy service-policy output Policy1 ip ip rtp rtp priority priority 16384 16384 16383 16383 1000 1000 ! BWavail = 10000 kbps * 80% - (2000+2000+1000) kbps = 3000 kbps © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-32
The sample configuration shows how CB-WFQ is used to guarantee 2Mbps to each of the two classes. The FastEthernet interface (in Ethernet mode) allows up to 80% of the interface bandwidth (10Mbps) to be reserved. IP RTP Prioritization together with the two classes consumes 5Mbps. The available bandwidth, therefore, is 3Mbps.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-29
CB-WFQ Example 2 policy-map policy-map Policy1 Policy1 class class Class1 Class1 bandwidth percent percent 20 20 class class Class2 Class2 bandwidth percent percent 20 20 ! interface FastEthernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 duplex duplex auto speed speed 10 10 max-reserved-bandwidth max-reserved-bandwidth 80 80 service-policy service-policy output Policy1 ip ip rtp rtp priority priority 16384 16384 16383 16383 1000 1000 ! BWavail = 10000 kbps * 80% - (10000*(20%+20%)+1000) kbps = 3000 kbps © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-33
This implementation is equal to CB-WFQ Example 1. The main benefit of using the percentage keyword is that this policy map can easily be used on another interface with a different link speed (bandwidth).
9-30
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ Examples 1 and 2 Router#show Router#show interface interface fastethernet fastethernet 0/0 0/0 FastEthernet0/0 FastEthernet0/0 is up, line line protocol protocol is is up up Hardware Hardware is is AmdFE, AmdFE, address address is is 0030.8546.aa00 0030.8546.aa00 (bia (bia 0030.8546.aa00) 0030.8546.aa00) Internet Internet address address is is 10.1.1.1 10.1.1.1/24 /24 MTU MTU 1500 1500 bytes, BW BW 10000 10000 Kbit, Kbit, DLY DLY 1000 1000 usec, usec, reliability reliability 255/255, 255/255, txload txload 1/255, 1/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation ARPA, ARPA, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) Half-duplex, Half-duplex, 10Mb/s, 10Mb/s, 100BaseTX/FX 100BaseTX/FX ARP type: ARPA, ARP ARP type: ARPA, ARP Timeout Timeout 04:00:00 04:00:00 Last Last input input 00:00:00, 00:00:00, output output 00:00:09, 00:00:09, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total output drops: d rops: 0 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 0/1000/64/0 0/1000/64/0 (size/max (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 0/1/256 0/1/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 2/2 2/2 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 3000 3000 kilobits/sec kilobits/sec ... ...
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-34
The show interface command confirms the calc ulation of available bandwidth on the previous CB-WFQ examples.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-31
CB-WFQ Example 3 policy-map policy-map Policy1 Policy1 class class Class1 Class1 bandwidth remaining remaining percent 20 20 class class Class2 Class2 bandwidth remaining remaining percent 20 20 ! interface FastEthernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 duplex duplex auto speed speed 10 10 max-reserved-bandwidth max-reserved-bandwidth 80 80 service-policy service-policy output Policy1 ip ip rtp rtp priority priority 16384 16384 16383 16383 1000 1000 ! BWavail = 10000 kbps * 80% - 1000 kbps = 7000 kbps © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-35
Example 3 shows how the available bandwidth can be distributed among the classes configured with the bandwidth remaining percent command. The reservation does not affect the calculation of available bandwidth (it is not a fixed guarantee).
The bandwidth remaining percent command allows you to allocate bandwidth as a relative percentage of the total bandwidth available on the interface. This command allows you to specify the relative percentage of the bandwidth to be allocated to the classes of traffic. In this example, 20 percent of the available bandwidth is allocated to Class1 and 20 percent to Class2. Essentially, you are specifying the ratio of the bandwidth to be allocated to the traffic class. The sum of the numbers used to indicate this ratio cannot exceed 100 percent. This way, you need not know the total amount of bandwidth available, just the relative percentage you want to allocate for each traffic class. Each traffic class gets a minimum bandwidth as a relative percentage of the remaining bandwidth. The remaining bandwidth is the bandwidth available after the priority queue, if present, is given its required bandwidth, and after any Resource Reservation Protocol (RSVP) flows are given their requested bandwidth.
9-32
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ Example 3 Router#show Router#show interface interface fastethernet fastethernet 0/0 0/0 FastEthernet0/0 FastEthernet0/0 is up, line line protocol protocol is is up up Hardware Hardware is is AmdFE, AmdFE, address address is is 0030.8546.aa00 0030.8546.aa00 (bia (bia 0030.8546.aa00) 0030.8546.aa00) Internet Internet address address is is 10.1.1.1 10.1.1.1/24 /24 MTU MTU 1500 1500 bytes, bytes, BW BW 10000 10000 Kbit, Kbit, DLY DLY 1000 1000 usec, usec, reliability reliability 255/255, 255/255, txload txload 1/255, 1/255, rxload rxload 1/255 1/255 Encapsulation Encapsulation ARPA, ARPA, loopback loopback not not set set Keepalive Keepalive set set (10 (10 sec) sec) Half-duplex, Half-duplex, 10Mb/s, 10Mb/s, 100BaseTX/FX 100BaseTX/FX ARP type: ARPA, ARP ARP type: ARPA, ARP Timeout Timeout 04:00:00 04:00:00 Last Last input input 00:00:00, 00:00:00, output output 00:00:03, 00:00:03, output output hang hang never never Last Last clearing clearing of of "show "show interface" interface" counters counters never never Input Input queue: queue: 0/75/0/0 0/75/0/0 (size/max/drops/flushes); (size/max/drops/flushes); Total output drops: d rops: 0 Queueing Queueing strategy: strategy: weighted weighted fair fair Output Output queue: queue: 0/1000/64/0 0/1000/64/0 (size/max (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 0/1/256 0/1/256 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 2/2 2/2 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 7000 7000 kilobits/sec kilobits/sec ... ...
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-36
The show interface command confirms the calculation of available bandwidth for Example 3.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-33
Monitoring and Troubleshooting CB-WFQ Router#
show policy-map interface [intf]
• Displays parameters and statistics of CB-WFQ Router#show -map interface Router#show policy policy-map interface FastEthernet0/0 FastEthernet0/0 Service-policy Service-policy output: Policy1 Class-map: Class-map: Class1 Class1 (match-any) (match-any) 00 packets, packets, 00 bytes bytes 55 minute minute offered offered rate rate 0 bps, bps, drop rate 0 bps Match: Match: any any Weighted Weighted Fair Fair Queueing Queueing Output Output Queue: Queue: Conversation 265 Bandwidth Bandwidth remaining remaining 20 20 (%) (%) Max Max Threshold Threshold 64 64 (packets) (packets) (pkts (pkts matched/bytes matched/bytes matched) matched) 0/0 0/0 (depth/total (depth/total drops/no-buffer drops/no-buffer drops) drops) 0/0/0 0/0/0 Class-map: Class-map: class-default class -default (match-any) (match-any) 42 packets, 4439 bytes 42 packets, 4439 bytes 55 minute minute offered offered rate rate 0 0 bps, bps, drop drop rate rate 0 0 bps bps Match: Match: any any
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-37
The show policy-map interface command displays all service policies applied to the interface. Among the settings, policing parameters and statistics are displayed.
9-34
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting CB-WFQ Router#
show queueing fair
• Displays queuing parameters on interfaces Router#show Router#show queueing queueing fair fair Current Current fair fair queue queue configuration: configuration: Interface Interface FastEthernet0/0 FastEthernet0/0 Serial0/0 Serial0/0 Serial0/1 Serial0/1
Discard Discard threshold threshold 64 64 64 64 64 64
CB-WFQ reserves 64 queues in the WFQ system
© 2001, Cisco Systems, Inc.
Dynamic Dynamic queues queues 256 256 32 32 32 32
Reserved Reserved queues queues 64 64 00 00
Link Link queues queues 88 88 88
Prio Priority rity queues queu es 11 11 11
One queue is reserved for IP RTP Prioritization
IP QoS Modular QoS CLI Service Policy-38
The show queueing fair command displays all interfaces using Weighted Fair Queuing. The FastEthernet interface show there are 64 reserved queues (for CB-WFQ). One queue is used for IP RTP prioritization. The discard threshold is the number of packets than have to be in the queuing system to start dropping packets in the longest queue. The number of dynamic queues specifies how many queues are used in the default class if flow-based WFQ is used. WFQ reserves 8 queues (link queues) for PAK_Priority packets (link-level messages and keepalives, routing protocol hello messages and keepalives etc.).
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-35
Monitoring and Troubleshooting CB-dWFQ Router#
show queueing interface [intf]
• Displays queuing parameters on a specific VIP-based interface c7500#show c7500#show queueing queueing interface interface serial serial 5/1/0 5/1/0 Interface -based fair Interface Serial5/1/0 Serial5/1/0 queueing queueing strategy: strategy: VIP VIP-based fair queueing queueing Serial5/1/0 Serial5/1/0 queue queue size size 00 pkts pkts output output 0, 0, wfq wfq drops drops 0, nobuffer nobuffer drops drops 00 WFQ: WFQ: aggregate aggregate queue queue limit limit 00 max max available available buffers buffers 00 Class Class 0: 0: weight weight 50 50 limit limit 250 250 qsize qsize 00 pkts pkts output output 00 drops drops 0 0 Class Class 23: 23: weight weight 30 30 limit limit 150 150 qsize qsize 00 pkts pkts output output 00 drops drops 00 Class Class 24: 24: weight weight 20 20 limit limit 100 100 qsize qsize 00 pkts pkts output output 00 drops drops 00
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-39
The show queueing interface command can be used to display the parameters and statistics of distributed Weighted Fair Queuing (dWFQ) on Cisco 7x00 series routers using Versatile Interface Processors (VIPs).
9-36
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Summary Class-based Weighted Fair Queuing (CB-WFQ) is a queuing mechanism that can provide bandwidth guarantees for up to 64 classes on one interface. Bandwidth guarantees can be configured by specifying: n
A fixed guarantee in kbps
n
A fixed guarantee in a percentage of interface bandwidth
n
A dynamic guarantee by specifying a percentage of available bandwidth
Lesson Review 1. What type of guarantee does CB-WFQ provide? 2. Which DiffServ PHB can be implemented using CB-WFQ? 3. What configuration steps are needed to configure CB-WFQ?
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-37
Class-based WRED Overview This lesson describes the WRED feature and shows how and where it can be used in the MQC.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
9-38
n
Describe Class-based Weighted Random Early Detection (CB-WRED)
n
Configure CB-WRED
n
Monitor and troubleshoot CB-WRED
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based WRED • Class-based WRED can be used in combination with CB-WFQ • Using CB-WFQ with WRED allows the implementation of DiffServ’s Assured Forwarding PHB • Class-based configuration of WRED is identical to standalone WRED • Flow-based WRED is not available with the Modular QoS CLI
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-44
Congestion avoidance techniques monitor the network interface load in an effort to anticipate and avoid congestion at common network bottlenecks. Congestion avoidance is achieved through packet dropping using more complex techniques. Traditionally, Cisco IOS used standalone RED and WRED mechanisms, as described in the A_QoS_CongestAvoid module, to avoid congestion on an interface. Those mechanisms can perform a differentiated drop based on the IP precedence or DSCP-value. The Class-Based Weighted Fair Queueing (CB-WFQ) system supports the use of WRED inside the queueing system, therefore implementing Class-based WRED. Each class is queued in its separate queue, and has a queue limit, performing taildrop by default. WRED can be configured as the preferred dropping method in a queue, implementing a differentiated drop based on traffic class and further on the IP precedence or DSCP value. Note
The combination of CB-WFQ with WRED on a single device is currently the only way to implement the DiffServ’s Assured Forwarding Per-Hop Behavior (AF PFB) using Cisco IOS software.
The class-based configuration of WRED is analogous to standalone WRED configuration. Flow-based WRED (FRED) is not available within the CB-WFQ queueing system and the Cisco IOS MQC.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-39
RED Profile Drop Probability
No drop
Random drop
Full drop
100%
Maximum Drop Probability
10% 20
Minimum Threshold
40
Average Queue Size
Maximum Threshold
• WRED starts randomly dropping packets when the average queue size is above the minimum threshold © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-45
RED is currently the primary congestion avoidance method used on router interfaces. Random Early Detection is a dropping mechanism that randomly drops packets before a queue is full. The dropping strategy is based primarily on the average queue length. When the average queue gets longer (fuller), RED will be more likely to drop an incoming packet than when the queue is shorter. Because RED drops packets randomly, it has no per-flow intelligence. The rationale behind this is that an aggressive flow will represent most of the arriving traffic. Therefore it is more probable that RED will drop a packet of an aggressive session. RED therefore punishes more aggressive sessions with higher statistical probability, and is able to somewhat selectively slow down the most significant cause of congestion. Directing one TCP session at a time to slow down allows for the full utilization of the bandwidth, rather than a utilization that manifests itself as crests and troughs of traffic. As a result, the TCP global synchronization is much less likely to occur, and TCP can utilize the bandwidth more efficiently. The average queue size also decreases significantly, because the possibility of the queue filling up is very small. This is due to very aggressive dropping in the event of traffic bursts, when the queue is already quite full. RED distributes losses over time and maintains normally low queue depth while absorbing spikes. RED can also utilize IP precedence or DSCP bits in packets to establish different drop profiles for different classes of traffic. The probability of a packet being dropped is based on three configurable parameters: n
9-40
Minimum threshold: When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
linearly as the average queue size increases, until the average queue size reaches the maximum threshold. n
Maximum threshold: When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.
n
Mark probability denominator: This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
These parameters define the RED profile, which implements the packet dropping strategy, which is based on the average queue length.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-41
RED Modes • RED has three modes: – No drop: when the average queue size is between 0 and the minimum threshold – Random drop: when the average queue size is between the minimum and the maximum threshold – Full drop (tail-drop): when the average queue size is at maximum threshold or above
• Random drop should prevent congestion (prevent tail-drops)
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-46
RED has three dropping modes, based on the average queue size:
9-42
n
When the average queue size is between 0 and the configured minimum threshold, no drops occur and all packets are queued.
n
When the average queue size is between the configured minimum threshold, and the configured maximum threshold, random drop occurs. Random drop is linearly proportional to the average queue length. The maximum probability of drop (when the queue is almost completely full) is 10% in Cisco IOS software if the default settings are used.
n
When the average queue size is at maximum or higher than the maximum threshold, RED performs full (tail) drop in the queue. This event is unlikely, because RED should slow down TCP traffic ahead of the congestion. If a lot of non-TCP traffic is present, RED cannot effectively drop traffic to reduce congestion, and tail-drops are likely to occur.
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
WRED Building Blocks Calculate Average Queue Size
IP packet
Queue Full?
WRED
IP precedence or DSCP
Select WRED Profile
© 2001, Cisco Systems, Inc.
Min. threshold Max. threshold Max prob. denom.
No
Current Queue Size FIFO Queue
Yes
Random Drop
Tail Drop
IP QoS Modular QoS CLI Service Policy-47
The figure shows how WRED is implemented, and what parameters influence WRED dropping decisions. The WRED algorithm is constantly updated with the calculated average queue size, which is based on the recent history of queue sizes. The configured WRED profiles define the dropping thresholds (and therefore the WRED probability slopes). When a packet arrives at the output queue, the IP precedence or the DSCP-value is used to select the correct WRED profile for the packet, and the packet is passed to WRED to perform a drop/enqueue decision. Based on the profile and the average queue size, WRED calculates the probability for dropping the current packet and then either drops it or passes it to the output queue. If the queue is already full, the packet is tail-dropped. Otherwise, it is eventually transmitted out on the interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-43
Weighted Random Early Detection • WRED uses a different RED profile for each weight • Each profile is identified by: – minimum threshold – maximum threshold – maximum drop probability
• Weight can be – IP precedence (8 profiles) – DSCP (64 profiles)
• WRED drops less important packets more aggressively than more important packets © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-48
Weighted Random Early Detection (WRED) combines RED with IP Precedence or DSCP and does packet drops based on IP Precedence or DSCP markings. WRED can selectively discard lower priority traffic when the interface begins to get congested and provide differentiated performance characteristics for different classes of service. WRED can also be configured so that non-weighted RED behavior is achieved.
9-44
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
WRED Profiles Drop Probability 100%
10% 10
20
40
Average Queue Size
• WRED profiles can be manually set • WRED has 8 default value sets for IP precedence based WRED • WRED has 64 default value sets for DSCP based WRED © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-49
The figure shows two WRED profiles, used with traffic of different QoS classes. One class has a much lower minimum and maximum threshold, and traffic of that class will be dropped much earlier and more aggressively, and will ultimately be tail dropped early, when heavy congestion occurs. The other class has a higher minimum and maximum threshold. Therefore dropping occurs later and is less likely to occur. These two classes maintain differentiated levels of service in the event of congestion. To avoid the need for setting all WRED parameters in a router, 8 default values are already defined for precedence-based WRED, and 64 DiffServ-aligned values are defined for DSCP-based WRED. Therefore, the default settings should suffice in the vast majority of deployments.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-45
IP Precedence and Class Selector Profiles Drop Probability
100%
10% IP precedence
0
20
1 2 3 4 5 6 7 RSVP 22 24 26 28 31 33 35 37 40
© 2001, Cisco Systems, Inc.
Average Queue Size
IP QoS Modular QoS CLI Service Policy-50
The Class selector range of DSCP values is used for backward compatibility with IP precedence. The same WRED profiles are applied to equal IP precedence and Class selector values:
9-46
IP precedence
DSCP (Class selector)
(three bits)
(six bits)
0
Default (0)
20
1
cs1 (8)
22
2
cs2 (16)
24
3
cs3 (24)
26
4
cs4 (32)
28
5
cs5 (40)
31
6
cs6 (48)
33
7
cs7 (56)
35
RSVP
RSVP
37
IP QoS Modular QoS CLI Service Policy
Default minimum threshold
Copyright 2001, Cisco Systems, Inc.
DSCP-based WRED (Expedited Forwarding) Drop Probability
100%
10%
EF
20
36 40
© 2001, Cisco Systems, Inc.
Average Queue Size
IP QoS Modular QoS CLI Service Policy-51
For the Expedited Forwarding DiffServ traffic class, WRED configures itself by default so that the minimum threshold is very high, thus increasing the probability of no drops being applied to that traffic class. EF-traffic is therefore expected to be dropped very late, compared to other traffic classes, and is therefore prioritized in the event of congestion. DSCP (six bits) EF (101110)
Copyright 2001, Cisco Systems, Inc.
Default minimum threshold 36
IP QoS Modular QoS CLI Service Policy
9-47
DSCP-based WRED (Assured Forwarding) Drop Probability
100%
AF Low Drop AF Medium Drop AF High Drop
10%
20 24
28 32
© 2001, Cisco Systems, Inc.
40
Average Queue Size
IP QoS Modular QoS CLI Service Policy-52
For the Assured Forwarding DiffServ traffic class, WRED configures itself by default, for three different profiles, depending on the Drop Preference DSCP marking bits. AF-traffic should therefore be classified into the three possible classes based on the application sensitivity to dropping. WRED implements a congestion avoidance PHB in agreement with the initial classification. DROP Precedence
Class #1
Class #2
Class #3
Class #4
Low Drop Prec
(AF11) 001010 (AF12) 001100 (AF13) 001110
(AF21) 010010 (AF22) 010100 (AF23) 010110
(AF31) 011010 (AF32) 011100 (AF33) 011110
(AF41) 100010 (AF42) 100100 (AF43) 100110
Medium Drop Prec High Drop Prec
9-48
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring WRED Router(config-pmap-c)#
random-detect
• Enables IP precedence based WRED in the selected class within the service policy configuration mode • Default service profile is used
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-53
The random-detect command is used to enable WRED on an interface. By default, WRED is IP precedence-based, using eight default WRED profiles. Within the CB-WFQ system, WRED is used to perform per-queue drop in the class queues. Therefore, each class queue has its own WRED method, which can be further weighed based on the IP precedence or DSCP-value. Each queue can therefore be configured with a separate dropping policy, to implement different drop policies for every class of traffic.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-49
Changing WRED Profile Router(config-pmap-c)#
random-detect precedence precedence min-threshold max-threshold mark-prob-denominator
• Changes RED profile for specified IP precedence value • Packet drop probability at maximum threshold is 1 / mark-prob-denominator • Non-weighted RED is achieved by using the same RED profile for all precedence values
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-54
In the example in the figure, WRED is enabled with default values, and then the values are changed for each IP Precedence level. The configured values are the same as for Random Early Detection, and are: n
Minimum threshold - When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold.
n
Maximum threshold - When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.
n
Mark probability denominator - This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
It is interesting to note, that the maximum probability of drop at the maximum threshold can be expressed as 1/mark-prob-denominator. The maximum drop probability is 10%, if default settings are used which have a mark probability denominator value of 10. If required, RED can be configured as a special case of WRED, by assigning the same profile to all eight IP precedence values.
9-50
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Changing WRED Sensitivity to Bursts Router(config-pmap-c)#
random-detect exponential-weighting-constant n
Qavg ( t + 1) = Qavg (t ) ⋅ (1 − 2 − n ) + Qt ⋅ 2 − n New average queue size
Previous average queue size
Current queue size
• WRED takes the average queue size to determine the current WRED mode (no drop, random drop, full drop) • High values of N allow short bursts • Low values of N make WRED more burst-sensitive • Default value (9) should be used in most scenarios • Average output queue size with N=9 is average t+1 = average t * 0.998 + queue_sizet * 0.002 © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-55
WRED does not calculate the drop probability using the current queue length, but rather uses the average queue length. The average queue length is constantly recalculated using two terms: the previously calculated average queue size and the current queue size. An exponential weighting constant N influences the calculation by weighing the two terms, therefore influencing how the average queue size follows the current queue size, in the following way: n
A low value of N makes the current queue size more significant in the new average size calculation, therefore more sensitive to bursts
n
A high value of N makes the previous average queue size more significant in the new average seize calculation, so that bursts influence the new value to a smaller degree.
The default value is 9 and should suffice for most scenarios, except perhaps those involving extremely high-speed interfaces (e.g. OC12), where it can be increased slightly (to about 12) to allow more bursts.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-51
Configuring DSCP-based WRED Router(config-pmap-c)#
random-detect {prec-based | dscp-based}
• Selects WRED mode • Precedence-based WRED is the default mode • DSCP-based uses 64 profiles
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-56
The random-detect dscp-based command is used to enable DSCP-based WRED on an interface, using the 64 default DSCP-based WRED profiles.
9-52
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Changing the WRED Profile Router(config-pmap-c)#
random-detect precedence precedence min-threshold max-threshold mark-prob-denominator
• Changes RED profile for specified IP precedence value • Packet drop probability at maximum threshold is 1 / mark-prob-denominator • Non-weighted RED is achieved by using the same RED profile for all precedence values
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-54
The DSCP-weighted WRED profiles can be changed, using the known three WRED parameters. The mask-prob-denominator defines the packet drop probability at the WRED maximum threshold. The maximum drop probability is 10%, if default settings are used which have a mark probability denominator value of 10. Normally, the DSCP-weighed profiles should be left at their default settings, because those settings are appropriate for most situations, if the traffic is classified according to the DiffServ service specification.
Copyright 2001, Cisco Systems, Inc.
IP prcecdence
Default minimum threshold
0
20
1
22
2
24
3
26
4
28
5
31
6
33
7
35
RSVP
37
IP QoS Modular QoS CLI Service Policy
9-53
9-54
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ with WRED Example 1 • Enable CB-WFQ to prioritize traffic according to the following requirements: – Class Gold is marked with IP precedence values 3 and 4 (3 is high drop, 4 is low drop) and should get 30% of interface bandwidth – Class Silver is marked with IP precedence values 1 and 2 (1 is high drop, 2 is low drop) and should get 20% of interface bandwidth – All other traffic should be per -flow fair-queued
• Use differentiated WRED to prevent congestion in all three classes (try to set up your own WRED profiles for Gold and Silver) © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-58
The first CB-WFQ with WRED example focuses on a network, which provides three different service levels for three traffic classes n
The Gold class, marked with IP precedence values of 3 and 4 (3 is used for high drop, and 4 is used for low drop within the service class) should get 30% of an interface bandwidth
n
The Silver class, marked with IP precedence values of 1 and 2 (1 being highdrop, and 2 being low-drop service) should get 20% of the interface bandwidth.
n
Best effort traffic should get the remaining bandwidth share, and should be fair-queued.
To enforce this service policy, a router will use CB-WFQ to perform bandwidth sharing, and WRED within service classes to perform differentiated drop.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-55
CB-WFQ with WRED Example 1 class-map class-map Gold Gold match 3 4 match ip ip precedence precedence 3 4 !! class-map class-map Silver Silver match match ip precedence 1 2 !! policy-map policy-map Policy1 Policy1 class class Gold Gold bandwidth bandwidth percent percent 30 30 random-detect random-detect random-detect random-detect precedence precedence random-detect random-detect precedence precedence class class Silver Silver bandwidth bandwidth percent percent 20 20 random-detect random-detect random-detect random-detect precedence precedence random-detect random-detect precedence precedence class class class-default class-default fair-queue fair-queue random-detect random-detect !! © 2001, Cisco Systems, Inc.
3 20 40 10 4 30 40 10
1 15 35 10 2 20 35 10
IP QoS Modular QoS CLI Service Policy-59
The figure shows a configuration implementing the example service policie s. The traffic is classified based on the precedence bits, and all non-contract traffic is classified into the default class.
9-56
n
The Gold class is guaranteed at least 30 percent of bandwidth, with a custom WRED profile, which establishes a low-drop and a high-drop per-hop behavior.
n
The Silver class is guaranteed at least 20 percent of bandwidth, is configured with somewhat lower WRED drop thresholds, and is therefore more likely to be dropped than the Gold class in the event of interface congestion.
n
All other traffic is part of the default class, is fair-queued, with default WRED parameters.
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-WFQ with WRED Example 2 • Use the QoS design from the previous example • Implement it using DSCP: – Class “Gold” is using AF1 – Class “Silver” is using AF2
• Make sure the new configurations still conform to the design and implementation from the previous example
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-60
CB-WFQ with WRED Example 1 was implemented using a CoS based on the precedence bit. In this example, the same policy is configured, but DSCP-based CoS classification and QoS services are used. Remember that the DiffServ model itself provides defined traffic classes and their associated PHB. DiffServ-based classification is used in this example.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-57
CB-WFQ with WRED Example 2 class-map class-map Gold Gold match match ip ip dscp dscp af11 af11 af12 af12 af13 af13 cs3 cs3 cs4 cs4 !! class-map class-map Silver Silver match match ip dscp dscp af21 af21 af22 af22 af23 af23 cs1 cs1 cs2 cs2 !! policy-map policy-map Policy1 Policy1 class class Gold Gold bandwidth bandwidth percent percent 30 30 random-detect -based random-detect dscp dscp-based random-detect random-detect dscp dscp af11 af11 30 30 40 40 10 10 random-detect random-detect dscp dscp af12 af12 25 25 40 40 10 10 random-detect random-detect dscp dscp af13 af13 20 20 40 40 10 10 random-detect random-detect dscp dscp cs3 cs3 20 20 40 40 10 10 random-detect random-detect dscp cs4 30 40 10
© 2001, Cisco Systems, Inc.
class class Silver Silver bandwidth bandwidth percent percent 20 20 random-detect -based random-detect dscp dscp-based random-detect random-detect dscp dscp af11 af11 25 25 35 35 10 10 random-detect random-detect dscp dscp af12 af12 20 20 35 35 10 10 random-detect random-detect dscp dscp af13 af13 15 15 35 35 10 10 random-detect random-detect dscp dscp cs3 cs3 15 15 35 35 10 10 random-detect random-detect dscp dscp cs4 cs4 25 25 35 35 10 10 class class class-default class-default fair-queue fair-queue random-detect -based random-detect dscp dscp-based !!
IP QoS Modular QoS CLI Service Policy-61
The configuration example shows how traffic classification is performed using DSCP-based classes, representing the Gold class as the AF1 class, and using the AF2 class as the Silver class. WRED DSCP-based parameters are sent reflecting the class-dependent drop strategy.
9-58
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting CB-WRED Router#show -map interface Router#show policy policy-map interface fastEthernet fastEthernet 0/0 0/0 FastEthernet0/0 FastEthernet0/0 Service-policy Service-policy output: Policy1 Class-map: Class-map: Gold (match-all) (match -all) 00 packets, packets, 00 bytes bytes 55 minute offered minute offered rate rate 0 bps, bps, drop rate 0 bps Match: Match: ip ip precedence precedence 33 44 Match: Match: ip ip dscp dscp 10 10 12 12 14 14 24 24 32 32 Weighted Weighted Fair Fair Queueing Queueing Output Output Queue: Queue: Conversation Conversation 265 265 Bandwidth Bandwidth 30 30 (%) (%) Bandwidth 3000 (kbps) Bandwidth 3000 (kbps) (pkts (pkts matched/bytes matched/bytes matched) matched) 0/0 0/0 (depth/total (depth/total drops/no-buffer drops/no-buffer drops) drops) 0/0/0 0/0/0 exponential exponential weight: weight: 99 mean queue depth: 0 mean queue depth: 0 Dscp Dscp (Prec) (Prec) 0(0) 0(0) 11 22 33
Random Random drop drop pkts/bytes pkts/bytes 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0
Tail drop pkts/bytes pkts/bytes 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0
Minimum Maximum Mark threshold threshold threshold threshold probability probability 20 40 1/10 20 40 1/10 22 40 1/10 22 40 1/10 24 40 1/10 24 40 1/10 26 40 1/10 26 40 1/10
... ... © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-62
The show policy-map interface command shows the service policy applied to an interface, including all WRED parameters implementing the dropping policy on that interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-59
Summary n
WRED can be used inside the Cisco IOS CB-WFQ, configured via the MQC
n
WRED can be applied per-service policy
n
All WRED parameters are inherited from the traditional Cisco IOS WRED implementation
Lesson Review 1. How does WRED supplement CB-WFQ? 2. Can WRED be combined with flow-based WFQ in the default class? 3. Which two operational modes does WRED support? 4. How many profiles does WRED support?
9-60
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Low-latency Queuing Overview This lesson describes the Low-latency Queueing (LLQ) feature within the CBWFQ system.
Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe Class-based Low-latency Queuing (CB-LLQ)
n
Configure CB-LLQ
n
Monitor and troubleshoot CB-LLQ
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-61
Class-based Low-latency Queuing • VoIP or other multimedia applications should not be fair-queued with other data • IP RTP Prioritization has a number of drawbacks: – It is not selective enough (filters only on UDP port range) – It does not support TCP or other protocols – You can only specify overall high-priority traffic rate
• Class-based Low-latency Queuing (CB-LLQ) removes most of the drawbacks of IP RTP Prioritization © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-67
While Weighed Fair Queuing (WFQ) provides a fair share of bandwidth to every flow, and provides fair scheduling of its queues, it cannot provide guaranteed bandwidth and low delay to select applications. Voice traffic, for example, may still compete with other aggressive flows in the WFQ queuing system, which lacks priority scheduling for time-critical traffic classes. IP RTP Prioritization is one Cisco IOS feature designed to guarantee priority of voice traffic. However, because it only can only prioritize pure RTP traffic (IP RTP Prioritization uses a UDP port range heuristic to distinguish RTP from the rest of the traffic), and lacks flexibility in policing, it does not present a via ble solution when multiple non-RTP time-critical applications are deployed in the network. Class-based Low-latency Queueing (CB-LLQ) is a method, used within the CBWFQ framework, which can prioritize traffic flows with the flexibility of the Cisco IOS MQC interface.
9-62
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Low-Latency Queueing Queuing and Scheduling Forwarder
Class Priority
Yes
BW Policing
Yes
BW Policing
Yes
Flow queue (FIFO)
Yes
Priority queue (FIFO)
No
Class Priority No
Class N?
WFQ Scheduling
No
Class Default?
© 2001, Cisco Systems, Inc.
WFQ/FIFO
IP QoS Modular QoS CLI Service Policy -68
When CB-WFQ is configured as the queueing system, it creates a number of queues, into which it classifies traffic classes. These queues are then scheduled with a WFQ-like scheduler, which can guarantee bandwidth to each class. If Class-based Low-latency Queuing is used within the CB-WFQ system, it creates additional, priority queues in the WFQ system, which are serviced by a strict priority scheduler. Any class of traffic can therefore be attached to a service policy, which uses priority scheduling, and hence can be prioritized over other classes.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-63
CB-LLQ Scheduling • High-priority classes are guaranteed: – Low-latency propagation of packets – Bandwidth
• High-priority classes are also policed – they can not exceed the guaranteed bandwidth
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-69
The CB-LLQ priority scheduler guarantees both low-latency propagation of packets and bandwidth to high-priority classes. Low-latency is achieved by expediting traffic using a priority schedule r. Bandwidth is also guaranteed by the nature of priority scheduling, but is policed to a user-configurable value. Policing of priority queues also prevents the priority scheduler from monopolizing the CBWFQ scheduler and starving non-priority classes, like legacy Priority Queuing does.
9-64
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring CB-LLQ Router(config-pmap-c)#
priority bandwidth
• Allocate a fixed amount of bandwidth (in kbps) to a class and ensure expedited forwarding • Traffic exceeding the specified bandwidth is dropped Router(config-pmap-c)#
priority percent percent
• Allocate a percentage of configured or default interface bandwidth to a class and ensure expedited forwarding • Traffic exceeding the specified bandwidth is dropped
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-70
Configured by the priority command, LLQ enables the use of a single priority queue within CBWFQ at the class level, allowing the user to direct traffic belonging to a class to the CBWFQ priority queue. To enqueue class traffic to the priority queue, configure the priority command for the class after the named class is specified within a policy map. Classes to which the priority command is applied are considered priority classes. One or more classes can be given priority status within a policy map. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is enqueued to the same, single, priority queue. The bandwidth and percent options allocate a fixed amount of bandwidth (in kbps) to the priority class, using absolute or relative bandwidth respectively. The priority queue is policed using this bandwidth parameter and all exceeding packets are dropped. Keep the following guidelines in mind when using the priority command: n
Layer 2 encapsulations are accounted for in the amount of bandwidth specified with the priority command. However, ensure a bandwidth is configured that has room for cell-tax overhead and possible jitter introduced by the routers in the voice path.
n
Use the priority command for VoIP on serial links and ATM PVCs. It does not support VoIP over Frame Relay links.
n
Use the priority command in conjunction with the set command. You cannot use the priority command in conjunction with any other command, including the random-detect, queue-limit, and bandwidth commands.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-65
n
9-66
You can configure the priority command in multiple classes, but you should only use it for voice-like, constant bit rate (CBR) traffic. If the traffic is not CBR, you must configure a large enough bandwidth parameter to absorb the data bursts.
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-LLQ Example class-map class-map VoIP VoIP match match ip ip precedence precedence 55 !! class-map class-map Gold Gold match match ip precedence 3 4 !! class-map class-map Silver Silver match 1 2 match ip ip precedence precedence 1 2 !! policy-map policy-map Policy1 Policy1 class class VoIP priority priority percent percent 10 10 class class Gold Gold bandwidth bandwidth percent percent 30 30 random-detect random-detect class class Silver bandwidth bandwidth percent percent 20 20 random-detect random-detect class class class-default class-default fair-queue fair-queue random-detect random-detect !! © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-71
This figure shows a configuration example, where the VoIP traffic class, classified by the IP precedence of 1, is queued in a priority queue within the CB-WFQ system. The priority class received priority scheduling compared to other classes’ queues, and is guaranteed, but limited to 10 percent of bandwidth.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-67
Monitoring and Troubleshooting CB-LLQ Router#show Router#show policy-map policy-map interface interface fastethernet fastethernet 0/0 0/0 FastEthernet0/0 FastEthernet0/0 Service-policy Service-policy output: output: LLQ LLQ Class-map: -any) Class-map: LLQ LLQ (match (match-any) 00 packets, packets, 0 0 bytes bytes 55 minute bps minute offered offered rate rate 0 0 bps, bps, drop drop rate rate 0 0 bps Match: Match: any Weighted Weighted Fair Fair Queueing Queueing Strict Strict Priority Priority Output Output Queue: Conversation 264 Bandwidth Bandwidth 1000 1000 (kbps) (kbps) Burst Burst 25000 25000 (Bytes) (Bytes) (pkts (pkts matched/bytes matched/bytes matched) matched) 0/0 0/0 (total (total drops/bytes drops/bytes drops) drops) 0/0 0/0 Class-map: -default (match -any) Class-map: class class-default (match-any) 00 packets, packets, 0 bytes 55 minute bps minute offered offered rate rate 0 0 bps, bps, drop drop rate rate 0 0 bps Match: Match: any any
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-72
The show policy-map interface command shows the service policy settings on an interface. The priority scheduling method is listed, if enabled.
9-68
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Summary n
CB-LLQ guarantees priority scheduling with guaranteed bandwidth on an interface
n
CB-LLQ is integrated with CB-WFQ and configured via the Cisco IOS MQC
n
CB-LLQ is more flexible than IP RTP Prioritization
Lesson Review 1. What advantages does CB-LLQ have over IP RTP Prioritization? 2. What guarantees does CB-LLQ provide?
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-69
Class-based Policing Overview This lesson section describes the Class-based Policing mechanism used within the CB-WFQ system. The lesson also compares Class-based Policing implementation with the standalone CAR mechanism.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
9-70
n
Describe Class-based Policing
n
Configure CB-Policing
n
Monitor and troubleshoot CB-Policing
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Policing • Class-based Policing is used to limit a traffic class to a configured bit rate • It uses a Token Bucket model to measure the arrival rate of packets • Class-based Policing is an improved version of the Committed Access Rate (CAR) mechanism • Class-based Policing is configured using the Modular QoS CLI
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-77
Class-based Policing allows the servic e provider to rate-limit traffic in and out of the router interfaces to a configured bit rate, thereby enabling various forms of ingress and egress rate-limiting in a network. Class-based policing is implemented within the CB-WFQ queueing method, and configured via the Cisco IOS MQC. Like Committed Access Rate (CAR), Class-based Policing simply rate-limits traffic according to a simple “forward or drop” policy, according to the configuration. Class-based policing also uses a token-bucket metering mechanism, similar to CAR, but with some modification and added flexibility.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-71
How do Routers Measure Traffic Rate Bandwidth
Link bandwidth Exceeding traffic Rate limit Conforming Traffic Time
• Routers use the Token Bucket mathematical model to keep track of packet arrival rate • The Token Bucket model is used whenever a new packet is processed • The return value is conform or exceed © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-78
In order to perform rate limiting, routers must meter (or measure) traffic rates through its interfaces. To enforce a rate limit, metered traffic is said to: n
Conform to the rate limit, if the rate of traffic is below the configured rate limit
n
Exceed the rate limit, if the rate of traffic is above the configured rate limit
The metering is usually performed with an abstract mathematical model called a token bucket, which is used when processing each packet. The token bucket can calculate whether the current packet conforms or exceeds the configured rate limit on an interface.
9-72
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Token Bucket
700
500 bytes
© 2001, Cisco Systems, Inc.
Conform Action
500 bytes
IP QoS Modular QoS CLI Service Policy-79
The token bucket is a mathematical model used in a device that regulates the data flow. The model has two basic ingredients: n
Tokens, where each token represents the permission to send a fixed number of bits into the network
n
The bucket, which has the capacity to hold a specified amount of tokens
Tokens are put into the bucket at a certain rate by the operating system. Each incoming packet, if forwarded, takes tokens from the bucket, representing the packet’s size. If not enough tokens are available in the bucket to send the packet, the policer discards the packet. If the bucket fills to capacity, newly arriving tokens are discarded, and discarded tokens are not available to future packets. The figure shows a token bucket, with the current capacity of 700 bytes. When a 500-byte packet arrives at the interface, its size is compared to the bucket capacity (in bytes). The packet conforms to the rate limit (500 bytes < 700 bytes), the packet is forwarded, and 500 bytes worth of tokens are removed from the bucket.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-73
Token Bucket
200
300 bytes
Exceed Action
s byte 300
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-80
When the next packet arrives immediately after the first packet, and because no new tokens have been added to the bucket (which is done periodically), there are not enough tokens in the bucket to represent the current packet. The current packet therefore exceeds the rate limit and is dropped.
9-74
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Token Bucket Be
Bc of tokens is added every Tc [ms]
Link BW
Link Utilization Bc
Bc
Bc
Bc
Bc
Bc
2*Tc
3*Tc
4*Tc
5*Tc
Tc = Bc / CIR Tc
Average BW (CIR)
Time
Be
• Bc is normal burst size (specifies sustained rate) • Be is excess burst size (specifies length of burst)
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-81
Token bucket implementations usually rely on three parameters: CIR, Bc and Be. CIR is the Committed Information Rate (also called the committed rate), which represents the long-term average rate of traffic. Bc is known as the burst capacity. Be is known as the excess burst capacity. Tc is a time interval constant. In the token bucket metaphor, tokens are put into the bucket at a certain rate, which is Bc tokens every Tc seconds. The bucket itself has a specified capacity. If the bucket fills to capacity (Bc + Be), newly arriving tokens are discarded. Each token is permission for the source to send a certain number of bits into the network. To send a packet, the regulator must remove, from the bucket, the number of tokens equal in representation to the packet size. For example, if 8000 bytes worth of tokens are placed in the bucket every 125 milliseconds, the router can steadily transmit 8000 bytes every 125 milliseconds, if traffic constantly arrives at the router. If there is no traffic at all, 8000 bytes per 125 milliseconds get accumulated in the bucket, up to the maximum size (Bc+Be). One second’s accumulation therefore collects 64000 bytes worth of tokens, which can be transmitted immediately in the case of a burst. The upper limit, Bc+Be, defines the maximum amount of data, which can be transmitted in a single burst, at the line rate. A token bucket permits burstiness but bounds it. It guarantees that the burstiness is bounded so that the flow will never send faster than the token bucket's capacity. This means, that in the long-term, the transmission rate will not exceed the established rate at which tokens are placed in the bucket (the committed rate).
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-75
Class-based Policing • CAR uses one single token bucket to determine if a packet conforms to or exceeds the bit-rate policy • CB-Policing uses one or two token buckets to determine if a packet: – Conforms – is within the average bit rate – Exceeds – exceeds the average bit rate but is within the allowed excess burst – Violates – exceeds both the average bit rate and the allowed excess burst (optional)
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-82
When CAR is in effect, its metering code uses a single token bucket, and is able to determine whether incoming traffic conforms or exceeds the configured rate-limit. Class-based Policing introduces a two-token-bucket scheme in the policer. Using two token buckets, traffic can: n
Conform to the rate limit, when it is within the average bit rate
n
Exceed the rate limit, when it exceeds the average bit rate, but does not exceed the allowed excess burst
n
Violate the rate limit, when it exceeds both the average rate and the excess bursts.
The double token bucket method is explained later in the lesson.
9-76
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Policing Actions • CB-Policing can execute three different actions (conform, exceed or violate) • Each action can be one of the following: – Transmit – Drop – Set IP Precedence and transmit – Set IP DSCP and transmit – Set QoS group and transmit – Set MPLS experimental bits and transmit – Set Frame Relay DE bit and transmit – Set ATM CLP bit and transmit © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-83
Based on the current packet conforming, exceeding, or violating the rate limit, an action can be taken by the policer. The CB-WFQ policer supports the following actions: n
Transmit—the packet is transmitted
n
Drop—the packet is dropped
n
Set precedence (or DSCP value) and transmit: the IP Precedence (ToS) or DSCP bits in the packet header are rewritten. The packet is then transmitted. This action can be used to either color (set precedence) or recolor (modify existing packet precedence) the packet.
n
Set QoS group and transmit: the QoS group can be set and then used only locally within the router. The QoS group can be used in later QoS mechanisms and performed in the same router, such as CB-WFQ. The packet is then transmitted.
n
Set MPLS experimental bits and transmit: the MPLS experimental bits can be set. The packet is then transmitted. These are usually used to signal QoS parameters in a MPLS cloud.
n
Set Frame Relay DE bit and transmit: the Frame Relay Discard Eligibility (DE) bit is set in the Layer-2 (Frame Relay) header and the packet is transmitted. This setting can be used to mark excessive or violating traffic (which should be dropped with preference on Layer-2 switches) at the edge of a Frame Relay network.
n
Set ATM CLP bit and transmit: the ATM Cell Loss Priority (CLP) bit is set in the Layer-2 (ATM) header and the packet is transmitted. This setting
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-77
can be used to mark excessive or violating traffic (which should be dropped with preference on Layer-2 switches) at the edge of an ATM network.
9-78
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Single Token Bucket with Class-based Policing
700
500 bytes
BE
Conform Action
• Packet conforms to the policy if the size of the packet is less or equal to the number of tokens in the TB © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-84
Class-based Policing can use a single or double token bucket method as the metering mechanism. The one token bucket algorithm is used when the violateaction option is not specified in the police MQC command. If one token bucket is used, the meter can only differentiate between conforming and exceeding traffic. Therefore, in a simple single token bucket algorithm, a packet conforms to the line rate, if the size of the packet is less or equal to the number of tokens in the token bucket. The actual metering algorithm used by CB-Policing is somewhat different from a pure token bucket, described above, and used by CAR. With CAR, the token bucket is refilled at periodic intervals (Tc) with a fixed number of tokens (Bc). Class-based policing employs a different method, which calculates the bucket size and adds tokens on every processed packet. The Class-based policing works in the following manner: n
The token bucket is initially set to the full size (the full size is the number of bytes specified as the normal burst size or Bc)
n
When a packet of size B bytes arrives at time t the following actions occur: –
Tokens are updated in the conform bucket. If the previous arrival of the packet was at t1 and the current time is t, the bucket is updated with (t-t1) worth of bits based on the token arrival rate. The perpacket token arrival rate is calculated as: (time between consecutive packets * policer rate)/8 bytes
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-79
9-80
–
If the number of bytes in the conform bucket - B is greater than or equal to 0, the packet conforms and the conform action is taken on the packet. If the packet conforms, B bytes are removed from the conform bucket and the conform action is completed for the packet.
–
If the number of bytes in the conform bucket - B is less than 0, the exceed action is taken.
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Single Token Bucket with Class-based Policing
200
300 bytes
BE
Exceed Action
• Packet exceeds the policy if the size of the packet is more than the number of tokens in the TB © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-85
When a packet size is more than the available number of tokens in a TB, the packet exceeds the rate limit. Again, this is a simplified algorithm for a pure token bucket. Class-based policing uses a slightly different algorithm, which was described previously.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-81
Double Token Bucket with Class-based Policing
700
500 bytes
BC
400
BE
Conform Action
• Packet conforms to the policy if the size of the packet is less or equal to the number of tokens in the first TB © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-86
Cisco IOS Class-based policing uses a double token bucket metering method, when the violate action is specified in the police MQC command. One bucket is used to meter conforming traffic (the conform bucket), and is of size BC. The other bucket is used to meter exceeding traffic, and is of size BE. The conform bucket is initially full (the full size is the number of bytes specified as the normal burst size, BC). The exceed bucket is also initially full (the full exceed bucket size is the number of bytes specified in the maximum burst size, BE). The tokens for both the conform and exceed token buckets are updated based on the token arrival rate (or CIR). In simple terms, with the double token bucket system, an incoming packet conforms to the rate limit, if the conform bucket has enough tokens for the size of the packet. Looking into the details of the algorithm, the actual processing which occurs is as follows: n
A packet of size B bytes arrives at time t
n
Tokens are updated in the conform bucket. If the previous arrival of the packet was at t1 and the current arrival of the packet is at t, the bucket is updated with t-t1 worth of bits based on the token arrival rate. The refill tokens are placed in the conform bucket. If the tokens overflow the conform bucket, the overflow tokens are placed in the exceed bucket. The token arrival rate is calculated as follows: (time between packets<which is equal to t-t1> * policer rate)/8 bytes
9-82
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
n
If the number of bytes in the conform bucket - B is greater than or equal to 0, the packet conforms and the conform action is taken on the packet. If the packet conforms, B bytes are removed from the conform bucket and the conform action is taken. The exceed bucket is unaffected in this scenario.
n
If the number of bytes in the conform bucket - B is less than 0, the excess token bucket is checked for bytes by the packet. If the number of bytes in the exceed bucket - B is greater than or equal to 0, the exceed action is taken and B bytes are removed from the exceed token bucket. No bytes are removed from the conform bucket.
n
If the number of bytes in the exceed bucket - B is less than 0, the packet violates and the violate action is taken. The action is complete for the packet.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-83
Double Token Bucket with Class-based Policing
200
300 bytes
BC
400
BE
Exceed Action
• Packet exceeds the policy if the size of the packet is more than the number of tokens in the first TB and less or equal to the number of tokens in the second TB © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-87
If looking at the double token bucket in a simplified way, an incoming packet would exceed the rate limit, if the conform bucket does not have enough tokens for the size of the packet, but the exceed bucket does. For a detailed insight, consult the previously laid-out algorithm.
9-84
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Double Token Bucket with Class-based Policing
200
400 bytes
BC
100
BE
Violate Action
• Packet violates the policy if the size of the packet is more than the number of tokens in the first and the second TB © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-88
In simple terms, the double token bucket system means that an incoming packet violates the rate limit, if neither the conform nor the exceed buckets have enough tokens for the size of the packet. For a detailed insight, consult the previously laid-out algorithm
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-85
Refilling the Token Buckets Add tokens at the configured bit rate
BC
Excess spills over into the second token bucket
TB1
TB2
BE
• The number of tokens that have to be added is actually calculated every time a new packet has to be processed:
TB1 = min(B C, TB1 + (Tnow -TLastPacket) * BitRate / 8) New size of the token bucket © 2001, Cisco Systems, Inc.
Previous size of the token bucket
Time now [seconds]
Time of the last packet [seconds]
IP QoS Modular QoS CLI Service Policy -89
The detailed token bucket algorithms are somewhat different from the classic token bucket algorithms used by CAR and GTS. Token refilling is done per packet, which can considerably smooth out rate limiting, because there is no fixed interval (Tc) for bucket refills. Instead, the calculation TB1_after = min(BC, TB1_before + (Tnow -TLastPacket ) * BitRate / 8) where TB1 is the token bucket size, BC is the maximum conform token bucket size, Tnow is the current time, TLastPacket is the time of arrival of the previous packet, and the BitRate is the CIR of the rate limit, defines the new size of the conform bucket, and is calculated for each incoming packet. If the number of tokens exceeds the size of the conform bucket (BC), excess tokens spill over and fill the second (exceed) bucket. If the exceed bucket overflows with tokens, those tokens are lost. The new token bucket size, therefore, equals to the BC (Conform Bucket Size) or the “Previous bucket size + added tokens since the last packet was transmitted”, which ever is smaller.
9-86
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring Class-based Policing Router(config-pmap-c)#
police avg-rate [BCC [BEE]] [conform-action [action] [exceed-action [action] [violate-action [action]]]] • avg-rate – traffic rate in bps (8.000 to 200.000.000) • BC – normal burst sets the size of the first token bucket in bytes (default is 1500 or avg-rate/32; whatever is higher) • BE – excess burst sets the size of the second token bucket in bytes (equals BC if not configured) • action – can be: • • • • • • • •
transmit (default conform action) drop (default exceed and violate action) set-prec-transmit ip-precedence set-dscp-transmit dscp set-qos-transmit qos-group set-mpls-exp-transmit mple-exp set frde-transmit set-clp-transmit
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-90
The police MQC command defines policing parameters for a traffic class. The avg-rate parameter defines the policed average traffic rate (CIR), the BC and BE define the double token bucket sizes, and the action defines an action for conforming, exceeding, and optionally violating traffic.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-87
Class-based Policing Example
• The customer can locate his server at service provider premises (switched LAN) • CB-Policing is used to limit the amount of traffic the web server can generate (more flexible perbandwidth pricing) • Unknown traffic is rate-limited to 64 kbps to allow remote configuration of new servers © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-91
This example uses Class-based Polic ing to perform rate-limiting of end-station traffic. The example setting is a hosting-farm, where a service provider needs to limit the amount of traffic a web-server can send towards its clients. All traffic from a particular server will be rate-limited according to a contract, and 64 kbps of bandwidth will be reserved for unknown traffic, such as future provisioning and configuration of new servers in the farm.
9-88
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Policing Example class-map class-map www.acme.com www.acme.com match match source-address source-address mac mac 000d.dddf.0480 000d.dddf.0480 !! class-map class-map www.void.com www.void.com match match source-address source-address mac mac 000d.dddc.ad21 000d.dddc.ad21 !! policy-map policy-map ServerFarm class www.acme.com police police 128000 128000 conform-action conform-action transmit transmit exceed-action exceed-action drop class www.void.com police police 256000 256000 conform-action conform-action transmit transmit exceed-action exceed-action drop class class-default police 64000 !! interface interface FastEthernet FastEthernet 0/0 service-policy input ServerFarm !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-92
The configuration example shows three configured traffic classes, two based on upstream MAC addresses, and one on the default traffic class. Traffic from particular servers is policed to a fixed bandwidth, and exceeding traffic is dropped. If Bc and Be are not specified within the police command, the default value will be used.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-89
Monitoring and Troubleshooting CB-Policing Router #show policy Router#show policy interface interface fastethernet fastethernet 0/0 0/0 FastEthernet0/0 FastEthernet0/0 Service-policy input: ServerFarm (1207) Service-policy input: ServerFarm (1207) Class-map: Class-map: www.acme.com www.acme.com (match-all) (match-all) (1209/6) (1209/6) 00 packets, packets, 00 bytes bytes 55 minute minute offered offered rate rate 0 bps, bps, drop rate 0 bps Match: Match: ip ip precedence precedence 44 (1213) (1213) Match: Match: source-address source-address mac mac 000D.DDDF.0480 000D.DDDF.0480 (1217) (1217) police: police: 128000 128000 bps, bps, 4000 4000 limit, limit, 4000 4000 extended extended limit limit conformed conformed 00 packets, packets, 00 bytes; bytes; action: action: transmit transmit exceeded exceeded 00 packets, packets, 00 bytes; bytes; action: action: drop drop conformed 0 bps, exceed 0 bps violate 0 conformed 0 bps, exceed 0 bps violate 0 bps bps ... ... Class-map: Class-map: class-default class -default (match-any) (match-any) (1229/0) (1229/0) 00 packets, packets, 00 bytes bytes 55 minute offered rate 0 bps, drop rate 0 bps minute offered rate bps, Match: Match: any any (1233) (1233) police: police: 64000 64000 bps, bps, 2000 limit, 2000 extended limit conformed conformed 00 packets, packets, 00 bytes; bytes; action: action: transmit transmit exceeded exceeded 00 packets, packets, 00 bytes; bytes; action: action: drop drop conformed 0 bps, exceed 0 bps violate 0 conformed 0 bps, exceed 0 bps violate 0 bps bps ... ...
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-93
The show policy-map interface command displays all service policies applied to the interface. Among the settings, policing parameters and statistics are displayed. For the www.acme.com class, the CIR was set to 128000 bps, the BC defaults to 128000/32 or 4000 bytes and BE defaults to BC or 4000 bytes also.
9-90
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Summary n
Like CAR, Class-based Policing provides rate limiting of traffic
n
Class-based policing is integrated with CB-WFQ
n
Class-based policing uses a modified double token bucket mechanism for metering
Lesson Review 1. What do CAR and Class-based Policing do? 2. What are the main differences between CAR and Class-based Policing? 3. What marking options does Class-based Policing support? 4. What actions does do Class-based Policing support?
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-91
Class-based Shaping Overview This lesson describes the Class-based Shaping mechanism. The lesson also compares the Class-based Shaping implementation with the standalone GTS mechanism.
Objectives Upon completion of this lesson, you will be able to perform the following tasks:
9-92
n
Describe Class-based Shaping
n
Configure CB-Shaping
n
Monitor and troubleshoot CB-Shaping
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Shaping • Use of Class-based Shaping is similar to that of Class-based Policing • CB-Shaping is used to rate-limit packets • Delays exceeding packets rather than dropping them • Has no marking capabilities • CB-Shaping is a version of Generic Traffic Shaping (GTS) using the Modular QoS CLI
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-98
Class-based Shaping, like Class-based Policing, is used to rate-limit traffic within the CB-WFQ queueing system. Class-based Shaping works by metering the traffic rate and delaying excessive packets until they conform to the configured shaped rate. Class-based Shaping is very similar to Generic Traffic Shaping (GTS), but is implemented as a part of the CB-WFQ system and is configured via the Cisco IOS MQC. Like GTS, Class-based Shaping has no packet marking capability.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-93
CB-Shaping CB-Shaping
Check shaping queue N
Add tokens
Token Bucket
BC+BE
Enough Tokens?
Tokens
No
Do nothing
Yes
Packet size Shaping Queue N
packet
Forward
Queue N
• Router periodically updates the token bucket (every TC ) and checks if any packets can be forwarded to the main queue • T C = BC / BitRate © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-99
CB-Shaping uses the basic token bucket mechanism, where BC tokens are added at every TC time interval. If enough tokens are present in the bucket when a packet arrives, the packet is immediately forwarded. Otherwise, the packet is delayed in the shaping queue, until enough tokens are available. The router periodically checks the shaping queue by doing the following: 1. Add BC of tokens to the token bucket. 2. Check if there are enough tokens to forward a packet from the shaping queue to the main class queue. The size of the first packet in the shaping queue must be smaller or equal to the number of tokens in the token bucket. Repeat this step until there is no longer enough tokens to forward a packet or the shaping queue is empty. 3. If there are not enough tokens the router stops processing the shaping queue for another period of TC.
9-94
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Refilling the Token Bucket • CB-Shaping has two shaping methods: – Shaping to the configured average rate (adds B C tokens every TC) – Shaping to the peak rate (adds BC+B E tokens every TC)
• Average rate is forwarding packets at the configured average rate with allowed bursting up to B E when there are extra tokens available • Peak rate is forwarding packets at the peak rate which is calculated using this formula: PeakRate = AvgRate * (1+BE/BC) © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-100
Class-based Shaping can be configured in two different ways: n
Shaping to the average rate, which uses the normal token bucket refilling method, adding BC tokens every TC time interval
n
Shaping to the peak rate, which adds BC+BE tokens every TC time interval
Shaping to the average rate behaves like standard GTS; it establishes a long-term average rate, with bursts of up to BE allowed, when enough tokens are in the bucket. Shaping to the peak rate sends traffic at the peak rate, which is defined as the average rate, multiplied by (1+BE/BC). This translates to sending packets at the average rate of the excess burst size all the time, which may result in dropping in the WAN cloud.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-95
Configuring CB-Shaping Router(config-pmap-c)#
shape {average | peak} bit-rate [BCC [BEE]]
• BC and BE can be omitted to let the router select the optimal values Router(config-pmap-c)#
shape max-buffers queue-limit
• Set the maximum number of packets that can be stored in the shaping queue
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-101
The shape average and shape peak commands configure average and peak shaping respectively within the CB-WFQ system. The shape max-buffers command specifies the maximum size of the shaping queue. The shaping queue delays packets until they conform to the shaping rate. If the shaping queue is full, packets are tail-dropped.
9-96
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
CB-Shaping Frame Relay Adaptation Router(config-pmap-c)#
shape adaptive mir-rate
• Adapts the shaping rate when BECN bits are received • Each BECN bit causes the shaping rate to be reduced to three quarters of the previous rate but not below the min-rate • This command has effect only if used on Frame Relay interfaces Router(config-pmap-c)#
shape shape fecn-adapt fecn-adapt
• Responds to FECN bits by creating test frames in the opposite direction with the BECN bit set © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-102
Class-based Shaping is able to respond to Layer-2 congestion by reducing its shaping rate to three-quarters of the current rate, until the Layer-2 network recovers from congestion. When BECN flags are no longer received, the rate is slowly ramped up again to the original shaping rate. This is also a lower limit of rate reduction, which bounds the reduction process so that at least some throughput is maintained. The BECN-integrating functionality is performed on a per subinterface (DLCI) basis. The shape adaptive command configures the Class-based Shaping system to adapt the shaping rate to BECN indications, as described above. The min-rate parameter specifies the minimum shaping rate allowed. However, if the congestion was caused by simplex traffic (such as a multicast video stream) or by an aggressive TCP connection, it is expected that the reverse traffic (frames flowing from the receiver to the sender, marked with the BECN bit) might come by less frequently than required to feed the integration. So the receiving DTE (the receiving router) can help matters when it receives a message with FECN set by first checking to see if it has any data, and if it does not, originating a message with BECN set. This message might be a Q.922 TEST RESPONSE message, which would, by virtue of its message type, be understood to be a message to discard and not reply to. This feature is called FECN-to-BECN propagation. The shape fecn-adapt command configures the Class-based Shaping system to respond to FECN-marked frames with BECN TEST frames.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-97
CB-Shaping Example class-map class-map Shape Shape match match access-group access-group 123 123 !! policy-map policy-map ShapeAvg S hapeAvg class Shape Shape shape shape average 16000 16000 1024 1024 2048 !! policy-map policy-map ShapePeak S hapePeak class Shape Shape shape shape peak peak 16000 16000 1024 2048 !! interface interface Serial0/0 Serial0/0 service-policy service-policy output ShapeAvg !! interface interface Serial0/1 Serial0/1 service-policy service-policy output ShapePeak !! access-list access-list 123 permit udp any any
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-103
This figure shows an example configuration for Class-based Shaping. All UDP traffic is classified into one class, which is shaped differently on two interfaces. On the Serial0/0 interface, all UDP traffic is shaped to the average rate, while on the Serial0/1 interface, all UDP traffic is shaped to the peak rate.
9-98
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting CB-Shaping Router#show -map interface Router#show policy policy-map interface Serial0/0 Serial0/0 Service-policy Service-policy output: output: ShapeAvg Class-map: Class-map: Shape Shape (match-all) (match-all) 782 782 packets, packets, 728824 728824 bytes bytes 55 minute offered minute offered rate rate 24000 24000 bps, bps, drop drop rate rate 22000 22000 Match: Match: access-group access -group 123 123 Traffic Traffic Shaping Target Byte Sustain Excess Interval Target Byte Rate Limit bits/int Rate bits/int bits/int bits/int (ms) (ms) 16000 384 1024 2048 64 16000 384 1024 2048 64 Queue Queue Depth Depth 64 64
Packets Packets
Bytes Bytes
135 135
125820 125820
Packets Packets Delayed Delayed 134 134
bps bps
Increment Increment Adapt Adapt (bytes) Active (bytes) Active 128 -128
Bytes Bytes Delayed Delayed 124888 124888
Shapin Shapingg Active Active yes yes
Class-map: -default (match -any) Class-map: class class-default (match-any) 99 packets, packets, 3234 3234 bytes bytes 55 minute minute offered offered rate rate 0 bps, drop rate 0 bps Match: Match: any © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-104
The show policy-map interface command displays all service policies applied to the interface. Among the settings, shaping parameters and statistics are displayed.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-99
Summary n
Class-based Shaping rate-limits traffic by delaying it in a shaping queue
n
Class-based Shaping meters traffic like GTS, using a single token bucket
n
Class-based Shaping is integrated into the CB-WFQ queuing system, configured via the Cisco IOS MQC
Lesson Review 1. What are the main differences between CB-Policing and CB-Shaping? 2. What two shaping methods does CB-Shaping support?
9-100
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Marking Overview This lesson describes the Class-based Marking capability of the Cisco IOS Modular QoS CLI (MQC).
Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe Class-based Marking
n
Configure CB-Marking
n
Monitor and troubleshoot CB-Marking
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-101
Class-based Marking • Class-based Marking is an additional tool available with the Modular QoS CLI that allows static per-class marking of packets • It can be used to mark inbound or outbound packets • It can be combined with any other QoS feature on output • It can be combined with CB-Policing on input
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-109
Marking packets or frames lets you set information in the Layer 2, 3, or 4 headers, or even set information within the payload of a packet, so the packet or frame can be identified and distinguished from other packets or frames. The CB-WFQ queuing system provides packet marking capabilities, using Classbased Marking, which is configured within the Cisco IOS MQC feature. It is perhaps the most flexible IOS marking tool, extending the marking functionality of CAR and policy routing. Class-based Marking can be used on input or output of interfaces, as a part of an input or an output service policy. On input, Class-based Marking can be combined with Class-based Policing, and on output, with any other CB-WFQ QoS feature.
9-102
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Class-based Marking • Packets can be marked with one of the following markers: – IP Precedence – IP DSCP – QoS Group – MPLS Experimental bits – IEEE 802.1Q or ISL CoS/Priority bits – Frame Relay DE bit – ATM CLP bit
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-110
Class-based Marking supports the following markers: n
IP precedence
n
IP DSCP value
n
QoS group
n
MPLS experimental bits
n
ATM CLP bit
n
Frame Relay DE bit
n
IEEE 802.1Q or ISL CoS/priority bits
Class-based marking can be combined with other mechanisms available in the Modular QoS CLI.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-103
Configuring IP Precedence Marking Router(config-pmap-c)#
set ip precedence ip-precedence • Mark IP packets with the specified IP precedence value • IP precedence can be set using a value (0 to 7) or a corresponding name (e.g. routine, priority, immediate) policy-map policy-map SetPrec SetPrec class class Class1 Class1 set ip precedence priority class class Class2 Class2 set set ip ip precedence precedence flash flash class class Class3 Class3 set ip precedence 5 !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-111
IP precedence is encoded into the three high-order bits of the ToS field in the IP header. It supports eight classes of which two are reserved and should not be used for user-defined classes (IP precedence 6 and 7). IP precedence 0 is the default value and is usually used for the best-effort class. The set ip precedence command marks packets of a class with the specified precedence value.
9-104
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring IP DSCP Marking Router(config-pmap-c)#
set ip dscp dscp • Mark IP packets with the specified DSCP value • DSCP can be set using a value (0 to 63) or a corresponding name (e.g af11, af12, af13, af21, ef, cs1, default) policy-map policy-map SetDSCP SetDSCP class class Class1 Class1 set ip dscp af11 class class Class2 Class2 set ip dscp af21 class class Class3 Class3 set ip dscp ef !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-112
DiffServ is a new model that supercedes, and is backward compatible with, IP Precedence. DiffServ uses 6 prioritization bits, which permits classification of up to 64 values (0-63). A DiffServ value is called a Differentiated Services Code Point (DSCP). The set ip dscp command is used to mark packets of a class with a DSCP value.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-105
Configuring QoS Group Marking Router(config-pmap-c)#
set qos-group qos-group
• Mark packets with the specified QoS group value (0 to 99) policy-map policy-map SetQoS SetQoS class class Class1 Class1 set qos-group 1 class class Class2 Class2 set qos-group 2 class class Class3 Class3 set qos-group 3 !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-113
Class-based Marking can mark packets with the QoS group value. The QoS group is a parameter that is local to the router where it is set. It is not part of any header. It is usually set on an input interface and later examined (matched) on output interfaces. Once the packet is transmitted, the QoS-group information is lost, and the next router must reclassify and mark the packet. QoS group supports up to 100 distinct values (classes). The set qos-group command is used to set the QoS group value to a packet inside a router. Values from 0 to 99 can be used to mark packets.
9-106
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring MPLS Marking Router(config-pmap-c)#
set mpls experimental exp-bits
• Mark labeled packets with the specified value (0 to 7) • MPLS marking can only be used on input policy-map policy-map SetMPLS SetMPLS class class Class1 Class1 qos-group qos-group set mpls mpls experimental experimental class class Class2 Class2 qos-group qos-group set mpls mpls experimental experimental class class Class3 Class3 qos-group qos-group set mpls mpls experimental experimental !!
© 2001, Cisco Systems, Inc.
11 11 22 22 22 33
IP QoS Modular QoS CLI Service Policy-114
Cisco IOS also supports marking of MPLS frames, which is used to set MPLS CoS parameters. The three EXP(erimetal) bits inside the MPLS label are used, and the set mpls experimental command is used within the MQS to mark MPLS frames with CoS information. Values from 0 to 7 can be used to mark MPLS frames.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-107
Configuring LAN Marking Router(config-pmap-c)#
set cos cos • Mark frames with the specified value (0 to 7) • The value applies to the Class of Service bits with the IEEE 802.1Q encapsulation or Priority bits with the ISL encapsulation • The command can only be used on output LAN interfaces that are using one of the two mentioned encapsulations policy-map policy-map SetCoS SetCoS class class Class1 Class1 set cos 1 class class Class2 Class2 set cos 2 class class Class3 Class3 set cos 3 !! © 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-115
The IEEE 802.1p standard specifies a standard for delivering QoS in local area networks (LANs). Packets are marked with three CoS bits, where CoS values range from zero for low-priority to seven for high-priority. CoS can only be applied on trunks, because only there is an encapsulation available with space for the bits: n
Inter-Switch Link (ISL) frame headers have a 1-byte User field that carries the CoS value in the three least significant bits.
n
IEEE 802.1p and 802.1q frame headers have a 2-byte Tag Control Information field that carries the CoS value in the three most significant bits, which are called the User Priority bits.
Other frame types cannot carry CoS values. In general, Layer 2 switches can examine, use, or alter MAC layer markings, not IP precedence or DSCP settings, since those are Layer 3. Layer 2 markings are generally applied on egress trunk ports.
9-108
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Configuring Frame Relay DE Marking Router(config-pmap-c)#
set fr-de • Mark packets with the Frame Relay Discard Eligibility (DE) bit value 1 • Do not use the command to mark frames with the default value 0 • The command can only be used on output Frame Relay interfaces policy-map policy-map SetFR SetFR class class Class1 Class1 set fr-de fr-de class class Class2 Class2 class class Class3 Class3 set fr-de fr-de !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-116
The user can specify which Frame Relay packets have low priority or low time sensitivity and will be the first to be dropped when a Frame Relay switch is congested. The mechanism that allows a Frame Relay switch to identify such packets is the discard eligible (DE) bit. This bit is set for all packets of a class with the set fr-de command. This feature requires that the Frame Relay network be able to interpret the DE bit. Some networks take no action when the DE bit is set. Other networks use the DE bit to determine which packets to discard. The most desirable interpretation is to use the DE bit to determine which packets should be dropped first and also which packets have lower time sensitivity.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-109
Configuring ATM CLP Marking Router(config-pmap-c)#
set atm-clp • Mark cells of packets with the ATM Cell Loss Priority (CLP) bit value 1 • Do not use the command to mark cells with the default value 0 • The command can only be used on output ATM interfaces policy-map policy-map SetATM SetATM class class Class1 Class1 set atm-clp atm-clp class class Class2 Class2 class class Class3 Class3 set atm-clp atm-clp !!
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-117
The ATM CLP Setting feature somewhat allows users to extend their IP QoS policies into an ATM network by setting the ATM CLP bit in ATM cells based on the IP Precedence value of the packets being sent. As congestion occurs in the ATM network, cells with the CLP bit set are more likely to be dropped, resulting in improved network performance for high priority traffic and applications. The set atm-clp command marks packets of a class with the ATM CLP bit as a part of an input or output policy.
9-110
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting CB-Marking Router #show policy -map interface Router#show policy-map interface serial serial 0/0 0/0 Serial0/0 Serial0/0 Service-policy Service-policy input: input: SetMPLS SetMPLS (1837) (1837) Class-map: Class-map: Class1 Class1 (match-any) (match-any) (1839/12) (1839/12) 00 packets, packets, 00 bytes bytes 30 30 second second offered offered rate rate 00 bps, bps, drop drop rate rate 00 bps bps Match: Match: qos-group qos-group 11 (1843) (1843) 00 packets, packets, 0 0 bytes bytes 30 30 second second rate rate 00 bps bps QoS QoS Set Set mpls mpls experimental experimental 11 Class-map: Class-map: Class2 Class2 (match-any) (match-any) (1847/13) (1847/13) 00 packets, packets, 00 bytes bytes 30 30 second second offered offered rate rate 00 bps, bps, drop drop rate rate 00 bps bps Match: Match: qos-group qos-group 22 (1851) (1851) 00 packets, packets, 0 0 bytes bytes 30 30 second second rate rate 00 bps bps QoS Set QoS Set mpls mpls experimental experimental 22 ... ...
© 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy-118
The show policy-map interface command displays all service policies applied to the interface. Among the settings, marking parameters and statistics are displayed.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-111
MQC Compatibility Matrix CB QoS mechanism
Configuration command
Supported directions
Can be combined with the following Class--based mechanisms Class
WFQ
bandwidth
output
WRED, Shaping, Policing, Marking
LLQ LLQ WRED Policing Shaping Marking
priority random--detect random police shape set
output output input/output input/output output input/output input/output
Shaping, Policing, Marking WFQ, LLQ WRED, Shaping, WFQ, LLQ, Marking WRED, Policing, WFQ, WFQ, LLQ, LLQ, Marking Marking WRED, Policing, Shaping, WFQ, LLQ
Output
Classify
Mark
Police
Input
Classify
Mark
Police
© 2001, Cisco Systems, Inc.
Shape
WRED
Queue
Schedule
Forward
IP QoS Modular QoS CLI Service Policy-119
The figure shows the compatibility matrix of all QoS mechanisms within the CB-WFQ system that can be configured via the Cisco IOS MQC. Supported combinations of features are shown, as well as their processing sequence, and applicability on input and output interfaces.
9-112
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Summary n
Class-based Marking is the most flexible Cisco IOS marking tool
n
Class-based Marking is implemented as a part of the CB-WFQ system
n
Class-based Marking supports marking of IP packets and a variety of Layer-2 frames
Lesson Review 1. Which parameters can be set using CB-Marking? 2. Can CB-Marking be used on input? 3. Can CB-Marking be combined with any other QoS mechanisms?
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-113
Summary After completing this module, you should be able to perform the following tasks:
9-114
n
Describe the policy part of the Modular QoS CLI
n
Configure packet marking with modular CLI
n
Configure policing and shaping with modular CLI
n
Configure class-based WFQ with modular CLI
n
Configure congestion avoidance mechanisms (WRED) with modular CLI
n
Configure low-latency queuing
n
Monitor and troubleshoot policy maps
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Review Questions and Answers Service Policy Question: What are the benefits of using MQC? Answer: Template-based configuration; new classification options can be used with any MQC-based QoS mechanism. Question: How many classes can be used for one service policy? Answer: The MQC allows up to 256 classes to be defined. One service policy can use any number of classes. CB-WFQ is limited to 64 classes.
Class-based We ighted Fair Queuing Question: What type of guarantee does CB-WFQ provide? Answer: CB-WFQ provides bandwidth guarantees. Question: Which DiffServ PHB can be implemented using CB-WFQ? Answer: Assured Forwarding (AF) PHB can be implemented using CB-WFQ. Question: What configuration steps are needed to configure CB-WFQ? Answer: a. Create class maps for all classes that require individual bandwidth guarantees b. Create a policy map and specify the bandwidth for each class c. Apply the policy map to one or more interfaces where the same policy is needed
Class-based WRED Question: How does WRED supplement CB-WFQ? Answer: WRED is used to prevent congestion within a class queue. Question: Can WRED be combined with flow-based WFQ in the default class? Answer: Yes. Question: Which two operational modes does WRED support? Answer: IP-precedence-based and DSCP-based. Question: How many profiles does WRED support? Answer: 8 profiles for IP-precedence-based WRED and 64 profiles for DSCPbased WRED. Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-115
Class-based Low-latency Queuing Question: What advantages does CB-LLQ have over IP RTP Prioritization? Answer: CB-LLQ can use any classification supported by class maps. IP RTP Prioritization can only classify based on a range of UDP port numbers. Question: What guarantees does CB-LLQ provide? Answer: CB-LLQ provides a bandwidth guarantee and minimum-delay forwarding of packets.
Class-based Policing Question: What do CAR and Class-based Policing do? Answer: CAR and Class-based policing are primarily used to limit the rate of a traffic cla ss by dropping excess packets.
Question: What are the main differences between CAR and Class-based Policing? Answer: Class-based Policing uses the MQC and supports three different actions (confirm, exceed and violate).
Question: What marking options does Class-based Policing support? Answer: IP precedence, DSCP, MPLS experimental bits, QoS group, Frame Relay DE bit, ATM CLP bit.
Question: What actions does do Class-based Policing support? Answer: CB-Policing supports the following actions: transmit, drop and set (marker). A different action can be used depending on whether a packet conforms, exceeds or violates the policy.
Class-based Shaping Question: What are the main differences between CB-Policing and CB-Shaping? Answer: CB-Shaping polices bandwidth by delaying exceeding packets instead of dropping them. Question: What two shaping methods does CB-Shaping support? Answer: CB-Shaping supports shaping to average or peak rate.
Class-based Marking
Question: Which parameters can be set using CB-Marking? Answer: CB-Marking can mark packets with the following markers: IP Precedence, IP DSCP, QoS Group, MPLS Experimental bits, IEEE 802.1Q or ISL CoS/Priority bits, Frame Relay DE bit, ATM CLP bit 9-116
IP QoS Modular QoS CLI Service Policy
Copyright 2001, Cisco Systems, Inc.
Question: Can CB-Marking be used on input? Answer: Yes. Question: Can CB-Marking be combined with any other QoS mechanisms? Answer: Yes. CB-Marking can be combined with WRED, Policing, Shaping, WFQ, LLQ.
Copyright 2001, Cisco Systems, Inc.
IP QoS Modular QoS CLI Service Policy
9-117
10
IP over ATM
Overview This module focuses on IP QoS mechanisms that can be used on ATM interfaces. It includes the following topics: n
Introduction to IP over ATM
n
Per-VC WRED
n
VC Bundling
n
Per-VC CB-WFQ
n
RSVP to SVC Mapping
Objectives Upon completion of this module, you will be able to perform the following tasks: n
List the requirements of IP QoS in combination with ATM QoS
n
Describe the hardware and software requirements for advanced IP QoS mechanisms on ATM interfaces
n
Describe per-VC queuing
n
Describe and configure per-VC WRED
n
Describe and configure VC bundling
n
Describe and configure per-VC CB-WFQ
n
Describe RSVP to SVC mapping
n
Monitor and troubleshoot IP QoS on ATM interfaces
Introduction to IP over ATM Objectives Upon completion of this lesson, you will be able to perform the following tasks:
10-2
IP QoS IP over ATM
n
Describe the QoS-related problems when using ATM networks
n
Describe the hardware and software requirements for advanced IP QoS mechanisms on ATM interfaces
n
Describe per-VC queuing
Copyright 2001, Cisco Systems, Inc.
IP vs. ATM Technology comparison IP
ATM
• Connectionless
• Connection oriented
• Per-packet QoS (IP precedence)
• Per-connection (virtual circuit) QoS
• Small number of service classes
• Large number of QoS traffic classes (CBR, VBR, UBR, ABR)
• IP precedence or DSCP does not encode service parameters
© 2001, Cisco Systems, Inc.
• Rich traffic parameters (PCR, MCR, SCR ...) specified for each VC
IP QoS IP over ATM-5
The Internet Protocol (IP) is a routed protocol that is used to transmit data in packets. It uses the best-effort delivery for individual packets without any flow control. Transmission Control Protocol (TCP) is used with IP to provide a connection-oriented service. Asynchronous Transfer Mode (ATM), on the other hand, provides connections between endpoints in the ATM network. The connections are called virtual circuits (VCs). IP’s default best effort service can be supplemented by differentiated quality of service based on IP precedence or DSCP marking. A QoS solution using IP precedence is limited to 8 classes, 2 of which are reserved and 1 should be used for the default best-effort class. A QoS solution using DSCP scales up to 64 classes. ATM provides a wider range of services: n
Constant Bit Rate (CBR) is useful for delay-sensitive applications such as voice. This service provides bandwidth and delay guarantees.
n
Variable Bit Rate—Real Time (VBR-RT) is useful for burstier delay-sensitive applications. This service provides bandwidth and delay guarantees.
n
Variable Bit Rate—Non Real Time (VBR-NRT) is useful for bursty traffic. This service provides bandwidth guarantees.
n
Available Bit Rate (ABR) is useful for best-effort traffic that is allowed more bandwidth, when available or configured. This service provides bandwidth guarantees and access to extra bandwidth.
n
Unspecified Bit Rate is useful for the real best effort where there are no guarantees.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-3
IP’s IP precedence or DSCP are only used to mark packets. They do not include any service parameters. Servic e parameters depend on the QoS mechanism being deployed. ATM’s services also include various per-connection service parameters, such as: n
Sustained Cell Rate (SCR) for CBR, VBR and ABR services
n
Minimum Cell Rate (MIR) for ABR
n
Peak Cell Rate (PCR) for VBR, ABR and UBR services
n
Maximum Burst Size (MBS)
Both IP and ATM can implement Quality of Service (QoS). The decision on which technology to use for quality of service should be based on a number of factors, such as: n
Availability of ATM
n
Interaction between ATM and IP
n
Scalability options of the technology
n
Performance limitations
This module introduces the possibilities of combining IP QoS with ATM.
10-4
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Integrating IP and ATM • Overlay model (ATM forum) – ATM VC’s are manually established between pairs of devices – IP packets are sent across these VC’s – ATM switches are not IP aware
• Peer model (MPLS) – ATM switches are IP aware on control (but not data) plane – ATM VC’s are established on-demand based on IP routing tables
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-6
There are two main approaches to integration of IP with/over ATM: n
The traditional way (overlay model) is to use individual permanent virtual circuits (PVC) to establish point-to-point adjacencies between IP routers. IP routing protocols are used to provide reachability across a network of ATM connections. ATM has no knowledge of IP and cannot use IP information to optimize its links.
n
The newer approach (MPLS) is to make ATM switches IP aware. ATM switches run an IP routing protocol to establish virtual circuits.
This module focuses on the QoS available with traditional permanent and switched virtual circuits (PVCs and SVCs). The IP QoS- IP over MPLS module discusses QoS possibilities when using the peer model.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-5
IP QoS and ATM • Routers can be interconnected over an ATM backbone using different ATM services: – UBR – congestion management is virtually impossible because routers are allowed to transmit packets at line speed – VBR – congestion management is easier, but it requires conservative setting of transmit rates – CBR – similar to VBR from IP perspective – ABR – pushes congestion back to the source, requires dynamic adjustment to available bandwidth
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-7
Achieving good quality of service for IP classes greatly depends on the type of ATM network and services used.
10-6
IP QoS IP over ATM
n
Using UBR, prevents routers from detecting congestion in the network. It is therefore difficult to manage congestion based on IP precedence or DSCP. The reason for this is because all packet drops happen on the congested link somewhere in the ATM network.
n
VBR makes it easier to push congestion back to the source where it can be managed by routers.
n
CBR is typically used for non-bursty delay sensitive traffic. It is therefore more important to prevent congestion by correctly provisioning the class that is using CBR.
n
ABR is a good solution where bandwidth can be utilized to the maximum without having many drops in the ATM network.
Copyright 2001, Cisco Systems, Inc.
UBR Virtual Circuits Random CLP marking
No congestion Router allowed to send at full speed
Unintelligent drops based on CLP
Congestion
• Solution: – Set CLP on the router based on IP information to minimize the effect of cell drops © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-8
A solution using UBR can be improved in terms of IP QoS, by marking less important packets with the CLP bit for congestion control. In case of congestion, the ATM switches will drop the less important packets to give more bandwidth for the higher-priority packets. The ATM FORUM also calls the UBR service category a “best effort” service, which requires neither tightly constrained delay nor delay variation. In fact, UBR provides no specific quality of service or guarantee throughput whatsoever. This traffic is therefore “at risk” since the network provides no performance guarantees for UBR traffic. The Internet and Local Area Networks are examples of this type of “best effort” delivery performance. Examples of this are LAN emulation (LANE), IP over ATM, and non-mission-critical traffic. This solution is fairly limited, since it allows for only two classes on the IP layer where congestion should be managed.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-7
VBR Virtual Circuits Congestion!
Router is sending at configured rate
Unintelligent random drops
Congestion is possible
• Solution: – Set CLP on the router based on IP information – Use available IP QoS mechanisms to manage congestion at the source © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-9
A solution using VBR is better at providing feedback to routers sending cells into the ATM network. Congestion will occur on a router’s virtual circuit, where it can be managed by using the QoS mechanisms available in the Cisco IOS software. CLP marking can be used for less-important packets or for those packets above the Sustained Cell Rate (SCR) to improve the chances for higher-priority packets when congestion occurs in the ATM network. The rt-VBR service category supports time-sensitive applications, which also requires constrained delay and delay variation requirements, but which transmit at a time varying rate constrained to a PCR, SCR, and MBS define a traffic contract in terms of the worst-case source traffic pattern for which the network guarantees a specified QOS. Examples of such bursty, delay-variation-sensitive sources are voice and variable -bit-rate video. The nrt-VBR service category supports applications that have no constraints on delay and delay variations, but which still have variable -rate, bursty traffic characteristics. This class of application expects a low Cell Loss Ratio (CLR). The traffic contract is the same as that for rt-VBR. Applications include packet data transfers, terminal sessions, and file transfers. Networks may statistically multiplex these VBR sources effectively.
10-8
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
CBR and ABR Virtual Circuits Congestion!
Router is sending at configured rate.
• Solution: – Use available IP QoS mechanism to handle congestion at the source © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-10
CBR virtual circuits, are used for delay-sensitive traffic. This traffic should not experience congestion due to keeping the quality of data being transmitted. If congestion occurs, it can be managed by the IP layer using the IP QoS mechanisms on the router’s ATM interface. The CBR service category supports real-time applications requiring a fixed amount of capacity defined by the PCR. CBR supports tightly constrained variations in delay. Example applications are voice, constant-bit-rate video, and Circuit Emulation Services (CES). Normally, networks must allocate the peak rate to these types of source. The ABR service category works in cooperation with sources that can change their transmission rate in response to rate-based network feedback used in the context of closed-loop flow control. The aim of ABR service is to dynamically provide access to capacity currently not in use by other service categories to users who can adjust their transmission rate in response to feedback. In exchange for this cooperation by the user, the network provides a service with very low loss. Applications specify a maximum transmit-rate (PCR_ and the minimum required rate, called the Minimum Cell Rate (MCR). ABR service does not provide bounded delay variation; hence real-time applications are for ABR are LAN interconnection, high-performance file transfers, database archival, non-timesensitive traffic, and web browsing.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-9
Congestion Management in ATM Networks • Congestion management on routers should be performed on a per-VC basis • Design options: – Make sure there is no congestion in the ATM network (ABR, CBR, VBR) and use IP QoS mechanisms at the source (CB-WFQ, WRED) – Mark less important packets with the CLP bit in case there is congestion in the ATM network (CBPolicing, CB-Marking) – Use multiple parallel (per-CoS) virtual circuits with ATM QoS (VC Bundling)
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-11
This module discusses three different approaches to designing QoS in IP networks on ATM:
10-10
IP QoS IP over ATM
1.
Using IP QoS mechanisms to ensure there is no congestion in the AMT network
2.
Using ATM QoS mechanisms with IP precedence used for classification (VC Bundling)
3.
Combining both IP and ATM QoS mechanisms
Copyright 2001, Cisco Systems, Inc.
Per-VC Queuing VIP Memory
ATM Port Adapter
Frame queue VC 1/50
Cell queue VC 1/50
Frame queue VC 1/64
Cell queue VC 1/64
Frame queue VC 1/76
Cell queue VC 1/76
Frame queue VC 1/39
Cell queue VC 1/39
ATM interface VC 1/50 VC 1/64 VC 1/76 VC 1/39
ATM hardware shaping
Per-VC queuing with per-VC congestion management
• Per-VC queuing is required in order to handle congestion on per-VC basis • Per-VC queuing prevents head-of-line blocking by slow virtual circuits © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-12
One of the most important parts of implementing QoS is to make ATM virtual circuits appear as physical interfaces on routers; that is, each VC must have its own queue (per-VC queuing). Per-VC queuing prevents one congested VC from slowing down other VCs (head-of-line blocking). Per-VC queuing can then be supplemented by various IP QoS mechanisms, such as: n
WRED
n
CAR
n
CB-WFQ
n
CB-LLQ
n
CB-Policing
n
CB-Shaping
n
CB-Marking
CB-Marking and CB-Policing can also be used to set the CLP bit.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-11
Summary The following steps have to be taken prior to the designing of a QoS solution for IP over ATM: n
Implement Per-VC queuing (to prevent head-of-line blocking and allow for IP QoS mechanisms to be implemented on individual virtual circuits)
n
Decide on the technology that will be used to implement QoS
Review Questions Answer the following questions: 1. What are the main differences between IP and ATM? 2. Which QoS services does ATM support? 3. How should congestion be handled when an ATM backbone is used? 4. Why is per-VC queuing so important?
10-12
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-VC WRED Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe per-VC WRED
n
Configure per-VC WRED
n
Monitor and troubleshoot per-VC WRED
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-13
Per-VC WRED • Single ATM VC is established over an ATM cloud between a pair of routers – ABR, VBR, UBR or CBR – Using UBR will not result in proper operation, as there is no ATM shaping in UBR
• All IP traffic toward a next-hop router is forwarded across a single ATM VC • Congestion is managed entirely on the IP layer using WRED on each individual ATM VC, resulting in differentiated IP services
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-17
A simple addition to best-effort service on ATM interfaces is Weighted Random Early Detection (WRED). WRED is most efficient when the majority of the traffic is TCP (TCP reacts to random drops and slows down the transmission rate). With other protocols, packet sources may not respond or may resend dropped packets at the same rate. Thus, dropping packets does not decrease congestion. WRED treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP traffic is more likely to be dropped than IP traffic UBR would probably result in congestion somewhere in the ATM network, thus preventing any intelligent congestion management on the IP layer. Any other ATM service (CBR, VBR or ABR) will push congestion back to the source where WRED can be used to drop packets based on the IP precedence or DSCP value.
10-14
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-VC WRED : Intelligent IP Packet Discard Traffic Shaping
Threshold Exceeded VIP2-50
PA-A3-XX VC1 VC2
VC3
Per-VC WRED: Intelligent Discard © 2001, Cisco Systems, Inc.
Per-VC Queues
No discard on PA
IP QoS IP over ATM-18
Per-VC queuing requires an Enhanced ATM Port Adapter that support up to 4096 cell queues. Each virtual circuit is assigned a queue and the ATM scheduler forwards cells according to the ATM service and shaping parameters. The router (or VIP on Cisco 7x00 series routers) also assigns one queue per virtual circuit. Cell departure is shaped if ABR, VBR or CBR services are used, thus causing congestion in the frame queue if packet arrival is greater than the shaping rate in ATM. Per-VC WRED can be used to manage congestion within individual queues (classes).
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-15
Configuring Configuring Per-VC WRED • The following configuration steps are needed to enable per-VC WRED: – Create a Random-Detect-Group template with a WRED profile – Apply the WRED template to an ATM interface or to individual ATM VCs – Verify and monitor the operation of per-VC WRED
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-19
Applying WRED to individual VCs is slightly different than applying WRED to interfaces. A Random Detect Group must be created if non-default WRED profiles need to be used on VCs. Standard WRED parameters (per-precedence minimum threshold, maximum threshold and maximum drop probability) are set in the random-detect-group configuration mode.
10-16
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Create and configure RED-group Router(config)# random-detect-group name name
• Creates a WRED template Router(cfg-red-group)# exponential-weighting-constant exponential-weighting-constant exp
• Defines WRED weighting constant • Default: 9 Router(cfg-red-group)# precedence precedence IP-prec min-threshold max-threshold max-threshold prob-denominator
• Defines RED profile for specified precedence • Default: as with per-interface WRED © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-20
The random-detect-group global configuration command creates a WRED profile and enters the red-group configuration mode. WRED per-precedence profiles are configured in the red-group configuration mode, using similar commands as with per-interface WRED, except the commands are not preceded by the random-detect keyword. Any class (IP precedence) can be configured with a RED profile different from the default by using the precedence command in the red-group configuration mode: n
Minimum threshold—When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold.
n
Maximum threshold—When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.
n
Mark probability denominator—This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
WRED does not calculate the drop probability using the current queue length, but instead uses the average queue length. The average queue length is constantly recalculated, using two terms: n
The previously calculated average queue size
n
The current queue size
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-17
An exponential weighting constant N influences the calculation by weighing the two terms. It therefore influences how the average queue size follows the current queue size, in the following way: n
A low value of N makes the current queue size more significant in the new average size calculation, therefore allowing larger bursts
n
A high value of N makes the previous average queue size more significant in the new average size calculation, so that bursts influence the new value to a smaller degree
The default value is 9 and should suffice for most scenarios, except perhaps those involving extremely high-speed interfaces (such as OC12), where it can be increased slightly (to about 12) to allow more bursts. Note
10-18
IP QoS IP over ATM
The default WRED parameter values are based on the best available data. Cisco recommends that you do not change the parameters from their default values unless you have determined that your applications will benefit from the changed values.
Copyright 2001, Cisco Systems, Inc.
Apply WRED group to an ATM PVC Router(config-if-atm-vc)#
random-detect random-detect [attach [attach random-detect-group] random-detect-group]
• Enables WRED on a PVC using the selected WRED profile • Default WRED parameters are used if the group name is omitted or refers to non-existent group • Default: no WRED is used on the ATM PVC
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-21
The last step in the configuration of per-VC WRED is to attach a random-detectgroup to a virtual circuit. The random-detect command is used in the VC configuration mode to enable WRED. If no random-detect-group is specified WRED will use the default WRED profiles.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-19
Monitoring and Troubleshooting Per-VC WRED Router# show show queueing random-detect random-detect [interface [interface intf [vc vpi vci vci ]] ]]
• Displays WRED parameters for an ATM (sub)interface or for individual VC
Router# show show queueing interface interface interface [vc vpi vpi vci] vci]
• Displays interface queues or individual per-VC queue
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-22
The show queuing random-detect command display WRED parameters and statistics for a specific interface or virtual circuit. There is only a single queue into which packets from all IP precedences are placed after dropping has taken place. The show queuing interface command displays per-VC queue parameters and statistics. The “Queuing strategy” reported by the command lists “random early detection (RED)” as the queuing mechanism. The default minimum thresholds are spaced evenly between half and the entire maximum threshold. Thresholds are specified in terms of packet count.
10-20
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
WRED Case Study • WRED is applied to a ATM PVCs in a network with the following IP precedence definitions IP prec. 0 1 2 3 4 5 6 7
Meaning High-loss best-effort traffic Low-loss best-effort traffic Premium traffic outside of the contract Premium traffic in the contract Unused Voice-over-IP Routing protocol traffic Routing protocol traffic
• WRED queue length is 100 packets for PVCs with SCR > 10 Mbps and 40 packets for slower PVCs
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-23
The case study shows a QoS design where packets are classified into three user classes: n
Best-effort class
n
Premium class
n
Voice class
The Best-effort and Premium classes use two IP precedence values to mark high-drop (out-of-contract) traffic and low-drop (within contract) traffic. IP precedence values 6 and 7 are reserved for control messages (for example, routing protocols) and should not be used for user traffic. The design lists these two additional requirements: n
Virtual circuits faster than 10Mbps should have queues that can hold up to 100 packets
n
Slower virtual circuits can store up to 40 packets in the queue
All virtual circuits should manage congestion by using WRED.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-21
Packet Discard Probability
Case Study WRED Profile
VoIP
Precedence 3
Routing
Precedence 1
0.1
Precedence 2 Precedence 0
RSVP
37
35
30
25
20
15
10
© 2001, Cisco Systems, Inc.
Average Queue Size
IP QoS IP over ATM-24
The figure illustrates the WRED parameters that should be implemented for fast and slow virtual circuits. The minimum and maximum thresholds should reflect a different maximum queue size for fast VCs (100 instead of 40). High drop Best-effort and Premium packets start being dropped when the average queue size reaches 10 or 15 respectively (25 or 37 on fast VCs). If the queue still grows the low-drop Best-effort packets start being dropped when the queue size reaches 20 (50 on fast VCs). High drop packets, of course, are more aggressively dropped than low-drop packets. Control packets, VoIP packets and packets of RSVP flows are only dropped in extreme situations when the average queue size is close to the maximum (40 for slow VCs and 100 for fast VCs).
10-22
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Router Configuration • Step #1 - configure WRED profile for slow PVCs random-detect-group random-detect-group slow-wred-profile slow-wred-profile precedence 0 10 25 10 precedence 1 20 40 10 precedence 2 15 25 10 precedence 3 25 40 10 precedence 1 10 10 precedence 44 precedence 5 35 40 10 precedence 6 30 40 10 precedence 7 30 40 10
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-25
The figure shows the configuration of WRED profiles used for slow VCs.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-23
Router Configuration • Step #2 - configure WRED profile for fast PVCs random-detect-group random-detect-group fast-wred-profile fast-wred-profile precedence 25 precedence 00 25 62 62 10 10 precedence 50 precedence 11 50 100 100 10 10 precedence 37 precedence 22 37 62 62 10 10 precedence 62 precedence 33 62 100 100 10 10 precedence 87 precedence 55 87 100 100 10 10 precedence 1 10 10 precedence 44 precedence 75 precedence 66 75 100 100 10 10 precedence 75 precedence 77 75 100 100 10 10
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-26
The figure shows the configuration of WRED profiles used for fast VCs. Note
10-24
IP QoS IP over ATM
This configuration simply uses scaled thresholds to support up to 100 packets in the queue.
Copyright 2001, Cisco Systems, Inc.
Router Configuration • Step #3 - Apply WRED profile on various PVCs interface interface ATM11/0/0 ATM11/0/0 ip address 17.1.0.1 17.1.0.1 255.255.255.0 255.255.255.0 atm pvc pvc 50 0 50 aal5snap 25000 50000 10 inarp inarp random-detect random-detect fast-wred-profile fast-wred-profile !! interface interface ATM11/0/0.100 ATM11/0/0.100 point-to-point ip address 17.1.1.1 255.255.255.252 atm pvc pvc 100 100 0 100 aal5snap 17000 34000 10 inarp inarp random-detect random-detect fast-wred-profile fast-wred-profile !! interface interface ATM11/0/0.101 ATM11/0/0.101 point-to-point ip address 17.1.1.5 255.255.255.252 atm atm pvc 101 101 55 101 101 aal5snap aal5snap 2000 2000 4000 4000 10 10 inarp random-detect random-detect slow-wred-profile slow-wred-profile
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-27
The figure shows the configuration of three virtual circuits. Two are using the WRED profile for fast VCs and the third is using the WRED profile for slow VCs.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-25
Summary Weighted Random Early Detection (WRED) is one of the IP QoS mechanisms that can be applied to individual virtual circuits. A Random Detect Group is used to configure a WRED profile that is attached to individual VCs using the random-detect command in the VC configuration mode.
Review Questions Answer the following questions: 1. What are the benefits of per-VC WRED? 2. What are the configuration steps needed to enable per-VC WRED?
10-26
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Bundling Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe VC bundling
n
Configure VC bundling
n
Monitor and troubleshoot VC bundling
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-27
VC Bundling • VC Bundling is a solution where ATM QoS mechanisms are used • Classes of Service are identified by IP precedence • Each VC uses an ATM service based on the requirements of the class • Routers automatically map packets in VCs based on their IP precedence value • Multiple parallel VCs are needed for each IP adjacency © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-32
VC Bundling is a solution where the task of providing differentiated quality of service is offloaded to the ATM switches. Classes are identified by using IP precedence values. The routers then perform classification based on IP precedence values. Up to eight parallel virtual circuits can be used for one IP adjacency. Appropriate ATM services are used for each IP precedence value, depending on the QoS requirements and provisioning. An IP precedence value or a range of IP precedence values are mapped to one virtual circuit. Non-contiguous IP precedence ranges are not supported.
10-28
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Bundling Case Study ATM VC ATM VC type Control VC (routing updates) VBR Voice CBR VPN traffic VBR Premium Internet traffic VBR Best-effort Internet traffic ABR
IP prec. 6-7 5 4 2-3 0-1
Control (routing) Voice VPN traffic Premium Internet Best-effort Internet
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-33
The figure illustrates a case study where there are four user classes and one class for control traffic. Routers perform classification based on IP precedence values: n
IP precedence 6 and 7 traffic is forwarded through the Control VC
n
IP precedence 5 traffic is forwarded through the Voice VC
n
IP precedence 4 traffic is forwarded through the VPN VC
n
IP precedence 2 and 3 traffic is forwarded through the Premium VC
n
IP precedence 0 and 1 traffic is forwarded through the Best-effort VC
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-29
VC Bundling Routing Adjacency
Routing protocol packets are exchanged over control VC as they are sent with IP precedence 6 Control (routing) Voice VPN traffic Premium Internet Each VC has its own HW queue in the Best-effort Internet router, managed with WRED Whole bundle is treated as one routing adjacency and is covered by a single ATM map
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-34
All five classes are separated in the ATM network and receive different quality of service. Routers have to perform per-VC queuing to prevent head-of-line blocking. All five virtual circuits, though, appear as one single point-to-point link on the IP layer.
10-30
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Provisioning • VCs are dimensioned based on expected load for the precedence(s) level transported on that VC • More isolation between classes • At the expense of – less statistical multiplexing, – more complex provisioning/engineering
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-35
VC Bundling provides an efficient utilization of QoS capabilities provided by ATM. IP classes are effectively isolated by being transported over different virtual circuits. The drawbacks of this approach are: n
Less statistical multiplexing. One class cannot use another class’s bandwidth (unless ABR is used).
n
More complex provisioning. Each IP adjacency, which normally requires one point-to-point virtual circuit, now requires multiple virtual circuits of different types and QoS.
As much as IP QoS is simplified to classification and marking using IP precedence, ATM QoS is more complex because there are up to eight times more virtual circuits to be configured.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-31
VC Bundle Management • Integrity of each individual VC is verified with end-to-end OAM cells
Control (routing) Voice VPN traffic Premium Internet Best-effort Internet
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-36
Most Layer-2 technologies include some type of link management. Keepalive frames are typically used as a last resort to determine if end-to-end connectivity works. For example: n
HDLC and PPP use link-level keepalive frames to determine if the link is operational.
n
Frame Relay uses keepalive frames to determine if the link between a router and a switch is operational. Frame Relay can also have end-to-end keepalive messages to determine if the virtual circuit is operational.
n
ATM uses two types of Operation Administration and Maintenance (OAM) cells to determine if link-level and end-to-end connectivity works.
VC bundling is more complex since there are multiple parallel virtual circuits used for one single IP adjacency. The question is: what should happen if only one VC goes down?
10-32
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Bundle Management
Control (routing) Voice VPN traffic
Best-effort Internet Two ways of handling loss of VC in the bundle: • The whole bundle is declared down • Traffic from the lost VC is bumped onto another VC • IP routing model does not allow the traffic for a single precedence value to be rerouted over another path © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-37
There are two possible ways of handling lost VCs: n
All VCs are declared inactive
n
The traffic for the lost VC is rerouted onto another VC within the same bundle
IP forwarding decisions are based solely on the destination address and cannot reroute packets based on their IP precedence values.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-33
VC Bumping • VC bumping = possibility for a traffic mapped to VC X to be forwarded onto another VC Y, in case of failure of X • Traffic can be bumped based on implicit or explicit rules • Individual VC or a group of VCs can be protected
Keep All Graphics Inside This Box © 2001, Cisco Systems, Inc.
10-34
IP QoS IP over ATM
www.cisco.com
Course acronym 2.0 —Chapter#-38
n
VC bumping is one approach to handling lost VCs. If one of the VCs goes down the traffic from that VC is forwarded through another VC in the same bundle.
n
Implicit bumping is the default behavior where packets are forwarded through the first available VC of a lower IP precedence value.
n
Explicit bumping requires manual configuration where the IP precedence of a backup VC is set.
Copyright 2001, Cisco Systems, Inc.
Implicit Bumping
Control (routing) Voice VPN traffic
Best-effort Internet
• Traffic from the lost VC is bumped onto the VC carrying traffic with the next lower precedence © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-39
The figure illustrates how routers automatically reroute Premium traffic to the first VC with a lower IP precedence value (Best-effort in the example).
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-35
Reject Bumping
Voice
Rejects bumping
VPN traffic Premium Internet Best-effort Internet
• Problem: Control traffic shall not be bumped onto voice VC (implicit rule) • Solution #1: Voice VC can reject bumping, bumped traffic goes to next lower VC © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-40
Some virtual circuits can be configured to reject bumped traffic. The figure illustrates how the Voice VC rejects bumped traffic (mixing delay sensitive, well-provisioned traffic with other types of packets is not desired and should be prevented). Implicit bumping searches down the “ladder” for the first available VC (it has to be operational and accept bumped traffic).
10-36
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Explicit Bumping
Bump explicitely to precedence 0
Voice VPN traffic Premium Internet Best-effort Internet
• Problem: Control traffic shall not be bumped onto voice VC (implicit rule) • Solution #2: Specify explicitely onto which VC the traffic will be bumped © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-41
Another approach is to explicitly set the backup VC. The Control VC in the figure was configured to use the Best-effort VC as backup.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-37
Bundle Failure Scenarios When a bundle is declared down, no traffic is forwarded out of the bundle, even if some VCs are still up (routing) Control Voice VPN traffic Premium Internet Whole bundle is lost
Precedence 0 traffic cannot be implicitly bumped
• Problem: under default settings, the whole bundle is declared down if the lowest-precedence VC is lost • Solution: be sure that the lowest-precedence VC is always bumped via explicit bumping rule © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-42
In this figure the VC used for IP precedence 0 does not have a lower-precedence VC to be used as backup. It is recommended to use explicit bumping for this VC.
10-38
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Protected VC
Control (routing) Voice VC is protected VC
VPN traffic Premium Internet Whole bundle is lost
Best-effort Internet
• Problem: voice traffic shall not be bumped onto data VC • Solution: failure of protected VC brings down the whole bundle, IP routing will find alternate path © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-43
Some VCs have special QoS requirements that cannot be accommodated by any other VC. The Voice VC in the figure cannot be bumped to any other VC because the voice quality would no longer meet the requirements. It is better to declare the entire bundle down and let the IP routing protocol find another path where guarantees can be met. Classes that under no circumstances should be mixed with other classes should reject bumped traffic (if a higher-precedence VC fails) and be protected (if their VC fails).
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-39
Protected group
Control (routing) Voice
Whole bundle is lost
All VCs in the protected group are lost
• Problem: if most of the VC’s are lost, it does not make sense to bump traffic onto low-volume VC’s • Solution: failure of all VC’s in a protected group will bring down the bundle © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-44
One group of VCs can be protected in a way where the bundle is declared down but only if all of the VCs in the group fail.
10-40
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Bumping – Final Details • If the VC which carries the bumped traffic fails, the traffic will follow the bumping rules specified for that VC • Traffic is restored to the original VC when that VC becomes operational
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-45
To summarize bumping: n
Default implicit bumping is used to find the first-lower precedence VC that accepts bumped traffic and is operational.
n
Explicit bumping can be used to select the backup VC. If the backup VC is down, that VC’s rules are used to find the backup of the backup VC.
n
Individual VCs can be configured to reject bumped traffic. Bumped traffic will skip such VCs.
n
An individual VC can be protected. If a protected VC fails the entire bundle is declared down.
n
A collection of VCs can belong to a protected group. If all VCs in the protected group fail the entire bundle is declared down.
Traffic is restored to the original VC the moment it becomes operational.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-41
Configuring VC Bundling • Configuration steps: – Configure ATM interface – Configure VC bundle – Configure individual VC in the bundle – Optionally use VC-class object as VC parameter template
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-46
The following configuration steps are needed to enable VC Bundling:
10-42
Step 1
Configure interface-wide parameters on an ATM interface
Step 2
Create a VC bundle
Step 3
Create up to eight VCs as members of the bundle
Step 4
Optionally, use the VC-class object as a template for bundle or VC configuration
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Bundle Parameters • Parameters configurable on the VC bundle or vc-class applied to the bundle – Layer-3 ATM maps – Encapsulation – Broadcast propagation – ATM Inverse ARP – OAM management – Global bumping rules
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-47
The figure lists the parameters that can be set on a bundle or a vc-class template. Individual member VCs inherits the parameters if they are not overridden in the VC configuration.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-43
Individual VC Parameters • Parameters configurable on individual VC in the bundle (or vc-class) – IP precedence mapping – VC protection mode – VC bumping rules – ATM VC mode and ATM QoS parameters – WRED group
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-48
Individual VC parameters can be inherited from a vc-class configured on the bundle, the bundle, or a vc-class configured on the VC. Parameters configured on the VC override all inherited parameters.
10-44
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Configuring Bundle-wide VC Class Router(config)#
class-vc class-vc vc-class-name vc-class-name oam-bundle oam-bundle [manage] [frequency] [frequency] bump bump {implicit {implicit | explicit precedence-level precedence-level | traffic} encapsulation encapsulation atm-encap atm-encap protocol protocol atm-map-parameters … [no] [no] broadcast broadcast inarp inarp timeout timeout
• Configures all parameters that can be specified on an ATM VC bundle in a VC class
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-49
Use the class-vc global configuration command to create a template used to configure common parameters on ATM interfaces, bundles or individual virtual circuits. VC classes can contain ATM specific configuration commands as well as commands used for VC Bundle management.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-45
Configuring ATM VC Bundle Router(config-if)#
bundle bundle bundle-name bundle-name class class vc-class-name vc-class-name oam-bundle oam-bundle [manage] [frequency] [frequency] bump bump {implicit {implicit || explicit explicit precedence-level precedence-level || traffic} traffic} encapsulation encapsulation atm-encap atm-encap protocol protocol atm-map-parameters … [no] [no] broadcast broadcast inarp inarp timeout timeout
• Configures ATM VC bundle • If a vc-class is applied to the bundle, the bundle inherits parameters specified in the vc-class • Individual parameters specified in the vc-class can be overwritten by bundle configuration commands © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-50
Use the bundle interface command to enter the bundle configuration mode. Parameters specific to this bundle should be configured on the bundle. Parameters that are common to multiple bundles should be configured in a template (VC class) and attached to the bundle using the class-bundle command. The command used to attach VC class templates differs, depending on which configuration mode is used:
10-46
IP QoS IP over ATM
n
The class-int interface command is used to attach a VC class to an interface
n
The class-bundle command is used to attach a VC class to a bundle
n
The class-vc command is used to attach a VC class to a virtual circuit
Copyright 2001, Cisco Systems, Inc.
Configuring OAM Management in the Bundle Router(config-atm-vc)#
oam-bundle oam-bundle [manage] [frequency] [frequency]
• Enables VC management with end-to-end OAM cells • Cells are sent but the bundle is not managed if the manage keyword is omitted • The frequency parameter specifies the cell generation rate in seconds Router(config-atm-vc)#
oam oam retry up-count up-count down-count down-count retry-frequency retry-frequency
• Specifies the OAM management-related thresholds • The up-count and down-count parameters specify the number of consecutive cells that have to be received (or lost) before the VC is declared up or down • The frequency parameter specifies the cell send frequency during VC state change verification © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-51
To enable end-to-end F5 Operation, Administration and Maintenance (OAM) loopback cell generation and OAM management for a virtual circuit (VC) class that can be applied to a VC bundle, use the oam-bundle vc-class configuration command. To enable end-to-end F5 OAM loopback cell generation and OAM management for all VC members of a bundle, use the oam-bundle bundle configuration command. If the manage keyword is omitted, loopback cells are sent but the bundle is not managed. The frequency parameter specifies the number of seconds between sending OAM loopback cells. Values range from 0 to 600 seconds. To configure parameters related to OAM management for an ATM PVC, SVC, or VC class, use the oam retry command in the appropriate command mode. The up-count parameter specifies the number of consecutive end-to-end F5 OAM loopback cell responses that must be received in order to change a PVC connection state to up. The down-count parameter specifies the number of consecutive end-to-end F5 OAM loopback cell responses that are not received in order to change a PVC state to down. The retry-frequency parameter specifies the frequency (in seconds) that the end-to-end F5 OAM loopback cells are transmitted when a change in the UP/DOWN state of a PVC is being verified. For example, if a PVC is up and a loopback cell response is not received after the frequency (in seconds) specified using the oam-pvc command, then loopback cells are sent at the retry-frequency to verify whether or not the PVC is down. Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-47
Configuring Traffic Bumping Router(config-atm-vc)#
bump bump implicit implicit
• Configures implicit bumping rules for the bundle or individual VC in the bundle • If the VC fails, the traffic is bumped to the VC carrying lower-precedence traffic Router(config-atm-vc)#
bump bump explicit explicit precedence precedence
• Configures explicit bumping rules for the bundle or individual VC in the bundle • If the VC fails, the traffic is bumped to the VC currently carrying packets with specified IP precedence © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-52
The bump implicit command, depending on the mode, applies implicit bumping rules, which is also the default, to a single VC bundle member (bundle -vc mode) or all VCs in the bundle (bundle mode). The (default) implicit bumping rule stipulates that bumped traffic is to be carried by a VC with a lower precedence. The bump implicit command specifies the IP precedence level to which traffic on a VC (bundle -vc mode) will be bumped when the VC goes down. It specifies a single number as the value of the precedence-level argument.
10-48
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Configuring Traffic Bumping Router(config-atm-vc)#
no no bump bump traffic traffic
• Prevents the VC (or all VCs in a bundle) from accepting bumped traffic Router(config-atm-vc)#
bump bump traffic traffic
• Allows the VC (or all VCs in a bundle) to accept bumped traffic
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-53
Use the no bump traffic command to reject bumped traffic on the configured VC. Use the bump traffic command to restore the default behavior.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-49
Configuring VC-wide VC Class Router(config)#
class-vc class-vc vc-class-name vc-class-name precedence precedence [other | range ] bump bump {implicit {implicit | explicit precedence-level precedence-level | traffic} protect protect {group {group | vc } ubr ubr || ubr+ ubr+ || vbr-nrt vbr-nrt atm-qos-parameters random-detect random-detect [attach group-name]
• Configures all parameters that can be specified on an ATM VC within the bundle in a VC class
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-54
Use the class-vc global configuration command to create a VC template. Interface, VC or bundle specific parameters can be set within the VC class.
10-50
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Configuring ATM VC in a Bundle Bundle Router(config-if)# bundle bundle-name pvc pvc name name [vpi/]vci class vc-class-name vc-class-name precedence precedence [other [other || range range ] bump {implicit {implicit || explicit explicit precedence-level precedence-level | traffic} protect {group | vc} ubr ubr || ubr+ ubr+ || vbr-nrt vbr-nrt atm-qos-parameters random-detect random-detect [attach group-name] group-name]
• Configures individual VC in an ATM VC bundle • If a vc-class is applied to the VC, the VC inherits parameters specified in the vc-class • Individual parameters specified in the vc-class can be overwritten by bundle configuration commands • Unspecified VC parameters are inherited from the bundle or from the ATM interface © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-55
Use the bundle command in the ATM interface or subinterface configuration mode. From within the bundle configuration mode the characteristics and attributes of the bundle and its members, such as the encapsulation type for all virtual circuits (VCs) in the bundle, the bundle management parameters and the service type, can be configured. Attributes and parameters that are configured in the bundle configuration mode are applied to all virtual circuit (VC) members of the bundle. VCs in a VC bundle are subject to the following configuration inheritance guidelines (listed in order of next highest precedence): 1. VC configuration in bundle -vc mode 2. Bundle configuration in bundle mode 3. Subinterface configuration in subinterface mode
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-51
Map IP Precedence to an ATM VC Router(config-atm-vc)#
precedence precedence [other [other || range range ]]
• Maps packets with specified range of IP precedence into the configured ATM VC • All the unmapped IP precedence values are mapped to the VC specifying “other” • Default: VC accepts all unspecified IP traffic
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-56
Assignment of precedence levels to VC bundle members provides the ability to create a differentiated service, because the IP Precedence levels can be distributed over the different VC bundle members. A single precedence level, or a range of levels to each discrete VC in the bundle, can be mapped, thereby enabling VCs in the bundle to carry packets marked with different precedence levels. Alternatively, a VC can be configured with the precedence other command to indicate that it can carry traffic marked with precedence levels not specifically configured for it. Only one VC in the bundle can be configured with the precedence other command to carry all precedence levels not specified. This VC is considered the default.
10-52
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
VC Protection Router(config-atm-vc)#
protect protect {{ group group || vc vc }}
• Configures the VC to be part of protected group or to be individually protected • Bundle is declared down if all VCs in the protected group are lost or if any individually-protected VC is lost • Only one protected group can be configured in a bundle • Default: VC is not protected
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-57
Use the protect vc command to protect a virtual circuit. Use the protect group command to make the VC a member of the protected group. When a protected VC goes down, it takes the bundle down. When all members of a protected group go down, the bundle goes down.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-53
VC Inheritance Rules • VC parameters are inherited in the following order – Parameters specified on individual VC – Parameters in the VC class applied to the individual VC – Parameters specified on the bundle to which the VC belongs – Parameters specified in the VC class applied to the bundle – Parameters specified on an interface or subinterface
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-58
The figure shows the inheritance rules for parameters set on interfaces, bundles, VC classes or individual VCs. The parameters configured on individual VCs override all inherited values.
10-54
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
ATM VC Bundle Case Study • IP traffic is transported across an international ATM PVC with the following IP precedence values Precedence 0-1 2-3 4 5 6,7
Meaning Best-effort Internet traffic Premium Internet traffic VPN traffic VoIP traffic Routing protocols
• Voice traffic, VPN traffic and Premium Internet traffic shall be transported across dedicated PVCs for easier provisioning
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-59
The figure illustrates a case study where there are four user classes and one class for control traffic. Routers perform classification based on IP precedence values: n
IP precedence 6 and 7 traffic is forwarded through the Control VC
n
IP precedence 5 traffic is forwarded through the Voice VC
n
IP precedence 4 traffic is forwarded through the VPN VC
n
IP precedence 2 and 3 traffic is forwarded through the Premium VC
n
IP precedence 0 and 1 traffic is forwarded through the Best-effort VC
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-55
Case Study Step 1: Bundle Design • Precedence 5 traffic (VoIP) is transported over a separate VC, no bumping is possible • Precedence 2-3 traffic (Premium Internet) is transported over a separate VC, can be bumped onto the best-effort VC • Precedence 4 traffic (VPN) is transported over a separate VC, can be bumped onto best -effort VC • Control traffic is transported over a separate VC, can be bumped onto the best-effort VC • Best-effort VC can be bumped onto Premium Internet VC • WRED has to be deployed on all VCs to prevent bumped best-effort traffic from congesting the VC © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-60
Per-VC WRED is the only IP QoS mechanism that will be used on the routers to manage congestion.
10-56
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Router Configuration • Case study step 2: configuring VC classes vc-class vc-class best_effort best_effort precedence other bump bump explicitly explicitly 22 protect group !! vc-class vc-class premium precedence precedence 2-3 2-3 bump implicitly protect group !! vc-class vc-class bundle encapsulation aal5snap broadcast protocol ip ip inarp inarp oam-bundle oam-bundle manage 3 © 2001, Cisco Systems, Inc.
vc-class vc-class vpn precedence precedence 44 bump explicitly explicitly 00 protect group !! vc-class vc-class voip voip precedence precedence 55 no bump traffic protect vc !! vc-class vc-class control precedence precedence 6-7 6-7 bump explicitly explicitly 00 protect group
IP QoS IP over ATM-61
The first part of the implementation shows the templates (VC classes) that will be used for individual virtual circuits (classes) and one for the bundle.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-57
Router Configuration • Case study step 3: configuring the WRED profile Guaranteed_BW PVC random-detect-group random-detect-group guaranteed_bw_pvc guaranteed_bw_pvc precedence precedence 00 20 20 40 40 10 precedence 25 precedence 11 25 40 40 10 precedence 35 precedence 22 35 40 40 10 precedence 30 precedence 66 30 40 40 10 precedence 30 precedence 77 30 40 40 10
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-62
A random-detect-group is created for the virtual circuits that need non-default WRED profiles.
10-58
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Router Configuration • Case study step 4: configure the bundle and individual PVC interface interface ATM ATM 5/1/0.22 5/1/0.22 point-to-point point -to-point ip ip address address 216.23.45.5 216.23.45.5 255.255.255.252 255.255.255.252 bundle bundle SanFrancisco SanFrancisco class class bundle pvc-bundle pvc-bundle SF-control SF-control 2266 class class control vbr-nrt vbr-nrt 1000 1000 1000 1000 pvc-bundle pvc-bundle SF-voip SF-voip 25 25 class class voip voip vbr vbr 2000 2000 2000 2000 pvc-bundle pvc-bundle SF-vpn SF-vpn 24 class vpn class vpn vbr-nrt vbr-nrt 4000 4000 4000 4000 pvc-bundle pvc-bundle SF-guaranteed SF-guaranteed 22 class class guaranteed_bw guaranteed_bw random-detect random -detect attach attach guaranteed_bw_pvc guaranteed_bw_pvc vbr-nrt vbr-nrt 8000 8000 8000 8000 pvc-bundle pvc-bundle SF-best-effort SF-best-effort 23 23 class class best_effort best_effort random-detect random -detect © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-63
The figure shows the configuration of the bundle with five individual VCs. Each VC is configured with the PVC type and parameters. All other configuration parameters are inherited from the VC classes attached to individual VCs and the VC class attached to the bundle.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-59
Summary VC Bundling is a solution where the task of providing differentiated quality of service is offloaded to ATM switches. Classes are identified by using IP precedence values, then the routers perform classification based on IP precedence values. Up to eight parallel virtual circuits can be used for one IP adjacency. Appropriate ATM services are used for each IP precedence value, depending on the QoS requirements and provisioning. A range of IP precedence values or a single IP precedence value are mapped to one virtual circuit. Non-contiguous IP precedence ranges are not supported.
Review Questions Answer the following questions: 1. How does VC Bundling classify IP packets? 2. Which QoS mechanisms are used when using VC Bundling? 3. How many parallel VCs can be used for one IP adjacency? 4. How many IP precedence values can map into one VC?
10-60
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-VC CB-WFQ Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe per-VC CB-WFQ
n
Configure per-VC CB-WFQ
n
Monitor and troubleshoot per-VC CB-WFQ
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-61
Per-VC CB-WFQ • Class-based Weighted Fair Queuing (CB-WFQ) can be used on ATM interfaces • QoS service policies can be applied to: – An interface – A subinterface – An individual virtual circuit
• Supported service policies are: – – – – –
CB-WFQ including WRED CB-LLQ CB-Marking including setting of ATM CLP bit CB-Shaping CB-Policing including setting of ATM CLP bit
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-68
Per-VC queuing can be supplemented by using the Modular QoS CLI (MQC). ATM PVCs can be combined with any QoS mechanism available with the MQC: n
CB-WFQ for bandwidth management
n
CB-LLQ for delay management
n
CB-Marking
n
CB-Shaping
n
CB-Policing
CB-Marking and CB-Policing also include the capability to mark cells with the Cell Loss Priority (CLP) bit.
10-62
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-interface Per-interface CB-WFQ PVC 0/50
Subinterface ATM1/0/0.1
PVC 0/51 Interface ATM1/0/0
CB-WFQ
PVC 0/52 PVC 0/53 PVC 0/54
Subinterface ATM1/0/0.2
• CB-WFQ can be applied to an entire interface class-map class-map HTTP HTTP match match http http !! policy-map policy-map LimitHTTP LimitHTTP class class HTTP HTTP police police 256000 256000 conform conform transmit transmit exceed exceed set-clp-transmit set-clp-transmit !! interface interface ATM5/0/0 ATM5/0/0 service-policy service-policy output output LimitHTTP LimitHTTP !! © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-69
The figure illustrates an ATM interface with two configured subinterfaces. The first subinterface uses two ATM PVCs, the second subinterface uses three ATM PVCs. A service policy can be applied to an entire ATM interface.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-63
Per-subinterface CB-WFQ Subinterface ATM1/0/0.1
PVC 0/50
CB-WFQ
PVC 0/51 Interface ATM1/0/0
PVC 0/52 PVC 0/53
CB-WFQ
PVC 0/54
Subinterface ATM1/0/0.2
• CB-WFQ can be applied to subinterfaces class-map class-map CorporateTraffic CorporateTraffic match -group 100 match access access-group 100 !! policy-map policy-map Smart Smart class class CorporateTraffic CorporateTraffic bandwidth bandwidth 10000 10000 class class class-default class-default set set atm-clp atm-clp !!
© 2001, Cisco Systems, Inc.
interface interface ATM5/0/0.1 ATM5/0/0.1 point-to-point point-to-point service-policy service-policy output output Smart Smart pvc pvc Core Core 0/51 0/51 vbr-nrt vbr-nrt 10000 10000 2000 !!
IP QoS IP over ATM-70
A service policy can also be applied to individual ATM subinterfaces.
10-64
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-interface Per-interface CB-WFQ CB-WFQ
PVC 0/50
CB-WFQ
PVC 0/51
CB-WFQ
PVC 0/52
CB-WFQ
PVC 0/53
CB-WFQ
PVC 0/54
Subinterface ATM1/0/0.1
Interface ATM1/0/0
Subinterface ATM1/0/0.2
• CB-WFQ can be applied to an individual virtual circuit
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-71
The highest QoS granularity is achieved by attaching service policies to individual virtual circuits.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-65
Per-interface Per-interface CB-WFQ Configuration Example class-map class-map MatchCorporate MatchCorporate match -group 100 match access access-group 100 !! policy-map policy-map MARK MARK class class MatchCorporate MatchCorporate police -action set-clp-transmit police 2000000 conform-action conform-action transmit transmit exceed exceed-action set-clp-transmit !! interface interface ATM5/0/0 ATM5/0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 service-policy service-policy output output MARK MARK pvc pvc 0/50 0/50 vbr-nrt vbr-nrt 500 500 400 400 1000 1000 inarp inarp 11 broadcast broadcast !! access-list access-list 100 100 permit permit ip ip 10.0.0.0 10.0.0.0 0.255.255.255 0.255.255.255 10.0.0.0 10.0.0.0 0.255.255.255 0.255.255.255
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-72
The example shows how a service policy is used in simple ATM configurations where the main interface is used to establish IP adjacency. The service policy is attached directly to the interface.
10-66
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Per-VC CB-WFQ Configuration Example class-map class-map MatchCorporate MatchCorporate match -group 100 match access access-group 100 !! policy-map policy-map MARK MARK class class MatchCorporate MatchCorporate police -action set-clp-transmit police 2000000 conform-action conform-action transmit transmit exceed exceed-action set-clp-transmit !! interface interface ATM5/0/0 ATM5/0/0 no no ip ip address address !! interface interface ATM5/0/0.1 ATM5/0/0.1 point-to-point point-to-point ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 pvc pvc 0/50 0/50 vbr-nrt vbr-nrt 500 500 400 400 1000 1000 inarp inarp 11 service-policy service-policy output output MARK MARK broadcast broadcast !! access-list access-list 100 100 permit permit ip ip 10.0.0.0 10.0.0.0 0.255.255.255 0.255.255.255 10.0.0.0 10.0.0.0 0.255.255.255 0.255.255.255
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-73
The more common alternative to configuring ATM is to use subinterfaces. A service policy can be attached to the subinterface or a virtual circuit.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-67
Monitoring and Troubleshooting Per-interface Per-interface CB-WFQ Router#
show policy-map interface ATM-interface
• Displays the Service Policy parameters and statistics for the selected interface or subinterface Router#show Router#show policy policy interface interface atm atm 5/0/0.1 5/0/0.1 ATM5/0/0.1 ATM5/0/0.1 Service-policy Service-policy output: output: Smart Smart (1755) (1755) Class-map: Class-map: CorporateTraffic CorporateTraffic (match-all) (match -all) (1757/42) (1757/42) 00 packets, packets, 00 bytes bytes 55 minute minute offered offered rate rate 0 0 bps, bps, drop drop rate rate 0 0 bps bps Match: Match: access-group access-group 100 100 (1761) (1761) queue size 0, queue limit 2500 queue size 0, queue limit 2500 packets packets output output 0, 0, packet drops 0 tail/random tail/random drops drops 0, 0, no no buffer buffer drops drops 0, 0, other other drops drops 00 Bandwidth: Bandwidth: kbps kbps 10000, 10000, weight weight 29 29 ... ...
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-74
Use the show policy-map interface command to display the parameters and statistics of input and output policies attached to interfaces. This command displays information about all classification options and the attached QoS mechanisms.
10-68
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting Per-VC CB-WFQ Router#
show queueing interface ATM-interface [vc [VPI/]VCI]
• Displays CB-WFQ parameters and statistics for the selected interface, subinterface or VC Router#show Router#show queueing queueing interface interface atm5/0 atm5/0 Interface Interface ATM5/0 ATM5/0 VC VC 0/5 0/5 Queueing Queueing strategy: strategy: fifo fifo Output Output queue queue 0/40, 0/40, 00 drops drops per per VC VC Interface Interface ATM6/0 ATM6/0 VC VC 0/16 0/16 Queueing strategy: fifo Queueing strategy: fifo Output Output queue queue 0/40, 0/40, 00 drops drops per per VC VC Interface Interface ATM6/0 VC 0/50 Queueing Queueing strategy: strategy: weighted weighted fair fair Total Total output output drops drops per per VC: VC: 00 Output queue: 0/512/64/0 (size/max Output queue: 0/512/64/0 (size/max total/threshold/drops) total/threshold/drops) Conversations Conversations 0/1/32 0/1/32 (active/max (active/max active/max active/max total) total) Reserved Reserved Conversations Conversations 0/0 0/0 (allocated/max (allocated/max allocated) allocated) Available Available Bandwidth Bandwidth 225 225 kilobits/sec kilobits/sec
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-75
Use the show queueing exec command to list all, or selected, configured queuing strategies.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-69
Summary Per-VC CB-WFQ allows the usage of the same QoS mechanisms as any other technology using single physical interfaces. The same configuration steps are needed to create a service policy. The policy can then be attached to an interface, subinterface or an individual VC. CB-Policing and CB-Marking also support the setting of the ATM CLP bit.
Review Questions Answer the following question: 1. Where can CB-WFQ be attached on ATM interfaces?
10-70
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
RSVP to SVC Mapping Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe RSVP to SVC mapping
n
Configure RSVP to SVC mapping
n
Monitor and troubleshoot RSVP to SVC mapping
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-71
RSVP to SVC Mapping • RSVP-enabled flows have bandwidth and delay requirements • Pass-through RSVP could affect the quality of service in case an ATM interface or PVC is congested • RSVP-enabled flows can get their own VCs and queues to prevent congestion affecting these flows • RSVP reservations are mapped to SVCs
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-80
The RSVP-ATM QoS Interworking feature provides support for Controlled Load Service using RSVP over an ATM core network. This feature requires the ability to signal for establishment of switched virtual circuits (SVCs) across the ATM cloud in response to RSVP reservation request messages. To meet this requirement, RSVP over ATM supports mapping of RSVP sessions to ATM SVCs.
10-72
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
RSVP to SVC Mapping
SVC RSVP
RSVP
• RSVP triggers SVC creation • ATM SVC parameters are calculated from the parameters in the RSVP reservation request
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-81
Traditionally, RSVP has been coupled with WFQ. WFQ provides bandwidth guarantees to RSVP and gives RSVP visibility to all packets visible to it. This visibility allows RSVP to identify and mark packets pertinent to it. The RSVP-ATM QoS Interworking feature provides the capability to decouple RSVP from WFQ, and instead associate it with ATM SVCs to handle reservation request messages (and provide bandwidth guarantees), and NetFlow to make packets visible to RSVP.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-73
ATM SVC Parameters Cell 1 ATM Header
AAL5SNAP Header
5
5
Cell 2 IP Header
Voice Data
43
Sustained Cell Rate
Cell overhead
ATM Header
Voice Data
5
48 Data Link Encapsulation overhead AAL5SNAP has 5 bytes of overhead
SCR = BW RSVP . (53/48) . (MPS + DLE + UCO)/MPS Bandwidth requested by RSVP
Unused
Unused Cell Overhead
Minimum IP packet size
• Peak Cell Rate uses the same formula except it is based on the line rate or the configured peak cell rate © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-82
To ensure correspondence between RSVP and ATM SVC values, the software algorithmically maps the rate and burst size parameters in the RSVP service parameters to the ATM Sustained Cell Rate (SCR) and Maximum Burst Size (MBS). For the Peak Cell Rate (PCR), it uses the value that is configured or it defaults to the line rate. The figure illustrates the formula used to calculate the ATM service parameters from the RSVP service parameters. RSVP does not include the Layer-2 overhead, which is difficult to calculate for ATM. Layer-3 packets are first framed (AAL5SNAP header is prepended) and then segmented in 48-byte cells. Each cell has an additional 5 bytes of overhead.
10-74
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
RSVP to SVC Mapping Optional QoS • RSVP can mark conforming and exceeding packets with different IP precedence or ToS values • Per-VC WRED can be used for differentiated dropping
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-83
In addition to RSVP mapping into SVCs, individual virtual circuits can use IP precedence or ToS marking and WRED for congestion management.
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-75
Configuring RSVP to SVC Mapping • The following configuration steps are needed to enable RSVP to SVC mapping: – Enable RSVP – Enable SVC creation – Optionally enable RSVP-based marking and WRED – Verify and monitor RSVP/ATM
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-84
The RSVP-ATM QoS Interworking feature allows the following tasks to be performed:
10-76
IP QoS IP over ATM
n
Enable RSVP by specifying the total amount of bandwidth that can be reserved by RSVP sessions and a maximum amount of bandwidth one session can reserve.
n
Configure an interface or subinterface to dynamically create SVCs in response to RSVP reservation request messages. To ensure defined QoS, these SVCs are established having QoS profiles consistent with the mapped RSVP flow specifications.
n
Optionally, attach distributed Weighted Random Early Detection (dWRED) group definitions to the Enhanced ATM port adapter (PA-A3) interface to support the per-VC dWRED drop policy. Use of per-VC dWRED ensures that, if packets must be dropped, then best-effort packets are dropped first and not those that conform to the appropriate QoS determined by the token bucket of RSVP.
n
Optionally, configure the IP Precedence and ToS values to be used for packets that conform to or exceed QoS profiles. As part of its input processing, RSVP uses the values specified to set the ToS and IP Precedence bits on incoming packets. If per-VC DWRED is configured, it then uses the ToS and IP Precedence bit settings on the output interface of the same router in determining which packets to drop. Also, interfaces on downstream routers use these settings in processing packets.
Copyright 2001, Cisco Systems, Inc.
Enabling RSVP Router(config-if)#
ip rsvp bandwidth reservable-bw max-flow-bw
• Enables RSVP reservation on an interface or subinterface • The reservable-bw parameters specifies the total maximum amount of bandwidth that can be reserved by RSVP flows • The max-flow-bw parameter specifies the maximum amount of bandwidth a single flow can reserve
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-85
The ip rsvp bandwidth interface command is used to enable RSVP on an interface. The interface and per-flow maximum reservable bandwidth limits have to be configured. Note
Copyright 2001, Cisco Systems, Inc.
RSVP cannot reserve more than 75% of the default or configured interface bandwidth.
IP QoS IP over ATM
10-77
Enabling Creation of SVCs Router(config-if)#
ip rsvp svc-required
• Enables creation of SVC for RSVP reservation • ATM QoS parameters are determined by using the parameters in the RSVP request Router(config-if)#
ip ip rsvp rsvp atm-peak-rate-limit atm-peak-rate-limit limit limit
• Sets the peak cell rate for all new SVC • Uses the line rate as the default
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-86
Use the ip rsvp svc-required interface configuration command to enable the creation of a Switched Virtual Circuit (SVC) to service any new Resource Reservation Protocol (RSVP) reservation made on the ATM interface or subinterface. Use the ip rsvp atm-peak-rate-limit interface configuration command to set a limit on the Peak Cell Rate (PCR) of reservations for all newly created Resource Reservation Protocol (RSVP) switched virtual circuits (SVCs) established on the ATM interface or any of its subinterfaces. The PCR, if it is not configured, defaults to the line rate.
10-78
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
RSVP-based Marking and WRED Router(config-if)#
ip rsvp precedence {conform | exceed} precedence precedence
• Packets conforming to the reserved bandwidth are marked with conform precedence • Packets exceeding the reserved bandwidth are marked with exceed precedence • NetFlow has to be enabled Router(config-if)#
random-detect attach random-detect-group random-detect-group
• Enables per-VC WRED • Uses the WRED profiles specified in the WRED group randomdetect-group • CEF switching is required © 2001, Cisco Systems, Inc.
IP QoS IP over ATM-87
Packets in an RSVP reserved path are divided into two classes: those that conform to the reservation service parameters and those that correspond to a reservation but exceed, or are outside, the reservation service parameters. The ip rsvp precedence interface command allows the IP Precedence values to be set to be applied to packets belonging to these two classes. The IP Precedence value for at least one class of traffic must be set when this command is used. A single instance of the command can be used to specify values for both classes, in which case the conform and exceed keywords can be specified in either order. As part of its input processing, RSVP uses the ip rsvp precedence command to set the IP Precedence bits on conforming and nonconforming packets. If per-VC dWRED is configured, the system uses the IP Precedence and ToS bit settings on the output interface in its packet drop process. The IP Precedence setting of a packet can also be used by interfaces on downstream routers. Execution of the ip rsvp precedence command causes IP Precedence values for all preexisting reservations on the interface to be modified. RSVP receives packets from the underlying forwarding mechanism. Therefore, before the ip rsvp precedence command is used to set IP Precedence, one of the following features is required: n
Weighted Fair Queuing (WFQ) must be enabled on the interface
n
RSVP switched virtual circuits (SVCs) must be used in combination with NetFlow
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-79
RSVP to SVC Mapping Example interface interface ATM2/1/0 ATM2/1/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 ip ip rsvp rsvp bandwidth bandwidth 10000 10000 10000 10000 ip ip rsvp rsvp svc-required svc-required ip route-cache flow ip route-cache flow ip 0 ip rsvp rsvp precedence precedence conform conform 5 5 exceed exceed 0 atm atm pvc pvc 11 00 55 qsaal qsaal atm atm pvc pvc 22 0 16 16 ilmi ilmi atm atm esi-address esi-address 111111111151.00 111111111151.00 pvc pvc pvc12 pvc12 0/51 0/51 inarp inarp 55 broadcast broadcast !!
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-88
The sample configuration shows that up to 10Mbps can be reserved by RSVP sessions. RSVP sessions trigger establishment of SVCs and marks conforming packets with IP precedence 5.
10-80
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Monitoring and Troubleshooting RSVP to SVC Mapping Router#
show ip rsvp interface [intf]
• Displays RSVP-related interface information Router#show Router#show ip ip rsvp rsvp interface interface interface allocated interface allocated i/f i/f max max Et4/0 0M 7M Et4/0 0M 7M AT5/0/0 0M 10M AT5/0/0 0M 10M Se5/1/0 0M 192K Se5/1/0 0M 192K
flow flow max max pct pct UDP UDP 5M 00 00 5M 1M 00 00 1M 192K 00 00 192K
IP IP 00 00 00
UDP_IP UDP_IP 00 00 00
UDP UDP M/C M/C 00 00 00
© 2001, Cisco Systems, Inc.
IP QoS IP over ATM-89
Use the show ip rsvp interface command to display RSVP parameters and statistics for all RSVP-enabled interfaces. Field interface allocate i/f max flow max pct UDP IP UDP_IP
Copyright 2001, Cisco Systems, Inc.
Description Interface name. Current allocation budget. Maximum allocatable bandwidth. Largest single flow allocatable on this interface. Percent of bandwidth utilized. Number of neighbors sending User Datagram Protocol (UDP)-encapsulated RSVP. Number of neighbors sending IP-encapsulated RSVP. Number of neighbors sending both UDP- and IP-encapsulated RSVP.
IP QoS IP over ATM
10-81
Summary RSVP flows can be provided guarantees either by using a queuing mechanism that supports per-flow queuing (for example, WFQ of CB-WFQ) or it can use dedicated per-flow Switched Virtual Circuits (SVCs) when entering an ATM backbone. Each RSVP flow triggers a generation of a SVC. The SVC inherits service parameters from the RSVP service parameters (modified to account for Layer-2 overhead).
Review Questions Answer the following questions: 1. How does RSVP benefit from using SVCs? 2. What are the necessary configuration steps to enable RSVP-to-SVC?
10-82
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Summary After completing this module, you should be able to perform the following tasks: n
List the requirements of IP QoS in combination with ATM QoS
n
Describe the hardware and software requirements for advanced IP QoS mechanisms on ATM interfaces
n
Describe per-VC queuing
n
Describe and configure per-VC WRED
n
Describe and configure VC bundling
n
Describe and configure per-VC CB-WFQ
n
Describe RSVP to SVC mapping
n
Monitor and troubleshoot IP QoS on ATM interfaces
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-83
Review Questions and Answers Introduction to IP over ATM Question: What are the main differences between IP and ATM? IP is connectionless, ATM is connection oriented IP applies QoS per packet, ATM per virtual circuit IP supports a smaller number of traffic classes (IP precedence, DSCP) and does not include any services by default ATM supports a larger number of traffic classes but has a fixed number of services (xBR) Answer: Which QoS services does ATM support? CBR, VBR, ABR and UBR Question: How should congestion be handled when an ATM backbone is used? Congestion should be pushed back to the ingress into the ATM network to allow IP-based congestion management. Answer: Why is per-VC queuing so important? Per-VC queuing prevents head-of-line blocking and allows per-VC congestion management.
Per-VC WRED Question: What are the benefits of per-VC WRED? Answer: Per-VC WRED allows differentiated congestion avoidance on per-VC basis.
Question: What are the configuration steps needed to enable per-VC WRED? Answer: Per-VC WRED requires the configuration of WRED profiles (random detect groups) which are then attached to individual VCs.
VC Bundling Question: How does VC Bundling classify IP packets? Answer: VC Bundling classifies IP packets based on the IP precedence value. Question: Which QoS mechanisms are used when using VC Bundling? Answer: A QoS design can rely on the ATM QoS or supplement it by using per-VC WRED or CB-WFQ. Question: How many parallel VCs can be used for one IP adjacency? 10-84
IP QoS IP over ATM
Copyright 2001, Cisco Systems, Inc.
Answer: Up to 8 parallel VCs can be used for one point-to-point IP adjacency. Question: How many IP precedence values can map into one VC? Answer: Up to 8 consecutive IP precedence values can map into one VC.
Per-VC CB-WFQ Question: Where can CB-WFQ be attached on ATM interfaces? Answer: CB-WFQ can be used on per-interface, per-subinterface or per-VC basis.
RSVP to SVC Mapping Question: How does RSVP benefit from using SVCs? Answer: RSVP-based flows can get their QoS resources by using dedicated SVCs with the appropriate ATM QoS parameters derived from the RSVP requests. Question: What are the necessary configuration steps to enable RSVP-to-SVC? Answer: Enable RSVP throughout the network and then enable SVC creation for RSVP flows on ATM interfaces n
Copyright 2001, Cisco Systems, Inc.
IP QoS IP over ATM
10-85
IP over MPLS
Overview This module focuses on the IP QoS mechanisms available in combination with Multiprotocol Label Switching (MPLS).
Objectives Upon completion of this module, you will be able to perform the following tasks: n
Describe and configure QoS Mechanisms in Frame-mode MPLS networks
n
Describe and configure QoS Mechanisms in Cell-mode MPLS networks
MPLS Introduction Objectives Upon completion of this lesson, you will be able to perform the following tasks:
23-2
n
Describe basic features of MPLS
n
Describe Frame-mode MPLS
n
Describe Cell-mode MPLS
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Basic MPLS Concepts • Multi-protocol Label Switching (MPLS) is a new forwarding mechanism in which packets are forwarded based on labels • Labels may correspond to IP destination networks (equal to traditional IP forwarding) • Labels can also correspond to other parameters (QoS, source address, ...) • MPLS was designed to support forwarding of other protocols as well
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Multi-protocol Label Switching (MPLS) is a switching mechanism that uses labels (numbers) to forward packets. Labels usually correspond to layer-3 destination addresses (equal to destinationbased routing). Labels can also correspond to other parameters (QoS, source address, etc.). MPLS was designed to support other protocols as well. Label switching is performed regardless of the layer-3 protocol.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-3
MPLS Example 10.1.1.1
10.1.1.1
L=3
Label removal and routing lookup L=3
5 L=
Routing lookup and label assignment 10.0.0.0/8 à L=5 Label swapping L=5 à L=3
• Only edge routers must perform a routing lookup. • Core routers switch packets based on simple label lookups and swap labels. © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The example in the figure illustrates a situation where the intermediary router does not have to perform a time-consuming routing lookup. Instead this router simply swaps a label with another label (5 is replaced by 3) and forwards the packet based on the received label (5). In larger networks, the result of MPLS labeling is that only the edge routers perform a routing lookup. All the core routers forward packets based on the labels.
23-4
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS vs. IP-over-ATM 10.1.1.1
L=17
L=3
L=5
10.1.1.1
Layer-2 devices run a layer-3 routing protocol and establish virtual circuits dynamically based on layer-3 information
• Layer-2 devices are IP-aware and run a routing protocol • There is no need to manually establish virtual circuits • MPLS provides a virtual full-mesh topology © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The example in the figure shows how MPLS is used in ATM networks to provide optimal routing across layer-2 ATM switches. In order for MPLS to work with ATM switches, the switches must be layer-3 aware (ATM switches must run a layer-3 routing protocol). Another benefit of this setup is that there is no longer a need to manually establish virtual circuits. ATM switches automatically create a full mesh of virtual circuits based on layer-3 routing information.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-5
Traffic Engineering with MPLS Primary OC-192 link
Large site A
Large site B
Secondary OC-48 link
Small site C
• Traffic can be forwarded based on other parameters (QoS, source, ...) • Load sharing across unequal paths can be achieved © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
MPLS also supports traffic engineering. Traffic engineered tunnels can be created based on a traffic analysis to provide load balancing across unequal paths. Multiple traffic engineering tunnels can lead to the same destination but can use different paths. Traditional IP forwarding would force all traffic to use the same path based on the destination-based forwarding decision. Traffic engineering determines the path at the source based on additional parameters (available resources and constraints in the network).
23-6
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Architecture • MPLS has two major components: • Control plane – exchanges layer-3 routing information and labels • Data plane – forwards packets based on labels
• Control plane contains complex mechanisms to exchange routing information (OSPF, EIGRP, IS-IS, BGP,...) and labels (TDP, LDP, BGP, RSVP, ...) • Control plane maintains the contents of the label switching table (label forwarding information base or LFIB) • Data plane has a simple forwarding engine
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
To better understand the inner workings of MPLS, its two major components should be clarified: n
Control plane, which takes care of the routing information exchange and the label exchange between adjacent devices
n
Data plane, which takes care of forwarding either based on destination addresses or labels.
There is a large number of different routing protocols such as OSPF, IGRP, EIGRP, IS-IS, RIP, BGP, etc. that can be used in the control plane. The control plane also requires protocols such as TDP (MPLS), LDP (MPLS), BGP (MPLS/VPNs), RSVP (Traffic Engineering), CR-LDP (Traffic Engineering), etc. to exchange labels. The data plane however, is a simple label-based forwarding engine that is independent of the type of routing protocol or label exchange protocol. A Label Forwarding Information Base (LFIB) is used to forward packets based on labels. The LFIB table is populated by the control plane.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-7
MPLS Architecture Control plane OSPF: 10.0.0.0/8
LDP: 10.0.0.0/8 Label 17
OSPF
LDP
OSPF: 10.0.0.0/8
LDP: 10.0.0.0/8 Label 4
Data plane Labeled packet Label 17
LFIB 4à17
Labeled packet Label 4
• Router’s functionality is divided into two major parts: control plane and data plane © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
A simple MPLS-enabled network implements destination-based forwarding that uses labels to make forwarding decisions. A layer-3 routing protocol is still needed to propagate layer-3 routing information. A label exchange mechanism is simply an add-on to propagate labels that are used for layer-3 destinations. The example in the figure illustrates the two components of the control plane: n
OSPF that receives and forwards IP network 10.0.0.0/8, and places that prefix into the routing table.
n
LDP that receives label 17 to be used for packets with a destination address 10.x.x.x. A local label 4 is generated and sent to upstream neighbors so these neighbors can label packets with the appropriate label. LDP inserts an entry into the Data Plane’s LFIB table where label 4 is mapped to label 17.
The data plane then forwards all packets with label 4 through the appropriate interfaces and replaces the label with label 17.
23-8
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Modes of Operation • MPLS technology is designed to be Layer-1 and Layer-2 independent • MPLS uses a 32-bit label field which is inserted between Layer-2 and Layer-3 headers (frame mode) • MPLS over ATM uses the ATM header as the label (cell mode)
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
MPLS is designed for use on virtually any media and layer-2 encapsulation. Most layer-2 encapsulations are frame-based and MPLS simply inserts a 32-bit label between the layer-2 and layer-3 headers (“frame-mode” MPLS). ATM is a special case where fixed-length cells are used and a label cannot be inserted on every cell. MPLS uses the VPI/VCI fields in the ATM header as a label (“cell-mode” MPLS).
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-9
Label Format LABEL 0
EXP S 19 20
22 23 24
TTL 31
MPLS uses a 32-bit label field that contains the following information: • 20-bit label • 3-bit experimental field • 1-bit bottom-of-stack indicator • 8-bit time-to-live field (TTL)
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
A 32-bit label contains the following fields:
23-10
n
20-bit label: the actual label
n
3-bit experimental field: used to define a class of service (i.e. IP precedence)
n
Bottom-of-stack bit: MPLS allows multiple labels to be inserted; this bit is used to determine if this is the last label in the packet
n
8-bit time-to-live (TTL) field: has the same purpose as the TTL field in the IP header
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Frame Mode MPLS Frame header Layer 2
IP header
Payload
Layer 3
Routing lookup and label assignment
Frame header Layer 2
Label
IP header
Layer 2½
Payload
Layer 3
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The example in the figure shows an edge router that receives a normal IP packet. The router then performs the following actions: n
A routing lookup to determine the outgoing interface
n
A label is assigned and inserted between layer-2 frame header and layer-3 packet header if the outgoing interface is enabled for MPLS and a next-hop label for the destination exists
n
The labeled packet is sent
Other routers in the core simply forward the packet based on the label.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-11
Cell mode MPLS Frame header
IP header
Layer 2
Frame header Layer 2
Payload
Layer 3
Label
IP header
Layer 2½
Payload
Layer 3
VPI/VCI fields are used for label switching
Cell 1
ATM header
AAL5 header
Layer 2
Cell 2
ATM header
© 2001, Cisco Systems, Inc.
Label Layer 2½
IP header
Payload
Layer 3
Payload
IP QoS IP over MPLS
Cell-mode MPLS uses the ATM header’s VPI/VCI fields to make forwarding decisions while the 32-bit label is still preserved in the frame but not used in the ATM network. The original label is only present in the first cell of a packet.
23-12
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Label Switch Router MPLS Domain 10.1.1.1
20.1.1.1
Edge LSR
L=3
L=5
L=31
L=43
10.1.1.1
20.1.1.1
LSR
• Label Switch Router (LSR) primarily forwards labeled packets (label swapping) • Edge LSR primarily labels IP packets and forwards them into the MPLS domain, or removes labels and forwards IP packets out of the MPLS domain © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Before proceeding with a detailed description of MPLS, some of the terminology that is used in this course is presented: n
Label Switch Router (LSR): a device that primarily forwards packets based on labels.
n
Edge LSR: a device that primarily labels packets or removes labels.
LSRs and Edge LSRs are usually devices that are capable of doing both label switching and IP routing. Their names are based on their position in an MPLS domain. Routers that have all interfaces enabled for MPLS are called LSRs because they mostly forward labeled packets. Routers that have some interfaces that are not enabled for MPLS are usually at the edge of an MPLS domain (autonomous system). These routers also forward packets based on IP destination addresses and label them if the outgoing interface is enabled for MPLS.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-13
ATM Label Switch Router MPLS Domain 10.1.1.1
20.1.1.1
L=1/3
L=1/3
L=1/3
L=1/5
L=1/5
L=1/5
L=1/6 L=1/6
L=1/6
L=1/9 L=1/9
L=1/9
ATM Edge LSR
10.1.1.1
20.1.1.1
ATM LSR
• ATM LSR can only forward cells • ATM Edge LSR segments packets into cells and forwards them into an MPLS ATM domain, or reassembles cells into packets and forwards them out of an MPLS ATM domain © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Label Switch Routers that perform cell-mode MPLS are called:
23-14
n
ATM LSR if they are ATM switches. All interfaces are enabled for MPLS and forwarding is done based only on labels.
n
ATM Edge LSR if they are routers connected to an MPLS-enabled ATM network.
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Architecture of LSRs LSRs, regardless of the type, perform the following three functions: • Exchange routing information • Exchange labels • Forward packets (LSRs and edge LSRs) or cells (ATM LSRs and ATM edge LSRs)
The first two functions are part of the control plane The last function is part of the data plane © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
LSRs of all types must perform the following functions: n
Exchange layer-3 routing information (ATM LSRs must also exchange layer-3 routing information)
n
Exchange labels
n
Forward packets or cells
Frame-mode and cell-mode MPLS use a different data plane: n
Frame-mode MPLS forwards packets based on the 32-bit label
n
Cell-mode MPLS forwards packets based on labels encoded into the VPI/VCI fields in the ATM header
The control plane performs the following functions: n
Exchange routing information regardless of the type of LSR;
n
Exchange labels according to the type of MPLS (frame-mode or cell-mode);
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-15
Architecture of LSRs LSR Exchange of routing information
Control plane Routing protocol IP routing table
Exchange of labels
Incoming labeled packets
Label distribution protocol
Data plane Label forwarding table
Outgoing labeled packets
LSRs primarily forward labeled packets or cells (ATM LSRs) © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The primary function of an LSR is to forward labeled packets. Therefore, every LSR needs a layer-3 routing protocol (OSPF, EIGRP, IS-IS, etc.) and a label exchange protocol (LDP, TDP, etc.). The label exchange protocol populates the LFIB table in the data plane that is used to forward labeled packets. Note
23-16
LSRs may not be able to forward unlabeled packets either because they are ATM LSRs, or they do not have all the routing information.
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Architecture of Edge LSRs Edge LSR Exchange of routing information
Control plane Routing protocol IP routing table
Exchange of labels
Incoming IP packets Incoming labeled packets
Label distribution protocol
Data plane IP forwarding table Label forwarding table
Outgoing IP packets Outgoing labeled packets
Note: ATM edge LSRs can only forward cells © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Edge LSRs also forward IP packets based on their IP destination addresses and optionally label them if a label exists. The following combinations are possible: n
A received IP packet is forwarded based on the IP destination address and sent as an IP packet.
n
A received IP packet is forwarded based on the IP destination address and sent as a labeled packet.
n
A received labele d packet is forwarded based on the label; the label is changed and the packet is sent.
The following scenarios are possible if the network is misconfigured: n
A received labeled packet is dropped if the label is not found in the LFIB table even if the IP destination exists in the FIB table.
n
A received IP packet is dropped if the destination is not found in the FIB table even if there is a label-switched path available for the destination.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-17
Summary MPLS architecture is divided into two parts: n
Control plane that takes care of routing information and label propagation.
n
Data plane that takes care of the forwarding of packets.
MPLS has two modes: n
Frame-mode MPLS that is used on all frame-based media.
n
Cell-mode MPLS that is used in MPLS-enabled ATM networks.
MPLS networks use the following devices: n
Label Switch Router (LSR) to forward packets based on a 32-bit label
n
Edge LSR to forward labeled packets or label IP packets or remove labels.
n
ATM LSRs to forward cells based on labels encoded into the VPI/VCI fields in the ATM header.
n
ATM Edge LSRs that segment labeled or unlabeled packets into ATM cells where a label is encoded into VPI/VCI fields in the ATM header.
Review Questions 1. What are the main benefits of MPLS? 2. How is an MPLS label encoded into IP packets? 3. How are labels propagated?
23-18
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Frame-mode MPLS Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe the QoS possibilities in networks using Frame-mode MPLS
n
Use MQC to implement QoS with Frame-mode MPLS
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-19
MPLS QoS • MPLS uses labels to make a forwarding decision • The MPLS label is inserted between Layer-2 (frame) and Layer-3 (IP packet) headers • All Layer-3 information becomes invisible to routers in an MPLS domain • Classification in MPLS-enabled networks can be performed on: • MPLS experimental bits • MPLS labels (future enhancement)
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Frame-mode MPLS uses 32-bit labels primarily to make a forwarding decision. Three bits in the label are used for experimental purposes. When an IP packet enters an MPLS domain a label is inserted between the frame and the IP header. The MPLS experimental bits can be used for classification and marking purposes when implementing QoS in an MPLS domain. Future enhancements will allow multiple labels to be used to describe the quality of service.
23-20
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Label Assignment Frame Header
IP
Payload
IP precedece
MPLS exp
Frame Header
LABEL
IP
Payload
• An MPLS label has a three-bit experimental field • Cisco routers automatically copy IP precedence bits into the MPLS experimental bits • The Modular QoS CLI can be used to classify labeled packets based on their MPLS experimental bits © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The figure illustrates the default behavior of Cisco routers. IP precedence is automatically copied from the IP header into MPLS label’s experimental bits. The modular QoS CLI can be used to classify labeled packets based on MPLS experimental bits as well as mark labeled packets with MPLS experimental-bit values.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-21
MPLS-aware QoS Mechanisms • The following QoS mechanisms are MPLS aware: - Weighted Random Early Detection (WRED): MPLS experimental bits are used as weight in the same manner as IP precedence - Committed Access Rate (CAR): marking of MPLS experimental bits - Class-Based Policing: marking of MPLS experimental bits - Class-based Marking: marking of MPLS experimental bits
• If classification is performed based on MPLS experimental bits, other MQC QoS mechanisms can also be used
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The figure lists the QoS mechanisms that can interact with MPLS-specific information: n
WRED performs random drops based on MPLS experimental values.
n
CAR can mark labeled packets with MPLS experimental values. Conforming and exceeding packets can be marked with different MPLS experimental values.
n
Class-based Policing can mark labeled packets with MPLS experimental values. Conforming, exceeding and violating packets can be marked with different MPLS experimental values.
n
Class-based Marking can statically mark labele d packets with an MPLS experimental value.
Other QoS mechanisms (for example: CB-WFQ, CB-LLQ) can be used in combination with classification that is based on the value of the MPLS experimental bits.
23-22
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Configuring CB-WFQ for MPLS Router(config-cmap)#
match mpls experimental exp
• Classifies packets based on MPLS experimental bits class-map class-map match-any match-any Gold Gold match match ip ip precedence precedence 33 44 match match mpls mpls experimental experimental 33 44 !! class-map class-map match-any match-any Silver Silver match match ip ip precedence precedence 11 22 match match mpls mpls experimental experimental 11 22 !! policy-map policy -map IP+MPLS class class Gold bandwidth bandwidth 3000 class class Silver Silver bandwidth bandwidth 1000 1000 !! Interface Interface Ethernet0/0 Ethernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 mpls mpls ip ip service-policy output service-policy output IP+MPLS IP+MPLS !! © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Classification based on MPLS experimental bits is performed by using the match mpls experimental command in the class-map configuration mode. Up to eight values can be used within one class map. The sample configuration shows a generic class map using the match-any classification strategy to classify IP packets and labeled packets with the same IP precedence or MPLS experimental value.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-23
CAR Diagram Meter Meter
Conforms? Conforms?
Conform or exceed marking value
Transmit? Transmit?
Yes
Forward or Enqueue
No Mark? Mark? Set Set IP IP prec? prec? Set Set DSCP? DSCP? Set Set MPLS MPLS exp? exp? Set Set QoS QoS grp? grp?
Continue? Continue? Yes
Yes
Yes
Yes
Set Set IP IP Precedence Precedence Set Set DSCP DSCP
Yes
Go to Next CAR command
No Drop Drop
Set SetMPLS MPLSExperimental Experimental Set Set QoS QoS Group Group
• Marking depends on whether the packet conforms to or exceeds the policy © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Committed Access Rate (CAR) can be used to differentially mark packets based on the arrival rate of packets within the selected class. If a packet conforms (is within contract) it is marked with one value, if it exceeds it is marked with a different value. CAR also supports recursive processing of packets. One packet can be processed by multiple rate-limit commands.
23-24
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Configuring Configuring CAR for MPLS Router(config-if)# rate-limit {input | output} {access-group rate-limit rate-limit acl} acl} rate B CC BBEE conform-act {set-mpls-exp-transmit exp exp | set-mpls-exp-continue set-mpls-exp-continue exp} exp} exceed-act exceed-act {set-mpls-exp-transmit {set-mpls-exp-transmit exp | set-mpls-exp-continue exp}
• CAR can mark MPLS packets based on their arrival rate • CAR supports recursive processing of rate-limit commands • CAR supports classification based on MPLS experimental bit values by using rate-limit access list • Both conform and exceed actions support other actions: transmit, continue, drop, set-prec-transmit, set-prec-continue, … interface interface Serial0/0 Serial0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.252 255.255.255.252 rate-limit rate-limit input 64000 2000 2000 2000 conform conform set set-mpls-exp-tr -mpls-exp-tr 55 exceed exceed setsetmpls -exp-tr 0 mpls-exp-tr 0 rate-limit rate-limit output output 64000 64000 2000 2000 2000 2000 conform conform set-mpls-exp-tr set-mpls-exp-tr 55 exceed exceed set setmpls -exp-tr 00 mpls-exp-tr !!
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
CAR also supports a special rate-limit access list that can match labeled packets based on their MPLS experimental values. The action options include the two that can set MPLS experimental values: n
set-mpls-exp-continue: sets the MPLS experimental bits (0 to 7) and evaluates the next rate-limit command.
n
set-mpls-exp-transmit: set the MPLS experimental bits (0 to 7) and transmits the packet.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-25
Configuring CAR for MPLS Router(config)# access-list access-list rate-limit rate-limit acl {exp | mask mask mask} mask}
• The acl index must be between 200 and 299 to select the rate limit access list for MPLS experimental bits • Rate limit access lists can be used to match on one or more MPLS experimental values • Set one value (exp) to be matched or use the mask option to match on more values • Each access list can have only one line interface interface Serial0/0 Serial0/0 rate-limit rate-limit output access-group access-group rate-limit 200 64000 64000 2000 2000 2000 conform conform transmit transmit exceed exceed drop drop rate-limit rate-limit input input access-group access-group rate-limit rate-limit 201 201 64000 64000 2000 2000 2000 2000 conform conform setsetmpls-exp-tr mpls-exp-tr 00 exceed exceed set-mpls-exp-tr set-mpls-exp-tr 00 !! access-list access-list rate-limit rate-limit 200 200 22 access-list access-list rate-limit rate-limit 201 201 mask mask FE !! © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Special rate-limit access lists allow high-performance classification based on the following parameters: n
IP precedence value if the number of the access list is in the range from 1 to 99
n
MAC address if the number of the access list is in the range from 100 to 199
n
MPLS experimental bits if the number of the access list is in the range from 200 to 299
A rate limit access list can have only one line. A single MPLS experimental value can be matched by setting the exp value. Multiple values can be matched by using the mask keyword and applying a mask in hex. This mask is an 8 bit value where each bit corresponds to one experimental value 0 through 7. The low order bit corresponds to value 0 and the high-order bit corresponds to value 7. Setting the bit value to 1 indicates that the corresponding experimental value is a match; setting the value to 0 indicates that the corresponding value is not a match. A combination of bits in the mask can be used to match on any number of MPLS experimental values. For example, to match an experimental value of 0, the mask would be 01 (0000 0001 binary). To match a value of 5, the mask would be 20 (0010 0000 binary). The second rate-limit command in the sample configuration above uses the mask FE (1111 1110 binary) to match all MPLS experimental values except value 0.
23-26
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
CB-Policing • CB-Policing is similar to CAR except: - It uses the Modular QoS CLI for classification - It supports three different actions (conform, exceed and violate) - It does not support recursive processing of packets
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Class-based Policing is used for the same purpose as CAR. CB-Policing differs from CAR in the following ways: n
The Modular QoS CLI is used to classify packets.
n
It can use two token buckets to determine whether a packet conforms to, exceeds or violates the policy.
n
It does not support recursive processing of packets (the continue option is not available).
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-27
Configuring Configuring CB-Policing for MPLS Router(config-pmap-c)#
police avg-rate [BCC [BE]] [conform-action [conform-action [action] [exceed-action [action] [action] [violate-action [action]]]] [action]]]]
• avg-rate – traffic rate in bps (8.000 to 200.000.000) • BC – normal burst size dimensions the first token bucket in bytes (default is 1500 or avg-rate/32; whatever is higher) • BE – excess burst size dimensions the second token bucket in bytes (equals BC if not configured) • action – can be: -
transmit (default conform action) drop (default exceed and violate action) set-prec-transmit ip-precedence set-dscp-transmit dscp set-qos-transmit qos-group set-mpls-exp-transmit mple-exp set frde-transmit set-clp-transmit
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The figure shows that one of several actions can be used to mark labeled packets with an MPLS experimental value. Three different values can be used within a single class depending on whether a packet conforms to, exceeds or violates the policy.
23-28
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
CB Marking • Class-based Marking can be used to mark labeled packets by setting the MPLS experimental bits • MPLS experimental bits can currently only be set on input • DSCP should be translated to IP precedence prior to entry into an MPLS domain
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Class-based Marking can use the classification options available in the Modular QoS CLI and statically mark classes with the MPLS experimental values. Implementation limitations should be considered when translating between any pair of parameters on MPLS domain borders (DSCP to MPLS, IP precedence to MPLS). MPLS marking is currently only supported on input. Inbound IP packets can be directly marked with MPLS experimental values. Using the QoS group parameter is necessary when translating MPLS experimental values back to IP precedence or DSCP (for example: MPLS to QoS group translation on input and QoS group to DSCP translation on output). This functionality and these limitations may change with new IOS versions.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-29
Configuring MPLS Marking Router(config-pmap-c)#
set mpls experimental exp-bits
• Mark labeled packets with the specified value (0 to 7) • MPLS marking can only be used on input policy-map policy-map SetMPLS SetMPLS class class Class1 Class1 qos-group qos-group set mpls mpls experimental experimental class class Class2 Class2 qos-group qos-group set mpls mpls experimental experimental class class Class3 Class3 qos-group qos-group set mpls mpls experimental experimental !!
© 2001, Cisco Systems, Inc.
11 11 22 22 22 33
IP QoS IP over MPLS
Use the set mpls experimental command in the policy-map class configuration mode to mark inbound packets with MPLS experimental values. The sample configuration shows how a QoS group parameter can be translated into MPLS experimental bits.
23-30
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Translation Case Study IP Domain MPLS Domain
• IP domain is using the DiffServ model: -
EF – Class Premium AF1 – Class Gold AF2 – Class Silver Default – Best effort class
• Translate IP DSCP values to and from MPLS experimental bits to achieve a similar result in the MPLS domain © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The QoS design in the case study uses DSCP to mark packets. Four classes must also be managed in the MPLS domain. A translation between DSCP and MPLS is needed to implement a similar QoS solution in the MPLS domain. Although standard DSCP values for AF classes seamlessly map to IP precedence values for backward compatibility it is sometimes necessary to manually translate markers between DSCP an IP precedence or DSCP and MPLS. For example: n
n
A QoS design based on IP precedence is using two IP precedence values to mark packets belonging to one class: -
Class Premium is marked with IP precedence 5 and is guaranteed low latency
-
Class Gold is using IP precedence 4 for conforming (low-drop) packets and IP precedence 3 for exceeding (high-drop) packets
-
Class Silver is using IP precedence 2 for conforming (low-drop) packets and IP precedence 1 for exceeding (high-drop) packets
-
Best effort traffic is marked with IP precedence 0
When migrating to DSCP-based implementation it is necessary to still support the old QoS design until the entire network is migrated to support DSCP.
The case study shows how this translation can be done manually. If the original IP-precedence-based design did not use multiple IP precedence values per class there should be no need to configure the translation manually. All class-maps, however, should include class selectors in their match options to support backward compatibility with IP precedence: n
Copyright 1999, Cisco Systems, Inc.
Matching packets for AF1 requires af11, af12, af13 and cs1 to be matched
Release Date: 2/1/99
23-31
n
Matching packets for AF2 requires af21, af22, af23 and cs2 to be matched
n
Matching packets for AF3 requires af31, af32, af33 and cs3 to be matched
n
Matching packets for AF4 requires af41, af42, af43 and cs4 to be matched
n
Matching packets for EF requires ef and cs5 to be matched
The solution shown on the following pages illustrates how default behavior can be changed by manually configuring the translation between IP precedence (MPLS experimental bits) and the DSCP.
23-32
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Translation Case Study Design DSCP
IP precedence QoS group
IP Domain
© 2001, Cisco Systems, Inc.
MPLS exp MPLS Domain
IP DSCP
MPLE experimental
EF AF1 low-drop AF1 medium-drop AF1 high-drop AF2 low-drop AF2 medium-drop AF2 high-drop Default
5 4 4 3 2 2 1 0 IP QoS IP over MPLS
The figure illustrates how DSCP values should be mapped to IP precedence or MPLS experimental values. Some information is lost because low-drop and medium-drop packets of AF1 and AF2 are marked as one low-drop class in the MPLS domain. The case study shows how some information about the conforming and exceeding packets within one class can be retained when entering a non-DSCP part of the network (either because routers do not support DSCP or because MPLS experimental bits are used to select Class of Service). The figure illustrates the translation from three drop probability levels on the DSCP layer into two drop probability level in the IP precedence (MPLS experimental) layer. Using this design further limits the network to only use two classes for AF PHB.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-33
MPLS Translation Case Study Implementation IP precedence DSCP IP Domain class-map class-map EF EF match match ip ip dscp dscp ef ef class-map class-map AF1LD AF1LD match match ip ip dscp dscp af11 af11 af12 af12 class-map class-map AF1HD AF1HD match match ip ip dscp dscp af13 af13 !! policy-map policy-map DSCP2prec DSCP2prec class class EF EF set set ip ip precedence precedence 55 class class AF1LD AF1LD set set ip ip precedence precedence 44 class class AF1HD AF1HD set set ip ip precedence precedence 33 !! © 2001, Cisco Systems, Inc.
MPLS exp MPLS Domain
interface interface Serial5/1/0 Serial5/1/0 service-policy service-policy input DSCP2prec !!
IP QoS IP over MPLS
The first part of the configuration shows how DSCP is translated to IP precedence on ingress into the MPLS network. IP precedence is then automatically copied into MPLS experimental bits. The default DSCP value equals the default IP precedence value and does not need to be translated. The EF class does not need to be translated either because the EF value (101110) is copied as IP precedence into the MPLS experimental field (101), which equals 5. The configuration for AF2 is not shown in the figure.
23-34
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
MPLS Translation Case Study Implementation QoS group DSCP
MPLS exp
IP Domain class-map class-map match-any match-any MPLS5 MPLS5 match match mpls exp 5 match match ip ip precedence precedence 5 5 class-map class-map match-any match-any MPLS4 MPLS4 match match mpls mpls exp exp 4 match match ip precedence 4 class-map class-map match-any match-any MPLS3 MPLS3 match match mpls mpls exp exp 3 match match ip ip precedence precedence 3 3 !! policy-map MPLS2QoS policy-map class class MPLS5 set set qos-group qos-group 5 class class MPLS4 set set qos-group qos-group 4 4 class class MPLS3 MPLS3 set set qos-group qos-group 3 © 2001, Cisco Systems, Inc.
MPLS Domain class-map class-map QoS5 QoS5 match match qos-group qos-group 55 class-map class-map QoS4 QoS4 match match qos-group qos-group 44 class-map class-map QoS3 QoS3 match match qos-group qos-group 33 !! policy-map policy-map QoS2DSCP class class QoS5 QoS5 set set ip ip dscp dscp ef ef class QoS4 class QoS4 set set ip dscp dscp af12 af12 class class QoS3 QoS3 set set ip dscp dscp af13 af13 !!
interface interface Serial5/1/1 Serial5/1/1 service-policy service-policy input input MPLS2QoS MPLS2QoS !! interface interface Serial5/1/0 Serial5/1/0 service-policy service-policy output output QoS2DSCP QoS2DSCP
IP QoS IP over MPLS
The remainder of the configuration is used to translate MPLS experimental values back into DSCP. The class-maps are configured to process IP packets (very likely due to penultimate hop popping) or labeled packets. Low-drop packets are translated into medium-drop packets in the DiffServ domain.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-35
Summary Frame-mode MPLS allows most IP QoS mechanisms to be used. The three MPLS experimental bits are used in the same way as IP precedence. IP precedence is actually copied into MPLS experimental bits.
Review Questions 1. Which MPLS parameter is used for classification and marking? 2. What is the default value of the MPLS experimental bits? 3. Which QoS mechanisms can be used to set MPLS experimental bits?
23-36
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Cell-mode MPLS Objectives Upon completion of this lesson, you will be able to perform the following tasks: n
Describe QoS features available with Cell-mode MPLS
n
Implement QoS on interfaces using Cell-mode MPLS
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-37
Cell-mode MPLS QoS • Classes are encoded with MPLS experimental bits • Cell-mode MPLS uses the VPI/VCI fields as labels for forwarding • ATM switches are not capable of looking into the frame-mode label where the experimental bits are • QoS is implemented using up to four parallel virtual circuits (label-switched paths)
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
ATM is a Layer-2 technology that does not use frames to transmit Layer-3 packets. Packets are fragmented into fixed-length cells. Cell-mode MPLS makes use of the ATM header to encode labels into VPI/VCI fields. These fields are only used to make a forwarding decision. QoS cannot be achieved using MPLS experimental bits because: n
They are only propagated in the first cell of a packet.
n
ATM switches do not look into the payload of cells.
QoS is therefore achieved using multiple labels (up to four).
23-38
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Cell-mode MPLS
Cell-mode MPLS Frame-mode MPLS Native IP
• IP precedence used in IP domain is automatically translated into MPLS experimental bits • MPLS experimental bits are optionally translated into up to four parallel virtual circuits (label-switched paths) © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The figure illustrates how IP packets can be propagated over a native IP network (no MPLS and no ATM or with ATM PVCs), a frame-based MPLS network and a cell-based MPLS network. QoS is retained when IP packets enter a frame-based MPLS network by copying the IP precedence bits into MPLS experimental bits. When labeled packets enter a cell-based MPLS network, QoS is retained by forwarding the packet through one of four VCs, which are based on the value of MPLS experimental bits.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-39
Configuring Multi-VC Router(config-if)#
mpls atm multi-vc
• The command enables Multi-VC operation of cell-mode MPLS • Eight MPLS experimental values are mapped to four virtual circuits • The class is determined by the two least significant MPLS experimental bits • Default mapping is similar to classification of distributed ToS-based WFQ • Default mapping can be replaced using the cos-map command
© 2001, Cisco Systems, Inc.
MPLS exp VC 0 1 2 3 4 5 6 7
Available Standard Premium Control Available Standard Premium Control
IP QoS IP over MPLS
Cell-mode MPLS uses one single VC for each IP destination. Use the mpls atm multi-vc interface command to enable routers to request up to four VCs for each IP destination. Classification is based on the low-order two bits of the MPLS experimental field (like ToS-based dWFQ). The table in the figure shows the default mapping of MPLS values into four VCs: available, standard, premium and control. Default mapping can be changed using the mpls cos-map and mpls prefix-map commands.
23-40
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Configuring CoS Mapping Router(config)#
mpls mpls cos-map number
• Create a CoS map • Allowed values are from 1 to 255 Router(config-mpls-cos-map)#
class class {available | control | premium | standard}
• Assigns a class to one of four virtual circuits • Class values can be in the range from 0 to 3 Router(config)#
mpls mpls prefix-map pfmap access-list acl cos-map cos-map
• Uses CoS map cos-map for all destinations permitted by access list acl © 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
A CoS map must be configured to change the default behavior of the translation of MPLS experimental values into one of four virtual circuits (available, standard, premium and control). Classes are identified by the two low-order bits of the MPLS experimental field. Use the mpls prefix-map command to bind a cos-map to all destinations permitted by the acl access list. Note
Copyright 1999, Cisco Systems, Inc.
Most MPLS-related commands are available with the starting keyword mpls or the older tag-switching version. Furthermore, using the mpls keyword results in the command being automatically translated into the tag-switching version for compatibility with older IOS versions.
Release Date: 2/1/99
23-41
Configuration Example tag-switching prefix-map 10 access-list 100 cos-map cos-map 10 tag-switching prefix-map 11 access-list 101 cos-map cos-map 10 tag-switching prefix-map 21 access-list access-list 32 cos-map 34 34 ! tag-switching cos-map cos-map 10 10 class class 00 available class class 1 standard class class 22 premium premium class class 33 control control ! interface interface ATM1/0.1 ATM1/0.1 mpls ip ip unnumbered unnumbered Loopback0 Loopback0 no no ip ip mroute-cache mroute-cache mpls mpls atm atm multi-vc multi-vc mpls mpls ip ! access-list 100 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
The sample configuration shows that all traffic to network 10.0.0.0/8 uses four parallel VCs. MPLS experimental bits are mapped using cos-map 10. Note that only prefix map 10 is properly configured. Prefix map 11 does not have the corresponding access list and prefix map 21 is missing the CoS map as well.
23-42
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Monitoring and Troubleshooting Cell-mode MPLS Router#
show mpls cos-map [cos-map]
• Lists all configured CoS maps Router#show Router#show mpls mpls cos-map 10 cos-map class tag-VC cos-map 10 tag-VC 33 control control 22 premium premium 11 standard standard 00 available available Router# Router#
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Use the show mpls cos-map command to verify the parameters assigned to a cos-map.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-43
Monitoring and Troubleshooting Cell-mode MPLS Router#
show mpls prefix-map [prefix-map]
• Lists all configured prefix maps Router#show Router#show mpls mpls prefix-map prefix-map prefix-map prefix-map 10 10 access-list access-list 100 100 cos-map cos-map 10 10 prefix-map prefix-map 11 11 access-list access-list 101 101 cos-map cos-map 10 10 Warning: Warning: In prefix-map prefix -map 11, 11, acl acl 101 101 is is not not configured configured prefix-map prefix-map 21 21 access-list access-list 32 32 cos-map cos-map 34 Warning: Warning: In prefix-map prefix -map 21, 21, acl acl 32 32 and and cos-map cos-map 34 34 are are not not configured configured Router# Router#
© 2001, Cisco Systems, Inc.
IP QoS IP over MPLS
Use the show mpls prefix-map command to display one or all configured prefix maps with their corresponding access lists and cos-maps. Using this command helps determine if there is a component missing:
23-44
n
Access list 101 is not configured for prefix map 11
n
Prefix map 21 is missing both the access list and the CoS map
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Summary Cell-mode MPLS uses up to four virtual circuits to achieve differentiated quality of service. Packets are classified based on the two low-order bits of the MPLS experimental field.
Review Questions 1. How is differentia ted QoS implemented on MPLS-enabled ATM interfaces? 2. What information is used for classification in cell-mode MPLS?
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-45
Summary After completing this module, you should be able to perform the following tasks:
23-46
n
Describe and configure QoS Mechanisms in Frame-mode MPLS networks
n
Describe and configure QoS Mechanisms in Cell-mode MPLS networks
World Wide Training Word Templates v1
Copyright 1999, Cisco Systems, Inc.
Review Questions and Answers MPLS Introduction Question: What are the main benefits of MPLS? Answer: Simplified BGP designs, support for MPLS-based VPNs. Question: How is an MPLS label encoded into IP packets? Answer: A 32-bit label header is inserted in front of the IP header. Question: How are labels propagated? Answer: Labels are propagated between adjacent routers using TDP or LDP.
Frame-mode MPLS Question: Which MPLS parameter is used for classification and marking? Answer: The MPLS experimental bits are used to classify and mark labeled packets. Question: What is the default value of the MPLS experimental bits? Answer: Cisco routers copy the IP precedence bits into MPLS experimental bits. Question: Which QoS mechanisms can be used to set MPLS experimental bits? Answer: CAR, Class-based Policing and Class-based Marking.
Cell-mode MPLS Question: How is differentiated QoS implemented on MPLS-enabled ATM interfaces? Answers: By using up to 4 VCs (labels) for each destination. Question: What information is used for classification in cell-mode MPLS? Answers: Classification is performed based on the two low-order IP precedence bits.
Copyright 1999, Cisco Systems, Inc.
Release Date: 2/1/99
23-47
Related Documents
Cisco Introduction Ip Qos (course)
December 2019 9
Mobile Ip Cisco
November 2019 10
Telefonia Ip Cisco Sena
April 2020 10
Cisco Requirement Ip Telephony
May 2020 4
Cisco Ip Phone Integration
June 2020 15