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 .
Response to Arguments
The rejection of claims 21-37 under 35 U.S.C. § 112(b) has been withdrawn in view of the claim amendment.
Applicant's arguments filed November 3 2025 have been fully considered but they are not persuasive. In regards to the applicants arguments regarding amended claim 21 and similarly amended claims 32 and 28, the examiner respectfully disagrees. More specifically the applicant argues the amended claim features in the claims including the detail in the network device in connection with being alerted to perform rewriting of the source MAC frame in response to destination MAC address in the MAC frame being associated with a VARP VTEP (i.e., Pg. 9 of the remarks). However the examiner respectfully disagrees with applicants arguments as the teachings of Zhang US (2015/0009992) which was used in the rejection of claims 21, 32, and 38 under 35 U.S.C. § 103, discloses the amended claim features in claims 21, 32, and 38.
For example, Zhang discloses the claim features of wherein the first network device (see Fig. 1 i.e., VXLAN gateway 108 & Fig. 2): is alerted that the source MAC frame requires rewriting to route the source MAC frame to the second VxLAN (see Fig. 8 i.e., step 806 such as receiving a VXLAN encapsulated packet alerts the VXLAN gateway 108 to rewrite the source MAC frame & Para’s [0044-0046] i.e., method 800 may be implemented by a VXLAN gateway…At bock 806, method 800 may receive the VXLAN encapsulated packet from a source VTEP. The VXLAN encapsulated data packet may have originated from a source endpoint and may be destined for a destination endpoint located in a different VXLAN network than the VXLAN network associated with the source endpoint… Method 800 then moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint within the un-encapsulated data packet (i.e., “rewritten source MAC frame”))
in response to the first destination MAC address (see Fig. 4 i.e., default GW MAC 408) in the source MAC frame (see Fig. 4) being associated with the VARP VTEP, (see Para’s [0024] i.e., VXLAN gateway acting as a VTEP, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address, [0033-0035], [0038] i.e., the default gateway MAC address 408 may be inserted as the MAC address for the destination endpoint, & [0045])
maintains, on a per-layer VXLAN basis (see Para’s [0023] i.e., VXLAN network identifier (VNI), [0032-0033] i.e., VNI associated with different XVLAN networks & [0044-0045] i.e., different VXLAN networks), a plurality of VARP VTEP IP addresses, (see Fig. 2 i.e., forwarding entry table 206 & Para’s [0028] i.e., Fig. 2 is a network node 200 such as a VTEP 106 and VXLAN gateway 108 in Fig. 1, [0030] i.e., The forwarding entry table 206 may associate VTEP addresses (i.e., “plurality of VARP VTEP IP addresses”) to endpoint addresses…the forwarding entry table may associate both the IP addresses and the MAC addresses of VTEPs (i.e., “plurality of VARP VTEP IP addresses”) to the IP addresses and MAC address of endpoints)
wherein the second destination IP address is one of the plurality of VARP VTEP IP addresses, (see Para’s [0027] i.e., VXLAN gateway 108 may be configured as a VTEP [0030] i.e., the forwarding entry table may associate both the IP addresses and the MAC addresses of VTEPs (i.e., second destination IP address of VXLAN gateway may be included in the IP addresses of VTEPs in the forwarding entry table as forwarding information since the VXLAN gateway is also a VTEP which routes packets between the VTEPs and endpoints in different VXLAN networks) to the IP addresses and MAC address of endpoints, [0032], [0036-0037], & [0044-0045] )
and wherein the second destination IP address (see Fig. 5 i.e., 514) is associated with the first destination MAC address (see Fig. 4 i.e., 408) in the source MAC frame (see Fig. 5 i.e., VXLAN GW IP is associated with the default GW MAC address 408 & Para’s, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address, [0030] i.e., IP addresses and MAC addresses of VTEPs, [0034], [0038] i.e., default gateway MAC address, & [0040] i.e., The VXLAN gateway IP address 514 and VXLAN gateway MAC address 520 may indicate the IP address and MAC address of the destination VTEP). The amended claim features in independent claims 32 and 38 which recite similar features to the amended claim features in claim 21, are also disclosed in Zhang for the same reasons as explained for independent claim 21.
For the reasons explained claim 21 remains rejected under 35 U.S.C. § 103, over the combination of Zhang (Of Record) in view of Enoki (Of Record), and further in view of Zhang (Of Record).
Claim 32 remains rejected under 35 U.S.C. § 103, over the combination of Zhang (Of Record) in view of Chu (Of Record), further in view of Enoki (Of Record), and further in view of Zhang (Of Record).
Claim 38 remains rejected under 35 U.S.C. § 103, over the combination of Zhang (Of Record) in view of Enoki (Of Record).
The dependent claims remain rejected over the prior art (Of Record) based at least on their dependence to independent claims 21, 32, and 38.
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 21-27 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang US (2015/0009992) in view of Enoki et al. US (2008/0170494), and further in view of Zhang US (2014/0146817).
Regarding Claim 21, Zhang discloses a system for routing a first packet (see Fig. 1) comprising: a first network device, (see Fig. 1 i.e., VXLAN gateway 108 & Para [0024])
wherein the first network device (see Fig. 1, 108) is configured to receive a first encapsulated packet (see Fig. 5 & Para’s [0039] i.e., VXLAN encapsulated data packet 304 is transmitted from VTEP A 106 to VXLAN gateway 108 & [0045]) and rewrite a source media access control (MAC) frame to create a rewritten source MAC frame, (see Fig. 8 i.e., step 812 & Para’s [0033] i.e., endpoint A 104 may transmit a data packet 302 destined for endpoint D 104. Data packet 302 may be a MAC frame (i.e., “source MAC frame”), [0044] i.e., method 800 of Fig. 8 may be implemented by the VXLAN gateway & [0045] i.e., After receiving the VXLAN encapsulated data packet, method 800 may proceed to block 808 and remove the VXLAN header from the received VXLAN encapsulated data packet. Method 800 may determine the MAC address for the destination endpoint by initiating an ARP request or obtaining the MAC address from an ARP cache and/or forwarding entry table. Method 800 then moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint within the un-encapsulated data packet (i.e., “rewritten source MAC frame”))
wherein said first encapsulated packet (see Fig. 5) is an encapsulation of a first packet (see Fig. 4 i.e., data packet 302) comprising the source MAC frame, (see Para’s [0033], [0038] i.e., Data packet 302 is the data packet transmitted from endpoint A 104 to VTEP 106. Data packet 302 may comprise payload 402, ether type 404, endpoint A MAC address 406 and default gateway MAC address 408 & [0039] i.e., Fig. 5 is a schematic diagram of an example embodiment of a VXLAN encapsulated data packet 304 which may comprise a VXLAN header 522 and an encapsulated data packet 523. The encapsulated data packet 523 may be substantially similar to data packet 302 shown in Fig. 4. The header of the encapsulated data packet 523 may be the inner header, while the VXLAN header 522 may be the outer header)
wherein said source MAC frame comprises: a payload, a first source MAC address, a first destination MAC address, a first source Internet Protocol (IP) address, and a first destination IP address, (see Fig. 4 & Para’s [0033] & [0038] i.e., Data packet 302 may comprise payload 402, ether type 404, endpoint A MAC address 406 and default gateway MAC address 408. Payload 402 may comprise the IP address for the source endpoint (e.g., endpoint A) and the destination endpoint (e.g. endpoint D), and the data for data packet 302)
said first source MAC address is associated with a first virtual extensible local area network, (see Fig. 4, 406 & Para’s [0022-0023], [0027], [0032] i.e., endpoint A is associated with VXLAN network 102a & [0038] i.e., Endpoint A MAC address 406 may indicate the MAC address of the source endpoint), and said first destination MAC address is associated with a virtual address resolution protocol (VARP) virtual tunnel end point (VTEP), (see Para’s [0024] i.e., VXLAN gateway acting as a VTEP, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address, [0035], & [0038] i.e., the default gateway MAC address 408 may be inserted as the MAC address for the destination endpoint)
wherein said rewritten source MAC frame replaces the first destination MAC address with a MAC address associated with a second VXLAN distinct from the first VXLAN, (see Para’s [0022], [0027] i.e., destination endpoint D 104 is associated with VXLAN network 102b (i.e., “second VXLAN”), [0032-0033] i.e., destination endpoint D 104 is located in another VXLAN network, [0035] i.e., the VXLAN gateway 108 may modify the contents of data packet 302 by replacing the default gateway MAC address with the MAC address of endpoint D 104, [0042], & [0045] i.e., After receiving the VXLAN encapsulated data packet, method 800 may proceed to block 808 and remove the VXLAN header from the received VXLAN encapsulated data packet. Method 800 may determine the MAC address for the destination endpoint by initiating an ARP request or obtaining the MAC address from an ARP cache and/or forwarding entry table. Method 800 then moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint (i.e., MAC address of endpoint D 104 is associated with second VXLAN network 102b) with the un-encapsulated data packet (i.e., “rewritten source MAC frame”))
wherein a first server (see Fig. 1 i.e., VTEP A 106) is associated with the first VXLAN (see Fig. 1 i.e., VTEP A 106 is associated with first VXLAN 102a & Para’s [0022-0023] i.e., VTEP 106 may include, but are not limited to network switches, servers, and/or access node…In one example embodiment, when endpoints 104 are VMs, the VTEP 106 may be located within the hypervisor of the server that houses endpoints 104)
wherein the first server is configured to receive the first packet (see Fig. 4 & Para’s [0033-0034] i.e., data packet 302 may be a MAC frame that may be transmitted to VTEP A 106 (i.e., “server”), & [0038] i.e., Fig. 4 is a schematic diagram of an example embodiment of data packet 302 that is transmitted from a source endpoint to a source VTEP (i.e., server)) and encapsulate the first packet in a first VXLAN frame to create the first encapsulated packet, (see Para’s [0033-0035] i.e., VTEP A 106 may obtain the MAC address and IP address of the VXLAN gateway 108 and encapsulate a VXLAN header that references the MAC address and IP address of VXLAN gateway 108. The VLAN header may be added in front of the data packet 302, [0039], & [0044-0045] i.e., method 800 performed by VXLAN gateway receives the VXLAN encapsulated data packet from a source VTEP at block 806)
wherein said first source IP address is associated with the first VXLAN and said first destination IP address is associated with the second VXLAN, (see Fig. 4 & Para’s [0022-0023], [0032-0032] i.e., source endpoint A 104 may participate in VXLAN network102a and endpoint D 104 may participate in another VXLAN network 102b & [0038] i.e., Data packet 302 may comprise payload 402, ether type 404, endpoint A MAC address 406 and default gateway MAC address 408. Payload 402 may comprise the IP address for the source endpoint (e.g., endpoint A) and the destination endpoint (e.g. endpoint D), and the data for data packet 302)
wherein said first VXLAN frame comprises a second destination IP address, (see Fig. 5 & Para [0034] i.e., VTEP A 106 may obtain the MAC address and IP address of the VXLAN gateway 108 and encapsulate a VXLAN header that references the MAC address and IP address (i.e., “second destination IP address”) of VXLAN gateway 108. The VLAN header may be added in front of the data packet 302 & [0039-0040] i.e., the VXLAN header 522 may comprise the VXLAN gateway IP address 514)
wherein the second destination IP address is a VARP VTEP IP address, (see Fig. 5 & Para’s [0024] i.e., VXLAN gateway acting as a VTEP, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP, [0034-0035] i.e., VTEP A 106 may obtain the MAC address and IP address of the VXLAN gateway 108 and encapsulate a VXLAN header that references the MAC address and IP address (i.e., “VARP VTEP IP address”) of VXLAN gateway 108. The VLAN header may be added in front of the data packet 302, [0039-0040] i.e., the VXLAN header 522 may comprise the VXLAN gateway IP address 514)
wherein the first network device (see Fig. 1 i.e., VXLAN gateway 108 & Fig. 2): is alerted that the source MAC frame requires rewriting to route the source MAC frame to the second VxLAN (see Fig. 8 i.e., step 806 such as receiving a VXLAN encapsulated packet alerts the VXLAN gateway 108 to rewrite the source MAC frame & Para’s [0044-0046] i.e., method 800 may be implemented by a VXLAN gateway…At bock 806, method 800 may receive the VXLAN encapsulated packet from a source VTEP. The VXLAN encapsulated data packet may have originated from a source endpoint and may be destined for a destination endpoint located in a different VXLAN network than the VXLAN network associated with the source endpoint… Method 800 then moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint within the un-encapsulated data packet (i.e., “rewritten source MAC frame”))
in response to the first destination MAC address (see Fig. 4 i.e., default GW MAC 408) in the source MAC frame (see Fig. 4) being associated with the VARP VTEP, (see Para’s [0024] i.e., VXLAN gateway acting as a VTEP, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address, [0033-0035], [0038] i.e., the default gateway MAC address 408 may be inserted as the MAC address for the destination endpoint, & [0045])
maintains, on a per-layer VXLAN basis (see Para’s [0023] i.e., VXLAN network identifier (VNI), [0032-0033] i.e., VNI associated with different XVLAN networks & [0044-0045] i.e., different VXLAN networks), a plurality of VARP VTEP IP addresses, (see Fig. 2 i.e., forwarding entry table 206 & Para’s [0028] i.e., Fig. 2 is a network node 200 such as a VTEP 106 and VXLAN gateway 108 in Fig. 1, [0030] i.e., The forwarding entry table 206 may associate VTEP addresses (i.e., “plurality of VARP VTEP IP addresses”) to endpoint addresses…the forwarding entry table may associate both the IP addresses and the MAC addresses of VTEPs (i.e., “plurality of VARP VTEP IP addresses”) to the IP addresses and MAC address of endpoints)
wherein the second destination IP address is one of the plurality of VARP VTEP IP addresses, (see Para’s [0027] i.e., VXLAN gateway 108 may be configured as a VTEP [0030] i.e., the forwarding entry table may associate both the IP addresses and the MAC addresses of VTEPs (i.e., second destination IP address of VXLAN gateway may be included in the IP addresses of VTEPs in the forwarding entry table as forwarding information since the VXLAN gateway is also a VTEP which routes packets between the VTEPs and endpoints in different VXLAN networks) to the IP addresses and MAC address of endpoints, [0032], [0036-0037], & [0044-0045] )
and wherein the second destination IP address (see Fig. 5 i.e., 514) is associated with the first destination MAC address (see Fig. 4 i.e., 408) in the source MAC frame (see Fig. 5 i.e., VXLAN GW IP is associated with the default GW MAC address 408 & Para’s, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address, [0030] i.e., IP addresses and MAC addresses of VTEPs, [0034], [0038] i.e., default gateway MAC address, & [0040] i.e., The VXLAN gateway IP address 514 and VXLAN gateway MAC address 520 may indicate the IP address and MAC address of the destination VTEP)
and wherein the first server (see Fig. 1 i.e., VTEP A 106) and the first network device (see Fig. 1 i.e., VXLAN gateway 108) are configured to communicate with a second server (see Fig. 1 i.e., VTEP B 106) associated the second VXLAN, (see Fig. 1 i.e., VTEP B 106 (i.e., second server) is associated with second VXLAN network 102b & Para’s [0021-0024] & [0032-0037])
While Zhang discloses the rewritten source frame comprises a first source MAC address (see Figures 4-5 i.e., 406 & Para’s [0038-0039] & [0045]) Zhang does not disclose the claim feature of wherein said rewritten source MAC frame replaces the first source MAC address with a MAC address associated with the VARP VTEP. However the claim feature would be rendered obvious in view of Enoki et al. US (2008/0170494).
Enoki discloses wherein a rewritten source MAC frame performed by a router replaces a first source MAC address with a MAC address associated with the router itself that received the packet (see Para [0027] i.e., A router used in the embodiment is an apparatus which relays data flowing on a network to another network…When the router receives a broadcast packet generated from an arbitrary host (apparatus), an IP address and a MAC address of the source are associated with each other to form an ARP table. When the data is relayed as described above, the router, with reference to the ARP table, rewrites a MAC address of a destination of the received data with that of the next router or the host and also rewrites a MAC address of the source with a MAC address of the router itself to relay the data).
(Enoki suggests the router rewrites a MAC address of the source with a MAC address of the router itself in order to relay the data to the next router for ensuring the data packet is routed properly the next router and for the next router to identify the source of the packet (see Para [0027]))
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first network device such as the VXLAN gateway which is a VTEP which rewrites the source MAC frame as disclosed in Zhang to replace the source MAC frame address with a MAC address associated with the VARP VTEP such as the VXLAN gateway, based on the teachings of Enoki discloses wherein a rewritten source MAC frame performed by a router replaces a first source MAC address with a MAC address associated with the router itself that received the packet, because the motivation lies in Enoki that the router rewrites a MAC address of the source with a MAC address of the router itself in order to relay the data to the next router for ensuring the data packet is routed properly to the next router and for the next router to identify the source of the packet.
The combination of Zhang in view of Enoki does not disclose wherein the first server is associated with the first VXLAN and the second VXLAN, and the second server associated with the first VXLAN and the second VXLAN. However the claim feature would be rendered obvious in view of Zhang US (2014/0146817).
Zhang wherein the first server is associated with the first VXLAN and the second VXLAN (see Fig. 1 i.e., first Server 150 (i.e., includes VTEP 1 152) on top left including one or more VMs 154 associated with a first VXLAN i.e., vX1 and second VXLAN vX2), and the second server associated with the first VXLAN and the second VXLAN (see Fig. 1 i.e., server 150 (i.e., includes VTEP 7 152) on the bottom right including one or more VMs 154 associated with a first VXLAN i.e., vX1 and second VXLAN vX2), (see Fig. 1 & Fig. 2 i.e., VMs 254 may be allocated to different VXLAN domains & Para [0016] i.e., A server 150 may comprise one or more VMs 154…In this example, the VMs 154 belong to three different VXLAN domains. The three different groups of VMs 154 have different shade patterns in Fig. 1 & [0019-0020] i.e., The server 250 comprises an improved or modified VTEP 252 and one or more VMs 254 coupled to the modified VTEP 252. The VMs 254 may be allocated to one or more VXLAN domains).
(Zhang suggests the server includes one or more VMs which are each associated with different VXLAN domains for forwarding traffic or packets of the VMs between different VXLAN domains for supporting and enabling VXLAN inter-domain communications, (see Para’s [0018-0020])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first server including one or more VMs associated with the first VXLAN 102a and the second server including one or more VMs associated with the second VXLAN 102b for communicating between the different VXLANs as disclosed in Zhang in view of Enoki to each be associated with the first VXLAN and the second VXLAN based on the teachings of Zhang who discloses a first server and a second server each including one or more VMs which are each associated with a first VXLAN and a second VXLAN, because the motivation lies in Zhang suggests the server includes one or more VMs which are each associated with different VXLAN domains for forwarding traffic or packets of the VMs between different VXLAN domains for supporting and enabling VXLAN inter-domain communications.
Regarding Claim 22, the combination of Zhang in view of Enoki, and further in view of Zhang discloses the system of claim 21, wherein the first network device is a Top of Rack (ToR) switch, (Zhang (‘992), see Fig. 1 i.e., VXLAN gateway 108 & Para’s [0023] i.e., access nodes may be (e.g., ToR switches & [0024] i.e., The VXLAN gateway 108 may be any network node, such as an access node (i.e., access node may be a “TOR switch”))
Regarding Claim 23, the combination of Zhang in view of Enoki, and further in view of Zhang discloses the system of claim 21, wherein the first network device is further configured to decapsulate the first encapsulated packet to reveal the first packet before rewriting the source MAC frame, (Zhang (‘992), see Fig. 8 & Para’s [0045] i.e., After receiving the VXLAN encapsulated data packet, method 800 may proceed to block 808 and remove the VXLAN header from the received VXLAN encapsulated data packet…Method 800 then moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint within the un-encapsulated data packet).
Regarding Claim 24, the combination of Zhang in view of Enoki, and further in view of Zhang discloses the system of claim 21, wherein the first network device is further configured to re-encapsulate the rewritten source MAC frame in a second VXLAN frame to create a re-encapsulated packet, (Zhang (‘992), see Fig. 6 & Fig. 8 i.e., step 816 & Para’s [0037], [0041] & [0045-0046] i.e., Method 800 then moves to block 816 and encapsulates the packet with a new VXLAN header (i.e., create a re-encapsulated packet)).
Regarding Claim 25, the combination of Zhang in view of Enoki, and further in view of Zhang discloses the system of claim 24, wherein the second VXLAN frame allows the re- encapsulated packet to be routed to the second server on the second VXLAN. (Zhang (‘992), see Fig. 1 i.e., second server VTEP B 106 & Fig. 8 i.e., step 818 & Para’s [0021-0024], [0032-0033] i.e., data packet 302 destined for endpoint D 104 located in another VXLAN network, [0037] i.e., Once VTEP B 106 receives the VXLAN encapsulated data packet 306, & [0045-0046] i.e., Method 800 then moves to block 816 and encapsulates the packet with a new VXLAN header (i.e., re-encapsulated packet)).
Regarding Claim 26, the combination of Zhang in view of Enoki, and further in view of Zhang discloses the system of claim 21, wherein the first network device is configured to route the first packet using a direct overlay, (Zhang (‘992), see Para [0006], [0021-0024] i.e., Endpoints 104 may be unaware of VXLAN networks 102a and 102b, and may transmit data packets directly to a VTEP 106…The VXLAN gateway 108 may be directly connected to VTEP A 106 and/or VTEP B 106 & [0044-0046])
Regarding Claim 27, the combination of Zhang in view of Enoki, and further in view of Zhang discloses the system of claim 21, wherein the first server comprises a first routing table portion for an underlay network (Zhang, see Para’s [0025] i.e., the forwarding entry tables may associated the IP addresses of the endpoints to the IP addresses of the VTEPs (i.e., “first routing table portion”). Other example embodiments of the forwarding entry tables may also associate the MAC addresses of the endpoints 104 to the MAC addresses of the VTEPs 106, [0030] i.e., the forwarding table entry table 206 may associate the IP addresses of VTEPs to the IP addresses of endpoints, [0044], & [0046]) and a second routing table portion for an overlay network (Zhang, see Para’s [0025] i.e., Other example embodiments of the forwarding entry tables may also associate the MAC addresses of the endpoints 104 to the MAC addresses of the VTEPs 106 (i.e., “second routing table portion”), [0030], & [0044]), and wherein the second routing table portion comprises information relating an IP address to a layer-2 domain, (Zhang, see Para’s [0025] i.e., the forwarding entry tables may associated the IP addresses of the endpoints to the IP addresses of the VTEPs (i.e., “first routing table portion”). Other example embodiments of the forwarding entry tables may also associate the MAC addresses of the endpoints 104 to the MAC addresses of the VTEPs 106 (i.e., “second routing table portion”), [0030] i.e., the forwarding table entry table 206 may associated both the IP addresses and MAC addresses of VTEPs to the IP addresses and MAC address of the endpoints, [0044] i.e., forwarding entry table that associates the endpoints with VTEPs within the joined VXLAN networks, & [0046])
Claims 28-31 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang US (2015/0009992) in view of Enoki et al. US (2008/0170494), and further in view of Zhang US (2014/0146817) as applied to claim 21 above, and further in view of Nakil et al. US (2015/0244617).
Regarding Claim 28, the combination of Zhang in view of Enoki, and further in view of Zhang discloses the system of claim 21, but does not disclose the system further comprising a spine tier comprising at least one spine switch. However the claim feature would be rendered obvious in view of Nakil et al. US (2015/0244617).
Nakil discloses a spine tier comprising at least one spine switch coupled to ToR switches 16 for routing traffic between a first server and a second server (Fig. 1-2A i.e., chassis switches 18A-18M (i.e., “spine tier” comprising at least one spine switch 18) which participate in routing traffic flows between server 12A to a destination server 12B or 12X & Para’s [0053-0054] i.e., TOR switches 16 (i.e., first and second network devices) and chassis switches 18 provide servers with redundant (multi-homed) connectivity to IP fabric 20 and service provider network 7. Chassis switches 18 aggregate traffic flows and provides high-speed connectivity between TOR switches 16, [0059], [0096] & [0132-0139]).
(Nakil suggests that the chassis switches 18 aggregate traffic flows and provides high-speed connectivity between ToR switches to properly route the traffic from a first server to a second server (see Fig.’s 1-2A & Para’s [0053-0054] & [0132-0139])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the system which includes the VXLAN gateway which may be an access node such as a ToR switch for routing a packet between a first server and a second server as disclosed in Zhang in view of Enoki, and further in view of Zhang to comprise the spine tier comprising at least one spine switch coupled to ToR switches 16 for routing traffic between a first server and a second server as disclosed in the teachings of Nakil, because the motivation lies in Nakil that the chassis switches 18 aggregate traffic flows and provides high-speed connectivity between ToR switches to properly route the traffic from a first server to a second server.
Regarding Claim 29, the combination of Zhang in view of Enoki, and further in view of Zhang discloses the system of claim 21 including the VXLAN gateway 108 which may be an access node such as a ToR switch (Zhang (‘992), see Para’s [0023-0024]), but does not disclose the system further comprising a leaf tier comprising the first network device. However the claim feature would be rendered obvious in view of Nakil et al. US (2015/0244617).
Nakil discloses a leaf tier comprising a first network device such as a first ToR switch 16 for routing traffic between a first server and a second server (see Fig. 2A i.e., TOR switches 16A-16N may be a “lief tier” & Para’s [0053-0054] i.e., switch fabric 14 is provided by a set of interconnected TOR switches 16A-16BN (collectively, “TOR switches 16”)).
(Nakil suggests that the TOR switches 16 and chassis switches 18 provides servers 12 with redundant connectivity to IP fabric 20 and the server provider network and chassis switches 18 aggregate traffic flows and provides high-speed connectivity between ToR switches to properly route the traffic from a first server to a second server (see Fig.’s 1-2A & Para’s [0053-0054] & [0132-0139])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the system which includes the VXLAN gateway which may be an access node such as a ToR switch for routing a packet between a first server and a second server as disclosed in Zhang in view of Enoki, and further in view of Zhang to be comprised in the leaf tier comprising a first network device such as a first ToR switch 16 for routing traffic between a first server and a second server as disclosed in the teachings of Nakil, because the motivation lies in Nakil that the TOR switches 16 and chassis switches 18 provides servers 12 with redundant connectivity to IP fabric 20 and the server provider network and chassis switches 18 aggregate traffic flows and provides high-speed connectivity between ToR switches to properly route the traffic from a first server to a second server.
Regarding Claim 30, the combination of Zhang in view of Enoki, and further in view of Zhang discloses the system of claim 29, but does not disclose the claim feature of wherein the leaf tier further comprises a second network device for connecting the first network device to the second server. However the claim feature would be rendered obvious in view of Nakil et al. US (2015/0244617).
Nakil discloses wherein the leaf tier further comprises a second network device (see Fig. 1 i.e., TOR switch 16N & Fig. 2A i.e., TOR switch 16B) for connecting the first network device (see Fig.’s 1-2A i.e., TOR switch 16A) to a second server (see Fig. 1 i.e., server 12X & Fig. 2A i.e., server 2), (see Para’s [0053-0054] & [0059])
(Nakil suggests that the TOR switches 16 and chassis switches 18 provides servers 12 with redundant connectivity to IP fabric 20 and the server provider network and chassis switches 18 aggregate traffic flows and provides high-speed connectivity between ToR switches to properly route the traffic from a first server to a second server (see Fig.’s 1-2A & Para’s [0053-0054] & [0132-0139])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the system which includes the VXLAN gateway which may be an access node such as a ToR switch for routing a packet between a first server and a second server as disclosed in Zhang in view of Enoki, and further in view of Zhang to be comprised in the leaf tier comprising a first network device such as a first ToR switch 16 and a second network device such as a second TOR switch 16 for connecting the first network device to a second server for routing traffic between a first server and the second server as disclosed in the teachings of Nakil, because the motivation lies in Nakil that the TOR switches 16 and chassis switches 18 provides servers 12 with redundant connectivity to IP fabric 20 and the server provider network and chassis switches 18 aggregate traffic flows and provides high-speed connectivity between ToR switches to properly route the traffic from a first server to a second server.
Regarding Claim 31, the combination of Zhang in view of Enoki, further in view of Zhang, and further in view of Nakil discloses the system of claim 30, wherein the second network device is a ToR switch, (Nakil, see Fig. 1 i.e., TOR switch 16N & Fig. 2A i.e., ToR switch 16B & Para’s [0053-0054] & [0059])
Claims 32-35 and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang US (2015/0009992) in view of Chu US (2014/0317616), further in view of Enoki et al. US (2008/0170494), and further in view of Zhang US (2014/0146817).
Regarding Claim 32, Zhang discloses a system for routing a first packet comprising: a first server (see Fig. 1 i.e., VTEP A 106) associated with a first Virtual Extensible Local Area Network (VXLAN) (see Fig. 1 i.e., VTEP A 106 is associated with first VXLAN 102a & Para’s [0022-0023] i.e., VTEP 106 may include, but are not limited to network switches, servers, and/or access node…In one example embodiment, when endpoints 104 are VMs, the VTEP 106 may be located within the hypervisor of the server that houses endpoints 104)
wherein the first VXLAN and a second VXLAN are distinct; (see Fig. 1 & Para’s [0022-0023] i.e., VXLAN networks 102a and 102b, [0032] i.e.., endpoint A 104 and VTEP A 106 may participate in one VXLAN network (e.g., VXLAN network 102a) and endpoint D 104 and VTEP B 106 participate in another VXLAN network (e.g., VXLAN network 102b), & [0033] i.e., because endpoint D 104 is located in another VXLAN network).
the first server is configured to receive a first packet (see Fig. 4 & Para’s [0033-0034] i.e., data packet 302 may be a MAC frame that may be transmitted to VTEP A 106 (i.e., “server”), & [0038] i.e., Fig. 4 is a schematic diagram of an example embodiment of data packet 302 that is transmitted from a source endpoint to a source VTEP (i.e., server)) and encapsulate the first packet in a first VXLAN frame to create a first encapsulated packet, (see Para’s [0033-0035] i.e., VTEP A 106 may obtain the MAC address and IP address of the VXLAN gateway 108 and encapsulate a VXLAN header that references the MAC address and IP address of VXLAN gateway 108. The VLAN header may be added in front of the data packet 302, [0039], & [0044-0045] i.e., method 800 performed by VXLAN gateway receives the VXLAN encapsulated data packet from a source VTEP at block 806)
said first packet comprising: a source media access control (MAC) frame, (see Fig. 4 & Para’s [0033] i.e., endpoint A 104 may transmit a data packet 302 destined for endpoint D 104. Data packet 302 may be a MAC frame (i.e., “source MAC frame”) & [0038])
said source MAC frame comprising: a payload, a first source MAC address, a first destination MAC address, a first source Internet Protocol (IP) address, and a first destination IP address, (see Fig. 4 & Para’s [0033] & [0038] i.e., Data packet 302 may comprise payload 402, ether type 404, endpoint A MAC address 406 and default gateway MAC address 408. Payload 402 may comprise the IP address for the source endpoint (e.g., endpoint A) and the destination endpoint (e.g. endpoint D), and the data for data packet 302)
said first source MAC address associated with the first VXLAN (see Fig. 4, 406 & Para’s [0022-0023], [0027], [0032] i.e., endpoint A is associated with VXLAN network 102a & [0038] i.e., Endpoint A MAC address 406 may indicate the MAC address of the source endpoint), and said first destination MAC address associated with a virtual address resolution protocol (VARP) virtual tunnel end point (VTEP), (see Para’s [0024] i.e., VXLAN gateway acting as a VTEP, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address, [0035], & [0038] i.e., the default gateway MAC address 408 may be inserted as the MAC address for the destination endpoint)
wherein said first source IP address associated with the first VXLAN and said first destination IP address associated with the second VXLAN, (see Fig. 4 & Para’s [0022-0023], [0032-0032] i.e., source endpoint A 104 may participate in VXLAN network102a and endpoint D 104 may participate in another VXLAN network 102b & [0038] i.e., Data packet 302 may comprise payload 402, ether type 404, endpoint A MAC address 406 and default gateway MAC address 408. Payload 402 may comprise the IP address for the source endpoint (e.g., endpoint A) and the destination endpoint (e.g. endpoint D), and the data for data packet 302)
said first VXLAN frame comprises a second destination IP address, (see Fig. 5 & Para [0034] i.e., VTEP A 106 may obtain the MAC address and IP address of the VXLAN gateway 108 and encapsulate a VXLAN header that references the MAC address and IP address (i.e., “second destination IP address”) of VXLAN gateway 108. The VLAN header may be added in front of the data packet 302 & [0039-0040] i.e., the VXLAN header 522 may comprise the VXLAN gateway IP address 514)
wherein the second destination IP address is a VARP VTEP IP address, (see Fig. 5 & Para’s [0024] i.e., VXLAN gateway acting as a VTEP, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP, [0034-0035] i.e., VTEP A 106 may obtain the MAC address and IP address of the VXLAN gateway 108 and encapsulate a VXLAN header that references the MAC address and IP address (i.e., “VARP VTEP IP address”) of VXLAN gateway 108. The VLAN header may be added in front of the data packet 302, [0039-0040] i.e., the VXLAN header 522 may comprise the VXLAN gateway IP address 514)
and a first network device (see Fig. 1 i.e., 108) configured to receive the first encapsulated packet, (see Fig. 5 & Para’s [0039] i.e., VXLAN encapsulated data packet 304 is transmitted from VTEP A 106 to VXLAN gateway 108 & [0045])
rewrite the source MAC frame to create a rewritten source MAC frame, (see Fig. 8 i.e., step 812 & Para’s [0033] i.e., endpoint A 104 may transmit a data packet 302 destined for endpoint D 104. Data packet 302 may be a MAC frame (i.e., “source MAC frame”), [0044] i.e., method 800 of Fig. 8 may be implemented by the VXLAN gateway & [0045] i.e., After receiving the VXLAN encapsulated data packet, method 800 may proceed to block 808 and remove the VXLAN header from the received VXLAN encapsulated data packet. Method 800 may determine the MAC address for the destination endpoint by initiating an ARP request or obtaining the MAC address from an ARP cache and/or forwarding entry table. Method 800 then moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint with the un-encapsulated data packet (i.e., “rewritten source MAC frame”))
and re-encapsulate the first packet in a second VXLAN frame to create a re-encapsulated packet, (see Fig. 6 & Fig. 8 i.e., step 816 & Para’s [0037], [0041] & [0045-0046] i.e., Method 800 then moves to block 816 and encapsulates the packet with a new VXLAN header (i.e., create a re-encapsulated packet)).
said rewritten source MAC frame replacing the first destination MAC address with a MAC address associated with the second VXLAN (see Para’s [0022], [0027] i.e., destination endpoint D 104 is associated with VXLAN network 102b (i.e., “second VXLAN”), [0032-0033] i.e., destination endpoint D 104 is located in another VXLAN network, [0035] i.e., the VXLAN gateway 108 may modify the contents of data packet 302 by replacing the default gateway MAC address with the MAC address of endpoint D 104, [0042], & [0045] i.e., After receiving the VXLAN encapsulated data packet, method 800 may proceed to block 808 and remove the VXLAN header from the received VXLAN encapsulated data packet. Method 800 may determine the MAC address for the destination endpoint by initiating an ARP request or obtaining the MAC address from an ARP cache and/or forwarding entry table. Method 800 then moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint (i.e., MAC address of endpoint D 104 is associated with second VXLAN network 102b) with the un-encapsulated data packet (i.e., “rewritten source MAC frame”))
A second network device (see Fig. 1 i.e., an intermediate network node may be located between the VXLAN gateway 108 and the VTEP B 106 for routing the packet to the destination endpoint 104 & Para [0024] i.e., Alternatively, the VXLAN gateway 108 may be coupled to VTEP A 106 and/or VTEP B 106 such that the interconnections between VTEPs 106 and VXLAN gateway 108 include OSI layer 2 and layer 3 network nodes (i.e., second device))
The second network device configured to receive the re-encapsulated packet (see Fig. 1 i.e., an intermediate network node may be located between the VXLAN gateway 108 and the VTEP B 106 which will receive the re-encapsulated packet from VXLAN gateway 108 for routing the packet to the destination endpoint 104 & Para’s [0024] i.e., Alternatively, the VXLAN gateway 108 may be coupled to VTEP A 106 and/or VTEP B 106 such that the interconnections between VTEPs 106 and VXLAN gateway 108 include OSI layer 2 and layer 3 network nodes (i.e., second device) & [0046])
wherein the first network device (see Fig. 1 i.e., VXLAN gateway 108 & Fig. 2): is alerted that the source MAC frame requires rewriting to route the source MAC frame to the second VxLAN (see Fig. 8 i.e., step 806 such as receiving a VXLAN encapsulated packet alerts the VXLAN gateway 108 to rewrite the source MAC frame & Para’s [0044-0046] i.e., method 800 may be implemented by a VXLAN gateway…At bock 806, method 800 may receive the VXLAN encapsulated packet from a source VTEP. The VXLAN encapsulated data packet may have originated from a source endpoint and may be destined for a destination endpoint located in a different VXLAN network than the VXLAN network associated with the source endpoint… Method 800 then moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint within the un-encapsulated data packet (i.e., “rewritten source MAC frame”))
in response to the first destination MAC address (see Fig. 4 i.e., default GW MAC 408) in the source MAC frame (see Fig. 4) being associated with the VARP VTEP, (see Para’s [0024] i.e., VXLAN gateway acting as a VTEP, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address, [0033-0035], [0038] i.e., the default gateway MAC address 408 may be inserted as the MAC address for the destination endpoint, & [0045])
maintains, on a per-layer VXLAN basis (see Para’s [0023] i.e., VXLAN network identifier (VNI), [0032-0033] i.e., VNI associated with different XVLAN networks & [0044-0045] i.e., different VXLAN networks), a plurality of VARP VTEP IP addresses, (see Fig. 2 i.e., forwarding entry table 206 & Para’s [0028] i.e., Fig. 2 is a network node 200 such as a VTEP 106 and VXLAN gateway 108 in Fig. 1, [0030] i.e., The forwarding entry table 206 may associate VTEP addresses (i.e., “plurality of VARP VTEP IP addresses”) to endpoint addresses…the forwarding entry table may associate both the IP addresses and the MAC addresses of VTEPs (i.e., “plurality of VARP VTEP IP addresses”) to the IP addresses and MAC address of endpoints)
wherein the second destination IP address is one of the plurality of VARP VTEP IP addresses, (see Para’s [0027] i.e., VXLAN gateway 108 may be configured as a VTEP [0030] i.e., the forwarding entry table may associate both the IP addresses and the MAC addresses of VTEPs (i.e., second destination IP address of VXLAN gateway may be included in the IP addresses of VTEPs in the forwarding entry table as forwarding information since the VXLAN gateway is also a VTEP which routes packets between the VTEPs and endpoints in different VXLAN networks) to the IP addresses and MAC address of endpoints, [0032], [0036-0037], & [0044-0045] )
and wherein the second destination IP address (see Fig. 5 i.e., 514) is associated with the first destination MAC address (see Fig. 4 i.e., 408) in the source MAC frame (see Fig. 5 i.e., VXLAN GW IP is associated with the default GW MAC address 408 & Para’s, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address, [0030] i.e., IP addresses and MAC addresses of VTEPs, [0034], [0038] i.e., default gateway MAC address, & [0040] i.e., The VXLAN gateway IP address 514 and VXLAN gateway MAC address 520 may indicate the IP address and MAC address of the destination VTEP)
and wherein the first server (see Fig. 1 i.e., VTEP A 106) and the first network device (see Fig. 1 i.e., VXLAN gateway 108) are configured to communicate with a second server (see Fig. 1 i.e., VTEP B 106) associated the second VXLAN, (see Fig. 1 i.e., VTEP B 106 (i.e., second server) is associated with second VXLAN network 102b & Para’s [0021-0024] & [0032-0037])
While Zhang discloses the first network device (i.e., Fig. 1, 108) rewrites the source MAC frame and creates a re-encapsulated packet for transmission to a second network device (see Fig. 1 & Para [0024] i.e., intermediate network node between VXLAN gateway 108 and VTEP B 106), Zhang does not disclose the second network device re-encapsulates the packet in a third VXLAN frame. However the claim feature would be rendered obvious in view of Chu US (2014/0317616).
Chu discloses a second network device (see Fig. 4 i.e., Tor switch 82) configured to receive a re-encapsulated packet from a first network device (see Fig. 4 i.e., Tor switch 80), (see Para’s [0041-0046] i.e., TOR switch 80 receives a packet and encapsulates the received packet which is forwarded to TOR switch 82).
the second network device re-encapsulates the packet in a third frame for forwarding to a destination device (see Para’s [0041-0046] i.e., TOR switch 80 receives a packet and encapsulates the received packet which is forward to TOR switch 82…TOR switch 82 decapsulates the received packet (i.e., remove the outer header) and then re-encapsulate the packet with an outer header including backbone-destination-address encoded with ethernet address of the TOR switch 84, and backbone-source-address encoded with ethernet address of the TOR switch 82 for forwarding to TOR switch 84).
(Chu suggests the second network device such as the TOR switch 82 re-encapsulates the received packet with updated routing information encoded in the packet for forwarding to the next destination for properly routing the received packet to its destination and for the next router to properly identify the source of the packet (see Fig. 4 & Para’s [0041-0046])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the second network device which receives the re-encapsulated packet from the first network device as disclosed in Zhang to re-encapsulate the packet in a third VXLAN frame based on the teachings of Chu who discloses a second network device such as TOR switch 82 re-encapsulates a packet received from a first network device such as TOR switch 80 in a third frame for forwarding to a destination device, because the motivation lies in Chu that the second network device such as the TOR switch 82 re-encapsulates the received packet with updated routing information encoded in the packet for forwarding to the next destination for properly routing the received packet to its destination and for the next router to properly identify the source of the packet.
While Zhang discloses the first network device rewrites the source MAC frame (see Para [0045]), the combination of Zhang in view of Chu does not disclose the claim features of said rewritten source MAC frame by the first network device includes replacing the first source MAC address with a MAC address associated with the VARP VTEP, and replacing the first destination MAC address with a MAC address associated with the second network device and the second network device further rewriting the source MAC frame to create a second rewritten source MAC frame, said second rewritten source MAC frame replacing the first source MAC address with a MAC address associated with the VARP VTEP, and replacing the first destination MAC address with a MAC address associated with the second VXLAN. However the claim features would be rendered obvious in view of Enoki et al. US (2008/0170494).
Enoki discloses said rewritten source MAC frame by a first network device such as a relay router includes replacing the first source MAC address with a MAC address associated with the router itself, and replacing a first destination MAC address with a MAC address associated with a second network device such as a next router (see Para [0027] i.e., A router used in the embodiment is an apparatus which relays data flowing on a network to another network…When the router receives a broadcast packet generated from an arbitrary host (apparatus), an IP address and a MAC address of the source are associated with each other to form an ARP table. When the data is relayed as described above, the router, with reference to the ARP table, rewrites a MAC address of a destination of the received data with that of the next router or the host and also rewrites a MAC address of the source with a MAC address of the router itself to relay the data).
and a second network device such as a relay router rewriting a source MAC frame to create a second rewritten source MAC frame (see Para [0027]), said second rewritten source MAC frame replacing the first source MAC address with a MAC address associated with the router itself, and replacing the first destination MAC address with a MAC address of a destination device (see Para [0027] i.e., A router used in the embodiment is an apparatus which relays data flowing on a network to another network…When the router receives a broadcast packet generated from an arbitrary host (apparatus), an IP address and a MAC address of the source are associated with each other to form an ARP table. When the data is relayed as described above, the router, with reference to the ARP table, rewrites a MAC address of a destination of the received data with that of the next router or the host and also rewrites a MAC address of the source with a MAC address of the router itself to relay the data. One of ordinary skill in the art would realize that a second relay router would perform the rewriting actions of Para [0027] for a received packet).
(Enoki suggests the router rewrites a MAC address of the source with a MAC address of the router itself in order to relay the data to the next router for ensuring the data packet is routed properly the next router and for the next router to identify the source of the packet (see Para [0027]))
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first network device and the second network device as disclosed in Zhang in view of Chu to each rewrite the received packet such as the source MAC frame being sent to the destination by the first device replacing the first source MAC address with a MAC address associated with the VARP VTEP, and replacing the first destination MAC address with a MAC address associated with the second network device and the second device replacing the first source MAC address with a MAC address associated with the VARP VTEP, and replacing the first destination MAC address with a MAC address associated with the second VXLAN based on the teachings of Enoki who discloses a network device such as a relay router when routing data rewrites a MAC address of a destination of the received data with that of a destination device and also rewrites a MAC address of the source with a MAC address of the router itself, because the motivation lies in Enoki that the router rewrites a MAC address of the source and destination with a MAC address of the router itself and the next destination in order to relay the data to the next device for ensuring the data packet is routed properly to the next device and for a next router to identify the source of the packet.
The combination of Zhang in view of Chu, and further in view of Enoki does not disclose wherein the first server is associated with the first VXLAN and the second VXLAN, and the second server associated with the first VXLAN and the second VXLAN. However the claim feature would be rendered obvious in view of Zhang US (2014/0146817).
Zhang wherein the first server is associated with the first VXLAN and the second VXLAN (see Fig. 1 i.e., first Server 150 (i.e., includes VTEP 1 152) on top left including one or more VMs 154 associated with a first VXLAN i.e., vX1 and second VXLAN vX2), and the second server associated with the first VXLAN and the second VXLAN (see Fig. 1 i.e., server 150 (i.e., includes VTEP 7 152) on the bottom right including one or more VMs 154 associated with a first VXLAN i.e., vX1 and second VXLAN vX2), (see Fig. 1 & Fig. 2 i.e., VMs 254 may be allocated to different VXLAN domains & Para [0016] i.e., A server 150 may comprise one or more VMs 154…In this example, the VMs 154 belong to three different VXLAN domains. The three different groups of VMs 154 have different shade patterns in Fig. 1 & [0019-0020] i.e., The server 250 comprises an improved or modified VTEP 252 and one or more VMs 254 coupled to the modified VTEP 252. The VMs 254 may be allocated to one or more VXLAN domains).
(Zhang suggests the server includes one or more VMs which are each associated with different VXLAN domains for forwarding traffic or packets of the VMs between different VXLAN domains for supporting and enabling VXLAN inter-domain communications, (see Para’s [0018-0020])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first server including one or more VMs associated with the first VXLAN 102a and the second server including one or more VMs associated with the second VXLAN 102b for communicating between the different VXLANs as disclosed in Zhang in view of Chu, and further in view of Enoki to each be associated with the first VXLAN and the second VXLAN based on the teachings of Zhang who discloses a first server and a second server each including one or more VMs which are each associated with a first VXLAN and a second VXLAN, because the motivation lies in Zhang suggests the server includes one or more VMs which are each associated with different VXLAN domains for forwarding traffic or packets of the VMs between different VXLAN domains for supporting and enabling VXLAN inter-domain communications.
Regarding Claim 33, the combination of Zhang in view of Chu, further in view of Enoki, and further in view of Zhang discloses the system of claim 32, wherein the first network device and the second network device are configured to route the first packet using an indirect overlay, (Zhang (‘992), see Fig. 1 & Para’s [0006] & [0024] i.e., Alternatively, the VXLAN gateway 108 may be coupled to VTEP A 106 and/or VTEP B 106 such that the interconnections between VTEPs 106 and VXLAN gateway 108 include OSI layer 2 and layer 3 network nodes)
Regarding Claim 34, the combination of Zhang in view of Chu, further in view of Enoki, and further in view of Zhang discloses the system of claim 33, wherein the first network device and the second network device are configured to route the first packet on a third VXLAN therebetween, (Zhang (‘992), see Fig. 1 & Para [0024] i.e., Alternatively, the VXLAN gateway 108 may be coupled to VTEP A 106 and/or VTEP B 106 such that the interconnections between VTEPs 106 and VXLAN gateway 108 include OSI layer 2 and layer 3 network nodes…other example embodiments of network system 100 may have VXLAN gateway 108 join and bridge communications for more than two VXLAN networks 102)
Regarding Claim 35, the combination of Zhang in view of Chu, and further in view of Enoki discloses the system of claim 32, including wherein the first network device is a first Top of Rack (ToR) switch (Zhang (‘992), see Fig. 1, 108 & Para’s [0023] i.e., access nodes may be e.g., ToR switches & [0024] i.e., VXLAN gateway 108 may be any network node, such as an access node), and the second network device (Zhang, see Para [0024] i.e., layer 2 and layer 3 network nodes) but does not explicitly disclose the second network device is a second ToR switch. However the claim feature would be rendered obvious in view of Zhang US (2014/0146817).
Zhang discloses a first network device such as a first ToR switch may be configured to communicate with a second network device such as a ToR switch (see Fig. 1 i.e., ToR switches 140 & Para’s [0015-0016] i.e., the servers 150 in the same data center (DC) are interconnected via ToR switches 140 & [0018-0021])
(Zhang suggests the ToR switches are used for enabling and supporting VLAN inter-domain communications for the VMs (see Fig.’s 1-2 & Para’s [0018-0021])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the second network device which may be a switch which communicates with the first network device such as a first ToR switch as disclosed in Zhang in view of Chu, and further in view of Enoki to be implemented as a second ToR switch based on the teachings of Zhang who discloses a first network device such as a first ToR switch may be configured to communicate with a second network device such as a ToR switch, because the motivation lies in Zhang suggests that the ToR switches are used for enabling and supporting VLAN inter-domain communications for the VMs.
Regarding Claim 37, the combination of Zhang in view of Enoki, and further in view of Zhang discloses the system of claim 36, but does not disclose the claim feature of wherein the first network device and the second network device are configured to route the first packet therebetween not using a VXLAN protocol. However the claim feature would be rendered obvious in view of Chu US (2014/0317616).
Chu discloses wherein a first network device (see Fig. 4 i.e., ToR switch 80) and a second network device (see Fig. 4 i.e., ToR switch 82) are configured to route a first packet therebetween not using a VXLAN protocol (see Fig. 4 & Para’s [0041-0046] i.e., packet is routed between ToR switch 80 and ToR switch 82 without using VXLAN protocol)
(Chu suggests the packet is routed from the first ToR switch to a second ToR switch with encapsulation techniques in order for the packet to be routed appropriately to its destination without using a VXLAN protocol which results in reduced overhead, (see Fig. 4 & Para’s [0041-0046])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first network device and the second network device configured to route the first packet therebetween as disclosed in Zhang in view of Enoki, and further in view of Zhang to route the first packet therebetween not using a VXLAN protocol as performed by the first network device and second network device disclosed in the teachings of Chu, because the motivation lies in Chu that the packet is routed from the first ToR switch to a second ToR switch with encapsulation techniques in order for the packet to be routed appropriately to its destination without using a VXLAN protocol which results in reduced overhead.
Claims 38-40 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang US (2015/0009992) in view of Enoki et al. US (2008/0170494).
Regarding Claim 38, Zhang discloses a first network device (see Fig. 1 i.e., VXLAN gateway 108) comprising: at least one processor (see Fig. 2 i.e., processor 202 & Para [0028]); and a non-transitory computer-readable medium (see Fig. 2 i.e., memory 204 & Para [0029] i.e., A memory 204 may be coupled to the processor 202 and may be non-transitory medium) storing computer-executable instructions to cause the at least one processor (see Fig. 2 & Para’s [0029-0031] i.e., store programs which are selected for execution…executable instructions) to perform a method for routing a first packet from a first layer-2 domain to a second layer-2 domain (see Fig. 1 & Para’s [0021-0024] i.e., the VXLAN gateway to forward packets between endpoints located in different VXLAN networks & [0033-0035]), the method comprising: receiving the first packet addressed to the first network device, (see Fig. 5 & Para’s [0035] & [0039] i.e., VXLAN encapsulated data packet 304 is transmitted from VTEP A 106 to VXLAN gateway 108 & [0045])
wherein the first packet comprises a first VXLAN frame (see Fig. 5) encapsulating a source MAC frame (see Fig. 4) to form a first encapsulated packet, (see Fig. 5 & Para’s [0033] i.e., data packet 302 may be a MAC frame, [0038] i.e., Data packet 302 is the data packet transmitted from endpoint A 104 to VTEP 106. Data packet 302 may comprise payload 402, ether type 404, endpoint A MAC address 406 and default gateway MAC address 408 & [0039] i.e., Fig. 5 is a schematic diagram of an example embodiment of a VXLAN encapsulated data packet 304 which may comprise a VXLAN header 522 and an encapsulated data packet 523. The encapsulated data packet 523 may be substantially similar to data packet 302 shown in Fig. 4. The header of the encapsulated data packet 523 may be the inner header, while the VXLAN header 522 may be the outer header)
wherein the first VXLAN frame comprises a VARP VTEP IP address (see Fig. 5 i.e., 514 & Para’s [0027] the address of VXLAN gateway 108 may be configured as the default VTEP destination address within VXLAN & [0040] i.e., VXLAN gateway IP address 514 may be inserted as the VTEP destination address)
decapsulating the first encapsulated packet to obtain the source MAC frame, (see Fig. 8 i.e., step 808 & Para’s [0044] i.e., method 800 may be implemented by a VXLAN gateway & [0045] i.e., method 800 may proceed to block 808 and remove the VXLAN header from the received VXLAN encapsulated data packet…Method 800 moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint within the un-encapsulated data packet)
rewriting the source MAC frame by changing a destination address from a VARP VTEP MAC address to a second layer-2 domain MAC address, (see Para’s [0022], [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address…destination endpoint D 104 is associated with VXLAN network 102b (i.e., “second VXLAN”), [0032-0033] i.e., destination endpoint D 104 is located in another VXLAN network, [0035] i.e., the VXLAN gateway 108 may modify the contents of data packet 302 by replacing the default gateway MAC address (i.e., “VARP VTEP MAC address”) with the MAC address of endpoint D 104, [0042], & [0045] i.e., After receiving the VXLAN encapsulated data packet, method 800 may proceed to block 808 and remove the VXLAN header from the received VXLAN encapsulated data packet. Method 800 may determine the MAC address for the destination endpoint by initiating an ARP request or obtaining the MAC address from an ARP cache and/or forwarding entry table. Method 800 then moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint (i.e., MAC address of endpoint D 104 is associated with second VXLAN network 102b) with the un-encapsulated data packet (i.e., “rewritten source MAC frame”))
generating a re-encapsulated packet comprising the rewritten source MAC frame and a second VXLAN frame; (see Fig. 6 & Fig. 8 i.e., step 816 & Para’s [0037], [0041] & [0045-0046] i.e., Method 800 then moves to block 816 and encapsulates the packet with a new VXLAN header (i.e., create a re-encapsulated packet)).
and routing the re-encapsulated packet towards the destination address in the second layer-2 domain, (see Fig. 8 i.e., step 818 & Para’s [0037] & [0046] i.e., After encapsulation, method 800 may then continue to block 818 to transmit the encapsulated VXLAN data packet to the destination VTEP)
wherein the first network device maintains a plurality of VARP VTEP MAC addresses (see Fig. 2 & Para’s [0028] i.e., network node 200 may be VXLAN gateway 108 in Fig. 1 & [0030] i.e., the forwarding entry table 206 may associated VTEP addresses to endpoint addresses…In an example embodiment, the forwarding entry table 206 may associate both the IP addresses and the MAC addresses of VTEPs to the IP addresses and MAC address of endpoints), each VARP VTEP MAC address being associated with a different layer-2 domain, (see Fig. 1 i.e., VTEP A 106 of VXLAN network 102a & VTEP B 106 of VXLAN network 102b & Para’s [0021-0024] i.e., the network system 100 that comprises at least two different VXLAN networks 102a and 102b…VXLAN networks 102a and 102b may each comprise a plurality of endpoints 104 and a VTEP 106, [0025], & [0030] i.e., In an example embodiment, the forwarding entry table 206 may associate both the IP addresses and the MAC addresses of VTEPs to the IP addresses and MAC address of endpoints)
wherein an existence of the VARP VTEP MAC address in the source MAC frame (see Fig. 4 i.e., 408) alerts the first network device that the source MAC frame requires routing to the second layer 2 domain (see Fig. 8 i.e., step 806 such as receiving a VXLAN encapsulated packet alerts the VXLAN gateway 108 to rewrite the source MAC frame & Para’s [0044-0046] i.e., method 800 may be implemented by a VXLAN gateway…At bock 806, method 800 may receive the VXLAN encapsulated packet from a source VTEP. The VXLAN encapsulated data packet may have originated from a source endpoint and may be destined for a destination endpoint located in a different VXLAN network than the VXLAN network associated with the source endpoint… Method 800 then moves to block 812 and replaces the MAC address of the default gateway with the MAC address of the destination endpoint within the un-encapsulated data packet (i.e., “rewritten source MAC frame”))
in response to the first destination MAC address (see Fig. 4 i.e., default GW MAC 408) in the source MAC frame (see Fig. 4) being associated with the VARP VTEP, (see Para’s [0024] i.e., VXLAN gateway acting as a VTEP, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address, [0033-0035], [0038] i.e., the default gateway MAC address 408 may be inserted as the MAC address for the destination endpoint, & [0045])
the first network device maintains, on a per-layer 2 domain basis (see Para’s [0023] i.e., VXLAN network identifier (VNI), [0032-0033] i.e., VNI associated with different XVLAN networks & [0044-0045] i.e., different VXLAN networks), a plurality of VARP VTEP IP addresses, (see Fig. 2 i.e., forwarding entry table 206 & Para’s [0028] i.e., Fig. 2 is a network node 200 such as a VTEP 106 and VXLAN gateway 108 in Fig. 1, [0030] i.e., The forwarding entry table 206 may associate VTEP addresses (i.e., “plurality of VARP VTEP IP addresses”) to endpoint addresses…the forwarding entry table may associate both the IP addresses and the MAC addresses of VTEPs (i.e., “plurality of VARP VTEP IP addresses”) to the IP addresses and MAC address of endpoints)
wherein the VARP VTEP IP address is one of the plurality of VARP VTEP IP addresses, (see Para’s [0027] i.e., VXLAN gateway 108 may be configured as a VTEP [0030] i.e., the forwarding entry table may associate both the IP addresses and the MAC addresses of VTEPs (i.e., second destination IP address of VXLAN gateway may be included in the IP addresses of VTEPs in the forwarding entry table as forwarding information since the VXLAN gateway is also a VTEP which routes packets between the VTEPs and endpoints in different VXLAN networks) to the IP addresses and MAC address of endpoints, [0032], [0036-0037], & [0044-0045] )
and the VARP VTEP IP address (see Fig. 5 i.e., 514) is associated with the VARP VTEP MAC address (see Fig. 5 i.e., VXLAN GW IP is associated with the default GW MAC address 408 (i.e., “VARP VTEP MAC address”) & Para’s, [0027] i.e., the address of VXLAN gateway 108 may be configured as the default VTEP destination address, [0030] i.e., IP addresses and MAC addresses of VTEPs, [0034], [0038] i.e., default gateway MAC address, & [0040] i.e., The VXLAN gateway IP address 514 and VXLAN gateway MAC address 520 may indicate the IP address and MAC address of the destination VTEP)
While Zhang discloses the rewritten source MAC frame comprises a source address which includes a first layer 2 domain MAC address (see Figures 4-5 i.e., 406 & Para’s [0038-0039] & [0045]), Zhang does not disclose the claim feature of said rewritten source MAC frame includes changing the source address from the first layer-2 domain MAC address to the VARP VTEP MAC address. However the claim feature would be rendered obvious in view of Enoki et al. US (2008/0170494).
Enoki discloses wherein a rewritten source MAC frame performed by a router replaces a first source MAC address with a MAC address associated with the router itself that received the packet (see Para [0027] i.e., A router used in the embodiment is an apparatus which relays data flowing on a network to another network…When the router receives a broadcast packet generated from an arbitrary host (apparatus), an IP address and a MAC address of the source are associated with each other to form an ARP table. When the data is relayed as described above, the router, with reference to the ARP table, rewrites a MAC address of a destination of the received data with that of the next router or the host and also rewrites a MAC address of the source with a MAC address of the router itself to relay the data).
(Enoki suggests the router rewrites a MAC address of the source with a MAC address of the router itself in order to relay the data to the next router for ensuring the data packet is routed properly the next router and for the next router to identify the source of the packet (see Para [0027]))
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first network device such as the VXLAN gateway which is a VTEP which rewrites the source MAC frame as disclosed in Zhang to change the source address from the first layer-2 domain MAC address to the VARP VTEP MAC address such as the VXLAN gateway, based on the teachings of Enoki discloses wherein a rewritten source MAC frame performed by a router replaces a first source MAC address with a MAC address associated with the router itself that received the packet, because the motivation lies in Enoki that the router rewrites a MAC address of the source with a MAC address of the router itself in order to relay the data to the next router for ensuring the data packet is routed properly to the next router and for the next router to identify the source of the packet.
Regarding Claim 39, the combination of Zhang in view of Enoki discloses the first network device of claim 38, wherein the first network device is configured to route the first packet using a direct overlay. (Zhang, see Para [0006], [0021-0024] i.e., Endpoints 104 may be unaware of VXLAN networks 102a and 102b, and may transmit data packets directly to a VTEP 106…The VXLAN gateway 108 may be directly connected to VTEP A 106 and/or VTEP B 106 & [0044-0046])
Regarding Claim 40, the combination of Zhang in view of Enoki discloses the first network device of claim 38, wherein the first network device is a ToR switch. (Zhang (‘992), see Fig. 1 i.e., VXLAN gateway 108 & Para’s [0023] i.e., access nodes may be (e.g., ToR switches & [0024] i.e., The VXLAN gateway 108 may be any network node, such as an access node (i.e., access node may be a “TOR switch”))
Claim 36 is rejected under 35 U.S.C. 103 as being unpatentable over Zhang US (2015/0009992) in view of Chu US (2014/0317616), further in view of Enoki et al. US (2008/0170494), and further in view of Zhang US (2014/0146817) as applied to claim 32 above, and further in view of Nakil et al. US (2015/0244617).
Regarding Claim 36, the combination of Zhang, in view of Chu, further in view of Enoki, and further in view of Zhang discloses the system of claim 32, but does not disclose the claim feature of wherein the first network device and the second network device are configured to route the first packet using a naked overlay. However the claim feature would be rendered obvious in view of Nakil et al. US (2015/0244617).
Nakil discloses wherein a first network device and a second network device are configured to route a first packet using a naked overlay (In light of the applicants specification in Para [0089], “naked overlay” refers to requiring the participation of spine switches, where the spine switches have knowledge (via their routing tables) about which layer 2 domains are accessible by each ToR, see Nakil, Fig. 1-2A i.e., chassis switches 18A-18M (i.e., “spine switches”) which participate in routing traffic flows between server 12A to a destination server 12B or 12X & Para’s [0053-0054] i.e., TOR switches 16 (i.e., first and second network devices) and chassis switches 18 provide servers with redundant (multi-homed) connectivity to IP fabric 20 and service provider network 7. Chassis switches 18 aggregate traffic flows and provides high-speed connectivity between TOR switches 16, [0059], [0096] & [0132-0139]).
(Nakil suggests that the chassis switches 18 aggregate traffic flows and provides high-speed connectivity between ToR switches to properly route the traffic from a first server to a second server (see Fig.’s 1-2A & Para’s [0053-0054] & [0132-0139])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first network device and the second network device which routes the packet as disclosed in Zhang, in view of Chu, further in view of Enoki, and further in view of Zhang to route the first packet using a naked overlay as disclosed in the teachings of Nakil who discloses wherein a first network device and a second network device are configured to route a first packet using a naked overlay by using chassis switches 18, because the motivation lies in Nakil that the chassis switches 18 aggregate traffic flows and provides high-speed connectivity between ToR switches to properly route the traffic from a first server to a second server.
Conclusion
THIS ACTION IS MADE FINAL. 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 ADNAN A BAIG whose telephone number is (571)270-7511. The examiner can normally be reached M-F 9:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Huy Vu can be reached at 571-272-3155. 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.
/ADNAN BAIG/Primary Examiner, Art Unit 2461