DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/18/2025 has been entered.
Response to Arguments
Applicant's arguments filed 08/18/2025 have been fully considered.
Applicant argues that the prior art of record does not teach on the amendment “wherein the bridge configuration data are provided to a first host computer executing an overlay virtual machine, and the bridge configuration data are not provided to a second host computer executing only a physical network segment virtual machine” to the independent claims. In response to the argument, Examiner respectfully agrees. Although the argument is persuasive, a prior art was discovered in the recently submitted IDS to read on the independent claims: US 9,910,686 B2 (Chandrashekhar)
Please see updated rejection below:
Claim(s) 1-3, 8-11, 14, 18-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 9,910,686 B2 (Chandrashekhar).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 9,910,686 B2 (Chandrashekhar) in view of US 2016/0094366 A1 (Wang).
Claim(s) 5, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 9,910,686 B2 (Chandrashekhar) in view of US 2016/0094366 A1 (Wang) further in view of US 2019/0116132 A1 (Suzuki).
Claim(s) 6-7, 12-13, 16-17, 22-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 9,910,686 B2 (Chandrashekhar) in view of US 2021/0194731 A1 (Gao).
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-3, 8-11, 14, 18-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 9,910,686 B2 (Chandrashekhar).
Regarding Claim 1:
Chandrashekhar teaches A method for configuring a network to bridge data messages between a logical overlay network layer 2 (L2) segment and a physical L2 segment, (Abstract: A managed physical routing element (MPRE) for routing data packet between virtual machines in different overlay networks) the method comprising:
identifying each host computer in the network on which at least one of logical network endpoints connected to the logical overlay network L2 segment executes; (Fig 2, each host has logical endpoints and the host is connected to the overlay L2 network segment. Col 6 ln 23-37, a network segment is a portion of the network within which the network elements communicate with each other by link layer L2 protocols such as an IP subnet. In some embodiments, a network segment is an encapsulation overlay network such as VXLAN or VLAN.)
and for each identified host computer, configuring (Figs 36-38, Col 36-38) a forwarding element (ie. MPSE, MPRE, LIF) on the identified host computer (Fig 2, 3 host computers) to bridge (i) data messages sent from the logical network endpoints executing on the identified host computer to network endpoints connected to the physical L2 segment (Col 6 ln 35-47, L2 level traffic between VMs is handled by MPSEs (not shown) operating locally within each host machine. Thus, for example, network traffic from the VM 223 to the VM 224 would pass through a first MPSE operating in the host 231, which receives the data from one of its ports and sends the data through the physical network 205 to a second MPSE operating in the host machine 232, which would then send the data to the VM 224 through one of its ports.) by providing bridge configuration data from a network management system to the forwarding element (Col 7 ln 57-62, The controller agent 340 receives control plane messages from a controller or a cluster of controllers. These control plane message includes configuration data for configuring the various components of the virtualization software (such as the MPSE 320 and the MPRE 330) and/or the virtual machines.)
and (ii) data messages sent from network endpoints connected to the physical L2 segment, executing on the identified host computer and on other host computers in the network, to the logical network endpoints (ie. VMs) executing on the identified host computer; (Col 5 ln 32-38, where each host machine operates its own local instance of the LRE as a managed physical routing element (MPRE) for performing L3 packet forwarding for the VMs running on that host. MPRE allows L3 forwarding of packets between VMs running on the same host machine to be performed locally at the host machine without having to go through the physical network.)
wherein the bridge configuration data are provided to a first host computer executing an overlay virtual machine, (Col 14 ln 39-57, The MPRE 1000 also includes a configuration data storage 1045. The storage 1045 stores data for configuring the various modules inside the MPRE 1000. The configuration data in the storage 1045 specifies a number of logical interfaces, as well as parameters of each logical interface (such its IP address, associated network segments, active/inactivate status, LIF type, etc.). )
and the bridge configuration data are not provided to a second host computer executing only a physical network segment virtual machine. (Fig 21, there is no MPSE or MPRE on the host computer that only has a physical virtual machine and as such no configuration data is provided.)
Regarding Claim 14:
Chandrashekhar teaches A non-transitory machine-readable medium storing a program which when executed by at least one processing unit configures a network to bridge data messages between a logical overlay network layer 2 (L2) segment and a physical L2 segment (Abstract: A managed physical routing element (MPRE) for routing data packet between virtual machines in different overlay networks), the program comprising sets of instructions for:
identifying each host computer in the network on which at least one logical network endpoint connected to the logical overlay network L2 segment executes; (Fig 2, each host has logical endpoints and the host is connected to the overlay L2 network segment. Col 6 ln 23-37, a network segment is a portion of the network within which the network elements communicate with each other by link layer L2 protocols such as an IP subnet. In some embodiments, a network segment is an encapsulation overlay network such as VXLAN or VLAN.)
and for each identified host computer, configuring (Figs 36-38, Col 36-38) a forwarding element (ie. MPSE, MPRE, LIF) on the identified host computer (Fig 2, 3 host computers) to bridge (i) data messages sent from the logical network endpoint executing on the identified host computer to network endpoints connected to the physical L2 segment (Col 6 ln 35-47, L2 level traffic between VMs is handled by MPSEs (not shown) operating locally within each host machine. Thus, for example, network traffic from the VM 223 to the VM 224 would pass through a first MPSE operating in the host 231, which receives the data from one of its ports and sends the data through the physical network 205 to a second MPSE operating in the host machine 232, which would then send the data to the VM 224 through one of its ports.) by providing bridge configuration data from a network management system to the forwarding element (Col 7 ln 57-62, The controller agent 340 receives control plane messages from a controller or a cluster of controllers. These control plane message includes configuration data for configuring the various components of the virtualization software (such as the MPSE 320 and the MPRE 330) and/or the virtual machines.)
and (ii) data messages sent from network endpoints connected to the physical L2 segment, executing on the identified host computer and on other host computers in the network, to the logical network endpoints executing on the identified host computer; (Col 5 ln 32-38, where each host machine operates its own local instance of the LRE as a managed physical routing element (MPRE) for performing L3 packet forwarding for the VMs running on that host. MPRE allows L3 forwarding of packets between VMs running on the same host machine to be performed locally at the host machine without having to go through the physical network.)
wherein the bridge configuration data are provided to a first host computer executing an overlay virtual machine, and the bridge configuration data are not provided to a second host computer executing only a physical network segment virtual machine. (Fig 21, there is no MPSE or MPRE on the host computer that only has a physical virtual machine and as such no configuration data is provided.)
Regarding Claim 2:
Chandrashekhar teaches the invention of Claim 1 as described.
Chandrashekhar teaches wherein for a particular host computer, the forwarding element is a logical routing module (ie. MPSE, MPRE, LIF) executing on the host (Fig 3, host 300) that also implements one or more distributed logical routers to which the logical overlay network L2 segment connects. (Fig 3, Col 8 ln 9-19, The VTEP (VXLAN tunnel endpoint) 350 allows the host 300 to serve as a tunnel endpoint for logical network traffic (e.g., VXLAN traffic). VXLAN is an overlay network encapsulation protocol. An overlay network created by VXLAN encapsulation is sometimes referred to as a VXLAN network, or simply VXLAN.)
Regarding Claim 3:
Chandrashekhar teaches the invention of Claim 1 as described.
Chandrashekhar teaches wherein the physical L2 segment is a VLAN (virtual local area network) and the logical overlay network L2 segment is one of a VXLAN (virtual extensible local area network). (Fig 3, Col 8 ln 9-19, The VTEP (VXLAN tunnel endpoint) 350 allows the host 300 to serve as a tunnel endpoint for logical network traffic (e.g., VXLAN traffic). VXLAN is an overlay network encapsulation protocol. An overlay network created by VXLAN encapsulation is sometimes referred to as a VXLAN network, or simply VXLAN.)
Regarding Claims 8, 18:
Chandrashekhar teaches the inventions of claims 1, 14 as described.
Chandrashekhar teaches wherein each respective forwarding element executing on a respective host computer does not bridge (ie. directly sends) (i) any data messages sent from network endpoints connected to the physical L2 segment executing on the respective host computer to logical network endpoints executing on other host computers or (ii) any data messages sent from logical network endpoints executing on other host computers to network endpoints connected to the physical L2 segment. (Fig 17, Col 20 ln 36-62, Residing on the host machine 1701 is a VM 1731 in segment A, a MPRE 1711 that has a logical interface 1721 for segment A, and an uplink module 1741 for receiving data from the physical network. Residing on the host machine 1702 is a VM 1732 in segment B, a MPRE 1712 that has a logical interface 1722 for segment B, and an uplink module 1742 for receiving data from the physical network. The VM 1731 already knows that the L2 link layer address of its default gateway is "VMAC" (e.g. , from a previous ARP query) and therefore it sends the data packet directly to the MPRE 1711 by using VMAC, as the destination IP is in another segment. See Col 21-22 for different routing scenarios for Fig 17, no bridging necessary.)
Regarding Claims 9, 19:
Chandrashekhar teaches the inventions of claims 1, 14 as described.
Chandrashekhar teaches wherein a particular forwarding element executing on a particular host computer: receives a data message, directed to an L2 address of a network endpoint connected to the physical L2 segment, from a logical network endpoint executing on the host computer; (Col 14 ln 34-38, The look-up table storage 1040 stores bridging tables needed for binding network segment identifiers (VNIs) with MAC addresses. The routing processor 1005 also updates entries in the bridging table and the ARP table by learning from incoming packets.)
determines whether an L2 learning table stored by the particular forwarding element includes an entry for the L2 address specifying (i) the physical L2 segment to which the network endpoint is connected (Col 14 ln 24-38, The routing processor 1005 also makes its routing decisions based on the content of the look-up table storage 1040. The look-up table storage 1040 stores the resolution table ( or ARP table) for L3 to L2 address resolution (e.g., from network layer IP address to link layer MAC address). The look-up table storage 1040 stores bridging tables needed for binding network segment identifiers (VNIs) with MAC addresses. The routing processor 1005 also updates entries in the bridging table and the ARP table by learning from incoming packets.)
and (ii) whether the network endpoint executes on the particular host computer; (Fig 11, Col 15 ln 7-14, At 1123, the process learns the pairing between the source MAC and the incoming packet's network segment identifier (e.g., VNI). Since the source MAC is certain to be in a network segment identified by the VNI, this information is useful for bridging a packet that has the same MAC address as its destination address. This information is stored in a bridge table in some embodiments to provide pairing between this MAC address with its VNI.)
and when the L2 learning table include an entry for the L2 address specifying the physical L2 segment and whether the network endpoint executes on the particular host computer, bridges the data message to the physical L2 segment and directs the bridged data message to the network endpoint. (Fig 11, Col 15 ln 15-34, Next, the process determines (at 1125) whether the destination MAC in the incoming data packet is a MAC that needs bridging. At 1130, the process performs a bridging operation by binding the unknown destination MAC with a VNI according to the bridging table. After the performing bridging, the process proceeds to 1150. The process next identifies (1150) an outbound LIF for the incoming packet (or more appropriately at this point, the outgoing packet). After identifying the outbound LIF, the process sends (at 1160) the outgoing packet by using the outbound LIF to the correct destination segment.)
Regarding Claims 10, 20:
Chandrashekhar teaches the inventions of claims 9, 19 as described.
Chandrashekhar teaches wherein: the particular forwarding element is a logical routing module; (Col 2, ln 19-29, a logical routing element (LRE) includes one or more logical interfaces (LIFs) that each serves as an interface to a particular segment of the network. )
and when the L2 learning table entry specifies that the network endpoint executes on the particular host computer, (Col 14 ln 24-38, routing decisions based on the content of the look-up table storage 1040.) the logical routing module provides the bridged data message to a virtual switch executing on the particular host computer that delivers the bridged data message to the network endpoint. (Col 9-10 ln 55-62, 1-3 FIG. 5a illustrates a first L3 routing operation for a packet whose destination is in the same host as the MPRE 330. In an operation labeled '1 ', the VM 312 sends a data packet to the MPRE 330 by using the MPRE's MAC address. In an operation labeled '2', the MPRE 330 performs L3 routing operation on the received data packet by resolving its destination L3 level IP address into a L2 level destination MAC address. Since the destination MAC address is for a VM within the host machine 300 (i.e., the VM 311), the MPSE 320 in the operation '3' forwards the routed packet to the destination VM directly without the packet ever reaching the physical network 390.)
Regarding Claims 11, 21:
Chandrashekhar teaches the inventions of claims 9, 19 as described.
Chandrashekhar teaches wherein: the particular forwarding element is a logical routing module; (Col 2, ln 19-29, a logical routing element (LRE) includes one or more logical interfaces (LIFs) that each serves as an interface to a particular segment of the network.)
and when the L2 learning table entry specifies that the network endpoint executes outside the particular host computer, (Col 14 ln 24-38, routing decisions based on the content of the look-up table storage 1040.) the logical routing module provides the bridged data message to a virtual switch executing on the particular host computer that delivers the bridged data message to an uplink port of the particular host computer to be sent to a different host computer on which the network endpoint executes via a physical network. (FIG. 6b illustrates a routing operation for a packet sent from an outside entity to another outside entity ( e.g., a virtual machine in another host machine) in operations '4' through '6'. Operations '4' and '5' are analogous operations of ' l' and '2', during which the MPRE 330 receives a packet from the physical network and the MPSE 320 and performs a L3 routing operation on the received data packet. In operation '6', the MPRE 330 sends the data packet back to the MPSE 320, which sends the packet to another virtual machine in another host machine based on the resolved MAC address.)
Claim Rejections - 35 USC § 103
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 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.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 9,910,686 B2 (Chandrashekhar) in view of US 2016/0094366 A1 (Wang).
Regarding Claim 4:
Chandrashekhar teaches the invention of claim 1 as described.
Chandrashekhar teaches on bridging packets and learning routing information from received packets (Col 13-14). However, Chandrashekhar is silent that the forwarding elements executing on the host computers bridge the data messages during migration of the network endpoints from the physical L2 segment to the logical overlay network L2 segment
Wang teaches wherein the forwarding elements executing on the host computers bridge the data messages during migration of the network endpoints from the physical L2 segment to the logical overlay network L2 segment. ([0169] In some embodiments, A VDB controller synchronizes the MAC addresses learned on local bridge to default bridge. The controller also handles the movement of the MAC addresses to new host when supporting virtual machine migration such as vMotion®.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to modify Chandrashekhar per Wang to include that the forwarding elements executing on the host computers bridge the data messages during migration of the network endpoints from the physical L2 segment to the logical overlay network L2 segment. This would have been advantageous as discussed above, as it would allow the modified system to provide further details as to encapsulation/bridging of the network packets which would allow for easier and more accurate implementation.
Claim(s) 5, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 9,910,686 B2 (Chandrashekhar) in view of US 2016/0094366 A1 (Wang) further in view of US 2019/0116132 A1 (Suzuki).
Regarding Claim 5:
Chandrashekhar (as modified by Wang) teaches the invention of claim 4 as described.
Chandrashekhar teaches on utilizing ARP (Col 13-14). However, Chandrashekhar (as modified by Wang) is silent on wherein when a particular network endpoint migrates from the physical L2 segment to the logical overlay network L2 segment: the particular network endpoint sends a GARP (gratuitous address request protocol) message to the network to indicate that an L2 address of the particular network endpoint is now located at the particular host computer on which the particular network endpoint executes, is connected to the logical overlay network L2 segment, and has a particular layer 3 address that maps to the L2 address; the forwarding element executing on the particular host computer bridges a copy of the GARP message from the logical overlay L2 segment to the physical L2 segment and sends a copy of the GARP message onto the physical L2 segment for delivery to any network endpoints connected to the physical L2 segment that have not yet migrated to the logical overlay network L2 segment.
Suzuki teaches, in the same field of endeavor, A mirror packet control device includes a processor that detects a notification of a completion of movement of a first virtual machine from another device to the mirror packet control device, Abstract.
Suzuki also teaches wherein when a particular network endpoint migrates from the physical L2 segment to the logical overlay network L2 segment: the particular network endpoint sends a GARP (gratuitous address request protocol) message to the network to indicate that an L2 address of the particular network endpoint is now located at the particular host computer on which the particular network endpoint executes, is connected to the logical overlay network L2 segment, and has a particular layer 3 address that maps to the L2 address; ([0115] The first detection unit 802 detects a notification of the completion of the movement of the monitor VM 102 from the other device to the own device. The notification is, for example, a GARP (Gratuitous Address Resolution Protocol) packet. For example, the first detection unit 802 receives a GARP packet from a virtual infrastructure.)
the forwarding element executing on the particular host computer forwards a copy of the GARP message from the logical overlay L2 segment to the physical L2 segment and sends a copy of the GARP message onto the physical L2 segment for delivery to any network endpoints connected to the physical L2 segment that have not yet migrated to the logical overlay network L2 segment. ([0162] The live migration completion detection unit 925-I monitors a GARP packet and detects the completion of the live migration in response to detecting the GARP packet. The live migration completion detection unit 925-i sets an ID for identifying a port of a VM that detected the GARP packet as a monitor ID. The live migration completion detection unit 925-i searches the monitor management table 700-i with the monitor ID and acquires a mirror port ID corresponding to the monitor ID. The live migration completion detection unit 925-i designates the monitor ID and the mirror port ID for the relearning notification packet transmission unit 926-i which executes a relearning notification packet transmitting process which will be described later with reference to FIG. 18.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to modify Chandrashekhar (as modified by Wang) by modifying Chandrashekhar per Suzuki to include wherein when a particular network endpoint migrates from the physical L2 segment to the logical overlay network L2 segment: the particular network endpoint sends a GARP (gratuitous address request protocol) message to the network to indicate that an L2 address of the particular network endpoint is now located at the particular host computer on which the particular network endpoint executes, is connected to the logical overlay network L2 segment, and has a particular layer 3 address that maps to the L2 address; the forwarding element executing on the particular host computer bridges a copy of the GARP message from the logical overlay L2 segment to the physical L2 segment and sends a copy of the GARP message onto the physical L2 segment for delivery to any network endpoints connected to the physical L2 segment that have not yet migrated to the logical overlay network L2 segment. This would have been advantageous as discussed above, as it would allow the combined system to provide assurance of accurate transfer of data packets during migration.
Regarding Claim 15:
Chandrashekhar teaches the invention of claim 14 as described.
Chandrashekhar teaches on utilizing ARP (Col 13-14). However, Chandrashekhar is silent that the forwarding elements executing on the host computers bridge the data messages during migration of the network endpoints from the physical L2 segment to the logical overlay network L2 segment
Wang teaches that the forwarding elements executing on the host computers bridge the data messages during migration of the network endpoints from the physical L2 segment to the logical overlay network L2 segment. ([0169] In some embodiments, A VDB controller synchronizes the MAC addresses learned on local bridge to default bridge. The controller also handles the movement of the MAC addresses to new host when supporting virtual machine migration such as vMotion®.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to modify Chandrashekhar per Wang to include that the forwarding elements executing on the host computers bridge the data messages during migration of the network endpoints from the physical L2 segment to the logical overlay network L2 segment. This would have been advantageous as discussed above, as it would allow the modified system to provide further details as to encapsulation/bridging of the network packets which would allow for easier and more accurate implementation.
Chandrashekhar teaches on utilizing ARP (Col 13-14). However, Chandrashekhar (as modified by Wang) is silent on wherein when a particular network endpoint migrates from the physical L2 segment to the logical overlay network L2 segment: the particular network endpoint sends a GARP (gratuitous address request protocol) message to the network to indicate that an L2 address of the particular network endpoint is now located at the particular host computer on which the particular network endpoint executes, is connected to the logical overlay network L2 segment, and has a particular layer 3 address that maps to the L2 address; the forwarding element executing on the particular host computer bridges a copy of the GARP message from the logical overlay L2 segment to the physical L2 segment and sends a copy of the GARP message onto the physical L2 segment for delivery to any network endpoints connected to the physical L2 segment that have not yet migrated to the logical overlay network L2 segment.
Suzuki teaches wherein when a particular network endpoint migrates from the physical L2 segment to the logical overlay network L2 segment: the particular network endpoint sends a GARP (gratuitous address request protocol) message to the network to indicate that an L2 address of the particular network endpoint is now located at the particular host computer on which the particular network endpoint executes, is connected to the logical overlay network L2 segment, and has a particular layer 3 address that maps to the L2 address; ([0115) The first detection unit 802 detects a notification of the completion of the movement of the monitor VM 102 from the other device to the own device. The notification is, for example, a GARP (Gratuitous Address Resolution Protocol) packet. For example, the first detection unit 802 receives a GARP packet from a virtual infrastructure.)
the forwarding element executing on the particular host computer forwards a copy of the GARP message from the logical overlay L2 segment to the physical L2 segment and sends a copy of the GARP message onto the physical L2 segment for delivery to any network endpoints connected to the physical L2 segment that have not yet migrated to the logical overlay network L2 segment. ([0162) The live migration completion detection unit 925-I monitors a GARP packet and detects the completion of the live migration in response to detecting the GARP packet. The live migration completion detection unit 925-i sets an ID for identifying a port of a VM that detected the GARP packet as a monitor ID. The live migration completion detection unit 925-i searches the monitor management table 700-i with the monitor ID and acquires a mirror port ID corresponding to the monitor ID. The live migration completion detection unit 925-i designates the monitor ID and the mirror port ID for the relearning notification packet transmission unit 926-i which executes a relearning notification packet transmitting process which will be described later with reference to FIG. 18.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to modify Chandrashekhar (as modified by Wang) by modifying Chandrashekhar per Suzuki to include wherein when a particular network endpoint migrates from the physical L2 segment to the logical overlay network L2 segment: the particular network endpoint sends a GARP (gratuitous address request protocol) message to the network to indicate that an L2 address of the particular network endpoint is now located at the particular host computer on which the particular network endpoint executes, is connected to the logical overlay network L2 segment, and has a particular layer 3 address that maps to the L2 address; the forwarding element executing on the particular host computer bridges a copy of the GARP message from the logical overlay L2 segment to the physical L2 segment and sends a copy of the GARP message onto the physical L2 segment for delivery to any network endpoints connected to the physical L2 segment that have not yet migrated to the logical overlay network L2 segment. This would have been advantageous as discussed above, as it would allow the combined system to provide assurance of accurate transfer of data packets during migration.
Claim(s) 6-7, 12-13, 16-17, 22-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 9,910,686 B2 (Chandrashekhar) in view of US 2021/0194731 A1 (Gao).
Regarding Claims 6, 16:
Chandrashekhar teaches the inventions of claims 1, 14 as described.
Chandrashekhar teaches on gathering address information from received packets (Col 13). However, Chandrashekhar is silent that the headers of the packets indicate logical overlay network L2 segment information.
Gao teaches, in the same field of endeavor, a packet transmission method, Abstract.
Gao also teaches physical L2 segment information from headers of the data messages and appending to the data message headers indicating logical overlay network L2 segment information. ([0058] A VXLAN packet is a packet in which UDP encapsulation and VXLAN header encapsulation are added to an original Ethernet packet. FIG. 1 shows a specific packet format. The VXLAN packet includes two parts: an original packet and VXLAN encapsulation. The original packet includes an inner Ethernet header, an inner IP header, and a payload. The VXLAN encapsulation includes an outer Ethernet header, an outer IP header, an outer UDP header, and a VXLAN header.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to modify Chandrashekhar per Gao to include that the headers of the packets indicate logical overlay network L2 segment information. This would have been advantageous as discussed above, as it would allow the combined system to provide further details as to encapsulation/bridging of the network packets which would allow for easier and more accurate implementation.
Regarding Claims 7, 17:
Chandrashekhar teaches the inventions of claims 1, 14 as described.
Chandrashekhar teaches on gathering address information from received packets (Col 13). However, Chandrashekhar is silent that the headers of the packets indicate logical overlay network L2 segment information.
Gao teaches physical L2 segment information from headers of the data messages and appending to the data message headers indicating logical overlay network L2 segment information. ([0058) A VXLAN packet is a packet in which UDP encapsulation and VXLAN header encapsulation are added to an original Ethernet packet. FIG. 1 shows a specific packet format. The VXLAN packet includes two parts: an original packet and VXLAN encapsulation. The original packet includes an inner Ethernet header, an inner IP header, and a payload. The VXLAN encapsulation includes an outer Ethernet header, an outer IP header, an outer UDP header, and a VXLAN header.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to modify Chandrashekhar per Gao to include that the headers of the packets indicate logical overlay network L2 segment information. This would have been advantageous as discussed above, as it would allow the modified system to provide further details as to encapsulation/bridging of the network packets which would allow for easier and more accurate implementation.
Regarding Claims 12, 22:
Chandrashekhar teaches the inventions of claims 1, 14 as described.
Chandrashekhar teaches on gathering address information from received packets (Col 13). However, Chandrashekhar is silent that the headers of the packets indicate logical overlay network L2 segment information.
Gao teaches physical L2 segment information from headers of the data messages and appending to the data message headers indicating logical overlay network L2 segment information. ([0058] A VXLAN packet is a packet in which UDP encapsulation and VXLAN header encapsulation are added to an original Ethernet packet. FIG. 1 shows a specific packet format. The VXLAN packet includes two parts: an original packet and VXLAN encapsulation. The original packet includes an inner Ethernet header, an inner IP header, and a payload. The VXLAN encapsulation includes an outer Ethernet header, an outer IP header, an outer UDP header, and a VXLAN header.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date to modify Chandrashekhar per Gao to include that the headers of the packets indicate logical overlay network L2 segment information. This would have been advantageous as discussed above, as it would allow the combined system to provide further details as to encapsulation/bridging of the network packets which would allow for easier and more accurate implementation.
Regarding Claims 13, 23:
Chandrashekhar (as modified by Gao) teaches the inventions of claims 12, 22 as described.
Chandrashekhar teaches wherein the particular forwarding element is a logical routing module, Col 2, ln 19-29, a logical routing element (LRE) includes one or more logical interfaces (LIFs) that each serves as an interface to a particular segment of the network.) wherein a virtual switch executing on the particular host computer: receives the data message from an uplink port that connects to a physical network; (Col 9-10 ln 55-62, 1-3 FIG. 5a In an operation labeled '2', the MPRE 330 performs L3 routing operation on the received data packet by resolving its destination L3 level IP address into a L2 level destination MAC address. Since the destination MAC address is for a VM within the host machine 300 (i.e., the VM 311), the MPSE 320 in the operation '3' forwards the routed packet to the destination VM directly without the packet ever reaching the physical network 390.)
uses a first L2 learning entry for data messages having physical L2 segment information and directed to the L2 address of the logical network endpoint to provide the data message to the logical routing module; (Fig 11, Col 15 ln 7-14, At 1123, the process learns the pairing between the source MAC and the incoming packet's network segment identifier (e.g., VNI). Since the source MAC is certain to be in a network segment identified by the VNI, this information is useful for bridging a packet that has the same MAC address as its destination address. This information is stored in a bridge table in some embodiments to provide pairing between this MAC address with its VNI.)
receives the bridged data message from the logical routing module; and uses a second L2 learning entry for data messages having logical overlay network L2 segment information and directed to the L2 address of the logical network endpoint to provide the data message to the logical network endpoint. (Col 9-10 ln 55-62, 1-3 FIG. 5a illustrates a first L3 routing operation for a packet whose destination is in the same host as the MPRE 330. In an operation labeled '1 ', the VM 312 sends a data packet to the MPRE 330 by using the MPRE's MAC address. In an operation labeled '2', the MPRE 330 performs L3 routing operation on the received data packet by resolving its destination L3 level IP address into a L2 level destination MAC address. Since the destination MAC address is for a VM within the host machine 300 (i.e., the VM 311), the MPSE 320 in the operation '3' forwards the routed packet to the destination VM directly without the packet ever reaching the physical network 390.)
Conclusion & Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RACHEL J HACKENBERG whose telephone number is (571)272-5417. The examiner can normally be reached 9am-5pm M-F.
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, Glenton B Burgess can be reached on (571)272-3949. 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.
/RACHEL J HACKENBERG/Primary Examiner, Art Unit 2454