Policing Tools | Network Quality of Service Technologies

Policers monitor traffic flows and identify and respond to traffic violations. For example, policers can monitor TelePresence flows at the campus access edge. Because TelePresence flows are bounded (to typically 5 Mbps per screen at 1080p), flows in excess of such bounds would be indicative of network abuse and can be immediately identified and responded to by policers.

Policers achieve these objectives by performing ongoing checks for traffic violations and taking immediate prescribed actions when such violations occur. For example, a policer can determine if the offered load is in excess of the defined traffic rate and then drop the out-of-contract traffic, as illustrated in Figure 1.

 
Figure 1: A generic policer

Additionally, policers can re-mark excess traffic to identify (but not necessarily drop) traffic that exceeds a given traffic contract, which might be valuable for reporting, billing, or capacity planning purposes. In such a role, the policer is called a marker. Figure 2 illustrates a policer functioning as a marker.

 
Figure 2: A policer as a marker

Cisco IOS policers are modeled after token bucket algorithms. Essentially, these algorithms are metering engines that keep track of how much traffic might be sent to conform to the specified traffic rates.

A token, in everyday use, is an item given to an individual that represents the right to use a given service, such as to ride on the subway or to play a video game, and so on. In QoS terminology, a token permits the policing algorithm to send a single bit (or in some cases, a byte) of traffic. Typically, these tokens are granted at the beginning of a second, according to the defined policing rate, referred to as the Committed Information Rate (CIR).

Tokens granted at the beginning of each second of operation are placed in a logical cache, referred to as the bucket. A key difference in policing algorithms is how unused tokens are dealt with at the end of each second: Some policers allow unused tokens to accumulate in the bucket, whereas others force unused tokens to be discarded. These differences, and the effects on traffic policing, is discussed in more detail shortly.

For example, if the CIR is set to 8000 bps, then 8000 tokens are placed in the bucket at the beginning of each second. Each time a bit of traffic is offered to the policer, the bucket is checked for tokens. If there are tokens in the bucket, the traffic is passed. One token is removed from the bucket for each bit of traffic that is passed, and such traffic is viewed to conform the rate, and the specified action for conforming traffic is taken. (The conforming traffic is typically transmitted unaltered.) When the bucket runs out of tokens, any additional offered traffic is viewed to exceed the rate, and the exceed action is taken. (The exceeding traffic is either re-marked or dropped.)

In addition to defining the CIR, policers require that a committed burst (Bc) also be defined. The committed burst, also known as the normal burst, refers to the bytes allowed in a subsecond traffic burst before packets will be considered to exceed the rate limit.

Operational Availabilities Technologies

As has been shown, the predominant way that availability of a network can be improved is to improve its MTBF by using devices that have redundant components and by engineering the network to be as redundant as possible, leveraging many of the technologies discussed in the previous sections.

However, glancing back to the general availability formula, another approach to improving availability is to reduce MTTR. Reducing MTTR is primarily a factor of operational resiliency.

MTTR operations can be significantly improved in conjunction with device and network redundant design. Specifically, the capability to make changes, upgrade software, and replace or upgrade hardware in a production network is extensively improved due to the implementation of device and network redundancy. The capability to upgrade individualdevices without taking them out of service is based on having internal component redundancy complemented with the system software capabilities. Similarly, by having dual active paths through redundant network devices designed to converge in subsecond timeframes, you can schedule an outage event on one element of the network and allow it to be upgraded and then brought back into service with minimal or no disruption to the network as a whole.

You can also improve MTTR by reducing the time required to perform any of the following operations:

• Failure detection
• Notification
• Fault diagnosis
• Dispatch and Arrival
• Fault repair

Some technologies that can help automate and streamline these operations include the following:

• General Online Diagnostics (GOLD)
• Embedded Event Manager (EEM)
• In Service Software Upgrade (ISSU)
• Online Insertion and Removal (OIR)

TelePresence Audio and Video Technologies

Codec Design Requirements

When Cisco began its quest to design and build a true-to-life telepresence experience, it had a rather large obstacle to overcome. No other vendor at that time had anything that could deliver the level of video and audio quality and integrated systems approach that Cisco wanted to create. So Cisco decided to build the codec from the ground up, purpose-built to meet the following requirements:

• First, it had to deliver multiple channels of 1080p resolution video, at a consistent 30 frames per second, at extremely low encoding and decoding times and at a bandwidth utilization rate the average large enterprise customer could afford to deploy.
• Second, it had to provide multiple, full-duplex channels of wideband audio. Furthermore, those channels could not be mixed together, nor stereo (left/right), but had to be discrete, independent channels to preserve the spatiality and directionality of the audio.
• Third, to meet its ease-of-use and reliability ideals, it had to provide a fully integrated system that could be completely managed by a single interface. Therefore, it could not utilize off-the-shelf components, such as cameras and displays, but needed integrated components that were managed and controlled by the system.
• Fourth, it had to provide integrated, easy-to-use data collaboration and audio conferencing so that participants could easily share documents and presentations with each other and allow audio-only participants to join the meeting.
• Finally, it had to do all these things in a completely standards-based way, leveraging the existing converged IP network and Unified Communications platforms Cisco was famous for.

As luck would have it, the time was right for the development of such a product:

• Digital Signal Processor (DSP) technology was just beginning to be capable of 1080p resolution video at the latency targets required.
• Camera lens and sensor technology was getting small enough to deliver a 1080p camera that was small enough to be discretely mounted over the bezel of the display.
• Display technology in the size (65-inch) and resolution (1080p) required was becoming affordable.
• The networking technologies required to make a system like this manageable and deployable on a converged IP network were finally mature—IP Telephony being one of the driving forces in the decade prior to Cisco TelePresence to allow technologies such as quality of service (QoS), Power over Ethernet (PoE), high availability, and Session Initiation Protocol (SIP) to become mature, allowing the same techniques to be leveraged by Cisco TelePresence.

The word codec is used in two different ways:

• It is used as the name of the physical device containing a CPU, memory, an operating system, Digital Signal Processors (DSP), and audio, video, and network interfaces: the Cisco TelePresence codec.
• It is widely used throughout the industry to refer to various audio and video encoding and decoding algorithms, such as the H.264 and AAC-LD codecs.