Introduction to Traffic Policing, Traffic Shaping

Traffic policing, traffic shaping are key factors in implementing QoS. Traffic policing controls the rate of incoming packets to ensure that network resources are properly allocated. Traffic shaping controls the rate of outgoing packets to allow the traffic rate to match that on the downstream device. These factors work together to provide QoS guarantees on networks.

Traffic Policing

Traffic policing controls the rate of incoming packets to ensure that network resources are properly allocated. If the traffic rate of a connection exceeds the specifications on an interface, traffic policing allows the interface to drop excess packets or re-mark the packet priority to maximize network resource usage and protect carriers' profits.

• CAR
  Traffic policing uses committed access rate (CAR) to control traffic. An example of this process is restricting the rate of Hypertext Transfer Protocol (HTTP) packets to 50% of the network bandwidth.
• Token Bucket
  CAR uses token buckets to meter the traffic rate, as shown in Figure 1. A token bucket can be considered a container of tokens, which has a pre-defined capacity. Tokens are put into the token bucket at a preset rate. When the token bucket is full of tokens, no more tokens can be added.
  
  Figure 1 Traffic policing according to CAR
  
  When a packet arrives, the device obtains enough tokens from the token bucket for packet transmission. If the token bucket does not have enough tokens to send the packet, the packet either waits for enough tokens or is discarded. This feature limits packets to be sent at a rate less than or equal to the rate at which tokens are generated.
• Traffic policing with a single token bucket
  A single token bucket is used for traffic policing when traffic measurement is relatively simple. When a single token bucket is used, packets are forwarded based on the availability of tokens in the token bucket. One token is used to forward one byte of data. If there are enough tokens available to forward a packet, the packet is considered conforming and is marked green. Otherwise, the packet is considered nonconforming or over the limit, and is marked red.
  The following are the two parameters used in traffic policing with a single token bucket:

  • Committed Information Rate (CIR): the rate at which tokens are put into a token bucket. The CIR is expressed in bit/s.
  • Committed Burst Size (CBS): the committed volume of traffic that an interface allows to pass through, also the depth of a token bucket. The CBS is expressed in bytes. The CBS must be greater than or equal to the size of the longest possible packet in the stream. Note that sometimes a single packet can consume all the tokens in the token bucket. The larger the CBS is, the greater the traffic burst can be.
  Each time a packet arrives, the packet is measured. If there are enough tokens in the bucket, the traffic rate is within the allowed range. In this case, the number of tokens equal to the byte size of the forwarded packet. If there are not enough tokens in the bucket, too many tokens are required and the traffic rate is beyond the allowed range.
• Traffic policing with two token buckets
  You can use two token buckets to measure traffic in more complex conditions and implement more flexible traffic policing. These two buckets are called the C and P buckets. Tokens are put in the C bucket at a rate of the CIR and its size is called the CBS. Tokens are put in the P bucket at a rate of the Peak Information Rate (PIR) and its size is called the Peak Burst Size (PBS). Each time the traffic is measured, the following rules are applied:

  • If there are enough tokens in the C bucket, packets are marked green.
  • If there are not enough tokens in the C bucket but enough tokens in the P bucket, packets are marked yellow.
  • If tokens in neither of the buckets are enough, packets are marked red.
  The parameters used in traffic policing with two token buckets are described as follows:

  • CIR: the rate at which tokens are put in the C bucket. The CIR is expressed in bit/s.
  • CBS: the committed volume of traffic that an interface allows to pass through, also the depth of the C bucket. The CBS is expressed in bytes. The CBS must be greater than or equal to the size of the longest possible packet in the stream. Note that sometimes a single packet can consume all the tokens in the token bucket. The larger the CBS is, the greater the traffic burst can be.
  • PIR: the rate at which tokens are put in the P bucket. The PIR is expressed in bit/s.
  • PBS: the maximum volume of traffic that an interface allows to pass through in a traffic burst, also the depth of the P bucket.
  The CX600 uses two algorithms, srTCM and trTCM, to implement traffic policing with two token buckets. The algorithms have two working modes, color-blind and color-aware. The color-blind mode is more commonly used. For details, see the "Overview".
• Traffic Policing Action
  According to different measurement results, TP implements the pre-configured policing actions, which are described as follows:
  • Pass: forwards the packets conforming to the SLA.
  • Discard: drops the packets exceeding the specified limit.
  • Remark: re-marks the packets whose traffic rate is between the CIR and PIR with a lower priority and allows these packets to be forwarded.
• Statistics Collection
  Traffic that enters a network must be controlled, and traffic statistics must be collected. Traditional statistics collection has the following defects:
  • For upstream traffic, only statistics about packets after a CAR operation is implemented can be collected. Statistics about the actual traffic in need and the packet loss during CAR are not provided.
  • For downstream traffic, only statistics about packets after a CAR operation is implemented can be collected. Statistics about the forwarded and dropped packets are not provided.
  Carriers require statistics about traffic that has been implemented with CAR to analyze user traffic beyond the specifications, which provides a basis for persuasion of purchasing a higher bandwidth.
  Using the interface-based CAR statistics collection function, the CX600 can collect and record statistics about the upstream traffic after a CAR operation (the actual access traffic of an enterprise user or an Internet bar), as well as statistics about the forwarded and dropped downstream packets after a CAR operation.

Traffic Shaping

Traffic shaping (TS) is a pro-active way to adjust the traffic output rate. A typical application of TS is to control the volume and burst of outgoing traffic based on the network connection. Thus the packets can be transmitted at a uniform rate.

TS is implemented by using the buffer and token bucket. As shown in Figure 2, after classification, packets are processed as follows:

• Packets to which traffic shaping does not apply are directly forwarded.
• For the packets to which traffic shaping applies, when no General Traffic Shaping (GTS) queue exists, the length of packets is compared with the number of tokens in the token bucket. If there are enough tokens for these packets, the packets are sent. If there are not enough tokens, the GTS queue is enabled where packets are cached. Tokens are put in the token bucket at the user-defined rate, and packets in the GTS queue are removed and sent periodically. As packets are sent, the number of tokens reduces based on the byte size of packets. During packet transmission, the byte size of packets is compared with the number of tokens in the token bucket. The number of tokens in the token bucket stops decreasing when all the packets in the GTS queue are sent or can no longer be sent.
• When the GTS queue exists, packets that go through traffic shaping enter the queue directly, waiting to be scheduled at fixed intervals by the GTS queue.
• If the GTS queue is full when new packets arrive at the queue, the packets are dropped.

Figure 2 Traffic shaping process

In Figure 3, Device A sends packets to Device B. Device B performs TP on the packets, and directly drops the nonconforming packets.

Figure 3 Traffic shaping

To reduce the number of packets that are unnecessarily dropped, you can implement TS on the outbound interface of Device A. Packets over the specification are cached onDevice A. When being able to send packets, TS gets the cached packets from the buffered queues and sends them out. Therefore, all the packets sent to Device B conform to the traffic specification.

The main differences between TS and TP are as follows:

• TS buffers excess traffic over the specifications. TP drops excess traffic over the specifications or re-marks such traffic with a lower priority.
• TS brings delay and jitter but rarely leads to packet loss. TP brings no delay or jitter but leads to packet loss.