Policing marks down or discards out-of-profile traffic to fulfill the Service Level Agreement (SLA), mitigate security threats such as DOS/DDOS attacks, alleviate traffic congestion and ensure high availability. As an important and effective Quality of Service (QoS) mechanism, policing is widely deployed by enterprises and service providers.
Various data plane statistics are maintained for each QoS policer in most packet-forwarding devices (e.g., switches, routers, etc.). Example command line interfaces (CLIs) and outputs showing data plane statistics for CISCO CATALYST 6K AND CISCO NEXUS 7K switches from CISCO SYSTEMS, INC., SAN JOSE, Calif. are discussed below. Policer statistics can describe dropped packets that are out-of-profile (e.g., violate the SLA). It should be understood that policer drops are different from queuing drops. For example, policer drops indicate that excess traffic from a source is above the specified rate limit, while queuing drops are symptoms of network congestion. If policer drops are observed, it can be beneficial to enforce the same QoS policing in the earliest possible upstream network devices (i.e., networking devices closest to misbehaving traffic sources). Otherwise, even though the policing is enforced in downstream network devices, the out-of-profile packets to be dropped inevitably waste networking resources, decrease good throughput, worsen congestion and cause more delay/jitter. However, due to application distribution, server virtualization, dynamic traffic patterns, complex networking topology, etc., it is not always straightforward to identify early in upstream network devices where a policer can be enforced. In many cases, out-of-profile traffic traverses through many network devices in the core before being dropped according to the policer policy.
Manual micro-level QoS policy reconfiguration is known in the art. For example, in response to a short-duration burst, a real-time alarm can be raised to promptly alert network administrators and trigger manual micro-level policer policy re-configuration. For example, it is possible to propagate QoS policies using a Border Gateway Protocol (BGP)-enabled device. A QoS policy can be manually configured/re-configured at the BGP-enabled device. The QoS policy can then be propagated to remote BGP-enabled devices via BGP messages and installed at the remote BGP-enabled devices (but not the local BGP-enabled device). QoS policy propagation via BGP is discussed in detail in Cisco Systems, Inc., Cisco IOS Quality of Service Solutions Configuration Guide: Configuring QoS Policy Propagation via Border Gateway Protocol, available at http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfprop.pdf. However, manual reconfiguration can be both tedious and prone to errors, especially due to application distribution, server virtualization, dynamic traffic patterns, complex networking topology, etc.
Additionally, automatic macro-level QoS policy reconfiguration is known in the art. Policer statistics can be collected during longer period of times (e.g., for days, weeks, or even longer) and then sent to a comprehensive network management system for traffic profiling. The network management system can automatically generate a set of QoS policies that is expected to better meet business needs with macro-level re-configuration. Using this type of solution, it is possible to intelligently generate and deploy QoS policies based on underlying network topology and network traffic profiles at different sites. CISCO AUTOQOS from CISCO SYSTEMS, INC., SAN JOSE, Calif. is one example and is discussed in detail in Cisco Systems, Inc., AutoQoS Technical Presentation (2006), available at http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ps6613/ps6656/prod_presentatipr0900aecd80313756.pdf. However, because statistics are collected over longer periods of time, the solution is not capable of immediately responding to short-duration bursts. Also, system-level configuration changes are required.
Further, distributed policing is also known. For example, distributed policing enables multiple devices across an entire network to police traffic flows that matches the same packet classification rules. According to distributed policing techniques, a single logical policing view across an entire network is synchronized by frequently reporting local policing control data and announcing global policing control data. Distributed policing is discussed in detail in U.S. Pat. No. 6,826,150 to Bhattacharya et al. Although distributed policing provides a mechanism to regulate misbehaving traffic flows in a real-time, it requires a complicated framework and associated control overhead to maintain a single logical policing view. In addition, each network device needs to provide resources for the same policing at all times.
USPTO Backgrounds
USPTO Backgrounds