IP to ATM Class of Service Design Guide
Available Languages
Table Of Contents
IP to ATM Class of Service Phase 1 Design Guide
Differentiated Services in Internet/Intranets and IP to ATM CoS
IP Differentiated Services in the Internet and Intranets
IP to ATM CoS for IP Differentiated Services over ATM
Looking Beyond IP to ATM CoS Phase 1
Tag Switching/MPLS Differentiated Services
Detailed IP to ATM CoS Phase 1 Operations
IP to ATM CoS Phase 1 Operations
Protection of Routing and Network Control Protocols
Per-VC Queueing and Back Pressure
Precedence Marking and Selective Discard
WRED/Discard-Bypass for Critical Routing Packets
Selective Packet Discard on Input
IP to ATM CoS Phase 1 Performance and Limitations
Throughput over DS3/E3 interface
Throughput over STM-1/OC-3 Interface
IP to ATM CoS Phase 1 Monitoring
Total Drops on Interface: show interface atm
WRED Intelligent Drops on the VIP: show queueing interface atm
Buffer-Shortage Drops on the VIP: show queueing interface atm
Instantaneous WRED Operation: show queueing interface atm
IP to ATM CoS Phase 1 Fine-Tuning
Where WRED Fine-Tuning Can (and Cannot) Help
Considerations on WRED Fine-Tuning
WRED Fine-Tuning to Reallocate Resources across CoS
Relative per-Precedence WRED Fine-Tuning
Common per-Precedence WRED Fine-Tuning
Exponential Weighting Constant WRED Fine-Tuning
WRED Fine-Tuning with High Numbers of Congested ATM PVCs
IP to ATM CoS Phase 1 Case Studies
Case Study 1: Protection of IP Routing Traffic in a Congested Network
Case Study 2: ISP Offering Premium Differentiated Service
Case Study 3: European ISP Offering Premium Internet Access over Transatlantic ATM Link
Case Study 4: Service Differentiation for Enhanced Multimedia in Enterprise Networks
IP to ATM Class of Service Phase 1 Design Guide
Scope and Audience
The Internet and intranet networks are migrating toward enhanced service offerings and in particular toward support for differentiated quality of service (QoS). This migration represents a key milestone in their continuing phenomenal worldwide success.
Cisco's Internetwork Operating System (Cisco IOS) software is gradually enhanced to offer more and more sophisticated QoS support at higher and higher performance levels. To extend existing IP class of service (CoS) features for operation over an ATM network, the IP to ATM CoS feature is gradually introduced in Cisco IOS software releases.
The IP to ATM CoS feature implements solutions for coarse-grained mapping of QoS between IP and ATM in Cisco router products, using ATM port adapters (PAs) that support ATM traffic shaping and have rich ATM service category support. This category of coarse-grained IP QoS is also often referred to as CoS, hence the name of the feature: IP to ATM CoS.
Phase 1 of the IP to ATM CoS feature was introduced in Cisco IOS 11.1(22)CC.
This document provides guidelines and suggestions for the deployment of the Cisco IOS IP to ATM CoS Phase 1 feature in operational networks. Another software revision is expected to cover Phase 2 of the IP to ATM CoS feature.
This document is meant for technical staff in charge of network architecture and network design. Although some background is provided on IP/Internet QoS, familiarity with IP QoS mechanisms and concepts is generally assumed; references are provided for readers wishing to obtain more information. Familiarity with ATM and ATM QoS concepts is also assumed.
Differentiated Services in Internet/Intranets and IP to ATM CoS
IP Differentiated Services in the Internet and Intranets
Rapid growth in Internet and intranet deployment and usage has resulted in a major shift in both corporate and consumer computing paradigms. This shift has resulted in massive increases in demand for both higher volume of communication and for predictable performance for some existing and emerging applications. However, this demand has often left Internet service providers (ISPs) or intranets with insufficient network capacities to indiscriminately offer predictable performance to all of the traffic. Thus, it became necessary to differentiate among the traffic so that the applications or users requiring (and willing to pay for) predictable performance can be identified and granted the appropriate QoS. In response to this need, Cisco introduced in Cisco IOS Release 11.1 CC new QoS extensions to Cisco IOS software network services. This set of services enables a new "Intelligent Internet" business model wherein ISPs and intranets can generate profitable business growth by rapidly defining, deploying, and charging for differentiated services targeted at specific customer requirements including efficient handling of mission-critical, bandwidth-hungry web applications, and real-time traffic such as Voice over IP or multimedia applications.
A brief overview of the architecture for large scale deployment of differentiated services follows, but details on this architecture and on the individual IP QoS features can be found in the following documents accessible to Cisco's customers and partners on Cisco's Web site, Cisco Connection Online (CCO):
•
White Paper: Advanced QoS Services for the Intelligent Internet
http://www.cisco.com/warp/public/732/net_enabled/qos_wp.htm•
http://www.cisco.com/warp/public/729/c8500/qosio_wp.htm•
http://www.cisco.com/warp/customer/732/netflow/qos_ds.htmillustrates the architecture for differentiated services.
Figure 1 Differentiated Services Architecture
Cisco IOS QoS features provide network operators with the means to distribute network functionality and responsibility between edge functions and backbone functions. This distribution of functionality enables simultaneous performance and services scalability for large scale support of differentiated services (also known as CoS).
At the edge of the network, ISPs gain the capability to do the following:
•
•
•
•
•
The Cisco IOS committed access rate (CAR) feature is one of the key edge features. CAR can perform packet classification, rate measurement, and enforcement as well as precedence marking, all at very high performance.
In the backbone of the network, Cisco IOS QoS and supporting technologies provide the capabilities to do the following:
•
•
•
Random Early Detection (RED) is a technique documented by the IETF and the Internet research community to perform congestion avoidance in an Internet backbone. RED provides network operators with the ability to flexibly specify traffic handling policies to maximize throughput under congestion conditions. RED works in conjunction with robust transport protocols (for example, Transmission Control Protocol [TCP]) to intelligently avoid network congestion by implementing algorithms that do the following:
•
•
•
In short, RED interacts with TCP to anticipate and manage congestion during periods of heavy traffic to maximize throughput through managed packet loss.
Details on RED can be found in the following papers:
•
http://www-nrg.ee.lbl.gov/floyd/red.html•
http://www-nrg.ee.lbl.gov/papers/red/red.htmlWeighted Random Early Detection (WRED) is a Cisco IOS feature that combines IP Precedence and RED congestion management capabilities to provide differentiated performance characteristics for different CoS, thus providing preferential traffic handling for higher priority packets. WRED also provides preferential traffic handling under congestion conditions without exacerbating the congestion.
Thus, WRED is a key IP QoS backbone function for the deployment of IP differentiated services over the Internet or intranets.
Weighted Fair Queueing (WFQ) is another Cisco IOS feature that implements a sophisticated scheduling algorithm that can allocate a configurable share of the link bandwidth to each CoS based on the packet's precedence. As an IP QoS backbone feature, WFQ can be used in combination with WRED, or on its own, for the deployment of IP differentiated services.
IP to ATM CoS for IP Differentiated Services over ATM
The IP to ATM CoS feature extends support of IP differentiated services where the underlying technology for IP transport is ATM. It provides rich and flexible mapping between the IP differentiated service mechanisms into the ATM QoS mechanisms to achieve consistent end-to-end differentiated services where part (or all) of the IP network uses ATM as the underlying transport technology.
With the IP to ATM CoS feature, all congestion is pushed out of the ATM network (because the router only sends traffic out onto the ATM network at a fixed ATM shaping rate). The congestion is thus pushed back onto the routers on the edge of the ATM network that can perform IP-level service differentiation and congestion management in the form of intelligent discard according to the WRED algorithm, taking into account every IP packet's precedence.
The main characteristics of the IP to ATM CoS Phase 1 feature are as follows:
•
•
•
•
•
illustrates IP to ATM CoS Phase 1 operations.
Figure 2 IP to ATM CoS Phase 1 Operations
Because WRED is also supported by Cisco IOS software on technologies other than ATM such as POSIP, serial, Ethernet, Fast Ethernet, FDDI, and so forth, a consistent service differentiation can be deployed end-to-end by Internet/intranet service providers across heterogeneous networks comprising any mix of ATM and other transport technologies.
illustrates where IP to ATM CoS Phase 1 belongs in an end-to-end differentiated service deployed over a heterogeneous network.
Figure 3 IP to ATM CoS Phase 1 Operations in an End-to-End Differentiated Service
Looking Beyond IP to ATM CoS Phase 1
IP to ATM CoS Phase 2
Phase 2 of IP to ATM CoS will expand the IP to ATM CoS feature to add the following:
•
•
•
•
•
illustrates IP to ATM CoS Phase 2 operations.
Figure 4 IP to ATM CoS Phase 2 Operations
Through the support of multiple parallel ATM VCs as a VC bundle, Phase 2 of IP to ATM CoS will allow the service provider, where appropriate, to take more advantage of the ATM QoS to provide stronger service differentiation at the IP layer. For instance, the service provider may want to transport the IP traffic belonging to real-time CoS (such as Voice over IP traffic) on an ATM VC with very strict time constraints such as a CBR or VBR-rt PVC, while transporting the nonreal-time traffic over an elastic ATM ABR PVC, enabling the service provider to efficiently make use of the spare capacity in the ATM network. The service provider could also elect to transport the IP traffic for which no commitment is provided ("best-effort" traffic) over an unspecified bit rate (UBR) PVC, the UBR traffic class being effectively the ATM version of a best-effort service.
12000 IP to ATM CoS
The IP to ATM CoS feature is planned to also be available on the Cisco 12000 series.
IETF Diff-Serv
The IETF has created a working group (Diff-Serv) that is standardizing the concept of IP differentiated services.
The charter of this working group and all the relevant Internet drafts can be found on the IETF Web site: http://www.ietf.org/html.charters/diffserv-charter.html.
The architecture and concepts standardized by Diff-Serv are identical to those supported by Cisco IOS software, but Cisco IOS software is expected to align with any detailed specifications from Diff-Serv that are ratified. Mapping of Diff-Serv over ATM will be maintained by alignment of the IP to ATM CoS feature for support of standardized differentiated services.
Tag Switching/MPLS Differentiated Services
Tag switching is a Cisco technology marrying Layer 2 connection-oriented concepts with Layer 3 connectionless concepts and is being standardized by the IETF as MultiProtocol Label Switching (MPLS).
Tag switching/MPLS offers the following benefits:
•
•
•
•
IP differentiated services are also supported by tag switching/MPLS in a consistent way. The same differentiated architecture applies with packet classification, measurement, and marking being performed on the edge while congestion control and queue management are performed at high performance in the backbone. The main difference is that tag switching first maps the IP Precedence of IP packets into the tag/MPLS CoS field of the tag/MPLS packet and then performs congestion avoidance and queue management based on the tag/MPLS CoS field.
Thus, as large networks migrate to tag switching/MPLS, the IP differentiated services can be very easily maintained and migrated from the current network environment to a full tag/MPLS environment or to a hybrid environment.
Detailed IP to ATM CoS Phase 1 Operations
IP to ATM CoS Phase 1 Operations
To support IP differentiated services using IP Precedence signalling in the parts of the network where ATM is the underlying transport technology, the IP to ATM CoS Phase 1 feature relies on the ATM layer QoS to offer a lossless transport of cells through the ATM network. The feature also relies on the router's awareness of high level priority through the IP Precedence field to perform the actual service differentiation exclusively at the IP layer on the edge of the ATM network.
The router uses ATM PVCs as virtual lossless pipes and performs service differentiation at the point of enqueueing packets onto the lossless ATM PVCs. To enable the ATM network to offer lossless ATM PVCs, the IP to ATM CoS Phase 1 feature makes use of ATM PVCs that are individually shaped by the PA-A3 according to their ATM traffic class of CBR, VBR-rt, VBR-nrt, and ATM traffic parameters. The ATM network is then required to offer a virtually lossless service on these shaped VCs.
Note
The IP to ATM CoS feature will also make use of ABR PVCs when ABR PVCs are supported by the PA-A3. When ABR PVCs are supported by the PA-A3, the ATM switches would have the appropriate buffering and the ABR algorithm so that the ABR PVCs would offer negligible ATM loss.
Note
In situations of congestion, the amount of IP traffic received would be superior to the shaping rate of the supporting VC. Consequently, packets for the congested VC would accumulate in the router. The IP-ATM CoS Phase 1 feature maintains a separate logical queue for each VC (that is, a per-VC queue) so that traffic is backed up independently on every VC based on its own level of congestion. Inside each of these per-VC queues, traffic from all the classes of service would thus be competing for the underlying ATM PVC bandwidth. To implement service differentiation, the IP to ATM CoS Phase 1 feature implements WRED independently on each of the per-VC output queues.
The IP to ATM CoS Phase 1 feature is implemented on the Cisco 7500 series routers as a distributed service on the output interface, which means that the IP to ATM CoS feature is actually performed jointly by the VIP and the PA-A3 supporting the output ATM interface without involvement of the Cisco 7500 Route Switch Processor (RSP). All the IP packets destined to the ATM interface are switched normally by input VIP interface processors (or by the RSP if the input interface is supported by an interface processor, for example, xIP, which does not support distributed switching) and are all forwarded onto the output VIP supporting the ATM interface regardless of their CoS. The output VIP and PA-A3 will then jointly enforce congestion management and service differentiation over all the ATM PVCs.
The VIP and the PA-A3 collaborate in the following ways:
•
•
•
•
•
In summary, the ATM layer functions such as ATM shaping are handled by the PA-A3, while the IP-level service differentiation is performed by the VIP. Through explicit back pressure from the PA to the VIP, the PA operates in a lossless environment and all congestion management and selective drops are performed on the VIP.
illustrates IP to ATM CoS Phase 1 detailed operations.
Figure 5 IP to ATM CoS Phase 1 Detailed Operations
The PA-A3 has a pool of buffers on board dedicated to the storage of packets in the PA-A3 per-VC queues.
The VIP2-50 also has a separate pool of buffers dedicated to storage of packets in the VIP2-50 per-VC queues. The number of buffers available for per-VC queueing on the VIP2-50 depends on the amount of SRAM installed on the VIP. With 8 MB of SRAM on board, up to 1085 packets worth of buffers may be available to the IP to ATM CoS feature for per-VC queueing. It must be noted that a per-VC queue will only develop on the VIP for the ATM PVCs on which there is temporary congestion (that is, there is more incoming IP traffic than the egress ATM shaping rate of the corresponding ATM PVC) and that this queue will only remain on the VIP for the duration of the burst.
Note
Note also that the fraction of VIP SRAM that can be used by the Layer 3 services (such as the IP to ATM CoS feature for per-VC buffering) is expected to be increased, which will result in a higher number of available buffers for the same SRAM configuration on the VIP.
In addition to ensuring that no drop is performed by the PA and, therefore, that all drops can be subject to WRED's selective intelligent discard, implementation of per-VC queueing both on the PA-A3 and on the VIP ensures a strict isolation of ATM PVCs from the congestion viewpoint. In other words, congestion experienced by one ATM PVC will not spill over other uncongested ATM PVCs, so they will not experience induced packet loss.
Note
The IP to ATM CoS Phase 1 solution has the following characteristics:
•
•
•
•
•
•
•
Activating WRED on an ATM PVC
Details on the command-line interface (CLI) for activation and configuration of the IP to ATM CoS Phase 1 feature can be found in the feature module for the IP to ATM CoS feature, which is accessible on CCO at:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/ipatmcs1.htm
With IP to ATM CoS Phase 1, a WRED algorithm can be activated and run independently on each of the VIP-based per-VC queues. The WRED algorithm is activated on a particular PVC by associating a random-detect group to a particular PVC in the atm pvc command:
atm pvc vcd vpi vci aal-encap [[midlow midhigh] [peak average [burst]] [inarp [minutes]] [oam [seconds] [random-detect [group-name]]
The random-detect group specifies the actual parameters of the WRED algorithm to be performed on the particular PVC. Where the same WRED drop profiles and parameters are to be used by multiple ATM PVCs, they can be associated with the same random-detect group, which facilitates configuration by requiring configuration of the WRED parameter only once, regardless of how many ATM PVCs will be using that same set of parameters.
Of course, whether ATM PVCs are associated with the same random-detect group or not, a separate instance of WRED algorithm always is running independently for each VC, with its own set of variables. In particular, a moving average queue size is computed independently for each per-VC queue on the VIP even when multiple VCs are associated with the same random-detect group. Note, however, that for each per-VC queue a single moving average is computed across all precedence values (that is, taking into account arrival of packets of any CoS).
Configuring WRED Parameters
The service differentiation is controlled by configuring different WRED drop probability parameters for each precedence for each random-detect group.
To configure the WRED parameters of a random-detect group, use the random-detect group command to enter random-detect group configuration mode:
random-detect group group-name
Subcommands of the random-detect group configuration mode can then be used to configure the WRED parameters for that particular random-detect group:
•
exponential weighting constant
•
precedence precedence min-threshold max-threshold mark-probability-denominator
A WRED configuration that provisions all precedences with the same thresholds and mark-probability-denominator will display an egalitarian drop behavior and will be in fact performing a standard RED congestion management algorithm. It is only by varying the drop probability parameters of a certain precedence against others that a corresponding priority for that precedence traffic can be provided.
Switching Mode
The IP to ATM CoS feature is supported by Cisco Express Forwarding (CEF) switching mode and operates in a distributed mode only. Thus Distributed CEF (DCEF) must be enabled on the ATM interface running the IP to ATM CoS feature. DCEF is enabled using the ip cef distributed command in global configuration mode.
VC Type
The IP to ATM CoS feature supports ATM PVCs. ATM switched virtual circuits (SVCs) are not supported.
Supported ATM Traffic Classes
The IP to ATM CoS feature supports all the ATM traffic classes supported by the PA-A3.
With IP to ATM CoS Phase 1, the PA-A3 supports ATM shaping on ATM PVCs of the following ATM traffic classes:
•
•
•
•
Note
ATM shaping on a CBR ATM PVC is achieved on the PA-A3 by configuring the average rate and the peak rate to the same bandwidth when the atm pvc command is issued. Configuring them for the same bandwidth will result in an ATM shaping with constant intercell gap, which is characteristic of CBR shaping.
The IP to ATM CoS Phase 1 feature can also be configured to run on a UBR PVC. However, because lossless operation is required from the ATM network (because the ATM network is not aware of the various classes of differentiated service and would perform indiscriminate loss), configuring IP to ATM CoS on a UBR PVC would only be useful in the very particular case where the ATM network is so underutilized that UBR connections can be assumed to be lossless. If that was the case, WRED should still be activated on the UBR PVC because it is possible that a queue may build up in the router on a UBR PVC.
ATM Shaping
The PA-A3 supports very accurate ATM traffic shaping in accordance with the Generic Cell Rate Algorithm (GCRA) documented in the ATM Forum Traffic Management Specification 4.0. It supports the following shaping parameters:
•
•
•
The granularity of the PA-A3 ATM traffic shaping (the difference between the two closest consecutive achievable effective shaping rates) is less than 0.02 percent for PCR around 10 Mbps and is less than 0.25 percent for PCR around 100 Mbps.
The PA-A3 ATM traffic shaping accuracy (the difference between the configured average rate and the measured effective SCR) is less than 0.3 percent for SCR rates around 100 Mbps.
It must be noted that the difference between the effective shaping rate and the configured shaping rate may be either positive or negative. In other words, depending on the configured shaping rate, the effective shaping rate actually achieved by the PA-A3 will in some cases be slightly lower than the configured rate and in some cases be slightly higher than the configured rate.
In the cases where the effective shaping rate is higher than the configured rate, it is essential that the ATM PVC be configured throughout the ATM network with a PCR/SCR that is at least as high as the effective shaping rate, rather than just the configured rate. In particular, if the ingress ATM switch performs an ATM policing function, this policing must be configured to accept traffic up to the effective shaping rate of the PA-A3; failure to do so could result in systematic dropping of cells by the policing function, which would compromise the IP to ATM CoS operation that relies on lossless ATM PVCs. Similarly, the ATM switches must allocate a bandwidth at every hop that corresponds to the PA-A3 effective shaping rate; failure to do so could result in ATM switches dropping cells on the ATM PVC because, for example, their per-VC queue would be growing due to an incoming cell rate higher than expected. Such behavior would again compromise the IP to ATM CoS operation. It is thus recommended that values for the ATM PVC traffic parameters (SCR/PCR) for policing, scheduling, and resource allocation be configured on the ATM switches that are slightly higher than the corresponding values configured on the router for shaping; this safety margin will enable the ATM network to guarantees lossless operation at the effective cell rate on the ATM PVC.
Subinterface Type
The IP to ATM CoS feature supports both multipoint and point-to-point subinterfaces.
Encapsulations
The IP to ATM CoS Phase 1 feature supports aal5snap and aal5mux encapsulations.
Address Resolution
The IP to ATM CoS Phase 1 feature supports both static map (with the map-group and map-list commands) and ATM Inverse ARP (with the inarp keyword in the atm pvc command) for the next hop protocol address resolution.
When the atm pvc command is issued with the inarp keyword, Cisco IOS software will send an InARP request as per RFC 1293 for the protocols configured in the interface. It will also respond to InARP requests from the remote end if that protocol is configured on that interface. The requests are responded to only if the request is from the same network as the router and all other requests are silently discarded. The InARP mappings are aged out and periodic requests are issued to refresh the map table.
Monitoring of PVC Status
The ATM OAM features supported in Cisco IOS software can be used for monitoring the status of the PVC when deploying the IP to ATM CoS feature.
In conjunction with the IP to ATM CoS Phase 1 feature, Cisco IOS software supports the following ATM OAM features for monitoring the status of ATM PVCs:
•
•
•
Note
The PVC Management feature with the IP to ATM CoS Phase 2 feature will provide immediate notification to the routing layer of any change in the PVC status and whatever triggered the PVC status change, such as detection of AIS/RDI or continuity checking through OAM loopback cells. Immediate notification will result in optimum rerouting speed in case of PVC failure.
Detection of AIS or RDI by the router will result in the ATM PVC being recognized as inactive by the ATM layer. However, this information is not explicitly communicated to the routing layer. Consequently rerouting will take place through detection of PVC failure by the routing protocol's polling/keepalive mechanisms. With the IP to ATM CoS Phase 1 feature, rerouting time on ATM PVC failure is thus determined entirely by the routing protocol.
WRED and Non-IP Traffic
With the IP to ATM CoS Phase 1 feature, non-IP packets are subjected to the WRED algorithm and treated exactly like IP packets with precedence 0. In other words, non-IP packets are taken into account when computing the WRED average queue length and a drop decision is made for every non-IP packet using the WRED drop profile of IP precedence 0 traffic (that is, precedence 0's min-threshold, max-threshold, and mark-probability-denominator).
It must be noted that when the WRED configuration is set up for decreasing drop probabilities as the precedence increases, non-IP traffic will be experiencing the lowest QoS enforced by WRED. In other words, non-IP traffic will be as likely to be dropped as IP best-effort traffic and is more likely to be dropped than any IP packet with non-0 precedence.
If non-IP traffic is set up for a QoS different than IP's best-effort traffic (for example, if the non-IP traffic experiences a higher QoS than IP best-effort), then IP best-effort traffic could be transported on the IP backbone using a precedence value different from 0 (for example, precedence 2). The WRED discard profile could then be configured and tuned separately for non-IP traffic (by configuring precedence 0's WRED parameters) and for IP best-effort (by configuring precedence 2's WRED parameters). Note also that even if the default configuration of WRED defines decreasing drop probability profiles as the precedence increases, the drop profile parameters of each precedence can be configured without any relative order so that precedence 0's discard profile can be configured to offer the highest QoS if this is deemed desirable for non-IP traffic.
Note
WRED and Multicast/Broadcast
The IP to ATM CoS feature is compatible with the Cisco IOS pseudobroadcasting that performs router-based replications of multicast/broadcast packets over ATM PVCs that have been declared as part of the pseudobroadcast domain by the broadcast keyword in the map-list statement.
The IP to ATM CoS Phase 1 feature enforces the same precedence-based service differentiation on IP multicast/broadcast packets as on IP unicast packets. An IP multicast/broadcast packet is treated by per-VC WRED exactly like a unicast IP packet of the same precedence.
Non-IP multicast packets are subject to per-VC WRED and subject to the IP precedence 0 discard profile.
Protection of Routing and Network Control Protocols
Ensuring integrity of routing protocol operations when deploying differentiated services over ATM is of paramount importance. It is not very useful for a router to allocate all resources to important data traffic if this allocation results in loss of important routing traffic and thus affects routing stability. Consequently, the IP to ATM CoS scheduling and discarding mechanisms implemented to prioritize important data make special provisions to guarantee that routing protocols have appropriate access to resources in order to maintain routing operations while still offering the required QoS to important data traffic.
The following sections describe several mechanisms that cooperate with the IP to ATM CoS Phase 1 feature to achieve very strong protection of routing protocols while offering IP differentiated services:
•
•
•
•
A case study also follows that illustrates a design for protection of routing protocols in a congested network.
The same mechanisms are also used to protect a number of network control messages that are necessary for network stability and integrity (such as ATM Inverse ARP).
Per-VC Queueing and Back Pressure
Per-VC queueing and back pressure mechanisms were described earlier. In the context of routing protection, per-VC queueing ensures that a congested VC does not result in a shortage of buffers on another VC, therefore preventing the congestion from spilling across VCs; routing traffic in uncongested VCs cannot be subject to drop because of congestion on another VC. Back pressure ensures that the VIP is notified of an increase or decrease of output VC queues on the PA before overflow or underflow occurs in that output VC queue. This means that no indiscriminate drop will occur on the PA-A3 and that the WRED selective discard mechanism running on the VIP can take into account the fact that a packet may be an important routing packet and thus should not be discarded.
This mechanism applies to IP and to non-IP routing protocols.
Precedence Marking and Selective Discard
As per the IP specification RFC 791, routing and network control packets may be flagged in the network to facilitate preferential treatment of those packets by routers. The packets are flagged by setting the Precedence field inside the IP type of service (ToS) octet to particular values (precedences 6 and 7). Figure 6 shows the placement of the Precedence field in the ToS octet and lists the corresponding precedence values. The network control and internetwork control precedences (7 and 6) are used in many networks running on Cisco routers, allowing easy identification of routing traffic so that it can be protected (for example, by Cisco IOS output scheduling mechanisms or Cisco IOS selective packet discard), which contributes to network stability in case of intense route fluctuations.
Note
Figure 6 ToS Octet
Routing packets generated by Cisco routers are marked with precedence 6. At the time these packets are enqueued, and consequently have gone through the WRED algorithm, the routing packets will experience a selective discard with very low loss probability (based on the WRED parameters for precedence 6).
We recommend you not use precedence 6 and 7 for any data traffic (that is, data traffic should only use precedences 0 to 5) so that routing traffic can always be easily identified and treated accordingly.
In the case where the network administrator modifies the WRED parameters from their default values for an ATM VC, we strongly recommend you ensure that the WRED parameters yield a very low loss probability for packets with precedence 6 and 7.
This mechanism applies to IP routing protocols only.
WRED/Discard-Bypass for Critical Routing Packets
The IP and non-IP routing protocol packets generated by the router and that are most critical to the stability of the routing protocol (such as link-state peer/adjacency keepalives/hellos) are flagged inside the router. Those packets are then treated with extreme care at any buffering stage and given the highest priority in terms of discard. In particular, these packets bypass the WRED discard algorithm and are never dropped. Consequently, even if the WRED parameters were not properly tuned to the network environment or if the IP traffic was not backing off as expected in response to the WRED discards, the critical routing packets would still be transmitted and the routing protocol would stay up.
This mechanism applies to IP routing protocols and non-IP routing.
Selective Packet Discard on Input
The three mechanisms just described for protection of routing traffic ensure that routing packets are protected from discard on output from the router toward the ATM network. Cisco IOS software also includes a feature called selective packet discard (SPD) ensuring protection of routing on input on a router. When enabled, the SPD feature ensures that, in situations where the router is receiving more packets than it can process, the router will selectively discard nonrouting packets and protect incoming routing packets to guarantee integrity of routing exchange and stability of the routing protocol.
This feature is particularly useful when cache-based switching modes are in use on the router because in case of major topology changes in the network, cache invalidation would result in a surge of packets requiring process switching, which in turn increases CPU load and packet backlog on input for processing if packets arrive faster than the CPU can handle them. In these particular situations, input congestion could result in lost routing packets. Because the IP to ATM CoS feature operates with CEF/DCEF switching, topology changes do not trigger cache invalidation and thus do not result in CPU load increase nor in input congestion. SPD is thus not expected to be required when the IP to ATM CoS feature is used.
However, SPD might still be useful to protect routing protocol integrity in very particular situations where the router CPU is heavily loaded (for instance because of a malicious attack whereby a large amount of traffic is addressed to the router CPU itself). In those situations, SPD would ensure that routing packets arriving on the router would not be discarded regardless of the volume of incoming traffic addressed to the router.
VIP Requirements
The IP to ATM CoS Phase 1 feature requires a VIP2-50 model for the VIP interface processor.
Because the IP to ATM CoS feature maintains a per-VC queue for each VC on the VIP, these queues are used simultaneously on all the VCs to absorb temporary bursts and to store early congestion traffic until the sources react to the WRED drops and adapt their transmission rate. We recommend use of a larger SRAM configuration (8 MB) when multiple ATM PVCs are expected to encounter congestion simultaneously.
IP to ATM CoS Phase 1 Performance and Limitations
Throughput
The IP to ATM CoS Phase 1 feature operates at a high rate. Details regarding throughput are provided in the following paragraphs.
Throughput over DS3/E3 interface
When an ATM DS3/E3 interface is used, activating the IP to ATM CoS Phase 1 feature does not reduce the no-drop rate achieved by the VIP2-50/PA-A3, which remains at the interface line rate with typical Internet packet size distribution such as IMIX traffic, even with a high number of ATM VCs (for example, 200 PVCs).
Note
Note
Throughput over STM-1/OC-3 Interface
When an STM-1/OC-3 interface is used with IMIX traffic, activating the IP to ATM CoS Phase 1 feature does not significantly reduce the maximum no-drop rate achieved by the VIP2-50/PA-A3 on the ATM STM-1/OC-3 interface.
Activating the IP to ATM CoS Phase 1 feature on a small number of ATM PVCs will not reduce the no-drop rate with IMIX traffic. The IP to ATM CoS Phase 1 feature then achieves a no-drop rate throughput of 88 percent of the STM-1/OC-3 ATM line rate.
Activating the IP to ATM CoS Phase 1 feature simultaneously over 50 ATM PVCs will degrade the no-drop rate with IMIX traffic by 2 percent. The IP to ATM CoS Phase 1 feature then achieves a no-drop rate throughput of 84 percent of the STM-1/OC-3 ATM line rate.
Activating the IP to ATM CoS Phase 1 feature simultaneously over 200 ATM PVCs will degrade the no-drop rate with IMIX traffic by 10 percent. The no-drop rate achieved by the STM-1/OC-3 ATM line rate will be 76 percent.
Note
The difference between the no-drop rate and the saturation throughput under persistent extreme overload is smaller when the IP to ATM CoS Phase 1 feature is activated than when it is not. This means that even in abnormal situations where the traffic sources do not back off as expected in reaction to WRED discards and they keep sending traffic significantly in excess of the throughput achievable through the network, the IP to ATM CoS Phase 1 feature does not introduce additional risks of performance collapse.
Note
Consequently, activating the IP to ATM CoS Phase 1 feature to take advantage of service differentiation and congestion avoidance is not expected to introduce a risk of compromising the network performance such as in reducing the no-drop rate or in creating a bottleneck that did not exist prior.
Number of PVCs with WRED
It is possible to configure per-VC WRED simultaneously over any number of ATM PVCs existing on the ATM interface. Regardless of the number of ATM PVCs configured with per-VC WRED and regardless of the level of simultaneous congestion on those PVCs, the back pressure mechanism of the PA-A3 will ensure that packets never need be indiscriminately dropped by the PA-A3, but rather that the necessary drops be performed on the VIP2-50 running the WRED algorithm.
Note
The following must be noted:
•
•
•
Consequently, if excessive congestion was occurring on a very high number of ATM PVCs at the very same point in time, the IP to ATM CoS Phase 1 feature could run out of VIP buffers for performing its selective random drop with full effectiveness on all VCs.
Note
VIP2-50 devices with large SRAM are thus strongly recommended in designs with a high number of ATM PVCs running per-VC WRED and that can experience congestion simultaneously.
The higher the number of configured active PVCs, the lower their SCR would need to be, and consequently the shorter the queue required by WRED to operate on the PVC. Thus, as is the case when using the default WRED profiles of the IP to ATM CoS Phase 1 feature, configuring lower WRED drop thresholds when per-VC WRED is activated on a very large number of low-speed congested ATM PVCs would minimize the risk of buffer shortage on the VIP.
Note
Full dynamic sharing of the VIP buffers across all per-VC queues allows maximum efficiency in the use of the available buffers. The buffers can be used at any time by any per-VC queue needing to absorb a burst of traffic. This dynamic sharing ensures that any PVC experiencing congestion at any point in time will have access to any required number of available buffers.
It must also be noted that the no-drop rate slightly decreases as the number of ATM PVCs increases. Refer to the "Throughput" section for information on the no-drop rate measured for various numbers of PVCs over IMIX traffic.
Single PA-A3 per VIP2-50
The IP to ATM CoS Phase 1 feature allows a single PA-A3 per VIP2-50.
IP to ATM CoS Phase 1 Monitoring
Total Drops on Interface: show interface atm
To learn the total number of packets that have been dropped on output on an ATM interface, use the show interface atm command.
7513-1-31# show interface atm 11/0/0ATM11/0/0 is up, line protocol is upHardware is cyBus ENHANCED ATM PAMTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec, rely 255/255, load 1/255Encapsulation ATM, loopback not set, keepalive not setEncapsulation(s): AAL5 AAL3/44096 maximum active VCs, 8 current VCCsVC idle disconnect time: 300 secondsLast input 00:00:00, output 00:00:00, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 801870 drops; input queue 0/75, 0 drops30 second input rate 19000 bits/sec, 1 packets/sec30 second output rate 22000 bits/sec, 2 packets/sec4072808 packets input, 757905093 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants0 input errors, 0 CRC, 0 frame, 0 overrun, 1225 ignored, 0 abort3672469 packets output, 260485571 bytes, 0 underruns0 output errors, 0 collisions, 0 interface resets0 output buffers copied, 0 interrupts, 0 failures7513-1-31#"Output" drops indicate the total aggregate of all drops on output (VIP WRED discard, VIP discard because of VIP buffer shortage, discard on the PA, and so forth).
Drops on the PA: show atm vc
To learn the number of packets that have been dropped by the PA on output on an ATM interface on a per-VC basis, use the show atm vc command.
Note that in normal operations with the IP to ATM CoS feature, there should be no drops on the PA because the PA provides back pressure to the VIP so that congestion is pushed back from the PA to the VIP, which can perform WRED selective discard on a per-VC basis.
7513-1-31# show atm vc 100ATM11/0/0.100: VCD: 100, VPI: 5, VCI: 100, etype:0x0, AAL5 - LLC/SNAP, Flags: 0xC0030PeakRate: 16000, Average Rate: 8000, Burst Cells: 512, VCmode: 0x0OAM DISABLED, InARP frequency: 15 minute(s)InPkts: 135, OutPkts: 134, InBytes: 9416, OutBytes: 9256InPRoc: 135, OutPRoc: 0, Broadcasts: 133InFast: 0, OutFast: 0, InAS: 0, OutAS: 1InPktDrops: 0, OutPktDrops: 0CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0OAM F5 cells sent: 0, OAM cells received: 0Status: ACTIVE7513-1-31#"OutPktDrops" keeps track of the packet drops performed by the PA because of the per-VC queue on the PA being congested and running out of buffers.
WRED Intelligent Drops on the VIP: show queueing interface atm
To learn the number of packets that have been selectively dropped by the WRED algorithm on the VIP on a per-VC basis, use the show queueing interface atm command.
7513-1-31# show queueing interface atm 11/0/0.103VC 5/103 -ATM11/0/0.103 queue size 46packets output 1346100, drops 134315, nobuffer drops 0WRED: queue average 44weight 1/512, max available buffers 1021Precedence 0: 40 min threshold, 81 max threshold, 1/10 mark weight1344366 packets output, drops: 134304 random, 10thresholdPrecedence 1: 45 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 2: 50 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 3: 55 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 4: 60 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 5: 65 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 6: 70 min threshold, 81 max threshold, 1/10 mark weight1734 packets output, drops: 1 random, 0 thresholdPrecedence 7: 75 min threshold, 81 max threshold, 1/10 mark weight(no traffic)"Random" and "threshold" drops indicate for each precedence how many packets have been discarded by the WRED algorithm:
•
•
Buffer-Shortage Drops on the VIP: show queueing interface atm
In some exceptional situations, the output VIP could have no buffers left to store a packet that is switched to this output VIP from the RSP or from an input VIP. Consequently, the VIP will need to indiscriminately drop that packet regardless of its precedence.
Such an exceptional situation could occur as a result of heavy congestion combined with misconfiguration of the WRED parameters. As an example, if the exponential weighting constant has been reconfigured from the default value to an excessively large value, then the WRED algorithm is slow to react to congestion (because the moving average increases only slowly as the instantaneous queue fills up) and WRED may not start intelligent discard early enough, so that the bursts keep filling the buffers.
Such situations should be avoided because these drops indiscriminately affect high precedence traffic.
Drops on the VIP due to buffer shortage can be monitored through the show queueing interface atm command through the "nobuffer drop" counter.
7513-1-31# show queueing interface atm 11/0/0.103VC 5/103 -ATM11/0/0.103 queue size 46packets output 1346100, drops 134315, nobuffer drops 0WRED: queue average 44weight 1/512, max available buffers 1021Precedence 0: 40 min threshold, 81 max threshold, 1/10 mark weight1344366 packets output, drops: 134304 random, 10 thresholdPrecedence 1: 45 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 2: 50 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 3: 55 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 4: 60 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 5: 65 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 6: 70 min threshold, 81 max threshold, 1/10 mark weight1734 packets output, drops: 0 random, 1 thresholdPrecedence 7: 75 min threshold, 81 max threshold, 1/10 mark weight(no traffic)"Nobuffer drops" indicate how many packets have been dropped indiscriminately by the VIP because no buffer was available at that time to accept the packet when it was handed over to the output VIP by the RSP or the VIP that received the packet. Because the VIP drops the packet without being able to run the IP to ATM CoS feature, and in fact without even looking at the packet at all, such packets are dropped irrespective of the moving average queue occupancy for the particular VC and irrespective of the packet precedence.
Instantaneous WRED Operation: show queueing interface atm
The show queueing interface atm command can also be used to learn how many total buffers are available in the VIP buffers for the WRED algorithm for a particular VC, and to learn the instantaneous value of the real buffer queue length and the instantaneous WRED average queue length.
7513-1-31# show queueing interface atm 11/0/0.103VC 5/103 -ATM11/0/0.103 queue size 46packets output 1346100, drops 134315, nobuffer drops 0WRED: queue average 44weight 1/512, max available buffers 1021Precedence 0: 40 min threshold, 81 max threshold, 1/10 mark weight1344366 packets output, drops: 134304 random, 10 thresholdPrecedence 1: 45 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 2: 50 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 3: 55 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 4: 60 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 5: 65 min threshold, 81 max threshold, 1/10 mark weight(no traffic)Precedence 6: 70 min threshold, 81 max threshold, 1/10 mark weight1734 packets output, drops: 1 random, 0 thresholdPrecedence 7: 75 min threshold, 81 max threshold, 1/10 mark weight(no traffic)"Queue size" indicates the number of packets buffered on the VIP in the per-VC queue corresponding to that VC at the time the show command was run.
"Queue average" indicates the instantaneous value of the moving average queue length computed by WRED for that particular VC at the time the show command was run.
"Max available buffers" indicates the number of packet buffers that are available on the VIP and can be dynamically used by all the IP to ATM CoS per-VC queues.
IP to ATM CoS Phase 1 Fine-Tuning
Where WRED Fine-Tuning Can (and Cannot) Help
As discussed earlier, the main goal of WRED is to achieve service differentiation across various CoS identified by the IP Precedence. Thus, WRED enables the network operator to achieve different performance and QoS objectives for each CoS. For example, the objectives for each CoS can include different levels of parameters such as the drop probability and the bandwidth achieved through the network by a TCP-compliant flow; these parameters could be defined in various ways in time (for example, average over some long-term period, average across the busy hour), in various ways in topology (for example, across all users, across some specific user population), and in various statistical ways (across all the traffic, across a representative set of flows).
Note
A number of network-wide inputs can be used by the network operator to determine whether WRED enforces the required level of service for each precedence. These inputs include the results of a per-precedence network performance measurement campaign, the information provided by a per-precedence service level agreement monitoring tool, or the WRED per-precedence discard statistics provided by the Cisco IOS show queueing interface atm command.
If these inputs reveal that the performance and QoS experienced by some classes of service is below their respective objectives, while the performance and QoS experienced by other classes of service is above their respective objectives, it is most likely that WRED fine-tuning can help. WRED's service differentiation can be tuned to reallocate network resources across the classes of service so that the underserviced CoS can be more favored by WRED at the expense of the overserviced CoS. See the section "WRED Fine-Tuning to Reallocate Resources across CoS" for more recommendations on this fine-tuning.
If these inputs reveal that the performance and QoS are below the respective objectives for all classes of service, then the level of traffic is probably simply too high compared to the resources available in the network to satisfy all CoS objectives. WRED fine-tuning likely will not help. Either the objectives should be loosened for some classes of service or more resources need to be deployed in the network.
Note
Considerations on WRED Fine-Tuning
Because of the dynamic nature of RED and WRED and their complex interactions with transport level flow control mechanisms (such as TCP flow control), fine-tuning WRED to achieve specific IP service differentiation objectives in particular operating conditions is a delicate exercise and great caution is recommended. We recommend you start operations or testing with the default WRED settings (or from configurations close to the WRED default settings) and fine-tune from there. Modifications to WRED parameters should be tested and validated under a vast range of network conditions before being deployed in a large network.
The default WRED settings take into account the following:
•
•
•
For these reasons we believe that the default WRED settings will provide a robust base to start from when deploying IP service differentiation over ATM (see the section "Default WRED Configuration").
Because higher rate ATM PVCs must cope with larger bursts, we recommend you not apply the same WRED profile (that is, the same random-detect group) to all VCs if they have vastly different rates. However, fine-tuning of WRED parameters for each different ATM PVC rate is neither required nor practical. We therefore suggest you make extensive use of the ability to associate the same random-detect group to multiple VCs and only define a few random-detect groups, each being applied to all the VCs belonging to a range of VC rates (for instance the "slow VCs," the "medium VCs," and the "fast VCs"). Then it is only necessary to fine-tune a few random-detect groups to achieve fine-tuning across all VCs.
For each random-detect group, it is expected that to achieve particular service differentiation objectives in a particular environment, only minor modifications of per-precedence parameters from the default values would be required (see the sections "Relative per-Precedence WRED Fine-Tuning" and "Common per-Precedence WRED Fine-Tuning"). We do not expect this configuration to normally require major modifications of the per-precedence parameters from the default values, nor do we expect that modification of the WRED exponential weighting to be required (see the section "Exponential Weighting Constant WRED Fine-Tuning").
General recommendations on RED setting can be found in the paper by Sally Floyd defining RED gateways (Random Early Detection Gateways): http://www.aciri.org/floyd/red.html.
Additional brief discussions on RED parameter settings are also available from Sally Floyd's web site at http://www.aciri.org/floyd/REDparameters.txt.
Default WRED Configuration
Using the atm pvc ... [random-detect [group_name]] command to associate to an ATM PVC a random-detect group without a group name, or with a group name whose WRED parameters have not been further configured through the random-detect group group-name command, results in a set of default WRED parameters being applied to the ATM PVC.
The default values allocate the same max-thresholds and the same mark-probability to all the precedences. However, the default min-threshold is different for every precedence: the higher the precedence, the higher the min-thresholds. Consequently the default WRED configuration offers an increasingly "better" service to higher precedences.
As indicated previously, these default values take into account the ATM shaping parameters associated with the VC. To accommodate for larger bursts that can appear at higher rates, the higher the VC shaping rate the larger the default min- and max-thresholds. For instance, with a 10-kbps ATM, here are the default WRED parameters applied to the VC in a particular router:
nf-7505-1# show runinterface ATM1/1/0.47 point-to-pointatm pvc 47 0 47 aal5snap 10 10 1 random-detect wredgroup1nf-7505-1# show queueing redVC 0/47 -random-detect group default:exponential weight 9precedence min-threshold max-threshold mark-probability---------------------------------------------------------------0: 20 40 1/101: 22 40 1/102: 24 40 1/103: 26 40 1/104: 28 40 1/105: 30 40 1/106: 32 40 1/107: 34 40 1/10In comparison, here are the default WRED parameters applied by the same router to a VC shaped at 9 Mbps of SCR and 10 Mbps of PCR:
nf-7505-1# show runinterface ATM1/1/0.49 point-to-pointatm pvc 49 0 49 aal5snap 10000 9000 100 random-detect wredgroup3nf-7505-1# show queueing redVC 0/49 -random-detect group default:exponential weight 9precedence min-threshold max-threshold mark-probablity---------------------------------------------------------------0: 72 144 1/101: 81 144 1/102: 90 144 1/103: 99 144 1/104: 108 144 1/105: 117 144 1/106: 126 144 1/107: 135 144 1/10WRED Fine-Tuning to Reallocate Resources across CoS
Relative per-Precedence WRED Fine-Tuning
In most environments the per-precedence WRED fine-tuning described in this section will be the only fine-tuning required to achieve specific IP service differentiation objectives (such as per-precedence service level agreements with different packet loss commitments).
In addition, in most environments we expect only minor modifications over the per-precedence WRED default values to be required.
Per-precedence WRED fine-tuning refers to adjustment to the three WRED parameters configurable on a per-precedence basis to shuffle resource allocation across CoS. Those per-precedence parameters are min-threshold, max-threshold, and mark-probability.
For instance, consider a situation where the default (or current) WRED parameters are the following:
nf-7505-1# show queueing redVC 0/49 -random-detect group default:exponential weight 9precedence min-threshold max-threshold mark-probablity---------------------------------------------------------------0: 72 144 1/101: 81 144 1/102: 90 144 1/103: 99 144 1/104: 108 144 1/105: 117 144 1/106: 126 144 1/107: 135 144 1/10The network administrator may want to configure the following:
•
•
•
•
The updated WRED parameters for the corresponding random-detect group would then look like the following:
nf-7505-1# show queueing redVC 0/49 -random-detect group wredgroup3:exponential weight 9precedence min-threshold max-threshold mark-probability---------------------------------------------------------------0: 72 133 1/81: 81 144 1/102: 90 144 1/103: 99 144 1/104: 108 144 1/105: 117 144 1/106: 135 155 1/1007: 135 155 1/100Common per-Precedence WRED Fine-Tuning
Common per-precedence WRED fine-tuning refers to the action of modifying the per-precedence WRED parameters to make the discard more aggressive across all precedences (or less aggressive across all precedences) rather than to modify these parameters to change the relative allocation of resources among the precedences as described previously.
Common per-precedence WRED fine-tuning may be required in situations where a significant number of drops occur on the VIP because of buffer shortage (see the earlier section "Instantaneous WRED Operation: show queueing interface atm") and some classes of service experience lower QoS than their corresponding objectives.
Note
When a VIP is experiencing a buffer shortage, you can modify the WRED parameters to enforce more aggressive discard across all the precedences by reducing the min- and max-thresholds for all (or a significant subset of) precedences (and perhaps also by increasing the mark weight). Such a common per-precedence WRED fine-tuning should be useful in an environment where a high number of ATM PVCs are running WRED and are simultaneously experiencing congestion.
Note
Exponential Weighting Constant WRED Fine-Tuning
We recommend you not modify the exponential weighting constant. We do not expect the fine-tuning guidelines provided in this section to be commonly required. Modifying the exponential weighting constant should only be performed with great care and if you have very clearly determined that your applications would benefit from the changed values.
The WRED average queue size computation is based on the previous average and the current size of the queue. The formula is as follows:
average = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)where n is the exponential weighting constant specified in the exponential weighting constant subcommand of the random-detect group command. Thus, the higher the factor, the more dependent the average is on the previous average.
The default exponential weighting constant value of 9 was chosen based on the best current RED expertise available.
For high values of n, the previous average becomes more significant in the moving average calculation. A large factor smooths out the peaks and lows in queue length. The average queue size is unlikely to change very quickly, avoiding drastic swings in size. The WRED process will be slow to start dropping packets, but it may continue dropping packets for a time after the actual queue size has fallen below the minimum threshold. The slow-moving average will accommodate temporary bursts in traffic.
If the value of n gets too high, WRED will not react to congestion. Packets will be transmitted or dropped as if WRED were not in effect because there will be a shortage of buffers before the WRED algorithm starts performing selective discard across the CoS. The result could be indiscriminate drops across all CoS, which in turn may prevent the network from achieving the performance and QoS objectives of the most stringent CoS. The result also could be the undesirable TCP synchronization phenomenon sometimes observed with FIFO queueing. In this situation, many TCP sources back off simultaneously when there is a heavy drop caused by buffer shortage. They then reopen their windows gradually at the same time, until eventually there is another buffer shortage, and they back off together again.
In situations where there is a significant number of drops due to buffer shortage on a VIP (see the earlier section "Buffer-Shortage Drops on the VIP: show queueing interface atm"), it may not be obvious whether modification of the per-precedence WRED parameters is required across all or most precedences (see the section "Common per-Precedence WRED Fine-Tuning") or whether modification of the exponential weighting constant is required. The following suggestions are provided based on monitoring the WRED instantaneous operations at critical times (see the earlier section "Instantaneous WRED Operation: show queueing interface atm").
If the queue size is often high while the average queue remains low compared to the min-thresholds configured for the precedences carrying the bulk of the traffic, then the average queue length likely is not tracking the congestion fast enough and reducing the exponential weighting to allow the moving average to adjust faster to congestion is advised (that is, increase instantaneous queue size).
If the queue size is often very low while the average queue remains high beyond min- and max-thresholds for the precedences carrying the bulk of the traffic, then the average queue length likely is not tracking the congestion disappearance fast enough. Reducing the exponential weighting to allow the moving average to adjust faster to congestion is advised (that is, increase instantaneous queue size).
For low values of n, the average queue size closely tracks the current queue size. The resulting average may fluctuate quickly with changes in the traffic levels. In this case, the WRED process responds quickly to congestion (that is, to small increases in queue length) and starts dropping packets as soon as small bursts of traffic are detected.
If the value of n gets too low, WRED will overreact to temporary traffic bursts and drop traffic unnecessarily, essentially preventing WRED from accepting normal traffic bursts for which it actually has physical buffering capacity. This overreaction will result in unnecessarily reducing the performance and QoS observed across all CoS.
WRED Fine-Tuning with High Numbers of Congested ATM PVCs
As described earlier in the section "IP to ATM CoS Phase 1 Performance and Limitations," the VIP may not have enough buffers to maintain a long per-VC queue for all the VCs simultaneously in the special cases where a very high number of ATM PVCs are configured with per-VC WRED and where a very high number of them can simultaneously experience congestion. In this particular situation, adjusting the WRED drop profile so that WRED starts dropping earlier on shorter average queue occupancy (that is, reducing min-threshold and also perhaps max-threshold) may be beneficial in allowing faster WRED reaction on all VCs.
IP to ATM CoS Phase 1 Case Studies
Case Study 1: Protection of IP Routing Traffic in a Congested Network
This case study presents an IP network design where a single level of service is supported for data traffic but where routing traffic is protected over user data in case of congestion.
The main design goals are as follows:
•
•
illustrates the network topology for this case study.
Figure 7 Network Topology for Case Study 1
In this design, the data traffic is transported as precedence 0. We strongly recommend you re-mark all traffic coming from outside of the network with precedence 0 to ensure that packets are not injected inadvertently or maliciously into the network with their precedence set to 6 or 7, in which case they would be "stealing" high-quality service and would be threatening the routing traffic integrity. In this design CAR is used on the edge of the network to perform re-marking of external traffic.
IP routing protocol messages are always generated by Cisco routers with precedence 6, which does not require any configuration action.
As described earlier, routing protocols are protected through per-VC queueing and back pressure, through selective discard, and through WRED/discard-bypass for critical routing packets. In this case study, the IP to ATM CoS Phase 1 selective discard mechanism of per-VC WRED is configured by setting the WRED discard profiles on every VC so that precedences 6 and 7 will experience a much lower drop probability than the data traffic.
Rpe1 Configuration
Rpe1 is a provider edge router. It is a router from the service provider network that sits on the edge and directly connects to routers on the customer premises. Every interface that receives packets from outside the service provider network (that is, from customer premises routers) performs re-marking of the precedence to 0.
ip cef distributed!interface Hssi3/0/0description Edge interface connecting to a CPEip address 192.168.10.1 255.255.255.0rate-limit input 10000000 24000 24000conform-action set-prec-transmit 0 exceed-action set-prec-transmit 0no ip route-cache optimumip route-cache distributedno keepaliveno cdp enable!interface serial4/0description Edge interface connecting to a CPEip address 192.168.50.1 255.255.255.0rate-limit input 1000000 24000 24000conform-action set-prec-transmit 0 exceed-action set-prec-transmit 0encapsulation hdlcip route-cache...!interface FastEthernet2/0/0description Interface connecting Rpe1 to the intra-POP switchip address 17.1.1.1 255.255.255.0no ip route-cache optimumip route-cache distributedno keepaliveno cdp enableRpe2 Configuration
Rpe2 is a provider edge router. It is a router from the server provider network that sits on the edge and directly peers with an edge router from another server provider. The interface that receives packets from the other server provider network performs re-marking of the precedence to 0.
!ip cef distributed!interface POS0/0/0description Edge interface connecting to another Service providerip address 192.168.100.1 255.255.255.0rate-limit input 10000000 24000 24000conform-action set-prec-transmit 0 exceed-action set-prec-transmit 0ip route-cache distributedno keepaliveclock source internalno cdp enable!interface FastEthernet2/0/0description Interface connecting Rpe2 to the intra-POP switchip address 17.2.1.1 255.255.255.0no ip route-cache optimumip route-cache distributedno keepaliveno cdp enable!Rwest Configuration
Rwest is a backbone router. It is a router from the server provider network that interconnects its POP with other remote POPs through the ATM WAN cloud. The IP to ATM CoS Phase 1 feature is activated on the two ATM PVCs connecting Rwest respectively to Reast and to Rsouth. The ATM PVCs are to be shaped as CBR PVCs respectively at 10 Mbps and 1 Mbps. Because these two PVCs have shaping rates that differ by an order of magnitude, different WRED profiles are configured on the two VCs, with larger discard thresholds on the faster PVC to accommodate for normal temporary bursts that would naturally be larger (in number of packets) on the faster VC (assuming similar Round Trip Time [RTT]).
!ip cef distributed!interface ATM11/0/0description ATM interface to the ATM WAN cloudno ip addressno ip route-cache optimumip route-cache distributedno ip mroute-cacheno keepalive!interface ATM11/0/0.100 point-to-pointdescription ATM PVC to Reastip address 17.0.0.1 255.255.255.0atm pvc 100 5 100 aal5snap 10000 10000 10 inarprandom-detect fast-wred-profile!interface ATM11/0/0.101 point-to-pointdescription ATM PVC to Rsouthip address 17.0.1.1 255.255.255.0atm pvc 101 5 101 aal5snap 1000 1000 10 inarprandom-detect slow-wred-profile!interface FastEthernet2/0/0description Interface connecting Rwest to the intra-POP switchip address 17.1.1.2 255.255.255.0no ip route-cache optimumip route-cache distributedno keepaliveno cdp enable!random-detect-group slow-wred-profileprecedence 0 20 40 10precedence 1 20 40 10precedence 2 20 40 10precedence 3 20 40 10precedence 4 20 40 10precedence 5 20 40 10precedence 6 35 60 100precedence 7 35 60 100!random-detect-group fast-wred-profileprecedence 0 72 144 10precedence 1 72 144 10precedence 2 72 144 10precedence 3 72 144 10precedence 4 72 144 10precedence 5 72 144 10precedence 6 130 200 100precedence 7 130 200 100!Rsouth Configuration
Rsouth is a backbone router. It is a router from the server provider network that interconnects its POP with other remote POPs through the ATM WAN cloud. The IP to ATM CoS Phase 1 feature is activated on the two ATM PVCs connecting Rsouth respectively to Reast and to Rwest. The ATM PVCs are to be shaped as CBR PVCs respectively at 9 Mbps and 1 Mbps. Because these two PVCs have shaping rates that differ by almost an order of magnitude, different WRED profiles are configured on the two VCs, with larger discard thresholds on the faster PVC to accommodate for normal temporary bursts that would naturally be larger (in number of packets) on the faster VC (assuming similar RTT).
Rsouth thus has a similar configuration to Rwest.
Reast Configuration
Reast is a backbone router. It is a router from the server provider network that interconnects its POP with other remote POPs through the ATM WAN cloud. The IP to ATM CoS Phase 1 feature is activated on the two ATM PVCs connecting Reast respectively to Rsouth and to Rwest. The ATM PVCs are to be shaped as CBR PVCs respectively at 9 Mbps and 10 Mbps. Because these two PVCs have shaping rates that are of the same order of magnitude and quite close, the same WRED profile is configured on the two VCs.
!ip cef distributed!interface ATM9/0/0description ATM interface to the ATM WAN cloudno ip addressno ip route-cache optimumip route-cache distributedno ip mroute-cacheno keepalive!interface ATM9/0/0.10 point-to-pointdescription ATM PVC to Rwestip address 17.0.0.2 255.255.255.0atm pvc 10 5 100 aal5snap 10000 10000 10 inarprandom-detect fast-wred-profile!interface ATM9/0/0.11 point-to-pointdescription ATM PVC to Rsouthip address 17.0.2.2 255.255.255.0atm pvc 11 5 101 aal5snap 9000 9000 10 inarprandom-detect fast-wred-profile!interface FastEthernet2/0/0description Interface connecting Reast to the intra-POP switchip address 17.2.1.2 255.255.255.0no ip route-cache optimumip route-cache distributedno keepaliveno cdp enable!random-detect-group fast-wred-profileprecedence 0 72 144 10precedence 1 72 144 10precedence 2 72 144 10precedence 3 72 144 10precedence 4 72 144 10precedence 5 72 144 10precedence 6 130 200 100precedence 7 130 200 100!Examples of Show Commands
The show queueing interface command confirms that per-VC WRED performs selective packet drops on data traffic in a situation of congestion but does not perform any drops of routing packets. It also confirms that there were no drops due to buffer shortage on the VIP.
Rwest# show queueing interface atm 11/0/0.100VC 5/100 -ATM11/0/0.100 queue size 83packets output 134757, drops 17402, nobuffer drops 0WRED: queue average 82weight 1/512, max available buffers 1021Precedence 0: 72 min threshold, 144 max threshold, 1/10 mark weight133023 packets output, drops: 17402 random, 0 thresholdPrecedence 1: 72 min threshold, 144 max threshold, 1/10 mark weight(no traffic)Precedence 2: 72 min threshold, 144 max threshold, 1/10 mark weight(no traffic)Precedence 3: 72 min threshold, 144 max threshold, 1/10 mark weight(no traffic)Precedence 4: 72 min threshold, 144 max threshold, 1/10 mark weight(no traffic)Precedence 5: 72 min threshold, 144 max threshold, 1/10 mark weight(no traffic)Precedence 6: 130 min threshold, 200 max threshold, 1/100 mark weight1734 packets output, drops: 0 random, 0 thresholdPrecedence 7: 130 min threshold, 200 max threshold, 1/100 mark weight(no traffic)The show atm vc command confirms that no packets are being dropped on the PA.
Rwest# show atm vc 100ATM11/0/0.100: VCD: 100, VPI: 5, VCI: 100, etype:0x0, AAL5 - LLC/SNAP, Flags: 0xC0030PeakRate: 10000, Average Rate: 10000, Burst Cells: 10, VCmode: 0x0OAM DISABLED, InARP frequency: 15 minute(s)InPkts: 1350, OutPkts: 1340, InBytes: 94160, OutBytes: 92560InPRoc: 1350, OutPRoc: 0, Broadcasts: 1330InFast: 0, OutFast: 0, InAS: 0, OutAS: 1InPktDrops: 0, OutPktDrops: 0CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0OAM F5 cells sent: 0, OAM cells received: 0Status: ACTIVERwest#The eigrp log-neighbor-change command is used in the Enhanced IGRP router configuration. Because no neighbor-change messages are sent to the syslog (and to the console), it confirms that, regardless of the congestion level on the data traffic, Enhanced IGRP neighbors remain visible to each other from the routing perspective and that the Enhanced IGRP routing thus remains stable.
!router eigrp 209eigrp log-neighbor-change!The show ip eigrp neighbor detail command is used to confirm that Enhanced IGRP routing messages are not lost and thus do not require retransmission.
Rwest# show ip eigrp neighbor detailIP-EIGRP neighbors for process 209H Address Interface Hold Uptime SRTT RTO Q Seq(sec) (ms) Cnt Num0 17.0.0.2 ATM11/0/0 14 17:11:35 1 200 0 1027Version 11.1/1.0, Retrans: 1, Retries: 0Case Study 2: ISP Offering Premium Differentiated Service
Before the availability of IP QoS features, ISPs needed to focus on a single market segment characterized by a particular trade-off between level of performance and price. For instance, some ISPs focused on low-cost services (standard) often sought by residential customers, while some ISPs focused on high-performance services (premium) often sought by business customers. These services needed to remain on separate physical networks because they each required very different traffic engineering practices: The high-performance service required a network with no or low overbooking to achieve high performance and the low-cost service required high overbooking in the network to achieve low cost.
The IP QoS features now enable an ISP to support both (or even multiple) standard and premium CoS on the same infrastructure by activating congestion management or scheduling mechanisms that operate independently for each CoS.
This case study presents an IP network design where a premium CoS is supported in addition to the standard best-effort CoS. The premium CoS may be marketed, for instance, to business users. The premium CoS is not marketed as a strictly guaranteed service (that is, with strictly guaranteed performance parameters) but rather is marketed as an engineered best-effort service just like "high end/overprovisioned" Internet backbones are marketed today. WRED, and per-VC WRED where the underlying transport technology is ATM, is used to enforce the service differentiation by more aggressively dropping standard traffic in case of congestion so that standard traffic is in effect more throttled in case of congestion than the premium service. This selective dropping results in a premium IETF-compliant TCP flow enjoying superior throughput over a standard IETF-compliant TCP flow. In case of congestion, an end user communicating using the standard service will experience the congestion while an end user communicating using the premium service will have a similar "experience" as if the user were using a lightly loaded network.
Packets that are part of the standard CoS are marked/re-marked with precedence 0 when received from the customer and enter the server provider network using the CAR feature. This marking ensures that traffic from a standard customer will be treated with the standard CoS.
Packets that are part of the premium CoS are marked/re-marked with precedence 4 when received from the customer and enter the server provider network using the CAR feature. This marking ensures that traffic from a premium customer will be treated with the premium CoS.
The service provider also uses CAR to sell and enforce a subrate premium service, a service where the amount of premium traffic to be sent by the customer is limited to a bandwidth that is lower than the physical interface bandwidth. For instance, the service provider can sell 5 Mbps of premium service to a customer connected at 34 Mbps through a High -Speed Serial Interface (HSSI).
QoS Policy Propagation via BGP (QPPB) is used to ensure that all traffic destined to a premium customer is marked with precedence 4 when it enters the service provider network (regardless of whether it comes from a premium or standard customer) and is thus treated with the premium CoS. This configuration of QPPB ensures that a premium customer benefits from high performance both on the traffic it sends and on the traffic it receives.
Routing traffic is treated inside the server provider network as a separate class that is not visible nor accessible to user traffic and that enjoys a lower drop probability to increase routing protection. Routing traffic is identified using precedence 6.
illustrates the network topology for this case study.
Figure 8 Network Topology for Case Study 2
Rpe1 Configuration
Rpe1 is a provider edge router. It is a router from the server provider network that sits on the edge and directly connects to routers on the customer premises. Every interface that receives packets from outside the service provider network (that is, from customer premises routers) performs re-marking of the precedence to 0 for packets belonging to the standard CoS and to 4 for packets belonging to the premium CoS.
!ip cef distributed!interface serial4/0description Edge interface connecting to a Standard Customerip address 192.168.50.1 255.255.255.0rate-limit input 1000000 24000 24000conform-action set-prec-transmit 0 exceed-action set-prec-transmit 0encapsulation hdlc! activate QPPB on this interfacebgp-policy destination ip-prec-mapip route-cache!interface serial4/1description Edge interface connecting to a Premium Customerip address 192.168.60.1 255.255.255.0rate-limit input 1000000 24000 24000conform-action set-prec-transmit 4 exceed-action set-prec-transmit 4encapsulation hdlc! activate QPPB on this interfacebgp-policy destination ip-prec-mapip route-cache!interface Hssi3/0/0description Edge interface connecting to a Customerwith 5Mb/s of Premiumip address 192.168.70.1 255.255.255.0! traffic below 5 Mb/s is marked as Premium (Precedence 4).! traffic beyond 5 Mb/s is marked as Standard (Precedence 0).! Only considers traffic which hasn't been ear-marked as going to! a Premium (ie traffic has qos-group 0)rate-limit input qos-group 0 5000000 24000 24000conform-action set-prec-transmit 4 exceed-action set-prec-transmit 0! activate QPPB on this interface (for Precedence and qos-group setting)bgp-policy destination ip-prec-mapbgp-policy destination ip-qos-mapno ip route-cache optimumip route-cache distributedno keepaliveno cdp enable...!interface FastEthernet2/0/0description Interface connecting Rpe1 to the intra-POP switchip address 17.1.1.1 255.255.255.0no ip route-cache optimumip route-cache distributedno keepaliveno cdp enable!router bgp 210! tell BGP to take into account the "receive_community" route-maptable-map receive_community! tell BGP to advertise prefixes with communities as defined in! the "mark_community" route-mapneighbor 210.210.14.1 remote-as 210neighbor 200.200.14.1 update-source Loopback0neighbor 210.210.14.1 route-map mark_community outneighbor 210.210.14.1 send-community!ip bgp-community new-format!! access lists for all the Premium customers on Rpe1access-list 1 permit 192.168.60.0 0.0.0.255access-list 2 permit 192.168.70.0 0.0.0.255!! advertise this Premium Customer with Community Premium (ie 210:4)route-map mark_community permit 10match ip address 1set community 210:4!! advertise this Premium Customer with Community Premium (ie 210:4)route-map mark_community permit 10match ip address 2set community 210:4!! advertise all other Customers with Community Standard (ie 210:0)route-map mark_community permit 30set community 210:0!ip community-list 1 permit 210:4!! configure QPPB to set Precedence to 4 on packets destined to an! address whose BGP advertisement has been received with Community 210:4route-map receive_community permit 10match community 1set ip precedence 4set ip qos-group 4!! configure QPPB to set Precedence to 0 otherwiseroute-map receive_community permit 20set ip precedence 0set ip qos-group 0!Rwest Configuration
Rwest is a backbone router. It is a router from the server provider network that interconnects its POP with other remote POPs through the ATM WAN cloud. The IP to ATM CoS Phase 1 per-VC WRED feature is activated on the two ATM PVCs connecting Rwest respectively to Reast and to Rsouth. The ATM PVCs are to be shaped as VBR PVCs with a PCR of 12 Mbps and an SCR of 8 Mbps. Because these two PVCs have identical shaping rates, the same WRED profile is configured on the two VCs.
The IP QoS WRED feature is activated on the POSIP link to Rnorth. Use of WRED over POSIP and over ATM allows for consistent end-to-end support.
!ip cef distributed!interface POS0/0/0description SDH/POSIP interface connecting to the SDH WAN cloudip address 17.10.0.1 255.255.255.0random-detectip route-cache distributedno keepaliveclock source internalno cdp enable!interface ATM11/0/0description ATM interface to the ATM WAN cloudno ip addressno ip route-cache optimumip route-cache distributedno ip mroute-cacheno keepalive!interface ATM11/0/0.100 point-to-pointdescription ATM PVC to Reastip address 17.0.0.1 255.255.255.0atm pvc 100 5 100 aal5snap 12000 8000 512 inarprandom-detect fast-wred-profile!interface ATM11/0/0.101 point-to-pointdescription ATM PVC to Rsouthip address 17.0.1.1 255.255.255.0atm pvc 101 5 101 aal5snap 12000 8000 512 inarprandom-detect fast-wred-profile!interface FastEthernet2/0/0description Interface connecting Rwest to the intra-POP switchip address 17.1.1.2 255.255.255.0no ip route-cache optimumip route-cache distributedno keepaliveno cdp enable!random-detect-group fast-wred-profileprecedence 0 72 120 10precedence 1 72 120 10precedence 2 72 120 10precedence 3 72 120 10precedence 4 110 144 30precedence 5 110 144 30precedence 6 144 200 100precedence 7 144 200 100!Examples of Show Commands
The show queueing interface command confirms that per-VC WRED performs selective packet drops with lower drop probability on the premium traffic than on the standard traffic in a situation of congestion. It also confirms that it does only exceptional dropping of routing packets and that it does not drop any packets due to buffer shortage on the VIP.
Rwest# show queueing interface atm 11/0/0.100VC 5/100 -ATM11/0/0.100 queue size 63packets output 150460, drops 29071, nobuffer drops 0WRED: queue average 75weight 1/512, max available buffers 1021Precedence 0: 72 min threshold, 120 max threshold, 1/10 mark weight133023 packets output, drops: 17402 random, 11343 thresholdPrecedence 1: 72 min threshold, 120 max threshold, 1/10 mark weight(no traffic)Precedence 2: 72 min threshold, 120 max threshold, 1/10 mark weight(no traffic)Precedence 3: 72 min threshold, 120 max threshold, 1/10 mark weight(no traffic)Precedence 4: 110 min threshold, 144 max threshold, 1/30 mark weight15703 packets output, drops: 211 random, 112 thresholdPrecedence 5: 110 min threshold, 144 max threshold, 1/30 mark weight(no traffic)Precedence 6: 144 min threshold, 200 max threshold, 1/100 mark weight1734 packets output, drops: 3 random, 0 thresholdPrecedence 7: 144 min threshold, 200 max threshold, 1/100 mark weight(no traffic)The show atm vc command confirms that no packets are being dropped on the PA.
Rwest# show atm vc 100ATM11/0/0.100: VCD: 100, VPI: 5, VCI: 100, etype:0x0, AAL5 - LLC/SNAP, Flags: 0xC0030PeakRate: 12000, Average Rate: 8000, Burst Cells: 512, VCmode: 0x0OAM DISABLED, InARP frequency: 15 minute(s)InPkts: 1350, OutPkts: 1340, InBytes: 94160, OutBytes: 92560InPRoc: 1350, OutPRoc: 0, Broadcasts: 1330InFast: 0, OutFast: 0, InAS: 0, OutAS: 1InPktDrops: 0, OutPktDrops: 0CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0OAM F5 cells sent: 0, OAM cells received: 0Status: ACTIVERwest#Case Study 3: European ISP Offering Premium Internet Access over Transatlantic ATM Link
As the price of intercontinental bandwidth (bandwidth between Europe/Asia and the United States) remains high compared to domestic bandwidth, this international bandwidth is often a scarce resource for European/Asian IP server providers. It is typically the most narrow bottleneck for Internet access from Europe or Asia. Large ISPs acting as network service providers (NSPs) for smaller ISPs or offering Internet access to business customers see a key business opportunity in generating direct revenue from this asset and want to control how the transatlantic bandwidth is distributed among competing users. In other words, they want to change their business model and reflect the cost of provisioning international bandwidth to the downstream customer (local ISPs, academic customers, business customers) based on the level of bandwidth overbooking that each customer is contracting for and experiencing.
To succeed, a European/Asian ISP can offer multiple levels of differentiated services on Internet access. In that service, an end user can contract a premium Internet access. Grouping the customers that have the same level of requirements for Internet access makes it is possible for the ISP to apply more generous resource provisioning and lower overbooking ratio that is appropriate for that pool of premium customers and offer them the required cost/performance point. Of course, the service could be enhanced further to offer more than two CoS for Internet access.
Because a very high proportion of Internet content is pulled from servers located in the United States and because the most stringent bottleneck for Internet access from Europe and Asia is often the transatlantic link, it is often sufficient to apply IP QoS mechanisms on that transatlantic link and only in the direction from the United States. There is typically little discard in the domestic network because it is usually far less congested or not congested at all.
This case study presents a European ISP network design supporting two levels of international access to the Internet (standard and premium) where the international bandwidth is provided through an ATM connection. In this environment, the service differentiation is provided through the IP to ATM CoS feature activated on a router on the U.S. side of the transatlantic link.
The main design goals are as follows:
•
Note
•
illustrates the network topology for this case study.
Figure 9 Network Topology for Case Study 3
Rus Configuration
Rus is an interconnect router sitting in the United States. It supports the interconnection to the U.S. Internet network provider on one side and supports the ATM international connection to the European backbone.
Rus can be operated by one of the following:
•
•
•
QPPB is used so that Rus is dynamically notified through BGP about which prefixes correspond to standard international Internet access customers and which prefixes correspond to premium international Internet access customers. QPPB is also used to set the precedence to 0 in packets destined to the standard customers and to 2 in packets destined to the premium customers.
The IP to ATM CoS Phase 1 per-VC WRED feature is also activated on Rus over the ATM PVC toward Reur in Europe. The ATM PVC is shaped as a CBR PVC with a PCR of 10 Mbps, and the IP to ATM CoS phase 1 per-VC WRED feature performs the service differentiation on traffic destined to the standard international Internet access customers and destined to the premium international Internet access customers because the packets respectively have their precedences set to 0 and 2.
interface FastEthernet2/0/0mac-address 0001.0002.0001ip address 192.168.1.1 255.255.255.0! remark precedence of all incoming traffic to 0rate-limit input 1000000 24000 24000 conform-action set-prec-transmit 0exceed-action set-prec-transmit 0! activate QPPB on this interfacebgp-policy destination ip-prec-mapno ip route-cache optimumip route-cache distributedno keepaliveno cdp enable!interface ATM11/0/0no ip addressno ip route-cache optimumip route-cache distributedno ip mroute-cacheno keepalive!interface ATM11/0/0.100 point-to-pointip address 17.0.0.1 255.255.255.0atm pvc 100 5 100 aal5snap 10000 10000 10 inarprandom-detect internet-access!router bgp 210! tell BGP to take into account the "receive_community" route-maptable-map receive_communityneighbor 210.210.14.1 remote-as 210neighbor 200.200.14.1 update-source Loopback0!ip bgp-community new-format!ip community-list 1 permit 210:4!! configure QPPB to set Precedence to 2 on packets destined to an! address whose BGP advertisement has been received with Community 210:2route-map receive_community permit 10match community 1set ip precedence 2!! configure QPPB to set Precedence to 0 otherwiseroute-map receive_community permit 20set ip precedence 0!random-detect-group internet-accessprecedence 0 72 120 10precedence 1 72 120 10precedence 2 110 144 30precedence 3 110 144 30precedence 4 110 144 30precedence 5 110 144 30precedence 6 144 200 100precedence 7 144 200 100!Rpe Configuration
Rpe is a provider edge router. It is a router from the server provider network that sits on the edge and directly connects to routers on the customer premises. Every interface that receives packets from outside the service provider network (that is, from customer premises routers) performs re-marking of incoming traffic to precedence 0 on all packets from all customers because our design assumes that the only service differentiation is performed over the international connection for traffic traveling from the United States. However, prefixes of customers subscribing to the premium international Internet access are advertised by Rpe with a community distinguishing them as such so that Rus can then mark the precedence to 2 of packets destined to these customers through QPPB.
!ip cef distributed!interface serial4/0description Edge interface connecting to a Standard Internet Customerip address 192.168.50.1 255.255.255.0! remark all incoming traffic to precedence zerorate-limit input 100000 2400 2400conform-action set-prec-transmit 0 exceed-action set-prec-transmit 0encapsulation hdlcip route-cache!interface serial4/1description Edge interface connecting to a Premium Internet Customerip address 192.168.60.1 255.255.255.0! remark all incoming traffic to precedence zerorate-limit input 100000 2400 2400conform-action set-prec-transmit 0 exceed-action set-prec-transmit 0encapsulation hdlcip route-cache!interface FastEthernet2/0/0description Interface connecting Rpe to the intra-POP switchip address 17.1.1.1 255.255.255.0no ip route-cache optimumip route-cache distributedno keepaliveno cdp enable!router bgp 210neighbor 210.210.20.1 remote-as 210neighbor 210.210.20.1 update-source Loopback0! tell BGP to advertise prefixes with communities as defined in! the "mark_community" route-mapneighbor 210.210.20.1 route-map mark_community outneighbor 210.210.20.1 send-community!ip bgp-community new-format!! access lists for all the Premium Internet Customers on Rpeaccess-list 5 permit 192.168.60.0 0.0.0.255!! advertise this Premium Customer with Community Premium (ie 210:2)route-map mark_community permit 10match ip address 5set community 210:2!! advertise all other Customers with Community Standard (ie 210:0)route-map mark_community permit 30set community 210:0!Case Study 4: Service Differentiation for Enhanced Multimedia in Enterprise Networks
This case study presents an enterprise network where the IP to ATM CoS Phase 1 feature is used to prioritize multimedia traffic (multimedia training distributed by a server running the Cisco IP/TV application) over other data traffic (FTP) to enhance the quality of the multimedia application and maximize effectiveness of the employees relying on these applications.
Clients in one location access various applications onto servers in a remote location. These applications include on-demand training video, live broadcast training multimedia sessions, and heavy FTP transfers. Connectivity between the locations is provided through an ATM PVC between the two site routers. The ATM PVC bandwidth is a possible bottleneck.
The main design goals are as follows:
•
•
•
illustrates the network topology for this case study.
Figure 10 Network Topology for Case Study 4
To achieve these goals, CAR is used on the router Rs connecting the servers to mark the precedence of incoming traffic depending on the server it is coming from: CAR marks as high priority (precedence 4) all the traffic sent by the IP/TV server that is the multimedia traffic, and CAR marks as low priority all the traffic coming from the FTP server. Then the IP to ATM CoS Phase 1 feature is used on Rs to prioritize the multimedia traffic by enforcing a more aggressive WRED discard on the low priority traffic so that in case of congestion, through TCP's adaptive flow control, the FTP transfers get throttled back to the bandwidth left over by the multimedia applications on the ATM PVC.
Note
In this case study, the video streams transferred by the IP/TV server are MPEG1 at 1.5 Mbps each, and the ATM PVC between the two locations is a CBR PVC at 5 Mbps. Thus, when two clients are simultaneously pulling a different video stream in the remote location, the FTP traffic is left with about 2 Mbps of bandwidth. When a third client starts pulling a different video stream in the remote location, the FTP traffic must adjust to the reduced remaining bandwidth inside the ATM PVC of about 500 kbps.
Note that because the Cisco IP/TV application uses IP multicast, when multiple clients are following the same multimedia channel (for example, live broadcast training multimedia session), the replication can be performed in the remote client site by the router supporting the multiple clients (Rc). Thus only 1.5 Mbps of bandwidth is consumed by this session over the ATM PVC regardless of the number of clients simultaneously following that session.
Rs Configuration
Rs is the router on the server site.
!ip cef distributed!interface FastEthernet1/0/0description interface connecting the IP/TV Serverip address 192.168.70.1 255.255.255.0! mark incoming traffic as High Priority (Precedence 4)rate-limit input 10000000 24000 24000conform-action set-prec-transmit 4 exceed-action set-prec-transmit 4no ip route-cache optimumip route-cache distributedno keepaliveno cdp enable!interface FastEthernet1/0/1description interface connecting the FTP Serverip address 192.168.80.1 255.255.255.0! mark incoming traffic as Low Priority (Precedence 0).rate-limit input 10000000 24000 24000conform-action set-prec-transmit 0 exceed-action set-prec-transmit 0no ip route-cache optimumip route-cache distributedno keepaliveno cdp enable!interface ATM11/0/0description ATM interface to the ATM WAN cloudno ip addressno ip route-cache optimumip route-cache distributedno ip mroute-cacheno keepalive!interface ATM11/0/0.100 point-to-pointdescription ATM PVC to Rcip address 192.168.100.1 255.255.255.0atm pvc 100 5 100 aal5snap 12000 8000 512 inarprandom-detect client-server-wred-profile!!random-detect-group client-server-wred-profileprecedence 0 50 120 10precedence 1 50 120 10precedence 2 50 120 10precedence 3 50 120 10precedence 4 110 144 30precedence 5 110 144 30precedence 6 144 200 100precedence 7 144 200 100!Glossary
Feedback