Quality of Service

Quality of Service
Srinath Beldona
Practice Head IP – NGN Business
[email protected]
1 © 2012 WIPRO LTD | WWW.WIPRO.COM

Understanding the need for QOS
Before Converged Networks

Converged Networks

Converged Networks: Quality Issues

Converged Networks: Quality Issues
• Lack of bandwidth: multiple flows compete for a limited

amount of bandwidth
• End-to-end delay (fixed and variable): packets have to
traverse many network devices and links that add up to
the overall delay
• Variation of delay (jitter): sometimes there is a lot of other
traffic, which results in more delay
• Packet Loss: packets may have to be dropped when a
link is congested

Lack of Bandwidth

Ways to Increase Available Bandwidth

End-to-End Delay

Types of Delay

Ways to Reduce Delay

Packet Loss

Ways to Prevent Packet Loss

Quality Of Service Defined

QoS for Converged Networks

Steps to Implementing QoS on a Network
• A one-to-one mapping between traffic classes and QoS

policies need not be made. For example, three QoS
policies could be implemented to meet the requirements
of the four traffic classes defined above:
• NoDelay: Assign to voice traffic
• Best Service: Assign to high-priority traffic
• Whenever: Assign to both the low priority and browser
traffic

Step 1: Identify Traffic and Its Requirements

QoS Traffic Requirements: Voice

QoS Requirements: Videoconferencing

QoS Traffic Requirements: Data

Step 2: Divide Traffic into Classes

Classification of Traffic
• A typical enterprise might define five traffic classes as

follows:
• Voice: Absolute priority for Voice over IP (VoIP) traffic
• Mission critical: Small set of locally defined critical
business applications
• Transactional: Database access, transaction services,
interactive traffic, preferred data
• services
• Best effort: Internet, e-mail
• Scavenger (less-than-best-effort): Napster, Kazaa, and
other point-to-point applications

Step 3: Define Policies for Each Traffic Class

Defining QoS Policies
• Using the traffic classes previously defined, QoS
policies could be determined as follows :
• Voice: Minimum bandwidth 1 Mbps. Use QoS marking to
mark voice packets as priority 5; use LLQ to always give
voice priority.
• Mission critical: Minimum bandwidth 1 Mbps. Use QoS
marking to mark critical data packets as priority 4; use
CBWFQ to prioritize critical class traffic flows.
• Best effort: Maximum bandwidth 500 kbps. Use QoS
marking to mark these data packets as priority 2; use
CBWFQ to prioritize best-effort traffic flows that are below
mission critical and voice.
• Scavenger: Maximum bandwidth 100 kbps. Use QoS
marking to mark less-than-best effort (scavenger) data
packets as priority 0; use WRED to drop these packets
whenever the network has a propensity for congestion.
QoS Policy: ABC Corporation
A network-wide definition of the specific levels of quality of
service assigned to different classes of network traffic
Application Priority
Voice and Video Quality Absolute Priority
ERP System Business Critical
Manufacturing System Business Critical
Internal Email and other Tools Business Best effort
Internet Access Best effort ( Lowest Priority)

QoS Policy (Cont.)

Methods for Implementing QoS Policy
• Command Language Interface (CLI)

• Modular QOS CLI (MQC)
• AutoQoS
• Quality of Service Policy Manager (QPM)

Implementing QoS with CLI

Modular QoS CLI

Implementing QoS with AutoQoS

Comparing Methods for Implementing QoS

QoS Policy Manager

Cisco AutoQoS with CiscoWorks QPM

Network MIBs for Monitoring QoS

MIBs for Managing QoS

QPM: Monitoring and Reporting with CBQoSMIB

Cisco NBAR Protocol Discovery MIB

Models for Implementing QOS

Models for Implementing QoS
Model Features
Best-Effort model Designed for best-effort, no-guarantee delivery of
packets
Integrated Services Sets aside some bandwidth for applications that

(IntServ) model require bandwidth and delay guarantees. IntServ
expects applications to signal their requirements to
the network.
Differentiated Was added to provide greater scalability in providing
Services (DiffServ) QoS to IP packets.
model
The main difference between the IntServ and DiffServ models is that in
DiffServ, the network recognizes packets (no signaling is needed) and
provides the appropriate services to the packets. IP networks today can use
all three models at the same time.
Three Models for Quality of Service
Model Method
Best Effort No QoS is applied to packets
IntServ Applications signal to the network that they

require special QoS
DiffServ The network recognizes classes that
require special QoS

Best-Effort Model

Best-Effort Model (Cont.)
• Benefits:
• Highly scalable
• No special mechanisms required
• Drawbacks:
• No service guarantees
• No service differentiation

IntServ Model

IntServ Model

IntServ Model (Cont.)


• 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)
• Drawbacks:
• Continuous signaling because of stateful architecture
• Flow-based approach not scalable to large
implementations such as the public Internet (can be made
more scalable when combined with elements of the
DiffServ Model)

DiffServ Model

DiffServ Model

DiffServ Model (Cont.)
• Benefits:
• Highly scalable
• Many levels of quality possible
• Drawbacks:
• No absolute service guarantee
• Complex mechanisms

Understanding the DiffServ Model

Differentiated Services Model
• The DiffServ architecture is based on a simple model in which
traffic entering a network is classified and possibly conditioned
at the boundaries of the network.
• The traffic class is then identified with a DSCP or bit marking in
the IP header.
• The Differentiated Services model describes services
associated with traffic classes
• DSCP values are used to mark packets to select a per-hop
behavior (PHB).
• Within the core of the network, packets are forwarded
according to the PHB that is associated with the DSCP
• No per-flow state in the core
• The core only performs simple “per-hop behaviors” on traffic
aggregates.
51
• The primary advantage of DiffServ is scalability
© 2012 WIPRO LTD | WWW.WIPRO.COM
Diffserv Architecture – RFC2475
Diffserv Domain
VoIP Bus Internet
RT
Packet “colour” Bus
In DSCP
Classification and Std
conditioning (meter,
Aggregate PHBs in
marking, policing) at
CORE (EF, AF, Default)
EDGE
Differentiated Services Model (Cont.)
• Wide variety of services and provisioning policies

• Decouple service and application in use
• No application modification
• No hop-by-hop signaling
• Interoperability with non-DiffServ-compliant nodes
• Incremental deployment

DSCP Encoding

Per-Hop Behaviors

Per-Hop Behaviors (Cont.)




• A DiffServ 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.

Backward Compatibility Using the Class Selector

Quality of Service Mechanisms

QoS Mechanisms
• Classification: Each class-oriented QoS mechanism has to
support some type of classification.
• Marking: This is used to mark packets based on
classification and metering or both.
• Congestion Management: Each interface must have a
queuing mechanism to prioritize transmission of packets.
• Congestion Avoidance: This is used to drop packets early to
avoid congestion later in the network.
• Policing and Shaping: This is used to enforce a rate limit
based on the metering (excess traffic is either dropped,
marked, or delayed).
• Link Efficiency: This is used to improve bandwidth efficiency
through compression and link fragmentation and interleaving

Classification

Marking

Congestion Management

Congestion Avoidance

Policing

Shaping

Policing and Shaping
• Policing • Shaping
• Drops out-of-profile traffic • Reduces bursts by queuing
(TCP retransmissions) out-of-profile traffic
• More resource efficient • Minimizes TCP retransmits
• Supports incoming and • Only for outbound interfaces
outgoing interfaces • Does not support (re-)marking
• Supports (re-)marking • "Delay instead drop"

Compression

Link Fragmentation and Interleaving

Applying QoS to Input and Output Interfaces

DiffServ Model: Life of a Packet

Overview

Life of a High-Priority (VoIP) Packet

Life of a High-Priority (VoIP) Packet (Contd.)

Life of a High-Priority (VoIP) Packet (Cont.)







Life of a Low-Priority (FTP) Packet

Life of a Low-Priority (FTP) Packet (Cont.)


CoS-to-DSCP Mapping in Catalyst 2950 Switch








Queuing

Introduction to Queuing
• Queuing algorithms are one of the primary ways to manage

congestion in a network.
• Network devices handle an overflow of arriving traffic by using
a queuing algorithm to sort traffic and determine a method of
prioritizing the traffic onto an output link.
• Each queuing algorithm was designed to solve a specific
network traffic problem and has a particular effect on network
performance.

Congestion and Queuing

Congestion and Queuing: Speed Mismatch

Congestion and Queuing Aggregation

Queuing Algorithms
• First In First Out (FIFO)

• Priority Queuing (PQ)
• Round robin (RR)
• Weighted Round Robin (WRR)
• Deficit Round Robin (DRR)

FIFO Queuing

Priority Queuing

Round Robin

Weighted Round Robin

Weighted Round Robin (Cont.)

Deficit Round Robin
• Solves problem with some implementations of WRR
described on previous slide
• Keeps track of the number of “extra” bytes dispatched in
each round the “deficit”
• Adds the “deficit” to the number of bytes dispatched in the
• next round
• Problem from previous slide resolved with deficit round
robin:
• –Threshold of 3000
• –Packet sizes of 1500, 1499, and 1500
• –Total sent in round = 4499 bytes
• –Deficit = (4499 – 3000) = 1499 bytes
• –On the next round send only the (threshold – deficit) = (3000 –
1499) = 1501 bytes

Queuing Components

Queuing Components (Cont.)

The Software Queue

Hardware Queue (TxQ) Size
• Routers determine the length of the hardware queue
based on the configured bandwidth of the interface.
• The length of the hardware queue can be adjusted with
the tx-ring limit command.
• Reducing the size of the transmit ring has two benefits:
• It reduces the maximum amount of time packets wait in the
FIFO queue before being transmitted.
• It accelerates the use of QoS in the Cisco IOS software.
• Improper tuning of the hardware queue may produce
undesirable results:
• 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.
Congestion on Software Interfaces
• Sub-interfaces and software interfaces do not have their

own separate tx ring, therefore no congestion can occur.
• Dialers, tunnels, Frame Relay sub-interfaces
• They congest when their main hardware interface tx-ring
congests
• The tx-ring state(full, not full) is, therefore, an indication of
congestion for software interfaces.
• Only hardware interfaces have a tx-ring.

FIFO Queuing

FIFO Queuing (Cont.)
• 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
• Causes starvation(aggressive flows can monopolize links)
• Causes jitter (bursts or packet trains temporarily fill the queue)

Weighted Fair Queuing
• A queuing algorithm should share the bandwidth fairly

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
• In the WFQ 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 to give
proportionately more bandwidth to flows with higher IP
precedence (lower weight).

WFQ Architecture

WFQ Implementations
• Implementation parameters
• Queuing platform: central CPU or VIP
• Classification mechanism
• Weighted fairness
• Modified tail drop within each queue

WFQ Classification

WFQ Classification (Cont.)
• A fixed number of per-flow queues is configured.

• A hash function is used to translate flow parameters into a
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

Dynamic queues and interface Bandwidth

WFQ Insertion and Drop Policy
• WFQ has two modes of dropping:

• Early dropping when the congestion discard threshold is reached
• Aggressive dropping when the hold-queue out limit is reached
• WFQ always drops packets of the most aggressive flow
• Drop mechanism exceptions
• Packet classified into an empty sub-queue is never dropped

WFQ Insertion and Drop Policy (Cont.)

Finish Time Calculation

Weight in WFQ Scheduling

Finish Time Calculation with Weights

IP Precedence to Weight Mapping

WFQ 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.

WFQ Case Study Interface Congestion

WFQ Case Study Interface Congestion (Cont.)

WFQ Case Study Flow Congestion

WFQ Case Study Flow Congestion (Cont.)

Benefits and Drawbacks of WFQ
• 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
• Drawbacks
• Multiple flows can end up in one queue
• Does not support the configuration of classification
• Cannot provide fixed bandwidth guarantees
• Complex classification and scheduling mechanisms

CB-WFQ and LLQ

Class Based WFQ & Low Latency Queuing
• Class-based weighted fair queuing (CBWFQ) extends the

standard WFQ functionality to provide support for user-
defined traffic classes.
• With CBWFQ, you define traffic classes based on match
criteria including protocols, access control lists (ACLs),
and input interfaces and IP Precedence and DSCP values.
• 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 the queue for that class.
• Low-latency queuing (LLQ) brings strict priority queuing to
CBWFQ

CBWFQ and LLQ

Class-Based Weighted Fair Queuing
• CBWFQ is a mechanism that is used to guarantee

bandwidth to classes.
• CBWFQ 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 queue.

CBWFQ Architecture

CBWFQ Architecture: 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 discard eligible 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.

CBWFQ Architecture: Insertion Policy
• Each queue has a maximum number of packets that it

can hold (queue size).
• The maximum queue size is platform-dependent.
• After a packet is classified to one of the queues, the
router will enqueue the packet if the queue limit has not
been reached (tail-drop within each class).
• WRED can be used in combination with CBWFQ to
prevent congestion of the class

CBWFQ Architecture: Scheduling
• CBWFQ guarantees bandwidth according to weights

assigned to traffic classes.
• Weights can be defined by specifying:
• Bandwidth (in kbps)
• Percentage of bandwidth(percentage of available interface
bandwidth)
• Percentage of remaining available bandwidth
• One service policy can not have mixed types of weights.
• The show interface command can be used to display the
available bandwidth.

CBWFQ Architecture: Available Bandwidth

CBWFQ Architecture: 75 Percent Rule

CBWFQ Benefits
• Benefits
• Minimum bandwidth allocation
• Finer granularity and scalability
• MQC interface easy to use
• Maximizes transport of priority traffic
• Weights guarantee minimum bandwidth
• Unused capacity shared among the other classes
• Queues separately configured for QoS
• Drawbacks
• Voice traffic can still suffer unacceptable delay

Low-Latency Queuing
• Priority queue added to CBWFQ for real-time traffic

• High-priority classes are guaranteed:
• –Low-latency propagation of packets
• –Bandwidth
• High-priority classes are also policed when congestion
occurs
• – they can then not exceed their guaranteed bandwidth
• Lower priority classes use CBWFQ

LLQ Architecture

LLQ Benefits
• Benefits
• High-priority classes are guaranteed:
• Low-latency propagation of packets
• Bandwidth
• Consistent configuration and operation across all media
types
• Entrance criteria to a class can be defined by an ACL
• Not limited to UDP ports as with IP RTP priority
• Defines trust boundary to ensure simple classification and entry
to a queue

Scheduling Tools
Queuing Algorithms
Voice 1 1 1 11
1 1 1 1 1 1 1 1 1 1 1 1 1
Video 1 1 1 1 2 12
3
Data 1 1 1 1 1 1 13
• The objective of queuing algorithms are to manage

congestion
• And provide packet scheduling based on flow
requirements

Congestion management
Congestion occurs when …

• Output interface (pos, Eth, serial) driver is ‘full’ (speed mismatch)
• When shaper is ‘active’
• When ATM PVC is ‘full’

Tx-ring vs Tx-queue
Forwarder
Interface Yes
Congested?
FIFO/PQ/CQ/WFQ (output hold-queue
interface ‘hold’ compromise
No latency/buffering )
Tx-Queues
Transmission
Queue (tx-ring)
Tx-ring (intf driver queue)Always FIFO

(in particles or packets, platform dependant !)
Changed w/ Tx-ring-limit or
show vip tx-polling-high <interface> <new-tx-polling-high> on vip
tx-ring vs tx-queue
• Tx-ring is the ‘driver queue’ (mainly in particles)

• Tx-queues used ONLY when tx-ring is full (in
packets)
• Tx-ring configurable (platform/adapter
dependant, PA-A3) high enough to
accommodate line rate, short enough to reduce
latency (tune carefully)
• Tx-ring tuned automatically when fancy queuing
configured (CSCdk17210)
• Tx-queue default 64 on low-end, on VIP
default=Bw/4000 (500ms of 250B packets, min=2)
Classification, Policing and Shaping

Voice QoS Requirements
Provisioning for Voice
• Latency ≤ 150 ms
One-Way
Voice
• Jitter ≤ 30 ms Requirements
• Loss ≤ 1%
• 17–106 kbps guaranteed priority
bandwidth per call
• 150 bps (+ Layer 2 overhead)
guaranteed bandwidth for Voice- • Smooth
Control traffic per call • Benign
• Drop sensitive
• CAC must be enabled • Delay sensitive
• UDP priority

Video QoS Requirements
Provisioning for Interactive Video
• Latency ≤ 150 ms One-Way

Video
• Requirements
Jitter ≤ 30 ms
• Loss ≤ 1%
• Minimum priority bandwidth guarantee
required is:
–Video-stream + 20%
–e.g. a 384 kbps stream would • Bursty
require 460 kbps of priority • Greedy
bandwidth • Drop sensitive
• CAC must be enabled • Delay sensitive
• UDP priority

Data QoS Requirements
Provisioning for Data
• Different applications have different
traffic characteristics Data
• Different versions of the same
application can have different traffic
characteristics
• Classify data into four/five
data classes model:
–Mission-critical apps • Smooth/bursty
–Transactional/interactive apps • Benign/greedy
–Bulk data apps • Drop insensitive
–Best effort apps • Delay insensitive
• TCP retransmits
–Optional: Scavenger apps

Data QoS Requirements
Provisioning for Data (Cont.)
• Use four/five main traffic classes:
Mission-critical apps—business-critical client-server applications
Transactional/interactive apps—foreground apps: client-server
apps or interactive applications
Bulk data apps—background apps: FTP, e-mail, backups,
content distribution
Best effort apps—(default class)
Optional: Scavenger apps—peer-to-peer apps, gaming traffic
• Additional optional data classes include internetwork-control (routing)
and network-management
• Most apps fall under best-effort, make sure that adequate bandwidth
is provisioned for this default class

Quality of Service Operations
How Do QoS Tools Work?
SHAPING/COMPRESSION/
POLICING CLASSIFICATION AND QUEUEING AND
FRAGMENTATION/INTERLEAVE
MARKING (SELECTIVE) DROPPING

Classification Tools
• Based on IP PRECEDENCE, DSCP, EXP & COS

• Based on ACLs (policy based routing, Committed Access
Rate)
• Based on protocol (L4 …)

Class of Service - Ethernet Tag
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
48-bit Destination MAC Address
48-bit Source MAC Address
C
3-bit
16-bit Ethertype (0x8100) F 12-bit VLAN ID
Prio I
16-bit Length/Type Data (variable) 802.1q

Tag
Data (variable) Pad (variable)
32-bit FCS
802.1p User Priority

3 bits wide; values 0–7

Class of Service - MPLS Label
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
20-bit Label EXP S TTL
MPLS EXP
3 bits wide; values 0–7

Class of Service - IP Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
4-bit 4-bit
8-bit TOS 16-bit Total Length
Version Hdr Len
3-bit
16-bit Indentification 13-bit Fragment Offset
Flags
8-bit TTL 8-bit Protocol 16-bit Header Checksum
32-bit Source IP Address
32-bit Destination IP Address
Options (if any)
Data
Type of Service byte

IP Prec 3bits
or
DSCP 6 bits
Class of Service - Putting It All Together
802.1q EXP 3 bit IPP

3 bits 3 bits 6 bit DSCP
8 bit TOS
Ethernet MPLS IP IP Ethernet

Header Label Header Payload FCS
802.1p EXP IP Prec DSCP ToS
0 0 0 0 0x00
1 1 1 8 0x20
2 2 2 16 0x40
3 3 3 24 0x60
4 4 4 32 0x80
5 5 5 40 0xA0
6 6 6 48 0xC0
7 7 7 56 0xE0

Differentiated Service Code Point (DSCP)
IPv4 ToS IP prec “ToS bits” U
DSCP ECN
Former ToS byte = new DS field
• DS codepoint: a specific value of the DSCP portion of the DS field, used to
select a PHB
• DS field (rfc2474): the IPv4 header TOS octet or the IPv6 Traffic Class octet
when interpreted in conformance with the definition given in [DSFIELD]. The
bits of the DSCP field encode the DS codepoint,
• ECN bits used for host Congestion Notification (RFC3168, cscdu83511)

DS field (RFC 2474, 2597, 2598)
Per-Hop Behaviours (PHB) DiffServ Code Points (DSCP)

46
Expedited Forwarding EF 101110
Assured Forwarding
Low Drop Med Drop High Drop
Pref Pref Pref
10 12 14
Class 1 AF11 AF12 AF13 001010 001100 001110
18 20 22
Class 2 AF21 AF22 AF23 010010 010100 010110
26 28 30
Class 3 AF31 AF32 AF33 011010 011100 011110
34 36 38
Class 4 AF41 AF42 AF43 100010 100100 100110
0
Best Effort BE 000000
DS field pools
DiffServ Code Points (DSCP) ‘pools’(RFC2474)
Pool 1 DSCP=xxxxx0 standard DSCP
Pool 2 DSCP=xxxx11 Local usage
Pool 3 DSCP=xxxx01 Local usage

(reserved for future std)

Classification Tools
DSCP Per-Hop Behaviors
• IETF RFCs have defined special keywords, called Per-Hop Behaviors, for
specific DSCP markings
• EF: Expedited Forwarding (RFC3246, formerly RFC2598)
– (DSCP 46)
• CSx: Class Selector (RFC2474)
–Where x corresponds to the IP Precedence value (1-7)
–(DSCP 8, 16, 24, 32, 40, 48, 56)
• AFxy: Assured Forwarding (RFC2597)
–Where x corresponds to the IP Precedence value
(only 1-4 are used for AF Classes)
•And y corresponds to the Drop Preference value (either 1 or 2 or 3)
–With the higher values denoting higher likelihood of dropping
–(DSCP 10/12/14, 18/20/22, 26/28/30, 34/36/38)
• BE: Best Effort or Default Marking Value (RFC2474)
–(DSCP 0)

Class-based Marking
DSCP and IP Prec
Router(config-pmap-c)#set ip dscp ?
<0-63> Differentiated services codepoint value
af11 Match packets with AF11 dscp (001010)
…
cs1 Match packets with CS1(precedence 1) dscp (001000)
…
default Match packets with default dscp (000000)
ef Match packets with EF dscp (101110)

Policy Based Routing
• Legacy marking technique:

interface Ethernet0/0
– ip policy route-map lab
access-list 101 permit tcp any host 10.22.1.10
route-map lab permit 10
– match ip address 101
– set ip precedence 4

Committed Access Rate (CAR)
• Two functions
Packet Classification—IP precedence and QoS group setting (dscp,
exp)
Access Bandwidth Management ‘rate limiting’

Committed Access Rate (CAR)
• Rate Limiting (Policing)

• Packet Classification
• Similar to Traffic Shaping, but no
Buffering
Matching specification: Confirm Action:

•1) All traffic
• Drop, Transmit, Recolor
•2) IP precedence
• Exceed Action:
•3) MAC address
• Drop, Transmit, Recolor
•4) IP access list
Traffic Traffic
Action
Matching Measurement
Policy
Specification Instrumentation

CAR Policy Examples
Recolor
Drop
Drop Multimedia
Recolor
Mission-Critical
Per Application CAR

Policing & Shaping Tools
• Used to force traffic to conform to SLAs

–Through POLICING or SHAPING

Policing vs. Traffic Shaping
• Both ensure that traffic does not exceed a (contracted)

BW limit
• Both limit BW but with different impact on traffic
–Policing drops more often - more retransmits
–Shaping adds variable delay (buffering)
• Policer causes TCP Retransmits
–Oscillation of Windows in TCP
• Policer can be used as Marker/’re-marker’ also

• Policer on input or output interface; Shaper on output

interface
• Shaper use regular Tc interval, policer use elapse time
between packet to credit ‘bucket’
• Shaper ‘smooth’ traffic, policer allows bursts
• Shaper can adapt to Network congestion (BECN, FECN)
• Shaper ‘create’ shaping queues (can be use as a
congestion mechanism in virtual intf like tunnel)
• Shape avg: send bc+be in 1st Tc (be is refilled when traffic
send < bc)
• Shape peak: send bc+be per Tc !!

Policing
Traffic
Traffic
Traffic Rate Traffic Rate
Time Time
Shaping
Traffic
Traffic
Traffic Rate
Traffic Rate
Time Time

Token/leaky bucket
B - Burst size max in bits

= bucket size
R R - Token arrival rate.
In practice: add
Overflow
an increment of
Tokens
B tokens every Tc
« excess »
or every time a
packet arrive
Packets Enough
token in YES: Conform
arriving
bucket ? (transmit at line rate)
NO: Exceed (drop, enqueue or use excess tokens)

Token/leaky bucket
• Bucket is filled at defined rate with ‘tokens’ (at

each Tc or elapsed time between incoming pkts
depends on implementation)
• Incoming Packets take available tokens in
bucket
• Packets can to take up to ‘burst’ bits (excess
burst is just a 2nd bucket mechanism)
• If no credits in bucket, packet gets dropped
(policer) or queued (shaper)
Burst must take into account max packets length and TCP window size
(slow start).

Single Rate/3 colors Policer (RFC2697)
Tc: token available in bucket1

Te: token avail in bucket2

Dual Rate/3 Colors Policer (RFC 2698)
Tp: token available in bucket1

Tc: token avail in bucket2

Actions (colors)
Conform / Exceed / Violate Actions

drop
set-dscp-transmit
set-mpls-exp-transmit
set-prec-transmit
set-clp-transmit
set-frde-transmit
set-qos-transmit
transmit

Traffic Shaping
Internet Service
Provider (ISP)
128 Kbps
Cloud
T1
Branch Office Central

Bottleneck Site
• Reduces outbound traffic flow to avoid
congestion (via buffering)
• Eliminates bottlenecks in topologies with data
rate mismatch
• Provides mechanism to partition interfaces to
match far-end BW requirements

Traffic Shaping
Traffic Transmit Output

Destined Queue Line
for Interface Match
Classify
No Match
Configured
Queuing (e.g.
WFQ, CQ, etc.)
Classification by: “Leaky

Extended Access Bucket”
List Functionality Shaping
(GTS only)

Shaping Q vs Output Q
Shaping Queue
FIFO, LLQ …
SubIntf 1.1 CIR=48 kbps Output

Tx Q ring
TS
Always FIFO
Main Intf 1
TS
SubIntf 1.2 Output
CIR=48 kbps
Interleaving
Dual fifo if
FRF12
Shaping Queue Output
Interface
FIFO, LLQ …
FIFO, WFQ…
(only fifo in
latest IOS)

Traffic shaping packet path
Packet path:
When a packet arrives at the interface for transmission, the following
happens:
• if the SHAPING queue is empty, the arriving packet is processed by
the traffic shaper.
1. If possible, the traffic shaper sends the packet to the OUTPUT
queue. (Means if number of bits allowed during Tc is not reached)
2. Otherwise, the packet is placed in the SHAPING queue and
sent in next Tc.
• If the SHAPING queue is not empty, the packet is placed in the
shaping queue.
When there are packets in the SHAPING queue, the traffic shaper
removes the number of packets it can transmit from the SHAPING
queue every time interval.
Some shaper like FRTS use a ‘negative’ bucket mechanism, if not enough
token : send the packet anyway and then wait until bucket is
‘positive’ again, PQ packets shortcut shaper but decrease bucket.
Other dTS, CB shaping wait until shaper has accumulated enough token
before sending packets, but PQ packets can preempt if enough
tokens
FRTS - dTS
• Bc updated at each Tc interval

• Shape average: Be is a burst, not a rate
–Be bucket is filled up when bc bucket overflows
–!! By default be = bc
• Shape peak = EIR (Bc + Be is sent for each Tc)  dTS
• CIR/MINCIR
–Adaptative shaping between CIR and MINCIR
•CIR = EIR of the service provider
•MINCIR = CIR of the service provider
–Fecn-adapt

FRTS versus dTS
FRTS dTS
Default Tc = 125ms (if bc not set) Default Tc = 4 ms (if bc not set)
10ms <= Tc <= 250ms (4ms CSCdx27315) 4ms <= Tc <= 128ms and must be a
Negative token credit multiple of 4ms
If configured Tc > 250 ms then Tc = (Tc Positive token credit only
+ 1)/2 until Tc <= 250 ms If configured Tc > 128ms then Tc =
Take this new Tc to calculate new bc Tc/2 until Tc <= 128ms
and be (byte increment and byte Take this new Tc to calculate a new bc
limit) and be
Traffic from llq is sent even if bc is
already negative Traffic from llq waits until enough
Part of the L2 is taken in account but token in bc
not all  sum(CIR)<95%AR Part of the L2 is taken in account but
not all  sum(CIR)<95%AR

Congestion Management

Scheduling Tools
Queuing Algorithms
Voice 1 1 1 11
1 1 1 1 1 1 1 1 1 1 1 1 1
Video 1 1 1 1 2 12
3
Data 1 1 1 1 1 1 13
• The objective of queuing algorithms are to manage

congestion
• And provide packet scheduling based on flow
requirements

Congestion management
Congestion occurs when …

• Output interface (pos, Eth, serial) driver is ‘full’ (speed mismatch)
• When shaper is ‘active’
• When ATM PVC is ‘full’

Tx-ring vs Tx-queue
Forwarder
Interface Yes
Congested?
FIFO/PQ/CQ/WFQ (output hold-queue
interface ‘hold’ compromise
No latency/buffering )
Tx-Queues
Transmission
Queue (tx-ring)
Tx-ring (intf driver queue)Always FIFO

(in particles or packets, platform dependant !)
Changed w/ Tx-ring-limit or
show vip tx-polling-high <interface> <new-tx-polling-high> on vip
tx-ring vs tx-queue
• Tx-ring is the ‘driver queue’ (mainly in particles)

• Tx-queues used ONLY when tx-ring is full (in
packets)
• Tx-ring configurable (platform/adapter
dependant, PA-A3) high enough to
accommodate line rate, short enough to reduce
latency (tune carefully)
• Tx-ring tuned automatically when fancy queuing
configured (CSCdk17210)
• Tx-queue default 64 on low-end, on VIP
default=Bw/4000 (500ms of 250B packets, min=2)
Scheduling Tools (platforms below 72xx)
• Legacy Congestion management algorithms

–First In First Out
–Priority Queuing
–Custom Queuing
–Weighted Fair Queuing (WFQ)
• latest Congestion management algorithms
–Class based WFQ (CB-WFQ) and LLQ

Scheduling Tools
• Congestion avoidance algorithms

–Weighted Random Early Detection (wRED)

First In First Out (FIFO)
Transmit
Queue
Output Line
• Simplest Queuing Algorithm

• “packets leave in order of arrival”
• Fixed Queue Lengths (default 40)
Result in dropping from tail of queue
under load

FIFO
• Order of Arrival completely determines the

bandwidth, promptness and buffer allocation
• Does not provide protection against ill-behaved
sources
• Bursty sources may cause high delay in
delivering some time sensitive control/signaling
messages

Priority Queuing (PQ)
Interface Hardware
• Ethernet
• Frame Relay
• ATM
• Serial Link
High • Etc.
Traffic
Destined Medium Transmit Output
for Interface Queue Line
Classify
Normal
Low
Q Length Defined
by Q Limit Absolute Priority
Scheduling
Interface Buffer Resources

Classification by:
• Protocol (IP, IPX, AppleTalk,
SNA, DecNet, Bridge, etc.)
• Incoming Interface
(EO, SO, S1, etc.)

Priority Queuing
Forwarder
Priority Classification
(Access)
List
Low Medium High

Priority Priority Priority
Transmission
Queue

Priority Queuing
• Four priority queues -

–High, Medium, Normal, Low
• Packets not classified by priority-list mechanism fall into normal
queue

Priority Queuing
• Can cause traffic lockout if configured

incorrectly
• FIFO within priority queue
–Within priority queue, may still be unpredictable
• Resource allocation
–lower priority queues may starve

Custom Queuing (CQ)
Interface Hardware
• Ethernet
• Frame Relay
1/10 • ATM
• Serial Link
2/10 • Etc.
Traffic Destined
3/10
for Interface Transmit Output
2/10 Queue Line
Classify
3/10
Up to 16
Link
Q Length Utilization Weighted Round
Deferred by Ratio Robin Scheduling
(byte count min
Queue Limit default 1500, each packet
started is sent)
Classification by: Interface Allocate

• Protocol (IP, IPX, AppleTalk, Buffer Proportion of Link
SNA, DecNet, Bridge, etc.) Resources Bandwidth
• Incoming interface
(EO, SO, S1, etc.)

Custom Queuing
Forwarder
Priority
(Access)
Control Traffic List
Queue #0
Queue #1 Queue #9
Queue #2 Queue #10
Queue #3 Queue #11
Queue #4 Queue #12
Queue #5 Queue #13
Queue #6 Queue #14
Queue #7 Queue #15
Queue #8 Queue #16
Transmission Queue
Custom Queuing
• Identify the traffic

• Distribute into FIFO queue by class
• Dequeue in some rotation
–Remove some number of bytes at most
–Move to next queue in round robin order

Priority vs. Custom Queuing
CQ
• 16 Queues PQ
• Packets
4 Queues: classified by protocol
High, Medium, or interface
Normal,
• Low per custom queues
FIFO
• Packets classified
Weighted by protocol
round robin or (but no ‘deficit’ mechanism)
scheduling
• interface
WRED and RSVP not supported
•• FIFO within priority
Guarantees BW perqueues
queue, not delay
• Absolute priority scheduling
• Lower priority queues may starve

Weighted Fair Queuing (WFQ)
Q Classification:
• Source address 1 1
• Dest address Reserved queues
...
• Source port (RSVP and RTP Reserve)
• Dest. Port 2 2 2
• Tos bits (not prec!)
Weight: 3
• IP Precedence ... IP Precedence 7
• RSVP/RTP Reserve De-
• W=32384/(prec+1) 4 4
queue
...
5 5
IP Precedence 0
...
6 6 6 (Best Effort/Hash queues)

• 8 fixed system queues:

–LMI, ARP, PPP control, Routing protocol
• 2n dynamic queues (hashing)
– IP Flow = 109-bit string = {Sadd, Dadd, PID,
Sport, Dport, 5-bit ToS} (not prec !)
– 16 -> 4096, default is 256 (based on BW CSCdm26683)
– If not enough queues, 1 hash for n flows
• x RSVP queues 0 -> 1000 [def: 0]

• system queues has fixed weight (1024)

• dynamic queues use IP prec (w=32384/(prec+1))
(since 12.0.5T)
–non ip flow use default 32384
–internal traffic (CDP) use 4096
• RSVP use w=4*(max_rsvp_bw/flow_bw)

• Output scheduling based on a TDM mechanism.

–Tail_time = tail_time(t-1) + packet_size*W
F(A1)=0+100
F(B1)=50+300 A1[100]
B1[300]
F(A2)=100+20 A2[20]
F(B2)=350+300 F(A3)=120+10 A3 [10]
B2[300]
t 100 70 60 50 0
Hence the resulting scheduling is:
B2 B1 A3 A2 A1

• Output Dropping based on a threshold.

–Congestive Discard Threshold (CDT)
–Not related to precedence
run-downleft#sh queue s 0/1

Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 7/1000/64/0 (size/max total/threshold/drops)
Conversations 5/5/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)

Upon enqueue of a new packet,

IF the sum of all subqueues > Max-limit (default 1000),
THEN, if the tail time of the new packet is > current (largest) system
tail time,
then the new packet is dropped
else the system tail-time packet is dropped and the new one is
enqueued
IF CDT(default 64) < the sum of all subqueues < Max-limit,
THEN, if the new packet’s tail time > current system tail time
then drop the new packet
else enqueue the new packet
Exception: a packet classified into an empty sub-queue is never
dropped (at least one packet in a queue)

WFQ drop behaviour
• CDT = 8, Max-Limit=14

Weighted Fair Queuing
• Provides relative bandwidth guarantees and dropping mechanism

–Fair Queuing (FQ) allocates equal share
of bandwidth to each active queue
–Weighted Fair Queuing (WFQ) allows
for unequal allocation of bandwidth
–sub_Queue BW= BW*(TOS+1)/ S (TOS+1)

WFQ
• 1 FTP - Tos 0 get 1/16*48K = 3 Kbps

• 1 FTP - Tos 0 1/16*48K = 3 Kbps
• 1 Telnet - Tos 4 5/16*48K = 15 Kbps
• 1 HTTP - Tos 2 3/16*48K = 9 Kbps
• 1 Voice - Tos 5 6/16*48K = 18 Kbps
______________
S (Tos+1)= 16

PQ-WFQ (IP RTP Priority)
• To prioritise Voice traffic (on FR, PPP)

• Create a priority queue (weight=0) + BW limit
• RTP only (range of UDP ports)
• Reduce voice latency
Router Exhaustive
Voice 1 1 Queuing
(Highest)
Data (High, 2 2 V V
PQ
e.g. IP Prec 4) 4 3 2 1 1
WAN
Data (Medium,
3 3 3 3 Circuit
e.g. IP Prec: 2) WFQ
4 4 4 4

Class-Based WFQ (CBWFQ)
Class queues
1 1 Max: 1023
...
2 2 2
De-queue
3
Default class-queue
OR
5 5
Classify
...
WFQ System
6 6 6 (unclassified traffic)

CBWFQ
Forwarder
Per class class-default

(ACL)
Per flow
Class #1 (hash)
Class #2
Flow #3
Class #3
Flow #2
Class #64
Flow #1
Scheduling based on Finish Time

CBWFQ
• Up to 1024 Classes (1023

+ default)
– Bandwidth (min guarantee, FIFO only!)
– wRED & queue-limit within classes
• “default class” : class-default
– fair-queue (wfq) & queue-limit
– fair-queue (wfq) & wred
– bandwidth (fifo) & queue-limit
– bandwidth (fifo) & wred

CBWFQ
• By default sum of BWclasses <=75% of ‘visible BW’ (for L2

overhead + default class) can be tuned with “max-reserved bandwidth xx” on main
intf or PVC (CSCdv06837)
• On FR-PVC 100% of mincir is reservable
• FIFO queuing per class (default 64 pkts)
• Hellos, keepalives, (non-TCP updates) use « PAK-
flag »
• routing updates (TCP) use default queue !!
• Output scheduling is still “weighted” between classes:
w computation is based on (1/class_BW ; 1/#hashed_queues)

PQ-CBWFQ or Low Latency Queuing LLQ
Forwarder
Per class class-default

(ACL)
Per flow
Class #1 (hash)
Class #2
Flow #256
Class #3
Flow #2
Class #63
PQ Flow #1
Scheduling based on Finish Time

WFQ “conversations” (‘show queue …’)
Conversation/ Type of Traffic

Queue Number
1 - 256 General flow based traffic queues. Traffic
(Up to 4096) that doesn’t belong to user created class
but the class-default if using CBWFQ.
W=32384/(prec+1)
257 - 263 Reserved queues for CDP or pak_pri traffic.

W=1024 except cdp
264 Reserved queue for priority class. W=0
265 - up User created classes in CBWFQ or LLQ.

W= f(class_bw)

number of queues in default-class depends on visible BW (16, 64,
128 ,256 ..configurable)

PQ-CBWFQ (LLQ)
• Priority Classes
– priority and max BW (not limited to RTP flows)
– burst size (200ms of traffic by default)
– “Expedite Forwarding” class in diffserv model
– low latency queuing classes
– Only 1 fifo PQ (even if several priority classes !!)
– « CAR like » policed if congestion (exept LLQ in
– FR is ALWAYS policed but drop only if congested)

WFQ vs LLQ
• Shared WFQ
BW, no guarantees
LLQ
• Prec define weight, BW

• %BW min guarantee per class
• PQ-WFQ for RTP only
• PQ classes, BW max allowed
(“CAR” like limiting)
• BW define weight (not prec)
• wRED per CB classes (prec,
DSCP oriented)

Congestion Avoidance

Scheduling Tools
TCP Global Synchronization: The Need for Congestion Avoidance
All TCP Flows Synchronize in

Waves Wasting Much of the
Available Bandwidth
Bandwidth
100% Utilization
Time
Tail Drop
3 Traffic Flows Start Another Traffic Flow

at Different Times Starts at This Point
Scheduling Tools
Congestion Avoidance Algorithms
TAIL
WREDDROP
Queue
3 3
1 01 2 1 2 0 2 0 3 2 1 3
0
3
0
3
• Without RED when the queue fills up ALL packets that arrive are
dropped—Tail drop
• With RED as oppose to doing a tail drop the router monitors the
average queue size and using randomization choose connections
to notify that a congestion is impending

RED algorithm
for each packet arrival

calculate the average queue size (avg)
if min_threshold > avg
queue arriving packet
else if min_threshold <=avg <=max_threshold
calculate packet-drop probability (p)
with packet-drop probability p
drop the arriving packet
or
queue the arriving packet
else if max_threshold <avg
drop arriving packet

RED
• The average queue size is calculated

based on the previous average and the
current size of the queue
Avg = (old_avg * (1 - 1/2^n)) +
current_queue_size * 1/2^n)
• ‘n’ exponential-weight-constant keyword
• ‘P’: drop probability
prob = mark_prob * (avg - min_th) / (max_th - min_th)
default mark_prob = 1/10

Weighted RED
Probability
1 _
of Packet
Discard
Two drop slopes are
shown; Up to eight
can be defined
Prec 0
Mark prob _ drop
profile
“Slope” is Prec 1
adjustable drop
profile
0
Queue Length
IP Prec 0 IP Prec 1
Max0/max 1
Min. Min.
• Configure min and max threshold per IP prec/ EXP

(or per DSCP drop pref)
Scheduling Tools
DSCP-Based WRED Operation
Drop All Drop All Drop All

Drop AF13 AF12 AF11
Probability
100%
50%
Average
0 Queue
Begin Begin Begin Size
Dropping Dropping Dropping
AF13 AF12 AF11 Max Queue
Length
(Tail Drop)
AF = (RFC 2597) Assured Forwarding

Congestion Avoidance Tools
IP ToS Byte Explicit Congestion Notification (ECN) Bits
Version ToS
Byte Len ID Offset TTL Proto FCS IP SA IP DA Data
Length
IPv4 Packet
7 6 5 4 3 2 1 0
DiffServ Code Point (DSCP) ECT CE
ECT Bit: CE Bit:

ECN-Capable Transport Congestion Experienced
RFC3168: IP Explicit Congestion Notification

WRED
(TCP behavior “slow start”)
• Sends as much as credit allows

• Starts credit small
–Avoid overloading network queues
• Increases credit exponentially
–To gauge network capability

WRED
(TCP behavior “slow start”)
Max
Window
.5 Max
Window
Max
TCP Slow Start - Time to recover depends on RTT
Window
Min
Window
RTT time

WRED
(TCP behavior)
• If ACK acknowledges something (TCP ACKs n+1)

–Update credit and send
• If not, presume it indicates a lost packet
–Send first unacknowledged message right away
–Halve current credit
–Increase linearly to gauge network throughput

TCP and tail drop
‘global synchronization’
1.200
Global Tail Drop

cwin 1
1.000
cwin2
cwin3
cwin4 MEAN
0.800 Sum
Line load
0.600
0.400
0.200
0.000
1 6 11 16 21 26 31 36
Time in RTT
TCP and RED drop
Line Usage
1.200
cwin 1
1.000 cwin2
MEAN
cwin3
cwin4
0.800
Sum
Line Load
0.600
RED Drop
0.400
0.200
0.000
1 6 11 16 21 26 31 36
Time in RTT
RED tuning
• Optimality is probably not practically achievable

• As a starting point, following slides give some
generic guidelines
–recommend fine-tuning based upon testing
and operational experience in each specific
environment
• The goal is to maximize the link utilization while
minimizing the mean queue depth hence delay

RED tuning: exponential
weighting constant
• The exponential weighting constant (x) determines how
closely the average queue depth tracks the actual queue
depth
–avg = (1-w) * avg + w * current_q_size
–where w = 2^(-x)

RED tuning: exponential
weighting constant
• The smaller x, the closer the max instantaneous queue size
is to maxth, hence the easier it is to limit the max latency via
RED and the more reactive to burst RED is
• For larger x, the converse is true
• Suggested settings for rate <= 10Mbps:
–x = 1/B, expressed as a negative power of 2
–where B is the output rate expressed in MTU sized
packets
–For 256kbps x = 4

RED tuning: min and max thresholds
Low-speed: suggested for <= 10Mbps
• Min threshold value should be high enough to maximize

the link utilization
–If too low, packets may be dropped unnecessarily,
and the link will not be fully utilised
• Min threshold = 1 * P
–where P is the pipesize = RTT * BW / (MTU * 8)
–we suggest that you use 1500 byte packets for the
MTU even if MTU is configured at 4470
–For an 256kbps, P is determined as follows:
•P = 500ms * 256kbps / (1500 * 8) = 11

RED tuning: min and max thresholds
• Difference between the max threshold and the min

threshold should be large enough to avoid global
synchronization
–If difference is too small, many packets may be
dropped at once, resulting in global synchronization
• Max threshold = 3 * P
• Set MaxP = 1
– i.e. probability of discard at max threshold = 1

Guidelines on RED tuning
Class load x P Min. Th Max. Th.

64kbps 3 3 3 9
128kbps 3 6 6 18
256kbps 4 11 11 33
• minth and maxth calculations are based upon

expected per class servicing rate
• Exponential weighting constant is set on a per
service-policy basis

High speed: suggested for > 10Mbps
• Min threshold = 0.15 * P

–we suggest that you use 1500 byte packets for the
MTU even if MTU is configured at 4470
–For an OC48 link, P is determined as follows:
•P = 100ms * 2.5Gbps / (1500 * 8) = 20,000

High speed: suggested for > 10Mbps
• Max threshold = 1 * P
• Set MaxP = 1
– i.e. probability of discard at max threshold = 1

Link speed P minth maxth

OC3/STM-1 1292 97 609
OC12/STM-4 5184 389 2437
OC48/STM-16 20000 1500 9692
• Based on simulations, these recommendations ensure at least 85%

utilisation with a mean queue size below 0.2P
–thus a mean queuing delay less than 20ms
• The calculations are calculated for expected per class load
–assumed 50% BUS, 50 % BE
• Note: on GSR MinTh is adjusted by hw such that (minTh = maxTh-
biggest power of 2)

Legacy GSR CLI configuration
cos-queue-group oc48_policy
precedence 0 queue 0
precedence 4 queue 1 • Legacy CLI required for
precedence 6 queue 1 MDRR/WRED:
precedence 5 queue low-latency
precedence 0 random-detect-label 1 –Engine 0
precedence 1 random-detect-label 0
precedence 3 random-detect-label 1 –Engine 2
precedence 4 random-detect-label 1
precedence 6 random-detect-label 1 –Engine 4 / 4+
random-detect-label 0 500 1012 1
random-detect-label 1 1500 9692 1 • Implicitly matches MPLS-
queue 0 1 EXP
queue 1 73
queue low-latency strict • Search on CCO for
!
int pos 1/0 Document ID: 18841
tx-cos oc48_policy

WRED (non TCP behavior)
• wRED will be unable to force the application to

back off, however, wRED will drop its packets in
proportion of its sending rate
• ‘Flow RED’ can discard per flow for non-adaptive
flows (ie UDP), with “Random-detect flow” (IOS
non-vip only)
• FRED maintain flow queues and drop based on:
avg*scaling_factor < Flow_queue_depth
–Means that this flow takes too much ressources (is
considered as non-adaptive)
–RED must be activate first!!

WRED summary
• Dropping a message is a way of telling the

sender to slow down
• Randomly drop up to threshold (then tail drop)
avoid ‘global synchronization’
• Weighted drop thresholds based on IP
Prec/EXP or DSCP
• Efficient on ‘adaptive’ flows (TCP)

Link Specific Management Tools

Ingress ‘CPU congestion avoidance’
• Selective Packet Discard (SPD) discard input packets based

on precedence (“router protection”)

Link-Specific Tools
Link-Fragmentation and Interleaving
Serialization Voice Data

Can Cause
Excessive Delay
Data Data Data Voice Data
With Fragmentation and Interleaving Serialization Delay Is Minimized
• Serialization delay is the finite amount of time required to

put frames on a wire
• For links ≤ 768 kbps serialization delay is a major factor affecting latency and
jitter
• For such slow links, large data packets need to be fragmented and interleaved
with smaller, more urgent voice packets

Link Fragmentation and Interleaving (LFI)
Traffic
Destined Transmit Output
for Interface Queue Line
IP Voice
Jumbogram
WFQ
• Large Packet Fragmentation:

Multlink PPP with LFI Fragment Size Based
Or on Required Delay
• Then interleave Voice packets with
Frame Relay with FRF11/12
other queues

PQ-WFQ for Frame Relay
• Dual Interface FIFO is turned on automatically when FRTS& FRF12 is

configured (N/A for 7500)
• Interface Queue operation before PQ-WFQ in 12.0(5)T:
LMI and unfragmented packets (VoIP, VoFR) to Hi queue
All fragmented packets (data) to Lo queue
• Interface Queue operation with PQ-WFQ in 12.0(5)T:
LMI and PQ contents (VoIP and VoFR) to Hi queue
Everything else, regardless of fragmentation (data) to Lo queue
Per PVC
Per Interface dual FIFO
V V Router
PQ - voice Interface
1 1
High
PQ V V WAN Circuit
2 L L 1 1
I
LM V V
3 3 3 3 4 3 2 4 3 2 L 1 1
WFQ
Low
4 4 4 4

Queuing & Interleaving (FRF12)
Voice flow
Data flow
Inter-
WFQ leaving
Data flow de-queuing Fragmentation PVC A
Interface queues
Voice flow
High FIFO
Data flow PVC B
Inter- Tx Ring
WFQ leaving
Data flow de-queuing Fragmentation Normal FIFO
Voice flow
Data flow PVC C

Inter-
WFQ
Data flow leaving
de-queuing Fragmentation
Frame Relay traffic-shaping with FRF 12 then FRF11

LLQ for FR updates
• BW in the priority class

given in Kbps
max allowable BW for “priority” classes is mincir
does NOT take cRTP into account
class is policed to given BW (cannot burst like the data classes)
• Voice is no longer shaped in 12.1.2T (except w/ dts)

If a voice packet present, it is sent in the next Tc timeslot
Bc is decremented for voice (even if already negative)
Data will be held back until Bc is positive again

Other Link-Specific Tools
IP RTP Header Compression
IP Header UDP Header RTP Header Voice

20 Bytes 8 Bytes 12 Bytes Payload
cRTP Reduces L3 VoIP BW by:

~ 20% for G.711 2-5 Bytes
~ 60% for G.729

Queuing Summary
LLQ
PQ CQ WFQ PQWFQ CBWFQ
(PQ-CBWFQ)
IP Prec,
RSVP, RTP VoFR and
Protocol, Protocol, VoFR and
Classification interface interface
Reserve, IP RTP Mod CLI
Mod CLI
protocol, Priority
port
1 PQ + 1024 1 PQ +
# queues 4 16 Per flow
WFQ classes CBWFQ
Fair: weight PQ: Strict

Strict Round- Fair (weight, PQ: Strict
Scheduling priority robin arrival time) WFQ: Fair
and BW CBWFQ:
Fair/BW
Delay
Yes No No Yes No Yes
guarantee
BW PQ: yes
No No No Yes Yes
Guarantee WFQ: No
Used for Last resort

No No Yes No Yes
Voice

Queuing Summary

How to configure QoS ?
• With Modular QoS CLI (MQC)

–Configuring Classification policies
–Associate policies to class
–Attaching policies to interface (in/out)

Modular QoS CLI
class-map CLASS1 (1024 class globally since 12.2(12))

match …
access-group Access group
destination-address Destination address (mac)
input-interface Select an input interface to match
ip IP specific values (prec, DSCP)
cos 802.1p/Q
mpls Multi Protocol Label Switching (exp)
not do not match
protocol Protocol (nbar …)
qos-group Qos-group
source-address Source address (mac)
packet length, fr-dlci … (12.2(13)T)
vlan 12.4T
(multicast supported since CSCdr34902 12.1(4)T)

Modular QoS CLI
policy-map TEST (limited to 256 w/ CSCdv64193)

class CLASS1 (256 class max per policy-map)
bandwidth Bandwidth in kbps or percent/percent remaining
priority Strict Scheduling Priority for this Class+ burst
(default 200ms of traffic)
queue-limit Queue Max Threshold for Tail Drop
random-detect Enable WRED as drop policy (IPprec or DSCP based) +
ECN bits option,; min/max_th in bytes or packets th in
bytes or packets
service-policy Configure QoS Service Policy-------> hierarchical
set Set QoS values (prec, DSCP,cos, exp, FRde, CLP…)
compress header ip RTP or TCP (12.2(13)T)
shape Traffic Shaping: avg (CIR) or peak (CIR*(1+be/bc))
police traffic policing (conform, exeed, violate) +2 rate
policer + multiple actions

Hierarchical policy
• Allow multi level (3) policy
policy-map bandwidth-allocation-policy
class udp
bandwidth <bw specification>
service-policy udp-hierarchy
class tcp
service-policy tcp-hierarchy
policy-map udp-hierarchy
class nfs
class tftp
policy-map tcp-hierarchy
class http
class ftp

Hierarchical limitations
• Any to any combination supported on vip

• Other platform parent/child restrictions:
parent level Bandwidth & Bandwidth Shaping Police

Shaping
Child level Bandwidth Police Police Police
Priority
Bandwidth

MQC features « flow chart »

Common classification
QoS feature ordering
Since 12.1T, avoid multiple cascading classification & improve perf
input common classification
input access lists
input marking
input policing
CEF/fast switching
output common classification
output access lists
output marking
output policing
Traffic shaping
queueing (CBWFQ, WRED which use ‘remarked’ TOS field)

Configure QoS with AutoQoS
• ‘AutoQoS’
–AutoQoS ‘discovery’ analyse traffic
–AutoQoS define automatically classes, policy-map, LFI, Wred and
apply policies

AutoQoS
AutoQoS Enterprise: WAN DiffServ Classes
Cisco AutoQoS
AutoDiscovery Traffic Class DSCP
Policy
Cisco AutoQoS
Application and Class-Maps IP Routing CS6
Protocol-Types
Match Statements Interactive Voice EF
Minimum Bandwidth Interactive Video AF41
Offered Bit Rate
to Class Queues,
(Average and CS4
Scheduling and Streaming Video
Peak)
WRED
Telephony Signaling CS3
Transactional/Interactive AF21
Network Management CS2
Bulk Data AF11
Scavenger CS1
Best Effort 0

AutoQoS
AutoQoS VoIP: Campus
set qos autoqos
set port macro 3/1 ciscoipphone 10 110
set qos enable
set qos map 2q2t tx 2 1 cos 1
set qos drop-threshold 2q2t tx queue 1 100 100
…
set qos cos-dscp-map 0 10 18 26 34 46 48 56
set qos ipprec-dscp-map 0 10 18 26 34 46 48 56
set qos policed-dscp-map 0,26,46:0
set qos policed-dscp-map 1:1
…
set qos policed-dscp-map 63:63
clear qos acl all
#ACL_IP-PHONES
set qos acl ip ACL_IP-PHONES trust-cos ip any any
#
commit qos acl all
!
set vlan 100 3/1
set port qos 3/1 trust-device ciscoipphone
set trunk 3/1 off negotiate 1-1005,1025-4094
set spantree portfast 3/1 enable
set port qos 3/1 trust trust-cos
set qos acl map ACL_IP-PHONES 3/1
set port qos 3/1-48 policy-source local
set port channel 3/1 mode off
AutoQoS
AutoQoS VoIP: WAN
interface Serial2/0
bandwidth 768
ip address 10.1.102.2 255.255.255.0
encapsulation ppp
auto qos voip trust
!
!
class-map match-any AutoQoS-VoIP-RTP-Trust
interface Multilink2001100117
match ip dscp ef
bandwidth 768
class-map match-any AutoQoS-VoIP-Control-Trust
ip address 10.1.102.2 255.255.255.0
match ip dscp cs3
service-policy output AutoQoS-Policy-Trust
match ip dscp af31
ip tcp header-compression iphc-format
!
no cdp enable
!
ppp multilink
policy-map AutoQoS-Policy-Trust
ppp multilink fragment delay 10
class AutoQoS-VoIP-RTP-Trust
ppp multilink interleave
priority percent 70
ppp multilink group 2001100117
class AutoQoS-VoIP-Control-Trust
ip rtp header-compression iphc-format
bandwidth percent 5
!
class class-default
…
fair-queue
!
!
interface Serial2/0
bandwidth 768
no ip address
encapsulation ppp
auto qos voip trust
no fair-queue
ppp multilink
ppp multilink group 2001100117
!
AutoQoS
AutoQoS Enterprise: WAN, Part 1: Discovery
interface Serial4/0 point-to-point

encapsulation frame-relay
bandwidth 256
ip address 10.1.71.1 255.255.255.0
frame-relay interface-dlci 100
auto discovery qos
• AutoDiscovery notes
–Command should be enabled on interface of interest
–Do not change interface bandwidth when running auto discovery
–Cisco Express Forwarding must be enabled
–All previously attached QoS policies must be removed from
the interface

AutoQoS
AutoQoS Enterprise: WAN, Part 1: Discover (Cont.)
Router# show auto discovery qos
AutoQoS Discovery enabled for applications

Discovery up time: 2 days, 55 minutes
AutoQoS Class information:
Class VoIP:
Recommended Minimum Bandwidth: 517 Kbps/50% (PeakRate)
Detected applications and data:
Application/ AverageRate PeakRate Total
Protocol (kbps/%) (kbps/%) (bytes)
rtp audio 76/7 517/50 703104
Class Interactive Video:
Recommended Minimum Bandwidth: 24 Kbps/2% (AverageRate)
rtp video 24/2 5337/52 704574
Class Transactional:
Recommended Minimum Bandwidth: 0 Kbps/0% (AverageRate)
citrix 36/3 74/7 30212
sqlnet 12/1 7/<1 1540

AutoQoS
AutoQoS Enterprise: WAN, Part 2: Provisioning

bandwidth 256
ip address 10.1.71.1 255.255.255.0
auto qos
class-map match-any AutoQoS-Voice-Se4/0

match protocol rtp audio
class-map match-any AutoQoS-Inter-Video-Se4/0
match protocol rtp video
class-map match-any AutoQoS-Transactional-Se4/0
match protocol sqlnet
match protocol citrix
!
policy-map AutoQoS-Policy-Se4/0
class AutoQoS-Voice-Se4/0
priority percent 70
set dscp ef
class AutoQoS-Inter-Video-Se4/0
bandwidth remaining percent 10
set dscp af41
class AutoQoS-Transactional-Se4/0
bandwidth remaining percent 1
set dscp af21
class class-default
fair-queue
!

AutoQoS
AutoQoS Enterprise: WAN, Part 2: Provisioning

bandwidth 256
ip address 10.1.71.1 255.255.255.0
auto qos
<policy continued>
!
policy-map AutoQoS-Policy-Se4/0-Parent
class class-default
shape average 256000
service-policy AutoQoS-Policy-Se4/0
!
class AutoQoS-FR-Serial4/0-100
!
map-class frame-relay AutoQoS-FR-Serial4/0-100
frame-relay cir 256000
frame-relay mincir 256000
frame-relay fragment 320
service-policy output AutoQoS-Policy-Se4/0-Parent

‘High-end’ routers
QOS mechanisms
• 7500 series + VIP use: ‘CEF

distributed’ QOS features
• GSR use: CAR + VOQ
and MDRR/WRED
• 7200-NSE,10000, 7600 (OSM modules) use:
PXF processors technology

7500 Distributed QOS
• dWFQ supports
–Flow-based WFQ
–ToS-based
–Qos group-based
–dLLQ

HQF

VIP Based Calendar Queueing
W=1 W=3 W=6
Per-Class
66% 22% 11%

Flow based dWFQ
Forwarder
Classifier - Compute Hash
Flow Queue Queue Queue Queue

Queues 0 1 2 511
Calendar Queues
Transmission Queue
Output scheduler aka “calendar” is round robin (weight=1)

ToS based dWFQ
Forwarder
lower 2bits
IP Prec-Based
Classifier
Flow Queue Queue Queue Queue

0 1 2 3
Queues
Weight
Calendar Queues
Transmission Queue
“calendar” has 4 default weighted classes (10,20,30,40%)

Qos group dWFQ
Forwarder
QoS group set using CAR or
QoS policy progation via BGP
Classifier
QOS-
Queue Queue Queue Queue
Group 1 2 99
0
Queues
Weight
(1-100) Calendar Queues
Transmission Queue

dWFQ drop mechanism
AL: Aggregate limit, AQ: Aggregate queue

IL: individual limit (per subqueue)
P, a new pkt, is dropped:
If pak-priority,
then queue Else IF
AQ>AL,
then P is dropped
Else IF AQ>0.66 AL and IQ>IL
Then P is dropped
Else txmit

dLLQ
Forwarder
Per class
(ACL)
Class #1 Class #2 Class #3
Per flow Per flow Per flow

(hash) (hash) (hash)
Flow #2 Flow #2 Flow #2
Flow #1 Flow #3 PQ Flow #1 Flow #3 Flow #1 Flow #3
Scheduling based on Calendar Queueing

Calendar queuing weight
• Compute LCM between all percentage (except LLQ)

• w=LCM/class_perc
• Scale w between 1 and 100 (w=w*100/w_max)

dLLQ features
• Class default 1% min guarantee (or 8k min)

• Class default BW always garanteed (=totale_BW –
sum(classes_BW))
• Fair queue option per class (not WFQ!!)
• Weight used in calendar queue <=100
• With 12.2(15)M & T with 2 digit % grain (0.01%
CSCdz40273)

Queue-limit on VIP
• Max-Available Buffers for the VIP [particles]

L3 services = DWRED,DWFQ, DCAR: 1/6 of SRAM
Global Shared Pool = 1/2 of SRAM depends on CSCdk45942
• Max-Available Buffers for a Port [particles]
a function of the amount of SRAM on the VIP, the amount of ports on the VIP,
the Port Bandwidth and the Port MTU. This is automatically computed by IOS.
• The Port Aggregate Limit [packets] = min of :
Half-sec of 250 bytes traffic (=bw/4000)
max-buffer available for the VIP (divided by 2 if 2PAs)
• Individual Limit [packets]
distributed proportionally to each class or flow (for
dFBWFQ IL= AL/2, 4 or 5, IOS dependent)

Distributed features
• dCEF, dNBAR, dTS, dGRE, dLLQ, dmlppp, dfrf12,dWRED, dLFI…

• Non distributed QOS (RSP based) no longer supported on VIP (but
non-MQC QoS supported on non-vip)

QOS Mechanisms in GSR
CAR
Meter
Inbound
Traffic
Classifier Marker Conditioner Queuing
Stream
(from dCEF MDRR
ToFab F
CAR CAR
Select dest xACL
or or A
slot/intf) Policy Routing WRED
B
R
I
Meter C
Outbound FromFab
Traffic Queuing Conditioner Marker Classifier
Stream
QOS features available depend on line card

GSR: input queuing (VOQ)
Receive Side of Input line card

Input
Ports Per Destination Slot VOQ,
Up to 2048 tofab Queues, E3 adds 2048 shaping queues
(16 slots x 16 ports/slot x 8 Cos)
w/ PQs per slot/intf/port … MDRR
Crossbar Switch Fabric

dCEF
WRED

GSR: output queuing
Transmit Side of output line card (up to 8 cos queues per port w/ PQ)
W-RED MDRR
Output
Ports
Crossbar Switch Fabric

Linecards on the GSR, the jungle
• In the GSR world we talk about engines [0-

4+, 6]
• The lower number, the older card
• Number of ‘to-fab’ & ‘from-fab’ queues
buffers, perfs, and QoS features (CAR-
shaper…) depends on engine ‘x’

GSR QoS Summary by Forwarding Engine
Engine 0 Engine 2 Engine 3 Engine 4 Engine 4+ Engine 6

622Mbps 2.5G 2.5G 10G 10G 20G
Ingress
Policing CAR *PIRC Nested CAR CAR ***** CAR CAR
Shaping No No Queue/Port No No No
Congestion
Avoid. WRED WRED WRED WRED WRED WRED
MDRR (strict
Latency Control only) MDRR MDRR MDRR MDRR MDRR
CoS Queues 128 2048 2048 2048 2048 2048
Egress
Policing Yes No Nested CAR CAR ***** CAR CAR
Shaping No Port 2 Level Yes Yes Yes
Congestion
Avoid. WRED WRED WRED WRED WRED WRED
MDRR (strict
Latency Control only) MDRR MDRR MDRR MDRR MDRR
CoS Queues 128 128** 2048/4096 128 128 128

Modified Deficit Round Robin (MDRR)
• All queues, except low-latency queue, are serviced in round robin fashion
• Two modes for servicing the low-latency queue
–Alternate Priority and Strict Priority

Modified Deficit Round Robin (MDRR)
Strict Priority
• In Strict Priority mode, the low latency
queue is always serviced if packets
are queued. Remaining queues are
.. serviced in ‘round robin’ fashion
• In Alternate Priority mode, service

Alternate Priority
alternates between the low-latency
queue and the other queues.
Remaining queues are serviced in
‘round robin’ fashion
..

Operation of DRR
• Weights can be applied to queues to further control

packet individual de-queue rate when interface is
congested
• Packet de-queue quantum q is:
q= MTU + (weight - 1)*512
(1<weight<100 to avoid large delays)
• For Tx side MDRR local MTU is used
• For Rx side MDRR largest MTU of destination interfaces
is used

Operation of DRR
• Dequeue packets until the queues counter is zero or negative.

• Move to next queue.
• If negative, retain the value until the next cycle.
• If positive, reset to zero. (i.e. avoid accumulation of credits)

Parallel eXpress Forwarding overview
US Patent 6,101,599 Column Column

Memory Memory
0 1 2 3
IM IM IM IM
Ingress Demux
Packet Packet
Egress Mux
4 5 6 7
Headers In IM IM IM IM
Headers Out
8 9 10 11
IM IM IM IM
12 13 14 15
IM IM IM IM
Column Column
Memory Memory feedback
•A PXF Processor is a 4x4 CPU Array

PXF overview
• Only header (64B) of a packet are sent through the

PXF processor.
• Each column of CPU provides a specific service or
set of services.
• Each row is a pipeline where services are applied
simultaneously to multiple packets.
• Multiple rows allow processing in parallel. (but no
‘out of order’ packets)
• Ability to run multiple pass in the array for complex
feature (that requires more cpu cycles)

PXF cascading PXF Services cascading
CEF
VTMS,
Accounting shaping,
ACLs, policing CBWFQ,
Classification WRED, LLQ
….
•PXF Services are platform dependant

Versatile Traffic Management Services (VTMS)
• VTMS is a set of PXF services for OSM

modules (7600/6500) and also 10K
• Dedicated for High-speed intf, (OC3 min)
• Allows classification, shaping (in-out), queuing
and congestion mngt (out)

VTMS OSM features Overview
• Classification Congestion Management

–Per logical interface, per direction
LLQ, CBWFQ (egress only)
–IP prec, EXP or DSCP-based only
(Cos for EoMPLS) Congestion Avoidance
–up to 64 classes per direction WRED per queue (egress only)
(64+default +system) Marking
–One VTMS queue per class (up to
8000) Use PFC for IP traffic
• Shaping per queue Perf
–Ingress, egress OC48 rate per PXF (2 PXF max)
–CIR, EIR
–Hier-shaping (egress only)

OSM Architecture PXF Queuing
PXF Queuing
Scheduling Multicast
Queues
Wheel Replication
ASIC (Titan)
LC-Bus
Classify
Receive Local Bus
Forwarding Bus Forwarding
And Engines
Fabric Interface
ASIC (Medusa)
Scheduling
Wheels Queues WRED
Fabric Link
ASIC
Switch
(Santa Ana) Fabric
Transmit Classify

OSM architecture
Fabric-Enabled Line Card Shared Bus

(8Gbps)
Titan
Multicast
Medusa
Engine
16 Gbps Local Switching Bus
PINNACLE Sculptor
[4 GE Ports]
Packet
512 KB PXF Complex Buffer IP/MPLS
L2 Buffer Software Qs
Hardware Qs Shaping
WAN Ports CBWFQ/LLQ
PQ, WRR
WRED WRED

The VTMS Scheduler
• The Virtual Time Management System (VTMS) is a

high-performance algorithm utilized within the PXF
environment to support
• Class-Based Weighted Fair Queuing (CB-WFQ)
• Traffic shaping
• VTMS is implemented in the PXF with two timing
wheels (no tx-ring)
• high priority (for LLQ) always served first
• low priority
• VTMS views queues as active or inactive depending
on whether they have packets to send

The VTMS Scheduler
Scheduling Wheel …. basics

(implementation details could be platform dependant)
• We have 2 “timing wheels”

A high priority wheel (for LLQ) always served first
A low priority wheel
• Each wheel is divided in slots or buckets (1024) with a fixed duration (128us)
• Each slot has one or more pending queue to serve QiD (active queues)
• A slot or queue is de-queued until the fixed ‘duration’ (burst size) is reached or slot is
empty
• The active Queue position in the timing wheel is based on packet size and ‘effective BW’
of this class:
• effBW =CIR + EIR/AggEIR*(visibleBW - AggCIR) ‘Agg’ is computed based on active
queues only
• Where CIR is ‘bandwidth’ and EIR is ‘bw remaining” statements (if not specified
EIR=CIR)
• Slot position=packet_size/byte_per_us*(255/effBW)
byte_per_us (from clockrate of interface not SCR nor CIR …)

VTMS Implementation (overview)
Link
QID 1 CIR=x1, EIR=y1
High priority timing
wheel (LLQ) QID 2 CIR=x2, EIR=y2
QID 3 CIR=x3, EIR=y3
QID 5
N QID 19
•QIDs on High priority wheel are

processed prior to Low priority
Low priority timing wheel
wheel QIDs
(other than LLQ) •Each queue is served until:
–Burst size reached
–Queue becomes empty
•If queue is active, QID is
QID 10
QID 7
rescheduled based on EffBW of
N
QID 22
QID 39 the queue and dequeued packet
QID 15 length
Current slot index = N

VTMS mechanism specifics
• Virtual Time Policer prevent tx-ring FIFO

to overload (flow-control mechanism)
• If full, HI Q deferred to next slot, Lo
deferred 64B later

VTMS mechanism specifics
• Class BW granularity = 1/255

• Only one absolute PQ class (policer recommended)
• 1% reserved for PAK-priority packets
• Queue limit min 32 (configurable or 2*wred_max_th)
• You can have ‘Bandwidth’ (CIR) AND ‘Bw_remaining’
(EIR) % within a class
• Sub-optimal link use with low-BW classes (band % max-
util cmd) but could create LLQ high latency

Updates in latest IOS train
• set FR de, ATM CLP, EXP …

• Dual rate policer, multiple actions
• QOS in MPLS
• Bw percent in LLQ
• RSVP classification
• QoS preclassify
• FRTS interface congestion (12.2(4)T)

Frame Relay DE bit
class-map match-fr-de
match fr-de
FR
policy-map DE-ToS
class match-fr-de
set ip precedence 1
interface s4/0.1
service-policy input DE-ToS
policy-map rate-limit policy-map FRDE

class class-default
class police
set fr-de
police 512000 1500 1500
interface s4/0.1
conform-action transmit
service-policy output FRDE
exceed-action set-frde-transmit
! Only when be is used
interface ser4/0.1
service-policy output rate-limit

ATM CLP bit
ATM
policy-map SETCLP policy-map rate-limit

class class-default class police
set atm-clp police 512000 1500 1500
!(PA-A3) conform-action transmit
interface atm1/0/0 exceed-action set-clp-transmit
service-policy output SETCLP !
interface atm1/0/0
service-policy output rate-limit

QoS and MPLS
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | EXP |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Two methods are possible

• Single LSP per ‘QoS’ FEC: E-LSP
use EXP field in MPLS header to select Diff-Serv queue
By default IP prec copied in EXP labelS (cisco)
By default exp is not copied ‘down’ (in label below nor IPprec)
• Multiple LSPs per ‘QoS’ FEC: L-LSP
use Label to select Diff-Serv queue: (not currently
implemented

End to End QoS (12.2(13)T)
Customer CE PE Customer
QoS QoS SP QoS QoS QoS
Uniform mode: QoS bits modified by each domain …
Short pipe: Core QoS is independant of edge
Pipe: SP devices QoS is independant of ingress
End to End: Transparency is assured CE to CE

MPLS « CoS transparency »
LSP TE
LSP LDP MPLS

MPLS
exp 5 or n exp 2
IP: dsp 5 MPLS
MPLS exp 5 or n IP: dscp 5
MPLS
exp 5 or n exp 5 or n
MPLS
IP: dscp 5 MPLS exp 5 or n
exp 5 or n
IP: dscp 5
IP: dscp 5
• By default ingress IP prec copied in EXP labels (or manually set to ‘n’ new cli set mpls exp imposition ‘n’ replace
set mpls exp ‘n’)
• Classification behavior on egress PE use DSCP
• PHP should not be configured (use explicit-null) and use QOS group to map EXP to QOS-group for egress PE
classification based on EXP
• By default EXP is NOT copied down after POPping

CoS transparency Uniform mode
Assume something recolors the top-most label here to 0

‘set mpls experimental top-most (0-7)’
IP: MPLS MPLS IP:

dscp exp 5 exp 0 dscp
5 MPLS 0
MPLS MPLS
exp 5 exp 5 exp 0
IP: IP: IP:
dscp dscp dscp
5 5 5
• in both the MPLS-to-MPLS and the MPLS-to-IP cases, the PHB’s of the top-most popped label is
copied into the new top label or the IP DSCP if no label remains. ‘mpls propagate-cos CSCdv21062’
• Only works for 8 distinct PHB’s. Requires specific mapping dscp->mpls-exp->dscp if the distinct
PHB’s are encoded using more than the 3 precedence bits (table-map)
• Egress PE classification based on IP DSCP

CoS transparency Pipe mode
IP: MPLS MPLS IP:

5 MPLS 5
MPLS MPLS
exp 5 exp 5 exp 0
IP: IP: IP:
dscp dscp dscp
5 5 5
• the PHB’s of the top-most popped label is copied into the new top label but not copied in IP
DSCP
• classification is based on mpls-exp field (use qos-group/discard-class) of the top-most
received MPLS frame

CoS transparency Short-Pipe mode
IP: MPLS MPLS IP:

5 MPLS 5
MPLS MPLS
exp 5 exp 5 exp 0
IP: IP: IP:
dscp dscp dscp
5 5 5
• the PHB’s of the top-most popped label is copied into the new top label but
not copied in IP DSCP
• Egress PE classification still based on IP DSCP

CoS Transparency End to End
CE
PE
MPLS MPLS
IP: MPLS
exp 2 exp 2
dscp exp 2
5 IP: MPLS
IP: exp 2
dscp dscp
5 5 IP:
dscp
Push a Null-Label and 5
use its EXP field to
convey result of Copy EXP of popped Null-label
classification into EXP of pushed labels
Preserve DSCP
• QOS policy is done on CE side, reduce load/complexity on PE

–the mpls-exp of the received mpls frame is copied in memory and later copied in all the mpls-exp field of the
pushed labels.
–mpls ip encapsulate exp-null on CE intf facing PE (cscdv19312)

Diff-Serv over MPLS:
“coloring” MPLS Frames (PE)
class-map match-all DSCP-VoIP
match ip dscp 40
class-map match-any DSCP-Business
match ip dscp 32
class-map match-all DSCP-Management
match ip dscp 48
!
policy-map UPC
class DSCP-VoIP
set mpls exp 2 interface Serial0/0.1
service-policy input UPC
class DSCP-Management
set mpls exp 1 (since 12.1(5)T)
class DSCP-Business
police 40000 1500 1500
conform-action set-exp-transmit 1 (since 12.2(1)T)
exceed-action drop violate-action drop
class class-default
31
set mpls exp 0 © 2012 WIPRO LTD | WWW.WIPRO.COM
Diff-Serv over MPLS:
“matching” MPLS Frames (P)
class-map match-all MPLS-VoIP

match mpls exp 2 (since 12.0(7)T)
class-map match-any MPLS-Gold
match mpls exp 1
!
policy-map MPLS-QoS
class MPLS-VoIP
priority 24
class MPLS-Gold
bandwidth 44
random
class class-default interface Serial0/1
bandwidth 125
bandwidth 22
max-reserved-bandwidth 90
random tag ip
service-policy output MPLS-QoS

PE Local Packet Marking
PE
• QoS Group Id and Discard class for local
packet marking
• Always an input feature (before label
MPLS IP POP)
• Used to implement uniform and pipe
mode
• Recommended semantics
–QoS group identifies class
QoS Group Id –Discard class identifies drop
precedence
Input Output • Discard class can drive WRED
EXP Policy
POP
Policy
• Not all classes will have a drop
Discard Class precedence (e.g. EF, best effort)

Qos-group and discard-class
INPUT POLICY on Egress PE’s

OUTPUT POLICY on egress PE’s
class-map AF11 class-map AF1

match qos-group 1
match mpls exp top 0 …
policy-map input
class AF11
set qos-group 1 policy-map output
set discard-class 1 class AF1
bandwidth percent 20
random-detect discard-class-based
As egress PE remove all labels, if egress QOS is based on MPLS-EXP field

QoS-group and discard-class are used for egress classification and droping,

RSVP Packet Classification
Egress Interface/PVC
Unclassified
Queuing (LLQ)
flows voice conforming, admitted flows
PQ
non-voice conforming,
RSVP admitted flows Reserved
Classifi- Queues
cation
Class1
non-admitted flows, Class2
voice signalling traffic,
PATH and RESV msgs
Default/BE
• Since CSCdp21647 RSVP is able to recognize voice flow and put it in PQ

• Or use “ip rsvp pq-profile…” (12.1(3)T)
• picks up bearer traffic only - another classification mechanism must be used to prioritize
signalling traffic (use “ip rsvp signalling dscp nn” to assign dscp value to sig)

LLQ Configuration
>> Absolute Percent Specification (CSCds25849)

policy-map Multiservice policy-map Multiservice 75% rule
class VoIP class VoIP applies
priority 240 priority 240
(OR priority percent 10) OR priority percent 10
class business class business
bandwidth percent 30 bandwidth 512
class data class data
bandwidth percent 20 bandwidth 256
>> Relative Percent Specification

policy-map Multiservice 75% rule
class VoIP doesn’t
priority percent 10 apply
class business
bandwidth remaining percent 30 (75% rule always apply on PQ)
class class-default CSCdy18323 for platform
bandwidth remaining percent 20 consistencies
QoS pre-classify
• when « IP is in IP » output intf can’t classify

based on inner IP header
• for GRE, IPSec, L2TP
• QoS preclassify cmd applied on tunnel,
crypto-map or V template
• Store a copy of initial IP header for
classification after encap
• 12.1(5)T for 7100/7200 12.2.(2)T for 2600/3600

LLQ Before Encryption
IOS 12.2(13)T
marking CSCdw74248
eng-154069
In case of crypto congestion, two queues BEFORE

Routing / Switching Crypto Engine:
•No new CLI

•2 queues are enabled in front of Crypto Engines when
LLQ is enabled on egress intf
IPSec encryption
• Priority queue: for all ‘priority’ classes
classification • Default queue: for the others
•Error message if Sum of PQs oversubscribe CE
queuing/scheduling

Classification model (# of classes)
4/5 Class Model 8 Class Model QoS Baseline Model
Voice Voice
Realtime Interactive-Video
Video Streaming Video
Call Signaling Call Signaling Call Signaling
IP Routing
Network Control
Network Management
Critical Data Mission-Critical Data

Critical Data
Transactional Data
Bulk Data Bulk Data
Best Effort Best Effort Best Effort
Scavenger Scavenger Scavenger

32 Time © 2012 WIPRO LTD | WWW.WIPRO.COM
Classification model (marking & PHB)
11 Class
IPP,COS,EXP/DSCP PHB
QoS Baseline Model
Voice 5 / 46 EF/CS5
Video-Conferencing 4 / 34 AF41
Call Signaling 3 / 24 CS3 (ex AF31)
IP Routing 6 / 48 CS6
Network Management 2 / 16 CS2
Mission-Critical Data 3 / 26 or temp 25 AF31
Transactional Data 2 / 18-20 AF21-22
Bulk Data 1 / 10-12 AF11-12
Streaming Video 4 / 32 CS4
Scavenger 1/8 CS1
Best Effort 0/0 0

Aggregate QoS Enterprise classes to SP classes
Entreprise QOS model can cover up to 11 classes

On SP side, we don’t have this granularity and
SP deploy generally 3, 4 or 5 classes max
Some Rules while aggregating Enterprise Classes to SP Classes:
• Don’t combine VoIP with video for slow (<768 Kbps) lines, to avoid
excessive serialization delay (no frag on PQ!)
• Don’t combine Call Signaling with VoIP for slow links (<768 Kbps)
• Don’t mix TCP and UDP traffic in the same class, as far as
possible. Drop (via WRED) insensitive UDP traffic may dominate
drop-sensitive TCP traffic in case of congestion.(or drop UDP very
aggressively)
• Marking/Remarking for In/Out contract traffic (for WRED-exp drop)

Aggregate QoS Enterprise classes to SP classes
Core Traffic Load:

• 50% of Line speed
• A link may get congested (x2 in case of failure)
• EF class: 25% of line rate (max 50% under network
failure conditions) – policed at 50% of line rate
• Business class: 90% of remaining BW after Voice
has been serviced (policed at edge)
• BE class: 10% of the remaining BW after Voice has
been serviced

In & Out contract remarking (ie 5 SP classes)
MPLS EXP Values Are Set on Ingress PE’s

PE Classes Ingress-Interface to Reflect Local SP Policies
Real-Time In-Contract
EF MPLS EXP 5
Video Out-of-Contract
REAL-TIME
CS5 (Dropped)
Critical Data In-Contract
CE-to-PE CS6 MPLS EXP 3
Packets AF31 CRITICAL Critical Data Out-of-Contract
Marked DATA MPLS EXP 7
with Appropriate CS3
DSCP Values to
Gain Admission Video In-Contract
into Desired
AF21 MPLS EXP 2
SP Class VIDEO Video Out-of-Contract
CS2 (Dropped)
Bulk Data In-Contract
AF11 MPLS EXP 1
CS1 BULK Bulk Data Out-of-Contract
MPLS EXP 6
Best-Effort In-Contract
MPLS EXP 0
BEST-EFFORT Best-Effort Out-of-Contract
MPLS EXP 4
Class translation to 3 SP-Edge, and 3 SP-Core
Application DSCP
SP Edge Classes SP Core Classes
Routing CS6
REALTIME REALTIME
Voice EF EF 35 percent EF 25 percent
Interactive Video AF41 è CS5 CS5 CS5 (50% max)
Streaming Video CS4 X
CS6 CS6
Mission- Critical Data DSCP 25 è AF31
AF31 AF31
Call Signaling AF31/CS3 è CS5 CRITICAL CRITICAL
DATA DATA
Transactional Data AF21 è CS3 40 percent
CS3 CS3
Network Management CS2 è CS3
Bulk Data AF11 X - EFFORT -
BEST BEST EFFORT
Scavenger CS1->0 25%
Best Effort 0
• 3 Edge classes can support 9 Enterprise classes

•No recommendation for Streaming Video (UDP), Bulk Data (large, TCP sessions)
typically
• “UDP and TCP traffic should not be in the same class”
• ingress PE remap inter-video and call-sig to EXP5

Enterprise Classes SP Edge Classes SP Core Classes

DSCP EXP DSCP (EXP)
Application DSCP
Routing CS6 EXP 5
REALTIME
REALTIME
Voice EF EF EXP5
Up to 35 % max 25 %
Interactive Video AF41 è CS5 CS5
Streaming Video CS4 è AF21

CS6 CRITICAL CRITICAL
Mission - Critical Data DSCP 25 è AF31 AF31 20% EXP 6
EXP 6
EXP 3 EXP 3
Call Signaling AF31/CS3 è CS5 CS3
Out of
Transactional Data AF21 è CS3 contract=EXP1
Out of
Network Management CS2 AF21 VIDEO EXP 2 contract=EXP1
15 % EXP 2
Bulk Data AF11
CS2 -
BEST EFFORT
Scavenger CS1 ->0 BEST EFFORT
25% EXP 0 EXP 0
Best Effort 0 CS0, 1
• 4 Edge classes can support 10 Enterprise classes

• Either BULK or Video can’t be supported. They can be mixed with BE, but will
only get Best Effort Treatment
• Video in “Real Time” class => High speed link in edge (else not possible)


DSCP EXP DSCP (EXP)
Application DSCP
Routing CS6 5
REALTIME
REALTIME
Voice EF EF EF
Up to 35 % max 25 %
Interactive Video AF41 è CS5 CS5 CS5
EXP = 5
CS6 CRITICAL 20% 3,6 CS6
Mission - Critical Data DSCP 25 è AF31 AF31 AF31 CRITICAL
Call Signaling AF31/CS3 è CS5 CS3 EXP:
CS3 In Contract= 3, 2, 6
Transactional Data AF21 è CS3 AF21 VIDEO 2
CS2 15 % AF21
Network Management CS2 CS2
AF11 BULK 5% 1
Bulk Data AF11 CS1
- 1, 0
Scavenger CS1 è 0 CS0 BEST EFFORT
0
Best Effort 0
• 5 Edge classes can support all the 11 Enterprise classes

•In this case only exp4 is available for out of contract

summary
Enterprise Traffic Metro Traffic L2VPN Enterprise Edge Class Metro Cos Sample L2VPN Edge Class Core Class Core EXP
Class Class Class DSCP DSCP Metro Out of Name Name (DSCPs)
Nomenclatrure Queues contract
VOICE Voice transport CBR EF EF 5 priority Real Time Real Time 5 (EF, CS5)
Call Signaling Call Control CBR AF31/CS3 CS5 5 priority Real time Real time
“”
Interactive Video Interactive CBR AF41CS5 CS5 5 (see note 1) Priority Real time Real Time
Video (see note 1) “”
Streaming Video (Transactional VBR-rt CS4 AF21 AF21 With Critical Video/Mgnt Bus 2 (AF21, CS2)
data) data (note 2) Critical
Network SP network VBR-rt CS2 CS2 3Q2T Video/Mgnt Bus 7 (SPT traffic)
Management Mgnt (Ent. Net (Cos=7) Critical
(note 3) Mgnt in inside
Trans. Data) Enterprise
today
SPT =7
Routing Routing VBR-nrt CS6 CS6 6 3Q1T Bus Critical Bus 6 (CS6)
Critical
Mission Critical CIR/PIR VBR-nrt AF31 AF31 3 (CIR) 2Q2T 1 (out-of- Bus Critical Bus 3 (AF31, CS3)
data (out of contract 1 (PIR) 2Q1T contact) Critical 1 (Af31, CS3)
=CS1)
Transactional CIR/PIR VBR-nrt AF21CS3 CS3 3 (CIR) 2Q2T 1 (out-of- Bus Critical Bus
Data (out of contract 1 (PIR) 2Q1T contact) Critical “”
=CS1)
Bulk BULK UBR AF11CS0 CS0 0 1Q1T Best Effort Best Effort 0 (CS0)
Scavenger BULK UBR CS1CS0 CS0 0 1Q1T Best Effort Best Effort “”
Best Effort Best Effort UBR 0 0 1Q1T Best Effort Best Effort “”
1. Inclusion of Interactive Video in real-time class needs high edge link bandwidth. If excluded, it can be included in another class (e.g.,
Video or Business Critical class) if that class can support the latency/jitter requirements of interactive video.
2. Streaming Video is included with Business Class in Metro solution
3. Metro Solution colors the Enterprise SPT traffic with Cos = EXP = 7 (not transported across SP network). Enterprise Network Mgnt traffic is
included in Transaction Data Class or Critical Data Class.
4. Reserve EXP 7 for future use, and 6 for Routing. That leaves EXP 4 in the core, which can possibly be used for out-of-contract traffic of
some class.
5. Streaming Video: assumed not to have strict delay, jitter requirements (e.g, VOD having large jitter buffer). If it has strict delay, jitter
33 requirements, it needs to be combined with Real Time (needs high bandwidth links)
© 2012 WIPRO LTD | WWW.WIPRO.COM
Latest enhancements
• ‘CLI’ enhancement (12.2(13)T…)

–Hierarchical CB-marking (CSCdw78847)
–Percent keyword for CB-policing, CB-shaping with bc, be in ms
–3 level hierarchy policer (CSCdw16046)
–QoS marking table ‘table-map cos-dscp’
–‘bandwidth inherit’ (CSCdy03863 in 12.2 also)
• Fragmentation before encryption
• RTP, c-RTP(CSCds43465) & FRTS in MQC
• FR-PVC bundles (‘ATM like’)

Latest enhancements (12.3T…)
• Voice Adaptive Traffic Shaping (EDCS-182071)

–Possibility to use CIR when no voice packets
–And use minCIR when voice is active (12.2(15)T)
• Turbo Qos classify (EDCS-190137 cscdz02344)
• Flow based QOS CBWFQ on low-end 12.0(26)S
for 7200 (Available in 7500 hqf FCS via ‘fair-queue’ cmd)
• MQC consistency !!! EDCS-137373
• Full L2 overhead accounting EDCS-230726

Latest enhancements (12.3T)
• QOS for DoS prevention

–Control plane policing (12.3(7)T)
• Qos-group per crypto-map (12.3(8)T)
• NBAR RTCP PDLM (auto-qos 12.3(7)T)

• Enhanced cRTP (12.3(11)T reordering and re-sending)
• QoS BW estimation tool (12.3(14)T ’corvil’ algo)

Conclusions
• QoS not inherent to network

• no BW creation, requires provisioning
• Requires for each flow:
–Classification, metering,
–and congestion control

Conclusions
• PQ, CQ (and FIFO) available for ages but many side effects.
• New mechanisms for “real” QoS, available only since 12.1-12.2 (T ...)
Today 12.3M offer a large choice of QoS mechanisms
• Requires upgrade plan ...

Backup slides
NCE / spicard © 2005, Cisco Systems, Inc. Cisco internal 337

QoS in SP environment
• Elaborate DiffServ Edge

implementation
Access link capacity controlled by CE
customer (prone to congestion)
Trust boundary (SLA CE
PE
enforcement) PE
• Backbone must be able to support
customer SLA IP/MPLS
• Per-customer QoS policies only at CE PE
the edge PE CE
• Ingress SLA, Egress SLA
CE
CE

L3 QoS models
• L3/nC/nD
–n customer per interface (fr/atm/vlans)
• L3/1C/1D (special case of nC/nD)
–1 customer per interface (ppp/hdlc)
• L3/nC/mD
–Multiple VC per customer per intf (fr/atm/vlans)

IP SLA (service for customer)
• Typically between 3 and 5

classes (real time, video,
Class1 interactive, business, BE)
Class2 • Delay, jitter and loss guarantees
Link/shaper
rate for conforming real-time traffic
Class2Class4 • Combination of delay and loss
Class5 guarantees for data traffic
• Sum of committed bandwidth
(per-class CIR) not to exceed
link/shaper rate
Committed Dela • Additional classes not visible to
Class JitterLoss
BW y
customer may exist (e.g.
Real management, control traffic)
X Low Low Low
time
Interacti
Y Low NA Low
ve
Busines
Z NA NA Low
s
Best
NA NA NA NA
Effort
Customer, SP-edge, SP-Core classes

DSCP EXP DSCP (EXP)
Application DSCP
Routing CS6 5
REALTIME
REALTIME
Voice EF EF EF
Up to 35 % max 25 %
Interactive Video AF41 è CS5 CS5 CS5
EXP = 5
CS6 CRITICAL 20% 3,6 CS6
Mission - Critical Data DSCP 25 è AF31 AF31 AF31 CRITICAL
Call Signaling AF31/CS3 è CS5 CS3 EXP:
CS3 In Contract= 3, 2, 6
Transactional Data AF21 è CS3 AF21 VIDEO 2
CS2 15 % AF21
Network Management CS2 CS2
AF11 BULK 5% 1
Bulk Data AF11 CS1
- 1, 0
Scavenger CS1 è 0 CS0 BEST EFFORT
0
Best Effort 0
• 5 Edge classes can support all the 11 Enterprise classes

QoS policies, Where ?
Edge Policies IP / MPLS Core Policies
CE Outbound PE Inbound PE Outbound

Policy Policy Policy
Access Link Core Link

PE Outbound PE Inbound P Outbound
CE Router PE Router Policy P Router
Policy Policy

SLA enforcement
• On PE Ingress/Egress
–To control per customer SLA
• On P devices
–3 options :
–50% Over provisioning NO QoS needed (but be
careful of link failure!)
–Diffserv (usually only egress intf)
–TE tunnel (could be complex to manage)

IP SLA Enforcement
• Managed vs. unmanaged IP

service
• Trust boundary on PE for IP/MPLS
unmanaged service
PE PE
• Trust boundary on CE for
Unmanaged Managed
managed service CE
CE
• Trust boundary defines SLA
enforcement point
• Different QoS design options
Site 1
Site 2

Managed vs. Unmanaged CE Routers
IP SLA
Managed CE Router
Customer PE
Access Router Core P Router
Link
Edge
CE Router Link
Edge POP
Provider
Classification + Boundary
Boundary of Of Trust
Trust
UnManaged CE Router
IP SLA
Customer PE
Access Core P Router
Router
Link
Edge
CE Router Link
POP
Boundary
Of Trust +
Edge
Classification

SLA enforcement
IP QoS – Managed Service
• CE output and PE output
policies enforce SLA
• Traffic classification and
marking on CE
• No input QoS policies Managed PE
generally needed CE
• Explicit-null encapsulation may
be used on CE to avoid
remarking customer traffic CE PE
Output Policy Output Policy
Classification / LLQ
Marking WRED
LLQ [Shaping]
WRED [LFI / cRTP]
[Shaping]
[LFI / cRTP]

Sample CE Output Policy –
Managed Service
Real Time Priority Queue

Tail drop
Video
TD
Interactive
? TD
Business
WRED
Best
WRED
Effort
Link
Fragmentation
Congestion Management and Interleaving
Classifier Congestion Avoidance Shaping (LFI)
• LFI used in slow links to reduce delay and jitter for real-time traffic + cRTP for
voice
• WRED used for TCP-friendly packet dropping
IP QoS – Unmanaged Service
• PE input and PE output policies

enforce SLA
• Traffic classification and markings
on PE
• CE policies require coordination with
Unmanaged PE policies (e.g. LFI, cRTP, end-to-
PE end latency !!!!)
CE
• More CPU required on PE …
PE
CE Input Policy
Classification /
Output Policy Marking
<NOT SP controlled > Policing
PE
Output Policy
LLQ
WRED
[Shaping]
[LFI / cRTP]

Sample PE Input Policy –
Unmanaged Service
• Excess real time (voice) usually
Real Time dropped
• Excess data marked down
• Dropping excess data at policer
Video would affect many TCP sessions
• Limited bandwidth sharing between
classes with aggregate sub-rate
Interactive • Voice and video will benefit from
? admission control
Business
Best
Effort
Classifier Policing

In & Out contract remarking (ie 5 SP classes)
MPLS EXP Values Are Set on Ingress PE’s

PE Classes Ingress-Interface to Reflect Local SP Policies
Real-Time In-Contract
EF MPLS EXP 5
Video Out-of-Contract
REAL-TIME
CS5 (Dropped)
Critical Data In-Contract
CE-to-PE CS6 MPLS EXP 3
Packets AF31 CRITICAL Critical Data Out-of-Contract
Marked DATA MPLS EXP 7
with Appropriate CS3
DSCP Values to
Gain Admission Video In-Contract
into Desired
AF21 MPLS EXP 2
SP Class VIDEO Video Out-of-Contract
CS2 (Dropped)
Bulk Data In-Contract
AF11 MPLS EXP 1
CS1 BULK Bulk Data Out-of-Contract
MPLS EXP 6
Best-Effort In-Contract
MPLS EXP 0
BEST-EFFORT Best-Effort Out-of-Contract
MPLS EXP 4
SA Agent (SAA) and Service Delivery
SLAs Are Becoming an Integral Part of Service Delivery

• Businesses are relying on them • SLA is cornerstone of
for mission critical applications carriers’ differentiated
(voice, clearing,…) service offerings
Service Provider
Enterprise Shared Network
Enterprise
Network Network

SLA Components
• Delay
• Jitter
• Bandwidth
• Availability
• Packet Loss
• Out of Sequence (OoS)
•…

The idea behind SAA
• If you have a running Cisco IOS® router, turn it into a probing device.
• Re-use and enhance existing network management applications.
(ex: CW2K, VPNSC, Infovista, Concord eHealth,
Agilent Firehunter,…).

Measurement Capabilities ‘probes’
Increasing Service Value

Path Jitter
Jitter Path
Echo
DLSw Echo
Echo
HTTP
DNS/
DHCP SNA APM
FTP ICMP
UDP ATM*
TCP
Connect Frame Relay
QoS Cisco IOS-Based

Service Assurance* MPLS VPN
Support
Agent Aware
(ToS) *With Cisco IOS 12.2(9)T
SAA Architecture Overview
Probe
Responder
Network Responder
SA Agent
SNMP/CLI IP Server
Targets
Management

QOS & ATM (Paris Project)
• Implemented on PA-A3
(TX-ring per VC allows ‘fancy’ queuing per VC, tx-ring tuning
per VC)
• Phase 1 - Per-VC WRED (single VC)
• Phase 2 - Precedence Mapping (multiple VC)
–Bundle Management
• Phase 3 - Per-VC WFQ
–

Per-VC WRED : Ph 1
Traffic
Threshold Exceeded Shaping
VIP2-50 PA-A3-XX
VC1
VC2
VC3
No discard
Per-VC Per-VC on PA
WRED: Queues
Intelligent Discard
IP ATM COS-Ph2: Bundle
Prec: 5 - 7 VC1: VBR-nrt
Prec: 0 - 4 VC2: ABR
• A single Bundle routing neighborship!

(several PVCs grouped in one intf)
• Flexible IP CoS mapping to VCs
• RED (WRED) runs on each VC queue
VC Bundle Mgmt
• Two Modes:
– Protected VC rule : when a protected VC goes
down, the bundle goes down
– Protected group rule : when all members in the
protected group fail, the bundle is declared DOWN
–When a bundle is declared down, no traffic is
forwarded out of the bundle

Bumping
• VC bumping: possibility for a traffic

mapped to a VC X to be forwarded onto
another VC Y, in case of failure of X.
–Implicit bumping rule : Y is the next lower
precedence level VC is selected,
–Explicit bumping rule : Y is explicitely
specified.

Bumping (Cont.)
• Traffic is restored to the original VC when it

comes back.
• « Reject Bumping »: It is possible for a VC to be
configured not to accept the bumped traffic
• When no alternate VC for some bumped traffic,
the bundle will be declared down.

Bumping (Cont.)
• To prevent from declaring a bundle DOWN due

to the failure of the lowest precedence VC,
explicit bumping should be configured on the
lowest precedence.
• Should be used in conjunction with the protected
group rule
• If the VC which carries the bumped traffic fails
also, the traffic will follow the bumping rules
specified for that VC.

Bundle example
TOS 6-7 <-> VC 1 - ATM VBR-nrt

Protected VC

Protected Group- bump explicit 7

Protected Group - bump implicit
TOS 0-1 <-> VC 4 - ATM UBR

Protected Group
Based on MPLS-EXP (since 12.2(8)T)

LLQ per VC:ph3
• Allows LLQ per PVC (in bundle)

Multicast
NCE / spicard © 2005, Cisco Systems, Inc. Cisco internal 365

Multicast workshop
• Identify mcast flows (type, BW req..)

• Topology: many2many or one2many
• Source location
• Devices involved (L2 switches, routers)
• Client Registration type IGMP v2, v3(SSM)
• Mcast addressing
• Qos SLA

Multicast Disadvantages
Multicast Is UDP Based!!!
• Best Effort Delivery: Drops are to be expected. Multicast applications should not
expect reliable delivery of data and should be designed accordingly. Reliable
Multicast is still an area for much research. Expect to see more developments in this
area.
• No Congestion Avoidance: Lack of TCP windowing and “slow-start” mechanisms
can result in network congestion. If possible, Multicast applications should attempt to
detect and avoid congestion conditions.
• Duplicates: Some multicast protocol mechanisms (e.g. Asserts, Registers and SPT
Transitions) result in the occasional generation of duplicate packets. Multicast
applications should be designed to expect occasional duplicate packets.
• Out of Order Delivery : Some protocol mechanisms may also result in out of order
delivery of packets.

Multicast Components
Cisco End-to-End Architecture
ISP A
ISP B
MSDP
RP
Multicast Source
Multicast Source DR Y
X RP
ISP B
ISP A
IGMP Snooping, MBGP
CGMP, RGMP
DR
IGMP PIM-SM DR
Bidir PIM
PIM-SSM
MVPN
Campus Multicast Interdomain Multicast
• End Stations (hosts-to-routers): • Multicast routing across
–IGMP domains MBGP
• Switches (Layer 2 Optimization):
CGMP, IGMP Snooping or RGMP • Multicast Source Discovery
• Routers (Multicast Forwarding MSDP with PIM-SM
Protocol): • Source Specific Multicast
PIM Sparse Mode or Bidirectional PIM PIM-SSM
IP Multicast Group Concept
1. You must be a Sender & Receiver

“member” of a group Group
Member 3
2. to receive
sendit to
data Sender
If you group
address, all
members receive it A B D “Non” Group
3. You do not have to Member
be C E
a member of a
group
to send to a group Group Group
Member 1 Member 2
Receiver Receiver
Click here to add Customer / Partner Logo

Quality of Service

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Quality of Service

Uploaded by

Copyright:

Available Formats

Quality of Service

1 © 2012 WIPRO LTD | WWW.WIPRO.COM

2 © 2012 WIPRO LTD | WWW.WIPRO.COM

3 © 2012 WIPRO LTD | WWW.WIPRO.COM

4 © 2012 WIPRO LTD | WWW.WIPRO.COM

• Lack of bandwidth: multiple flows compete for a limited

5 © 2012 WIPRO LTD | WWW.WIPRO.COM

6 © 2012 WIPRO LTD | WWW.WIPRO.COM

7 © 2012 WIPRO LTD | WWW.WIPRO.COM

8 © 2012 WIPRO LTD | WWW.WIPRO.COM

9 © 2012 WIPRO LTD | WWW.WIPRO.COM

10 © 2012 WIPRO LTD | WWW.WIPRO.COM

11 © 2012 WIPRO LTD | WWW.WIPRO.COM

12 © 2012 WIPRO LTD | WWW.WIPRO.COM

13 © 2012 WIPRO LTD | WWW.WIPRO.COM

14 © 2012 WIPRO LTD | WWW.WIPRO.COM

• A one-to-one mapping between traffic classes and QoS

15 © 2012 WIPRO LTD | WWW.WIPRO.COM

16 © 2012 WIPRO LTD | WWW.WIPRO.COM

17 © 2012 WIPRO LTD | WWW.WIPRO.COM

18 © 2012 WIPRO LTD | WWW.WIPRO.COM

19 © 2012 WIPRO LTD | WWW.WIPRO.COM

20 © 2012 WIPRO LTD | WWW.WIPRO.COM

• A typical enterprise might define five traffic classes as

21 © 2012 WIPRO LTD | WWW.WIPRO.COM

22 © 2012 WIPRO LTD | WWW.WIPRO.COM

Voice and Video Quality Absolute Priority

ERP System Business Critical

Manufacturing System Business Critical

Internal Email and other Tools Business Best effort

Internet Access Best effort ( Lowest Priority)

24 © 2012 WIPRO LTD | WWW.WIPRO.COM

25 © 2012 WIPRO LTD | WWW.WIPRO.COM

• Command Language Interface (CLI)

26 © 2012 WIPRO LTD | WWW.WIPRO.COM

27 © 2012 WIPRO LTD | WWW.WIPRO.COM

28 © 2012 WIPRO LTD | WWW.WIPRO.COM

29 © 2012 WIPRO LTD | WWW.WIPRO.COM

30 © 2012 WIPRO LTD | WWW.WIPRO.COM

31 © 2012 WIPRO LTD | WWW.WIPRO.COM

32 © 2012 WIPRO LTD | WWW.WIPRO.COM

33 © 2012 WIPRO LTD | WWW.WIPRO.COM

34 © 2012 WIPRO LTD | WWW.WIPRO.COM

35 © 2012 WIPRO LTD | WWW.WIPRO.COM

36 © 2012 WIPRO LTD | WWW.WIPRO.COM

37 © 2012 WIPRO LTD | WWW.WIPRO.COM

Integrated Services Sets aside some bandwidth for applications that

Best Effort No QoS is applied to packets

IntServ Applications signal to the network that they

39 © 2012 WIPRO LTD | WWW.WIPRO.COM

40 © 2012 WIPRO LTD | WWW.WIPRO.COM

41 © 2012 WIPRO LTD | WWW.WIPRO.COM

42 © 2012 WIPRO LTD | WWW.WIPRO.COM

43 © 2012 WIPRO LTD | WWW.WIPRO.COM

44 © 2012 WIPRO LTD | WWW.WIPRO.COM

45 © 2012 WIPRO LTD | WWW.WIPRO.COM

46 © 2012 WIPRO LTD | WWW.WIPRO.COM

47 © 2012 WIPRO LTD | WWW.WIPRO.COM

48 © 2012 WIPRO LTD | WWW.WIPRO.COM

49 © 2012 WIPRO LTD | WWW.WIPRO.COM

50 © 2012 WIPRO LTD | WWW.WIPRO.COM

VoIP Bus Internet

• Wide variety of services and provisioning policies