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 . Claims 1-20 are presented for examination.
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 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.
Foreign Priority
Receipt is acknowledged of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the file. Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. IN202341089495, filed on 12/28/2023.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 05/03/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Internet Communication Authorization
The examiner recommends filling a written authorization for internet communication in response to the present action. Doing so permits the USPTO to communicate with applicant using internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claims Objections
Claims 1, 9, 17 objected to because of the following informalities:
The Limitation “mapping the first multicast group to a second multicast group…by applying a mapping rule” is indefinite. The claim language never specifies what entity performs the mapping, where the mapping rule is stored, whether the mapping is deterministic, static or dynamic? Also its not clear whether multiple second multicast groups are possible for the same first group creating an ambiguity for an ordinary artisan.
The Limitation “encapsulating the multicast packet…..whose destination address is a multicast address of the second multicast group” is indefinite. The claim language does not clarify whether the encapsulation header carries multicast address or the encapsulated packet itself is modified or the destination address is inner vs. outer header. VXLAN systems have two destination addresses (overlay + underlay), it needs to distinguish between them. Appropriate corrections are required.
The Limitation “determining a third multicast group….for carrying multicast traffic to a multicast querier of a VLAN” is indefinite. The “multicast querier” is a role, not a destination, traffic is not carried to querier, and it’s not clear whether the third group is per VLAN, per querier or per-receiver set. Applicant need to clarify what topology this steps creates. Appropriate corrections are required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Immidi (US pub, 2019/0207779 A1) in view of McCane (US pub, 2009/0207840 A1).
Referring to claims 1 & 9, Immidi teaches a method, comprising: receiving, by a network device in an overlay network, a multicast packet destined to a first multicast group via an edge port of the network device, wherein the network device operates as a tunnel endpoint in the overlay network, and wherein the edge port is coupled to a source of the first multicast group (see ¶ [014], [019], Claim 1, registering a network device as a virtual extensible (VXLAN) Tunnel endpoints (VTEP) in an overlay network……..receiving multicast traffic from the multicast source);
encapsulating, by the network device, the multicast packet with a first encapsulation header with a destination address, which is a multicast address of the second multicast group (see ¶[014], VXLAN uses [048] encapsulation of network packets… ¶ [016]-[019] multicast traffic may be transmitted using a VXLAN, Fig. 1-3 show VXLAN encapsulation with underlay multicast delivery via RP);
identifying, by the network device, a Rendezvous Point (RP) of the second multicast group (see ¶ [016], “the network architecture 200…include ….a rendezvous point (RP) 250”, i.e. Identifies a Rendezvous point used for multicast routing in the underlay network); and
forwarding, by the network device, the encapsulated multicast packet to the RP based on the multicast address of the second multicast group (see ¶ [027],”transmitting the multicast traffic to a rendezvous point” , i.e. Transmitting multicast traffic to an RP and maintaining (*,G) / S,G) routes) & Claim 2, ¶ [027], “transmitting the multicast traffic to a rendezvous point).
Immidi teaches underlay multicast groups for VXLAN multicast delivery but does not expressly teach mapping, by the network device, the first multicast group to a second multicast group configured in an underlying network of the overlay network by applying a mapping rule.
However, McCanne teaches mapping, by the network device, the first multicast group to a second multicast group configured in an underlying network of the overlay network by applying a mapping rule (see McCanne: ¶ [078], Overlay routers cannot natively join an overlay group. Instead they Hash the overlay group to a native group …hash function is chosen to map the entire overlay address range into the native multicast address range that is bound to the overlay scope of the multicast…when an overlay router learns that it is incident to the multicast routing tree for some overlay group G…it joins the native multicast group h(G), i.e. Hash function that performs this mapping “ho” & ¶ [081], Collision Tolerance and Group pooling which corresponds to the claimed “mapping rule” and “range of predetermined multicast groups”);
It would have been obvious to an ordinary person skilled in the art at the time invention was made to modify Immidi’s VXLAN multicast system to include Overlay-to-Native multicast group mapping techniques as taught by McCanne in order to efficiently leverage underlay multicast infrastructure and reduce multicast state, as both references address scalable multicast distribution in overlay networks.
Referring to claims 2, 10 McCane teaches the method of claim 1,wherein the mapping rule comprises at least one of: a hash function producing an index for a range of predetermined multicast groups configured in the underlying network (see ¶ [078], Hash Overlay group to a native group, where the hash function is chosen to map the entire overlay address range into the native multicast address range……”;
sequential mapping to the range of multicast groups (see ¶ [081], Explains collisions and group pooling within a range of native multicast groups); and
a random mapping to the range of multicast groups (see McCane: ¶ [101], mapping is random, distributed mapping between multicast addresses and source domains, [141], [147],[151], [167]).
Referring to claim 3, 11, Immidi and McCane teaches the method of claim 1, wherein the first multicast group is based on a Protocol Independent Multicast (PIM) sparse-mode (SM) protocol (Immidi: [033], PIM-SM join behavior to RP(*,G) joins), and wherein the second multicast group is based on a bidirectional PIM (PIM-BIDIR) protocol (McCanne [077]-[079], Overlay routers forward traffic using native multicast shared trees, i.e. McCanne teaches RP-centric multi-cast trees and native multicast routing consistent with BIDIR/Shared-tree semantics even though protocol name BIDIR-PIM is not explicitly used, the RP-rooted shared tree model is disclosed).
It would have been obvious to utilize PIM-SM overlay joins as taught by Immidi to include RP=rooted shared trees / bidirectional multicast behavior in order to order to efficiently leverage underlay multicast infrastructure and reduce multicast state, as both references address scalable multicast distribution in overlay networks.
Referring to claim 4, 12, Immidi and McCane teaches the method of claim 1, wherein identifying the RP of the second multicast group comprises: selecting the RP from a set of RPs of a range of predetermined multicast groups configured in the underlying network (see ¶ [016], Network architecture includes a Rendezvous Point (RP0 250 used for multicast routing); and
using the mapping rule to select the second multicast group from the range of predetermined multicast groups (McCanne: [078]-[080], Mapping overlay address ranges into native multicast address ranges, McCanne teaches mapping overlay groups into range of native multicast groups which inherently corresponds to multicast infrastructure (including RP selection per group range making RP selection from a configured set obvious when mapping groups into ranges).
Referring to claims 5, 13, McCane teaches the method of claim 1, wherein multicast traffic from the source of the first multicast group is forwarded via a multicast tree rooted at the RP of the second multicast group (see ¶ [078], “Hash function…maps the entire overlay address range into the native multicast address range”).
Referring to claims 6,14. Immidi teaches the method of claim 1, further comprising determining, by the network device, a third multicast group configured in the underlying network, wherein the third multicast group is for carrying multicast traffic to a multicast querier of a virtual local area network (VLAN) associated with the multicast packet (see ¶ [032], IGMP join on VXLAN VLAN; DR processes IGMP joins and manages multicast forwarding, i.e. Immidi discloses IGMP join processing on a VXLAN VLAN and designated-router behavior, establishing VLAN association, Multicast Querier (IGMP Context), multicast traffic distribution to queriers).
Referring to claims 7,15. Immidi teaches the method of claim 6, further comprising:
encapsulating, by the network device, a copy of the multicast packet with a second encapsulation header, wherein a destination address of the second encapsulation header comprises a second multicast address of the third multicast group (¶ [037] Immidi disclose multicast traffic replication and forwarding to multiple receivers via the underlay “multicast traffic forwarded using shared trees to multiple receivers);
identifying, by the network device, a second RP of the third multicast group (replication of multicast packets to multiple underlay multicast destinations is inherent in shared-tree multicast forwarding); and forwarding, by the network device, the encapsulated copy of the multicast packet to the second RP based on the second multicast address (see ¶ [037], Mutlicast traffic forwarded using shared trees to multiple receivers, ).
Referring to claim 8,16. The method of claim 1, wherein the third multicast group is associated with a respective multicast group sending traffic over the VLAN (see ¶ [032], “IGMP join/request/message on the VXLAN VLAN”).
Referring to claim 17, Immidi teaches a method comprising: receiving, by a network device in an overlay network, a first join request from a client device requesting multicast traffic of a first multicast group via an edge port of the network device, wherein the network device operates as a tunnel endpoint in the overlay network (see ¶ [032], The multicast receiver 304 …may send an IGMP join request/message on the VXLAN VLAN”, i.e. Immidi discloses receiving IGMP join requests from multicast receiver in a VXLAN environment);
generating, by the network device, a second join request requesting multicast traffic of the second multicast group (see ¶ [033], “the network device may send a (*,G) join request/message to the rendezvous point” , i.e. Immidi discloses generating and forwarding (*,G) join messages toward the RP)
identifying, by the network device, a Rendezvous Point (RP) of the second multicast group (see ¶ [016], “the network architecture 200…include ….a rendezvous point (RP) 250”, i.e. Identifies a Rendezvous point used for multicast routing in the underlay network); and
forwarding, by the network device, the second join request to the RP based on a multicast address of the second multicast group (see ¶ [033], “the network device…may forward the (*,G) join to the rendezvous point 250” i.e. Immidi teaches forwarding join requests to the RP to establish multicast state)
Immidi teaches underlay multicast groups for VXLAN multicast delivery but does not expressly teach mapping, by the network device, the first multicast group to a second multicast group configured in an underlying network of the overlay network by applying a mapping rule.
However, McCanne mapping, by the network device, the first multicast group to a second multicast group configured in an underlying network of the overlay network by applying a mapping rule (see McCanne: ¶ [078], Overlay routers cannot natively join an overlay group. Instead they Hash the overlay group to a native group …hash function is chosen to map the entire overlay address range into the native multicast address range that is bound to the overlay scope of the multicast…when an overlay router learns that it is incident to the multicast routing tree for some overlay group G…it joins the native multicast group h(G), i.e. Hash function that performs this mapping “ho” & ¶ [081], Collision Tolerance and Group pooling which corresponds to the claimed “mapping rule” and “range of predetermined multicast groups”);
It would have been obvious to an ordinary person skilled in the art at the time invention was made to modify Immidi’s VXLAN multicast system to include Overlay-to-Native multicast group mapping techniques as taught by McCanne in order to efficiently leverage underlay multicast infrastructure and reduce multicast state, as both references address scalable multicast distribution in overlay networks.
Referring to claim 18, Immidi teaches the method of claim 17, further comprising:
receiving, by the network device, a multicast packet encapsulated by an encapsulation header with a destination address, which is the multicast address of the second multicast group, wherein the multicast packet belongs to the first multicast group ([033], Receiving multicast traffic via the underlay after sending (*.G) joins, i.e. distinction between outer (underlay) and inner (overlay) group me membership is inherent in VXLAN encapsulation); and
forwarding, by the network device, the multicast packet via the edge port based on the first join request (see ¶ [037], Immidi teaches forwarding multicast traffic to receivers based on routing state).
Referring to claim 19, McCanne teaches the method of claim 17, wherein the mapping rule comprises at least one a hash function producing an index for a range of predetermined multicast groups configured in the underlying network ([078], Hash mapping of overlay group to native group, i.e. McCanne explicitly teaches hash mapping and discusses address collision and group pooling); a sequential mapping to the range of multicast groups; and a random mapping to the range of multicast groups (sequential or random selection from a group range in an obvious design alternative to hashing once group poolin is taught~Obvious over McCanne ).
Referring to claim 20, Immidi and McCanne teaches the method of claim 17, wherein the first multicast group is based on a Protocol Independent Multicast (PIM) sparse-mode (SM) protocol, and wherein the second multicast group is based on a bidirectional PIM (PIM-BIDIR) protocol (Immidi ¶ [033], PIM-SM join messages to RP & McCanne ¶ [077]-[079], RP-rooted shared trees / bidirectional multicast behavior).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Additional relevant prior art can be found in the included form PTO-892 (Notice of Cited References).
The examiner also requests, when responding to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application. Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111 (c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AFTAB N. KHAN whose telephone number is (571)270-5172. The examiner can normally be reached on Monday-Friday 8AM-5PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Glenton 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AFTAB N. KHAN/
Primary Examiner, Art Unit 2454