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
Applicant's arguments filed 06/17/2025 have been fully considered but they are not persuasive.
Applicant’s arguments (Examiner’s emphasis – Bold, Italics)
Argument 1 (Summary of pages 7-10).
…Applicant argued that none of the cited references, alone or in combination, disclose this claimed feature of “generating an update message comprising ... an attribute including a type length value (TLV) having a tunnel type and a path bit positions sub-TLV.” Claim 14 includes similar features.
Response:
Examiner respectfully disagrees.
In particular, Dutta discloses generating an update message which includes attributes such as reachability information via a next-hop [0160], a type length value (TLV) encoded in a BitString [0265], including generating subset tunnel bit string based on a first tunnel bit string, wherein the subset tunnel bit string includes set bit positions corresponding to only MPLS-TE tunnels sharing the adjacency next-hop. Dutta [0021] discloses identifying a first bit position in a tunnel bit string included in the BIER header; determine a bit string entry in the BIFT based on the first bit position in the tunnel bit string; obtain an adjacency next-hop for a payload of the received BIER packet based on the bit string entry in the BIFT; and send a BIER packet including the payload to the adjacency next-hop. Thus, disclosing a path bit position included in the header of a BIER that is used to describe characteristics of a network path including determining an adjacency next-hop of an identified path. However, Dutta did not explicitly disclose “Sub-TLV”, a Type-Length-Value (TLV) structure that provides additional, specific information within another TLV, serving as a nested data container. In figs. 11- 16, Yong discloses an encapsulated sub-type-length-value (TLV) that provides the nested data structure required by the claim. In particular, [0063-0065] figs. 10 &12 discloses supported NLRI type 1092 comprising several attributes encapsulated in a packet header. The packet may be a BGP update message, including a header filed and supports a sub-TLV structure. Therefore, Yong provides the sub-TLV structure in a BGP packet header where the bit position of Dutta can be defined. Thus, Dutta modified by Yong disclose all of the limitations of claim 1 by providing a sub-TLV structure where path bit positions can be defined as required by the claim.
Furthermore, Xiong et al. (US 2021/0092046 A1) in [0096; 0184-0188] discloses a BIER(TE) head carries multiple BST sub-TLVs. A bit position B is newly added, and B being set represents that the package message carries the BSL-TLV; otherwise, the message is forwarded in a default manner. Also, for each BST sub-TLV, an index parameter and a sub-BST in the bit string sub-TLV are acquired. An operation may be performed on a combined BST and the sub-BST to obtain a bit position that is not 0; and the bit position that is not 0 is traversed in the BIER message forwarding table of the node, and for the bit position that is not 0, the message forwarding is performed to an adjacency type of the bit position that is not 0.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1,8-10,13-14, 21-23 and 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dutta (US 2020/0344162 A1), in view of Yong (US 2014/0086253 A1).
Regarding claim 1, Dutta discloses a method implemented by a controller (fig. 2 – SDN controller) configured to implement a border gateway protocol (BGP) and control a Bit Index Explicit Replication Traffic/Tree Engineering (BIER-TE) domain (Dutta, fig. 2, [0031; 0108] discloses a centralized SDN controller that oversees an assignment of a domain wide unique BIFT-id for (SubDomain (SD), Set-id (SI), BitStrinLength (BSL) in a Bit Index Explicit Replication (BIER) domain which includes Bit-Forwarding Routers (BFRs). The unique BIFT-id for (SD, SI, BitString) is advertised across the BIER domain by the BIER control plane protocols such as Border Gateway Protocol-Link State (BGP-LS), comprising:
generating an update message (Dutta [0176] the SDN controller programs the BIFT in each router with the bit assigned. [0189] if router BR1 intends to send the multicast flow along a traffic engineered explicit path tree, which meets the QoS requirements of the flow, then the explicit path is computed by the SDN controller based on its traffic engineering database (TE-DB) of the network. [0220] In SDN, the PCE server may be a component of SDN controller. Computation Element (PCE) Server receives updates on TE metrics of the links in the network and builds/generates its own updated TE-DB),
comprising a network layer reachability information (NLRI) (BFERs reachable via a next-hop) (Dutta [0160] in S90, a BitString update message is generated for an original packet by AND”ing the “original” BitString with a Forwarding Bit Mask (F-BM), where the update includes the BitString of the forwarded packet which provides reachability information used to identify only those BFERs reachable via that next-hop), and
an attribute including a type length value (TLV) having a tunnel type (Dutta [0264] A RSVP-TE message (e.g., Path or Resv Message) carries several “Objects”, each Object carrying a set of parameters or characteristics of a MPLS-TE tunnel. [0220] Since the PCE server/SDN controller receives updates on TE metrics of the links in the network and builds/generates its own updated TE-DB), a bit string entry for the tunnel in a Bit Index Forwarding Table (BIFT) (e.g., a Traffic Engineering-Bit Index Forwarding Table (TE-BIFT)) for tunnels from a source router to a plurality of destination routers, may also be updated, the BIFT being indexed based on the source router identification information and at least a portion of the destination router identification information. [0265] one of the attributes of the BIER-TB BitString is a Type, Length, Value (TLV) encoded information in the BitString) and
distributing the update message to a bit forwarding router (BFR) in the BIER-TE domain (Dutta, fig. 2, [0031] discloses illustrates an example Bit Index Explicit Replication (BIER) domain including Bit-Forwarding Routers (BFRs). [0118] FIG. 5, When a BFIR receives a multicast data packet from outside the BIER domain, the BFIR determines the set of BFERs for that packet. [0160] in S90, a BitString update is generated for an original packet by AND”ing the “original” BitString with a Forwarding Bit Mask (F-BM), and then forward the copy of the updated packet to the next-hop/Bit-FRs) in the BIER-TE domain).
Dutta did not explicitly disclose a path bit positions sub-TLV, generating an update message comprising a BIER-TE path subsequent address family indicator (SAFI), a network layer reachability information (NLRI) including a distinguisher field.
Yong discloses generating an update message comprising a BIER-TE path subsequent address family indicator (SAFI) (Yong [0065], fig. 14, discloses a BGP Update message 1400 which comprise a header field 1010, a variable-sized Multiprotocol Reachable Network Layer Reachable Information (MP_REACH_NLRI) field 1420, and a variable-sized Multiprotocol Unreachable Network Layer Reachable Information (MP_UNREACH_NLRI) field 1450. The header field 1010 may indicate a BGP Update message type in the header type field 1010. The MP_REACH_NLRI field 1420 may advertise the feasible routes and may comprise an AFI field 1431, a SAFI field 1432, a length of next hop network address field 1433, a network address of next hop field 1434, and a NLRI field 1435. The MP_UNREACH_NLRI field 1450 may advertise the withdrawn routes and may comprise an AFI field 1451, a SAFI field 1452, and a withdrawn routes field 1453),
a network layer reachability information (NLRI) including a distinguisher field (Yong fig. 10, [0065], fig. 14, discloses a BGP Update message 1400 which comprise a header field 1010, a variable-sized Multiprotocol Reachable Network Layer Reachable Information (MP_REACH_NLRI) field 1420, and a variable-sized Multiprotocol Unreachable Network Layer Reachable Information (MP_UNREACH_NLRI) field 1450. The header field 1010 may indicate a BGP Update message type in the header type field 1010. The MP_REACH_NLRI field 1420 may advertise the feasible routes and may comprise an AFI field 1431, a SAFI field 1432, a length of next hop network address field 1433, a network address of next hop field 1434, and a NLRI field 1435. The MP_UNREACH_NLRI field 1450 may advertise the withdrawn routes and may comprise an AFI field 1451, a SAFI field 1452, and a withdrawn routes field 1453), and
an attribute including a type length value (TLV) and a path bit positions sub-TLV (Yong [0063] figs. 10 & 12, discloses a detailed view of supported NLRI type sub-TLV 1092 of FIG. 10. Supported NLRI type sub-TLV 1092 may comprise a type field 1210, a length field 1220, and a supported NLRI type message value 1230. The type field 1210 may indicate the message is a supported NLRI type message. The length field 1220 may indicate the size of the supported NLRI type message value 1230).
One of ordinary skill would have been motivated to combine the teachings of Dutta, and Yong because these teachings are from the same field of endeavor with respect to the use of Border Gateway Protocol (BGP) to announce update of addresses of a next-hop in a service path.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Yong into the method by Dutta, thereby enabling performing encapsulation translation on the data packet by replacing the encapsulation header of the first encapsulation type with an encapsulation header of the second encapsulation type to form a translated packet, and forwarding the translated packet toward the egress tunnel endpoint via a second overlay tunnel, wherein the first encapsulation type and the second encapsulation type are different encapsulation types, and wherein the data packet is destined to the egress tunnel endpoint, Yong, [Abstract].
Regarding claim 8, Dutta modified by Yong disclose the method of claim 1, wherein the update message is distributed to a BGP peer running on a bit forwarding ingress router (BFIR) of the BIER-TE domain (Dutta [0065] discloses a multicast data packet entering a BIER domain, the ingress router (e.g., source S in FIG. 1) determines a set of egress routers to which the packet should be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header includes a BitString in which each bit represents exactly one egress router in the domain. To forward the packet to a given set of egress routers, the specific bits corresponding to those routers are set in the BitString included in the BIER header. Update messages of the BitString are forward to a next-hop (peer node) or advertised across peer nodes in the BIER domain using a BIER control plane protocol such as a Border Gateway Protocol-Link State (BGP-LS)).
The motivation to combine is similar to that of claim 1.
Regarding claim 9, Dutta modified by Yong disclose the method of claim 1, wherein the TLV further comprises a path name sub-TLV that encodes a name of a BIER-TE path (Dutta [0354] discloses a header of a Bit Index Explicit Replication package (H-BIER) where a Bit Forwarding Router (BFR) advertises a BFR-Prefix in OSPF Extended Prefix TLV, that includes the H-BIER Sub-TLV. The BFR can include BIER Sub-TLV in the advertisement, and the BFR is configured to send or receive H-BIER packets on MPLS network, then it sends MPLS Encapsulation sub-TLV. A path Label/name value is the label that the BFR will use to identify a path through which it receives H-BIER packets. [0339] also discloses a BIER Algorithm. It specifies the algorithm to be used when calculating optimal path to the BFR-Prefix).
The motivation to combination is similar to that of claim 1.
Regarding claim 10, Dutta modified by Yong disclose the method of claim 1, wherein the TLV further comprises a traffic description sub-TLV that encodes multicast traffic transported by a BIER-TE path (Dutta [0366] attributes encoded in a header of a BIER Sub-TLV packet (H-BIER Sub-TLV) defining a best BIER-Path. To advertise the name or prefix of the best BIER-Path, a best path to the prefix in the source area is examined to find the advertising router associated with the best path to that prefix. Determine if such advertising router advertised a H-BIER Sub-TLV for the prefix. If yes, the ABR will copy the information from such H-BIER Sub-TLV when advertising H-BIER Sub-TLV to each attached area. That is, the H-BIER Sub-TLV encodes an identifier of the best BIER-TE path).
The motivation to combine is similar to that of claim 1.
Regarding claim 13, Dutta modified by Yong disclose the method of claim 1, wherein the update message further comprises an address family indicator (AFI) that identifies Internet Protocol version four (IPv4) or Internet Protocol version six (IPv6) (Yong [0063] discloses a supported NLRI type message value 1230 which may include a plurality of address family identifiers (AFIs) and subsequent address family identifiers (SAFIs), which may indicate the route types. Each AFI or SAFI may be about 2 octets long. Currently, AFI may be Internet Protocol Version 4 (IPv4), Internet Protocol Version 6 (IPv6), or Layer 2 Virtual Private Network (L2VPN), and SFI may be IPv4, IPv6, or Ethernet Virtual Private Network (EVPN), as defined in RFC 5512).
The motivation to combine is similar to that of claim 1.
Regarding claim 14, Dutta discloses a controller (router) configured to implement a border gateway protocol (BGP) and control a Bit Index Explicit Replication Traffic/Tree Engineering (BIER-TE) domain, (Dutta [Abstract] a router, determines source and destination router identification information for a tunnel traversing the router based on a routable source IP address for the tunnel; program a bit string entry for the tunnel in a Bit Index Forwarding Table (BIFT) for tunnels from a source router to a plurality of destination routers, the BIFT being indexed based on the source router identification information and at least a portion of the destination router identification information; and route packet data received at the router according to the BIFT. [0108] a BitString Forwarding Router’s prefix (BFR's BFR-Prefix) to a tuple {SD, SI, BitString} mapping is advertised across the BIER domain by the BIER control plane protocols (e.g., Intermediate System-to-Intermediate System (IS-IS), Open Shortest Path First (OSPF), Border Gateway Protocol-Link State (BGP-LS), or the like)).
a memory storing instructions (Dutta, [0002] a router comprising: at least one processor and at least one memory including computer program code); and
a processor coupled to the memory, the processor configured to execute the instructions to cause the controller to a router comprising: (Dutta, [0002] a router comprising: at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the router to: determine source router identification information for a tunnel (e.g., a Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) tunnel) traversing the router based on a routable source IP address for the tunnel; determine destination router identification information for the tunnel based on a routable destination IP address for the tunnel):
The rest of the limitations of claim 14 are rejected with rational similar to that of claim 1.
Regarding claim(s) 21-23 and 26, the claim(s) are rejected with rational similar to that of claim(s) 8-10 and 13, respectively.
Claim(s) 2 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dutta (US 2020/0344162 A1), in view of Yong (US 2014/0086253 A1), further in view of Chen et al. (US 2019/0116114 A1).
Regarding claim 2, Dutta and Yong disclose the method of claim 1, but did not explicitly disclose wherein the distinguisher field comprises a value that uniquely identifies content associated with a BIER-TE path.
Chen discloses wherein the distinguisher field (BIER-TE path identifier) comprises a value that uniquely identifies content associated with a BIER-TE path (Chen [0012] discloses a packet to be sent to a BFER in a BIER-TE and a path identifier are received, where the path identifier is used uniquely distinguish a primary path and a backup path through which the packet is sent from a first BFR to a next-hop BFR of the first BFR; a bitstring for use in forwarding the packet to the BFER is determined according to the path identifier; and the bitstring is filled into the packet, and the packet is forwarded according to the bitstring).
One of ordinary skill would have been motivated to combine the teachings of Dutta, Yong and Chen because these teachings are from the same field of endeavor with respect to techniques for packet forwarding using a BIER-TE Forwarding Table (BIFT).
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Chen into the method by Dutta and Yong thereby configuring a BIER-TE path with links belongs to multiple Fast Re-Route path, achieving the effect of reasonably and effectively protecting a configuration path to avoid waste of resources, Chen, [0038].
Regarding claim(s) 15, the claim(s) is/are rejected with rational similar to that of claim(s) 2.
Claim(s) 3-4 and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dutta (US 2020/0344162 A1), in view of Yong (US 2014/0086253 A1), further in view of Peng et al. (US 2020/0267011 A1).
Regarding claim 3, Dutta modified by Yong disclose the method of claim 1, but did not explicitly disclose wherein the NLRI includes a tunnel identifier field comprising a sub-domain identifier (ID), a bit forwarding router identifier (BFR-id) field, and a tunnel ID, wherein the sub-domain identifier identifies a sub-domain through which a BIER-TE tunnel crosses, the BFR-id field identifies a bit forwarding ingress router (BFIR) of the BIER-TE tunnel, and the tunnel ID uniquely identifies the BIER-TE tunnel within the BFIR and the sub- domain.
Peng discloses wherein the NLRI includes a tunnel identifier field comprising a sub-domain identifier (ID), a bit forwarding router identifier (BFR-id) field, and a tunnel ID, wherein the sub-domain identifier identifies a sub-domain through which a BIER-TE tunnel crosses, the BFR-id field identifies a bit forwarding ingress router (BFIR) of the BIER-TE tunnel, and the tunnel ID uniquely identifies the BIER-TE tunnel within the BFIR and the sub- domain (Peng [0076] discloses P-Multicast route as a route type newly added in Multicast-Virtual Private Network Layer Reachability Information (MCAST-VPN NLRI) defined in RFC 6514 and is configured for a P-Multicast join notification. The P-Multicast route may include the PTA, where the Tunnel Type field may be set to the BIER, and the Tunnel Identifier field is set to a corresponding {BIER sub-domain ID, BFIR-prefix}. FIG. 6 illustrates P-Multicast route message. The node S sends the multicast message encapsulated through the BIER in the BIER sub-domain 0, and in a BitString in the BIER header, a Bit-Position corresponding to BFR-id-ABR1 and a Bit-Position corresponding to BFR-id-ABR2 will be set. The message will be sent to an IGP next hop, a node T according to a conventional BIER forwarding procedure, and after receiving the message, the node T continues to send the message to the ABR1 and the ABR2 according to the BIER forwarding procedure).
One of ordinary skill would have been motivated to combine the teachings of Dutta, Yong and Peng because these teachings are from the same field of endeavor with respect to techniques for effectively routing multicast traffic.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Peng into the method by Dutta and Yong, thereby enabling dividing nodes in each domain of a multi-domain network into a multicast proxy nodes and a common nodes; sending, by the common nodes, a subscription request to a multicast source node outside the each domain through the multicast proxy nodes in the each domain; sending, by the multicast source node, a bit indexed explicit replication (BIER) multicast message obtained through BIER encapsulation to the multicast proxy nodes; and sending, by the multicast proxy nodes, the BIER multicast message to the common nodes, Peng, [Abstract].
Regarding claim 4, Dutta, Yong and Peng disclose the method of claim 3, wherein the tunnel identifier field comprises a BFR prefix of the BFIR of the BIER-TE tunnel (Dutta, figs. 12, 15, 17 and 18, 0226 -0229-0230] In FIG. 12, for simplicity all routers R1-R8 are within the same SubDomain and Set-id {1,0}. If an allocated BitString for routers R1-R8 are bits 1-8, respectively, then a router uses the loopback address used as source or destination IP address for MPLS-TE tunnels as the BFR-Prefix. In steps S1502 and S1504, the router R3 determines the tuple {SD, SI, BitString} mapped to the source IP address (BFR-Prefix) of the MPLS-TE tunnel. This is denoted as {srcSD, srcSI, srcBitString} (sometimes referred to as source or ingress router identification information), which uniquely identifies the source of the MPLS-TE tunnel. Also, at step S1504, the router R3 determines the {SD, SI, BitString} mapped to the destination IP address (BFR-Prefix) of the MPLS-TE tunnel. This is denoted as {dstSD, dstSI, dstBitString} (sometimes referred to as destination or egress router identification information)).
The motivation to combine is similar to that of claim 3
Regarding claim(s) 16 and 17, the claim(s) is/are rejected with rational similar to that of claim(s) 3 and 4, respectively.
Claim(s) 5-6 and 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dutta (US 2020/0344162 A1), in view of Yong (US 2014/0086253 A1), further in view of Mishra et al. (US 11,102,107 B1).
Regarding claim 5, Dutta modified by Yong disclose the method of claim 1, but did not explicitly disclose wherein the attribute comprises a tunnel encapsulation attribute.
Mishra discloses wherein the attribute comprises a tunnel encapsulation attribute (Mishra, fig. 5b, col. 8, lines 21-36, at 590, during a BGP procedure, a source router (e.g., router R4) generates a BGP update that includes a BGP route and a tunnel encapsulation attribute, such that the tunnel encapsulation attribute indicates multiple subdomains of a BIER domain of the network on which multicast packets can be forwarded, by the source router, to receiver routers in the network).
One of ordinary skill would have been motivated to combine the teachings of Dutta, Yong and Mishra because these teachings are from the same field of endeavor with respect to the use of Border Gateway Protocol (BGP) to announce update of addresses of a next-hop in a service path.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Mishra into the method by Dutta and Yong, thereby a first router is configured to perform Bit Index Explicit Replication (BIER) for forwarding of multicast packets in a network, storing configuration information that indicates that the first router belongs to multiple subdomains of a BIER domain, and is able to forward the multicast packets for a virtual private network on the multiple subdomains, Mishra, [Abstract].
Regarding claim 6, Dutta modified by Yong disclose the method of claim 1, but did not explicitly disclose the method of claim 1, wherein the attribute comprises a P-Multicast Service Interface (PSMI) tunnel attribute (PTA).
Mishra discloses wherein the attribute comprises a P-Multicast Service Interface (PSMI) tunnel attribute (PTA) (Mishra, fig. 5b, col. 8, lines 21-36, the BGP update may include an I-PMSI route as the BGP route, and a tunnel encapsulation attribute may include multiple PTAs corresponding to respective ones of the multiple subdomains, as shown in FIG. 5B. The tunnel encapsulation attribute may include a TLV element, and the TLV element may include sub-TLVs. The source router may encode at least some of the multiple PTAs in corresponding ones of the sub-TLVs).
The motivation to combine is similar to that of claim 5.
Regarding claim(s) 18-19, the claim(s) is/are rejected with rational similar to that of claim(s) 5-6, respectively.
Claim(s) 7 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dutta (US 2020/0344162 A1), in view of Yong (US 2014/0086253 A1), further in view XIONG et al. (US 2021/0092046 A1).
Regarding claim 7, Dutta modified by Yong disclose the method of claim 1, but did not explicitly disclose wherein the path bit positions sub-TLV includes a bit index forwarding table identifier (BIFT-id) field, a set identifier (SI) field, and a bitstring field.
Xiong discloses wherein the path bit positions sub-TLV includes a bit index forwarding table identifier (BIFT-id) field, a set identifier (SI) field, and a bitstring field (Xiong [0085] fig. 14, discloses a package format 12 includes fields, such as a BIFT-id and sub-BSTs; fields, such as an SD ID, a BSL and an SI, are used as globally unique variables of a key value, which is the same as a node side BIFT ID; and of course, the format may also include an on-flag bit N. When N is set, it means that the sub-TLV is a bottom TLV).
One of ordinary skill would have been motivated to combine the teachings of Dutta, Yong and Xiong because these teachings are from the same field of endeavor with respect to the use of Border Gateway Protocol (BGP) to announce update of addresses of a next-hop in a service path.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Yong into the method by Dutta and Yong thereby providing a packet forwarding method based on BIER-TE, by acquiring X bit string sub-package structures from a BIER-TE based message; and forwarding the message according to the X bit string sub-package structures, where X is greater than or equal to 1, Xiong, [Abstract].
Regarding claim(s) 20 the claim(s) is/are rejected with rational similar to that of claim(s) 7.
Claim(s) 11 and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dutta (US 2020/0344162 A1), in view of Yong (US 2014/0086253 A1), further in view of Mack-Crane et al. (US 2013/0114595 A1).
Regarding claim 11, Dutta modified by Yong disclose the method of claim 1, but did not explicitly disclose wherein the TLV further comprises a service sub-TLV that contains a service identifier (ID) or a label to be added into a packet to be carried by a BIER-TE path.
Mack-Crane discloses wherein the TLV further comprises a service sub-TLV that contains a service identifier (ID) (Mack-Crane [0010;0033] when a sub-type-length-value (sub-TLV) is advertised, it comprises a shared tree field that indicates a Backbone Service Instance Identifier (I-SID) endpoint which uses a shared tree for multicast frames, and a tie-break mask that indicates the shared tree used for the I-SID endpoint. A multicast advertising sub-TLV 300 may comprise a type element 310, a length element 312, a Backbone Media Access Control (B-MAC) address 314, a reserved element 316, base Virtual LAN identifier (VID) 318, and a plurality of Backbone Service Instance Identifier (I-SID) tuples 320).
One of ordinary skill would have been motivated to combine the teachings of Dutta, Yong and Mack-Crane because these teachings are from the same field of endeavor with respect to techniques for effectively routing multicast traffic.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Mack-Crane into the method by Dutta and Yong, thereby enabling the selection of a first multicast routing mode from a plurality of multicast routing modes supported by a network comprising the network component, assign the first multicast routing mode to a first multicast flow, and advertise a first information frame to a first plurality of nodes, wherein the first information frame provides the assignment of the first multicast routing mode to the first multicast flow, Mack-Crane, [Abstract].
Regarding claim(s) 24, the claim(s) is/are rejected with rational similar to that of claim(s) 11.
Claim(s) 12 and 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dutta (US 2020/0344162 A1), in view of Yong (US 2014/0086253 A1), further in view of Wang et al. (US 2017/0302547 A1).
Regarding claim 12, Dutta modified by Yong disclose the method of claim 1, wherein the TLV further comprises a path identifier sub-TLV that contains a sub-domain identifier (sub-domain-id) field (Subdomain-id=the SD), a bit forwarding ingress router identifier (BFIR-id) field, (Dutta [00302; 0307] discloses a H-BIER info Sub-TLV carries Subdomain-id=the SD where the BFR resides. [0124;0222;0224] H-BIER also carries a BIFT-id is used to identify a bit index forwarding table (BIFT) corresponding to combination of a subdomain and a set. In H-BIER, the BIFT-id identifies that it is an H-BIER packet and thus distinguishes itself from the conventional BIER packets).
Dutta modified by Yong did not disclose a tunnel identifier (ID), and a path number field.
Wang discloses a tunnel identifier (ID), and a path number field (Wang, fig. 3B, [0014; 0056 and 0069] discloses aggregated port information that is carried in a Sub-TLV. The information carried in the Sub-TLV include an extended tunnel ID and a path identifier).
One of ordinary skill would have been motivated to combine the teachings of Dutta, Yong and Wang because these teachings are from the same field of endeavor with respect to routing packets using Sub-TLV value encoded in header of a packet.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Wang into the method by Dutta and Yong, thereby enabling performing bidirectional forwarding detection (BFD) on an aggregated link between a first network device and a second network device, Wang, [Abstract].
Regarding claim(s) 25, the claim(s) is/are rejected with rational similar to that of claim(s) 12.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following publications show the state of the art related to border gateway protocol (BGP) and control a Bit Index Explicit Replication Traffic/Tree Engineering (BIER- TE) domain,
Shepherd et al. (US 2015/0131660 A1)
Chen (US 2019/0116114 A1)
Wijnands et al. (US 2015/0078378 A1)
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 DIXON F DABIPI whose telephone number is (571)270-3673. The examiner can normally be reached on Monday - Friday from 9:00 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher L Parry, can be reached at telephone number 571-272-8328. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/D.F.D/ Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451