The ATM Forum publishes multi-vendor recommendations to further the use of ATM technology.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
The Traffic Management Specification Version 4.0 defines five ATM service categories that describe the traffic transmitted by users onto a network and the Quality of Service (QoS) that a network needs to provide for that traffic. The five service categories are listed here:
variable bit rate non-real-time (VBR-nrt)
The focus of this document is on VBR-nrt.
Native ATM traffic shaping is typically implemented by assigning a virtual circuit (VC) to the VBR-nrt service category. Cisco router ATM interfaces implement VBR-nrt traffic shaping in a way that's unique to the hardware.
The terminology related to VBR-nrt traffic shaping can be very confusing. This document seeks to clarify the peak cell rate (PCR), sustained cell rate (SCR), and maximum burst size (MBS) parameters that are specified when configuring VBR-nrt VCs. This document also provides a single reference on how Cisco ATM router interfaces implement traffic shaping.
Traffic shaping limits the rate of transmission, and smoothes transmission rates by storing traffic that is above the configured rate in a queue.
In other words, when a packet arrives at an interface for transmission on an ATM virtual circuit (VC), the following happens:
If the queue is empty, the arriving packet is placed in the queue. During every time interval, the traffic shaper schedules and sends a packet.
If the queue is full, the packet is dropped. This is known as a tail-drop, assuming the default First In, First Out (FIFO) queueing mechanism is being used.
Why would you want to control or limit the rate of an ATM VC? Here are some reasons to consider:
To partition your T1, T3, and even OC-3 (optical carrier) links into smaller channels.
To ensure that traffic from one VC does not consume the entire bandwidth of an interface, thus adversely impacting other VCs with resulting data loss.
To control bandwidth access when policy dictates that the rate of a given VC on average not exceed a certain rate.
To match the local interface's transmission rate to the speed of a remote target interface. Suppose one end of a link transmits at 256 kbps and the other end transmits at 128 kbps. Without an even, end-to-end pipe, an intermediate switch may have to drop some packets at the lower-speed end, disrupting applications using the link.
Traffic shaping retains excess data in the router and allows the router to apply intelligent quality of service (QoS) mechanisms like Weighted Random Early Detection (WRED) and Class-Based Weighted Fair Queueing (CBWFQ). These QoS mechanisms determine in which order to service the packets within the per-VC queues as well as which packets to discard when the queues exceed certain thresholds.
Note: The bandwidth command under the atm interface does not provide traffic shaping on the interface. Instead, it is used for routing protocols algorithms like IGRP and EIGRP to calculate the composite metric to decide the best path to a route.
Providers of ATM switch networks enforce a traffic contract by implementing traffic policing mechanisms. Usage parameter control (UPC) applies a mathematical formula to determine whether the traffic being sent by a router on a VC complies with the contract. Providers typically implement policing on the first switch into the network at a point referred to as the User-Network Interface (UNI). Since ATM switches operate at layer 2 of the OSI reference model, they cannot read fields in the IP header and determine which packets take precedence when congestion occurs. Policing is based purely on cell arrival times.
On the Catalyst 8500 series and LightStream1010 ATM switch routers, configure traffic policing by specifying a value for the UPC parameter in the atm pvc command.
atm pvc vpi vci [cast-type type] [upc upc] [pd pd] [rx-cttr index] [tx-cttr index] [wrr-weight weight]
The per-VC UPC policy specifies one of three actions to take with cells deemed non-compliant by an ATM switch:
Drop the cells.
Tag the cells by setting the cell loss priority (CLP) bit in the ATM header.
Pass the cells.
By default, UPC passes any non-compliant cells.
Here is a typical example of a set of rules that a UPC policy will enforce for a VBR-nrt VC:
Cells that are received at or below the SCR are carried unchanged through the network.
Cell bursts with rates above the SCR but below the PCR are transmitted unchanged for burst sizes smaller than the MBS.
Cells that are received above the PCR are deemed non-compliant and subject to the configured UPC action, such as tag or discard.
Cell bursts that exceed the MBS number of cells are deemed non-compliant and subject to the configured UPC action, such as tag or discard.
On Cisco ATM switches, use the show atm vc interface atm command to display the number of Rx and Tx UPC violations as well as any resulting drops.
switch#show atm vc interface atm 1/0/1 0 100 Interface: ATM1/0/1, Type: e1suni VPI = 0 VCI = 100 Status: UP Time-since-last-status-change: 00:09:51 Connection-type: PVC Cast-type: point-to-point Packet-discard-option: disabled Usage-Parameter-Control (UPC): drop Wrr weight: 2 Number of OAM-configured connections: 0 OAM-configuration: disabled OAM-states: Not-applicable Cross-connect-interface: ATM4/0/0, Type: oc3suni Cross-connect-VPI = 0 Cross-connect-VCI = 100 Cross-connect-UPC: drop Cross-connect OAM-configuration: disabled Cross-connect OAM-state: Not-applicable Threshold Group: 3, Cells queued: 0 Rx cells: 5317, Tx cells: 5025 Tx Clp0:5025, Tx Clp1: 0 Rx Clp0:5317, Rx Clp1: 0 Rx Upc Violations:45, Rx cell drops:45 Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0 Rx connection-traffic-table-index: 70 Rx service-category: VBR-nrt (Non-Realtime Variable Bit Rate) Rx pcr-clp01: 720 Rx scr-clp01: 320 Rx mcr-clp01: none Rx cdvt: 300 Rx mbs: 64 Tx connection-traffic-table-index: 70 Tx service-category: VBR-nrt (Non-Realtime Variable Bit Rate) Tx pcr-clp01: 720 Tx scr-clp01: 320 Tx mcr-clp01: none Tx cdvt: 300 Tx mbs: 64
Traditionally, only ATM switches implemented traffic policing. Recently, as part of Cisco's robust quality of service (QoS) feature set, Cisco ATM router interfaces now can be configured to set the CLP bit as part of a service policy designed to implement traffic policing. On a router, traffic policing differs from traffic shaping by dropping excess traffic or rewriting a packet header, rather than storing the excess in a queue.
Use the set-clp-transmit command to configure a router to set the CLP bit as a policing action. To do so, create a policy map and then configure the police command with set-CLP-transmit as an action.
7500(config)# policy-map police 7500(config-pmap)# class group2 7500(config-pmap-c)# police bps burst-normal burst-max conform-action action exceed-action action violate-action action
The set-clp-transmit command is supported as of Cisco IOS® Software Release 12.1(5)T on RSP platforms and 12.2(1)T on other platforms.
Every router interface has a port speed, which defines the maximum number of bits that can be transmitted and received over the physical interface per second. We sometimes refer to the port speed as the "line rate". For example, a PA-A3-T3 provides a single port of ATM at layer 2 and DS-3 at layer 1. The physical port speed on a DS-3 is rounded to 45 mbps.
An interface's line rate converts to a number of 53-byte ATM cells. To determine this number, use the following formula:
Line rate / 424 bits per cell = number of cells or cell timeslots per second
For example, a DS-1 (without framing overhead) transmits at 1.536 mbps. The DS-1 line rate of 1.536 mbps divided by 424 bits per cell equals 3622 cells per second. The table below shows the line type, mbps and cell rate per second for various line rates:
|Line Type||mbps||Cell Rate per Second|
Note: Many ATM switches measure bandwidth in cells per second, while Cisco routers use bits per second (kbps or mbps). The conversion factor between cells per second and bits per second is:
1 cell = 53 bytes = (53 bytes) * (8 bits/byte) = 424 bits
We can calculate the peak rate and the sustained rate in kbps using the formulas below:
Peak rate = Peak Cell Rate (PCR) [cells per second] x 424 [bits per cell]
Sustained rate = Sustained Cell Rate (SCR) [cells per second] x [bits per cell]
It is useful to understand the concept of ATM cell time. The amount of time that it takes for one ATM cell to pass a given point in an interface is called the cell time. We can calculate this value as follows:
ATM cell time = 1 cell / ATM cell rate (in cells per second)
Here is a sample calculation for a DS-1 link:
1 cell / 3622 cells per second = .0002760417 seconds per ATM cell
Note: A millisecond is 0.001 (one-thousandth) of a second and a microsecond is 0.000001 (one-millionth) of a second. The representation of .0002760417 in milliseconds is .276 and the representation in microseconds is 276.04. This document uses the representation of cell times in microseconds.
All Cisco ATM router interfaces support some form of traffic shaping. Most interfaces support native ATM traffic shaping via the vbr-nrt command.
When selecting PCR and SCR values, consult the following table, which describes the officially supported values for each interface hardware type. Cisco ATM router interfaces do not support any kbps value in the range from zero to the line rate. Instead, they support a set of values that adhere to a formula or to a set of incremented values. In addition, note that the configured values in kbps include the bandwidth consumed by user data as well as by all ATM overhead, including the 5-byte cell header, cell padding, and AAL5 overhead.
Since setting PCR and SCR to the same value effectively removes any burst capability, you can no longer configure a non-zero value for MBS in this configuration if your Cisco IOS Software Release includes the changes made in CSCdr50565 and CSCds86153.
|Interface Hardware||Supported Traffic Shaping Parameters|
|PA-A3-OC3 / PA-A6-OC3||
|PA-A3-T3/E3 / PA-A6-T3/E3||
|NP-1A-MM NP-1A-SM NP-1A-SM-LR||
|Multiflex Trunk Module (MFT)||
|ADSL interface for 826, 827||VBR-nrt, UBR, and CBR, per-VC queueing. For more details, read Queuing and ATM Traffic Shaping on the Cisco 827 Router|
|ADSL interface for IAD 2400||The IAD shaper only supports integer values of peak-inter-cell-delay, for example 1,2,3,... So if the line rate is 1536, the PCRs available are 1536, 768, 512, 384. This doesn't mean that you can't configure any value, but that the actual value used will be the same as above.2 For SCR, you need to specify the maximum number of burst cell to regulate the traffic flow properly. All service categories are configurable.|
|7300-2OC3ATM-MM 7300-2OC3ATM-SMI 7300-2OC3ATM-SML||
|4xOC3 for ESR||
|1xOC12 for ESR||
1 The ATM network modules for the 2600 and 3600 series use the RS8234 SAR, which supports 256 predefined values of PCR for VBR-nrt.
2 For example, if the PCR is configured as 320, the shaper will fallback to PCR=298. This means that despite an SCR of 320 being configured to support four simultaneous voice calls, the quality of the fourth call will be poor because the SCR is more than PCR 298. In this case, change the PCR in the IAD config to 448 (=896/2).
The VBR-nrt service category uses three parameters when implementing traffic shaping:
|SCR||Defines the sustained rate at which you expect to transmit data, voice and video. Consider SCR to be the true bandwidth of a VC and not the long-term average traffic rate.|
|PCR||Defines the maximum rate at which you expect to transmit data, voice and video. Consider PCR and MBS as a means of reducing latency, not increasing bandwidth.|
|MBS||Defines the amount of time or the duration at which the router sends at PCR. Calculate this time in seconds using the following formula: T = (burst cells x 424 bits per cell) / (PCR - SCR) MBS will accommodate temporary bursts or short spikes in the traffic pattern. For example, an MBS of 100 cells allows a burst of three MTU-size Ethernet frames or one MTU-size FDDI frame. It is important that you factor longer duration bursts into the SCR.|
Note: The maximum MBS for NM-1A-T3, NM-1A-E3 and NM-1A-OC3 modules is 200 cells. Please refer to this bug CSCeb42179. The maximum MBS for PA-A3-OC3 and PA-A3-T3/E3 modules is 23376 cells. Please refer to this bug CSCdk37079.
Beginning in 12.3(5) the behavior of the MBS value was revised for PVCs that have PCR equal to SCR. When considering that the MBS maintains the duration of the burst, when PCR equals SCR we have not configured a PCR greater than the SCR and MBS value will not be used. Rather than allowing the user to configure an MBS, it will default to 1. Previous behavior would allow the MBS to be configured even though the value was being ignored. The example below shows the output from a router where the PCR is configured to equal the SCR.
The following is an example of MBS value when PCR equals SCR:
Router(config-if-atm-vc)#vbr-nrt ? <1-6093> Peak Cell Rate(PCR) in Kbps Router(config-if-atm-vc)#vbr-nrt 1000 ? <1-1000> Sustainable Cell Rate(SCR) in Kbps Router(config-if-atm-vc)#vbr-nrt 1000 1000 ? <1-1> Maximum Burst Size(MBS) in Cells <cr>
VBR-nrt implementations follow a leaky bucket or token bucket algorithm. An ATM VC needs to have a token in the bucket to transmit a cell. The algorithm replenishes tokens in the bucket at the rate of SCR. If a source is idle and does not transmit for a period of time, tokens accumulate in the bucket. An ATM VC can use the accumulated tokens to burst at the rate of PCR until the bucket is empty, at which point tokens are again replenished at the rate of SCR.
It is important to understand that PCR is a temporary burst. The duration at which you send at PCR is derived from the MBS translated into a "time on the wire." For example, recall the above formula for calculating the cell time with a DS-1 link:
1 cell / 3622 cells per second = 276.04 microseconds per ATM cell
On a DS-1 link, an MBS value of 100 equates to a PCR duration of 2.8 seconds. We recommend that you take the time to understand how the MBS value translates to a PCR duration when provisioning VBR-nrt VCs.
Since the PCR burst is temporary, configure a VC as VBR-nrt if your traffic is bursty and can benefit from the short bursts at PCR. Otherwise, if your traffic pattern is bulk data transfer, PCR brings virtually no benefit. The reason is that to burst at PCR, the ATM VC must send for some duration below SCR. Let's look at some examples.
Assume a need to transmit interactive traffic that consists of one 1500-byte packet every second for a total of 12 kbps. (We will ignore ATM overhead in this example.) Configure a VBR-nrt using the following specifications:
PCR = 800 kbps
SCR = 64 kbps
MBS = 32 cells
A PCR of 800 kbps means the first packet is sent in 15 microseconds (12 kbps packet / 800 kbps PCR). It then takes 187.5 microseconds (12 kbps packet / 64 kbps SCR) for the token bucket to replenish. The next packet is sent in 15 microseconds. This sample illustrates how PCR bursts reduce latency. Without PCR, on a VC with only an SCR of 64 kbps, it would take 187.5 microseconds to send the first and the second packet.
Now assume a need to transmit a large file. Only the first packet (likely) is sent at PCR. The average transfer rate will peak at the SCR since the tokens cannot accumulate. Therefore, VBR-nrt bursting offers little benefit for large file transfers.
These examples used an MBS value that matches exactly the size of a single 1500-byte packet. Some applications, such as certain video devices, send very large IP packets up to 64 kB. These packets easily exceed the MTU of the link, and it can be useful to send the entire packet as a burst. Thus, select an MBS of 1334 cells derived from the formula of 64 kb packet / 48 payload bytes per cell.
There is no official definition of a burst. We can think of a burst in terms of MTU-sized frames or whatever size frame the traffic pattern presents. This frame will then break down into some number of cells. The best we can do is go with the recommendations and again understand when we use the MBS.
Note that if you configure PCR=SCR, the burst calculation is ignored and the credit is set to 1, regardless of the burst size. In summary, we recommend the following when choosing traffic-shaping parameters for VBR-nrt VCs:
SCR: This rate should be the one you would pick if your traffic was constrained to a constant bit-rate circuit and you did not care about latency. Look on this as the true bandwidth of the VC.
MBS: This number of cells should accommodate the typical burst size you expect for "bursty" traffic.
PCR: This rate should be derived in combination with MBS in order to achieve the desired latency for "bursty" traffic. Look on this as a means of decreasing the latency of a VC rather than increasing its bandwidth.
One of the most common reports to the Cisco Technical Assistance Center is a failure to see the ATM interface bursting at the configured PCR. It is important to understand that the ATM interface does burst, but does so only when the ATM VC has transmitted for a duration below the SCR. If the ATM VC has always transmitted at SCR, then no burst credits have accumulated.
To "see" the burst, Cisco recommends using the following test procedure if you have access to an ATM cell tester:
Configure a PCR that is two times the kbps rate of the SCR.
Start the cell tester.
Start the traffic generator and transmit at a rate above the PCR.
Consult the measured intercell gap on the cell tester. You will see the burst because the cell tester will report a smaller intercell gap.
Stop the cell tester and continue sending at PCR on the traffic generator.
Start the cell tester again. Importantly, you will not see the burst. This is because the traffic generator has always sent above the PCR (and/or above the SCR). The ATM VC has never sent below SCR and thus has never accumulated enough credits to send above the SCR again.
When configuring the traffic shaping values for a VBR-nrt VC, factor any sustained bursts into the SCR. As illustrated with the above test procedure, the MBS is not designed for sustained transmission above the SCR.
In typical hub and spoke wide-area network topologies, the traffic flow volume is asymmetrical, in which more traffic flows down to the remote site than comes from the remote site. Such configurations may benefit from provisioning an asymmetrical permanent virtual circuit (PVC), which uses different PCR and SCR traffic shaping values at the two router ends of an nrt-VBR PVC.
See Do Both Router Ends of an ATM PVC Need to Use the Same Traffic Shaping Values? for guidance on configuring asymmetrical PVCs.
When configuring switched virtual circuits (SVCs) on an ATM router interface, the vbr-nrt command accepts input-pcr, input-scr, and input-mbs parameters. In the following example, we specify an output PCR and SCR of 5 MB and an input PCR and SCR of 2.5 MB.
Router(config-subif)#svc nsap 47.00918100000000E04FACB401.00E04FACB401.00 Router(config-if-atm-vc)#vbr-nrt 1536 768 94 ? <1-1536> Input Peak Cell Rate(PCR) in Kbps <cr> Router(config-if-atm-vc)#vbr-nrt 1536 768 94 1536 768 ? <1-65535> Input Maximum Burst Size(MBS) in Cells <cr>
When specifying traffic parameters for a PVC, note how the same vbr-nrt configuration statement does not offer the option of configuring these values since the VC is not performing any signaling.
Router(config)#int atm6/6.1 Router(config-subif)#pvc 100/100 Router(config-if-atm-vc)#vbr-nrt 1536 1536 ? <1-1> Maximum Burst Size(MBS) in Cells <cr> Router(config-if-atm-vc)#vbr-nrt 1536 1536 1 ? <cr>
You must ensure that you properly configure traffic shaping on your routers. Without traffic shaping, cells transmitted by the router will not conform to the traffic contract with the ATM network. Such nonconformance will lead to violations and excessive cell loss if the ATM switch is configured for traffic policing.
Symptoms of incorrectly configured traffic shaping parameters include the following:
Small pings to the far-end location succeed, but larger packet sizes fail.
Certain applications such as Telnet seem to work, but other applications such as File Transfer Protocol (FTP) do not.
If you are experiencing these symptoms, we recommend contacting your ATM network provider to investigate whether the switches are policing and whether the VC has experienced cell loss. Then determine if any configuration changes are necessary on the router.
Since traffic shaping limits the output of a VC, you may see output drops on the ATM interface or on one or more VCs. See Troubleshooting Output Drops on ATM Router Interfaces for guidance on resolving this problem.
A frequent question to Cisco TAC is why output drops are occurring even though the VC appears not to be reaching the configured SCR, as shown in the output of show interface atm. In other words, why does the interface kbps rate never hit the configured SCR (or PCR if the PCR is equal to the SCR) ? There are several reasons why the interface rate can be lower than the SCR:
The shaping engine does not count the AAL5 trailer and ATM cell header in the kbps rate displayed when you use the show interface atm command.
The shaping engine does not differentiate between actual data bytes and padding or filler payload. An ATM cell must contain 48 bytes in the payload field. An ATM interface uses two cells to transmit a 64-byte IP packet. In the second cell, "wasted" payload in the form of padding is counted by the ATM switch, but ignored by the router. Thus, unused cell payload can prevent the actual bit rate from reaching the SCR.
The average bit-rate is based on a default load interval of 5 minutes. (Use the load-interval interface command to adjust the interval down to its lowest value of 30 seconds.) Traffic bursts can exceed the SCR and PCR for a short period of time, causing output drops eventhough the long-term rate is below SCR.
Thus, avoid using the unit of bits-per-second in the show interface atm output to measure traffic shaping accuracy. Instead, we recommend translating the SCR into packets-per-second. A larger packet size should produce a bit rate that is closer to the configured SCR. In addition, we strongly recommend using an ATM traffic analyzer when measuring traffic-shaping accuracy.
ATM VCs using a very low SCR value may experience ping timeouts. For example, a 1500-byte packet equates to 12,000 bits without overhead or 13,200 bits with the 10 percent cell tax. Configuring an SCR of 8 kbps gives you a two-second transmission time, which matches the default ping timeout. Thus, you may need to configure a higher timeout value to resolve the problem.
If your ATM VC is configured with a higher SCR value and is experiencing ping failures, conduct ping tests of various sizes and monitor the round-trip times printed to the screen. Note the round-trip min/avg/max values.
1500 Byte Ping Results: Sending 5, 1500-byte ICMP Echos to 22.214.171.124, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 420/1345/1732 ms
Ideally, an ATM interface should schedule the cells of an ATM VC at an even pace and with an even inter-cell gap. For example, if you configure an ATM VC with an SCR of 500 kbps on a DS-1 physical interface, the VC should be assigned every third timeslot (1500 kbps line rate / 500 kbps SCR = 3).
In some cases, the scheduler on the ATM router interface transmits adjacent cells back-to-back, rather than with the expected inter-cell gap. This condition is referred to as cell clumping. When this condition occurs, an ATM switch may reasonably determine that the kbps rate being transmitted by the router is technically exceeding the VC's allowed rate at that given moment.
ATM switches support a configurable value known as cell delay variation tolerance (CDVT), which implements a "forgiveness factor" for cell clumping. In other words, it forgives the router and the ATM VC if a few cells are transmitted back to back and delays implementing a UPC penalty. CDVT is measured in seconds and is designed to accommodate apparent violations of the traffic contract.
- ATM Technology Support
- Configuring Traffic Shaping on the PA-A3 and PA-A6 ATM Port Adapters
- Traffic Management Specification Version 4.0
- Understanding Traffic Shaping with AIP
- Does the PA-A1 ATM Port Adapter Support Traffic Shaping?
- Do Both Router Ends of an ATM PVC Need to Use the Same Traffic Shaping Values?
- Troubleshooting Output Drops on ATM Router Interfaces
- Technical Support & Documentation - Cisco Systems
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.