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. ATMTechnology comparison

IP vs. ATMTechnology 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 QoStraffic 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).

IP’s default best effort service can be supplemented by differentiated quality of service based on IP precedence or DSCP marking. A QoS solution using IP precedence is limited to 8 classes, 2 of which are reserved and 1 should be used for the default best-effort class. A QoS solution using DSCP scales up to 64 classes.

ATM provides a wider range of services:

n Constant Bit Rate (CBR) is useful for delay-sensitive applications such as voice. This service provides bandwidth and delay guarantees.

n Variable Bit Rate—Real Time (VBR-RT) is useful for burstier delay-sensitive applications. This service provides bandwidth and delay guarantees.

n Variable Bit Rate—Non Real Time (VBR-NRT) is useful for bursty traffic. This service provides bandwidth guarantees.

n Available Bit Rate (ABR) is useful for best-effort traffic that is allowed more bandwidth, when available or configured. This service provides bandwidth guarantees and access to extra bandwidth.

n Unspecified Bit Rate is useful for the real best effort where there are no guarantees.


IP’s 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.

ATM’s services also include various per-connection service parameters, such as:

n Sustained Cell Rate (SCR) for CBR, VBR and ABR services

n Minimum Cell Rate (MIR) for ABR

n Peak Cell Rate (PCR) for VBR, ABR and UBR services

n Maximum Burst Size (MBS)

Both IP and ATM can implement Quality of Service (QoS). The decision on which technology to use for quality of service should be based on a number of factors, such as:

n Availability of ATM

n Interaction between ATM and IP

n Scalability options of the technology

n Performance limitations

This module introduces the possibilities of combining IP QoS with ATM.



Integrating IP and ATMIntegrating IP and ATM

• Overlay model (ATM forum)– ATM VC’s are manually established between pairs

of devices– IP packets are sent across these VC’s– ATM switches are not IP aware

• Peer model (MPLS)– ATM switches are IP aware on control (but not

data) plane– ATM VC’s are established on-demand based on IP

routing tables

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 ATMIP 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 CircuitsUBR Virtual Circuits

• Solution:– Set CLP on the router based on IP information to minimize the

effect of cell drops

No congestionRouter allowed to send at full speed

Congestion

RandomCLP 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 CircuitsVBR 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 router’s virtual circuit, where it can be managed by using the QoS mechanisms available in the Cisco IOS software. CLP marking can be used for less-important packets or for those packets above the Sustained Cell Rate (SCR) to improve the chances for higher-priority packets when congestion occurs in the ATM network.

The rt-VBR service category supports time-sensitive applications, which also requires constrained delay and delay variation requirements, but which transmit at a time varying rate constrained to a PCR, SCR, and MBS define a traffic contract in terms of the worst-case source traffic pattern for which the network guarantees a specified QOS. Examples of such bursty, delay-variation-sensitive sources are voice and variable-bit-rate video.

The nrt-VBR service category supports applications that have no constraints on delay and delay variations, but which still have variable-rate, bursty traffic characteristics. This class of application expects a low Cell Loss Ratio (CLR). The traffic contract is the same as that for rt-VBR. Applications include packet data transfers, terminal sessions, and file transfers. Networks may statistically multiplex these VBR sources effectively.



CBR and ABR Virtual CircuitsCBR 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 router’s ATM interface.

The CBR service category supports real-time applications requiring a fixed amount of capacity defined by the PCR. CBR supports tightly constrained variations in delay. Example applications are voice, constant-bit-rate video, and Circuit Emulation Services (CES). Normally, networks must allocate the peak rate to these types of source.

The ABR service category works in cooperation with sources that can change their transmission rate in response to rate-based network feedback used in the context of closed-loop flow control. The aim of ABR service is to dynamically provide access to capacity currently not in use by other service categories to users who can adjust their transmission rate in response to feedback. In exchange for this cooperation by the user, the network provides a service with very low loss. Applications specify a maximum transmit-rate (PCR_ and the minimum required rate, called the Minimum Cell Rate (MCR). ABR service does not provide bounded delay variation; hence real-time applications are for ABR are LAN interconnection, high-performance file transfers, database archival, non-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 QoSmechanisms 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 QueuingPer-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 interfaceCell 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


n Describe per-VC WRED

n Configure per-VC WRED

n Monitor and troubleshoot per-VC WRED



Per-VC WREDPer-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

PerPer--VCVCWRED:WRED:

Intelligent DiscardIntelligent Discard

Threshold Exceeded

VC1

VC2

VC3

No discardNo discardon PAon PA

Traffic Traffic ShapingShaping

PerPer--VCVCQueuesQueues

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 WREDConfiguring 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 namerandom-detect-group nameRouter(config)#

• Creates a WRED template

Create and configure RED-groupCreate and configure RED-group

exponential-weighting-constant expexponential-weighting-constant expRouter(cfg-red-group)#

• Defines WRED weighting constant• Default: 9

precedence IP-prec min-threshold max-threshold prob-denominatorprecedence IP-prec min-threshold max-threshold prob-denominatorRouter(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 threshold—When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold.

n Maximum threshold—When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.

n Mark probability denominator—This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.

WRED does not calculate the drop probability using the current queue length, but instead uses the average queue length. The average queue length is constantly recalculated, using two terms:

n The previously calculated average queue size

n The current queue size


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

Monitoring and Troubleshooting 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 StudyWRED Case Study

• WRED is applied to a ATM PVCs in a network with the following IP precedence definitionsIP prec. Meaning

0 High-loss best-effort traffic1 Low-loss best-effort traffic2 Premium traffic outside of the contract3 Premium traffic in the contract4 Unused5 Voice-over-IP6 Routing protocol traffic7 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 ProfileCase Study WRED Profile

Pac

ket D

isca

rdP

roba

bilit

y

AverageQueue Size

0.1

RSVP

15

10

20

25

30

35

37

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 ConfigurationRouter Configuration

• Step #1 - configure WRED profile for slow PVCs

random-detect-group slow-wred-profileprecedence 0 10 25 10precedence 1 20 40 10precedence 2 15 25 10precedence 3 25 40 10precedence 4 1 10 10precedence 5 35 40 10precedence 6 30 40 10precedence 7 30 40 10

random-detect-group slow-wred-profileprecedence 0 10 25 10precedence 1 20 40 10precedence 2 15 25 10precedence 3 25 40 10precedence 4 1 10 10precedence 5 35 40 10precedence 6 30 40 10precedence 7 30 40 10

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-profileprecedence 0 25 62 10precedence 1 50 100 10precedence 2 37 62 10precedence 3 62 100 10precedence 5 87 100 10precedence 4 1 10 10precedence 6 75 100 10precedence 7 75 100 10

random-detect-group fast-wred-profileprecedence 0 25 62 10precedence 1 50 100 10precedence 2 37 62 10precedence 3 62 100 10precedence 5 87 100 10precedence 4 1 10 10precedence 6 75 100 10precedence 7 75 100 10

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/0ip address 17.1.0.1 255.255.255.0atm pvc 50 0 50 aal5snap 25000 50000 10 inarp

random-detect fast-wred-profile!interface ATM11/0/0.100 point-to-pointip address 17.1.1.1 255.255.255.252atm pvc 100 0 100 aal5snap 17000 34000 10 inarp


random-detect slow-wred-profile

interface ATM11/0/0ip address 17.1.0.1 255.255.255.0atm pvc 50 0 50 aal5snap 25000 50000 10 inarp



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.


1. What are the benefits of per-VC WRED?

2. What are the configuration steps needed to enable per-VC WRED?


VC Bundling


n Describe VC bundling

n Configure VC bundling

n Monitor and troubleshoot VC bundling



VC BundlingVC Bundling

• VC Bundling is a solution where ATM QoSmechanisms 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 StudyVC Bundling Case Study

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

Control (routing)Voice

VPN trafficPremium 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 trafficPremium 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 ProvisioningVC 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 class’s bandwidth (unless ABR is used).

n More complex provisioning. Each IP adjacency, which normally requires one point-to-point virtual circuit, now requires multiple virtual circuits of different types and QoS.

As much as IP QoS is simplified to classification and marking using IP precedence, ATM QoS is more complex because there are up to eight times more virtual circuits to be configured.



VC Bundle ManagementVC 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 ManagementVC 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 BumpingVC 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 implicitor 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 BumpingImplicit 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 BumpingReject 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


Rejectsbumping

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 BumpingExplicit 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 explicitelyto 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 ScenariosBundle 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 trafficcannot be implicitly

bumped

Whole bundleis 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 VCProtected 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 isprotected VC

Whole bundleis 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 groupProtected group

• Problem: if most of the VC’s are lost, it does not make sense to bump traffic onto low-volume VC’s

• Solution: failure of all VC’s in a protected group will bring down the bundle

Whole bundleis lost

Control (routing)

Voice

All VCs in theprotected 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 DetailsVC 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 VC’s rules are used to find the backup of the backup VC.

n Individual VCs can be configured to reject bumped traffic. Bumped traffic will skip such VCs.

n An individual VC can be protected. If a protected VC fails the entire bundle is declared down.

n A collection of VCs can belong to a protected group. If all VCs in the protected group fail the entire bundle is declared down.

Traffic is restored to the original VC the moment it becomes operational.



Configuring VC BundlingConfiguring 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 ParametersVC 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 ParametersIndividual 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-nameoam-bundle [manage] [frequency]bump {implicit | explicit precedence-level | traffic}encapsulation atm-encapprotocol atm-map-parameters …[no] broadcastinarp timeout

class-vc vc-class-nameoam-bundle [manage] [frequency]bump {implicit | explicit precedence-level | traffic}encapsulation atm-encapprotocol atm-map-parameters …[no] broadcastinarp 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 BundleConfiguring ATM VC Bundle

bundle bundle-nameclass vc-class-nameoam-bundle [manage] [frequency]bump {implicit | explicit precedence-level | traffic}encapsulation atm-encapprotocol atm-map-parameters …[no] broadcastinarp timeout

bundle bundle-nameclass vc-class-nameoam-bundle [manage] [frequency]bump {implicit | explicit precedence-level | traffic}encapsulation atm-encapprotocol atm-map-parameters …[no] broadcastinarp 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-frequencyoam retry up-count down-count retry-frequencyRouter(config-atm-vc)#

• 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 implicitbump implicitRouter(config-atm-vc)#

• 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 BumpingConfiguring Traffic Bumping

bump explicit precedencebump explicit precedenceRouter(config-atm-vc)#

• 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 trafficno bump trafficRouter(config-atm-vc)#

• Prevents the VC (or all VCs in a bundle) from accepting bumped traffic

Configuring Traffic BumpingConfiguring Traffic Bumping

bump trafficbump trafficRouter(config-atm-vc)#

• 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 ClassConfiguring VC-wide VC Class

class-vc vc-class-nameprecedence [other | range ]bump {implicit | explicit precedence-level | traffic}protect {group | vc }ubr | ubr+ | vbr-nrt atm-qos-parametersrandom-detect [attach group-name]

class-vc vc-class-nameprecedence [other | range ]bump {implicit | explicit precedence-level | traffic}protect {group | vc }ubr | ubr+ | vbr-nrt atm-qos-parametersrandom-detect [attach group-name]

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 BundleConfiguring ATM VC in a Bundle

bundle bundle-namepvc name [vpi/]vci

class vc-class-nameprecedence [other | range ]bump {implicit | explicit precedence-level | traffic}protect {group | vc}ubr | ubr+ | vbr-nrt atm-qos-parametersrandom-detect [attach group-name]

bundle bundle-namepvc name [vpi/]vci

class vc-class-nameprecedence [other | range ]bump {implicit | explicit precedence-level | traffic}protect {group | vc}ubr | ubr+ | vbr-nrt atm-qos-parametersrandom-detect [attach group-name]

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 ]Router(config-atm-vc)#

• 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 ProtectionVC Protection

protect { group | vc }protect { group | vc }Router(config-atm-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 RulesVC 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 valuesPrecedence Meaning

0-1 Best-effort Internet traffic2-3 Premium Internet traffic

4 VPN traffic5 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 classesvc-class best_effort vc-class vpnprecedence other precedence 4bump explicitly 2 bump explicitly 0protect group protect group

! !vc-class premium vc-class voipprecedence 2-3 precedence 5bump implicitly no bump trafficprotect group protect vc

! !vc-class bundle vc-class controlencapsulation aal5snap precedence 6-7broadcast bump explicitly 0protocol ip inarp protect groupoam-bundle manage 3

vc-class best_effort vc-class vpnprecedence other precedence 4bump explicitly 2 bump explicitly 0protect group protect group

! !vc-class premium vc-class voip

precedence 2-3 precedence 5bump implicitly no bump trafficprotect group protect vc

! !vc-class bundle vc-class control

encapsulation aal5snap precedence 6-7broadcast bump explicitly 0protocol ip inarp protect groupoam-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_pvcprecedence 0 20 40 10precedence 1 25 40 10precedence 2 35 40 10precedence 6 30 40 10precedence 7 30 40 10

random-detect-group guaranteed_bw_pvcprecedence 0 20 40 10precedence 1 25 40 10precedence 2 35 40 10precedence 6 30 40 10precedence 7 30 40 10

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-pointip address 216.23.45.5 255.255.255.252bundle SanFranciscoclass bundlepvc-bundle SF-control 26class controlvbr-nrt 1000 1000pvc-bundle SF-voip 25class voipvbr 2000 2000pvc-bundle SF-vpn 24class vpnvbr-nrt 4000 4000pvc-bundle SF-guaranteed 22class guaranteed_bwrandom-detect attach guaranteed_bw_pvcvbr-nrt 8000 8000pvc-bundle SF-best-effort 23class best_effortrandom-detect

interface ATM 5/1/0.22 point-to-pointip address 216.23.45.5 255.255.255.252bundle SanFranciscoclass bundlepvc-bundle SF-control 26class controlvbr-nrt 1000 1000

pvc-bundle SF-voip 25class voipvbr 2000 2000

pvc-bundle SF-vpn 24class vpnvbr-nrt 4000 4000

pvc-bundle SF-guaranteed 22class guaranteed_bwrandom-detect attach guaranteed_bw_pvcvbr-nrt 8000 8000

pvc-bundle SF-best-effort 23class best_effortrandom-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.


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


n Describe per-VC CB-WFQ

n Configure per-VC CB-WFQ

n Monitor and troubleshoot per-VC CB-WFQ



Per-VC CB-WFQPer-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-WFQPer-interface CB-WFQ

• CB-WFQ can be applied to an entire interface

Interface ATM1/0/0

SubinterfaceATM1/0/0.1


PVC 0/50

PVC 0/51

PVC 0/52

PVC 0/53

PVC 0/54

CB-WFQ

class-map HTTPmatch http!policy-map LimitHTTPclass HTTPpolice 256000 conform transmit exceed set-clp-transmit

!interface ATM5/0/0service-policy output LimitHTTP!

class-map HTTPmatch http

!policy-map LimitHTTPclass HTTPpolice 256000 conform transmit exceed set-clp-transmit

!interface ATM5/0/0service-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-WFQPer-subinterface CB-WFQ

• CB-WFQ can be applied to subinterfaces

Interface ATM1/0/0



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-pointmatch access-group 100 service-policy output Smart! pvc Core 0/51policy-map Smart vbr-nrt 10000 2000class CorporateTraffic !bandwidth 10000

class class-defaultset atm-clp

!

class-map CorporateTraffic interface ATM5/0/0.1 point-to-pointmatch access-group 100 service-policy output Smart

! pvc Core 0/51policy-map Smart vbr-nrt 10000 2000class CorporateTraffic !bandwidth 10000

class class-defaultset atm-clp

!

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



Per-interface CB-WFQPer-interface CB-WFQ

• CB-WFQ can be applied to an individual virtual circuit

Interface ATM1/0/0



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-WFQConfiguration ExamplePer-interface CB-WFQConfiguration Example

class-map MatchCorporatematch access-group 100!policy-map MARKclass MatchCorporatepolice 2000000 conform-action transmit exceed-action set-clp-transmit

!interface ATM5/0/0ip address 10.1.1.1 255.255.255.0service-policy output MARKpvc 0/50vbr-nrt 500 400 1000inarp 1broadcast

!access-list 100 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255

class-map MatchCorporatematch access-group 100

!policy-map MARKclass MatchCorporatepolice 2000000 conform-action transmit exceed-action set-clp-transmit

!interface ATM5/0/0ip address 10.1.1.1 255.255.255.0service-policy output MARKpvc 0/50vbr-nrt 500 400 1000inarp 1broadcast


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-WFQConfiguration Example

Per-VC CB-WFQConfiguration Example

class-map MatchCorporatematch access-group 100!policy-map MARKclass MatchCorporatepolice 2000000 conform-action transmit exceed-action set-clp-transmit

!interface ATM5/0/0no ip address!interface ATM5/0/0.1 point-to-pointip address 10.1.1.1 255.255.255.0pvc 0/50vbr-nrt 500 400 1000inarp 1service-policy output MARKbroadcast


class-map MatchCorporatematch access-group 100

!policy-map MARKclass MatchCorporatepolice 2000000 conform-action transmit exceed-action set-clp-transmit

!interface ATM5/0/0no ip address

!interface ATM5/0/0.1 point-to-pointip address 10.1.1.1 255.255.255.0pvc 0/50vbr-nrt 500 400 1000inarp 1service-policy output MARKbroadcast


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



Monitoring and Troubleshooting Per-interface CB-WFQ

Monitoring and Troubleshooting Per-interface CB-WFQ

show policy-map interface ATM-interfaceshow policy-map interface ATM-interfaceRouter#

• Displays the Service Policy parameters and statistics for the selected interface or subinterfaceRouter#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 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: access-group 100 (1761)queue size 0, queue limit 2500packets output 0, packet drops 0tail/random drops 0, no buffer drops 0, other drops 0Bandwidth: 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 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: access-group 100 (1761)queue size 0, queue limit 2500packets output 0, packet drops 0tail/random drops 0, no buffer drops 0, other drops 0Bandwidth: 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.



Monitoring and Troubleshooting Per-VC CB-WFQ

Monitoring and Troubleshooting 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 VCRouter#show queueing interface atm5/0Interface ATM5/0 VC 0/5Queueing strategy: fifoOutput queue 0/40, 0 drops per VCInterface ATM6/0 VC 0/16 Queueing strategy: fifoOutput queue 0/40, 0 drops per VCInterface ATM6/0 VC 0/50Queueing strategy: weighted fairTotal output drops per VC: 0Output 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/0Interface ATM5/0 VC 0/5

Queueing strategy: fifoOutput queue 0/40, 0 drops per VCInterface ATM6/0 VC 0/16 Queueing strategy: fifoOutput queue 0/40, 0 drops per VCInterface ATM6/0 VC 0/50Queueing strategy: weighted fairTotal output drops per VC: 0Output 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



n Configure RSVP to SVC mapping

n Monitor and troubleshoot RSVP to SVC mapping



RSVP to SVC MappingRSVP 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 MappingRSVP 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 ParametersATM SVC Parameters

SCR = BWRSVP . (53/48) . (MPS + DLE + UCO)/MPS

Data Link Encapsulation overheadAAL5SNAP 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 DataIP

HeaderAAL5SNAP

HeaderATM

HeaderATM

HeaderVoice 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 MappingOptional QoS

RSVP to SVC MappingOptional QoS

• RSVP can mark conforming and exceeding packets with different IP precedence or ToSvalues

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



ConfiguringRSVP to SVC Mapping

ConfiguringRSVP 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 RSVPEnabling RSVP

ip rsvp bandwidth reservable-bw max-flow-bwip rsvp bandwidth reservable-bw max-flow-bwRouter(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 SVCsEnabling Creation of SVCs

ip rsvp svc-requiredip 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 limitip rsvp atm-peak-rate-limit limitRouter(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 WREDRSVP-based Marking and WRED

ip rsvp precedence {conform | exceed} precedenceip 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-grouprandom-detect attach random-detect-groupRouter(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 MappingExample

RSVP to SVC MappingExample

interface ATM2/1/0ip address 10.1.1.1 255.255.255.0ip rsvp bandwidth 10000 10000ip rsvp svc-requiredip route-cache flowip rsvp precedence conform 5 exceed 0atm pvc 1 0 5 qsaalatm pvc 2 0 16 ilmiatm esi-address 111111111151.00pvc pvc12 0/51inarp 5broadcast

!

interface ATM2/1/0ip address 10.1.1.1 255.255.255.0ip rsvp bandwidth 10000 10000ip rsvp svc-requiredip route-cache flowip rsvp precedence conform 5 exceed 0atm pvc 1 0 5 qsaalatm pvc 2 0 16 ilmiatm esi-address 111111111151.00pvc pvc12 0/51inarp 5broadcast

!

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.



Monitoring and Troubleshooting RSVP to SVC Mapping

Monitoring and Troubleshooting RSVP to SVC Mapping

show ip rsvp interface [intf]show ip rsvp interface [intf]Router#

• Displays RSVP-related interface information

Router#show ip rsvp interfaceinterface allocated i/f max flow max pct UDP IP UDP_IP UDP M/CEt4/0 0M 7M 5M 0 0 0 0 0AT5/0/0 0M 10M 1M 0 0 0 0 0Se5/1/0 0M 192K 192K 0 0 0 0 0

Router#show ip rsvp interfaceinterface allocated i/f max flow max pct UDP IP UDP_IP UDP M/CEt4/0 0M 7M 5M 0 0 0 0 0AT5/0/0 0M 10M 1M 0 0 0 0 0Se5/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).


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

Documents

s10 - Ip Qos - Ip Over Atm