Traffic Policing






Traffic Policing

The previous sections covered ways you can queue different flows of traffic and then prioritize those flows. That is an important part of QoS. Sometimes, however, it is necessary to actually regulate or limit the amount of traffic an application is allowed to send across various interfaces or networks.

Cisco has a few tools that enable network administrators to define how much bandwidth an application or even a user can use. These features come in two different flavors: rate-limiting tools such as CAR, and shaping tools such as GTS or FRTS.

The main difference between these two traffic-regulation tools is that rate-limiting tools drop traffic based upon policing, and shaping tools generally buffer the excess traffic while waiting for the next open interval to transmit the data.

CAR and traffic shaping tools are similar in that they both identify when traffic exceeds the thresholds set by the network administrator.

Often, these two tools are used together. Traffic shaping is used at the edge of the network (customer premises) to make sure the customer is utilizing the bandwidth for business needs.

CAR is often used in service provider networks to ensure that a subscriber does not exceed the amount of bandwidth set by contract with the service provider.

CAR

CAR is a policing mechanism that enables network administrators to set exceed or conform actions. Often you use a conform action to transmit the traffic and an exceed action to drop the packet or to mark it with a lower IP Precedence value.

CAR's rate-limiting mechanism enables a user to

  • Control the maximum rate of traffic transmitted or received on an interface

  • Give granular control at Layer 3, which enables an IP network to exhibit qualities of a TDM network

You can rate-limit traffic by precedence, Media Access Control (MAC) address, IP addresses, or other parameters. Network administrators also can configure access lists to create even more granular rate-limiting policies.

It is important to note that CAR does not buffer any traffic to smooth out traffic bursts. Therefore, CAR is ideal for high-speed environments, as queuing adds no delay.

To configure CAR and Distributed CAR (DCAR) on Cisco 7000 series routers with RSP7000 or on Cisco 7500 series routers with a VIP2-40 or greater interface processor for all IP traffic, use the following commands, beginning in global configuration mode:

rate-limit {input | output} bps burst-normal
 burst-max conform-action action exceed-action action

The network administrator can specify a basic CAR policy for all IP traffic. See Figure for a description of conform and exceed action keywords.

Figure rate-limit Command Action Keywords

Keyword

Description

continue

Evaluates the next rate-limit command.

drop

Drops the packet.

set-prec-continue new-prec

Sets the IP Precedence and evaluates the next rate-limit command.

set-prec-transmit new-prec

Sets the IP Precedence and transmits the packet.

transmit

Transmits the packet.


For basic CAR and DCAR to be functional, you must define the following criteria:

  • Packet direction, incoming or outgoing.

  • An average rate, determined by a long-term average of the transmission rate. Traffic that falls under this rate always conforms.

  • A normal burst size, which determines how large traffic bursts can be before some traffic is considered to exceed the rate limit.

  • An excess burst size.

Traffic that falls between the normal burst size and the excess burst size exceeds the rate limit with a probability that increases as the burst size increases. CAR propagates bursts.

It does not smooth or shape traffic.

Figure describes the conform and exceed actions.

You can use CAR and Versatile Interface Processor Distributed CAR (VIP-DCAR) only with IP traffic. Non-IP traffic is not rate-limited.

You can configure CAR or VIPDCAR on an interface or subinterface. CAR and VIP-DCAR are not supported on the following interfaces, however:

  • Fast EtherChannel

  • Tunnel

  • Primary Rate Interface (PRI)

  • Any interface that does not support Cisco express forwarding (CEF)

Traffic Shaping

Cisco IOS QoS software includes two types of traffic shaping: GTS and FRTS. Both traffic-shaping methods are similar in implementation, although their command-line interfaces differ somewhat and they use different types of queues to contain and shape traffic that is deferred.

If a packet is deferred, GTS uses a WFQ to hold the delayed traffic. FRTS uses either a CQ or a PQ to hold the delayed traffic, depending on what you configured. As of April 1999, FRTS also supports WFQ to hold delayed traffic.

Traffic shaping enables you to control the traffic going out of an interface to match its flow to the speed of the remote, target interface and to ensure that the traffic conforms to policies contracted for it. Thus, you can shape traffic adhering to a particular profile to meet downstream requirements, thereby eliminating bottlenecks in topologies with data-rate mismatches.

You use traffic shaping primarily to

  • Control usage of available bandwidth

  • Establish traffic policies

  • Regulate traffic flow to avoid congestion

You can use traffic shaping in the following situations:

  • You can configure traffic shaping on an interface if you have a network with different access rates. Suppose one end of the link in a Frame Relay network runs at 256 kbps and the other end runs at 128 kbps. Sending packets at 256 kbps could cause the applications using the link to fail.

  • You can configure traffic shaping if you offer a subrate service. In this case, traffic shaping enables you to use the router to partition your T1 or T3 links into smaller channels.

Traffic shaping prevents packet loss. It is especially important to use traffic shaping in Frame Relay networks because the switch cannot determine which packets take precedence and, therefore, which packets should be dropped when congestion occurs.

Moreover, it is of critical importance for VoIP that you control latency. By limiting the amount of traffic and traffic loss in the network, you can smooth out traffic patterns and give priority to real-time traffic.

Differences Between GTS and FRTS

As mentioned, both GTS and FRTS are similar in implementation in that they share the same code and data structures, but they differ in regard to their command-line interfaces and the queue types they use.

Here are two ways in which GTS and FRTS differ:

  • FRTS CLI supports shaping based on each data-link connection identifier (DLCI). GTS is configurable per interface or subinterface.

  • GTS supports a WFQ shaping queue.

You can configure GTS to behave the same way as FRTS by allocating one DLCI per subinterface and using GTS plus BECN support. The two behave the same, except for the different shaping queues they use.

In versions of software previous to Cisco IOS Software Release 12.04(T), FRTS and WFQ were not compatible. This limitation was removed, and now both FRTS and GTS work with WFQ. This enables network administrators to choose a more granular QoS mechanism (FRTS and WFQ per DLCI).

Traffic Shaping and Queuing

Traffic shaping smoothes traffic by storing traffic above the configured rate in a queue. When a packet arrives at the interface for transmission, the following happens:

  • If the queue is empty, the traffic shaper processes the arriving packet.

    If possible, the traffic shaper sends the packet.

    Otherwise, it places the packet in the queue.

  • If packets are in the queue, the traffic shaper sends another new packet in the queue.

When packets are in the queue, the traffic shaper removes the number of packets it can transmit from the queue every time interval.

GTS

GTS applies on a per-interface basis and can use access lists to select the traffic to shape. It works with a variety of Layer 2 technologies, including Frame Relay, ATM, Switched Multimegabit Data Service (SMDS), and Ethernet.

On a Frame Relay subinterface, you can set up GTS to adapt dynamically to available bandwidth by integrating BECN signals, or to simply shape to a pre-specified rate. You also can configure GTS on an ATM interface to respond to RSVPs signaled over statically configured ATM permanent virtual circuits (PVCs).

Most media and encapsulation types on the router support GTS. You also can apply GTS to a specific access list on an interface. Figure shows how GTS works.

GTS in Action


To enable traffic shaping for outbound traffic on an interface, use the traffic-shape rate_interface configuration command. Use the "no" form of this command to disable traffic shaping on the interface.

traffic-shape rate bit-rate [burst-size [excess-burst-size]]
no traffic-shape rate

The syntax description follows:

  • bit-rate Bit rate that traffic is shaped to, in bits per second (bps). This is the access bit rate you contract with your service provider, or the service level you intend to maintain.

  • burst-size (Optional) Sustained number of bits you can transmit per interval. On Frame Relay interfaces, this is the committed burst size contracted with your service provider; the default is the bit rate divided by 8.

  • excess-burst-size (Optional) Maximum number of bits that can exceed the burst size in the first interval in a congestion event. On Frame Relay interfaces, this is the excess burst size contracted with your service provider; the default is equal to the burst size traffic shape group.

To enable traffic shaping based on a specific access list for outbound traffic on an interface, use the traffic-shape group interface configuration command. Use the no form of this command to disable traffic shaping on the interface for the access list:

traffic-shape_group access-list bit-rate [burst-size [excess-burst-size]]
no traffic-shape group access-list

Consider the following examples. Corporation A wants to limit the output of its Frame Relay circuit to the CIR of the link to prevent packets from being flagged as discard eligible (DE). The Frame Relay circuit is 56 kbps and the CIR is 32 kbps. Figure shows the needed configuration.

Traffic-Shaping Configuration for Corporation A

interface serial 0/0
encapsulation frame-relay
traffic-shape rate 32000 4000 0

Corporation B wants to shape its outbound traffic into its WAN network so that FTP traffic uses only 64, 000 bps of its 256-kbps circuit. Figure shows the needed configuration.

Traffic-Shaping Configuration for Corporation B

interface serial 0/0
traffic-shape group 101 64000 8000 0
!
access-list 101 permit tcp any eq ftp any

FRTS

Like GTS, FRTS smoothes out traffic spikes by buffering excess traffic. FRTS also can eliminate problems caused by different access rates at the ingress and egress of a Frame Relay network. A central-site Frame Relay network, for instance, often has a high-speed (T1 or greater) connection to the network, and a remote site usually has a connection to the frame network less than 384 kbps.

The central-site router can transmit to the remote router at T1 speeds, but the remote router can receive traffic only at 384 kbps or less. This forces the Frame Relay network to buffer the traffic and can add seconds to a packet stream. This renders voice unacceptable in almost any network.

FRTS enables the use of FECN and BECN to dynamically transmit more or less bandwidth.

In Frame Relay networks, BECNs and FECNs indicate congestion. You specify BECN and FECN by bits within a Frame Relay frame.

Using information contained in the BECN-tagged packets received from the network, FRTS also can dynamically throttle traffic. With BECN-based throttling, packets are held in the router's buffers to reduce the data flow from the router into the Frame Relay network.

The throttling is done on each virtual circuit (VC) and the transmission rate is adjusted based on the number of BECN-tagged packets received.

Fragmentation

Both propagation and queuing delay are discussed in previous chapters. The reasoning behind the need for fragmentation is simple. Large packets (1500-byte MTUs) take a long time to move across low-bandwidth links (768 kbps and less). Fragmentation breaks larger packets into smaller packets. You can accomplish this at either Layer 2 or Layer 3 of the Open Systems Interconnection (OSI) reference model.

In many data applications, latency caused by low-bandwidth links does not matter to the end user. In real-time applications, however, this can cause many problems (choppy voice quality, missed frames, dropped calls, and so on).

A 1500-byte packet moving across a 56-kbps circuit, for example, takes 214 ms to traverse the circuit. The ITU-T recommendation for uni-directional maximum voice latency is less than 150 ms. Therefore, one 56-kbps circuit and one 1500-byte packet consume the entire VoIP delay budget. For example:

Packet size in bytes/sec x 8 = Packet size in bits/sec

Packet size in bits/sec / Circuit size in bits/sec

= Time required to transmit packet

1500 bytes/sec x 8 = 12000 bits/sec

12000 bits/sec / 56000 bits/sec = .214 sec = 214 msec

Fragmentation in itself is not enough to remove the latency problem on low-bandwidth circuits. The router must also be able to queue based upon fragments or smaller packets instead of by the original (prefragmented) packet.

The Cisco Systems VoIP implementation enables users to modify the number of samples per packet. By default with G.729, two 10-ms speech samples are put into one frame. This gives you a packet every 20 ms. This means you need to be able to transmit a VoIP packet out of the router every 20 ms.

This 20-ms distance between each frame can change based upon the number of speech samples you decide to put in each frame. Also, this number is important because it enables you to determine the size of fragmentation needed.

As shown in Figure, you can determine your fragment size depending on the speed of the link and the samples per frame.

Fixed-Frame Propagation Delay

Frame Size

Link Speed

1 Byte

64 Byte

128 Byte

256 Byte

512 Byte

1024 Byte

1500 Byte

56 kbps

143µs

9 ms

18 ms

36 ms

72 ms

144 ms

214 ms

64 kbps

125µs

8 ms

16 ms

32 ms

64 ms

128 ms

187 ms

128 kbps

62.5µs

4 ms

8 ms

16 ms

32 ms

64 ms

93 ms

256 kbps

31µs

2 ms

4 ms

8 ms

16 ms

32 ms

46 ms

512 kbps

15.5µs

1 ms

2 ms

4 ms

8 ms

16 ms

23 ms

768 kbps

10 8µs

640 ms

1.28 ms

2.56 ms

5.12 ms

10.24 ms

15 ms

1536 kbps

5µs

320µs

640µs

1.28 ms

2.56 ms

5.12 ms

7.5 ms


Blocking

Fragmentation helps to eliminate "blocking" issues. Blocking is the amount of time you allow another packet to consume available WAN bandwidth and force other real-time packets to be queued. Blocking directly affects your delay budget. You can use different rules of thumb, but generally, you want to keep the blocking delay at 80 percent of your total voice packet size.

If you have two 10-ms speech samples in one 20-ms packet, for example, you want a maximum blocking delay of approximately 16 ms. Assuming your WAN link is 56 kbps and using Figure as an example, you want your packets to be fragmented to about 128 bytes. If you want an exact figure, the algorithm to use to determine your packet fragmentation size is as follows:

WAN bandwidth x blocking delay = fragment size in bits

Utilizing this algorithm to compute the exact delay based on the preceding recommendations:

WAN bandwidth (56 kbps) x blocking delay (16 ms) = 896 bits per second (112 bytes per second)

MCML PPP

Multi-Class Multilink Point-to-Point Protocol (MCML PPP) allows for the creation of two "bundles." One bundle can be fragmented and interleaved while the second bundle can simply be interleaved, as illustrated in Figure. This functionality is available starting in Cisco IOS Software Release 12.2(13)T and offers many advantages to using ML PPP.

Multi-Class, Multilink PPP


You can use MCML only on interfaces that can run PPP, which immediately rules out a large portion of WAN networks (Frame Relay, ATM, and so on).

MCML specifies only the fragmentation method; it does not specify the queuing technique needed to prioritize the fragments.

FRF.12

FRF.12 is a specification by the Frame Relay Forum Technical Committee, and you can find it at http://www.frforum.com. This specification enables Frame Relay networks to operate in a manner similar to MCML PPP. Because this fragmentation also happens at the link layer, the upper-layer protocols are not aware of the fragmentation.

As with MCML PPP, packets are fragmented at entry to the WAN network and reassembled when the destination router receives them.

FRF.12 also specifies the interworkings between Frame Relay and ATM. This enables packets fragmented by FRF.12 on the Frame Relay side of the circuit to be reassembled on the ATM side of the circuit.

IP MTU and MTU

On WAN interfaces that do not support MCML PPP or FRF.12, you can set the interface or protocol MTU to a lower value, which then forces fragmentation.

The MTU on a serial interface is usually 1500 bytes. With FRF.12 and MCML PPP, you can change the actual packet size sent on the interface without disturbing the actual packet flow. When you lower the MTU or IP MTU size, the packet changes for the duration of that packet's trip.

Figure shows the IP MTU configuration.

Configuring IP MTU

interface Serial0/0
 ip mtu 300
 no ip address
 encapsulation frame-relay
 fair-queue 64 256 1000
!
interface Serial0/0.1 point-to-point
 ip mtu 300
 ip address 40.0.0.7 255.0.0.0

Figure shows the MTU configuration.

Configuring MTU

interface Serial0/0
  mtu 300
  no ip address
  ip rsvp bandwidth 1158 1158
  encapsulation frame-relay
fair-queue 64 256 1000
!
interface Serial0/0.1 point-to-point
  mtu 300
  ip address 40.0.0.7 255.0.0.0

IP MTU Caveats

Changing the size of the IP packet for its entire life can cause many problems. The receiving station's overall performance is affected, for instance, because it handles many smaller packets more slowly than one big packet. Also, the header of the packet needs to be duplicated for each fragment.

Consider one 1500-byte packet that includes a 40-byte header. If you fragment the 1460-byte payload into 100-byte frames, you get 14 packets with 100 bytes and one packet with 60 bytes. You now need to put a 40-byte header back onto each of the 15 packets. In doing so, you increase the header size from 40 bytes to 600 bytes.

Another major problem with IP MTU and MTU sizing is that if the Do Not Fragment (DNF) bit is set on a packet, that packet is discarded. Many applications set this bit to prevent intermediary devices (routers and other network elements) from breaking their packet into many pieces. One reason the DNF bit might be set is to keep the receiving station from being burdened by having to put the fragments back into the proper order.

MTU Caveats

MTU sizing changes the size of all packets exiting that interface, including IP, Internetwork Packet eXchange (IPX), AppleTalk, and routing updates. This can be a problem for routing updates, Frame Relay Local Management Interface (LMI) updates, and other protocols that don't support fragmentation.

Edge QoS Wrap-Up

At this point, you should understand the basics of packet classification, fragmentation, queuing, bandwidth, and policing mechanisms. It is important to note that you can use some or many of these mechanisms concurrently in a given environment.

As a rule of thumb, with low bandwidth links you should always use packet classification and queuing mechanisms. Based upon bandwidth constraints and administrative policies, you might need to use compression and fragmentation methods as well.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows