DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This communication is in responsive to the Application filed on February 29, 2024, in which claims 1-20 have been presented for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims 12, 13 and 15 are rejected under 35 U.S.C. 102(a)(1). Claims 1-11, 14 and 16-20 are rejected under 35 U.S.C. 103.
Information Disclosure Statement
4. The information disclosure statements, filed February 29, 2024, and June 4, 2025, are in compliance with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609. They have been placed in the application file, and the information referred to therein has been considered as to the merits.
Claim Rejections - 35 USC § 102
5. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
6. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
7. Claims 12, 13 and 15 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Francois Labonte (United States Patent Application Publication No. 2021/0399988 A1), hereinafter “Labonte”.
Regarding claim 12, Labonte discloses a method of operating a network device comprising: receiving data packets (wherein packets are received at a network device 1000, such as that shown in FIG. 10. In particular, network device 1000 is equipped with internal fabric module 1004 and I/O modules 1006(1)-1006(P), which collectively represent the data, or forwarding, plane of network device 1000. Internal fabric module 1004 is configured to interconnect the various other modules of network device 1000. Each I/O module 1006(1)-1006(P) includes one or more input/output ports 1010(1)-1010(Q) that are used by network device 1000 to send and receive network packets. See also network device 400 illustrated in FIG. 4A, receiving incoming packets 408) (Labonte, FIGS. 4A and 10, paragraph [0040]); determining whether the data packets are associated with a given flow (wherein with continued reference to FIG. 4A, Labonte discloses a network device 400 having a policer agent 406 that configures quality of service (QoS) policers 400a-n with respective maximum burst sizes 407. Labonte further teaches that maximum burst sizes may refer to a threshold under which a given burst of packets/traffic is permitted to be forwarded by policer 108 (shown in FIG. 1, as well as in FIG. 4A as QoS policers 400a-n) and above which it is not. More particularly, a burst of traffic having a size (e.g., in packets) that is less than the maximum burst size may be forwarded (e.g., if enough time has elapsed since a prior arriving burst). However, when a burst of traffic has a size that is greater than the maximum burst size, Labonte teaches that a portion of the burst that is under the maximum burst size may be forwarded while the portion of the burst that is over the maximum burst size may be dropped. As shown in FIG. 4A, policer agent 406 calculates maximum burst sizes 407 as a function of maximum burst time 416, maximum channel rates 402, and policer rates 404. For example, for each of QoS policers 400a-n, policer agent 406 may calculate a maximum burst size as a function of a maximum burst time, a maximum channel rate, and a policer rate associated with each particular QoS policer 400a-n. In the given embodiment, policer agent 406 configures each of QoS policers 400a-n with respective maximum burst sizes 411a-n. In this manner, Labonte teaches that each of policers 400a-n is provisioned with a maximum burst size specific to its policer rate and maximum channel rate. As such, Labonte teaches that network device 400 is configured such that data packets of a given flow are routed to the appropriate QoS policer 400a-n associated with the packets matching the maximum burst sizes 411a-n) (Labonte, FIGS. 1 and 4A, paragraphs [0020], [0028] and [0030]); in response to determining that the data packets are associated with the given flow, conveying the data packets to a first policer (wherein again, packets of a given flow are routed to the appropriate QoS policer 400a-n associated with the packets matching the respective maximum burst sizes 411a-n. For example, a packet having a maximum burst size of 411a would be routed to respective QoS policer 400a) (Labonte, FIG. 4A, paragraph [0030]); and in response to determining that the data packets are not associated with the given flow, conveying the data packets to a second policer different than the first policer (wherein continuing with the example above, a packet having a maximum burst size of 411b would be routed to [a different] respective QoS policer 400a) (Labonte, FIG. 4A, paragraph [0030]).
Regarding claim 13, Labonte discloses the method of claim 12, further comprising: with the first policer, limiting a flow rate of the data packets to be processed to a first value (wherein as above, after calculating the maximum burst size (MBS), policer agent 106 (See FIG. 1, corresponding to policer agent 406 in FIG. 4A) configures policer 108 with maximum burst size 122 such that policer 108 polices traffic according to maximum burst size 122. That is, in FIG. 4A, policer agent 406 configures each of QoS policers 400a-n with their appropriate maximum burst size, such that the flow rate is limited by their respective maximum burst size 411a-n) (Labonte, FIGS. 1 and 4A, paragraphs [0023] and [0030]); and with the second policer, limiting a flow rate of the data packets to be processed to a second value greater than the first value (wherein again, with second QoS policer (e.g., QoS policer 400b), traffic is limited according to maximum burst size 411b) (Labonte, paragraphs [0023] and [0030]).
Regarding claim 15, Labonte discloses the method of claim 12, wherein determining whether the data packets are associated with the given flow comprises determining whether at least a portion of header information in the data packets match an entry in a traffic policy database stored on the network device (wherein QoS policers 400a-n may police traffic based on source address or destination address of incoming traffic. With particular reference to FIG. 3, Labonte teaches that policers 314a-n may have an associated maximum burst time, maximum channel rate, and policer rate stored (as policy information) in policer agent 306. As further shown in FIGS. 4B and 5, Labonte illustrates a data structure for configuring a plurality of traffic type policers 500a-n of a network device 500. In particular, data structure 501 (See FIG. 5, illustrating policy information including each of maximum burst time, maximum channel rate, and policer rate) may be stored in memory or in a database (e.g., database 490 in FIG. 4B) in the control plane (i.e., policer agent) of a network device. Thus, the network devices 400, 500 may receive, process, and transmit traffic comprising packets using header information, and comparing with maximum burst size information in database 490) (Labonte, FIGS. 3, 4B and 5, paragraphs [0025], [0029], [0033] and [0042]).
Claim Rejections - 35 USC § 103
8. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
9. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
10. Claims 1-8, 10, 14, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Labonte in view of Smethurst et al. (United States Patent No. US 7,224,668 B1), hereinafter “Smethurst”.
Regarding claim 14, Labonte discloses the method of claim 12, but does not explicitly disclose further comprising: before determining whether the data packets are associated with the given flow, determining whether the data packets comprise control plane packets to be processed in a control plane of the network device. However in an analogous art, Smethurst discloses before determining whether data packets are associated with a given flow, determining whether the data packets comprise control plane packets to be processed in a control plane of a network device (wherein Smethurst teaches that a full range of traditional port control features can be applied to help protect a control plane 150 of an internetworking device 100, such as a router, bridge, switch, server or the like (See FIG. 1), from a DoS attack, or to provide other QoS. Such control features can, e.g., be implemented as a set of programmed rules that determine whether or not packets arriving at the control plane port 140 qualify for delivery to the control plane and at what level of QoS) (Smethurst, FIG. 1, col. 4, ll. 47-48, col. 6, ll. 1-7). Labonte and Smethurst are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte and Smethurst before him or her, to modify the network device of Labonte to include the additional limitation of before determining whether data packets are associated with a given flow, determining whether the data packets comprise control plane packets to be processed in a control plane of a network device, as disclosed by Smethurst, with reasonable expectation that this would result in a network device that provided extra protection to the control plane, particularly by applying rules to a packet if the packet has been first determined to have a destination of the control plane, and then applying the specific control plane feature (i.e., rate limit with access list), thus preventing even correctly addressed packets from progressing up to any of the control plane processes if the specific rate limit has been exceeded (See Smethurst, col. 6, ll. 12-23). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte with Smethurst to obtain the invention as specified in claim 14.
Regarding claim 1, Labonte discloses a method of operating a network device having a packet processor and a central processing unit (CPU) (wherein as discussed and shown above with respect to independent claim 12, a network device 1000, such as that shown in FIG. 10 includes a management module 1002 having one or more management central processing units (CPUs) 1008 for managing/controlling the operation of the device, as well as an internal fabric module 1004 and I/O modules 1006(1)-1006(P), which collectively represent the data, or forwarding, plane of network device 1000 (which Examiner maps to the recited “packet processor”)) (Labonte, FIG. 10, paragraphs [0039] and [0040]), the method comprising: with the packet processor, receiving data packets (wherein as set forth above, packets are received at a network device 1000, such as that shown in FIG. 10. In particular, each I/O module 1006(1)-1006(P) includes one or more input/output ports 1010(1)-1010(Q) that are used by network device 1000 to send and receive network packets. See also network device 400 illustrated in FIG. 4A, receiving incoming packets 408 at packet processing pipeline 450b) (Labonte, FIGS. 4A and 10, paragraph [0040]); determining whether the data packets match a given flow (wherein with continued reference to FIG. 4A, Labonte discloses a network device 400 having a policer agent 406 that configures quality of service (QoS) policers 400a-n with respective maximum burst sizes 407. Labonte further teaches that maximum burst sizes may refer to a threshold under which a given burst of packets/traffic is permitted to be forwarded by policer 108 (shown in FIG. 1, as well as in FIG. 4A as QoS policers 400a-n) and above which it is not. More particularly, a burst of traffic having a size (e.g., in packets) that is less than the maximum burst size may be forwarded (e.g., if enough time has elapsed since a prior arriving burst). However, when a burst of traffic has a size that is greater than the maximum burst size, Labonte teaches that a portion of the burst that is under the maximum burst size may be forwarded while the portion of the burst that is over the maximum burst size may be dropped. As shown in FIG. 4A, policer agent 406 calculates maximum burst sizes 407 as a function of maximum burst time 416, maximum channel rates 402, and policer rates 404. For example, for each of QoS policers 400a-n, policer agent 406 may calculate a maximum burst size as a function of a maximum burst time, a maximum channel rate, and a policer rate associated with each particular QoS policer 400a-n. In the given embodiment, policer agent 406 configures each of QoS policers 400a-n with respective maximum burst sizes 411a-n. In this manner, Labonte teaches that each of policers 400a-n is provisioned with a maximum burst size specific to its policer rate and maximum channel rate. As such, Labonte teaches that network device 400 is configured such that data packets of a given flow are routed to the appropriate QoS policer 400a-n associated with the packets matching the maximum burst sizes 411a-n) (Labonte, FIGS. 1 and 4A, paragraphs [0020], [0028] and [0030]); and in response to determining that the data packets match the given flow, limiting a flow rate of the data packets sent to the CPU for processing by a first amount (wherein as above, after calculating the maximum burst size (MBS), policer agent 106 (See FIG. 1, corresponding to policer agent 406 in FIG. 4A) configures policer 108 with maximum burst size 122 such that policer 108 polices traffic according to maximum burst size 122. That is, in FIG. 4A, policer agent 406 configures each of QoS policers 400a-n with their appropriate maximum burst size, such that the flow rate is limited by their respective maximum burst size 411a-n) (Labonte, FIGS. 1 and 4A, paragraphs [0023] and [0030]). Labonte does not explicitly disclose determining whether the data packets comprise control plane packets to be processed by the CPU; and in response to determining that the data packets comprise control plane packets to be processed by the CPU, determining whether the data packets match a given flow. In an analogous art, however, Smethurst discloses determining whether the data packets comprise control plane packets to be processed by the CPU (wherein Smethurst teaches that a full range of traditional port control features can be applied to help protect a control plane 150 of an internetworking device 100, such as a router, bridge, switch, server or the like (See FIG. 1), from a DoS attack, or to provide other QoS. Such control features can, e.g., be implemented as a set of programmed rules that determine whether or not packets arriving at the control plane port 140 qualify for delivery to the control plane and at what level of QoS) (Smethurst, FIG. 1, col. 4, ll. 47-48, col. 6, ll. 1-7); and in response to determining that the data packets comprise control plane packets to be processed by the CPU, determining whether the data packets match a given flow (wherein in one particular example, Smethurst teaches that aggregate control plane services for Telnet type traffic are rate limited. In a first construction 500, a class map is defined as “telnet-class”. Smethurst teaches that these packets are, e.g., identified by matching the telnet access group 140. Telnet access group 140 matches packets with “TCP field” equal to “telnet”) (Smethurst, col. 7, ll. 30-35). As discussed and shown above, Labonte and Smethurst are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte and Smethurst before him or her, to modify the network device of Labonte to include the additional limitations of determining whether the data packets comprise control plane packets to be processed by the CPU; and in response to determining that the data packets comprise control plane packets to be processed by the CPU, determining whether the data packets match a given flow, as disclosed by Smethurst, with reasonable expectation that this would result in a network device that provided extra protection to the control plane, particularly by applying rules to a packet if the packet has been first determined to have a destination of the control plane, and then applying the specific control plane feature (i.e., rate limit with access list), thus preventing even correctly addressed packets from progressing up to any of the control plane processes if the specific rate limit has been exceeded (See Smethurst, col. 6, ll. 12-23). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte with Smethurst to obtain the invention as specified in claim 1.
As to claim 2, Labonte-Smethurst discloses the method of claim 1, further comprising: in response to determining that the data packets do not match the given flow, limiting a flow rate of the data packets sent to the CPU for processing by a second amount different than the first amount (wherein continuing with the example above, a packet having a maximum burst size of 411b would be routed to [a different] respective QoS policer 400a) (Labonte, FIG. 4A, paragraph [0030]). The motivation regarding the obviousness of claim1 is also applied to claim 2.
Regarding claim 3, Labonte-Smethurst discloses the method of claim 2, wherein determining whether the data packets comprise control plane packets comprises monitoring a destination address of the data packets (wherein one example is shown in the flow chart in FIG. 4. In a first state 400, a line card detects a packet and delivers it to the central switch engine 130. In a next step 402, the central switch engine 130 performs normal input port services and Quality of Service (QoS) processing on the received packet. In a next state 403, the central switch engine 130 performs its normal Layer 2 and Layer 3 switching/routing decision. In the case of a normal transit packet, the packet would be routed to a destination port 120 on an associated line card 110, using e.g., the forwarding table information 160. If, however, the packet is destined for a known control plane 150 address, or to an address not on a forwarding table 160, the packet is tagged being destined to as a control plane port. The packet is then routed through the aggregate control plane port 140) (Smethurst, FIG. 4, col. 6, l. 65-col. 7, l. 12). Again, Labonte and Smethurst are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte and Smethurst before him or her, to modify the network device of Labonte to include the additional limitation of wherein determining whether the data packets comprise control plane packets comprises monitoring a destination address of the data packets, as disclosed by Smethurst, with reasonable expectation that this would result in ensuring packets were properly routed up to the control plane, and providing appropriate rate limiting thus further protecting the control plane (See Smethurst, col. 6, ll. 18-23). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte with Smethurst to obtain the invention as specified in claim 3.
Regarding claim 4, Labonte-Smethurst discloses the method of claim 2, wherein determining whether the data packets match the given flow comprises monitoring whether at least a portion of header information in the data packets matches an entry in a CPU traffic policy database on the packet processor (wherein QoS policers 400a-n may police traffic based on source address or destination address of incoming traffic. With particular reference to FIG. 3, Labonte teaches that policers 314a-n may have an associated maximum burst time, maximum channel rate, and policer rate stored (as policy information) in policer agent 306. As further shown in FIGS. 4B and 5, Labonte illustrates a data structure for configuring a plurality of traffic type policers 500a-n of a network device 500. In particular, data structure 501 (See FIG. 5, illustrating policy information including each of maximum burst time, maximum channel rate, and policer rate) may be stored in memory or in a database (e.g., database 490 in FIG. 4B) in the control plane (i.e., policer agent) of a network device. Thus, the network devices 400, 500 may receive, process, and transmit traffic comprising packets using header information, and comparing with maximum burst size information in database 490) (Labonte, FIGS. 3, 4B and 5, paragraphs [0025], [0029], [0033] and [0042]). The motivation regarding the obviousness of claim1 is also applied to claim 4.
Regarding claim 5, Labonte-Smethurst discloses the method of claim 2, further comprising: with a dynamically configured policer, limiting the flow rate of the data packets sent to the CPU for processing by the first amount (at least impliedly, as Labonte teaches that a first policer 108 may be configured by policer agent 106, and then plurality of additional policers may be configured with respective maximum burst sizes such as a maximum burst size 122. More particularly, Labonte teaches that the policer rate, maximum data rate and maximum burst time are a first policer rate, maximum data rate, and maximum burst time, respectively, for the initial policer. As well, Labonte teaches receiving a plurality of additional policer rates, determining a plurality of additional maximum burst sizes based on the plurality of additional policer rates, one or more maximum data rates, and one or more maximum burst times, and configuring a plurality of policers in the network device to police traffic based on the plurality of additional maximum burst sizes. For clarity, Examiner maps the recited “dynamically configured policer” to the disclosed additional plurality of policers, configured for the plurality of additional maximum burst sizes) (Labonte, paragraphs [0019] and [0053]); and with a statically configured policer, limiting the flow rate of the data packets sent to the CPU for processing by the second amount (wherein again, Labonte teaches configuring a first policer, which Examiner maps to the recited “statically configured policer”) (Labonte, paragraphs [0019] and [0053]). The motivation regarding the obviousness of claim 1 is also applied to claim 5.
Regarding claim 6, Labonte-Smethurst discloses the method of claim 2, further comprising: after determining that the data packets comprise control plane packets to be processed by the CPU, conveying the data packets from the packet processor to the CPU (wherein Smethurst teaches that packets received from the ports 120 are fed to a route processor 125 (See FIG. 1), which includes a central switch engine 130 and further includes the control plane 150 running on the route processor 125) (Smethurst, FIG. 1, col. 4, ll. 55-60); and updating a flow table on the CPU with flow data on the data packets (wherein Smethurst further teaches that the control plane 150 functions largely independently of the data plane 135. The control plane 150 is responsible for processing routing, signaling and control protocols that dictate the packet forwarding behavior of the data plane 135. Such protocols typically manipulate forwarding tables 160, per flow Quality of Service (QoS) tables 161, access control lists 162, and the like are utilized by the device 100 to make packet forwarding decisions. For example, the control plane 150 might manipulate the forwarding table 160 in the switch engine 130 or change the state of one of the port interfaces 120 in a line card 110 to effect a route change) (Smethurst, col. 5, ll. 10-21). Again, Labonte and Smethurst are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte and Smethurst before him or her, to modify the network device of Labonte to include the additional limitations of after determining that the data packets comprise control plane packets to be processed by the CPU, conveying the data packets from the packet processor to the CPU; and updating a flow table on the CPU with flow data on the data packets, as disclosed by Smethurst, with reasonable expectation that this would result in the ability to effect an appropriate route change when needed, thereby providing enhanced Denial of Service (DoS) protection, or otherwise maintaining a specific Quality of Service (QoS) at the control plane 150, particularly by maintaining packet forwarding and protocol states while the network device is either under attack or experiencing normal to heavy traffic load (See Smethurst, col. 5, ll. 17-28). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte with Smethurst to obtain the invention as specified in claim 6.
Regarding claim 7, Labonte-Smethurst discloses the method of claim 6, further comprising: with a policer manager on the CPU, monitoring the flow data from the flow table and dynamically installing a flow policer in the packet processor for limiting the flow rate of the data packets sent to the CPU for processing by the first amount (wherein policer agent 106 configures policer 108 for limiting the flow rate based on the computed maximum burst size 122) (Labonte, paragraph [0019]). The motivation regarding the obviousness of claim 1 is also applied to claim 7.
Regarding claim 8, Labonte-Smethurst discloses the method of claim 7, further comprising: with the policer manager, programming an entry in a CPU traffic policy database on the packet processor (wherein again, the data structure 501 (See again, FIGS. 3 and 5) includes policy information with entries such as maximum burst time, maximum channel rate, and policer rate, which may be stored in memory or in a database (e.g., database 490 in FIG. 4B) in the control plane (i.e., policer agent) of a network device) (Labonte, FIGS. 3, 4B and 5, paragraphs [0025], [0029] and [0033]), wherein determining whether the data packets match the given flow comprises monitoring whether at least a portion of header information in the data packets matches the entry in the CPU traffic policy database (wherein the network devices 400, 500 may receive, process, and transmit traffic comprising packets using header information, and comparing with maximum burst size information in database 490) (Labonte, paragraph [0042]). The motivation regarding the obviousness of claim1 is also applied to claim 8.
Regarding claim 10, Labonte-Smethurst discloses the method of claim 6, further comprising: with a policer manager on the CPU, monitoring the flow data from the flow table and programming an entry in a CPU traffic policy database on the packet processor (wherein again, the data structure 501 (See again, FIGS. 3 and 5) includes policy information with entries such as maximum burst time, maximum channel rate, and policer rate, which may be stored in memory or in a database (e.g., database 490 in FIG. 4B) in the control plane (i.e., policer agent) of a network device) (Labonte, FIGS. 3, 4B and 5, paragraphs [0025], [0029] and [0033]), wherein determining whether the data packets match the given flow comprises monitoring whether at least a portion of header information in the data packets matches the entry in the CPU traffic policy database(wherein the network devices 400, 500 may receive, process, and transmit traffic comprising packets using header information, and comparing with maximum burst size information in database 490) (Labonte, paragraph [0042]). The motivation regarding the obviousness of claim1 is also applied to claim 10.
As to claim 18, Labonte discloses a network device (wherein as discussed and shown above with respect to independent claim 12, Labonte discloses a network device 1000 (See again, FIG. 10) including a management module 1002 having one or more management central processing units (CPUs) 1008 for managing/controlling the operation of the device, as well as an internal fabric module 1004 and I/O modules 1006(1)-1006(P), which collectively represent the data, or forwarding, plane of network device 1000. See also FIG. 1, which illustrates network device 100, as well as FIGS. 4A and 4B, which illustrate network device 400) (Labonte, FIGS. 1, 4B and 10, paragraphs [0039] and [0040]) comprising: control plane processing circuitry configured to execute an operating system of the network device (wherein network device 100 includes control plane 102, which configures, manages, and monitors the operation of data plane 104) (Labonte, FIGS. 1, 4A and 4B, paragraphs [0017] and [0048]); and packet processing circuitry (wherein as given above, network device 1000 further includes an internal fabric module 1004 and I/O modules 1006(1)-1006(P), which collectively represent the data, or forwarding, plane of network device 1000 (which Examiner maps to the recited “packet processing circuitry”)) (Labonte, FIG. 10, paragraphs [0039] and [0040]) configured to: receive data packets (wherein as set forth above, packets are received at a network device 1000, such as that shown in FIG. 10. In particular, each I/O module 1006(1)-1006(P) includes one or more input/output ports 1010(1)-1010(Q) that are used by network device 1000 to send and receive network packets. See also network device 400 illustrated in FIG. 4A, receiving incoming packets 408 at packet processing pipeline 450b) (Labonte, FIGS. 4A and 10, paragraph [0040]); determine whether the data packets are part of a given flow (wherein with continued reference to FIG. 4A, Labonte discloses a network device 400 having a policer agent 406 that configures quality of service (QoS) policers 400a-n with respective maximum burst sizes 407. Labonte further teaches that maximum burst sizes may refer to a threshold under which a given burst of packets/traffic is permitted to be forwarded by policer 108 (shown in FIG. 1, as well as in FIG. 4A as QoS policers 400a-n) and above which it is not. More particularly, a burst of traffic having a size (e.g., in packets) that is less than the maximum burst size may be forwarded (e.g., if enough time has elapsed since a prior arriving burst). However, when a burst of traffic has a size that is greater than the maximum burst size, Labonte teaches that a portion of the burst that is under the maximum burst size may be forwarded while the portion of the burst that is over the maximum burst size may be dropped. As shown in FIG. 4A, policer agent 406 calculates maximum burst sizes 407 as a function of maximum burst time 416, maximum channel rates 402, and policer rates 404. For example, for each of QoS policers 400a-n, policer agent 406 may calculate a maximum burst size as a function of a maximum burst time, a maximum channel rate, and a policer rate associated with each particular QoS policer 400a-n. In the given embodiment, policer agent 406 configures each of QoS policers 400a-n with respective maximum burst sizes 411a-n. In this manner, Labonte teaches that each of policers 400a-n is provisioned with a maximum burst size specific to its policer rate and maximum channel rate. As such, Labonte teaches that network device 400 is configured such that data packets of a given flow are routed to the appropriate QoS policer 400a-n associated with the packets matching the maximum burst sizes 411a-n) (Labonte, FIGS. 1 and 4A, paragraphs [0020], [0028] and [0030]); rate limit the data packets by a first amount in response to determining that the data packets satisfy a set of criteria (wherein as above, after calculating the maximum burst size (MBS), policer agent 106 (See FIG. 1, corresponding to policer agent 406 in FIG. 4A) configures policer 108 with maximum burst size 122 such that policer 108 polices traffic according to maximum burst size 122. That is, in FIG. 4A, policer agent 406 configures each of QoS policers 400a-n with their appropriate maximum burst size, such that the flow rate is limited by their respective maximum burst size 411a-n) (Labonte, FIGS. 1 and 4A, paragraphs [0023] and [0030]); and rate limit the data packets by a second amount, different than the first amount, in response to determining that the data packets do not satisfy the set of criteria (wherein again, and continuing with the example above, a packet having a maximum burst size of 411b would be routed to [a different] respective QoS policer 400a) (Labonte, FIG. 4A, paragraph [0030]). Labonte does not explicitly disclose to determine whether the data packets are destined for the control plane processing circuitry. However in an analogous art, Smethurst discloses to determine whether data packets are destined for control plane processing circuitry (wherein Smethurst teaches that a full range of traditional port control features can be applied to help protect a control plane 150 of an internetworking device 100, such as a router, bridge, switch, server or the like (See FIG. 1), from a DoS attack, or to provide other QoS. Such control features can, e.g., be implemented as a set of programmed rules that determine whether or not packets arriving at the control plane port 140 qualify for delivery to the control plane and at what level of QoS) (Smethurst, FIG. 1, col. 4, ll. 47-48, col. 6, ll. 1-7). Again, Labonte and Smethurst are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte and Smethurst before him or her, to modify the network device of Labonte to include the additional limitation of to determine whether the data packets are destined for the control plane processing circuitry, as disclosed by Smethurst, with reasonable expectation that this would result in a network device that provided extra protection to the control plane, particularly by applying rules to a packet if the packet has been first determined to have a destination of the control plane, and then applying the specific control plane feature (i.e., rate limit with access list), thus preventing even correctly addressed packets from progressing up to any of the control plane processes if the specific rate limit has been exceeded (See Smethurst, col. 6, ll. 12-23). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte with Smethurst to obtain the invention as specified in claim 18.
Regarding claim 19, Labonte discloses the network device of claim 18, wherein the packet processing circuitry comprises content addressable memory (wherein Labonte discloses a content addressable memory (CAM), including a ternary content addressable memory (TCAM). In particular, with reference to FIG. 10, Labonte discloses that I/O module 1006(1)-1006(P) within network device 1000 further includes a routing table 1013(1)-1013(P), which may include a content addressable memory (CAM, such as a TCAM). As well, with reference to FIG. 11, Labonte discloses that ingress pipeline 1110 may include parser 1111, tunnel termination 1112, and a lookup functionality (e.g., using TCAM/SRAM)) (Labonte, FIG. 10, paragraph [0040]). Labonte does not expressly disclose having a first set of entries used to determine whether the data packets are destined for the control plane processing circuitry and having a second set of entries used to determine whether the data packets are part of the given flow. However in an analogous art, Smethurst discloses having a first set of entries used to determine whether the data packets are destined for the control plane processing circuitry (at least impliedly, as Smethurst teaches performing a lookup mechanism to determine whether packets are addressed to the control plane. In particular, Smethurst teaches that control plane port services most importantly determine if a given packet is destined to a control plane process 150, and teaches that such determination can be made through a route look-up mechanism or in other ways. For example, an L2 destination address look-up mechanism may be used for L2 port addresses. Alternatively for an L3 port, L3 destination address lookup functions such as Cisco Express Forwarding (CEF) may be used to identify packets destined to control plane processes 155. Both of the look-up mechanisms are able to identify packets destined for the control plane 150) (Smethurst, col. 5, ll. 56-65) and having a second set of entries used to determine whether the data packets are part of the given flow (wherein as discussed and shown above with respect to claim 1, Smethurst further teaches a particular example whereby aggregate control plane services are limited for Telnet type traffic. In a first construction 500, a class map is defined as “telnet-class”. Smethurst teaches that these packets are e.g., identified by matching the telnet access group 140. Telnet access group 140 matches packets with the “TCP field” equal to “telnet”) (Smethurst, col. 7, ll. 30-35). Again, Labonte and Smethurst are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte and Smethurst before him or her, to modify the network device of Labonte to include the additional limitation of having a first set of entries used to determine whether the data packets are destined for the control plane processing circuitry and having a second set of entries used to determine whether the data packets are part of the given flow, as disclosed by Smethurst, with reasonable expectation that this would result in a network device that provided extra protection to the control plane, particularly by applying rules to a packet if the packet has been first determined to have a destination of the control plane, and then applying the specific control plane feature (i.e., rate limit with access list), thus preventing even correctly addressed packets from progressing up to any of the control plane processes if the specific rate limit has been exceeded (See Smethurst, col. 6, ll. 12-23). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte with Smethurst to obtain the invention as specified in claim 19.
11. Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Labonte in view of Atlas et al. (United States Patent No. US 9,485,118 B1), hereinafter “Atlas”.
Regarding claim 16, Labonte discloses the method of claim 15, but does not explicitly disclose further comprising: gathering flow statistics on the given flow; with a policer manager, monitoring the flow statistics and dynamically installing the first policer based on the flow statistics; and with the policer manager, uninstalling the first policer when the flow statistics satisfy some criteria. However Atlas discloses gathering flow statistics on a given flow (wherein Atlas discloses a network device 6 (See FIG. 1, also shown in greater detail in FIG. 2) having a dynamic policing module 30 (See again, FIG. 2) in the data plane, which is itself shown in greater detail in FIG. 3. Using identifying features, Atlas teaches that classification module 70 of dynamic policing module 30 applies configuration data 75 to policed host-bound traffic 35 to assign network packets of the one or more host-bound packet flows that constitute policed host-bound traffic 35 to one of protocol groups 72. Atlas further teaches that protocol groups 72 categorized as per-session fairness use one or more tables with table entries, or another associative data structure, to allow flow identification and store statistics for identified flows using packets received counters and bytes received counters for each table entry. In some examples (including the illustrated example), protocol groups 72 categorized as per-session fairness use hash tables with hash buckets to allow flow identification and store statistics for identified flows, hashed to the hash buckets, using packets received counters and bytes received counters for each hash bucket) (Atlas, FIGS. 1-3, col. 13, l. 66-col. 14, l. 4, col. 14, l. 67-col. 15, ll. 29-39); with a policer manager, monitoring the flow statistics and dynamically installing the first policer based on the flow statistics (wherein Atlas further teaches that control plane 8 of network device 6 (See again, FIG. 1) detects congestion in the host-bound path. Upon detecting the congestion, control plane 8 identifies packet flows utilizing an excessive amount of host-bound path resources and computes limits for the identified packet flows based on available resources and a fair share for the identified packet that may be dependent, for instance, upon the protocol associated with the packet flow (e.g., BGP) and the number of packet flows associated with that particular protocol. Control plane 8 then programs one or more of forwarding components 10 to dynamically add or update policers configured with the computed limits for the identified packet flows. More particularly, with reference to FIG. 3, Atlas teaches that upon dynamic policing module 30 incrementing counters 78, 80, 89, and/or 90 due to a processed packet, add policer module 83 (See FIG. 3) determines whether computed limits 73 for protocol groups 72, as computed by limit computation module 82, are violated by the counter increases. For per-protocol fairness and damage control protocol groups 72, add policer module 83 may add a penalty-box policer for a protocol group if (1) the corresponding packets received counter 78 meets or exceeds the packet limit of computed limits 73 for the protocol group, or (2) corresponding bytes received counter 80 meets or exceeds the byte limit of computed limits 73 for the protocol group) (Atlas, FIGS. 1 and 3, col. 6, ll. 34-45, col. 18, ll. 56-67); and with the policer manager, uninstalling the first policer when the flow statistics satisfy some criteria (wherein policer manager 85 (See again, FIG. 3) periodically updates penalty-box policers 24 with computed limits 73 and, when appropriate, removes one or more of penalty-box policers 24. That is, policer manager 85 additionally removes penalty-box policers 24 for policed network flows of policed host-bound traffic 35 that are no longer greedy or otherwise do not require policing. Atlas teaches that this has the effect of freeing policers of forwarding component 18A, a limited resource, for future use in policing other network flows of host-bound traffic 34) (Atlas, FIG. 3, col. 17, l. 66-col. 18, l. 1, col. 18, ll. 25-30). Labonte and Atlas are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte and Atlas before him or her, to modify the network device of Labonte to include the additional limitations of gathering flow statistics on the given flow; with a policer manager, monitoring the flow statistics and dynamically installing the first policer based on the flow statistics; and with the policer manager, uninstalling the first policer when the flow statistics satisfy some criteria, as disclosed by Atlas, with reasonable expectation that this would result in a network device that freed policers of forwarding components, which are limited resources, for future use in policing other network flows of host-bound traffic, thereby conserving resources (See Atlas, col. 18, ll. 28-30). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte with Atlas to obtain the invention as specified in claim 16.
12. Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Labonte in view of Hughes et al. (United States Patent Application Publication No. US 2017/0353383 A1), hereinafter “Hughes”.
Regarding claim 17, Labonte discloses the method of claim 15, but does not explicitly disclose further comprising: gathering flow statistics on the given flow; and with a policer manager, monitoring the flow statistics and programming the entry in the traffic policy database based on the flow statistics. However in an analogous art, Hughes discloses gathering flow statistics on the given flow (wherein Hughes discloses a flow management server system 206 (See FIG. 2) including a flow statistics server subsystem 206a that may be provided by an information handling system (IHS) 100 (shown in FIG. 1), and may include some or all of the components of the IHS 100. In particular, with reference to FIG. 3, Hughes discloses an embodiment of a flow statistics server subsystem 300, which may be the flow statistics server subsystem 206a of FIG. 2. As such, the flow statistics server subsystem 300 may be the IHS 100 discussed above with reference to FIG. 1 and/or may include some or all of the components of the IHS 100. In the illustrated embodiment, the flow statistics server subsystem 300 includes a chassis 302 that houses the components of the flow statistics server subsystem 300. The chassis 302 houses a processing system (not illustrated, but which may include one or more of the processors 102 discussed above with reference to FIG. 1) and a memory system (not illustrated, but which may include the memory system 114 discussed above with reference to FIG. 1) that includes instructions that, when executed by the processing system, cause the processing system to provide one or more first-level flow statistics engines and second-level flow statistics engines that are configured to perform the functions of the first level flow statistics engines, second level flow statistics engines, and flow statistics servers subsystems. With reference to FIG. 8A, Hughes teaches that a method 700 begins at block 702 where first level flow statistics are collected. In an embodiment, at block 702, each of controllers 204a, 204b, and up to 204c performs first-level flow statistic collection operations 800a, 800b, and up to 800c, respectively, to retrieve first-level flow statistics from its respective subset of switch device(s) 202a, 202b, and up to 202c. The first-level flow statistics collected at block 702 may include raw flow statistics reported by the subsets of switch devices 202a-c such as, e.g., a number of transmitted bytes, a number of transmitted frames, flow rates for particular interfaces and/or networks, flow durations, and/or a variety of other first-level flow information) (Hughes, FIGS. 1-3 and 8A, paragraphs [0023], [0025] and [0034]); and with a policer manager (wherein the flow management server system 206 (See again, FIG. 2), which Examiner maps to the recited “policer manager” for added clarity, includes a flow analytics server subsystem 206b that is shown in greater detail in FIG. 4, as flow management server system 400. In particular, the flow analytics server subsystem 400 may be the IHS 100 discussed above with reference to FIG. 1 and/or may include some or all of the components of the IHS 100. In the illustrated embodiment, the flow analytics server subsystem 400 includes a chassis 402 that houses the components of the flow analytics server subsystem 400) (Hughes, FIGS. 2 and 4, paragraphs [0024] and [0027]), monitoring the flow statistics and programming an entry in a traffic policy database based on the flow statistics (wherein the chassis 402 houses a flow analytics engine 404 that may be coupled to a storage system. For example, chassis 402 may house a storage system (not illustrated, but which may include one or more of the storage devices 108 discussed above with reference to FIG. 1) that includes a flow analytics database 406 and a policy database 408. Using the specific example provided in FIG. 2, the flow analytics database 406 may be coupled to the second-level flow statistics engine 308 in the flow statistics server subsystem 300 (e.g., via a coupling between the storage system in the flow analytics server subsystem 400 and the processing system in the flow statistics server subsystem 300) such that it is configured to receive and store second-level flow statistics. In addition, the policy database 406 may be coupled to the flow analytics engine 404 (e.g., via a coupling between the storage system and the processing system) and configured to receive and store flow policies such as flow operation policies) (Hughes, FIG. 4, paragraph [0028]). Labonte and Hughes are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte and Hughes before him or her, to modify the network device of Labonte to include the additional limitations of gathering flow statistics on the given flow; and with a policer manager, monitoring the flow statistics and programming the entry in the traffic policy database based on the flow statistics, as disclosed by Hughes, with reasonable expectation that this would result in a network device that allowed for the collection and generation of flow statistics to be focused on the collection of data that is most relevant to the network, without the need for user modification or interaction in the details of which flow statistics to collect, as well as for providing scalability, at least in part, based on the reduced and distributed flow processing effort that focused possibly limited flow gathering and analysis resources on particular areas of the network, and allowing that data to be used for later flow analysis and control (See Hughes, paragraph [0039]). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte with Hughes to obtain the invention as specified in claim 17.
13. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Labonte-Smethurst, and further in view of Atlas.
Regarding claim 9, Labonte-Smethurst discloses the method of claim 7, but does not expressly disclose further comprising: with the policer manager, dynamically uninstalling the flow policer from the packet processor in response to determining that the data packets are not causing the CPU to drop data packets from other flows. In an analogous art however, Atlas discloses with a policer manager, dynamically uninstalling a flow policer from a packet processor in response to determining that data packets are not causing the CPU to drop data packets from other flows (wherein as discussed and shown above with respect to claim 16, policer manager 85 (See again, FIG. 3) periodically updates penalty-box policers 24 with computed limits 73 and, when appropriate, removes one or more of penalty-box policers 24. That is, policer manager 85 additionally removes penalty-box policers 24 for policed network flows of policed host-bound traffic 35 that are no longer greedy or otherwise do not require policing. Atlas teaches that this has the effect of freeing policers of forwarding component 18A, a limited resource, for future use in policing other network flows of host-bound traffic 34) (Atlas, FIG. 3, col. 17, l. 66-col. 18, l. 1, col. 18, ll. 25-30). As discussed and shown above, Labonte-Smethurst and Atlas are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte-Smethurst and Atlas before him or her, to modify the network device of Labonte-Smethurst to include the additional limitation of with a policer manager, dynamically uninstalling a flow policer from a packet processor in response to determining that data packets are not causing the CPU to drop data packets from other flows, as disclosed by Atlas, with reasonable expectation that this would result in a network device that freed policers of forwarding components, which are limited resources, for future use in policing other network flows of host-bound traffic, thereby conserving resources (See Atlas, col. 18, ll. 28-30). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte-Smethurst with Atlas to obtain the invention as specified in claim 9.
14. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Labonte-Smethurst, and further in view of Bishara (United States Patent No. US 8,054,744 B1), hereinafter “Bishara”.
Regarding claim 11, Labonte-Smethurst discloses the method of claim 10, but does not expressly disclose further comprising: with the policer manager, deleting the entry from the CPU traffic policy database in response to determining that the data packets are not causing the CPU to drop data packets from other flows. However in an analogous art, Bishara discloses with a policer manager, deleting an entry from a CPU traffic policy database in response to determining that data packets are not causing a CPU to drop data packets from other flows (wherein Bishara teaches that a traffic monitoring manager (TMM) 170 (See FIG. 1) may handle flow expiration. That is, e.g., the TMM 170 can identify an idle flow based on the last packet timestamp associated with a flow. If the last packet timestamp is older than a timeout parameter, the TMM 170 may determine that the flow is idle and then remove the corresponding entry from the TCAM 128. Examiner notes that this scenario necessarily implies that data packets from such an idle flow would not be causing packets from other flows to be dropped, at least because packets of an idle flow will no longer be arriving. Examiner further notes that the claim is silent with regard to which entry is being deleted from the recited “CPU traffic policy database,” which Examiner here maps to the disclosed TCAM 128. Additionally, Bishara teaches that the ingress pipeline 104 and/or the egress pipeline 112 can help expedite identifying the ending of flows. For example, the ingress pipeline 104 and/or the egress pipeline 112 can monitor the finish (FIN) flag and the reset (RST) flag in TCP packets to identify TCP connections that are terminating. When a terminating TCP connection associated with a flow is terminating, the ingress pipeline 104 and/or the egress pipeline 112 can send a signal to the TMM 170. In response, the TMM 170 may determine that the flow is idle and then remove the corresponding entry from the TCAM 128) (Bishara, col. 8, l. 61-col. 9, l. 9). Labonte-Smethurst and Bishara are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte-Smethurst and Bishara before him or her, to modify the network device of Labonte-Smethurst to include the additional limitation of with a policer manager, deleting an entry from a CPU traffic policy database in response to determining that data packets are not causing a CPU to drop data packets from other flows, as disclosed by Bishara, with reasonable expectation that this would result in a network device having the added benefit of conserving resources, particularly by enabling subsequent storage of entries corresponding to new flows, and thus subsequent classification of these new flows at wire speed using TCAM-based classification (See Bishara, col. 9, ll. 10-13). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte-Smethurst with Bishara to obtain the invention as specified in claim 11.
15. Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Labonte-Smethurst, further in view of Atlas, and further in view of Bishara.
Regarding claim 20, Labonte-Smethurst discloses the network device of claim 19, but does not expressly disclose wherein the control plane processing circuitry is further configured to: store a flow table having flow statistics for the data packets; and execute a policer manager configured to program the content addressable memory and to install a flow policer in the packet processing circuitry for rate limiting the data packets by the first amount based on the flow statistics. However in an analogous art, Atlas discloses to store a flow table having flow statistics for the data packets (wherein as discussed and shown above with respect to claim 16, Atlas teaches that protocol groups 72 categorized as per-session fairness use one or more tables with table entries, or another associative data structure, to allow flow identification and store statistics for identified flows using packets received counters and bytes received counters for each table entry. In some examples (including the illustrated example), protocol groups 72 categorized as per-session fairness use hash tables with hash buckets to allow flow identification and store statistics for identified flows, hashed to the hash buckets, using packets received counters and bytes received counters for each hash bucket) (Atlas, FIGS. 1-3, col. 13, l. 66-col. 14, l. 4, col. 14, l. 67-col. 15, ll. 29-39); and execute a policer manager configured to install a flow policer in the packet processing circuitry for rate limiting the data packets by the first amount based on the flow statistics (wherein as further discussed and shown above, Atlas teaches that control plane 8 of network device 6 (See again, FIG. 1) detects congestion in the host-bound path. Upon detecting the congestion, control plane 8 identifies packet flows utilizing an excessive amount of host-bound path resources and computes limits for the identified packet flows based on available resources and a fair share for the identified packet that may be dependent, for instance, upon the protocol associated with the packet flow (e.g., BGP) and the number of packet flows associated with that particular protocol. Control plane 8 then programs one or more of forwarding components 10 to dynamically add or update policers configured with the computed limits for the identified packet flows. More particularly, with reference to FIG. 3, Atlas teaches that upon dynamic policing module 30 incrementing counters 78, 80, 89, and/or 90 due to a processed packet, add policer module 83 (See FIG. 3) determines whether computed limits 73 for protocol groups 72, as computed by limit computation module 82, are violated by the counter increases. For per-protocol fairness and damage control protocol groups 72, add policer module 83 may add a penalty-box policer for a protocol group if (1) the corresponding packets received counter 78 meets or exceeds the packet limit of computed limits 73 for the protocol group, or (2) corresponding bytes received counter 80 meets or exceeds the byte limit of computed limits 73 for the protocol group) (Atlas, FIGS. 1 and 3, col. 6, ll. 34-45, col. 18, ll. 56-67). Labonte-Smethurst and Atlas are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte-Smethurst and Atlas before him or her, to modify the network device of Labonte-Smethurst to include the additional limitations of to store a flow table having flow statistics for the data packets; and execute a policer manager configured to install a flow policer in the packet processing circuitry for rate limiting the data packets by the first amount based on the flow statistics, as disclosed by Atlas, with reasonable expectation that this would result in a network device that installed policers of forwarding components, which would restrict traffic in a work-conserving manner, mitigate congestion, and improve fair sharing among protocols (See Atlas, col. 12, ll. 20-22). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte-Smethurst with Atlas to obtain the invention as specified in claim 20. Labonte-Smethurst-Atlas does not expressly disclose a policer manager to program the content addressable memory. However in an analogous art, Bishara discloses a policer manager to program a content addressable memory (wherein Bishara discloses a traffic monitoring manager (TMM) 170 coupled to ingress pipeline 104 and egress pipeline 112 (See FIG. 1). The TMM 170 generally creates flow entries for new flows when the new flows are detected by ingress policy engine 127 and egress policy engine 154. In particular, with reference to FIG. 2, Bishara teaches that at block 232, in response to receiving a packet corresponding to a new flow, the TMM 170 may create a new flow entry corresponding to the new flow. Creating the new flow entry may include creating an existing flow ID that is unique as compared to the flow IDs of the other existing flows. At block 236, the TMM 170 may create an existing flow rule for the detected new flow. Creating the existing flow rule may include creating a rule for detecting packets from the flow and specifying set of one or more actions to be taken when a packet from the flow is detected. The rule for detecting packets from the flow may include a ternary content addressable memory (TCAM) match rule, such as all IP packets having a particular source IP address and a particular destination IP address. Regarding specifying the action to be taken, Bishara further teaches that a TCAM entry corresponding to the new flow may be created, and storing the TCAM entry in the TCAM 128. The TCAM entry created by the TMM 170 may specify or indicate a set of one or more actions to be taken when packets from the flow are detected. For example, the TCAM entry may be a flow ID or a pointer that may be utilized to obtain information in another memory such as the SRAM 129. Examples of actions in the set of one or more actions to be taken may include forwarding the packet to the next unit in the pipeline (the action entry may also specify whether forwarding may be done with or without mirroring to the TMM 170), trapping the packet to the TMM 170, monitoring a counter pointer, etc.) (Bishara, FIGS. 1 and 2, col. 7, ll. 59-64, col. 11, ll. 10-35). Labonte-Smethurst-Atlas and Bishara are analogous art because they are from the same field of endeavor, namely, systems and methods for managing network traffic flows. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Labonte-Smethurst-Atlas and Bishara before him or her, to modify the network device of Labonte-Smethurst-Atlas to include the additional limitation of a policer manager to program a content addressable memory, as disclosed by Bishara, with reasonable expectation that this would result in a network device having the added benefit of identifying new flows and programming the TCAM by creating flow entries for the new flows when detected by the policy engines (See Bishara, col. 7, ll. 62-64). Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Labonte-Smethurst-Atlas with Bishara to obtain the invention as specified in claim 20.
Conclusion
16. Further references of interest are cited on Form PTO-892, which is an attachment to this Office Action. For instance, Labonte (USPGPUB 2019/0104090) discloses a method and apparatus of a network element that processes control plane data in a network element. In an exemplary embodiment, the network element receives network data and determines a class of the network data. The network element additionally determines that this class of the network data is to be processed. The network element further marks the network data based on at least on an existence of an indication of whether the network element had previously processed other data in the same class as the class of the network data. Furthermore, the network element queues the network data (See Abstract). THORAT (USPGPUB 2022/0141118) discloses a method and a system for securing an SDN controller from denial of service attacks. A SDN controller receives, from a networking device, data packets pertaining to a flow in Packet_IN messages, if the flow does not match flow entries in a first flow table of the networking device. A table miss flow entry pertaining to the flow is created in a second flow table of the networking device for sending the Packet_IN. The SDN controller installs a flood prevention flow entry in the second flow table to enable the networking device to drop subsequent data packets pertaining to the flow until the SDN controller installs, in the first flow table, a flow entry matching the flow. The flood prevention flow entry is deleted from the second flow table after the installation of the flow entry matching the flow (See Abstract). LIVNE (WIPO 2023/033962) discloses a network interface device comprising circuitry to cause transmission of packets based on transmission times and use of at least one of multiple time slot granular scheduling lists, wherein the multiple time slot granular scheduling lists comprise at least one list of a first time slot duration and at least one list of a second time slot duration and wherein the first time slot duration is different than the second time slot duration (See Abstract).
17. Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOSTAS J. KATSIKIS whose telephone number is (571)270-5434. The examiner can normally be reached Monday-Friday, 9:00am-5:00pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian J. Gillis can be reached at 571-272-7952. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KOSTAS J KATSIKIS/Primary Examiner, Art Unit 2441
Prosecution Insights