DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending in this application.
Response to Arguments
Applicant’s arguments regarding the rejections of claims 1-20 under 35 U.S.C. 112b have been fully considered and are persuasive. The rejections have been withdrawn. However, new 35 U.S.C. 112b rejections are applied to claims 1-20 based on the amendments.
Most of the objections to the drawings are withdrawn.
The 35 U.S.C. 101 rejections of claims 15-20 are withdrawn.
The double patenting rejections of claims 1-20 are withdrawn.
Applicant's arguments regarding the 35 U.S.C. 103 rejections of claims 1-20 have been fully considered but they are moot in light of the references being applied in the current rejection.
Information Disclosure Statement
The IDS filed on 05/14/2026 has been considered.
Drawings
Replacement Fig. 1C is objected to because it violates 37 CFR 1.84(q) which recites “Lead lines. Lead lines are those lines between the reference characters and the details referred to. Such lines may be straight or curved and should be as short as possible. They must originate in the immediate proximity of the reference character and extend to the feature indicated. Lead lines must not cross each other. Lead lines are required for each reference character except for those which indicate the surface or cross section on which they are placed. Such a reference character must be underlined to make it clear that a lead line has not been left out by mistake. Lead lines must be executed in the same way as lines in the drawing. See paragraph (l) of this section.”
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 1, 8, and 15 (line numbers refer to claim 1):
Lines 17, 18, 21,and 24-25 recite “the communications session” and it is unclear if this refers to “communication session”.
Claims 2-7, 9-14, and 16-20 are dependent claims of claims 1, 8, and 15, and fail to resolve the deficiencies of claims 1, 8, and 15, so they are rejected for the same reasons.
Claim Rejections - 35 USC § 103
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.
Claims 1 and 3-7 are rejected under 35 U.S.C. 103 as being unpatentable over Tewari et al. (US 20200371842 A1 hereinafter Tewari), in view of Ganji et al. (US 20170295097 A1 hereinafter Ganji), in view of Palermo et al. (US 20170286142 A1 hereinafter Palermo), in view of Brouer et al. (US 20230132905 A1 hereinafter Brouer), and further in view of Puri et al. (US 20180139101 A1 hereinafter Puri).
As per claim 1, Tewari teaches the invention substantially as claimed including a method for managing connections or bidirectional flows of a communication session in a software defined network (SDN) comprising a server hosting a virtual machine, the SDN further comprising a policy enforcement/forwarding engine, the method comprising ([0022] A first inbound or outbound data packet is received from/to the user's third-party hardware at the appliance and the SDN policies are applied to those packets using the appliance; [0005] The SDN appliance virtual machine may include one or more network containers (NCs). Each of the network containers may include SDN policies that are applicable to a user's virtual network. Therefore, a user's network container may process inbound and outbound packet traffic according to the SDN policies defined in the user's network container; [0042] Data center 200 may include servers 226a, 226b, and 226c (which may be referred to herein singularly as “a server 226” or in the plural as “the servers 226”) that provide computing resources available as virtual machines 228a and 228b; [0024] The multi-tenant appliance may be configured to apply the SDN policies; [0048] Network device 222 may facilitate communications within networks in data center 200, for example, by forwarding packets or other data communications as appropriate based on characteristics of such communications (e.g., header information including source and/or destination addresses, protocol identifiers, etc.)):
processing, by a policy enforcement/forwarding engine associated with the virtual machine, a communication session in accordance with packet processing rules associated with the virtual machine (Fig. 2A; [0022] A first inbound or outbound data packet is received from/to the user's third-party hardware at the appliance and the SDN policies are applied to those packets using the appliance; [0051] The policy rules (e.g., VFP rules); [0053] policies that are applicable to a virtual network implemented by the one or more virtual machines; [0048] Network device 222 may facilitate communications within networks in data center 200, for example, by forwarding packets or other data communications as appropriate based on characteristics of such communications);
storing, by the policy enforcement/forwarding engine, session information for the communication session ([0022] A first inbound or outbound data packet is received from/to the user's third-party hardware at the appliance and the SDN policies are applied to those packets using the appliance; [0004] third-party hardware such as high capacity processing machines or storage devices);
synchronizing, by the policy enforcement/forwarding engine to the acceleration device, packet processing rules associated with the communications session, wherein the synchronizing enables traffic associated with the communications session to be processed by the acceleration device; and offloading, by the policy enforcement/forwarding engine, policy enforcement of data traffic received after the synchronization of the packet processing rules for the communications session to the acceleration device ([0022] The SDN policies of the appliance may be offloaded to the FPGA. Subsequent packet data associated with the user's third-party hardware may be processed using the FPGA, where the FPGA updates the packet data using the SDN policies provided from the appliance; [0053] policies that are applicable to a virtual network implemented by the one or more virtual machines; [0005] The SDN appliance virtual machine may include one or more network containers (NCs). Each of the network containers may include SDN policies that are applicable to a user's virtual network. Therefore, a user's network container may process inbound and outbound packet traffic according to the SDN policies; [0006] In some embodiments disclosed herein, a multi-tenant appliance may be implemented which includes a network container for each tenant that incorporates third-party hardware. Each network container may include a hairpin layer to reflect packets before arriving at the tenant's virtual machine(s); [0007] Thus the data traffic does not reach the virtual machine but gets reflected and is directed to the outbound rules. Since these are VFP rules that can get offloaded to the FPGA, traffic will be processed in hardware).
Tewari fails to teach storing, by the policy enforcement/forwarding engine, session information for the communication session in a connection table; determining, by the virtual machine, that the communication session meets a criterion for offloading policy enforcement of the communication session to an acceleration device; in response to the determining, sending, by the virtual machine to the policy enforcement/forwarding engine, a request to offload policy enforcement of the communication session from the policy enforcement/forwarding engine associated with virtual machine to the acceleration device and wherein synchronizing the packet processing rules comprises synchronizing connection state and transformation rules for the communication session prior to offloading policy enforcement of subsequent data traffic for the communications session.
However, Ganji teaches storing, by the policy enforcement/forwarding engine, session information for the communication session in a connection table ([0019] The connection table 116 includes multiple connection entries 126 including first through third connection entries 126a-126c. The connection entries 126 are the session entries 120; [0034] the second processor 108 generates and stores the first connection entry 126a in the connection table 116; [0017] Further, to enforce security in a communication network, the second processor discards unwanted IP packets based on predefined rules.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Tewari with the teachings of Ganji to optimize packet transmission (see Ganji [0018] optimize IP packet transmission).
Tewari and Ganji fail to teach determining, by the virtual machine, that the communication session meets a criterion for offloading policy enforcement of the communication session to an acceleration device; in response to the determining, sending, by the virtual machine to the policy enforcement/forwarding engine, a request to offload policy enforcement of the communication session from the policy enforcement/forwarding engine associated with the virtual machine to the acceleration device and wherein synchronizing the packet processing rules comprises synchronizing connection state and transformation rules for the communication session prior to offloading policy enforcement of subsequent data traffic for the communications session.
However, Palermo teaches determining, by the virtual machine, that the communication session meets a criterion for offloading policy enforcement of the communication session to an acceleration device; in response to the determining, offload policy enforcement of the communication session from the policy enforcement/forwarding engine associated with the virtual machine to the acceleration device ([0016] Each VM may perform the relevant processing of the network packets based on the service for which they are configured using a central processing unit (CPU) of the network device 106 (see, e.g., the CPU 202 of FIG. 2) and/or one or more acceleration units of the network device 106 (see, e.g., the acceleration units 206 of FIG. 2). In use, the network device 106 monitors each VM and determines whether the workload (e.g., service(s)) executed by any given VM is causing the present compute usage of the VM (e.g., usage of the CPU 202 on behalf of the VM) to exceed a predefined limit (e.g., 80% of assigned compute resources). In the illustrative embodiment, the “compute resources” of the CPU 202 is defined as the processing capacity of the CPU 202. If so, the network device 106 identifies and allocates a suitable purpose-specific acceleration unit to the VM to offload processing of the workload and thereby reduce the compute usage; [0031] the virtual machine management module is configured to initialize virtual machines within the network device 106 (e.g., for use in processing network packets) and to assign limits to each virtual machine (e.g., defining an amount of compute capability of the CPU 202 each virtual machine may use); [0021] The acceleration units 206 may be embodied as one or more devices and/or circuits capable of the functions described herein, including accelerating network packet processing tasks).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Tewari and Ganji with the teachings of Palermo to reduce compute usage (see Palermo [0016] In use, the network device 106 monitors each VM and determines whether the workload (e.g., service(s)) executed by any given VM is causing the present compute usage of the VM (e.g., usage of the CPU 202 on behalf of the VM) to exceed a predefined limit (e.g., 80% of assigned compute resources). In the illustrative embodiment, the “compute resources” of the CPU 202 is defined as the processing capacity of the CPU 202. If so, the network device 106 identifies and allocates a suitable purpose-specific acceleration unit to the VM to offload processing of the workload and thereby reduce the compute usage).
Tewari, Ganji, and Palermo fail to teach sending, by the virtual machine to the policy enforcement/forwarding engine, a request to offload policy enforcement and wherein synchronizing the packet processing rules comprises synchronizing connection state and transformation rules for the communication session prior to offloading policy enforcement of subsequent data traffic for the communications session.
However, Brouer teaches sending, by the virtual machine to the policy enforcement/forwarding engine, a request to offload policy enforcement ([0036] VM 110 may then request offload module 214 to offload the packet filter onto the vNIC).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Tewari, Ganji, and Palermo with the teachings of Brouer to reduce latencies (see Brouer [0013] Offloading the binary reduces the software overhead of the VM. For example, a VM may offload a filter (e.g., the Berkeley Packet Filter (BPF)) to a NIC. By enabling the NIC to filter which data packets the VM receives, the host system does not need to wake the VM or have the VM allocate resources for each received data packet. That is, the VM may remain in sleep mode or engaged in performing other tasks for each data packet dropped by the binary filter, thus lowering latency, power consumption, and preventing interruptions to the other tasks processed).
Tewari, Ganji, Palermo, and Brouer fail to teach wherein synchronizing the packet processing rules comprises synchronizing connection state and transformation rules for the communication session prior to offloading policy enforcement of subsequent data traffic for the communications session.
However, Puri teaches wherein synchronizing the packet processing rules comprises synchronizing connection state and transformation rules for the communication session prior to offloading policy enforcement of subsequent data traffic for the communications session ([0022] In order to ensure that previously established connections with the VM, via the source host switch, are maintained, the flow state and/or other connections rules may be transferred or migrated from the source switch to the destination switch; [0041] In order to maintain communication links established with a VM, for example, when it is live migrated to a different host device, the communication link transformations, rules, and/or state, may be transferred to the destination host and modified so that any prior reference in the connection information to the source host is changed to the destination host; [0046] Transformations that are performed by these SDN switches 226 and 238 are typically expressed in the form of rules. A typical rule may include: [0047] If a packet is addressed to the address of the underlay node (PA—Physical address), then transform it to the address in use in the overlay endpoint (CA—customer address or DIP); [0062] As illustrated, process 800 may begin at operation 802, in which connection rule information corresponding to a configured communication link including a virtual machine associated with a source host, may be obtained. In one example, operation 802 may be performed by SLB agent 220 of source host 244, for example, by querying VFP 224 and/or VM switch 226. The connection state information, which may include state information, layer transformations, or other rules, as described above, may be an example of connection state information 602. [0063] Next, at operation 804, the connection rule information may be transferred or communicated to a destination host selected for live migration of the virtual machine. Operation 804 may be an example of operation 608 described above, with connection state information 602 being transferred to destination host 246. Operation 804 may be performed by host 244, SLB agent 220, VFP 224, or VM switch 226, or a combination thereof. [0064] Next, at operation 806, which may be optional, the VM may be live migrated from the source host to a destination host; [0067] In some aspects of process 800, the virtual machine, after the live migration is complete, may communicate at least one data packet to the recipient device according to the modified connection rule information, at operation 810. As described above, process 800 may enable a live migrated VM to maintain communication links that were established prior to the live migration, that have specific rules or are associated with one or more states;).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Tewari, Ganji, Palermo, and Brouer with the teachings of Puri to improve performance (see [0055] Rules need not be re-evaluated for any existing flows that have been live migrated. For both stateful and stateless protocols, the performance benefits of using flow state even after live migration can be maintained.).
As per claim 3, Tewari, Ganji, Palermo, Brouer, and Puri teach the method of claim 1. Palermo teaches wherein the determining, by the virtual machine, that the communication session meets a criterion comprises meeting a performance threshold ([0016] Each VM may perform the relevant processing of the network packets based on the service for which they are configured using a central processing unit (CPU) of the network device 106 (see, e.g., the CPU 202 of FIG. 2) and/or one or more acceleration units of the network device 106 (see, e.g., the acceleration units 206 of FIG. 2). In use, the network device 106 monitors each VM and determines whether the workload (e.g., service(s)) executed by any given VM is causing the present compute usage of the VM (e.g., usage of the CPU 202 on behalf of the VM) to exceed a predefined limit (e.g., 80% of assigned compute resources). In the illustrative embodiment, the “compute resources” of the CPU 202 is defined as the processing capacity of the CPU 202. If so, the network device 106 identifies and allocates a suitable purpose-specific acceleration unit to the VM to offload processing of the workload and thereby reduce the compute usage).
As per claim 4, Tewari, Ganji, Palermo, Brouer, and Puri teach the method of claim 1. Tewari teaches wherein the synchronization to the acceleration device comprises parsing a plurality of packet processing rules to identify packet processing rules that are applicable to the virtual machine as a source or destination ([0007] In one embodiment, the rules may be implemented as virtual filtering platform (VFP) rules that may be offloaded to a field-programmable gate array (FPGA) device which is configured to be a hardware acceleration device so that data traffic will be processed in hardware and minimize impact to software; [0022] The SDN policies of the appliance may be offloaded to the FPGA; [0005] The SDN appliance virtual machine may include one or more network containers (NCs). Each of the network containers may include SDN policies that are applicable to a user's virtual network. Therefore, a user's network container may process inbound and outbound packet traffic according to the SDN policies defined in the user's network container; [0053] Operation 301 may be followed by operation 303. Operation 303 illustrates accessing policies that are applicable to a virtual network implemented by the one or more virtual machines.).
As per claim 5, Tewari, Ganji, Palermo, Brouer, and Puri teach the method of claim 1. Tewari teaches wherein the acceleration device comprises an SDN appliance or a smart switch ([0020] In some computing environments that provide virtualized computing and storage services, host networking may be configured to offload tasks to hardware devices. Such devices may be referred to as a hardware acceleration device…the peripheral device may be a network communications device, such as a network interface card (NIC). Such a NIC may be referred to herein as a smartNIC or sNIC; [0021] The specialized hardware appliance may variously be referred to herein as a multi-tenant appliance, SDN appliance).
As per claim 6, Tewari, Ganji, Palermo, Brouer, and Puri teach the method of claim 1. Palermo teaches further comprising returning policy enforcement of the communication session to the virtual machine ([0043] When the present compute of the VM drops below the compute capability usage limit, the resource allocation module 350 is configured to deallocate at least a portion of the allocated processing capacity of the respective acceleration unit 206. In such embodiments, the VM may then migrate from using the acceleration unit instructions usable by the applicable acceleration unit 206 back to using the standard instructions usable by the CPU 202; [0016] Each VM may perform the relevant processing of the network packets).
As per claim 7, Tewari, Ganji, Palermo, Brouer, and Puri teach the method of claim 6. Palermo teaches wherein the returning the policy enforcement is performed in response to determining that the communication session no longer meets the criterion for offloading policy enforcement of the communication session to the acceleration device ([0016] If so, the network device 106 identifies and allocates a suitable purpose-specific acceleration unit to the VM to offload processing of the workload and thereby reduce the compute usage. When the workload decreases, the network device 106 may deallocate the acceleration unit for use by another VM; [0043] When the present compute of the VM drops below the compute capability usage limit, the resource allocation module 350 is configured to deallocate at least a portion of the allocated processing capacity of the respective acceleration unit 206. In such embodiments, the VM may then migrate from using the acceleration unit instructions usable by the applicable acceleration unit 206 back to using the standard instructions usable by the CPU 202; [0016] Each VM may perform the relevant processing of the network packets).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Tewari, Ganji, Palermo, Brouer, and Puri, as applied to claim 1 above, in view of Wang (US 20160014025 A1).
As per claim 2, Tewari, Ganji, Palermo, and Brouer teach the method of claim 1. Tewari teaches further comprising a next hop for the communication session to the virtual machine ([0005] if the SDN policies are enforced by virtual machines running in the network containers, an extra hop into the virtual machine is required; [0010] In an embodiment, when a ToR does not have an effective policy for a network packet, the ToR may offload policy evaluation to the multi-tenant appliance and obtain applicable policies from the multi-tenant appliance, after which the ToR may determine the next hop for the network packet. This policy evaluation need only be done for the first packet. The independent device may update the ToR when a policy becomes invalid; [0021] This specialized hardware appliance may work with devices such as the ToR to provide line rate evaluation of policies and routing of a next hop where a network packet should be forwarded. The specialized hardware appliance may variously be referred to herein as a multi-tenant appliance, SDN appliance, or appliance.).
Tewari, Ganji, Palermo, Brouer, and Puri fail to teach updating a next hop IP address of a tunnel set up for the communication session to the virtual machine.
However, Wang teaches updating a next hop IP address of a tunnel set up for the communication session to the virtual machine ([0058] The router 341 may receive the BGP update message, and identify the host route path attribute field carried in the BGP update message. When determining that the second GRE tunnel reaching the router 322 has been established, the router 341 may find a host route entry from the route table according to the IP address prefix 10.1.1.1 and the length of the IP address prefix 32 carried in the NLRI field, and determine that the next-hop in the host route entry is tunnel 1; [0081] The route controlling unit 631 may generate a host route entry according to an IP address of a virtual machine, and generate an update message carrying a host route of the generated host route entry. An IP address prefix of the host route and a length of the IP address prefix respectively correspond an IP address of the virtual machine and a length of the IP address).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Tewari, Ganji, Palermo, Brouer, and Puri with the teachings of Wang to provide reliability (see Wang [0001] In order to achieve high reliability and redundancy deployment, many enterprise networks and data centers include multiple layer-2 networks located in different geographical locations…A virtual machine may migrate among the layer-2 networks to achieve dynamic allocation and management of resources among the layer-2 networks.).
Claims 8, 10-17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tewari, in view of Palermo, in view of Brouer, and further in view of Puri.
As per claim 8, Tewari teaches a system for managing connections or bidirectional flows of a communication session in a software defined network (SDN), the system comprising: a processing unit; and a computer readable medium having encoded thereon computer readable instructions that when executed by the processing unit cause the system to perform operations comprising ([0022] A first inbound or outbound data packet is received from/to the user's third-party hardware at the appliance and the SDN policies are applied to those packets using the appliance; [0005] The SDN appliance virtual machine may include one or more network containers (NCs). Each of the network containers may include SDN policies that are applicable to a user's virtual network. Therefore, a user's network container may process inbound and outbound packet traffic according to the SDN policies defined in the user's network container; [0071] It should be appreciated that the subject matter presented herein may be implemented as a computer process, a computer-controlled apparatus, a computing system, an article of manufacture, such as a computer-readable storage medium, or a component including hardware logic for implementing functions, such as a field-programmable gate array (FPGA) device, a massively parallel processor array (MPPA) device; [0073] In various embodiments, computing device 600 may be a uniprocessor system including one processor 610 or a multiprocessor system; [0048] Network device 222 may facilitate communications within networks in data center 200, for example, by forwarding packets or other data communications as appropriate based on characteristics of such communications (e.g., header information including source and/or destination addresses, protocol identifiers, etc.)): a virtual machine hosted by a server of the SDN ([0042] Data center 200 may include servers 226a, 226b, and 226c (which may be referred to herein singularly as “a server 226” or in the plural as “the servers 226”) that provide computing resources available as virtual machines 228a and 228b; [0005] The SDN appliance virtual machine); synchronizing, to the acceleration device, packet processing rules associated with the virtual machine, wherein the synchronizing enables traffic associated with the communication session to be processed by the acceleration device; and offloading policy enforcement of data traffic received after the synchronization of the packet processing rules for the communication session to the acceleration device ([0022] The SDN policies of the appliance may be offloaded to the FPGA. Subsequent packet data associated with the user's third-party hardware may be processed using the FPGA, where the FPGA updates the packet data using the SDN policies provided from the appliance; [0053] policies that are applicable to a virtual network implemented by the one or more virtual machines; [0005] The SDN appliance virtual machine may include one or more network containers (NCs). Each of the network containers may include SDN policies that are applicable to a user's virtual network. Therefore, a user's network container may process inbound and outbound packet traffic according to the SDN policies; [0006] In some embodiments disclosed herein, a multi-tenant appliance may be implemented which includes a network container for each tenant that incorporates third-party hardware. Each network container may include a hairpin layer to reflect packets before arriving at the tenant's virtual machine(s); [0007] Thus the data traffic does not reach the virtual machine but gets reflected and is directed to the outbound rules. Since these are VFP rules that can get offloaded to the FPGA, traffic will be processed in hardware).
Tewari fails to teach receiving, from a virtual machine, a request to offload policy enforcement of a communication session from the virtual machine to an acceleration device, wherein the communication session meets a criterion for offloading policy enforcement of the communication session to the acceleration device; wherein synchronizing the packet processing rules comprises synchronizing connection state and transformation rules for the communication session prior to offloading policy enforcement of subsequent data traffic for the communications session.
However, Palermo teaches receiving, from a virtual machine, offload policy enforcement of a communication session from the virtual machine to an acceleration device, wherein the communication session meets a criterion for offloading policy enforcement of the communication session to the acceleration device ([0016] Each VM may perform the relevant processing of the network packets based on the service for which they are configured using a central processing unit (CPU) of the network device 106 (see, e.g., the CPU 202 of FIG. 2) and/or one or more acceleration units of the network device 106 (see, e.g., the acceleration units 206 of FIG. 2). In use, the network device 106 monitors each VM and determines whether the workload (e.g., service(s)) executed by any given VM is causing the present compute usage of the VM (e.g., usage of the CPU 202 on behalf of the VM) to exceed a predefined limit (e.g., 80% of assigned compute resources). In the illustrative embodiment, the “compute resources” of the CPU 202 is defined as the processing capacity of the CPU 202. If so, the network device 106 identifies and allocates a suitable purpose-specific acceleration unit to the VM to offload processing of the workload and thereby reduce the compute usage; [0031] the virtual machine management module is configured to initialize virtual machines within the network device 106 (e.g., for use in processing network packets) and to assign limits to each virtual machine (e.g., defining an amount of compute capability of the CPU 202 each virtual machine may use); [0021] The acceleration units 206 may be embodied as one or more devices and/or circuits capable of the functions described herein, including accelerating network packet processing tasks).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Tewari with the teachings of Palermo to reduce compute usage (see Palermo [0016] In use, the network device 106 monitors each VM and determines whether the workload (e.g., service(s)) executed by any given VM is causing the present compute usage of the VM (e.g., usage of the CPU 202 on behalf of the VM) to exceed a predefined limit (e.g., 80% of assigned compute resources). In the illustrative embodiment, the “compute resources” of the CPU 202 is defined as the processing capacity of the CPU 202. If so, the network device 106 identifies and allocates a suitable purpose-specific acceleration unit to the VM to offload processing of the workload and thereby reduce the compute usage).
Tewari and Palermo fail to teach receiving, from a virtual machine, a request to offload policy enforcement; wherein synchronizing the packet processing rules comprises synchronizing connection state and transformation rules for the communication session prior to offloading policy enforcement of subsequent data traffic for the communications session.
However, Brouer teaches receiving, from a virtual machine, a request to offload policy enforcement ([0036] VM 110 may then request offload module 214 to offload the packet filter onto the vNIC).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Tewari and Palermo with the teachings of Brouer to reduce latencies (see Brouer [0013] Offloading the binary reduces the software overhead of the VM. For example, a VM may offload a filter (e.g., the Berkeley Packet Filter (BPF)) to a NIC. By enabling the NIC to filter which data packets the VM receives, the host system does not need to wake the VM or have the VM allocate resources for each received data packet. That is, the VM may remain in sleep mode or engaged in performing other tasks for each data packet dropped by the binary filter, thus lowering latency, power consumption, and preventing interruptions to the other tasks processed).
Tewari, Palermo, and Brouer fail to teach wherein synchronizing the packet processing rules comprises synchronizing connection state and transformation rules for the communication session prior to offloading policy enforcement of subsequent data traffic for the communications session.
However, Puri teaches wherein synchronizing the packet processing rules comprises synchronizing connection state and transformation rules for the communication session prior to offloading policy enforcement of subsequent data traffic for the communications session ([0022] In order to ensure that previously established connections with the VM, via the source host switch, are maintained, the flow state and/or other connections rules may be transferred or migrated from the source switch to the destination switch; [0041] In order to maintain communication links established with a VM, for example, when it is live migrated to a different host device, the communication link transformations, rules, and/or state, may be transferred to the destination host and modified so that any prior reference in the connection information to the source host is changed to the destination host; [0046] Transformations that are performed by these SDN switches 226 and 238 are typically expressed in the form of rules. A typical rule may include: [0047] If a packet is addressed to the address of the underlay node (PA—Physical address), then transform it to the address in use in the overlay endpoint (CA—customer address or DIP); [0062] As illustrated, process 800 may begin at operation 802, in which connection rule information corresponding to a configured communication link including a virtual machine associated with a source host, may be obtained. In one example, operation 802 may be performed by SLB agent 220 of source host 244, for example, by querying VFP 224 and/or VM switch 226. The connection state information, which may include state information, layer transformations, or other rules, as described above, may be an example of connection state information 602. [0063] Next, at operation 804, the connection rule information may be transferred or communicated to a destination host selected for live migration of the virtual machine. Operation 804 may be an example of operation 608 described above, with connection state information 602 being transferred to destination host 246. Operation 804 may be performed by host 244, SLB agent 220, VFP 224, or VM switch 226, or a combination thereof. [0064] Next, at operation 806, which may be optional, the VM may be live migrated from the source host to a destination host; [0067] In some aspects of process 800, the virtual machine, after the live migration is complete, may communicate at least one data packet to the recipient device according to the modified connection rule information, at operation 810. As described above, process 800 may enable a live migrated VM to maintain communication links that were established prior to the live migration, that have specific rules or are associated with one or more states;).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Tewari, Palermo, and Brouer with the teachings of Puri to improve performance (see [0055] Rules need not be re-evaluated for any existing flows that have been live migrated. For both stateful and stateless protocols, the performance benefits of using flow state even after live migration can be maintained.).
As per claim 10, Tewari, Palermo, Brouer, and Puri teach the system of claim 8. Palermo teaches wherein the criterion comprises a performance threshold ([0016] Each VM may perform the relevant processing of the network packets based on the service for which they are configured using a central processing unit (CPU) of the network device 106 (see, e.g., the CPU 202 of FIG. 2) and/or one or more acceleration units of the network device 106 (see, e.g., the acceleration units 206 of FIG. 2). In use, the network device 106 monitors each VM and determines whether the workload (e.g., service(s)) executed by any given VM is causing the present compute usage of the VM (e.g., usage of the CPU 202 on behalf of the VM) to exceed a predefined limit (e.g., 80% of assigned compute resources). In the illustrative embodiment, the “compute resources” of the CPU 202 is defined as the processing capacity of the CPU 202. If so, the network device 106 identifies and allocates a suitable purpose-specific acceleration unit to the VM to offload processing of the workload and thereby reduce the compute usage).
As per claim 11, Tewari, Palermo, Brouer, and Puri teach the system of claim 8. Tewari teaches wherein the synchronization to the acceleration device comprises parsing a plurality of packet processing rules to identify packet processing rules that are applicable to the virtual machine as a source or destination ([0007] In one embodiment, the rules may be implemented as virtual filtering platform (VFP) rules that may be offloaded to a field-programmable gate array (FPGA) device which is configured to be a hardware acceleration device so that data traffic will be processed in hardware and minimize impact to software; [0022] The SDN policies of the appliance may be offloaded to the FPGA; [0005] The SDN appliance virtual machine may include one or more network containers (NCs). Each of the network containers may include SDN policies that are applicable to a user's virtual network. Therefore, a user's network container may process inbound and outbound packet traffic according to the SDN policies defined in the user's network container; [0053] Operation 301 may be followed by operation 303. Operation 303 illustrates accessing policies that are applicable to a virtual network implemented by the one or more virtual machines.).
As per claim 12, Tewari, Palermo, Brouer, and Puri teach the system of claim 8. Tewari teaches wherein the acceleration device comprises an SDN appliance or a smart switch ([0020] In some computing environments that provide virtualized computing and storage services, host networking may be configured to offload tasks to hardware devices. Such devices may be referred to as a hardware acceleration device…the peripheral device may be a network communications device, such as a network interface card (NIC). Such a NIC may be referred to herein as a smartNIC or sNIC; [0021] The specialized hardware appliance may variously be referred to herein as a multi-tenant appliance, SDN appliance).
As per claim 13, Tewari, Palermo, Brouer, and Puri teach the system of claim 8. Palermo teaches further comprising computer readable instructions that when executed by the processing unit cause the system to perform operations comprising returning policy enforcement of the communication session to the virtual machine ([0043] When the present compute of the VM drops below the compute capability usage limit, the resource allocation module 350 is configured to deallocate at least a portion of the allocated processing capacity of the respective acceleration unit 206. In such embodiments, the VM may then migrate from using the acceleration unit instructions usable by the applicable acceleration unit 206 back to using the standard instructions usable by the CPU 202; [0016] Each VM may perform the relevant processing of the network packets; [0011] The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors).
As per claim 14, Tewari, Palermo, Brouer, and Puri teach the system of claim 13. Palermo teaches wherein the returning the policy enforcement is performed in response to determining that the communication session no longer meets the criterion for offloading policy enforcement of the communication session to the acceleration device ([0016] If so, the network device 106 identifies and allocates a suitable purpose-specific acceleration unit to the VM to offload processing of the workload and thereby reduce the compute usage. When the workload decreases, the network device 106 may deallocate the acceleration unit for use by another VM; [0043] When the present compute of the VM drops below the compute capability usage limit, the resource allocation module 350 is configured to deallocate at least a portion of the allocated processing capacity of the respective acceleration unit 206. In such embodiments, the VM may then migrate from using the acceleration unit instructions usable by the applicable acceleration unit 206 back to using the standard instructions usable by the CPU 202; [0016] Each VM may perform the relevant processing of the network packets).
As per claim 15, it is a non-transitory computer readable storage medium of claim 8, so it is rejected for similar reasons. Additionally, Tewari teaches a non-transitory computer readable storage medium having encoded thereon computer readable instructions that when executed by a system cause the system to perform operations ([0071] It should be appreciated that the subject matter presented herein may be implemented as a computer process, a computer-controlled apparatus, a computing system, an article of manufacture, such as a computer-readable storage medium, or a component including hardware logic for implementing functions, such as a field-programmable gate array (FPGA) device, a massively parallel processor array (MPPA) device).
As per claims 16, 17, 19, and 20, they are non-transitory computer readable storage medium claims of claims 10, 11, 13, and 14, so they are rejected for similar reasons.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Tewari, Palermo, Brouer, and Puri, as applied to claims 8 and 15 above, in view of Wang.
As per claim 9, Tewari, Palermo, Brouer, and Puri teach the system of claim 8. Tewari teaches further comprising computer readable instructions that when executed by the processing unit cause the system to perform operations comprising a next hop for the communication session to the virtual machine ([0005] if the SDN policies are enforced by virtual machines running in the network containers, an extra hop into the virtual machine is required; [0010] In an embodiment, when a ToR does not have an effective policy for a network packet, the ToR may offload policy evaluation to the multi-tenant appliance and obtain applicable policies from the multi-tenant appliance, after which the ToR may determine the next hop for the network packet. This policy evaluation need only be done for the first packet. The independent device may update the ToR when a policy becomes invalid; [0021] This specialized hardware appliance may work with devices such as the ToR to provide line rate evaluation of policies and routing of a next hop where a network packet should be forwarded. The specialized hardware appliance may variously be referred to herein as a multi-tenant appliance, SDN appliance, or appliance; [0071] It should be appreciated that the subject matter presented herein may be implemented as a computer process, a computer-controlled apparatus, a computing system, an article of manufacture, such as a computer-readable storage medium, or a component including hardware logic for implementing functions, such as a field-programmable gate array (FPGA) device, a massively parallel processor array (MPPA) device).
Tewari, Palermo, Brouer, and Puri fail to teach updating a next hop IP address of a tunnel set up for the communication session to the virtual machine
However, Wang teaches updating a next hop IP address of a tunnel set up for the communication session to the virtual machine ([0058] The router 341 may receive the BGP update message, and identify the host route path attribute field carried in the BGP update message. When determining that the second GRE tunnel reaching the router 322 has been established, the router 341 may find a host route entry from the route table according to the IP address prefix 10.1.1.1 and the length of the IP address prefix 32 carried in the NLRI field, and determine that the next-hop in the host route entry is tunnel 1; [0081] The route controlling unit 631 may generate a host route entry according to an IP address of a virtual machine, and generate an update message carrying a host route of the generated host route entry. An IP address prefix of the host route and a length of the IP address prefix respectively correspond an IP address of the virtual machine and a length of the IP address).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Tewari, Palermo, Brouer, and Puri with the teachings of Wang to provide reliability (see Wang [0001] In order to achieve high reliability and redundancy deployment, many enterprise networks and data centers include multiple layer-2 networks located in different geographical locations…A virtual machine may migrate among the layer-2 networks to achieve dynamic allocation and management of resources among the layer-2 networks.)
As per claim 18, it is a non-transitory computer readable storage medium claim of claim 9, so it is rejected for similar reasons.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HSING CHUN LIN whose telephone number is (571)272-8522. The examiner can normally be reached Mon - Fri 9AM-5PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/H.L./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights