s10 - Ip Qos - Ip Over Atm

10
IP over ATM
Overview
This module focuses on IP QoS mechanisms that can be used on ATM interfaces.
It includes the following topics:
n Introduction to IP over ATM
n Per-VC WRED
n VC Bundling
n Per-VC CB-WFQ
n RSVP to SVC Mapping
Objectives
Upon completion of this module, you will be able to perform the following tasks:
n List the requirements of IP QoS in combination with ATM QoS
n Describe the hardware and software requirements for advanced IP QoS
mechanisms on ATM interfaces
n Describe per-VC queuing
n Describe and configure per-VC WRED
n Describe and configure VC bundling
n Describe and configure per-VC CB-WFQ
n Describe RSVP to SVC mapping
n Monitor and troubleshoot IP QoS on ATM interfaces
10-2 IP QoS IP over ATM Copyright 2001, Cisco Systems, Inc.
Introduction to IP over ATM
Objectives
Upon completion of this lesson, you will be able to perform the following tasks:
n Describe the QoS-related problems when using ATM networks
Copyright 2001, Cisco Systems, Inc. IP QoS IP over ATM 10-3
2001, Cisco Systems, Inc. IP QoS IP over ATM-5
IP vs. ATM
Technology comparison
IP vs. ATM
Technology comparison
IP
Connectionless
Per-packet QoS (IP
precedence)
Small number of service
classes
IP precedence or DSCP
does not encode
service parameters
ATM
Connection oriented
Per-connection (virtual
circuit) QoS
Large number of QoS
traffic classes (CBR,
VBR, UBR, ABR)
Rich traffic parameters
(PCR, MCR, SCR ...)
specified for each VC

The Internet Protocol (IP) is a routed protocol that is used to transmit data in
packets. It uses the best-effort delivery for individual packets without any flow
control. Transmission Control Protocol (TCP) is used with IP to provide a
connection-oriented service.
Asynchronous Transfer Mode (ATM), on the other hand, provides connections
between endpoints in the ATM network. The connections are called virtual circuits
(VCs).
IPs default best effort service can be supplemented by differentiated quality of
service based on IP precedence or DSCP marking. A QoS solution using IP
precedence is limited to 8 classes, 2 of which are reserved and 1 should be used
for the default best-effort class. A QoS solution using DSCP scales up to 64
classes.
ATM provides a wider range of services:
n Constant Bit Rate (CBR) is useful for delay-sensitive applications such as
voice. This service provides bandwidth and delay guarantees.
n Variable Bit RateReal Time (VBR-RT) is useful for burstier delay-sensitive
applications. This service provides bandwidth and delay guarantees.
n Variable Bit RateNon Real Time (VBR-NRT) is useful for bursty traffic.
This service provides bandwidth guarantees.
n Available Bit Rate (ABR) is useful for best-effort traffic that is allowed more
bandwidth, when available or configured. This service provides bandwidth
guarantees and access to extra bandwidth.
n Unspecified Bit Rate is useful for the real best effort where there are no
guarantees.
IPs IP precedence or DSCP are only used to mark packets. They do not include
any service parameters. Service parameters depend on the QoS mechanism being
deployed.
ATMs services also include various per-connection service parameters, such as:
n Sustained Cell Rate (SCR) for CBR, VBR and ABR services
n Minimum Cell Rate (MIR) for ABR
n Peak Cell Rate (PCR) for VBR, ABR and UBR services
n Maximum Burst Size (MBS)
Both IP and ATM can implement Quality of Service (QoS). The decision on which
technology to use for quality of service should be based on a number of factors,
such as:
n Availability of ATM
n Interaction between ATM and IP
n Scalability options of the technology
n Performance limitations
This module introduces the possibilities of combining IP QoS with ATM.

Integrating IP and ATM Integrating IP and ATM
Overlay model (ATM forum)
ATM VCs are manually established between pairs
of devices
IP packets are sent across these VCs
ATM switches are not IP aware
Peer model (MPLS)
ATM switches are IP aware on control (but not
data) plane
ATM VCs are established on-demand based on IP
routing tables

There are two main approaches to integration of IP with/over ATM:
n The traditional way (overlay model) is to use individual permanent virtual
circuits (PVC) to establish point-to-point adjacencies between IP routers. IP
routing protocols are used to provide reachability across a network of ATM
connections. ATM has no knowledge of IP and cannot use IP information to
optimize its links.
n The newer approach (MPLS) is to make ATM switches IP aware. ATM
switches run an IP routing protocol to establish virtual circuits.
This module focuses on the QoS available with traditional permanent and switched
virtual circuits (PVCs and SVCs).
The IP QoS- IP over MPLS module discusses QoS possibilities when using the
peer model.

IP QoS and ATM IP QoS and ATM
Routers can be interconnected over an ATM
backbone using different ATM services:
UBR congestion management is virtually
impossible because routers are allowed to
transmit packets at line speed
VBR congestion management is easier, but it
requires conservative setting of transmit rates
CBR similar to VBR from IP perspective
ABR pushes congestion back to the source,
requires dynamic adjustment to available
bandwidth

Achieving good quality of service for IP classes greatly depends on the type of
ATM network and services used.
n Using UBR, prevents routers from detecting congestion in the network. It is
therefore difficult to manage congestion based on IP precedence or DSCP.
The reason for this is because all packet drops happen on the congested link
somewhere in the ATM network.
n VBR makes it easier to push congestion back to the source where it can be
managed by routers.
n CBR is typically used for non-bursty delay sensitive traffic. It is therefore
more important to prevent congestion by correctly provisioning the class that is
using CBR.
n ABR is a good solution where bandwidth can be utilized to the maximum
without having many drops in the ATM network.

UBR Virtual Circuits UBR Virtual Circuits
Solution:
Set CLP on the router based on IP information to minimize the
effect of cell drops
No congestion
Router allowed to
send at full speed
Congestion
Random
CLP marking
Unintelligent drops
based on CLP

A solution using UBR can be improved in terms of IP QoS, by marking less
important packets with the CLP bit for congestion control. In case of congestion,
the ATM switches will drop the less important packets to give more bandwidth for
the higher-priority packets.
The ATM FORUM also calls the UBR service category a best effort service,
which requires neither tightly constrained delay nor delay variation. In fact, UBR
provides no specific quality of service or guarantee throughput whatsoever. This
traffic is therefore at risk since the network provides no performance guarantees
for UBR traffic. The Internet and Local Area Networks are examples of this type
of best effort delivery performance. Examples of this are LAN emulation
(LANE), IP over ATM, and non-mission-critical traffic.
This solution is fairly limited, since it allows for only two classes on the IP layer
where congestion should be managed.

VBR Virtual Circuits VBR Virtual Circuits
Solution:
Set CLP on the router based on IP information
Use available IP QoS mechanisms to manage congestion at the
source
Router is sending
at configured rate
Congestion is
possible
Unintelligent random
drops
Congestion!

A solution using VBR is better at providing feedback to routers sending cells into
the ATM network. Congestion will occur on a routers virtual circuit, where it can
be managed by using the QoS mechanisms available in the Cisco IOS software.
CLP marking can be used for less-important packets or for those packets above
the Sustained Cell Rate (SCR) to improve the chances for higher-priority packets
when congestion occurs in the ATM network.
The rt-VBR service category supports time-sensitive applications, which also
requires constrained delay and delay variation requirements, but which transmit at
a time varying rate constrained to a PCR, SCR, and MBS define a traffic contract
in terms of the worst-case source traffic pattern for which the network guarantees
a specified QOS. Examples of such bursty, delay-variation-sensitive sources are
voice and variable-bit-rate video.
The nrt-VBR service category supports applications that have no constraints on
delay and delay variations, but which still have variable-rate, bursty traffic
characteristics. This class of application expects a low Cell Loss Ratio (CLR).
The traffic contract is the same as that for rt-VBR. Applications include packet
data transfers, terminal sessions, and file transfers. Networks may statistically
multiplex these VBR sources effectively.
CBR and ABR Virtual Circuits CBR and ABR Virtual Circuits
Solution:
Use available IP QoS mechanism to handle congestion at the
source
Router is sending
at configured rate.
Congestion!

CBR virtual circuits, are used for delay-sensitive traffic. This traffic should not
experience congestion due to keeping the quality of data being transmitted. If
congestion occurs, it can be managed by the IP layer using the IP QoS
mechanisms on the routers ATM interface.
The CBR service category supports real-time applications requiring a fixed
amount of capacity defined by the PCR. CBR supports tightly constrained
variations in delay. Example applications are voice, constant-bit-rate video, and
Circuit Emulation Services (CES). Normally, networks must allocate the peak rate
to these types of source.
The ABR service category works in cooperation with sources that can change
their transmission rate in response to rate-based network feedback used in the
context of closed-loop flow control. The aim of ABR service is to dynamically
provide access to capacity currently not in use by other service categories to users
who can adjust their transmission rate in response to feedback. In exchange for
this cooperation by the user, the network provides a service with very low loss.
Applications specify a maximum transmit-rate (PCR_ and the minimum required
rate, called the Minimum Cell Rate (MCR). ABR service does not provide
bounded delay variation; hence real-time applications are for ABR are LAN
interconnection, high-performance file transfers, database archival, non-time-
sensitive traffic, and web browsing.
Congestion Management in ATM
Networks
Congestion Management in ATM
Networks
Congestion management on routers should
be performed on a per-VC basis
Design options:
Make sure there is no congestion in the ATM
network (ABR, CBR, VBR) and use IP QoS
mechanisms at the source (CB-WFQ, WRED)
Mark less important packets with the CLP bit in
case there is congestion in the ATM network (CB-
Policing, CB-Marking)
Use multiple parallel (per-CoS) virtual circuits with
ATM QoS (VC Bundling)

This module discusses three different approaches to designing QoS in IP networks
on ATM:
1. Using IP QoS mechanisms to ensure there is no congestion in the AMT
network
2. Using ATM QoS mechanisms with IP precedence used for classification (VC
Bundling)
3. Combining both IP and ATM QoS mechanisms

Per-VC Queuing Per-VC Queuing
Per-VC queuing is required in order to handle congestion on per-VC
basis
Per-VC queuing prevents head-of-line blocking by slow virtual circuits
ATM Port Adapter
VC 1/50
VC 1/64
VC 1/76
VC 1/39
ATM interface
Cell queue VC 1/50
Cell queue VC 1/64
Cell queue VC 1/76
Cell queue VC 1/39
VIP Memory
Frame queue VC 1/50
Frame queue VC 1/64
Frame queue VC 1/76
Frame queue VC 1/39
ATM
hardware
shaping
Per-VC queuing with per-VC
congestion management

One of the most important parts of implementing QoS is to make ATM virtual
circuits appear as physical interfaces on routers; that is, each VC must have its
own queue (per-VC queuing). Per-VC queuing prevents one congested VC from
slowing down other VCs (head-of-line blocking).
Per-VC queuing can then be supplemented by various IP QoS mechanisms, such
as:
n WRED
n CAR
n CB-WFQ
n CB-LLQ
n CB-Policing
n CB-Shaping
n CB-Marking
CB-Marking and CB-Policing can also be used to set the CLP bit.

Summary
The following steps have to be taken prior to the designing of a QoS solution for IP
over ATM:
n Implement Per-VC queuing (to prevent head-of-line blocking and allow for IP
QoS mechanisms to be implemented on individual virtual circuits)
n Decide on the technology that will be used to implement QoS
Review Questions
Answer the following questions:
1. What are the main differences between IP and ATM?
2. Which QoS services does ATM support?
3. How should congestion be handled when an ATM backbone is used?
4. Why is per-VC queuing so important?
Per-VC WRED
Objectives
n Describe per-VC WRED
n Configure per-VC WRED
n Monitor and troubleshoot per-VC WRED
Per-VC WRED Per-VC WRED
Single ATM VC is established over an ATM
cloud between a pair of routers
ABR, VBR, UBR or CBR
Using UBR will not result in proper operation, as
there is no ATM shaping in UBR
All IP traffic toward a next-hop router is
forwarded across a single ATM VC
Congestion is managed entirely on the IP
layer using WRED on each individual ATM
VC, resulting in differentiated IP services

A simple addition to best-effort service on ATM interfaces is Weighted Random
Early Detection (WRED). WRED is most efficient when the majority of the traffic
is TCP (TCP reacts to random drops and slows down the transmission rate). With
other protocols, packet sources may not respond or may resend dropped packets at
the same rate. Thus, dropping packets does not decrease congestion. WRED
treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP
traffic is more likely to be dropped than IP traffic
UBR would probably result in congestion somewhere in the ATM network, thus
preventing any intelligent congestion management on the IP layer.
Any other ATM service (CBR, VBR or ABR) will push congestion back to the
source where WRED can be used to drop packets based on the IP precedence or
DSCP value.

Per-VC WRED : Intelligent
IP Packet Discard
Per-VC WRED : Intelligent
IP Packet Discard
VIP2-50 PA-A3-XX
Per Per--VC VC
WRED: WRED:
Intelligent Discard Intelligent Discard
Threshold Exceeded
VC1
VC2
VC3
No discard No discard
on PA on PA
Traffic Traffic
Shaping Shaping
Per Per--VC VC
Queues Queues

Per-VC queuing requires an Enhanced ATM Port Adapter that support up to 4096
cell queues. Each virtual circuit is assigned a queue and the ATM scheduler
forwards cells according to the ATM service and shaping parameters.
The router (or VIP on Cisco 7x00 series routers) also assigns one queue per virtual
circuit.
Cell departure is shaped if ABR, VBR or CBR services are used, thus causing
congestion in the frame queue if packet arrival is greater than the shaping rate in
ATM. Per-VC WRED can be used to manage congestion within individual queues
(classes).

Configuring Per-VC WRED Configuring Per-VC WRED
The following configuration steps are needed
to enable per-VC WRED:
Create a Random-Detect-Group template with a
WRED profile
Apply the WRED template to an ATM interface or
to individual ATM VCs
Verify and monitor the operation of per-VC WRED

Applying WRED to individual VCs is slightly different than applying WRED to
interfaces. A Random Detect Group must be created if non-default WRED
profiles need to be used on VCs. Standard WRED parameters (per-precedence
minimum threshold, maximum threshold and maximum drop probability) are set in
the random-detect-group configuration mode.

random-detect-group name random-detect-group name
Router(config)#
Creates a WRED template
Create and configure RED-group Create and configure RED-group
exponential-weighting-constant exp exponential-weighting-constant exp
Router(cfg-red-group)#
Defines WRED weighting constant
Default: 9
precedence IP-prec min-threshold max-threshold prob-denominator
precedence IP-prec min-threshold max-threshold prob-denominator
Router(cfg-red-group)#
Defines RED profile for specified precedence
Default: as with per-interface WRED

The random-detect-group global configuration command creates a WRED
profile and enters the red-group configuration mode. WRED per-precedence
profiles are configured in the red-group configuration mode, using similar
commands as with per-interface WRED, except the commands are not preceded
by the random-detect keyword.
Any class (IP precedence) can be configured with a RED profile different from
the default by using the precedence command in the red-group configuration
mode:
n Minimum thresholdWhen the average queue depth is above the minimum
threshold, RED starts dropping packets. The rate of packet drop increases
linearly as the average queue size increases, until the average queue size
reaches the maximum threshold.
n Maximum thresholdWhen the average queue size is above the maximum
threshold, all packets are dropped. If the difference between the maximum
threshold and the minimum threshold is too small, many packets might be
dropped at once, resulting in global synchronization.
n Mark probability denominatorThis is the fraction of packets dropped
when the average queue depth is at the maximum threshold. For example, if
the denominator is 512, one out of every 512 packets is dropped when the
average queue is at the maximum threshold.
WRED does not calculate the drop probability using the current queue length, but
instead uses the average queue length. The average queue length is constantly
recalculated, using two terms:
n The previously calculated average queue size
n The current queue size
An exponential weighting constant N influences the calculation by weighing the
two terms. It therefore influences how the average queue size follows the current
queue size, in the following way:
n A low value of N makes the current queue size more significant in the new
average size calculation, therefore allowing larger bursts
n A high value of N makes the previous average queue size more significant in
the new average size calculation, so that bursts influence the new value to a
smaller degree
The default value is 9 and should suffice for most scenarios, except perhaps those
involving extremely high-speed interfaces (such as OC12), where it can be
increased slightly (to about 12) to allow more bursts.
Note The default WRED parameter values are based on the best available data.
Cisco recommends that you do not change the parameters from their default
values unless you have determined that your applications will benefit from the
changed values.

Apply WRED group to
an ATM PVC
Apply WRED group to
an ATM PVC
random-detect [attach random-detect-group]
random-detect [attach random-detect-group]
Router(config-if-atm-vc)#
Enables WRED on a PVC using the selected WRED
profile
Default WRED parameters are used if the group
name is omitted or refers to non-existent group
Default: no WRED is used on the ATM PVC

The last step in the configuration of per-VC WRED is to attach a random-detect-
group to a virtual circuit. The random-detect command is used in the VC
configuration mode to enable WRED. If no random-detect-group is specified
WRED will use the default WRED profiles.

show queueing random-detect [interface intf [vc vpi vci ]]
show queueing random-detect [interface intf [vc vpi vci ]]
Router#
Displays WRED parameters for an ATM
(sub)interface or for individual VC
Monitoring and Troubleshooting
Per-VC WRED
Per-VC WRED
show queueing interface interface [vc vpi vci]
show queueing interface interface [vc vpi vci]
Router#
Displays interface queues or individual per-VC
queue

The show queuing random-detect command display WRED parameters and
statistics for a specific interface or virtual circuit. There is only a single queue into
which packets from all IP precedences are placed after dropping has taken place.
The show queuing interface command displays per-VC queue parameters and
statistics. The Queuing strategy reported by the command lists random early
detection (RED) as the queuing mechanism. The default minimum thresholds are
spaced evenly between half and the entire maximum threshold. Thresholds are
specified in terms of packet count.
WRED Case Study WRED Case Study
WRED is applied to a ATM PVCs in a network with
the following IP precedence definitions
IP prec. Meaning
0 High-loss best-effort traffic
1 Low-loss best-effort traffic
2 Premium traffic outside of the contract
3 Premium traffic in the contract
4 Unused
5 Voice-over-IP
6 Routing protocol traffic
7 Routing protocol traffic
WRED queue length is 100 packets for PVCs with
SCR > 10 Mbps and 40 packets for slower PVCs

The case study shows a QoS design where packets are classified into three user
classes:
n Best-effort class
n Premium class
n Voice class
The Best-effort and Premium classes use two IP precedence values to mark
high-drop (out-of-contract) traffic and low-drop (within contract) traffic.
IP precedence values 6 and 7 are reserved for control messages (for example,
routing protocols) and should not be used for user traffic.
The design lists these two additional requirements:
n Virtual circuits faster than 10Mbps should have queues that can hold up to 100
packets
n Slower virtual circuits can store up to 40 packets in the queue
All virtual circuits should manage congestion by using WRED.

Case Study WRED Profile Case Study WRED Profile
P
a
c
k
e
t

D
i
s
c
a
r
d
P
r
o
b
a
b
i
l
i
t
y
Average
Queue Size
0.1
RSVP
1
5
1
0
2
0
2
5
3
0
3
5
3
7
Precedence 2
Precedence 0
Precedence 3
Precedence 1
VoIP
Routing

The figure illustrates the WRED parameters that should be implemented for fast
and slow virtual circuits. The minimum and maximum thresholds should reflect a
different maximum queue size for fast VCs (100 instead of 40).
High drop Best-effort and Premium packets start being dropped when the average
queue size reaches 10 or 15 respectively (25 or 37 on fast VCs). If the queue still
grows the low-drop Best-effort packets start being dropped when the queue size
reaches 20 (50 on fast VCs). High drop packets, of course, are more aggressively
dropped than low-drop packets.
Control packets, VoIP packets and packets of RSVP flows are only dropped in
extreme situations when the average queue size is close to the maximum (40 for
slow VCs and 100 for fast VCs).
Router Configuration Router Configuration
Step #1 - configure WRED profile for slow
PVCs
random-detect-group slow-wred-profile
precedence 0 10 25 10
random-detect-group slow-wred-profile

The figure shows the configuration of WRED profiles used for slow VCs.

Step #2 - configure WRED profile for fast
PVCs
random-detect-group fast-wred-profile
random-detect-group fast-wred-profile

The figure shows the configuration of WRED profiles used for fast VCs.
Note This configuration simply uses scaled thresholds to support up to 100 packets
in the queue.

Step #3 - Apply WRED profile on various
PVCs
interface ATM11/0/0
ip address 17.1.0.1 255.255.255.0
atm pvc 50 0 50 aal5snap 25000 50000 10 inarp
random-detect fast-wred-profile
!
interface ATM11/0/0.100 point-to-point
ip address 17.1.1.1 255.255.255.252
!
ip address 17.1.1.5 255.255.255.252
random-detect slow-wred-profile
interface ATM11/0/0
ip address 17.1.0.1 255.255.255.0
!
ip address 17.1.1.1 255.255.255.252
!
ip address 17.1.1.5 255.255.255.252
random-detect slow-wred-profile

The figure shows the configuration of three virtual circuits. Two are using the
WRED profile for fast VCs and the third is using the WRED profile for slow VCs.

Summary
Weighted Random Early Detection (WRED) is one of the IP QoS mechanisms
that can be applied to individual virtual circuits.
A Random Detect Group is used to configure a WRED profile that is attached to
individual VCs using the random-detect command in the VC configuration mode.
Review Questions
1. What are the benefits of per-VC WRED?
2. What are the configuration steps needed to enable per-VC WRED?
VC Bundling
Objectives
n Describe VC bundling
n Configure VC bundling
n Monitor and troubleshoot VC bundling
VC Bundling VC Bundling
VC Bundling is a solution where ATM QoS
mechanisms are used
Classes of Service are identified by IP
precedence
Each VC uses an ATM service based on the
requirements of the class
Routers automatically map packets in VCs
based on their IP precedence value
Multiple parallel VCs are needed for each IP
adjacency

VC Bundling is a solution where the task of providing differentiated quality of
service is offloaded to the ATM switches. Classes are identified by using IP
precedence values. The routers then perform classification based on IP
precedence values. Up to eight parallel virtual circuits can be used for one IP
adjacency. Appropriate ATM services are used for each IP precedence value,
depending on the QoS requirements and provisioning.
An IP precedence value or a range of IP precedence values are mapped to one
virtual circuit. Non-contiguous IP precedence ranges are not supported.

VC Bundling Case Study VC Bundling Case Study
ATM VC ATM VC type IP prec.
Control VC (routing updates) VBR 6-7
Voice CBR 5
VPN traffic VBR 4
Premium Internet traffic VBR 2-3
Best-effort Internet traffic ABR 0-1
Control (routing)
Voice
VPN traffic
Premium Internet
Best-effort Internet

The figure illustrates a case study where there are four user classes and one class
for control traffic.
Routers perform classification based on IP precedence values:
n IP precedence 6 and 7 traffic is forwarded through the Control VC
n IP precedence 5 traffic is forwarded through the Voice VC
n IP precedence 4 traffic is forwarded through the VPN VC
n IP precedence 2 and 3 traffic is forwarded through the Premium VC
n IP precedence 0 and 1 traffic is forwarded through the Best-effort VC

Control (routing)
Voice
VPN traffic
Premium Internet
VC Bundling
Routing Adjacency
VC Bundling
Routing Adjacency
Whole bundle is treated as one routing adjacency
and is covered by a single ATM map
Routing protocol packets are exchanged over
control VC as they are sent with IP precedence 6
Each VC has its own HW queue in the
router, managed with WRED

All five classes are separated in the ATM network and receive different quality of
service. Routers have to perform per-VC queuing to prevent head-of-line blocking.
All five virtual circuits, though, appear as one single point-to-point link on the IP
layer.
VC Provisioning VC Provisioning
VCs are dimensioned based on expected
load for the precedence(s) level transported
on that VC
More isolation between classes
At the expense of
less statistical multiplexing,
more complex provisioning/engineering

VC Bundling provides an efficient utilization of QoS capabilities provided by
ATM. IP classes are effectively isolated by being transported over different virtual
circuits. The drawbacks of this approach are:
n Less statistical multiplexing. One class cannot use another classs bandwidth
(unless ABR is used).
n More complex provisioning. Each IP adjacency, which normally requires one
point-to-point virtual circuit, now requires multiple virtual circuits of different
types and QoS.
As much as IP QoS is simplified to classification and marking using IP precedence,
ATM QoS is more complex because there are up to eight times more virtual
circuits to be configured.

VC Bundle Management VC Bundle Management
Integrity of each individual VC is verified with
end-to-end OAM cells
Control (routing)
Voice
VPN traffic
Premium Internet

Most Layer-2 technologies include some type of link management. Keepalive
frames are typically used as a last resort to determine if end-to-end connectivity
works. For example:
n HDLC and PPP use link-level keepalive frames to determine if the link is
operational.
n Frame Relay uses keepalive frames to determine if the link between a router
and a switch is operational. Frame Relay can also have end-to-end keepalive
messages to determine if the virtual circuit is operational.
n ATM uses two types of Operation Administration and Maintenance (OAM)
cells to determine if link-level and end-to-end connectivity works.
VC bundling is more complex since there are multiple parallel virtual circuits used
for one single IP adjacency.
The question is: what should happen if only one VC goes down?

VC Bundle Management VC Bundle Management
Control (routing)
Voice
VPN traffic
Two ways of handling loss of VC in the bundle:
The whole bundle is declared down
Traffic from the lost VC is bumped onto another VC
IP routing model does not allow the traffic for a single
precedence value to be rerouted over another path

There are two possible ways of handling lost VCs:
n All VCs are declared inactive
n The traffic for the lost VC is rerouted onto another VC within the same bundle
IP forwarding decisions are based solely on the destination address and cannot
reroute packets based on their IP precedence values.


2001, Cisco Systems, Inc. www.cisco.com Course acronym 2.0 Chapter#-38
Keep All Graphics Inside This Box
VC Bumping VC Bumping
VC bumping = possibility for a traffic
mapped to VC X to be forwarded onto
another VC Y, in case of failure of X
Traffic can be bumped based on implicit
or explicit rules
Individual VC or a group of VCs can be
protected

n VC bumping is one approach to handling lost VCs. If one of the VCs goes
down the traffic from that VC is forwarded through another VC in the same
bundle.
n Implicit bumping is the default behavior where packets are forwarded
through the first available VC of a lower IP precedence value.
n Explicit bumping requires manual configuration where the IP precedence of
a backup VC is set.

Implicit Bumping Implicit Bumping
Control (routing)
Voice
VPN traffic
Traffic from the lost VC is bumped onto the VC
carrying traffic with the next lower precedence

The figure illustrates how routers automatically reroute Premium traffic to the first
VC with a lower IP precedence value (Best-effort in the example).

Reject Bumping Reject Bumping
Problem: Control traffic shall not be bumped onto
voice VC (implicit rule)
Solution #1: Voice VC can reject bumping, bumped
traffic goes to next lower VC
Voice
VPN traffic
Premium Internet
Rejects
bumping

Some virtual circuits can be configured to reject bumped traffic.
The figure illustrates how the Voice VC rejects bumped traffic (mixing delay
sensitive, well-provisioned traffic with other types of packets is not desired and
should be prevented). Implicit bumping searches down the ladder for the first
available VC (it has to be operational and accept bumped traffic).

Voice
VPN traffic
Premium Internet
Explicit Bumping Explicit Bumping
Problem: Control traffic shall not be bumped onto
voice VC (implicit rule)
Solution #2: Specify explicitely onto which VC the
traffic will be bumped
Bump explicitely
to precedence 0

Another approach is to explicitly set the backup VC.
The Control VC in the figure was configured to use the Best-effort VC as backup.

Bundle Failure Scenarios Bundle Failure Scenarios
Problem: under default settings, the whole bundle is
declared down if the lowest-precedence VC is lost
Solution: be sure that the lowest-precedence VC is
always bumped via explicit bumping rule
Precedence 0 traffic
cannot be implicitly
bumped
Whole bundle
is lost
Control (routing)
VPN traffic
Premium Internet
Voice
When a bundle is declared down, no
traffic is forwarded out of the
bundle, even if some VCs are still up

In this figure the VC used for IP precedence 0 does not have a lower-precedence
VC to be used as backup. It is recommended to use explicit bumping for this VC.

Protected VC Protected VC
Problem: voice traffic shall not be bumped onto data
VC
Solution: failure of protected VC brings down the
whole bundle, IP routing will find alternate path
Voice VC is
protected VC
Whole bundle
is lost
Control (routing)
VPN traffic
Premium Internet

Some VCs have special QoS requirements that cannot be accommodated by any
other VC.
The Voice VC in the figure cannot be bumped to any other VC because the voice
quality would no longer meet the requirements. It is better to declare the entire
bundle down and let the IP routing protocol find another path where guarantees
can be met. Classes that under no circumstances should be mixed with other
classes should reject bumped traffic (if a higher-precedence VC fails) and be
protected (if their VC fails).

Protected group Protected group
Problem: if most of the VCs are lost, it does not make
sense to bump traffic onto low-volume VCs
Solution: failure of all VCs in a protected group will
bring down the bundle
Whole bundle
is lost
Control (routing)
Voice
All VCs in the
protected group
are lost

One group of VCs can be protected in a way where the bundle is declared down
but only if all of the VCs in the group fail.

VC Bumping Final Details VC Bumping Final Details
If the VC which carries the bumped traffic
fails, the traffic will follow the bumping rules
specified for that VC
Traffic is restored to the original VC when
that VC becomes operational

To summarize bumping:
n Default implicit bumping is used to find the first-lower precedence VC that
accepts bumped traffic and is operational.
n Explicit bumping can be used to select the backup VC. If the backup VC is
down, that VCs rules are used to find the backup of the backup VC.
n Individual VCs can be configured to reject bumped traffic. Bumped traffic will
skip such VCs.
n An individual VC can be protected. If a protected VC fails the entire bundle is
declared down.
n A collection of VCs can belong to a protected group. If all VCs in the
protected group fail the entire bundle is declared down.
Traffic is restored to the original VC the moment it becomes operational.

Configuring VC Bundling Configuring VC Bundling
Configuration steps:
Configure ATM interface
Configure VC bundle
Configure individual VC in the bundle
Optionally use VC-class object as VC parameter
template

The following configuration steps are needed to enable VC Bundling:
Step 1 Configure interface-wide parameters on an ATM interface
Step 2 Create a VC bundle
Step 3 Create up to eight VCs as members of the bundle
Step 4 Optionally, use the VC-class object as a template for bundle or VC configuration

VC Bundle Parameters VC Bundle Parameters
Parameters configurable on the VC bundle or
vc-class applied to the bundle
Layer-3 ATM maps
Encapsulation
Broadcast propagation
ATM Inverse ARP
OAM management
Global bumping rules

The figure lists the parameters that can be set on a bundle or a vc-class template.
Individual member VCs inherits the parameters if they are not overridden in the
VC configuration.

Individual VC Parameters Individual VC Parameters
Parameters configurable on individual VC in
the bundle (or vc-class)
IP precedence mapping
VC protection mode
VC bumping rules
ATM VC mode and ATM QoS parameters
WRED group

Individual VC parameters can be inherited from a vc-class configured on the
bundle, the bundle, or a vc-class configured on the VC. Parameters configured on
the VC override all inherited parameters.

Configuring Bundle-wide
VC Class
Configuring Bundle-wide
VC Class
class-vc vc-class-name
oam-bundle [manage] [frequency]
bump {implicit | explicit precedence-level | traffic}
encapsulation atm-encap
protocol atm-map-parameters
[no] broadcast
inarp timeout
[no] broadcast
inarp timeout
Router(config)#
Configures all parameters that can be specified on
an ATM VC bundle in a VC class

Use the class-vc global configuration command to create a template used to
configure common parameters on ATM interfaces, bundles or individual virtual
circuits.
VC classes can contain ATM specific configuration commands as well as
commands used for VC Bundle management.

Configuring ATM VC Bundle Configuring ATM VC Bundle
bundle bundle-name
class vc- cl ass- name
[no] broadcast
inarp timeout
bundle bundle-name
[no] broadcast
inarp timeout
Router(config-if)#
Configures ATM VC bundle
If a vc-class is applied to the bundle, the bundle
inherits parameters specified in the vc-class
Individual parameters specified in the vc-class can
be overwritten by bundle configuration commands

Use the bundle interface command to enter the bundle configuration mode.
Parameters specific to this bundle should be configured on the bundle. Parameters
that are common to multiple bundles should be configured in a template (VC class)
and attached to the bundle using the class-bundle command.
The command used to attach VC class templates differs, depending on which
configuration mode is used:
n The class-int interface command is used to attach a VC class to an interface
n The class-bundle command is used to attach a VC class to a bundle
n The class-vc command is used to attach a VC class to a virtual circuit

oam-bundle [manage] [frequency] oam-bundle [manage] [frequency]
Router(config-atm-vc)#
Enables VC management with end-to-end OAM cells
Cells are sent but the bundle is not managed if the manage
keyword is omitted
The frequency parameter specifies the cell generation rate in
seconds
Configuring OAM Management in
the Bundle
Configuring OAM Management in
the Bundle
oam retry up-count down-count retry-frequency oam retry up-count down-count retry-frequency
Specifies the OAM management-related thresholds
The up-count and down-count parameters specify the number of
consecutive cells that have to be received (or lost) before the
VC is declared up or down
The frequency parameter specifies the cell send frequency
during VC state change verification

To enable end-to-end F5 Operation, Administration and Maintenance (OAM)
loopback cell generation and OAM management for a virtual circuit (VC) class
that can be applied to a VC bundle, use the oam-bundle vc-class configuration
command.
To enable end-to-end F5 OAM loopback cell generation and OAM management
for all VC members of a bundle, use the oam-bundle bundle configuration
command.
If the manage keyword is omitted, loopback cells are sent but the bundle is not
managed.
The frequency parameter specifies the number of seconds between sending OAM
loopback cells. Values range from 0 to 600 seconds.
To configure parameters related to OAM management for an ATM PVC, SVC, or
VC class, use the oam retry command in the appropriate command mode.
The up-count parameter specifies the number of consecutive end-to-end F5 OAM
loopback cell responses that must be received in order to change a PVC
connection state to up.
The down-count parameter specifies the number of consecutive end-to-end F5
OAM loopback cell responses that are not received in order to change a PVC
state to down.
The retry-frequency parameter specifies the frequency (in seconds) that the
end-to-end F5 OAM loopback cells are transmitted when a change in the
UP/DOWN state of a PVC is being verified. For example, if a PVC is up and a
loopback cell response is not received after the frequency (in seconds) specified
using the oam-pvc command, then loopback cells are sent at the retry-frequency
to verify whether or not the PVC is down.
bump implicit
bump implicit
Configures implicit bumping rules for the bundle or
individual VC in the bundle
If the VC fails, the traffic is bumped to the VC
carrying lower-precedence traffic
Configuring Traffic Bumping Configuring Traffic Bumping
bump explicit precedence bump explicit precedence
Configures explicit bumping rules for the bundle or
individual VC in the bundle
If the VC fails, the traffic is bumped to the VC
currently carrying packets with specified IP
precedence

The bump implicit command, depending on the mode, applies implicit bumping
rules, which is also the default, to a single VC bundle member (bundle-vc mode) or
all VCs in the bundle (bundle mode). The (default) implicit bumping rule stipulates
that bumped traffic is to be carried by a VC with a lower precedence.
The bump implicit command specifies the IP precedence level to which traffic on
a VC (bundle-vc mode) will be bumped when the VC goes down. It specifies a
single number as the value of the precedence-level argument.

no bump traffic
no bump traffic
Prevents the VC (or all VCs in a bundle) from
accepting bumped traffic
Configuring Traffic Bumping Configuring Traffic Bumping
bump traffic bump traffic
Allows the VC (or all VCs in a bundle) to accept
bumped traffic

Use the no bump traffic command to reject bumped traffic on the configured VC.
Use the bump traffic command to restore the default behavior.

Configuring VC-wide VC Class Configuring VC-wide VC Class
precedence [other | range ]
protect {group | vc }
ubr | ubr+ | vbr-nrt atm-qos-parameters
random-detect [attach group-name]
protect {group | vc }
Router(config)#
Configures all parameters that can be specified on
an ATM VC within the bundle in a VC class

Use the class-vc global configuration command to create a VC template.
Interface, VC or bundle specific parameters can be set within the VC class.

Configuring ATM VC in a Bundle Configuring ATM VC in a Bundle
bundle bundle-name
pvc name [vpi/]vci
protect {group | vc}
bundle bundle-name
pvc name [vpi/]vci
protect {group | vc}
Router(config-if)#
Configures individual VC in an ATM VC bundle
If a vc-class is applied to the VC, the VC inherits parameters
specified in the vc-class
Individual parameters specified in the vc-class can be
overwritten by bundle configuration commands
Unspecified VC parameters are inherited from the bundle or
from the ATM interface

Use the bundle command in the ATM interface or subinterface configuration
mode.
From within the bundle configuration mode the characteristics and attributes of the
bundle and its members, such as the encapsulation type for all virtual circuits
(VCs) in the bundle, the bundle management parameters and the service type, can
be configured. Attributes and parameters that are configured in the bundle
configuration mode are applied to all virtual circuit (VC) members of the bundle.
VCs in a VC bundle are subject to the following configuration inheritance
guidelines (listed in order of next highest precedence):
1. VC configuration in bundle-vc mode
2. Bundle configuration in bundle mode
3. Subinterface configuration in subinterface mode

Map IP Precedence to an
ATM VC
Map IP Precedence to an
ATM VC
precedence [other | range ] precedence [other | range ]
Maps packets with specified range of IP precedence
into the configured ATM VC
All the unmapped IP precedence values are mapped
to the VC specifying other
Default: VC accepts all unspecified IP traffic

Assignment of precedence levels to VC bundle members provides the ability to
create a differentiated service, because the IP Precedence levels can be
distributed over the different VC bundle members. A single precedence level, or a
range of levels to each discrete VC in the bundle, can be mapped, thereby enabling
VCs in the bundle to carry packets marked with different precedence levels.
Alternatively, a VC can be configured with the precedence other command to
indicate that it can carry traffic marked with precedence levels not specifically
configured for it. Only one VC in the bundle can be configured with the
precedence other command to carry all precedence levels not specified. This
VC is considered the default.
VC Protection VC Protection
protect { group | vc } protect { group | vc }
Configures the VC to be part of protected group or
to be individually protected
Bundle is declared down if all VCs in the protected
group are lost or if any individually-protected VC is
lost
Only one protected group can be configured in a
bundle
Default: VC is not protected

Use the protect vc command to protect a virtual circuit. Use the protect group
command to make the VC a member of the protected group.
When a protected VC goes down, it takes the bundle down. When all members of
a protected group go down, the bundle goes down.

VC Inheritance Rules VC Inheritance Rules
VC parameters are inherited in the following
order
Parameters specified on individual VC
Parameters in the VC class applied to the
individual VC
Parameters specified on the bundle to which the
VC belongs
Parameters specified in the VC class applied to
the bundle
Parameters specified on an interface or
subinterface

The figure shows the inheritance rules for parameters set on interfaces, bundles,
VC classes or individual VCs. The parameters configured on individual VCs
override all inherited values.

ATM VC Bundle
Case Study
ATM VC Bundle
Case Study
IP traffic is transported across an international ATM
PVC with the following IP precedence values
Precedence Meaning
0-1 Best-effort Internet traffic
2-3 Premium Internet traffic
4 VPN traffic
5 VoIP traffic
6,7 Routing protocols
Voice traffic, VPN traffic and Premium Internet traffic
shall be transported across dedicated PVCs for
easier provisioning

The figure illustrates a case study where there are four user classes and one class
for control traffic.
Routers perform classification based on IP precedence values:
n IP precedence 6 and 7 traffic is forwarded through the Control VC
n IP precedence 5 traffic is forwarded through the Voice VC
n IP precedence 4 traffic is forwarded through the VPN VC
n IP precedence 2 and 3 traffic is forwarded through the Premium VC
n IP precedence 0 and 1 traffic is forwarded through the Best-effort VC

Case Study Step 1: Bundle
Design
Case Study Step 1: Bundle
Design
Precedence 5 traffic (VoIP) is transported over a
separate VC, no bumping is possible
Precedence 2-3 traffic (Premium Internet) is
transported over a separate VC, can be bumped onto
the best-effort VC
Precedence 4 traffic (VPN) is transported over a
separate VC, can be bumped onto best -effort VC
Control traffic is transported over a separate VC, can
be bumped onto the best-effort VC
Best-effort VC can be bumped onto Premium Internet
VC
WRED has to be deployed on all VCs to prevent
bumped best-effort traffic from congesting the VC

Per-VC WRED is the only IP QoS mechanism that will be used on the routers to
manage congestion.

Case study step 2: configuring VC classes
vc-class best_effort vc-class vpn
precedence other precedence 4
bump explicitly 2 bump explicitly 0
protect group protect group
! !
vc-class premium vc-class voip
precedence 2-3 precedence 5
bump implicitly no bump traffic
protect group protect vc
! !
vc-class bundle vc-class control
encapsulation aal5snap precedence 6-7
broadcast bump explicitly 0
protocol ip inarp protect group
oam-bundle manage 3
vc-class best_effort vc-class vpn
precedence other precedence 4
bump explicitly 2 bump explicitly 0
protect group protect group
! !
vc-class premium vc-class voip
precedence 2-3 precedence 5
bump implicitly no bump traffic
protect group protect vc
! !
vc-class bundle vc-class control
encapsulation aal5snap precedence 6-7
broadcast bump explicitly 0
protocol ip inarp protect group
oam-bundle manage 3

The first part of the implementation shows the templates (VC classes) that will be
used for individual virtual circuits (classes) and one for the bundle.

Case study step 3: configuring the WRED
profile Guaranteed_BW PVC
random-detect-group guaranteed_bw_pvc
random-detect-group guaranteed_bw_pvc

A random-detect-group is created for the virtual circuits that need non-default
WRED profiles.

Case study step 4: configure the bundle and individual PVC
interface ATM 5/1/0.22 point-to-point
ip address 216.23.45.5 255.255.255.252
bundle SanFrancisco
class bundle
pvc-bundle SF-control 26
class control
vbr-nrt 1000 1000
pvc-bundle SF-voip 25
class voip
vbr 2000 2000
pvc-bundle SF-vpn 24
class vpn
vbr-nrt 4000 4000
pvc-bundle SF-guaranteed 22
class guaranteed_bw
random-detect attach guaranteed_bw_pvc
vbr-nrt 8000 8000
pvc-bundle SF-best-effort 23
class best_effort
random-detect
interface ATM 5/1/0.22 point-to-point
ip address 216.23.45.5 255.255.255.252
bundle SanFrancisco
class bundle
pvc-bundle SF-control 26
class control
vbr-nrt 1000 1000
pvc-bundle SF-voip 25
class voip
vbr 2000 2000
pvc-bundle SF-vpn 24
class vpn
vbr-nrt 4000 4000
pvc-bundle SF-guaranteed 22
class guaranteed_bw
random-detect attach guaranteed_bw_pvc
vbr-nrt 8000 8000
pvc-bundle SF-best-effort 23
class best_effort
random-detect

The figure shows the configuration of the bundle with five individual VCs. Each
VC is configured with the PVC type and parameters. All other configuration
parameters are inherited from the VC classes attached to individual VCs and the
VC class attached to the bundle.

Summary
VC Bundling is a solution where the task of providing differentiated quality of
service is offloaded to ATM switches. Classes are identified by using IP
precedence values, then the routers perform classification based on IP
precedence values. Up to eight parallel virtual circuits can be used for one IP
adjacency. Appropriate ATM services are used for each IP precedence value,
depending on the QoS requirements and provisioning.
A range of IP precedence values or a single IP precedence value are mapped to
one virtual circuit. Non-contiguous IP precedence ranges are not supported.
Review Questions
1. How does VC Bundling classify IP packets?
2. Which QoS mechanisms are used when using VC Bundling?
3. How many parallel VCs can be used for one IP adjacency?
4. How many IP precedence values can map into one VC?
Per-VC CB-WFQ
Objectives
n Describe per-VC CB-WFQ
n Configure per-VC CB-WFQ
n Monitor and troubleshoot per-VC CB-WFQ
Per-VC CB-WFQ Per-VC CB-WFQ
Class-based Weighted Fair Queuing (CB-WFQ) can
be used on ATM interfaces
QoS service policies can be applied to:
An interface
A subinterface
An individual virtual circuit
Supported service policies are:
CB-WFQ including WRED
CB-LLQ
CB-Marking including setting of ATM CLP bit
CB-Shaping
CB-Policing including setting of ATM CLP bit

Per-VC queuing can be supplemented by using the Modular QoS CLI (MQC).
ATM PVCs can be combined with any QoS mechanism available with the MQC:
n CB-WFQ for bandwidth management
n CB-LLQ for delay management
n CB-Marking
n CB-Shaping
n CB-Policing
CB-Marking and CB-Policing also include the capability to mark cells with the Cell
Loss Priority (CLP) bit.

Per-interface CB-WFQ Per-interface CB-WFQ
CB-WFQ can be applied to an entire interface
Interface
ATM1/0/0
Subinterface
ATM1/0/0.1
Subinterface
ATM1/0/0.2
PVC 0/50
PVC 0/51
PVC 0/52
PVC 0/53
PVC 0/54
CB-WFQ
class-map HTTP
match http
!
policy-map LimitHTTP
class HTTP
police 256000 conform transmit exceed set-clp-transmit
!
interface ATM5/0/0
service-policy output LimitHTTP
!
class-map HTTP
match http
!
policy-map LimitHTTP
class HTTP
police 256000 conform transmit exceed set-clp-transmit
!
interface ATM5/0/0
service-policy output LimitHTTP
!

The figure illustrates an ATM interface with two configured subinterfaces. The
first subinterface uses two ATM PVCs, the second subinterface uses three ATM
PVCs.
A service policy can be applied to an entire ATM interface.
Per-subinterface CB-WFQ Per-subinterface CB-WFQ
CB-WFQ can be applied to subinterfaces
Interface
ATM1/0/0
Subinterface
ATM1/0/0.1
Subinterface
ATM1/0/0.2
PVC 0/50
PVC 0/51
PVC 0/52
PVC 0/53
PVC 0/54
CB-WFQ
CB-WFQ
class-map CorporateTraffic interface ATM5/0/0.1 point-to-point
match access-group 100 service-policy output Smart
! pvc Core 0/51
policy-map Smart vbr-nrt 10000 2000
class CorporateTraffic !
bandwidth 10000
class class-default
set atm-clp
!
class-map CorporateTraffic interface ATM5/0/0.1 point-to-point
match access-group 100 service-policy output Smart
! pvc Core 0/51
policy-map Smart vbr-nrt 10000 2000
class CorporateTraffic !
bandwidth 10000
class class-default
set atm-clp
!

A service policy can also be applied to individual ATM subinterfaces.

Per-interface CB-WFQ Per-interface CB-WFQ
CB-WFQ can be applied to an individual
virtual circuit
Interface
ATM1/0/0
Subinterface
ATM1/0/0.1
Subinterface
ATM1/0/0.2
PVC 0/50
PVC 0/51
PVC 0/52
PVC 0/53
PVC 0/54
CB-WFQ
CB-WFQ
CB-WFQ
CB-WFQ
CB-WFQ

The highest QoS granularity is achieved by attaching service policies to individual
virtual circuits.

Per-interface CB-WFQ
Configuration Example
class-map MatchCorporate
match access-group 100
!
policy-map MARK
class MatchCorporate
police 2000000 conform-action transmit exceed-action set-clp-transmit
!
interface ATM5/0/0
ip address 10.1.1.1 255.255.255.0
service-policy output MARK
pvc 0/50
vbr-nrt 500 400 1000
inarp 1
broadcast
!
access-list 100 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
!
policy-map MARK
!
interface ATM5/0/0
ip address 10.1.1.1 255.255.255.0
pvc 0/50
vbr-nrt 500 400 1000
inarp 1
broadcast
!

The example shows how a service policy is used in simple ATM configurations
where the main interface is used to establish IP adjacency. The service policy is
attached directly to the interface.
Per-VC CB-WFQ
Per-VC CB-WFQ
!
policy-map MARK
!
interface ATM5/0/0
no ip address
!
ip address 10.1.1.1 255.255.255.0
pvc 0/50
vbr-nrt 500 400 1000
inarp 1
broadcast
!
!
policy-map MARK
!
interface ATM5/0/0
no ip address
!
ip address 10.1.1.1 255.255.255.0
pvc 0/50
vbr-nrt 500 400 1000
inarp 1
broadcast
!

The more common alternative to configuring ATM is to use subinterfaces. A
service policy can be attached to the subinterface or a virtual circuit.

show policy-map interface ATM-interface show policy-map interface ATM-interface
Router#
Displays the Service Policy parameters and statistics
for the selected interface or subinterface
Router#show policy interface atm 5/0/0.1
ATM5/0/0.1
Service-policy output: Smart (1755)
Class-map: CorporateTraffic (match-all) (1757/42)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 100 (1761)
queue size 0, queue limit 2500
packets output 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
Bandwidth: kbps 10000, weight 29
...
Router#show policy interface atm 5/0/0.1
ATM5/0/0.1
Service-policy output: Smart (1755)
Class-map: CorporateTraffic (match-all) (1757/42)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 100 (1761)
queue size 0, queue limit 2500
packets output 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
Bandwidth: kbps 10000, weight 29
...

Use the show policy-map interface command to display the parameters and
statistics of input and output policies attached to interfaces.
This command displays information about all classification options and the attached
QoS mechanisms.

Per-VC CB-WFQ
Per-VC CB-WFQ
show queueing interface ATM-interface [vc [VPI/]VCI] show queueing interface ATM-interface [vc [VPI/]VCI]
Router#
Displays CB-WFQ parameters and statistics for the
selected interface, subinterface or VC
Router#show queueing interface atm5/0
Interface ATM5/0 VC 0/5
Queueing strategy: fifo
Output queue 0/40, 0 drops per VC
Queueing strategy: weighted fair
Total output drops per VC: 0
Output queue: 0/512/64/0 (size/max total/threshold/drops)
Conversations 0/1/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 225 kilobits/sec
Router#show queueing interface atm5/0
Queueing strategy: weighted fair
Total output drops per VC: 0
Output queue: 0/512/64/0 (size/max total/threshold/drops)
Conversations 0/1/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 225 kilobits/sec

Use the show queueing exec command to list all, or selected, configured queuing
strategies.

Summary
Per-VC CB-WFQ allows the usage of the same QoS mechanisms as any other
technology using single physical interfaces. The same configuration steps are
needed to create a service policy. The policy can then be attached to an interface,
subinterface or an individual VC.
CB-Policing and CB-Marking also support the setting of the ATM CLP bit.
Review Questions
Answer the following question:
1. Where can CB-WFQ be attached on ATM interfaces?
RSVP to SVC Mapping
Objectives
n Configure RSVP to SVC mapping
n Monitor and troubleshoot RSVP to SVC mapping
RSVP to SVC Mapping RSVP to SVC Mapping
RSVP-enabled flows have bandwidth and
delay requirements
Pass-through RSVP could affect the quality
of service in case an ATM interface or PVC is
congested
RSVP-enabled flows can get their own VCs
and queues to prevent congestion affecting
these flows
RSVP reservations are mapped to SVCs

The RSVP-ATM QoS Interworking feature provides support for Controlled Load
Service using RSVP over an ATM core network. This feature requires the ability
to signal for establishment of switched virtual circuits (SVCs) across the ATM
cloud in response to RSVP reservation request messages. To meet this
requirement, RSVP over ATM supports mapping of RSVP sessions to ATM
SVCs.
RSVP to SVC Mapping RSVP to SVC Mapping
RSVP RSVP
SVC
RSVP triggers SVC creation
ATM SVC parameters are calculated from the
parameters in the RSVP reservation request

Traditionally, RSVP has been coupled with WFQ. WFQ provides bandwidth
guarantees to RSVP and gives RSVP visibility to all packets visible to it. This
visibility allows RSVP to identify and mark packets pertinent to it.
The RSVP-ATM QoS Interworking feature provides the capability to decouple
RSVP from WFQ, and instead associate it with ATM SVCs to handle reservation
request messages (and provide bandwidth guarantees), and NetFlow to make
packets visible to RSVP.
ATM SVC Parameters ATM SVC Parameters
SCR = BW
RSVP
. (53/48) . (MPS + DLE + UCO)/MPS
Data Link Encapsulation
overhead
AAL5SNAP has 5 bytes
of overhead
Minimum IP packet
size
Unused Cell
Overhead
Cell
overhead
Bandwidth requested
by RSVP
Sustained
Cell Rate
Peak Cell Rate uses the same formula except it is based on the
line rate or the configured peak cell rate
Voice Data
IP
Header
AAL5SNAP
Header
ATM
Header
ATM
Header
Voice Data Unused
Cell 1 Cell 2
5 5 43 5 48

To ensure correspondence between RSVP and ATM SVC values, the software
algorithmically maps the rate and burst size parameters in the RSVP service
parameters to the ATM Sustained Cell Rate (SCR) and Maximum Burst Size
(MBS). For the Peak Cell Rate (PCR), it uses the value that is configured or it
defaults to the line rate.
The figure illustrates the formula used to calculate the ATM service parameters
from the RSVP service parameters. RSVP does not include the Layer-2 overhead,
which is difficult to calculate for ATM. Layer-3 packets are first framed
(AAL5SNAP header is prepended) and then segmented in 48-byte cells. Each cell
has an additional 5 bytes of overhead.

RSVP to SVC Mapping
Optional QoS
RSVP to SVC Mapping
Optional QoS
RSVP can mark conforming and exceeding
packets with different IP precedence or ToS
values
Per-VC WRED can be used for differentiated
dropping

In addition to RSVP mapping into SVCs, individual virtual circuits can use IP
precedence or ToS marking and WRED for congestion management.

Configuring
RSVP to SVC Mapping
Configuring
RSVP to SVC Mapping
The following configuration steps are needed
to enable RSVP to SVC mapping:
Enable RSVP
Enable SVC creation
Optionally enable RSVP-based marking and WRED
Verify and monitor RSVP/ATM

The RSVP-ATM QoS Interworking feature allows the following tasks to be
performed:
n Enable RSVP by specifying the total amount of bandwidth that can be
reserved by RSVP sessions and a maximum amount of bandwidth one session
can reserve.
n Configure an interface or subinterface to dynamically create SVCs in response
to RSVP reservation request messages. To ensure defined QoS, these SVCs
are established having QoS profiles consistent with the mapped RSVP flow
specifications.
n Optionally, attach distributed Weighted Random Early Detection (dWRED)
group definitions to the Enhanced ATM port adapter (PA-A3) interface to
support the per-VC dWRED drop policy. Use of per-VC dWRED ensures
that, if packets must be dropped, then best-effort packets are dropped first and
not those that conform to the appropriate QoS determined by the token bucket
of RSVP.
n Optionally, configure the IP Precedence and ToS values to be used for packets
that conform to or exceed QoS profiles. As part of its input processing, RSVP
uses the values specified to set the ToS and IP Precedence bits on incoming
packets. If per-VC DWRED is configured, it then uses the ToS and IP
Precedence bit settings on the output interface of the same router in
determining which packets to drop. Also, interfaces on downstream routers
use these settings in processing packets.

Enabling RSVP Enabling RSVP
ip rsvp bandwidth reservable-bw max-flow-bw ip rsvp bandwidth reservable-bw max-flow-bw
Router(config-if)#
Enables RSVP reservation on an interface or
subinterface
The reservable-bw parameters specifies the total
maximum amount of bandwidth that can be reserved
by RSVP flows
The max-flow-bw parameter specifies the maximum
amount of bandwidth a single flow can reserve

The ip rsvp bandwidth interface command is used to enable RSVP on an
interface. The interface and per-flow maximum reservable bandwidth limits have
to be configured.
Note RSVP cannot reserve more than 75% of the default or configured interface
bandwidth.
Enabling Creation of SVCs Enabling Creation of SVCs
ip rsvp svc-required ip rsvp svc-required
Router(config-if)#
Enables creation of SVC for RSVP reservation
ATM QoS parameters are determined by using the
parameters in the RSVP request
ip rsvp atm-peak-rate-limit limit
ip rsvp atm-peak-rate-limit limit
Router(config-if)#
Sets the peak cell rate for all new SVC
Uses the line rate as the default

Use the ip rsvp svc-required interface configuration command to enable the
creation of a Switched Virtual Circuit (SVC) to service any new Resource
Reservation Protocol (RSVP) reservation made on the ATM interface or
subinterface.
Use the ip rsvp atm-peak-rate-limit interface configuration command to set a
limit on the Peak Cell Rate (PCR) of reservations for all newly created Resource
Reservation Protocol (RSVP) switched virtual circuits (SVCs) established on the
ATM interface or any of its subinterfaces. The PCR, if it is not configured,
defaults to the line rate.

RSVP-based Marking and WRED RSVP-based Marking and WRED
ip rsvp precedence {conform | exceed} precedence ip rsvp precedence {conform | exceed} precedence
Router(config-if)#
Packets conforming to the reserved bandwidth are marked with
conform precedence
Packets exceeding the reserved bandwidth are marked with
exceed precedence
NetFlow has to be enabled
random-detect attach random-detect-group
random-detect attach random-detect-group
Router(config-if)#
Enables per-VC WRED
Uses the WRED profiles specified in the WRED group random-
detect-group
CEF switching is required

Packets in an RSVP reserved path are divided into two classes: those that conform
to the reservation service parameters and those that correspond to a reservation
but exceed, or are outside, the reservation service parameters.
The ip rsvp precedence interface command allows the IP Precedence values to
be set to be applied to packets belonging to these two classes. The IP Precedence
value for at least one class of traffic must be set when this command is used. A
single instance of the command can be used to specify values for both classes, in
which case the conform and exceed keywords can be specified in either order.
As part of its input processing, RSVP uses the ip rsvp precedence command to
set the IP Precedence bits on conforming and nonconforming packets. If per-VC
dWRED is configured, the system uses the IP Precedence and ToS bit settings on
the output interface in its packet drop process. The IP Precedence setting of a
packet can also be used by interfaces on downstream routers.
Execution of the ip rsvp precedence command causes IP Precedence values for
all preexisting reservations on the interface to be modified.
RSVP receives packets from the underlying forwarding mechanism. Therefore,
before the ip rsvp precedence command is used to set IP Precedence, one of
the following features is required:
n Weighted Fair Queuing (WFQ) must be enabled on the interface
n RSVP switched virtual circuits (SVCs) must be used in combination with
NetFlow

RSVP to SVC Mapping
Example
RSVP to SVC Mapping
Example
interface ATM2/1/0
ip address 10.1.1.1 255.255.255.0
ip rsvp bandwidth 10000 10000
ip rsvp svc-required
ip route-cache flow
ip rsvp precedence conform 5 exceed 0
atm pvc 1 0 5 qsaal
atm pvc 2 0 16 ilmi
atm esi-address 111111111151.00
pvc pvc12 0/51
inarp 5
broadcast
!
interface ATM2/1/0
ip address 10.1.1.1 255.255.255.0
ip rsvp bandwidth 10000 10000
ip rsvp svc-required
ip route-cache flow
ip rsvp precedence conform 5 exceed 0
atm pvc 1 0 5 qsaal
atm pvc 2 0 16 ilmi
atm esi-address 111111111151.00
pvc pvc12 0/51
inarp 5
broadcast
!

The sample configuration shows that up to 10Mbps can be reserved by RSVP
sessions. RSVP sessions trigger establishment of SVCs and marks conforming
packets with IP precedence 5.

RSVP to SVC Mapping
RSVP to SVC Mapping
show ip rsvp interface [intf] show ip rsvp interface [intf]
Router#
Displays RSVP-related interface information
Router#show ip rsvp interface
interface allocated i/f max flow max pct UDP IP UDP_IP UDP M/C
Et4/0 0M 7M 5M 0 0 0 0 0
AT5/0/0 0M 10M 1M 0 0 0 0 0
Se5/1/0 0M 192K 192K 0 0 0 0 0
Router#show ip rsvp interface
interface allocated i/f max flow max pct UDP IP UDP_IP UDP M/C
Et4/0 0M 7M 5M 0 0 0 0 0
AT5/0/0 0M 10M 1M 0 0 0 0 0
Se5/1/0 0M 192K 192K 0 0 0 0 0

Use the show ip rsvp interface command to display RSVP parameters and
statistics for all RSVP-enabled interfaces.
Field Description
interface Interface name.
allocate Current allocation budget.
i/f max Maximum allocatable bandwidth.
flow max Largest single flow allocatable on this
interface.
pct Percent of bandwidth utilized.
UDP Number of neighbors sending User Datagram
Protocol (UDP)-encapsulated RSVP.
IP Number of neighbors sending IP-encapsulated
RSVP.
UDP_IP Number of neighbors sending both UDP- and
IP-encapsulated RSVP.

Summary
RSVP flows can be provided guarantees either by using a queuing mechanism that
supports per-flow queuing (for example, WFQ of CB-WFQ) or it can use
dedicated per-flow Switched Virtual Circuits (SVCs) when entering an ATM
backbone.
Each RSVP flow triggers a generation of a SVC. The SVC inherits service
parameters from the RSVP service parameters (modified to account for Layer-2
overhead).
Review Questions
1. How does RSVP benefit from using SVCs?
2. What are the necessary configuration steps to enable RSVP-to-SVC?
Summary
After completing this module, you should be able to perform the following tasks:
n List the requirements of IP QoS in combination with ATM QoS
n Describe and configure per-VC WRED
n Describe and configure VC bundling
n Describe and configure per-VC CB-WFQ
n Monitor and troubleshoot IP QoS on ATM interfaces
Review Questions and Answers
Introduction to IP over ATM
Question: What are the main differences between IP and ATM?
IP is connectionless, ATM is connection oriented
IP applies QoS per packet, ATM per virtual circuit
IP supports a smaller number of traffic classes (IP precedence, DSCP) and does
not include any services by default
ATM supports a larger number of traffic classes but has a fixed number of
services (xBR)
Answer: Which QoS services does ATM support?
CBR, VBR, ABR and UBR
Question: How should congestion be handled when an ATM backbone is used?
Congestion should be pushed back to the ingress into the ATM network to allow
IP-based congestion management.
Answer: Why is per-VC queuing so important?
Per-VC queuing prevents head-of-line blocking and allows per-VC congestion
management.

Per-VC WRED
Question: What are the benefits of per-VC WRED?
Answer: Per-VC WRED allows differentiated congestion avoidance on per-VC
basis.
Question: What are the configuration steps needed to enable per-VC WRED?
Answer: Per-VC WRED requires the configuration of WRED profiles (random
detect groups) which are then attached to individual VCs.

VC Bundling
Question: How does VC Bundling classify IP packets?
Answer: VC Bundling classifies IP packets based on the IP precedence value.
Question: Which QoS mechanisms are used when using VC Bundling?
Answer: A QoS design can rely on the ATM QoS or supplement it by using
per-VC WRED or CB-WFQ.
Question: How many parallel VCs can be used for one IP adjacency?
Answer: Up to 8 parallel VCs can be used for one point-to-point IP adjacency.
Question: How many IP precedence values can map into one VC?
Answer: Up to 8 consecutive IP precedence values can map into one VC.

Per-VC CB-WFQ
Question: Where can CB-WFQ be attached on ATM interfaces?
Answer: CB-WFQ can be used on per-interface, per-subinterface or per-VC
basis.

RSVP to SVC Mapping
Question: How does RSVP benefit from using SVCs?
Answer: RSVP-based flows can get their QoS resources by using dedicated
SVCs with the appropriate ATM QoS parameters derived from the RSVP
requests.
Question: What are the necessary configuration steps to enable RSVP-to-SVC?
Answer: Enable RSVP throughout the network and then enable SVC creation
for RSVP flows on ATM interfaces
n

s10 - Ip Qos - Ip Over Atm

Uploaded by

Document Information

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

s10 - Ip Qos - Ip Over Atm

Uploaded by

Copyright:

Available Formats

10

You might also like