Multilevel coupled policer
AssigneeCisco Technology, Inc.
InventorsJohn H. W. Bettink, David J. Tsiang, Clarence Filsfils
Life of this patent
Estimating the term…
Loading patent…
AssigneeCisco Technology, Inc.
InventorsJohn H. W. Bettink, David J. Tsiang, Clarence Filsfils
Estimating the term…
A multilevel coupled policer is configured to police packets using at least two policing levels, including a first-level of class policers and a second-level aggregate policer. The multilevel coupled policer is configured to share bandwidth of the aggregate policer among packet traffic corresponding to the class policers based on the packet traffic. The multilevel coupled policer is configured to apply a particular class policer corresponding to a particular packet to identify a tentative policing action. The multilevel coupled policer is configured to apply the second-level aggregate policer to the particular packet based on the identified the tentative policing action and a result of a comparison operation of the number of tokens in one or more token buckets associated with the second-level aggregate policer and the length of the particular packet in order to determine a final policing action for marking and/or applying to the particular packet.
A method for policing packets using a multilevel coupled policer scheme including a first-level plurality of class policers and a second-level aggregate policer, with each of said policers associated with a token bucket, the multilevel coupled policer scheme configured to share bandwidth of the aggregate policer among packet traffic corresponding to the class policers based on said packet traffic, the method comprising:
A multilevel coupled policer configured to police packets, the multilevel coupled policer including:
Dependencies are inferred from the claim text.
From the US filing history. Foreign family members aren’t listed.
Drawings are temporarily unavailable. Open the PDF at USPTO
Traffic control in data switching networks: flow control; Congestion control
Flow control; Congestion control: traffic policing
Flow control; Congestion control: using token-bucket
Traffic characterised by specific attributes, e.g. priority or QoS: relying on flow classification, e.g. using integrated services [IntServ]
About 2 years 6 months of term left · ends 3 May 2029 (estimated)
One embodiment of the invention relates to communications and computer systems, especially routers, packet switching systems, and other devices; and more particularly, one embodiment relates to multilevel coupled policers and their use for policing packet traffic.
The communications industry is rapidly changing to adjust to emerging technologies and ever increasing customer demand. This customer demand for new applications and increased performance of existing applications is driving communications network and system providers to employ networks and systems having greater speed and capacity (e.g., greater bandwidth). In trying to achieve these goals, a common approach taken by many communications providers is to use packet switching technology. Increasingly, public and private communications networks are being built and expanded using various packet technologies, such as Internet Protocol (IP). Note, nothing described or referenced in this document is admitted as prior art to this application unless explicitly so stated.
Consumers and designers of these systems typically desire high reliability and increased performance at a reasonable price. Also, certain users and applications of communications services demand a guaranteed quality of service. To help in this regard, communications systems may meter or police the amount of traffic allowed into a communications component or across a link. For example, a line card might assign and enforce an average traffic rate while accommodating a limited burstiness in the traffic.
The appended claims set forth the features of the invention with particularity. The invention, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:
FIG. 1A is a block diagram of a prior art policer configuration;
FIG. 1B is a block diagram of a prior art hierarchical policer configuration;
Disclosed are, inter alia, methods, apparatus, data structures, computer-readable media, mechanisms, and means for policing traffic using one or more multilevel coupled policers.
Note, embodiments described herein include various elements and limitations, with no one element or limitation contemplated as being a critical element or limitation. Each of the claims individually recites an aspect of the invention in its entirety. Moreover, some embodiments described may include, but are not limited to, inter alia, systems, networks, integrated circuit chips, embedded processors, ASICs, methods, and computer-readable media containing instructions. One or multiple systems, devices, components, etc. may comprise one or more embodiments, which may include some elements or limitations of a claim being performed by the same or different systems, devices, components, etc. The embodiments described hereinafter embody various aspects and configurations within the scope and spirit of the invention, with the figures illustrating exemplary and non-limiting configurations. Note, computer-readable media and means for performing methods and processing block operations are disclosed and are in keeping with the extensible scope and spirit of the invention.
As used herein, the term “packet” refers to packets of all types or any other units of information or data, including, but not limited to, frames, fixed length cells and variable length packets, each of which may or may not be divisible into smaller packets or cells. The term “packet” as used herein also refers to both the packet itself or a packet indication, such as, but not limited to all or part of a packet or packet header, a data structure value, pointer or index, or any other part or direct or indirect identification of a packet or information associated therewith. For example, often times a router operates on one or more fields or data of a packet, especially the header, so the body of the packet is often stored in a separate memory while the packet header is manipulated, and based on the results of the processing of the packet (i.e., the packet header in this example), the entire packet is forwarded or dropped, etc. Additionally, these packets may contain one or more types of information, including, but not limited to, voice, data, video, and audio information. The term “item” is used generically herein to refer to a packet or any other unit or piece of information or data, a device, component, element, or any other entity. The phrases “processing a packet” and “packet processing” typically refer to performing some steps or actions based on the packet contents (e.g., packet header or other fields), and such steps or action may or may not include modifying, storing, dropping, and/or forwarding the packet and/or associated data. The term or reference to “dropping” a packet or a variant thereof (e.g., drop the packet, the packet is dropped, etc.) is used herein to identify the physical dropping of the packet, causing the packet to be dropped, and/or marking or distinguishing the packet for subsequent dropping or potentially different processing (e.g., a higher probability of being dropped by subsequent processing, Early Congestion Notification marking, etc.) than that of an “admitted” packet. The term “interface” of a networked device broadly refers to a physical interface, a logical interface (e.g., a portion of a physical interface or sometimes referred to in industry as a sub-interface—for example, such as, but not limited to a particular VLAN associated with a network interface), and/or a virtual interface (e.g., traffic grouped together based on some characteristic—for example, such as, but not limited to, a tunnel interface), or even a “port” as commonly used in bridging terminology.