Enterasys Networks X-PeditionTM manual Class-based Traffic Shaping

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-actionapplies 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-actionapplies to this packet; if neither of the token bytes for normal burst or excess burst is enough, the violate-actionapplies 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