Class-Based Traffic Shaping - Enterasys Security Router X-PeditionTM User Manual

Mechanisms Providing QoS
This is how the policer works. It maintains two token buckets, one holding tokens for normal
burst and the other for excess burst. The policing algorithm handles token refilling and burst
checking.
Token buckets are refilled every time a new packet arrives. The specified bandwidth and the
interval between the arrival time of the new packet and that of the previous packet are used to
calculate the number of tokens to refill the buckets. The formula is as follows:
Refill Token Bytes equals (Bandwidth multiplied by Interval) divided by 8
The bucket for holding tokens for normal burst is refilled first. If the calculated Refill Token Bytes is
enough to top the bucket for normal burst to the burst value specified, the remainder of Refill
Token Bytes are added to the bucket for excess burst (refer to the formula below). Also, the number
of tokens for excess burst is further limited by the excess burst value specified in the police
command.
The packet length is checked against the token bytes available in the two buckets. If the number of
token bytes in the bucket for normal burst is larger than the packet length, the conform-action
applies to this packet; if the token bytes for normal burst is not enough, but the number of token
bytes for excess burst is larger than the packet length, the exceed-action applies to this packet; if
neither of the token bytes for normal burst or excess burst is enough, the violate-action applies to
this packet.
In the following example, traffic policing is configured with an average rate of 8,000 bits per
second, normal burst size of 2,000 bytes, and excess burst size of 4,000 bytes. Packets entering
serial interface 1/0 are analyzed as to whether packets conform, exceed, or violate specified
parameters. Packets which conform to parameters are sent, those which exceed parameters are set
to a DSCP value of 43 and sent, and those which violate parameters are dropped.
XSR(config)#class-map the_heat
XSR(config-cmap<the_heat>)#match access-group 2
XSR(config)#policy-map turf
XSR(config-pmap<turf>)#class the_heat
XSR(config-pmap-c<the_heat>)#bandwidth percent 30
XSR(config-pmap-c<the_heat>)#police 8000 2000 4000 conform-action transmit
exceed-action set-dscp-transmit 43 violate-action drop
XSR(config)#interface serial 1/0
XSR(config-if<S1/0>)#service-policy output turf

Class-based Traffic Shaping

Routers can guarantee local performance to a connection only when that traffic is "well-behaved".
It is well established in IP networks that multiple router hops distort original traffic patterns
causing an instantaneously higher rate at some routers even when the connection satisfies the
client-specified rate constraint at the network entry way. Unfortunately, traffic pattern distortions
due to network load fluctuations tend to accumulate in the worse case. Traffic shaping is designed
to partially or completely reconstruct traffic at each router to offset this problem.
The XSR's QoS traffic shaping models traffic using token bucket. It works this way: you specify
traffic characteristics using the token bucket parameters of average rate and maximum burst size.
The XSR monitors output traffic and, if necessary, delays excess traffic using a buffer or queueing
mechanism. Packets are stored in the queue as long as there are no available tokens in the bucket.
Tokens in the bucket are supplied with the configured rate up to the maximum of the burst size.
The XSR continues sending packets from the queue when it has enough tokens in the bucket. The
resulting output traffic meets the required average and maximum burst rates.
XSR User's Guide 12-7