Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claim 8 is objected to because of the following informalities:
Claim 8 within its preamble recites “wherein method further comprises”. It appears that this should recited “wherein the method further comprises”.
Appropriate correction is required.
Applicant’s assistance is requested to identify any other issues that Applicant becomes aware of.
Claim Rejections - 35 USC § 102
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.
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.
Claim(s) 1-2, 4-10, 12-15, 17-21 and 27-31 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 11128561 B1 to Matthews et al. (“Matthews”).
Regarding claim 1, Matthews taught a method for packet processing, comprising:
receiving, by a network device (consider column 21, lines 13-15), a first packet (“data unit”); forwarding, by the network device, based on first traffic characteristic information of the first packet (“specific packet fields”/”observed state attributes”/”data unit attributes”), the first packet by using a first load balancing algorithm that matches the first traffic characteristic information; receiving, by the network device, a second packet; and forwarding, by the network device, based on second traffic characteristic information of the second packet, the second packet by using a second load balancing algorithm that matches the second traffic characteristic information, wherein the first load balancing algorithm and the second load balancing algorithm are different (used by “ALB paths” and, alternatively, “ECMP”, “LAG” or “other multipath grouping mechanisms”). (consider column 1, line 66-column 2, line 40, “A given node in the network may communicate with another node in the network by sending data units along one or more different paths through the network that lead to the other node, each path including any number of intermediate nodes. The transmission of data across a computing network typically involves sending units of data, such as packets, cells, or frames, along paths through intermediary networking devices, such as switches or routers, that direct or redirect each data unit towards a corresponding destination. In many cases, there are multiple paths by which one node in a network may communicate with another node in the network. A network device must thus include path selection logic to select between these multiple paths. Generally, the path selection logic involves identifying a group of candidate paths (also referred to herein as a “multipath group”) by which a destination node is reachable from the network device, and selecting a path from the group. For example, a shortest-path-first mechanism may assign costs to each path in a group based on the topology of the network, and then select the lowest-cost path (e.g., the path the traverses the least number of nodes). Load balancing may be implemented to distribute data units over multiple paths. A multipath group may be identified for each destination, with each destination being a single address (e.g., a single node) or set of addresses (e.g., a subnet), depending on the embodiment. In some embodiments, the multipath group may be a distinct subset of all possible paths to the destination, such as an administrator-defined group of optimal paths, or an “equal-cost” group of paths that are all topologically shortest paths or that all have the same associated cost metric. Rather than selecting a single best path to a destination for all data units that a sender sends to the destination, the path selection logic may group the data units into different flows of traffic, and then select different paths from the multipath group for different data units, depending on which flows the data units belong to. For example, some common load balancing techniques bind arriving packet flows, as identified based on specific packet fields (e.g., OSI Layer 3 routing information, etc.), to a multipath group member that is selected from among Link Aggregation Groups (LAGs) or Equal Cost Multipathing Groups (ECMPs) based on a hash function of the specific packet fields.”) (consider further column 3, line 38-column 4, line 27, “In contrast, techniques as described herein may be used to perform automatic load balancing (ALB) on paths in multipath routing operations of a network device, such as a router, a switch, a line card in a chassis, and so forth. The techniques may be used to select, from a multipath group, the path to assign to a flow based on observed state attributes that can include, but are not limited to, path state(s), device state(s), port state(s), or queue state(s) associated with the paths. Other states beyond path and port state, such as buffer state(s) for a set of ports, flow control state(s), etc., may also be used as a basis for assigning flows to paths. A mapping of the path previously assigned to a flow or group of flows (e.g., on account of having then been optimal in view of the observed state attributes) is maintained, for example, in a table. So long as the flow(s) are active and the path is still valid, the mapped path is selected for subsequent data units belonging to the flow(s), which may, among other effects, avoid or reduce packet re-ordering. However, if the flow(s) go dormant or idle, or if the mapped path fails, a new optimal path may be assigned to the flow(s) from the multipath group. In an embodiment, under ALB techniques as described herein, re-ordering of data units as a consequence of reassigning a flow to a different path may be reduced or even avoided, depending on configuration. At the same time, the ALB techniques may support fast, balanced, optimal failovers when flows with previously assigned paths experience problems or failures. In an embodiment, some ALB implementations may optionally configure a load balancing mechanism to aggressively move flows to optimal links to achieve higher performance at the expense of having to manage additional reordering of data units. Data units may be grouped into traffic flows based on a variety of flow identification mechanisms. For instance, traffic flows are often identified based on data unit attributes, such as by a 5-tuple combination of the destination IP address, source IP address, destination TCP/IP port, source TCP/IP port, and protocol, or any other suitable set of one or more data unit attributes. In an embodiment, such individual traffic flows may be aggregated into ALB flows, each of which may be identified with a unique ALB flow identifier. The ALB flow identifier may be provided in a data unit itself (e.g., in a packet header), or generated from data unit attributes using a mapping function, such as a hash function, to create the unique identifier. Thus, an ALB flow as described herein may comprise a set of one or more component traffic flows. Different component flows in the set of component flows of the ALB flows may correspond to, or are identified by, different sets of common attributes of data units in traffic flows. Each component flow in the set of component flows of the ALB flows corresponds to, or is identified by, a respective set of common attributes (e.g., a set of common 5-tuple attributes, etc.) of data units in a traffic flow or a single unique identifier in scenarios in which the unique identifier is generated (e.g., hash-based generation, etc.).”) (consider further column 21, lines 12-38 regarding “Automatic Load Balancing” wherein “A network device, such as network device 200 of FIG. 2 or any other switch, router, or network device, may implement ALB techniques to perform path selection operations. In an embodiment, the ALB techniques may be integrated with, or used to enhance, load balancing techniques in connection with path groups based on ECMP, LAG, or other multipath grouping mechanisms. The network device may perform the ALB-based path selection operations using device, path, and/or other statistics collected and generated by the network device under the techniques as described herein. In an embodiment, the ALB path selection logic and a default path selection logic may be implemented in parallel. Data units having certain characteristics may be designated as ALB-eligible, in that the path selection logic may select paths for the data units using the ALB-selection logic instead of the default path selection logic. FIG. 3A illustrates an example path resolution logic 300 in which an ALB-based path selection mechanism may be used in place of default load balancing selection mechanism for multi-path groups (e.g., ECMP, LAG, etc.) for a certain amount of traffic in a network device. In some operational scenarios, some or all of the path resolution logic 300 and/or load balancing process flows may be implemented in an ingress packet processor such as IPP 230 of FIG. 2A, or other suitable component of a network device.”) (consider further generally column 21, line 40-column 26, line 28 regarding “Default Path Selection Logic”, “ALB Flow Identification”, and “ALB Flow Categorization”, specifically column 21, line 50-column 22, line 5, “For every arriving data unit, the default path selection logic 380 performs a lookup using a multipath group identifier 330 into a group attribute table 302 to access or otherwise resolve the group attributes of a multipath group of paths by which the arriving data unit may be forwarded. The group identifier may be determined based on one or more attributes associated with or extracted from the arriving data unit, such as by a lookup of a destination address specified in the packet header against a prefix table or other forwarding table. Using the group identifier 330, attributes of a corresponding multipath group of paths are located in a group attributes table 302. Element selection logic 304 is used to select a specific element (corresponding to a specific path) in the group, such as by using a hash function of various packet header fields, as described elsewhere herein. Path resolution logic 316 locates corresponding path information in an element list table 306 by computing a pointer to a specific index in the element list table 306 where the path information may be found. The path selection logic then uses this path information to determine where to forward the data unit (e.g., a specific egress port, internal component, traffic manager, etc.)”)
Regarding claim 2, Matthews taught the method according to claim 1, wherein the forwarding, by the network device, based on the first traffic characteristic information of the first packet, the first packet by using a first load balancing algorithm that matches the first traffic characteristic information comprises:
determining, by the network device based on the first load balancing algorithm that matches the first traffic characteristic information, a first target hash function used for the first packet (“function”) and a first target hash key composition member of the first packet (“selected data fields (representing a hash key) of each arriving data unit”); obtaining, by the network device, a first target hash value (“ALB flow identifier/”path information”) through computing based on the first target hash function and the first target hash key composition member; and determining, by the network device, an egress port of the first packet based on the first target hash value. (consider generally column 12, lines 17-32, “A non-limiting example flow of a data unit 205 through components of a device 200 is as follows. The data unit 205 may be received by a port 210. The data unit 205 is buffered by an arbiter 220 until it can be processed by an ingress packet processor (IPP) 230, and then delivered to an interconnect. From the interconnect, the data unit 205 is forwarded to a traffic manager 240. Traffic manager 240 stores the data unit 205 in a buffer 244 and assigns the data unit 205 to a queue 245. Traffic manager 240 manages the flow of the data unit 205 through the queue 245 until the data unit 205 is released to an egress packet processor (EPP) 250. Depending on the processing, the traffic manager 240 may then assign the data unit 205 to another queue 245 so that it may be processed by yet another EPP 250, or the EPP 250 may send the data unit 205 to an egress arbiter 260 from which the data unit 205 is finally forwarded out another port 290.”) (again, column 21, line 50-column 22, line 5, specifically “For every arriving data unit, the default path selection logic 380 performs a lookup using a multipath group identifier 330 into a group attribute table 302 to access or otherwise resolve the group attributes of a multipath group of paths by which the arriving data unit may be forwarded. The group identifier may be determined based on one or more attributes associated with or extracted from the arriving data unit, such as by a lookup of a destination address specified in the packet header against a prefix table or other forwarding table. Using the group identifier 330, attributes of a corresponding multipath group of paths are located in a group attributes table 302. Element selection logic 304 is used to select a specific element (corresponding to a specific path) in the group, such as by using a hash function of various packet header fields, as described elsewhere herein. Path resolution logic 316 locates corresponding path information in an element list table 306 by computing a pointer to a specific index in the element list table 306 where the path information may be found. The path selection logic then uses this path information to determine where to forward the data unit (e.g., a specific egress port, internal component, traffic manager, etc.)”) (consider further column 23, lines 18-67, “For arriving data units belonging to ALB groups determined to be ALB-enabled, a flow identifier generator 308 identifies the ALB flow to which the data unit is assigned. For example, an ALB flow identifier may be computed based on various data unit attributes (e.g., fields of the packet header, such as described previously), using hash-based or other mechanisms such as described elsewhere herein. The ALB flow identifier may also optionally be computed based on one or more ALB group attributes resolved or retrieved from the ALB group attributes table 310. For example, a set of individual flow identifiers computed using data unit attributes may be aggregated into a single ALB flow based on ranges of identifiers, modulo-based buckets, or other mapping mechanisms indicated by the one or more ALB group attributes. Moreover, in an embodiment, an individual flow identifier or aggregated flow identifier may be adapted so as to be unique across all ALB groups, such as by adding an offset associated with the ALB group or appending an ALB group identifier. The ALB flow identifier may or may not be the same as a flow identifier (e.g., ECMP identifier, LAG identifier, etc.) generated by the default path selection logic 380. Additionally, optionally or alternatively, the ALB flow identifier may or may not be generated from the same attributes (e.g., five-tuple attributes, a set of source and destination IP addresses, source and destination IP ports and protocol, etc.) of data units used to generate the flow identifier for the default path selection logic 380. In an embodiment, the ALB flow identifier is calculated as a function of: (a) a hash value computed with a hash function (which computes or produces a hash value based on a given hash key) from selected data fields (representing a hash key) of each arriving data unit; (b) an ALB group base pointer; and (c) a ALB group flow count attribute, the latter two of which may be stored in, for instance, the ALB group attribute table 310. The ALB group flow count attribute may be a per-ALB-group attribute for each ALB group, which indicates the number of ALB flows that exist for the group, thus controlling the granularity at which flows are managed for the group. The function may be, for instance, to sum the ALB group base pointer with the result of a modulo operation between the hash value and the ALB group flow count attribute. Example traffic flow types to be managed in an ALB group may include, but are not necessarily limited to only, any of: one or more lossy flow types, one or more lossless flow types, and so forth. A traffic flow type may be, but is not necessarily, specified with a flow-type attribute value in an ALB or non-ALB configuration table accessible to the ALB operations.”)
Regarding claim 4, Matthews taught the method according to claim 1, wherein the network device comprises load balancing configuration information, the load balancing configuration information indicates an association relationship between a load balancing algorithm and traffic characteristic information. (again, consider column 3, line 38-column 4, line 27, specifically “A mapping of the path previously assigned to a flow or group of flows (e.g., on account of having then been optimal in view of the observed state attributes) is maintained, for example, in a table. So long as the flow(s) are active and the path is still valid, the mapped path is selected for subsequent data units belonging to the flow(s), which may, among other effects, avoid or reduce packet re-ordering.”) (again, consider further column 21, lines 12-38 regarding “Automatic Load Balancing” wherein “A network device, such as network device 200 of FIG. 2 or any other switch, router, or network device, may implement ALB techniques to perform path selection operations. In an embodiment, the ALB techniques may be integrated with, or used to enhance, load balancing techniques in connection with path groups based on ECMP, LAG, or other multipath grouping mechanisms. The network device may perform the ALB-based path selection operations using device, path, and/or other statistics collected and generated by the network device under the techniques as described herein. In an embodiment, the ALB path selection logic and a default path selection logic may be implemented in parallel. Data units having certain characteristics may be designated as ALB-eligible, in that the path selection logic may select paths for the data units using the ALB-selection logic instead of the default path selection logic. FIG. 3A illustrates an example path resolution logic 300 in which an ALB-based path selection mechanism may be used in place of default load balancing selection mechanism for multi-path groups (e.g., ECMP, LAG, etc.) for a certain amount of traffic in a network device. In some operational scenarios, some or all of the path resolution logic 300 and/or load balancing process flows may be implemented in an ingress packet processor such as IPP 230 of FIG. 2A, or other suitable component of a network device.”) (again, consider further generally column 21, line 40-column 26, line 28 regarding “Default Path Selection Logic”, “ALB Flow Identification”, and “ALB Flow Categorization”, specifically column 21, lines 42-46, “According to an embodiment, the path selection logic includes a default path selection logic 380, which may be based on a group attribute table 302, such as an ECMP group table or LAG group table. In an embodiment, the group table may be a weighted-cost multi-path (“WCMP”) table…” and column 21, line 50-column 22, line 5, “For every arriving data unit, the default path selection logic 380 performs a lookup using a multipath group identifier 330 into a group attribute table 302 to access or otherwise resolve the group attributes of a multipath group of paths by which the arriving data unit may be forwarded. The group identifier may be determined based on one or more attributes associated with or extracted from the arriving data unit, such as by a lookup of a destination address specified in the packet header against a prefix table or other forwarding table. Using the group identifier 330, attributes of a corresponding multipath group of paths are located in a group attributes table 302. Element selection logic 304 is used to select a specific element (corresponding to a specific path) in the group, such as by using a hash function of various packet header fields, as described elsewhere herein. Path resolution logic 316 locates corresponding path information in an element list table 306 by computing a pointer to a specific index in the element list table 306 where the path information may be found. The path selection logic then uses this path information to determine where to forward the data unit (e.g., a specific egress port, internal component, traffic manager, etc.)”)
Regarding claim 5, Matthews taught the method according to claim 4, wherein the method further comprises:
receiving, by the network device, a first instruction; and configuring, by the network device, the load balancing configuration information based on the first instruction. (consider column 2, lines 19-28, “Load balancing may be implemented to distribute data units over multiple paths. A multipath group may be identified for each destination, with each destination being a single address (e.g., a single node) or set of addresses (e.g., a subnet), depending on the embodiment. In some embodiments, the multipath group may be a distinct subset of all possible paths to the destination, such as an administrator-defined group of optimal paths, or an “equal-cost” group of paths that are all topologically shortest paths or that all have the same associated cost metric.”) (consider also column 22, lines 39-50, “The ALB flow identification operation may, in some embodiments, then check to see if the ALB group determined for an arriving data unit is eligible for further ALB operations. This may involve, for instance, determining if the ALB group identifier for the data unit is in a set or range of values that has been marked as being ALB-eligible. The ALB group identifier may be specifically marked as eligible in, for instance, the ALB group attribute table, or ranges of ALB identifiers (or multipath group identifiers 330) may be marked as eligible. An ALB group may have been marked as eligible, for instance, manually by a system administrator or automatically in response to various conditions.”)
Regarding claim 6, Matthews taught the method according to claim 4, wherein the load balancing configuration information comprises one or more of the following information:
identification information of the load balancing configuration information; the load balancing algorithm corresponding to the load balancing configuration information; matching information, wherein the matching information belongs to the traffic characteristic information; configuration information for hash key composition member selection; or configuration information for hash function selection. (again, consider further generally column 21, line 40-column 26, line 28 regarding “Default Path Selection Logic”, “ALB Flow Identification”, and “ALB Flow Categorization”, specifically column 22, lines 39-64, “The ALB flow identification operation may, in some embodiments, then check to see if the ALB group determined for an arriving data unit is eligible for further ALB operations. This may involve, for instance, determining if the ALB group identifier for the data unit is in a set or range of values that has been marked as being ALB-eligible. The ALB group identifier may be specifically marked as eligible in, for instance, the ALB group attribute table, or ranges of ALB identifiers (or multipath group identifiers 330) may be marked as eligible. An ALB group may have been marked as eligible, for instance, manually by a system administrator or automatically in response to various conditions. For groups that are not eligible, the default path selection logic 380 is used to select a path for the data unit, whereas otherwise the ALB selection logic 390 is utilized. In some embodiments, all multipath groups are ALB-eligible, and thus this check may be skipped. For example, as depicted in FIG. 3, using the group identifier 330 (and optionally the flow type) for the arriving data unit, a lookup into an ALB group attribute table 310 is performed to resolve ALB group attributes applicable for the ALB group to which the arriving data unit belongs. The ALB group attributes for the data unit, as resolved from the ALB group attribute table 310, can be used to determine whether the arriving data unit is enabled or eligible for further ALB operations.”)
Regarding claim 7, Matthews taught the method according to claim 4, wherein the load balancing configuration information specifically indicates an association relationship between the first load balancing algorithm and the first traffic characteristic information; (again, consider column 3, line 38-column 4, line 27, column 21, lines 12-38, column 21, lines 42-46, and column 21, line 50-column 22, line 5) and
the forwarding, by the network device, based on the first traffic characteristic information of the first packet, the first packet by using a first load balancing algorithm that matches the first traffic characteristic information comprises:
determining, by the network device, based on the first traffic characteristic information of the first packet and the load balancing configuration information, the first load balancing algorithm that matches the first traffic characteristic information. (again, consider further column 21, lines 12-38 regarding “Automatic Load Balancing” wherein “A network device, such as network device 200 of FIG. 2 or any other switch, router, or network device, may implement ALB techniques to perform path selection operations. In an embodiment, the ALB techniques may be integrated with, or used to enhance, load balancing techniques in connection with path groups based on ECMP, LAG, or other multipath grouping mechanisms. The network device may perform the ALB-based path selection operations using device, path, and/or other statistics collected and generated by the network device under the techniques as described herein. In an embodiment, the ALB path selection logic and a default path selection logic may be implemented in parallel. Data units having certain characteristics may be designated as ALB-eligible, in that the path selection logic may select paths for the data units using the ALB-selection logic instead of the default path selection logic. FIG. 3A illustrates an example path resolution logic 300 in which an ALB-based path selection mechanism may be used in place of default load balancing selection mechanism for multi-path groups (e.g., ECMP, LAG, etc.) for a certain amount of traffic in a network device. In some operational scenarios, some or all of the path resolution logic 300 and/or load balancing process flows may be implemented in an ingress packet processor such as IPP 230 of FIG. 2A, or other suitable component of a network device.”) (again, consider further generally column 21, line 40-column 26, line 28 regarding “Default Path Selection Logic”, “ALB Flow Identification”, and “ALB Flow Categorization”, specifically specifically column 21, lines 42-46, “According to an embodiment, the path selection logic includes a default path selection logic 380, which may be based on a group attribute table 302, such as an ECMP group table or LAG group table. In an embodiment, the group table may be a weighted-cost multi-path (“WCMP”) table…”, column 21, line 50-column 22, line 5, “For every arriving data unit, the default path selection logic 380 performs a lookup using a multipath group identifier 330 into a group attribute table 302 to access or otherwise resolve the group attributes of a multipath group of paths by which the arriving data unit may be forwarded. The group identifier may be determined based on one or more attributes associated with or extracted from the arriving data unit, such as by a lookup of a destination address specified in the packet header against a prefix table or other forwarding table. Using the group identifier 330, attributes of a corresponding multipath group of paths are located in a group attributes table 302. Element selection logic 304 is used to select a specific element (corresponding to a specific path) in the group, such as by using a hash function of various packet header fields, as described elsewhere herein. Path resolution logic 316 locates corresponding path information in an element list table 306 by computing a pointer to a specific index in the element list table 306 where the path information may be found. The path selection logic then uses this path information to determine where to forward the data unit (e.g., a specific egress port, internal component, traffic manager, etc.)” and column 22, lines 39-64, “The ALB flow identification operation may, in some embodiments, then check to see if the ALB group determined for an arriving data unit is eligible for further ALB operations. This may involve, for instance, determining if the ALB group identifier for the data unit is in a set or range of values that has been marked as being ALB-eligible. The ALB group identifier may be specifically marked as eligible in, for instance, the ALB group attribute table, or ranges of ALB identifiers (or multipath group identifiers 330) may be marked as eligible. An ALB group may have been marked as eligible, for instance, manually by a system administrator or automatically in response to various conditions. For groups that are not eligible, the default path selection logic 380 is used to select a path for the data unit, whereas otherwise the ALB selection logic 390 is utilized. In some embodiments, all multipath groups are ALB-eligible, and thus this check may be skipped. For example, as depicted in FIG. 3, using the group identifier 330 (and optionally the flow type) for the arriving data unit, a lookup into an ALB group attribute table 310 is performed to resolve ALB group attributes applicable for the ALB group to which the arriving data unit belongs. The ALB group attributes for the data unit, as resolved from the ALB group attribute table 310, can be used to determine whether the arriving data unit is enabled or eligible for further ALB operations.”)
Regarding claim 8, Matthews taught the method according to claim 1, wherein method further comprises at least one of:
filling, by the network device, a first load balancing identifier into the first packet; or filling, by the network device, a second load balancing identifier into the second packet. (consider column 4, lines 3-16, “Data units may be grouped into traffic flows based on a variety of flow identification mechanisms. For instance, traffic flows are often identified based on data unit attributes, such as by a 5-tuple combination of the destination IP address, source IP address, destination TCP/IP port, source TCP/IP port, and protocol, or any other suitable set of one or more data unit attributes. In an embodiment, such individual traffic flows may be aggregated into ALB flows, each of which may be identified with a unique ALB flow identifier. The ALB flow identifier may be provided in a data unit itself (e.g., in a packet header), or generated from data unit attributes using a mapping function, such as a hash function, to create the unique identifier.”) (consider further column 9, line 56-column 10, line 10, “When a node 110 receives a data unit, it typically examines addressing information within the data unit (and/or other information within the data unit) to determine how to process the data unit. The addressing information may be, for instance, an Internet Protocol (IP) address, MPLS label, or any other suitable information. If the addressing information indicates that the receiving node 110 is not the destination for the data unit, the receiving node 110 may look up the destination node 110 within receiving node's routing information and route the data unit to another node 110 connected to the receiving node 110 based on forwarding instructions associated with the destination node 110 (or an address group to which the destination node belongs). The forwarding instructions may indicate, for instance, an outgoing port over which to send the data unit, a label to attach the data unit, a next hop, etc. In cases where multiple (e.g., equal-cost, non-equal-cost, etc.) paths to the destination node 110 are possible, the forwarding instructions may include information indicating a suitable approach for selecting one of those paths, or a path deemed to be the best path may already be defined.”) (consider further column 13, line 61-column 14, line 5, “Based on decisions made while processing a data unit 205, a packet processor may, in some embodiments, and/or for certain processing tasks, manipulate a data unit 205 directly. For instance, the packet processor may add, delete, or modify information in a data unit header or payload. In other embodiments, and/or for other processing tasks, a packet processor may generate control information that accompanies the data unit 205, or is merged with the data unit 205, as the data unit 205 continues through the device 200. This control information may then be utilized by other components of the device 200 to implement decisions made by the packet processor.”)
Regarding claim 9, Matthews taught the method according to claim 1, wherein the forwarding, by the network device, based on the first traffic characteristic information of the first packet, the first packet by using a first load balancing algorithm that matches the first traffic characteristic information comprises:
determining, by the network device, a first target logic circuit (“egress packet processor”/”EPP”) based on the first traffic characteristic information of the first packet, wherein the first target logic circuit runs the first load balancing algorithm corresponding to the first packet; and processing, by the network device, the first packet by using the first target logic circuit, and determining an egress port of the first packet. (consider generally column 12, lines 17-32, “A non-limiting example flow of a data unit 205 through components of a device 200 is as follows. The data unit 205 may be received by a port 210. The data unit 205 is buffered by an arbiter 220 until it can be processed by an ingress packet processor (IPP) 230, and then delivered to an interconnect. From the interconnect, the data unit 205 is forwarded to a traffic manager 240. Traffic manager 240 stores the data unit 205 in a buffer 244 and assigns the data unit 205 to a queue 245. Traffic manager 240 manages the flow of the data unit 205 through the queue 245 until the data unit 205 is released to an egress packet processor (EPP) 250. Depending on the processing, the traffic manager 240 may then assign the data unit 205 to another queue 245 so that it may be processed by yet another EPP 250, or the EPP 250 may send the data unit 205 to an egress arbiter 260 from which the data unit 205 is finally forwarded out another port 290.”) (consider further column 13, lines 35-60, “Different packet processors may be configured to perform different packet processing tasks. These tasks may include, for example, identifying paths along which to forward data units 205, forwarding data units 205 to egress arbiters 260, implementing flow control and/or other policies, manipulating packets, performing statistical or debugging operations, making measurements related to delays and/or port loadings, determining port conditions and/or states, aggregating and broadcasting port conditions and/or states, performing hash-based loading balancing, performing ALB operations, and so forth. A device 200 may comprise any number of packet processors configured to perform any number of processing tasks. In an embodiment, the packet processors within a device 200 may be arranged such that the output of one packet processor is, eventually, inputted into another packet processor, in such a manner as to pass data units 205 from certain packet processor(s) to other packet processor(s) in a sequence of stages, until finally disposing of the data units 205 (e.g., by sending the data units 205 out an egress port 290, “dropping” data units 205, etc.). The exact set and/or sequence of packet processors that process a given data unit 205 may vary, in some embodiments, depending on the attributes of the data unit 205 and/or the state of the device 200. There is no limit to the number of packet processor(s) that may be chained together in such a manner.”) (consider further column 14, lines 19-67 regarding “Ingress and Egress Processing”, specifically “In an embodiment, a packet processor may be generally classified as an IPP 230 or an EPP 250… The EPP(s) 250 of a device 200, by contrast, may be configured to perform non-intake tasks necessary to implement the forwarding logic of the device 200. These tasks may include, for example, tasks such as identifying paths along which to forward data units 205, implementing flow control and/or other policies, manipulating data units 205, performing statistical or debugging operations, making measurements related to delays and/or port loadings, determining port conditions and/or states, sending measurements and/or port conditions/states to traffic managers, and so forth. In an embodiment, there may be different EPP(s) 250 assigned to different flows or other categories of traffic, such that not all data units 205 will be processed by the same EPP 250… In an embodiment, each EPP 250 is coupled to a different group of egress ports 290 to which they may send data units 205 processed by the EPP 250. In an embodiment, access to a group of ports 290 may be regulated via an egress arbiter 260 coupled to the EPP 250.”)
Regarding claim 10, Matthews taught the method according to claim 9, wherein the processing, by the network device, the first packet by using the first target logic circuit, and determining the egress port of the first packet comprises:
processing, by the network device, the first packet by using the first target logic circuit, and determining a first target hash function used for the first packet and a first target hash key composition member of the first packet; obtaining, by the network device, a first target hash value through computing based on the first target hash function and the first target hash key composition member; and determining, by the network device, the egress port of the first packet based on the first target hash value. (again, consider column 13, lines 35-60, “Different packet processors may be configured to perform different packet processing tasks. These tasks may include, for example, identifying paths along which to forward data units 205, forwarding data units 205 to egress arbiters 260, implementing flow control and/or other policies, manipulating packets, performing statistical or debugging operations, making measurements related to delays and/or port loadings, determining port conditions and/or states, aggregating and broadcasting port conditions and/or states, performing hash-based loading balancing, performing ALB operations, and so forth.”) (again, consider generally column 12, lines 17-32, “A non-limiting example flow of a data unit 205 through components of a device 200 is as follows. The data unit 205 may be received by a port 210. The data unit 205 is buffered by an arbiter 220 until it can be processed by an ingress packet processor (IPP) 230, and then delivered to an interconnect. From the interconnect, the data unit 205 is forwarded to a traffic manager 240. Traffic manager 240 stores the data unit 205 in a buffer 244 and assigns the data unit 205 to a queue 245. Traffic manager 240 manages the flow of the data unit 205 through the queue 245 until the data unit 205 is released to an egress packet processor (EPP) 250. Depending on the processing, the traffic manager 240 may then assign the data unit 205 to another queue 245 so that it may be processed by yet another EPP 250, or the EPP 250 may send the data unit 205 to an egress arbiter 260 from which the data unit 205 is finally forwarded out another port 290.”) (again, consider column 21, line 50-column 22, line 5, specifically “For every arriving data unit, the default path selection logic 380 performs a lookup using a multipath group identifier 330 into a group attribute table 302 to access or otherwise resolve the group attributes of a multipath group of paths by which the arriving data unit may be forwarded. The group identifier may be determined based on one or more attributes associated with or extracted from the arriving data unit, such as by a lookup of a destination address specified in the packet header against a prefix table or other forwarding table. Using the group identifier 330, attributes of a corresponding multipath group of paths are located in a group attributes table 302. Element selection logic 304 is used to select a specific element (corresponding to a specific path) in the group, such as by using a hash function of various packet header fields, as described elsewhere herein. Path resolution logic 316 locates corresponding path information in an element list table 306 by computing a pointer to a specific index in the element list table 306 where the path information may be found. The path selection logic then uses this path information to determine where to forward the data unit (e.g., a specific egress port, internal component, traffic manager, etc.)”) (consider further column 23, lines 18-67, “For arriving data units belonging to ALB groups determined to be ALB-enabled, a flow identifier generator 308 identifies the ALB flow to which the data unit is assigned. For example, an ALB flow identifier may be computed based on various data unit attributes (e.g., fields of the packet header, such as described previously), using hash-based or other mechanisms such as described elsewhere herein. The ALB flow identifier may also optionally be computed based on one or more ALB group attributes resolved or retrieved from the ALB group attributes table 310. For example, a set of individual flow identifiers computed using data unit attributes may be aggregated into a single ALB flow based on ranges of identifiers, modulo-based buckets, or other mapping mechanisms indicated by the one or more ALB group attributes. Moreover, in an embodiment, an individual flow identifier or aggregated flow identifier may be adapted so as to be unique across all ALB groups, such as by adding an offset associated with the ALB group or appending an ALB group identifier. The ALB flow identifier may or may not be the same as a flow identifier (e.g., ECMP identifier, LAG identifier, etc.) generated by the default path selection logic 380. Additionally, optionally or alternatively, the ALB flow identifier may or may not be generated from the same attributes (e.g., five-tuple attributes, a set of source and destination IP addresses, source and destination IP ports and protocol, etc.) of data units used to generate the flow identifier for the default path selection logic 380. In an embodiment, the ALB flow identifier is calculated as a function of: (a) a hash value computed with a hash function (which computes or produces a hash value based on a given hash key) from selected data fields (representing a hash key) of each arriving data unit; (b) an ALB group base pointer; and (c) a ALB group flow count attribute, the latter two of which may be stored in, for instance, the ALB group attribute table 310. The ALB group flow count attribute may be a per-ALB-group attribute for each ALB group, which indicates the number of ALB flows that exist for the group, thus controlling the granularity at which flows are managed for the group. The function may be, for instance, to sum the ALB group base pointer with the result of a modulo operation between the hash value and the ALB group flow count attribute. Example traffic flow types to be managed in an ALB group may include, but are not necessarily limited to only, any of: one or more lossy flow types, one or more lossless flow types, and so forth. A traffic flow type may be, but is not necessarily, specified with a flow-type attribute value in an ALB or non-ALB configuration table accessible to the ALB operations.”)
Regarding claim 12, Matthews taught the method according to claim 1, wherein the first traffic characteristic information of the first packet comprises one or more of the following:
differentiated services code point (DSCP) information of the first packet, priority information of the first packet, ingress port information of the first packet, virtual local area network (VLAN) information of the first packet, ingress port group information of the first packet, egress port information of the first packet, egress port group information of the first packet, or virtual routing and forwarding (VRF) table information of the first packet. (consider column 4, lines 3-16, “Data units may be grouped into traffic flows based on a variety of flow identification mechanisms. For instance, traffic flows are often identified based on data unit attributes, such as by a 5-tuple combination of the destination IP address, source IP address, destination TCP/IP port, source TCP/IP port, and protocol, or any other suitable set of one or more data unit attributes. In an embodiment, such individual traffic flows may be aggregated into ALB flows, each of which may be identified with a unique ALB flow identifier. The ALB flow identifier may be provided in a data unit itself (e.g., in a packet header), or generated from data unit attributes using a mapping function, such as a hash function, to create the unique identifier.”) (consider further column 9, line 56-column 10, line 10, “When a node 110 receives a data unit, it typically examines addressing information within the data unit (and/or other information within the data unit) to determine how to process the data unit. The addressing information may be, for instance, an Internet Protocol (IP) address, MPLS label, or any other suitable information. If the addressing information indicates that the receiving node 110 is not the destination for the data unit, the receiving node 110 may look up the destination node 110 within receiving node's routing information and route the data unit to another node 110 connected to the receiving node 110 based on forwarding instructions associated with the destination node 110 (or an address group to which the destination node belongs). The forwarding instructions may indicate, for instance, an outgoing port over which to send the data unit, a label to attach the data unit, a next hop, etc. In cases where multiple (e.g., equal-cost, non-equal-cost, etc.) paths to the destination node 110 are possible, the forwarding instructions may include information indicating a suitable approach for selecting one of those paths, or a path deemed to be the best path may already be defined.”) (consider further column 13, line 35-column 14, line 5, “Different packet processors may be configured to perform different packet processing tasks. These tasks may include, for example, identifying paths along which to forward data units 205, forwarding data units 205 to egress arbiters 260, implementing flow control and/or other policies, manipulating packets, performing statistical or debugging operations, making measurements related to delays and/or port loadings, determining port conditions and/or states, aggregating and broadcasting port conditions and/or states, performing hash-based loading balancing, performing ALB operations, and so forth. Based on decisions made while processing a data unit 205, a packet processor may, in some embodiments, and/or for certain processing tasks, manipulate a data unit 205 directly. For instance, the packet processor may add, delete, or modify information in a data unit header or payload. In other embodiments, and/or for other processing tasks, a packet processor may generate control information that accompanies the data unit 205, or is merged with the data unit 205, as the data unit 205 continues through the device 200. This control information may then be utilized by other components of the device 200 to implement decisions made by the packet processor.”) (again, consider generally column 12, lines 17-32, “A non-limiting example flow of a data unit 205 through components of a device 200 is as follows. The data unit 205 may be received by a port 210. The data unit 205 is buffered by an arbiter 220 until it can be processed by an ingress packet processor (IPP) 230, and then delivered to an interconnect. From the interconnect, the data unit 205 is forwarded to a traffic manager 240. Traffic manager 240 stores the data unit 205 in a buffer 244 and assigns the data unit 205 to a queue 245. Traffic manager 240 manages the flow of the data unit 205 through the queue 245 until the data unit 205 is released to an egress packet processor (EPP) 250. Depending on the processing, the traffic manager 240 may then assign the data unit 205 to another queue 245 so that it may be processed by yet another EPP 250, or the EPP 250 may send the data unit 205 to an egress arbiter 260 from which the data unit 205 is finally forwarded out another port 290.”) (again, consider column 21, line 50-column 22, line 5, specifically “For every arriving data unit, the default path selection logic 380 performs a lookup using a multipath group identifier 330 into a group attribute table 302 to access or otherwise resolve the group attributes of a multipath group of paths by which the arriving data unit may be forwarded. The group identifier may be determined based on one or more attributes associated with or extracted from the arriving data unit, such as by a lookup of a destination address specified in the packet header against a prefix table or other forwarding table. Using the group identifier 330, attributes of a corresponding multipath group of paths are located in a group attributes table 302. Element selection logic 304 is used to select a specific element (corresponding to a specific path) in the group, such as by using a hash function of various packet header fields, as described elsewhere herein. Path resolution logic 316 locates corresponding path information in an element list table 306 by computing a pointer to a specific index in the element list table 306 where the path information may be found. The path selection logic then uses this path information to determine where to forward the data unit (e.g., a specific egress port, internal component, traffic manager, etc.)”)
Regarding claim 13, Matthews taught the method according to claim 1, wherein the first load balancing algorithm or the second load balancing algorithm is one of the following:
equal-cost multi-path routing (ECMP), weight-cost multi-path routing (WCMP), or link aggregation (LAG). (again, consider further column 21, lines 12-38 regarding “Automatic Load Balancing” wherein “A network device, such as network device 200 of FIG. 2 or any other switch, router, or network device, may implement ALB techniques to perform path selection operations. In an embodiment, the ALB techniques may be integrated with, or used to enhance, load balancing techniques in connection with path groups based on ECMP, LAG, or other multipath grouping mechanisms. The network device may perform the ALB-based path selection operations using device, path, and/or other statistics collected and generated by the network device under the techniques as described herein. In an embodiment, the ALB path selection logic and a default path selection logic may be implemented in parallel. Data units having certain characteristics may be designated as ALB-eligible, in that the path selection logic may select paths for the data units using the ALB-selection logic instead of the default path selection logic. FIG. 3A illustrates an example path resolution logic 300 in which an ALB-based path selection mechanism may be used in place of default load balancing selection mechanism for multi-path groups (e.g., ECMP, LAG, etc.) for a certain amount of traffic in a network device. In some operational scenarios, some or all of the path resolution logic 300 and/or load balancing process flows may be implemented in an ingress packet processor such as IPP 230 of FIG. 2A, or other suitable component of a network device.”) (again, consider further generally column 21, line 40-column 26, line 28 regarding “Default Path Selection Logic”, “ALB Flow Identification”, and “ALB Flow Categorization”, specifically column 21, lines 42-46, “According to an embodiment, the path selection logic includes a default path selection logic 380, which may be based on a group attribute table 302, such as an ECMP group table or LAG group table. In an embodiment, the group table may be a weighted-cost multi-path (“WCMP”) table…”)
Regarding claim 27, Matthews taught the method according to claim 1, wherein the forwarding, by the network device, based on the second traffic characteristic information of the second packet, the second packet by using a second load balancing algorithm that matches the second traffic characteristic information comprises:
determining, by the network device based on the second load balancing algorithm that matches the second traffic characteristic information, a second target hash function used for the second packet and a second target hash key composition member of the second packet; obtaining, by the network device, a second target hash value through computing based on the second target hash function and the second target hash key composition member; and determining, by the network device, an egress port of the second packet based on the second target hash value. (consider generally column 12, lines 17-32, “A non-limiting example flow of a data unit 205 through components of a device 200 is as follows. The data unit 205 may be received by a port 210. The data unit 205 is buffered by an arbiter 220 until it can be processed by an ingress packet processor (IPP) 230, and then delivered to an interconnect. From the interconnect, the data unit 205 is forwarded to a traffic manager 240. Traffic manager 240 stores the data unit 205 in a buffer 244 and assigns the data unit 205 to a queue 245. Traffic manager 240 manages the flow of the data unit 205 through the queue 245 until the data unit 205 is released to an egress packet processor (EPP) 250. Depending on the processing, the traffic manager 240 may then assign the data unit 205 to another queue 245 so that it may be processed by yet another EPP 250, or the EPP 250 may send the data unit 205 to an egress arbiter 260 from which the data unit 205 is finally forwarded out another port 290.”) (again, column 21, line 50-column 22, line 5, specifically “For every arriving data unit, the default path selection logic 380 performs a lookup using a multipath group identifier 330 into a group attribute table 302 to access or otherwise resolve the group attributes of a multipath group of paths by which the arriving data unit may be forwarded. The group identifier may be determined based on one or more attributes associated with or extracted from the arriving data unit, such as by a lookup of a destination address specified in the packet header against a prefix table or other forwarding table. Using the group identifier 330, attributes of a corresponding multipath group of paths are located in a group attributes table 302. Element selection logic 304 is used to select a specific element (corresponding to a specific path) in the group, such as by using a hash function of various packet header fields, as described elsewhere herein. Path resolution logic 316 locates corresponding path information in an element list table 306 by computing a pointer to a specific index in the element list table 306 where the path information may be found. The path selection logic then uses this path information to determine where to forward the data unit (e.g., a specific egress port, internal component, traffic manager, etc.)”) (consider further column 23, lines 18-67, “For arriving data units belonging to ALB groups determined to be ALB-enabled, a flow identifier generator 308 identifies the ALB flow to which the data unit is assigned. For example, an ALB flow identifier may be computed based on various data unit attributes (e.g., fields of the packet header, such as described previously), using hash-based or other mechanisms such as described elsewhere herein. The ALB flow identifier may also optionally be computed based on one or more ALB group attributes resolved or retrieved from the ALB group attributes table 310. For example, a set of individual flow identifiers computed using data unit attributes may be aggregated into a single ALB flow based on ranges of identifiers, modulo-based buckets, or other mapping mechanisms indicated by the one or more ALB group attributes. Moreover, in an embodiment, an individual flow identifier or aggregated flow identifier may be adapted so as to be unique across all ALB groups, such as by adding an offset associated with the ALB group or appending an ALB group identifier. The ALB flow identifier may or may not be the same as a flow identifier (e.g., ECMP identifier, LAG identifier, etc.) generated by the default path selection logic 380. Additionally, optionally or alternatively, the ALB flow identifier may or may not be generated from the same attributes (e.g., five-tuple attributes, a set of source and destination IP addresses, source and destination IP ports and protocol, etc.) of data units used to generate the flow identifier for the default path selection logic 380. In an embodiment, the ALB flow identifier is calculated as a function of: (a) a hash value computed with a hash function (which computes or produces a hash value based on a given hash key) from selected data fields (representing a hash key) of each arriving data unit; (b) an ALB group base pointer; and (c) a ALB group flow count attribute, the latter two of which may be stored in, for instance, the ALB group attribute table 310. The ALB group flow count attribute may be a per-ALB-group attribute for each ALB group, which indicates the number of ALB flows that exist for the group, thus controlling the granularity at which flows are managed for the group. The function may be, for instance, to sum the ALB group base pointer with the result of a modulo operation between the hash value and the ALB group flow count attribute. Example traffic flow types to be managed in an ALB group may include, but are not necessarily limited to only, any of: one or more lossy flow types, one or more lossless flow types, and so forth. A traffic flow type may be, but is not necessarily, specified with a flow-type attribute value in an ALB or non-ALB configuration table accessible to the ALB operations.”) (it may be reasonably inferred that the teachings of Matthews are to be performed in a repetitive and iterative manner such that any elements involved in such functionality are duplicated as understood by those skilled in the computer networking art)
Regarding claim 28, Matthews taught the method according to claim 4, wherein the load balancing configuration information indicates an association relationship between a second load balancing algorithm and second traffic characteristic information; (again, consider column 3, line 38-column 4, line 27, column 21, lines 12-38, column 21, lines 42-46, and column 21, line 50-column 22, line 5) and
the forwarding, by the network device, based on the second traffic characteristic information of the second packet, the second packet by using a second load balancing algorithm that matches the second traffic characteristic information comprises:
determining, by the network device, based on the second traffic characteristic information of the second packet and the load balancing configuration information, the second load balancing algorithm that matches the second traffic characteristic information. (again, consider further column 21, lines 12-38 regarding “Automatic Load Balancing” wherein “A network device, such as network device 200 of FIG. 2 or any other switch, router, or network device, may implement ALB techniques to perform path selection operations. In an embodiment, the ALB techniques may be integrated with, or used to enhance, load balancing techniques in connection with path groups based on ECMP, LAG, or other multipath grouping mechanisms. The network device may perform the ALB-based path selection operations using device, path, and/or other statistics collected and generated by the network device under the techniques as described herein. In an embodiment, the ALB path selection logic and a default path selection logic may be implemented in parallel. Data units having certain characteristics may be designated as ALB-eligible, in that the path selection logic may select paths for the data units using the ALB-selection logic instead of the default path selection logic. FIG. 3A illustrates an example path resolution logic 300 in which an ALB-based path selection mechanism may be used in place of default load balancing selection mechanism for multi-path groups (e.g., ECMP, LAG, etc.) for a certain amount of traffic in a network device. In some operational scenarios, some or all of the path resolution logic 300 and/or load balancing process flows may be implemented in an ingress packet processor such as IPP 230 of FIG. 2A, or other suitable component of a network device.”) (again, consider further generally column 21, line 40-column 26, line 28 regarding “Default Path Selection Logic”, “ALB Flow Identification”, and “ALB Flow Categorization”, specifically specifically column 21, lines 42-46, “According to an embodiment, the path selection logic includes a default path selection logic 380, which may be based on a group attribute table 302, such as an ECMP group table or LAG group table. In an embodiment, the group table may be a weighted-cost multi-path (“WCMP”) table…”, column 21, line 50-column 22, line 5, “For every arriving data unit, the default path selection logic 380 performs a lookup using a multipath group identifier 330 into a group attribute table 302 to access or otherwise resolve the group attributes of a multipath group of paths by which the arriving data unit may be forwarded. The group identifier may be determined based on one or more attributes associated with or extracted from the arriving data unit, such as by a lookup of a destination address specified in the packet header against a prefix table or other forwarding table. Using the group identifier 330, attributes of a corresponding multipath group of paths are located in a group attributes table 302. Element selection logic 304 is used to select a specific element (corresponding to a specific path) in the group, such as by using a hash function of various packet header fields, as described elsewhere herein. Path resolution logic 316 locates corresponding path information in an element list table 306 by computing a pointer to a specific index in the element list table 306 where the path information may be found. The path selection logic then uses this path information to determine where to forward the data unit (e.g., a specific egress port, internal component, traffic manager, etc.)” and column 22, lines 39-64, “The ALB flow identification operation may, in some embodiments, then check to see if the ALB group determined for an arriving data unit is eligible for further ALB operations. This may involve, for instance, determining if the ALB group identifier for the data unit is in a set or range of values that has been marked as being ALB-eligible. The ALB group identifier may be specifically marked as eligible in, for instance, the ALB group attribute table, or ranges of ALB identifiers (or multipath group identifiers 330) may be marked as eligible. An ALB group may have been marked as eligible, for instance, manually by a system administrator or automatically in response to various conditions. For groups that are not eligible, the default path selection logic 380 is used to select a path for the data unit, whereas otherwise the ALB selection logic 390 is utilized. In some embodiments, all multipath groups are ALB-eligible, and thus this check may be skipped. For example, as depicted in FIG. 3, using the group identifier 330 (and optionally the flow type) for the arriving data unit, a lookup into an ALB group attribute table 310 is performed to resolve ALB group attributes applicable for the ALB group to which the arriving data unit belongs. The ALB group attributes for the data unit, as resolved from the ALB group attribute table 310, can be used to determine whether the arriving data unit is enabled or eligible for further ALB operations.”) (it may be reasonably inferred that the teachings of Matthews are to be performed in a repetitive and iterative manner such that any elements involved in such functionality are duplicated as understood by those skilled in the computer networking art)
Regarding claim 29, Matthews taught the method according to claim 1, wherein the forwarding, by the network device, based on the second traffic characteristic information of the second packet, the second packet by using a second load balancing algorithm that matches the second traffic characteristic information comprises:
determining, by the network device, a second target logic circuit based on the second traffic characteristic information of the second packet, wherein the second target logic circuit runs the second load balancing algorithm corresponding to the second packet; and processing, by the network device, the second packet by using the second target logic circuit, and determining an egress port of the second packet. (consider generally column 12, lines 17-32, “A non-limiting example flow of a data unit 205 through components of a device 200 is as follows. The data unit 205 may be received by a port 210. The data unit 205 is buffered by an arbiter 220 until it can be processed by an ingress packet processor (IPP) 230, and then delivered to an interconnect. From the interconnect, the data unit 205 is forwarded to a traffic manager 240. Traffic manager 240 stores the data unit 205 in a buffer 244 and assigns the data unit 205 to a queue 245. Traffic manager 240 manages the flow of the data unit 205 through the queue 245 until the data unit 205 is released to an egress packet processor (EPP) 250. Depending on the processing, the traffic manager 240 may then assign the data unit 205 to another queue 245 so that it may be processed by yet another EPP 250, or the EPP 250 may send the data unit 205 to an egress arbiter 260 from which the data unit 205 is finally forwarded out another port 290.”) (consider further column 13, lines 35-60, “Different packet processors may be configured to perform different packet processing tasks. These tasks may include, for example, identifying paths along which to forward data units 205, forwarding data units 205 to egress arbiters 260, implementing flow control and/or other policies, manipulating packets, performing statistical or debugging operations, making measurements related to delays and/or port loadings, determining port conditions and/or states, aggregating and broadcasting port conditions and/or states, performing hash-based loading balancing, performing ALB operations, and so forth. A device 200 may comprise any number of packet processors configured to perform any number of processing tasks. In an embodiment, the packet processors within a device 200 may be arranged such that the output of one packet processor is, eventually, inputted into another packet processor, in such a manner as to pass data units 205 from certain packet processor(s) to other packet processor(s) in a sequence of stages, until finally disposing of the data units 205 (e.g., by sending the data units 205 out an egress port 290, “dropping” data units 205, etc.). The exact set and/or sequence of packet processors that process a given data unit 205 may vary, in some embodiments, depending on the attributes of the data unit 205 and/or the state of the device 200. There is no limit to the number of packet processor(s) that may be chained together in such a manner.”) (consider further column 14, lines 19-67 regarding “Ingress and Egress Processing”, specifically “In an embodiment, a packet processor may be generally classified as an IPP 230 or an EPP 250… The EPP(s) 250 of a device 200, by contrast, may be configured to perform non-intake tasks necessary to implement the forwarding logic of the device 200. These tasks may include, for example, tasks such as identifying paths along which to forward data units 205, implementing flow control and/or other policies, manipulating data units 205, performing statistical or debugging operations, making measurements related to delays and/or port loadings, determining port conditions and/or states, sending measurements and/or port conditions/states to traffic managers, and so forth. In an embodiment, there may be different EPP(s) 250 assigned to different flows or other categories of traffic, such that not all data units 205 will be processed by the same EPP 250… In an embodiment, each EPP 250 is coupled to a different group of egress ports 290 to which they may send data units 205 processed by the EPP 250. In an embodiment, access to a group of ports 290 may be regulated via an egress arbiter 260 coupled to the EPP 250.”) (it may be reasonably inferred that the teachings of Matthews are to be performed in a repetitive and iterative manner such that any elements involved in such functionality are duplicated as understood by those skilled in the computer networking art)
Regarding claim 30, Matthews taught the method according to claim 29, wherein the processing, by the network device, the second packet by using the second target logic circuit, and determining the egress port of the second packet comprises:
processing, by the network device, the second packet by using the second target logic circuit, and determining a second target hash function used for the second packet and a second target hash key composition member of the second packet; obtaining, by the network device, a second target hash value through computing based on the second target hash function and the second target hash key composition member; and determining, by the network device, the egress port of the second packet based on the second target hash value. (again, consider column 13, lines 35-60, “Different packet processors may be configured to perform different packet processing tasks. These tasks may include, for example, identifying paths along which to forward data units 205, forwarding data units 205 to egress arbiters 260, implementing flow control and/or other policies, manipulating packets, performing statistical or debugging operations, making measurements related to delays and/or port loadings, determining port conditions and/or states, aggregating and broadcasting port conditions and/or states, performing hash-based loading balancing, performing ALB operations, and so forth.”) (again, consider generally column 12, lines 17-32, “A non-limiting example flow of a data unit 205 through components of a device 200 is as follows. The data unit 205 may be received by a port 210. The data unit 205 is buffered by an arbiter 220 until it can be processed by an ingress packet processor (IPP) 230, and then delivered to an interconnect. From the interconnect, the data unit 205 is forwarded to a traffic manager 240. Traffic manager 240 stores the data unit 205 in a buffer 244 and assigns the data unit 205 to a queue 245. Traffic manager 240 manages the flow of the data unit 205 through the queue 245 until the data unit 205 is released to an egress packet processor (EPP) 250. Depending on the processing, the traffic manager 240 may then assign the data unit 205 to another queue 245 so that it may be processed by yet another EPP 250, or the EPP 250 may send the data unit 205 to an egress arbiter 260 from which the data unit 205 is finally forwarded out another port 290.”) (again, consider column 21, line 50-column 22, line 5, specifically “For every arriving data unit, the default path selection logic 380 performs a lookup using a multipath group identifier 330 into a group attribute table 302 to access or otherwise resolve the group attributes of a multipath group of paths by which the arriving data unit may be forwarded. The group identifier may be determined based on one or more attributes associated with or extracted from the arriving data unit, such as by a lookup of a destination address specified in the packet header against a prefix table or other forwarding table. Using the group identifier 330, attributes of a corresponding multipath group of paths are located in a group attributes table 302. Element selection logic 304 is used to select a specific element (corresponding to a specific path) in the group, such as by using a hash function of various packet header fields, as described elsewhere herein. Path resolution logic 316 locates corresponding path information in an element list table 306 by computing a pointer to a specific index in the element list table 306 where the path information may be found. The path selection logic then uses this path information to determine where to forward the data unit (e.g., a specific egress port, internal component, traffic manager, etc.)”) (consider further column 23, lines 18-67, “For arriving data units belonging to ALB groups determined to be ALB-enabled, a flow identifier generator 308 identifies the ALB flow to which the data unit is assigned. For example, an ALB flow identifier may be computed based on various data unit attributes (e.g., fields of the packet header, such as described previously), using hash-based or other mechanisms such as described elsewhere herein. The ALB flow identifier may also optionally be computed based on one or more ALB group attributes resolved or retrieved from the ALB group attributes table 310. For example, a set of individual flow identifiers computed using data unit attributes may be aggregated into a single ALB flow based on ranges of identifiers, modulo-based buckets, or other mapping mechanisms indicated by the one or more ALB group attributes. Moreover, in an embodiment, an individual flow identifier or aggregated flow identifier may be adapted so as to be unique across all ALB groups, such as by adding an offset associated with the ALB group or appending an ALB group identifier. The ALB flow identifier may or may not be the same as a flow identifier (e.g., ECMP identifier, LAG identifier, etc.) generated by the default path selection logic 380. Additionally, optionally or alternatively, the ALB flow identifier may or may not be generated from the same attributes (e.g., five-tuple attributes, a set of source and destination IP addresses, source and destination IP ports and protocol, etc.) of data units used to generate the flow identifier for the default path selection logic 380. In an embodiment, the ALB flow identifier is calculated as a function of: (a) a hash value computed with a hash function (which computes or produces a hash value based on a given hash key) from selected data fields (representing a hash key) of each arriving data unit; (b) an ALB group base pointer; and (c) a ALB group flow count attribute, the latter two of which may be stored in, for instance, the ALB group attribute table 310. The ALB group flow count attribute may be a per-ALB-group attribute for each ALB group, which indicates the number of ALB flows that exist for the group, thus controlling the granularity at which flows are managed for the group. The function may be, for instance, to sum the ALB group base pointer with the result of a modulo operation between the hash value and the ALB group flow count attribute. Example traffic flow types to be managed in an ALB group may include, but are not necessarily limited to only, any of: one or more lossy flow types, one or more lossless flow types, and so forth. A traffic flow type may be, but is not necessarily, specified with a flow-type attribute value in an ALB or non-ALB configuration table accessible to the ALB operations.”) (it may be reasonably inferred that the teachings of Matthews are to be performed in a repetitive and iterative manner such that any elements involved in such functionality are duplicated as understood by those skilled in the computer networking art)
Claims 14-15 and 17-21 recite an apparatus that contain substantially the same limitations as recited in claims 1-2 and 4-8 respectively and are also rejected under 35 USC § 102(a)(1) as being anticipated by the same teachings of Matthews.
Claim 31 recites a non-transitory computer readable storage medium that contains substantially the same limitations as recited in claim 1 and is also rejected under 35 USC § 102(a)(1) as being anticipated by the same teachings of Matthews.
Allowable Subject Matter
Claims 3, 11, and 16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The cited prior art is directed to the use of multipath grouping of packet(s) in order to effect the load balancing by the grouping of such packet(s) including by the use of hash functionality to assign egress ports to the packet(s).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to G. C. Neurauter, Jr. whose telephone number is (571)272-3918. The examiner can normally be reached Monday-Friday 9am-5pm Eastern Time.
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, Tonia Dollinger, can be reached at 571-272-4170. 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.
/G. C. Neurauter, Jr./Primary Examiner, Art Unit 2459
Prosecution Insights