Contents
- IP to ATM Class of Service Overview
- Finding Feature Information
- About IP to ATM CoS
- Single ATM VC Support
- VC Bundle Support and Bundle Management
- Per-VC LLQ WFQ and CBWFQ Support
- Why Use IP to ATM CoS
- Benefits
- IP to ATM CoS Features
- Congestion Avoidance
- Bumping and ATM VC Bundles
- Restrictions
IP to ATM Class of Service Overview
This module provides a high-level overview of IP to ATM Class of Service (CoS), a feature suite that maps QoS characteristics between IP and ATM.
- Finding Feature Information
- About IP to ATM CoS
- Why Use IP to ATM CoS
- IP to ATM CoS Features
- Congestion Avoidance
- Bumping and ATM VC Bundles
- Restrictions
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
About IP to ATM CoS
The IP to ATM CoS feature implements a solution for coarse-grained mapping of QoS characteristics between IP and ATM, using Cisco Enhanced ATM port adapters (PA-A3) on Cisco 7200 and Cisco 7500 series routers. (This category of coarse-grained QoS is often referred to as CoS). The resulting feature makes it possible to support differential services in network service provider environments.
IP to ATM CoS is designed to provide a true working solution to class-based services, without the investment of new ATM network infrastructures. Now networks can offer different service classes (sometimes termed differential service classes ) across the entire WAN, not just the routed portion. Mission-critical applications can be given exceptional service during periods of high network usage and congestion. In addition, noncritical traffic can be restricted in its network usage, which ensures greater QoS for more important traffic and user types.
The IP to ATM CoS feature is supported on Cisco 2600, Cisco 3600, Cisco 7200, and Cisco 7500 series routers equipped with the following hardware:
- Cisco 2600 and Cisco 3600 series: ATM OC-3, T1 IMA, or E1 IMA port adapter
Cisco 7200 series: Cisco 7500 series:
IP to ATM CoS supports configuration of the following features:
Single ATM VC Support
IP to ATM CoS support for a single ATM VC allows network managers to use existing features, such as committed access rate (CAR) or policy-based routing (PBR), to classify and mark different IP traffic by modifying the IP Precedence field in the IP version 4 (IPv4) packet header. Subsequently, Weighted Random Early Detection (WRED) or distributed WRED (DWRED) can be configured on a per-VC basis so that the IP traffic is subject to different drop probabilities (and therefore priorities) as IP traffic coming into a router competes for bandwidth on a particular VC.
Enhanced ATM port adapters (PA-A3) provide the ability to shape traffic on each VC according to the ATM service category and traffic parameters employed. When you use the IP to ATM CoS feature, congestion is managed entirely at the IP layer by WRED running on the routers at the edge of the ATM network.
The figure below illustrates the IP to ATM CoS support for a single ATM VC.
VC Bundle Support and Bundle Management
ATM VC bundle management allows you to configure multiple VCs that have different QoS characteristics between any pair of ATM-connected routers. As shown in the figure below, these VCs are grouped in a bundle and are referred to as bundle members.
ATM VC bundle management allows you to define an ATM VC bundle and add VCs to it. Each VC of a bundle has its own ATM traffic class and ATM traffic parameters. You can apply attributes and characteristics to discrete VC bundle members or you can apply them collectively at the bundle level.
Using VC bundles, you can create differentiated service by flexibly distributing IP precedence levels over the different VC bundle members. You can map a single precedence level or a range of levels to each discrete VC in the bundle, thereby enabling individual VCs in the bundle to carry packets marked with different precedence levels. You can use WRED (or DWRED) to further differentiate service across traffic that has different IP precedences but that uses the same VC in a bundle.
To determine which VC in the bundle to use to forward a packet to its destination, the ATM VC bundle management software matches precedence levels between packets and VCs (see the figure below). IP traffic is sent to the next hop address for the bundle because all VCs in a bundle share the same destination, but the VC used to carry a packet depends on the value set for that packet in the IP Precedence bits of the type of service (ToS) byte of its header. The ATM VC bundle management software matches the IP precedence of the packet to the IP Precedence value or range of values assigned to a VC, sending the packet out on the appropriate VC. Moreover, the ATM VC bundle management feature allows you to configure how traffic will be redirected when the VC the packet was matched to goes down. The figure below illustrates how the ATM VC bundle management software determines which permanent virtual circuit (PVC) bundle member to use to carry a packet and how WRED (or DWRED) is used to differentiate traffic on the same VC.
The support of multiple parallel ATM VCs allows you to create stronger service differentiation at the IP layer. For instance, you might want to provide IP traffic belonging to real-time CoS (such as Voice over IP traffic) on an ATM VC with strict constraints (constant bit rate (CBR) or variable bit rate real-time (VBR-rt), for example), while transporting traffic other than real-time traffic over a more elastic ATM available bit rate (ABR) PVC. Using a configuration such as this would allow you to fully utilize your network capacity. You could also elect to transport best-effort IP traffic over an unspecified bit rate (UBR) PVC--UBR is effectively the ATM version of best-effort service.
Per-VC LLQ WFQ and CBWFQ Support
The IP to ATM CoS feature allows you to apply a policy map to a VC to specify a service policy for that VC so that all traffic sent on that VC is categorized according to the classes and their match criteria defined by the service policy. In other words, IP to ATM CoS takes the functionality defined for standard LLQ, WFQ, and CBWFQ and makes it available for application and use at the discrete VC level.
IP to ATM CoS allows you to configure a single, standalone VC or individual VCs belonging to a bundle. You also can configure collectively all VCs belonging to a bundle. However, for per-VC LLQ, WFQ and CBWFQ, you can configure individual VCs only. That is, you can configure a standalone VC or a VC that belongs to a bundle, but you cannot use per-VC LLQ, WFQ and CBWFQ to configure a bundle of VCs collectively.
Per-VC LLQ, WFQ and CBWFQ allows you to differentiate the use of individual VCs within a bundle. For instance, you can apply one service policy to one VC belonging to a VC bundle and apply a different service policy to another VC belonging to the same bundle. You can also apply the same policy map to multiple VCs--whether standalone or bundle members--but each VC can have only one service policy. To concatenate service policies, you must create a third policy map and include in it all the classes that you want to use from policy maps you would have concatenated.
The following is a summary of how you configure a VC to use CBWFQ:
- You define traffic classes to specify the classification policy (class maps). This process determines how many types of packets are to be differentiated from one another.
- You configure policy maps containing classes that specify the policy for each traffic class.
- You attach a policy map to a VC that uses IP to ATM CoS to specify the service policy for the VC.
To apply flow-based WFQ on a per-VC basis, you configure WFQ in the predefined CBWFQ default class, which is called class-default, but you do not ascribe bandwidth to the default class.
Why Use IP to ATM CoS
Internet service classes can be identified and sorted within the router network. But as traffic traverses the wide-area ATM fabric, the relative ATM class definitions are not equivalent, and a traffic type may be treated differently in the ATM switching fabric than in the router network; mission-critical applications or data could be dropped during times of network congestion.
The IP to ATM CoS feature uses the Cisco Enhanced ATM port adapter (PA-A3) on Cisco 7500 and Cisco 7200 series routers to provide the ability to map IP CoS and ATM QoS, extending the capability previously available only for IP networks; differentiated services are preserved through the ATM network.
Benefits
Here are some benefits of using IP to ATM CoS:
- Ensures effective differential classes over IP and traditional ATM networks. For instance, the VC bundle management feature provides for differentiated QoS by allowing for the coexistence of multiple VCs with different QoS characteristics from the same source to the same destination.
- Uses existing ATM infrastructures.
- Implements solutions for coarse-grained mapping of QoS characteristics called CoS between IP and ATM.
- Employs a high-performance design benefiting from distributed processing on the Cisco 7500 series routers and Versatile Interface Processor (VIP).
- Uses the Cisco Enhanced ATM port adapter (PA-A3), which supports traffic shaping and has rich ATM Service Category support. This port adapter (PA) is supported on the Cisco 7500+VIP and Cisco 7200 series routers.
- Provides per-VC queueing on the PA, per-VC back pressure, and per-VC WRED VIP queueing, which bring stability to a network by ensuring that system packets such as Border Gateway Protocol (BGP) and Intermediate System-to-Intermediate System (IS-IS) are never dropped.
- Provides flexible management of the VC bundle on PVC failure.
- Provides CBWFQ functionality at the VC level.
IP to ATM CoS Features
IP to ATM CoS includes the following features:
- Per-VC queueing infrastructure. This feature enables queues to be maintained on a per-VC basis. Packets are queued and dequeued based on the back pressure from the PA. Use of a queue per VC prevents one or more congested VCs from affecting the traffic flow on other VCs that are not congested.
- Per-VC WRED (or DWRED). This feature applies the WRED algorithm independently to each per-VC queue. The WRED parameters are configurable on a per-VC basis so that congestion management can be configured as appropriate for each VC.
- Per-VC WRED (or DWRED) statistics. This feature maintains per-flow and per-VC statistics based on IP precedence.
- Per-VC LLQ, WFQ and CBWFQ. This feature allows you to apply CBWFQ functionality--normally applicable at the interface or subinterface levels only--to an individual VC configured for IP to ATM CoS. You can use this feature to apply either CBWFQ or flow-based WFQ on a per-VC basis.
- Per-VC traffic policing. This feature allows you to police traffic within a traffic policy, per-VC.
Congestion Avoidance
For each VC that is created on the Enhanced ATM port adapter (PA-A3), the PA allocates some of the buffers from its buffer pool to that VC in order to create a queue for that VC.
The use of per-VC queues ensures that a direct relationship exists between the outgoing ATM VC and the IP packets to be forwarded on that queue. This mechanism establishes a packet queue for each outgoing ATM VC. In this manner, should an ATM VC become congested, only the packet queue associated with that VC will begin to fill. If the queue overfills, then all other queues remain unaffected. Such a mechanism ensures that an individual VC cannot consume all of the resources of the router should only one of its outgoing VCs be congested or underprovisioned.
Queues for buffering more packets for a particular VC are created in the Layer 3 processor system and are mapped one-to-one to the per-VC queues on the PA. When the PA per-VC queues become congested, they signal back pressure to the Layer 3 processor; the Layer 3 processor can then continue to buffer packets for that VC in the corresponding Layer 3 queue. Furthermore, because the Layer 3 queues are accessible by the Layer 3 processor, a user can run flexible software scheduling algorithms on those queues.
When you transport data over ATM fabrics, it is essential that decisions to discard data (because of insufficient network resources or congestion) be made at the packet level. To do otherwise would be to send incomplete data packets into the ATM fabric, causing the packets to be discarded by either the ATM switched fabric (if it is equipped with early packet discard) or at the remote end where the packet will be reassembled and found to be incomplete.
To initiate effective congestion management techniques, IP to ATM CoS uses per-VC WRED (or DWRED). Per-VC WRED (or DWRED) selectively places TCP sessions in slow start mode to ensure higher aggregate throughput under congestion. The figure below shows low priority packets being dropped on VC1 because VC1 is congested. In this example, VC2 is not congested and all packets, regardless of priority, are sent.
Running the WRED algorithm independently on each per-VC queue provides differentiated QoS to traffic of different IP Precedence values.
Bumping and ATM VC Bundles
The ATM VC bundle is designed to behave as a single routing link to the destination router while managing the integrity of its group of circuits. The integrity of each circuit is maintained through individual monitoring. Should a circuit fail, appropriate action is taken, in the form of circuit bumping or bundle disabling.
VC integrity is maintained through ATM Operation, Administration, and Maintenance (OAM) polling mechanisms. These mechanisms will determine whether a VC is unavailable or severely congested. Should an individual circuit become unavailable, then the device consults a preset series of rules to determine the course of action to take next. These rules are defined by the Internet service provider (ISP) through configuration parameters.
The figure below conceptualizes a failed VC bundle member whose failure calls into effect the configured bumping rules.
In the event of failure, the router responds with one of two methods. The first method dynamically assigns the traffic bound on the failed VC to an alternative VC, which is termed circuit bumping . Bumped traffic is then shared on an existing in-service VC. Traffic typically would be bumped from a higher class to a lower one, although it need not be. For example, should the premium, or first class, data circuit become unavailable, then all premium users would share the second class or general circuit. Preference would then be given to the premium traffic within this shared circuit.
The second method is to declare all circuits of the bundle to be down. In effect, the device is declaring the routed bundle inactive and asking the routing layer to search for an alternate.
The determination of whether to bump or whether to declare the bundle inactive is predefined by the network provider when administering the network configuration.
Restrictions
The following restrictions apply for IP to ATM CoS:
IP to ATM CoS supports only PVCs: - For PVC connections, it supports multipoint and point-to-point subinterfaces.
- For PVC encapsulations, it supports only ATM adaptation layer (AAL5), Subnetwork Access Protocol (SNAP), and multiplex device (mux) interfaces.
- IP to ATM CoS does not allow point-to-multipoint VCs in the bundle. All VCs share the same source and destination (target) addresses.
- IP to ATM CoS does not work with the ATM Interface Processor (AIP) and the ATM port adapter (PA-A1).