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 .
Detailed Action
This office action is responsive to communication filed on 11/28/2023.
Claims 1- 20 are pending examination.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rao et al. (US20200073692A1) hereinafter Rao in view of Vairavakkalai et al. (US11070469B1) [Same assignee, different inventor] hereinafter Vairavakkalai.
As per claim 1, Rao discloses A computing device (see Fig.2, computing device - 200) comprising:
processing circuitry having access to memory (see Fig.2, computing device - 200, processing circuity - 210, storage device - 244, 246, processing circuitry has access to the storage device - bus 242), the processing circuitry and memory configured to execute:
a containerized network function (see Fig. 2, Pod 202A includes one or more containers 229A, par0080);
a virtual router to implement a data plane for a containerized router (see Fig. 2, see para. 0078, virtual router – 220, Virtual router 220 uses the VRF 222A corresponding to the virtual network for the inner packet to generate an outer header for the inner packet, the outer header including an outer IP header for the overlay tunnel and a tunnel encapsulation header identifying the virtual network. Virtual router 220 encapsulates the inner packet with the outer header. ‘Virtual router 220 may encapsulate the tunnel packet with a new layer 2 header having a destination layer 2 address associated with a device external to the computing device 200, e.g., a TOR switch 16 or one of servers 12); and
a containerized routing protocol daemon (see Fig.2, Container engine 208) to implement a control plane for the containerized router, wherein the containerized network function and containerized routing protocol daemon execute on the same computing device (see para. 0082, 0083, container engine 208 runs containerized applications {a containerized routing protocol daemon} in the form of containers 229A-229B. Container engine 208 represents a Dockert, rkt, or other container engine for managing containers. In general, container engine 208 receives requests and manages objects such as images, containers, networks, and volumes. An image is a template with instructions for creating a container. A container is an executable instance of an image. Based on directives from controller agent 209, container engine 208 may obtain images and instantiate them as executable containers 229A-229B in pods 202A-202B);
a first virtual network interface (see Fig.2, virtual network interfaces 212A) enabling communications between the containerized network function and the virtual router (see Fig. 2, par0057, 0085, orchestration agent 209 receives a container specification data for pod 202A and directs container engine 208 to create the pod 202A with containers 229A based on the container specification data for pod 202A. Orchestration agent 209 also invokes the single network module 206A to configure, for pod 202A, multiple virtual network interfaces 212A-212B for virtual networks corresponding to VRFs 222A-222B, respectively. In a similar manner, orchestration agent 209 directs container engine 208 to create the pod 202B with containers 229B based on the container specification data for pod 202B).
Rao does not explicitly disclose wherein the virtual router is configured with a static route to cause the virtual router to forward traffic destined for a prefix to the first virtual network interface to send the traffic to the containerized network function.
Vairavakkalai however discloses wherein a virtual router is configured with a static route to cause the virtual router to forward traffic destined for a prefix to the first virtual network interface to send the traffic to the containerized network function (see Fig.2, para. 51, container engine 284 observes routing protocol sessions between RPD modules 286 and border routers 111 and determine that RPD module 286A is handling a high level of routing information traffic relative to other RPD modules 286. In such an example, container engine 284 causes RPD module 286A to no longer peer with border router 111B. Container engine 284 further causes RPD module 286N to begin peering with border router 111B, thereby reducing the load on RPD module 286A, and thereby altering the balance of BGP peering traffic handled by each of RPD modules 286, see also para. 53, Each of RPD modules 286 may peer with other RPD modules 286 that are handling the same address family, container engine 284 may, to the extent possible, configure each of RPD modules 286 to peer with border routers 111 such that each of RPD modules 286 processes routing information or routes for a different address family or a different set of address families / to forward traffic destined for a prefix to the first virtual network interface to send the traffic to the containerized network function, see also para. 18. 39 IP v4 address {prefix} families).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein a virtual router is configured with a static route to cause the virtual router to forward traffic destined for a prefix to the first virtual network interface to send the traffic to the containerized network function, as taught by Vairavakkalai in the method of Rao, so routers may send update messages to advertise newly available routes or to inform that some routes are no longer available and this will benefit the computing infrastructure of Rao, see Vairavakkalai para. 6 and 7.
As per claim 2, Rao and Vairavakkalai disclose the computing device of claim 1.
Rao further disclose a second virtual network interface enabling communications between the containerized network function and the virtual router, the second virtual network interface different from the first virtual network interface (see para. 0085, Orchestration agent 209 also invokes the single network module 20613 to configure, for pod 202B, a virtual network interface 213 for a virtual network corresponding to VRF 222B),
wherein the containerized network function is configured to send traffic processed by the containerized network function to the virtual router via the second virtual network interface (see para. 0120-0123, the VRFs 222 of virtual routers 220 for the minion nodes may be configured to cause traffic forwarding along the sequence of services, such as by configuring service VRFs for the containerized network functions to use as left VRFs for the service, where for a two tier application with a frontend and a database backed, the frontend pod can be configured as a virtual network endpoint for virtual network A (corresponding to VRF 222A) and the database pod can be configured as a virtual network endpoint for virtual network B (corresponding to VRF 222B, send traffic processed by the containerized network function to the virtual router via the second virtual network interface, packets received at virtual network interface 212A from the frontend pod may be processed by the containerized firewall and output via virtual network interface 212B {the second virtual network interface} over virtual network B to the backend database pod).
As per claim 3, Rao and Vairavakkalai disclose the computing device of claim 1.
Rao does not explicitly disclose wherein the containerized routing protocol daemon is configured to advertise the prefix to attract traffic destined for the prefix to the computing device.
Vairavakkalai further disclose wherein the containerized routing protocol daemon is configured to advertise the prefix to attract traffic destined for the prefix to the computing device (see para. 3, a computer network using a routing protocol, such as BGP, for example, directs data packets between network nodes based on addressing information within the data packets. A route advertisement message, such as a BGP UPDATE message, advertises one or more routes for network prefixes reachable via the network, see also para. 54).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the containerized routing protocol daemon is configured to advertise the prefix to attract traffic destined for the prefix to the computing device, as taught by Vairavakkalai in the method of Rao, so routers may send update messages to advertise newly available routes or to inform that some routes are no longer available and this will benefit the computing infrastructure of Rao, see Vairavakkalai para. 6 and 7.
As per claim 4, Rao and Vairavakkalai disclose the computing device of claim 3.
Rao does not explicitly disclose wherein the containerized routing protocol daemon is configured to execute one or more routing protocols to exchange routing information with routers external to the computing device, and wherein the containerized routing protocol daemon is configured to advertise the prefix using the one or more routing protocols.
Vairavakkalai further disclose wherein the containerized routing protocol daemon is configured to execute one or more routing protocols to exchange routing information with routers external to the computing device, and wherein the containerized routing protocol daemon is configured to advertise the prefix using the one or more routing protocols (see para. 5, 8, implementing a routing protocol service system that can be effectively scaled to provide routing protocol services, such as Border Gateway Protocol route reflector or Border Gateway Protocol route server services. In some examples, the routing protocol service system is implemented using a containerization platform, with multiple containers each independently executing a routing protocol daemon (“RPD”), see also para. 12, 13, Network 150 may also be an autonomous system, implemented in a manner similar to any of autonomous systems 110. Routers 190 included within network 150 also implement a routing protocol to route packets from source network addresses to destination network addresses).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the containerized routing protocol daemon is configured to execute one or more routing protocols to exchange routing information with routers external to the computing device, and wherein the containerized routing protocol daemon is configured to advertise the prefix using the one or more routing protocols, as taught by Vairavakkalai in the method of Rao, so routers may send update messages to advertise newly available routes or to inform that some routes are no longer available and this will benefit the computing infrastructure of Rao, see Vairavakkalai para. 6 and 7.
As per claim 5, the combination of Rao and Vairavakkalai disclose the computing device of claim 1.
Rao does not explicitly disclose wherein the traffic destined for the prefix comprises first traffic destined for the prefix, further comprising: a physical interface; a second virtual network interface enabling communications between the containerized network function and the virtual router, the second virtual network interface different from the first virtual network interface, wherein the virtual router is configured to apply the static route based on the first traffic destined for the prefix being received on the physical interface, and wherein the virtual router is configured to, based on second traffic destined for the prefix being received on the second virtual network interface from the containerized network function, apply a different route to forward the second traffic to a downstream router.
Vairavakkalai further disclose wherein the traffic destined for the prefix comprises first traffic destined for the prefix, further comprising: a physical interface; a second virtual network interface enabling communications between the containerized network function and the virtual router, the second virtual network interface different from the first virtual network interface, wherein the virtual router is configured to apply the static route based on the first traffic destined for the prefix being received on the physical interface, and wherein the virtual router is configured to, based on second traffic destined for the prefix being received on the second virtual network interface from the containerized network function, apply a different route to forward the second traffic to a downstream router (see para. 39, NAT module 283 may perform functions relating to remapping one address space into another by modifying network address information in a header of a network data unit packet. In the context of an IP network, for example, network address translation remaps one IP address space into another by modifying the network address information int eh IP header of IP packets while they are in transit on a network. NAT module 283 may translate private addresses used by containers 285 into a common public address visible to devices on network 105. Devices on network 105 (e.g., border routers 111) may communicate with specific RPD modules 286 by using the common public address, and NAT module 283 translates the public address into the private address used by a specific one of containers 285 on network 150 through network translation. Although NAT module 283 may be described in connection with FIG. 2 as primarily performing address translation operations, NAT module 283 may alternatively, or in addition, perform other operations, including those that provide some level of security for containers executing on compute node 270 or devices within network 150).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the traffic destined for the prefix comprises first traffic destined for the prefix, further comprising: a physical interface; a second virtual network interface enabling communications between the containerized network function and the virtual router, the second virtual network interface different from the first virtual network interface, wherein the virtual router is configured to apply the static route based on the first traffic destined for the prefix being received on the physical interface, and wherein the virtual router is configured to, based on second traffic destined for the prefix being received on the second virtual network interface from the containerized network function, apply a different route to forward the second traffic to a downstream router, as taught by Vairavakkalai in the method of Rao, so routers may send update messages to advertise newly available routes or to inform that some routes are no longer available and this will benefit the computing infrastructure of Rao, see Vairavakkalai para. 6 and 7.
As per claim 6, Rao and Vairavakkalai disclose the computing device of claim 1.
Rao further disclose wherein the containerized network function is configured to implement a secure tunnel for the traffic destined for the prefix (see para. 0044, for server 12A, for each of the packets outbound from virtual network endpoints hosted by server 12A (e.g., pod 22A), the virtual router 21A attaches a tunnel encapsulation header indicating the virtual network for the packet to generate an encapsulated or “tunnel” packet, and virtual router 21A outputs the encapsulated packet via overlay tunnels for the virtual networks to a physical destination computing device, such as another one of servers 12. As used herein, a virtual router 21 may execute the operations of a tunnel endpoint to encapsulate inner packets sourced by virtual network endpoints to generate tunnel packets and decapsulate tunnel packets to obtain inner packets for routing to other virtual network endpoints).
As per claim 7, Rao and Vairavakkalai disclose the computing device of claim 1.
Rao further disclose wherein the containerized network function is configured to implement one of a broadband network gateway (BNG), Intrusion Detection and Prevention (IDP/IDS), Traffic Monitor, Network Address Translation device, or IPSec (see para. 0104, network controller 324 may provide network function virtualization (NFV) to networks, such as business edge networks, broadband subscriber management edge networks, and mobile edge networks. NFV involves orchestration and management of networking functions such as a Firewalls, Intrusion Detection or: Preventions Systems (IDS/IPS)).
As per claim 8, Rao and Vairavakkalai disclose the computing device of claim 1.
Rao further disclose wherein the processing circuitry and memory are configured to execute: a container network interface plugin configured to configure the first virtual network interface based on a network attachment definition obtained by an orchestrator for the containerized router (see para. 0116, 0117, the orchestration agent 209 invokes a single network plugin 206A to configure the virtual network interfaces for the pod 202A (410). Network plugin 206A requests (412) and obtains the interface configuration data 25 from virtual router agent 216 (414). Network plugin 206A may obtain the interface configuration data 25 from virtual router agent 216 by requesting the interface configuration data for the pod corresponding to the pod_uuid included in the container specification data for pod 202A).
As per claim 9, Rao and Vairavakkalai disclose the computing device of claim 8.
Rao further disclose a second virtual network interface enabling communications between the containerized network function and the virtual router, the second virtual network interface different from the first virtual network interface, wherein the containerized network function is configured to send traffic processed by the containerized network function to the virtual router via the second virtual network interface, wherein the network attachment definition comprises a first network attachment definition, and wherein the container network interface plugin is configured to configure the second virtual network interface based on a second network attachment definition obtained by the orchestrator (see para. 0116-0119, Network controller 324 may send the interface configuration data 25 to the virtual router agent 216 for virtual router 220 of computing device 200 and configure corresponding virtual network interfaces 212A, 212B in the computing device 200 (406). Virtual router agent 216 may store an association of each vni_uuid with the corresponding configured virtual network interface and to create each of the virtual network interfaces 212A, 212B indicated in interface configuration data 25 (416), network plugin 206A may insert the virtual network interface into the pod 202A network namespace (e.g., one end of a veth pair that is the virtual network interface) (418) and may make any necessary changes on the computing device 200 (e attaching the other end of the veth pair into virtual router 220).
As per claim 10, Rao and Vairavakkalai disclose the computing device of claim 8.
Rao further disclose wherein the container network interface plugin is configured to configure, based on container specification data obtained by the orchestrator, the containerized router with a route for the prefix, and wherein the containerized router is configured to advertise the route (see para. 0119, network plugin 206A notifies virtual router agent 216 of the now-operational (by virtue of insertion into pod 202A) virtual network interfaces 212A, 212B (420). Network plugin 206A may also obtain the virtual network addresses from the virtual router agent 216 (422) or by invoking an appropriate IPAM plugin. Network plugin 206A may configure the virtual network addresses inside the pod 202A network namespace and may setup routes by invoking the virtual router agent 216. Alternatively, network plugin 206A may configure the virtual network addresses inside the pod 202A network namespace and may setup routes consistent with the IP Address Management section by invoking an appropriate IPAM plugin. Network plugin 206A may update the orchestration control plane by notifying orchestration agent 209 (424)).
As per claim 11, Rao and Vairavakkalai disclose the computing device of claim 10.
Rao does not explicitly disclose wherein the container specification data indicates the route for the prefix with an advertise routes field.
Vairavakkalai further disclose wherein the container specification data indicates the route for the prefix with an advertise routes field (see para. 5, a route advertisement message, such as a BGP UPDATE message, advertises one or more routes {an advertise routes field} for network prefixes reachable via the network, see also para. 54).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the container specification data indicates the route for the prefix with an advertise routes field, as taught by Vairavakkalai in the method of Rao, so routers may send update messages to advertise newly available routes or to inform that some routes are no longer available and this will benefit the computing infrastructure of Rao, see Vairavakkalai para. 6 and 7.
As per claim 12, Rao discloses A computing system comprising: an orchestrator; (Fig. 1, Fig. 2, par0012-0013, one or more computing devices interconnected by a physical network, wherein each of the computing devices [computing system] comprises processing circuitry coupled to a memory device, wherein the controller further comprises: an orchestrator for a virtualized computing infrastructure….a method comprises sending, by an orchestrator [orchestrator] for a virtualized computing infrastructure to a network controller for the virtualized computing infrastructure).
a container network interface plugin, wherein the orchestrator is configured to: obtain a network attachment definition; and cause the container network interface plugin to configure the first virtual network interface based on the network attachment definition, (see para. 0116, 0117, the orchestration agent 209 invokes a single network plugin 206A to configure the virtual network interfaces for the pod 202A (410). Network plugin 206A requests (412) and obtains the interface configuration data 25 from virtual router agent 216 (414). Network plugin 206A may obtain the interface configuration data 25 from virtual router agent 216 by requesting the interface configuration data for the pod corresponding to the pod_uuid included in the container specification data for pod 202A).
Rao and Vairavakkalai disclose the additional elements of claim 12 as discussed per claim 1 above.
As per claim 13. Rao and Vairavakkalai teach all the elements as discussed per claims 9 above.
As per claim 14. Rao and Vairavakkalai teach all the elements as discussed per claims 10 above.
As per claim 15. Rao and Vairavakkalai teach all the elements as discussed per claims 11 above.
As per claim 16, A method (Fig. 1, Fig. 2, par0013) comprising: executing, with a computing device (see Fig.2, computing device - 200): a containerized network function;
a virtual router to implement a data plane for a containerized router (see Fig. 2, see para. 0078, virtual router – 220, Virtual router 220 uses the VRF 222A corresponding to the virtual network for the inner packet to generate an outer header for the inner packet, the outer header including an outer IP header for the overlay tunnel and a tunnel encapsulation header identifying the virtual network. Virtual router 220 encapsulates the inner packet with the outer header. ‘Virtual router 220 may encapsulate the tunnel packet with a new layer 2 header having a destination layer 2 address associated with a device external to the computing device 200, e.g., a TOR switch 16 or one of servers 12; and
a containerized routing protocol daemon (see Fig.2, Container engine 208) to implement a control plane for the containerized router, wherein the containerized network function and containerized routing protocol daemon execute on the same computing device, and (see para. 0082, 0083, container engine 208 runs containerized applications {a containerized routing protocol daemon} in the form of containers 229A-229B. Container engine 208 represents a Dockert, rkt, or other container engine for managing containers. In general, container engine 208 receives requests and manages objects such as images, containers, networks, and volumes. An image is a template with instructions for creating a container. A container is an executable instance of an image. Based on directives from controller agent 209, container engine 208 may obtain images and instantiate them as executable containers 229A-229B in pods 202A-202B);
wherein a first virtual network interface (see Fig.2, virtual network interfaces 212A) of the computing device enables communications between the containerized network function and the virtual router; and (see Fig. 2, par0057, 0085, orchestration agent 209 receives a container specification data for pod 202A and directs container engine 208 to create the pod 202A with containers 229A based on the container specification data for pod 202A. Orchestration agent 209 also invokes the single network module 206A to configure, for pod 202A, multiple virtual network interfaces 212A-212B for virtual networks corresponding to VRFs 222A-222B, respectively. In a similar manner, orchestration agent 209 directs container engine 208 to create the pod 202B with containers 229B based on the container specification data for pod 202B).
Rao does not explicitly disclose forwarding, by the virtual router, based on a static route, traffic destined for a prefix to the first virtual network interface to send the traffic to the containerized network function.
Vairavakkalai however discloses forwarding, by the virtual router, based on a static route, traffic destined for a prefix to the first virtual network interface to send the traffic to the containerized network function (see Fig.2, para. 51, container engine 284 observes routing protocol sessions between RPD modules 286 and border routers 111 and determine that RPD module 286A is handling a high level of routing information traffic relative to other RPD modules 286. In such an example, container engine 284 causes RPD module 286A to no longer peer with border router 111B. Container engine 284 further causes RPD module 286N to begin peering with border router 111B, thereby reducing the load on RPD module 286A, and thereby altering the balance of BGP peering traffic handled by each of RPD modules 286, see also para. 53, Each of RPD modules 286 may peer with other RPD modules 286 that are handling the same address family, container engine 284 may, to the extent possible, configure each of RPD modules 286 to peer with border routers 111 such that each of RPD modules 286 processes routing information or routes for a different address family or a different set of address families / to forward traffic destined for a prefix to the first virtual network interface to send the traffic to the containerized network function, see also para. 18. 39 IP v4 address {prefix} families).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of forwarding, by the virtual router, based on a static route, traffic destined for a prefix to the first virtual network interface to send the traffic to the containerized network function, as taught by Vairavakkalai in the method of Rao, so routers may send update messages to advertise newly available routes or to inform that some routes are no longer available and this will benefit the computing infrastructure of Rao, see Vairavakkalai para. 6 and 7.
As per claim 17. Rao and Vairavakkalai teach all the elements as discussed per claims 2 above.
As per claim 18. Rao and Vairavakkalai teach all the elements as discussed per claims 3 above.
As per claim 19. Rao and Vairavakkalai teach all the elements as discussed per claims 6 above.
As per claim 20. Rao and Vairavakkalai teach all the elements as discussed per claims 8 above.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent are -
• Sivaramakrishnan et al. (US9571394B1) – Related art in the area for enhancing operations of virtual networks.
• Nakil et al. (US20130332602A1) – Related art in the area of determining a physical network path taken by packets of a network packet flow.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONISHWAR MOHAN whose telephone number is (571)272-2907. The examiner can normally be reached Monday - Thursday 7:00 am - 5:00 pm.
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, William Trost can be reached on (571) 272-7872. 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.
/M.M./Examiner, Art Unit 2442
/WILLIAM G TROST IV/Supervisory Patent Examiner, Art Unit 2442
Prosecution Insights