DETAILED ACTION
This office action is a response to an amendment filed on 09/03/2026.
Response to Amendment
The Amendment filed on 09/03/2026 has been entered.
Claims 1-6, 8-16 and 18-22 are pending
Claims 1-3, 6, 8, 11-13, 16, and 18 are amended
Claims 7 and 17 are canceled
Claims 21-22 are new
Claims 1-6, 8-16 and 18-22 remain rejected.
Specification
The disclosure is objected to because of the following informalities (and appropriate corrections are required):
In Para. [0048-0049], the instant specification recites, “PQ node or PQ router.” However, the “PQ” is in an abbreviation form and has not been followed by the full explanation of the term and needs to be clarified and defined within the specification.
Appropriate correction is required.
Claim Objections
Claims 21 and 22 are objected to because of the following informalities:
Claims 21 and 22 recite, “PQ”, which is in an abbreviation form and which have not been followed by the full explanation of the term and need to be clarified and defined within the claims.
Appropriate correction is required.
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 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 of this title, 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 1-6, 8-10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (US 20060159009 A1), hereinafter referenced as Kim, in view of Atlas et al. (US 8958286 B1), hereinafter referenced as Atlas, and further in view of Liam Casey (US 20030142674 A1), hereinafter referenced as Casey.
Regarding claim 1, Kim teaches a router, comprising: a processing system including a processor; and a memory that stores executable instructions that, when executed by the processing system, facilitate performance of operations (Para. [0003]-Kim discloses a fast rerouting apparatus and method of an MPLS multicast packet for rapidly coping with a failure generated when the MPLS multicast packet is transmitted. Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP is required. Fig. 1, Para. [0011]-Kim discloses the fast rerouting apparatus comprises: a message sender for sending and receiving a message to and from an upstream or downstream node; a message processor for, when a path requested for routing through a routing request message from the upstream node is a path to perform fast rerouting, sending a routing request message for establishing a next hop database (NHDB) to the downstream node through the message sender, and establishing the NHDB using information included in a response message received from the downstream node; and a storage for storing the established NHDB), the operations comprising:
receiving a point-to-multipoint dataflow comprising a plurality of packets (Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP. Fig. 10, Para. [0076]-Kim discloses to notify information of a downstream router participating in establishing a point-to-multipoint LSP for an upstream router. Para. [0053]-Kim discloses packets are transmitted on the network using the labels ..., the label is transmitted along R4.fwdarw.R3.fwdarw.R2, or R4.fwdarw.R7.fwdarw.R6.fwdarw.R2. Fig. 1, Para. [0038]-Kim discloses a router sending a packet to the reference router is called "upstream router," and router receiving a packet from the reference router is called "downstream router.");
forwarding, to a data network, packets of the point-to-multipoint dataflow for communication to a plurality of point-to-multipoint receivers along respective Label Switched Paths (Para. [0006]-Kim discloses two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP. Fig. 10, Para. [0076]-Kim discloses to notify information of a downstream router participating in establishing a point-to-multipoint LSP for an upstream router. Para. [0053]-Kim discloses packets are transmitted on the network using the labels ..., the label is transmitted along R4.fwdarw.R3.fwdarw.R2, or R4.fwdarw.R7.fwdarw.R6.fwdarw.R2. Fig. 1, Para. [0038]-Kim discloses a router sending a packet to the reference router is called "upstream router," and router receiving a packet from the reference router is called "downstream router.");
identifying a network failure between the router and a nexthop router for one Label Switched Path (Fig. 14, Para. [[0109]-Kim discloses when R2 detects a failure of the network, R2 notifies R6 that the failure occurs in order to transmit packets to the backup LSP. The failure can be detected through exchange of a Hello message between routers. A Unicast Backup LSP (Label Switched Path) Request object is used, wherein an "F" flag should be set);
routing packets of the point-to-multipoint dataflow according to a preexisting unicast backup Label Switched Path for the one Label Switched Path (Fig. 14, Para. [[0109]-Kim discloses when R2 detects a failure of the network, R2 notifies R6 that the failure occurs in order to transmit packets to the backup LSP. The failure can be detected through exchange of a Hello message between routers. A Unicast Backup LSP (Label Switched Path) Request object is used, wherein an "F" flag should be set);
receiving subsequent packets of the point-to-multipoint dataflow (Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur {EXAMINER'S REEMARKS: Corressponding to packet trasmission after convergence}, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets);
unicast transport label to a packet label stack (Para. [0033-0035]-Kim discloses MPLS (Multi-Protocol Label Switching) unicast {EXAMINER'S REMARKS: Corresponding to the referenced unicast transport label} to thereby be applied to MPLS multicast ... For the MPLS fast rerouting, the backup LSP is established at a position where an original LSP can be branched off in order to protect any link or node at which a failure may occur. The original LSP is called "protected LSP," and the LSP established for use as a rerouting path is called "backup path." The MPLS fast rerouting makes use of an MPLS label stack, and the backup LSP may cross the protected LSP.),
subsequently, forwarding received packets to the point-to-multipoint receivers according to the update (Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets).
Kim fails to explicitly teach determining that the data network has reconverged following the network failure; receiving new unicast primary routes based on a reconvergence of the data network; … adding a unicast transport label to a packet label stack of the subsequent packets, … receiving an update to a multicast Label Distribution Protocol tree for routing the plurality of packets in the data network, … the update based on the reconvergence of the data network.
However, Atlas teaches determining that the data network has reconverged following the network failure (Col. 18, Lines [43-44]-Atlas discloses source node 12B determines that the network has converged (e.g., based on signaling or a time-out));
receiving new unicast primary routes based on a reconvergence of the data network (Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure);
receiving subsequent packets of the point-to-multipoint dataflow (Fig. 10, Col. 28, Lines [7-10]-Atlas discloses to forward the packet into Area 304 instead of area 302; this is what would occur after convergence in area 302 when node 306C sends IP packets on the SPT towards ABR 310A);
adding a unicast transport label to a packet label stack of the subsequent packets (Col. 31, Lines [40-42]-Atlas discloses PLR tunnels the multicast traffic in unicast (either IP or LDP), where the outer IP address or LDP label {EXAMINER'S REMARKS: Corresponding to the referenced unicast transport label} indicates that MP and the appropriate topology. Col. 14, Lines [36-48]-Atlas discloses LDP module 116D uses the label-stacking ability of multi-protocol label switching (MPLS) {EXAMINER'S REMARKS: Corresponding to a transport label} ... When receiving a packet with a topology-id label, LDP module 116D pops the topology-id label and uses the topology-id label to guide the next-hop selection in combination with the next label in the stack. For example, LDP module 116D does a lookup within FIB 114 on the next inner label or the IP address of the packet (in the case of IP), and that lookup returns a set of sets of next-hops. Fig. 10, Col. 28, Lines [7-10]-Atlas discloses to forward the packet into Area 304 instead of area 302; this is what would occur after convergence in area 302 when node 306C sends IP packets on the SPT towards ABR 310A),
receiving an update to a multicast Label Distribution Protocol tree for routing the plurality of packets in the data network (Col. 12, Lines [36-41 and 58-66]-Atlas discloses routing component 104 periodically updates RIB 110 to accurately reflect the topology of the network and other entities. RIB 110 may describe a topology of the computer network in which network device 100 resides, and may also include routes through the shared trees in the computer network ... routing protocols 116 include ..., and Label Distribution Protocol (LDP) 116D, for exchanging routing information with other routing devices and for updating RIB {Rounting Information Base} 110. In addition, routing protocols 116 include Multicast Label Distribution Protocol (mLDP) 116E and Protocol Independent Multicast (PIM) 116N for routing traffic through a computer network with other routing devices conceptually formed into shared multicast trees. Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure),
the update based on the reconvergence of the data network (Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure. Col. 18, Lines [38-47]-Atlas discloses after calculation of the primary and alternate next-hops is completed (176), source node 12B will handle other messages received from neighbor devices (178), e.g., routing updates. Source node 12B begins forwarding subsequently received packets using the new primary next-hop (180). Once source node 12B determines that the network has converged (e.g., based on signaling or a time-out), and so it can reasonably be assumed that the network traffic is no longer being carried on the MRT, then source node 12B installs the new MRT next-hops).
Kim and Atlas are both considered to be analogous to the claimed invention because they are in the same field of computer networks, dealing with forwarding network traffic within computer networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim to incorporate the teachings of Atlas on network reconvergence and unicast routes, with a motivation for receiving unicast routes upon reconvergence, and guarantee Internet Protocol (IP) and Label Distribution Protocol (LDP) fast reroute for unicast and multicast traffic, (Atlas, Col. 2, Lines [7-9]).
Kim fails to explicitly teach the unicast transport label is associated with the nexthop router.
However, Casey teaches adding a unicast transport label to a packet label stack of the subsequent packets (Para. [0077]-Casey discloses if it is a unicast packet ... then use the SET label to index into the SET to Core (S2C) Label Mapping to retrieve the new label stack and outgoing core i/f. Swap service labels, add transport label and forward over the outgoing i/f currently associated with the transport LSP),
the unicast transport label is associated with the nexthop router (Figs. 3-6, Para. [0077]-Casey discloses if it is a unicast packet (SET dest. MAC address is that of Core-PE and the SET label has a valid value in the low order bits) then use the SET label to index into the SET to Core (S2C) Label Mapping to retrieve the new label stack and outgoing core i/f. Swap service labels, add transport label and forward over the outgoing i/f currently associated with the transport LSP).
Casey is considered to be analogous because it is in the same field of communication networks, dealing with multi-protocol label switching label control.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim in view of Atlas to incorporate the teachings of Casey on unicast transport label (UTL), with a motivation to add UTL to a packet label stack, and guarantee improved label control, (Casy, Para. [0009]).
Claims 11-16, 19-20 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (US 20060159009 A1), hereinafter referenced as Kim, in view of Atlas et al. (US 8958286 B1), hereinafter referenced as Atlas, and further in view of Liam Casey (US 20030142674 A1), hereinafter referenced as Casey, and further in view of Wijnands et al. (US 20150078378 A1), hereinafter referenced as Wijnands.
Regarding claim 11, Kim teaches a non-transitory machine-readable medium, comprising executable instructions that, when executed by a processing system including a processor, facilitate performance of operations (Para. [0003]-Kim discloses a fast rerouting apparatus and method of an MPLS multicast packet for rapidly coping with a failure generated when the MPLS multicast packet is transmitted. Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP is required. Fig. 1, Para. [0011]-Kim discloses the fast rerouting apparatus comprises: a message sender for sending and receiving a message to and from an upstream or downstream node; a message processor for, when a path requested for routing through a routing request message from the upstream node is a path to perform fast rerouting, sending a routing request message for establishing a next hop database (NHDB) to the downstream node through the message sender, and establishing the NHDB using information included in a response message received from the downstream node; and a storage for storing the established NHDB), the operations comprising:
receiving, at a router forming an ingress router in a point-to-multipoint network, a point-to-multipoint dataflow comprising a plurality of packets (Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP. Fig. 10, Para. [0076]-Kim discloses to notify information of a downstream router participating in establishing a point-to-multipoint LSP for an upstream router. Para. [0053]-Kim discloses packets are transmitted on the network using the labels ..., the label is transmitted along R4.fwdarw.R3.fwdarw.R2, or R4.fwdarw.R7.fwdarw.R6.fwdarw.R2. Fig. 1, Para. [0038]-Kim discloses a router sending a packet to the reference router is called "upstream router," and router receiving a packet from the reference router is called "downstream router.");
forwarding, to a data network, packets of the point-to-multipoint dataflow for communication to a plurality of point-to-multipoint receivers along respective Label Switched Paths (Para. [0006]-Kim discloses two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP. Fig. 10, Para. [0076]-Kim discloses to notify information of a downstream router participating in establishing a point-to-multipoint LSP for an upstream router. Para. [0053]-Kim discloses packets are transmitted on the network using the labels ..., the label is transmitted along R4.fwdarw.R3.fwdarw.R2, or R4.fwdarw.R7.fwdarw.R6.fwdarw.R2. Fig. 1, Para. [0038]-Kim discloses a router sending a packet to the reference router is called "upstream router," and router receiving a packet from the reference router is called "downstream router."),
identifying a network failure between the router and a nexthop router for one Label Switched Path (Fig. 14, Para. [[0109]-Kim discloses when R2 detects a failure of the network, R2 notifies R6 that the failure occurs in order to transmit packets to the backup LSP. The failure can be detected through exchange of a Hello message between routers. A Unicast Backup LSP (Label Switched Path) Request object is used, wherein an "F" flag should be set);
routing packets of the point-to-multipoint dataflow according to a preexisting unicast backup Label Switched Path for the one Label Switched Path (Fig. 14, Para. [[0109]-Kim discloses when R2 detects a failure of the network, R2 notifies R6 that the failure occurs in order to transmit packets to the backup LSP. The failure can be detected through exchange of a Hello message between routers. A Unicast Backup LSP (Label Switched Path) Request object is used, wherein an "F" flag should be set);
receiving subsequent packets of the point-to-multipoint dataflow (Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur {EXAMINER'S REEMARKS: Corressponding to packet trasmission after convergence}, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets);
unicast transport label to a packet label stack (Para. [0033-0035]-Kim discloses MPLS (Multi-Protocol Label Switching) unicast {EXAMINER'S REMARKS: Corresponding to the referenced unicast transport label} to thereby be applied to MPLS multicast ... For the MPLS fast rerouting, the backup LSP is established at a position where an original LSP can be branched off in order to protect any link or node at which a failure may occur. The original LSP is called "protected LSP," and the LSP established for use as a rerouting path is called "backup path." The MPLS fast rerouting makes use of an MPLS label stack, and the backup LSP may cross the protected LSP).
Kim fails to explicitly teach the plurality of point-to-multipoint receivers associated with one or more egress nodes of the point-to-multipoint network; … determining that the data network has reconverged following the network failure; receiving new unicast primary routes based on a reconvergence of the data network; … adding a unicast transport label to a packet label stack of the subsequent packets.
However, Atlas teaches the plurality of point-to-multipoint receivers associated with one or more egress nodes of the point-to-multipoint network (Fig. 5, Col. 34, Lines [2-6]-Atlas discloses multiple P2MP {Point-to-Multipoint} Child Data Objects could be included in a P2MP Label Mapping. In some examples, only those specified in the most recently received P2MP Label Mapping should be stored and used by mLDP 116E of network device 100. Col. 15, Lines [27-34]-Atlas discloses for IP unicast traffic, tunneling may be used. The tunnel egress could be the original destination in the area, the next-next-hop, etc. If the tunnel egress is the original destination router, then the traffic remains on the redundant tree with sub-optimal routing. If the tunnel egress is the next-next-hop, then protection of multi-homed prefixes and node-failure for ABRs is not available. Selection of the tunnel egress is a router-local decision. Col. 36, Lines [29-33]-Atlas discloses if the multicast traffic is PIM, then nodes 432, 434 may mark packets so that the packets self-identify the P2MP tree to which the traffic belongs, i.e., identify which blue/red MRT P2MP tree the packets are part of);
determining that the data network has reconverged following the network failure (Col. 18, Lines [43-44]-Atlas discloses source node 12B determines that the network has converged (e.g., based on signaling or a time-out));
receiving new unicast primary routes based on a reconvergence of the data network (Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure);
receiving subsequent packets of the point-to-multipoint dataflow (Fig. 10, Col. 28, Lines [7-10]-Atlas discloses to forward the packet into Area 304 instead of area 302; this is what would occur after convergence in area 302 when node 306C sends IP packets on the SPT towards ABR 310A);
adding a unicast transport label to a packet label stack of the subsequent packets (Col. 31, Lines [40-42]-Atlas discloses PLR tunnels the multicast traffic in unicast (either IP or LDP), where the outer IP address or LDP label {EXAMINER'S REMARKS: Corresponding to the referenced unicast transport label} indicates that MP and the appropriate topology. Col. 14, Lines [36-48]-Atlas discloses LDP module 116D uses the label-stacking ability of multi-protocol label switching (MPLS) {EXAMINER'S REMARKS: Corresponding to a transport label} ... When receiving a packet with a topology-id label, LDP module 116D pops the topology-id label and uses the topology-id label to guide the next-hop selection in combination with the next label in the stack. For example, LDP module 116D does a lookup within FIB 114 on the next inner label or the IP address of the packet (in the case of IP), and that lookup returns a set of sets of next-hops. Fig. 10, Col. 28, Lines [7-10]-Atlas discloses to forward the packet into Area 304 instead of area 302; this is what would occur after convergence in area 302 when node 306C sends IP packets on the SPT towards ABR 310A).
Kim and Atlas are both considered to be analogous to the claimed invention because they are in the same field of computer networks, dealing with forwarding network traffic within computer networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim to incorporate the teachings of Atlas on network reconvergence, unicast and egress routes, with a motivation for receiving unicast routes upon reconvergence, and guarantee Internet Protocol (IP) and Label Distribution Protocol (LDP) fast reroute for unicast and multicast traffic, (Atlas, Col. 2, Lines [7-9]).
Kim fails to explicitly teach the unicast transport label is associated with the nexthop router.
However, Casey teaches adding a unicast transport label to a packet label stack of the subsequent packets (Para. [0077]-Casey discloses if it is a unicast packet ... then use the SET label to index into the SET to Core (S2C) Label Mapping to retrieve the new label stack and outgoing core i/f. Swap service labels, add transport label and forward over the outgoing i/f currently associated with the transport LSP),
the unicast transport label is associated with the nexthop router (Figs. 3-6, Para. [0077]-Casey discloses if it is a unicast packet (SET dest. MAC address is that of Core-PE and the SET label has a valid value in the low order bits) then use the SET label to index into the SET to Core (S2C) Label Mapping to retrieve the new label stack and outgoing core i/f. Swap service labels, add transport label and forward over the outgoing i/f currently associated with the transport LSP).
Casey is considered to be analogous because it is in the same field of communication networks, dealing with multi-protocol label switching label control.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim in view of Atlas to incorporate the teachings of Casey on unicast transport label (UTL), with a motivation to add UTL to a packet label stack, and guarantee improved label control, (Casy, Para. [0009]).
Kim fails to explicitly teach determining that an update has been received for an Incoming Label Map (ILM) or a Forwarding Table Next (FTN) corresponding to a multicast Label Distribution Protocol tree for the point-to-multipoint dataflow; and responsive to the determining that the update has been received for the ILM or the FTN, stopping the adding of the unicast transport label to the packet label stack of the subsequent packets.
However, Wijnands teaches determining that an update has been received for an Incoming Label Map (ILM) or a Forwarding Table Next (FTN) corresponding to a multicast Label Distribution Protocol tree for the point-to-multipoint dataflow (Para. [0114-0117]-Wijnands discloses multicast data packet is forwarded along the P2P LSP using unicast MPLS ... BIER-enabled nodes can forward multicast data packets using inherently loop-free topologies ... example of such a loop-free topology is a point-to-multipoint label switched path (P2MP LSP). Para. [0104]-Wijnands discloses BIER-enabled node then updates the copy of the multicast data packet by removing the multicast data packet's top label (e.g., the label that was on top of the multicast data packet's MPLS label stack when the packet was received by the BIER-enabled node). Para. [0037-0039]-Wijnands discloses the multicast forwarding table includes information identifying each interface of multicast-enabled node 110 that is connected to a multicast distribution tree (MDT) to one or more receivers for the multicast group ... the process traditionally used in multicast of setting up MDTs and updating multicast forwarding tables for each group results in considerable amounts of state information within the network); and
responsive to the determining that the update has been received for the ILM or the FTN, stopping the adding of the unicast transport label to the packet label stack of the subsequent packets (Para. [0114-0117]-Wijnands discloses multicast data packet is forwarded along the P2P LSP using unicast MPLS ... BIER-enabled nodes can forward multicast data packets using inherently loop-free topologies ... example of such a loop-free topology is a point-to-multipoint label switched path (P2MP LSP). Para. [0104]-Wijnands discloses BIER-enabled node then updates the copy of the multicast data packet by removing the multicast data packet's top label (e.g., the label that was on top of the multicast data packet's MPLS label stack when the packet was received by the BIER-enabled node). Para. [0037-0039]-Wijnands discloses the multicast forwarding table includes information identifying each interface of multicast-enabled node 110 that is connected to a multicast distribution tree (MDT) to one or more receivers for the multicast group ... the process traditionally used in multicast of setting up MDTs and updating multicast forwarding tables for each group results in considerable amounts of state information within the network).
Wijnands is considered to be analogous because it is in the same field of communication networks, dealing with Multiprotocol Label Switching.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim in view of Atlas and Casey to incorporate the teachings of Wijnands on MLDP tree, with a motivation to stop unicast transport label upon receiving updates for incoming label map, and guarantee improved network performance, (Wijnands, Para. [0003]).
Regarding claim 2, Kim, in view of Atlas and Casey, teaches the router of claim 1,
Kim further teaches pushing a point-to-multipoint label associated with the nexthop router onto a label stack of a received packet of the point-to-multipoint dataflow to forward the received packet of the point-to-multipoint dataflow (Fig. 5, Para. [0055-0057]-Kim discloses R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets. Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP. Fig. 10, Para. [0076]-Kim discloses to notify information of a downstream router participating in establishing a point-to-multipoint LSP for an upstream router);
prior to the determining that the data network has reconverged, and responsive to the identifying the network failure, pushing a backup label associated with the preexisting unicast backup Label Switched Path onto the label stack of the received packet (Fig. 1, Para. [0039]-Kim discloses when a failure occurs between R2 and R3, R2 sends a packet, which is to be sent through R3, to R6 in order to send it through the backup LSP. At this time, R2 allocates an Inbound label allocated by R4 of the protected LSP and pushes a label for the backup LSP. Fig. 11, Para. [0027]-Kim discloses format of a Unicast Backup LSP Request object of a signaling protocol according to the present invention. Para. [0007-0008]-Kim discloses a failure that occurs on a network is restored by establishing a new LSP to replace the LSP where the failure occurs at the router and then transmitting a packet to be transmitted through the LSP where the failure occurs through the newly established LSP ... The fast rerouting sets up the backup LSP before any failure occurs, and when the failure occurs on a network, redirects a packet to the closest location from a location where the failure occurs. Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets).
Regarding claim 3, Kim, in view of Atlas and Casey, teaches the router of claim 2,
Kim further teaches responsive to the identifying the network failure, pushing a backup label associated with the preexisting unicast backup Label Switched Path onto a label stack of the received packet (Figs. 2-3 and 5, Para. [0055-0057]-Kim discloses transmission of a packet on a network to which the MPLS fast rerouting ... R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets ... this fast rerouting applied to MPLS unicast is applied to MPLS multicast),
the preexisting unicast backup Label Switched Path forming a protection path to the nexthop router for use during the network failure (Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6); and
prior to the determining that the data network has reconverged, forwarding the received packet according to the backup label (Para. [0006]-Kim discloses two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6. Para. [0007-0008]-Kim discloses a failure that occurs on a network is restored by establishing a new LSP to replace the LSP where the failure occurs at the router and then transmitting a packet to be transmitted through the LSP where the failure occurs through the newly established LSP ... The fast rerouting sets up the backup LSP before any failure occurs, and when the failure occurs on a network, redirects a packet to the closest location from a location where the failure occurs. Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets).
Regarding claim 4, Kim, in view of Atlas and Casey, teaches the router of claim 3,
Kim further teaches the pushing the backup label onto the label stack of the received packet comprises: pushing a backup label operative to forward the received packet to the nexthop router over the protection path to the nexthop router (Fig. 13, Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6),
the nexthop router is responsive to receiving the packets of the point-to-multipoint dataflow, including the received packet, for communication to designated point-to-multipoint receivers along the respective Label Switched Paths (Fig. 13, Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6. Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP. Fig. 10, Para. [0076]-Kim discloses to notify information of a downstream router participating in establishing a point-to-multipoint LSP for an upstream router).
Regarding claim 5, Kim, in view of Atlas and Casey, teaches the router of claim 4,
Kim further teaches the pushing the backup label onto the label stack of the received packet comprises: pushing a backup label operative to forward the received packet to the nexthop router over the protection path to the nexthop router (Fig. 13, Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6),
the nexthop router is responsive to receiving the packets of the point-to-multipoint dataflow to pop the backup label from a label stack of the packets of the point-to-multipoint dataflow and to forward the packets of the point-to-multipoint dataflow according to a point-to-multipoint label associated with the designated point-to-multipoint receivers along the respective Label Switched Paths (Fig. 5, Para. [0056]-Kim discloses R6 swaps label 17 for label 22 to transmit the packet to the next node in the protected LSP, router R7. If penultimate-hop-popping is used, R7 transmits a packet, that is received from R6, to the merge point, R4, after it pops the label 22 from the packet ... If penultimate-hop-popping is not used, R4 will pop the bypass tunnel's label and examine the label underneath to determine the path that the packet is to follow. Fig. 13, Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6).
Regarding claim 6, Kim, in view of Atlas and Casey, teaches the router of claim 3,
Kim further teaches receiving additional packets of the of the point-to-multipoint dataflow (Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP. Fig. 10, Para. [0076]-Kim discloses to notify information of a downstream router participating in establishing a point-to-multipoint LSP for an upstream router. Para. [0053]-Kim discloses packets are transmitted on the network using the labels ..., the label is transmitted along R4.fwdarw.R3.fwdarw.R2, or R4.fwdarw.R7.fwdarw.R6.fwdarw.R2. Fig. 1, Para. [0038]-Kim discloses a router sending a packet to the reference router is called "upstream router," and router receiving a packet from the reference router is called "downstream router");
forwarding the additional packets according to the backup label until the data network has reconverged following the network failure (Para. [0007-0008]-Kim discloses a failure that occurs on a network is restored by establishing a new LSP to replace the LSP where the failure occurs at the router and then transmitting a packet to be transmitted through the LSP where the failure occurs through the newly established LSP ... The fast rerouting sets up the backup LSP before any failure occurs, and when the failure occurs on a network, redirects a packet to the closest location from a location where the failure occurs. Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets);
receiving subsequent packets of the point-to-multipoint dataflow (Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur {EXAMINER'S REEMARKS: Corressponding to packet trasmission after convergence}, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets); and
adding of the unicast transport label (Para. [0033-0035]-Kim discloses MPLS (Multi-Protocol Label Switching) unicast {EXAMINER'S REMARKS: Corresponding to the referenced unicast transport label} to thereby be applied to MPLS multicast ... For the MPLS fast rerouting, the backup LSP is established at a position where an original LSP can be branched off in order to protect any link or node at which a failure may occur. The original LSP is called "protected LSP," and the LSP established for use as a rerouting path is called "backup path." The MPLS fast rerouting makes use of an MPLS label stack, and the backup LSP may cross the protected LSP).
Kim fails to explicitly teach responsive to the determining that the data network has reconverged, performing the adding of the unicast transport label to the packet label stack of the subsequent packets.
However, Atlas teaches receiving subsequent packets of the point-to-multipoint dataflow (Fig. 10, Col. 28, Lines [7-10]-Atlas discloses to forward the packet into Area 304 instead of area 302; this is what would occur after convergence in area 302 when node 306C sends IP packets on the SPT towards ABR 310A);
responsive to the determining that the data network has reconverged, performing the adding of the unicast transport label to the packet label stack of the subsequent packets (Col. 31, Lines [40-42]-Atlas discloses PLR tunnels the multicast traffic in unicast (either IP or LDP), where the outer IP address or LDP label {EXAMINER'S REMARKS: Corresponding to the referenced unicast transport label} indicates that MP and the appropriate topology. Col. 14, Lines [36-48]-Atlas discloses LDP module 116D uses the label-stacking ability of multi-protocol label switching (MPLS) {EXAMINER'S REMARKS: Corresponding to a transport label} ... When receiving a packet with a topology-id label, LDP module 116D pops the topology-id label and uses the topology-id label to guide the next-hop selection in combination with the next label in the stack. For example, LDP module 116D does a lookup within FIB 114 on the next inner label or the IP address of the packet (in the case of IP), and that lookup returns a set of sets of next-hops. Fig. 10, Col. 28, Lines [7-10]-Atlas discloses to forward the packet into Area 304 instead of area 302; this is what would occur after convergence in area 302 when node 306C sends IP packets on the SPT towards ABR 310A).
Kim and Atlas are both considered to be analogous to the claimed invention because they are in the same field of computer networks, dealing with forwarding network traffic within computer networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim in view of Casey to incorporate the teachings of Atlas on network reconvergence and unicast routes, with a motivation for receiving unicast routes upon reconvergence, and guarantee Internet Protocol (IP) and Label Distribution Protocol (LDP) fast reroute for unicast and multicast traffic, (Atlas, Col. 2, Lines [7-9]).
Casey also further teaches performing the adding of the unicast transport label to the packet label stack of the subsequent packets (Figs. 3-6, Para. [0077]-Casey discloses if it is a unicast packet (SET dest. MAC address is that of Core-PE and the SET label has a valid value in the low order bits) then use the SET label to index into the SET to Core (S2C) Label Mapping to retrieve the new label stack and outgoing core i/f. Swap service labels, add transport label and forward over the outgoing i/f currently associated with the transport LSP).
Casey is considered to be analogous because it is in the same field of communication networks, dealing with multi-protocol label switching label control.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim in view of Atlas to incorporate the teachings of Casey on unicast transport label (UTL), with a motivation to add UTL to a packet label stack, and guarantee improved label control, (Casy, Para. [0009]).
Regarding claim 8, Kim, in view of Atlas and Casey, in view of Atlas and Casey teaches the router of claim 1,
Kim further teaches subsequently, forwarding received packets to the point-to-multipoint receivers according to the update (Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets).
Kim fails to teach receiving an update to a multicast Label Distribution Protocol tree for routing the plurality of packets in the data network, the update based on the reconvergence of the data network.
However, Atlas teaches receiving an update to a multicast Label Distribution Protocol tree for routing the plurality of packets in the data network (Col. 12, Lines [36-41 and 58-66]-Atlas discloses routing component 104 periodically updates RIB 110 to accurately reflect the topology of the network and other entities. RIB 110 may describe a topology of the computer network in which network device 100 resides, and may also include routes through the shared trees in the computer network ... routing protocols 116 include ..., and Label Distribution Protocol (LDP) 116D, for exchanging routing information with other routing devices and for updating RIB {Routing Information Base} 110. In addition, routing protocols 116 include Multicast Label Distribution Protocol (mLDP) 116E and Protocol Independent Multicast (PIM) 116N for routing traffic through a computer network with other routing devices conceptually formed into shared multicast trees. Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure);
the update based on the reconvergence of the data network (Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure. Col. 18, Lines [38-47]-Atlas discloses after calculation of the primary and alternate next-hops is completed (176), source node 12B will handle other messages received from neighbor devices (178), e.g., routing updates. Source node 12B begins forwarding subsequently received packets using the new primary next-hop (180). Once source node 12B determines that the network has converged (e.g., based on signaling or a time-out), and so it can reasonably be assumed that the network traffic is no longer being carried on the MRT, then source node 12B installs the new MRT next-hops).
Atlas is considered to be analogous because it is in the same field of computer networks, dealing with forwarding network traffic within computer networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim in view of Casey to incorporate the teachings of Atlas on multicast Label Distribution Protocol (mLDP) tree, with a motivation to update mLDP, and guarantee restoring a failure occurring on a multiprotocol label switching (MPLS) network, (Kim, Para. [0003).
Regarding claim 9, Kim, in view of Atlas and Casey, teaches the router of claim 1,
Kim further teaches identifying the preexisting unicast backup Label Switched Path for the one Label Switched Path (Para. [0091]-Kim discloses setting up an existing unicast LSP is performed at each router. When requested to set up the unicast backup LSP, R6 selects ERs (Explicit Routes) to set up the unicast backup LSP with reference to the NHDB. Para. [0079]-Kim discloses Unicast Backup LSP Request object is used when another router of a multicast tree is requested to set a unicast LSP. Here, the multicast tree refers to paths used to transmit a multicast packet to hosts belonging to the multicast group).
Kim fails to teach the preexisting unicast backup Label Switched Path is associated with a directly-connected neighbor router that provides a loop free path with respect to the nexthop router.
However, Atlas teaches the preexisting unicast backup Label Switched Path is associated with a directly-connected neighbor router that provides a loop free path with respect to the nexthop router (Col. 32, Lines [4-8]-Atlas discloses each router along the path, including the originating router, determines which of an LFA {Loop Free Alternative}, the Blue MRT or the Red MRT to use for its next-hops. When a router receives a backup join and is not the destination PLR, the router identifies a unicast alternate to the PLR that avoids the failure-candidate node, creates local multicast group state, and forwards the backup join to that alternate's next-hop. Col. 13, Lines [46-65]-Atlas discloses LFA module 122 may compute and select loop-free alternate (LFA) next-hops ... With LFA, there is no need to tunnel unicast traffic, whether IP or LDP. Col. 15, Lines [7-10]-Atlas discloses with LDP unicast forwarding, regardless of whether topology-identification label or encoding topology in label is used, no additional loopbacks per router are required as are required in the IP unicast forwarding case. Col. 15, Lines [37-38]-Atlas discloses a network device 100 may tunnel IP packets via an LDP LSP. Col. 32, Lines [27-28]-Atlas discloses the backup tree may be the merged set of unicast alternates).
Atlas is considered to be analogous because it is in the same field of computer networks, dealing with forwarding network traffic within computer networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim in view of Casey to incorporate the teachings of Atlas on unicast backup Label Switched Path, with a motivation to provide loop-free path, and guarantee restoring a failure occurring on a multiprotocol label switching (MPLS) network, (Kim, Para. [0003).
Regarding claim 10, Kim, in view of Atlas and Casey, teaches the router of claim 1,
Kim fails to teach identifying a remote loop free alternate backup path; and routing packets of the point-to-multipoint dataflow according to the remote loop free alternate backup path.
However, Atlas teaches identifying a remote loop free alternate backup path (Fig. 6, Col. 17, Lines [52-56]-Atlas discloses LFA module 122 of source node 12B may also select a loop-free alternate (LFA) next-hop to use for reaching destination node 12G, for potential use in the event of a failure associated with neighbor node 12D (150). Col. 17, Lines [4-5]-Atlas discloses remote destinations may not be advertising additional IP loopback addresses for the MRTs. Col. 32, Lines [4-8]-Atlas discloses each router along the path, including the originating router, determines which of an LFA {Loop Free Alternative}, the Blue MRT or the Red MRT to use for its next-hops. When a router receives a backup join and is not the destination PLR, the router identifies a unicast alternate to the PLR that avoids the failure-candidate node, creates local multicast group state, and forwards the backup join to that alternate's next-hop. Col. 13, Lines [46-65]-Atlas discloses LFA module 122 may compute and select loop-free alternate (LFA) next-hops ... With LFA, there is no need to tunnel unicast traffic, whether IP or LDP. Col. 15, Lines [7-10]-Atlas discloses with LDP unicast forwarding, regardless of whether topology-identification label or encoding topology in label is used, no additional loopbacks per router are required as are required in the IP unicast forwarding case. Col. 15, Lines [37-38]-Atlas discloses a network device 100 may tunnel IP packets via an LDP LSP. Col. 32, Lines [27-28]-Atlas discloses the backup tree may be the merged set of unicast alternates); and
routing packets of the point-to-multipoint dataflow according to the remote loop free alternate backup path (Fig. 6, Col. 17, Lines [52-56]-Atlas discloses LFA module 122 of source node 12B may also select a loop-free alternate (LFA) next-hop to use for reaching destination node 12G, for potential use in the event of a failure associated with neighbor node 12D (150). Col. 17, Lines [4-13]-Atlas discloses remote destinations may not be advertising additional IP loopback addresses for the MRTs. In that case, a router attached to a proxy-node, which represents destinations outside the local island, must advertise IP addresses associated with that proxy-node. Packets sent to an address associated with a proxy-node will have their outer IP header removed by the router attached to the proxy-node and be forwarded by the router along the outgoing interface on the MRT towards a router outside the local island that was represented by the proxy-node. Col. 32, Lines [4-8]-Atlas discloses each router along the path, including the originating router, determines which of an LFA {Loop Free Alternative}, the Blue MRT or the Red MRT to use for its next-hops. When a router receives a backup join and is not the destination PLR, the router identifies a unicast alternate to the PLR that avoids the failure-candidate node, creates local multicast group state, and forwards the backup join to that alternate's next-hop. Col. 13, Lines [46-65]-Atlas discloses LFA module 122 may compute and select loop-free alternate (LFA) next-hops ... With LFA, there is no need to tunnel unicast traffic, whether IP or LDP. Col. 15, Lines [7-10]-Atlas discloses with LDP unicast forwarding, regardless of whether topology-identification label or encoding topology in label is used, no additional loopbacks per router are required as are required in the IP unicast forwarding case. Col. 15, Lines [37-38]-Atlas discloses a network device 100 may tunnel IP packets via an LDP LSP. Col. 32, Lines [27-28]-Atlas discloses the backup tree may be the merged set of unicast alternates. Claim [11]-Atlas discloses multicast Label Distribution Protocol (mLDP) label map message having a first Point to Multipoint (P2MP) Forwarding Equivalence Class (FEC) element that specifies the first multicast tree using a first multi-topology identifier).
Atlas is considered to be analogous because it is in the same field of computer networks, dealing with forwarding network traffic within computer networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim in view of Casey to incorporate the teachings of Atlas on loop-free alternate backup path, with a motivation to route packets of the point-to-multipoint dataflow, and guarantee restoring a failure occurring on a multiprotocol label switching (MPLS) network, (Kim, Para. [0003).
Regarding claim 12, Kim, in view of Atlas, Casey and Wijnands, teaches the non-transitory machine-readable medium of claim 11,
Kim further teaches pushing a point-to-multipoint label associated with the nexthop router onto a label stack of a received packet of the point-to-multipoint dataflow to forward the received packet of the point-to-multipoint dataflow (Fig. 5, Para. [0055-0057]-Kim discloses R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets. Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP. Fig. 10, Para. [0076]-Kim discloses to notify information of a downstream router participating in establishing a point-to-multipoint LSP for an upstream router); and
responsive to the identifying the network failure, pushing a backup label associated with the preexisting unicast backup Label Switched Path onto the label stack of the received packet (Fig. 1, Para. [0039]-Kim discloses when a failure occurs between R2 and R3, R2 sends a packet, which is to be sent through R3, to R6 in order to send it through the backup LSP. At this time, R2 allocates an Inbound label allocated by R4 of the protected LSP and pushes a label for the backup LSP. Fig. 11, Para. [0027]-Kim discloses format of a Unicast Backup LSP Request object of a signaling protocol according to the present invention).
Regarding claim 13, Kim, in view of Atlas, Casey and Wijnands, teaches the non-transitory machine-readable medium of claim 12,
Kim further teaches responsive to the identifying the network failure, pushing a backup label associated with the preexisting unicast backup Label Switched Path onto a label stack of the received packet (Figs. 2-3 and 5, Para. [0055-0057]-Kim discloses transmission of a packet on a network to which the MPLS fast rerouting ... R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets ... this fast rerouting applied to MPLS unicast is applied to MPLS multicast),
the preexisting unicast backup Label Switched Path forming a protection path to the nexthop router for use during the network failure (Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6); and
forwarding the received packet according to the backup label (Para. [0006]-Kim discloses two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6).
Regarding claim 14, Kim, in view of Atlas, Casey and Wijnands, teaches the non-transitory machine-readable medium of claim 13,
Kim further teaches the pushing the backup label onto the label stack of the received packet comprises: pushing a backup label operative to forward the received packet to the nexthop router over the protection path to the nexthop router (Fig. 13, Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6),
the nexthop router is responsive to receiving the packets of the point-to-multipoint dataflow, including the received packet, for communication to designated point-to-multipoint receivers along the respective Label Switched Paths (Fig. 13, Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6. Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP. Fig. 10, Para. [0076]-Kim discloses to notify information of a downstream router participating in establishing a point-to-multipoint LSP for an upstream router).
Regarding claim 15, Kim in view of Atlas, Casey and Wijnands, teaches the non-transitory machine-readable medium of claim 14,
Kim further teaches the pushing the backup label onto the label stack of the received packet comprises: pushing a backup label operative to forward the received packet to the nexthop router over the protection path to the nexthop router (Fig. 13, Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6),
the nexthop router responsive to receiving the packets of the point-to-multipoint dataflow to pop the backup label from a label stack of the packets of the point-to-multipoint dataflow and to forward the packets of the point-to-multipoint dataflow according to a point-to-multipoint label associated with the designated point-to-multipoint receivers along the respective Label Switched Paths (Fig. 5, Para. [0056]-Kim discloses R6 swaps label 17 for label 22 to transmit the packet to the next node in the protected LSP, router R7. If penultimate-hop-popping is used, R7 transmits a packet, that is received from R6, to the merge point, R4, after it pops the label 22 from the packet ... If penultimate-hop-popping is not used, R4 will pop the bypass tunnel's label and examine the label underneath to determine the path that the packet is to follow. Fig. 13, Para. [0103]-Kim discloses R2 transmits a Path message to R6 based on the selected ER. The Path message transmitted from R2 to R6 includes the same information as the Path message of the protected LSP which is transmitted from R2 to R3, and a Unicast Backup LSP Request object. When R2 receives the Resv message from R6, R2 transmits the Path message for setup of the backup LSP to R6).
Regarding claim 16, Kim in view of Atlas, Casey and Wijnands, teaches the non-transitory machine-readable medium of claim 13,
Kim further teaches receiving additional packets of the of the point-to-multipoint dataflow (Para. [0009]-Kim discloses a new fast rerouting apparatus and method for the MPLS multicast employing a point-to-multipoint LSP. Fig. 10, Para. [0076]-Kim discloses to notify information of a downstream router participating in establishing a point-to-multipoint LSP for an upstream router. Para. [0053]-Kim discloses packets are transmitted on the network using the labels ..., the label is transmitted along R4.fwdarw.R3.fwdarw.R2, or R4.fwdarw.R7.fwdarw.R6.fwdarw.R2. Fig. 1, Para. [0038]-Kim discloses a router sending a packet to the reference router is called "upstream router," and router receiving a packet from the reference router is called "downstream router."); and
forwarding the additional packets according to the backup label until the data network has reconverged following the network failure (Para. [0007-0008]-Kim discloses a failure that occurs on a network is restored by establishing a new LSP to replace the LSP where the failure occurs at the router and then transmitting a packet to be transmitted through the LSP where the failure occurs through the newly established LSP ... The fast rerouting sets up the backup LSP before any failure occurs, and when the failure occurs on a network, redirects a packet to the closest location from a location where the failure occurs. Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets).
Regarding claim 18, Kim in view of Atlas, Casey and Wijnands, teaches the non-transitory machine-readable medium of claim 11,
Kim further teaches subsequently, forwarding received packets to the point-to-multipoint receivers according to the update (Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets).
Kim fails to teach receiving an update to a multicast Label Distribution Protocol tree for routing the plurality of packets in the data network, the update based the reconvergence of the data network.
However, Atlas teaches receiving an update to a multicast Label Distribution Protocol tree for routing the plurality of packets in the data network (Col. 12, Lines [36-41 and 58-66]-Atlas discloses routing component 104 periodically updates RIB 110 to accurately reflect the topology of the network and other entities. RIB 110 may describe a topology of the computer network in which network device 100 resides, and may also include routes through the shared trees in the computer network ... routing protocols 116 include ..., and Label Distribution Protocol (LDP) 116D, for exchanging routing information with other routing devices and for updating RIB {Routing Information Base} 110. In addition, routing protocols 116 include Multicast Label Distribution Protocol (mLDP) 116E and Protocol Independent Multicast (PIM) 116N for routing traffic through a computer network with other routing devices conceptually formed into shared multicast trees. Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure);
the update based the reconvergence of the data network (Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure. Col. 18, Lines [38-47]-Atlas discloses after calculation of the primary and alternate next-hops is completed (176), source node 12B will handle other messages received from neighbor devices (178), e.g., routing updates. Source node 12B begins forwarding subsequently received packets using the new primary next-hop (180). Once source node 12B determines that the network has converged (e.g., based on signaling or a time-out), and so it can reasonably be assumed that the network traffic is no longer being carried on the MRT, then source node 12B installs the new MRT next-hops).
Atlas is considered to be analogous because it is in the same field of computer networks, dealing with forwarding network traffic within computer networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim, in view of Casey and Wijnands, to incorporate the teachings of Atlas on multicast Label Distribution Protocol (mLDP) tree, with a motivation to update mLDP, and guarantee restoring a failure occurring on a multiprotocol label switching (MPLS) network, (Kim, Para. [0003).
Regarding claim 19, Kim in view of Atlas, Casey and Wijnands, teaches the non-transitory machine-readable medium of claim 11,
Kim further teaches identifying the preexisting unicast backup Label Switched Path for the one Label Switched Path (Para. [0091]-Kim discloses setting up an existing unicast LSP is performed at each router. When requested to set up the unicast backup LSP, R6 selects ERs (Explicit Routes) to set up the unicast backup LSP with reference to the NHDB. Para. [0079]-Kim discloses Unicast Backup LSP Request object is used when another router of a multicast tree is requested to set a unicast LSP. Here, the multicast tree refers to paths used to transmit a multicast packet to hosts belonging to the multicast group).
Kim fails to teach the preexisting unicast backup Label Switched Path is associated with a directly-connected neighbor router that provides a loop free path with respect to the nexthop router.
However, Atlas teaches the preexisting unicast backup Label Switched Path is associated with a directly-connected neighbor router that provides a loop free path with respect to the nexthop router (Col. 32, Lines [4-8]-Atlas discloses each router along the path, including the originating router, determines which of an LFA {Loop Free Alternative}, the Blue MRT or the Red MRT to use for its next-hops. When a router receives a backup join and is not the destination PLR, the router identifies a unicast alternate to the PLR that avoids the failure-candidate node, creates local multicast group state, and forwards the backup join to that alternate's next-hop. Col. 13, Lines [46-65]-Atlas discloses LFA module 122 may compute and select loop-free alternate (LFA) next-hops ... With LFA, there is no need to tunnel unicast traffic, whether IP or LDP. Col. 15, Lines [7-10]-Atlas discloses with LDP unicast forwarding, regardless of whether topology-identification label or encoding topology in label is used, no additional loopbacks per router are required as are required in the IP unicast forwarding case. Col. 15, Lines [37-38]-Atlas discloses a network device 100 may tunnel IP packets via an LDP LSP. Col. 32, Lines [27-28]-Atlas discloses the backup tree may be the merged set of unicast alternates).
Atlas is considered to be analogous because it is in the same field of computer networks, dealing with forwarding network traffic within computer networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim, in view of Casey and Wijnands, to incorporate the teachings of Atlas on unicast backup Label Switched Path, with a motivation to provide loop-free path, and guarantee restoring a failure occurring on a multiprotocol label switching (MPLS) network, (Kim, Para. [0003).
Regarding claim 20, Kim in view of Atlas, Casey and Wijnands, teaches the non-transitory machine-readable medium of claim 11,
Kim fails to teach identifying a remote loop free alternate backup path; and routing packets of the point-to-multipoint dataflow according to the remote loop free alternate backup path.
However, Atlas teaches identifying a remote loop free alternate backup path (Col. 17, Lines [4-5]-Atlas discloses remote destinations may not be advertising additional IP loopback addresses for the MRTs. Col. 32, Lines [4-8]-Atlas discloses each router along the path, including the originating router, determines which of an LFA {Loop Free Alternative}, the Blue MRT or the Red MRT to use for its next-hops. When a router receives a backup join and is not the destination PLR, the router identifies a unicast alternate to the PLR that avoids the failure-candidate node, creates local multicast group state, and forwards the backup join to that alternate's next-hop. Col. 13, Lines [46-65]-Atlas discloses LFA module 122 may compute and select loop-free alternate (LFA) next-hops ... With LFA, there is no need to tunnel unicast traffic, whether IP or LDP. Col. 15, Lines [7-10]-Atlas discloses with LDP unicast forwarding, regardless of whether topology-identification label or encoding topology in label is used, no additional loopbacks per router are required as are required in the IP unicast forwarding case. Col. 15, Lines [37-38]-Atlas discloses a network device 100 may tunnel IP packets via an LDP LSP. Col. 32, Lines [27-28]-Atlas discloses the backup tree may be the merged set of unicast alternates); and
routing packets of the point-to-multipoint dataflow according to the remote loop free alternate backup path (Col. 17, Lines [4-13]-Atlas discloses remote destinations may not be advertising additional IP loopback addresses for the MRTs. In that case, a router attached to a proxy-node, which represents destinations outside the local island, must advertise IP addresses associated with that proxy-node. Packets sent to an address associated with a proxy-node will have their outer IP header removed by the router attached to the proxy-node and be forwarded by the router along the outgoing interface on the MRT towards a router outside the local island that was represented by the proxy-node. Col. 32, Lines [4-8]-Atlas discloses each router along the path, including the originating router, determines which of an LFA {Loop Free Alternative}, the Blue MRT or the Red MRT to use for its next-hops. When a router receives a backup join and is not the destination PLR, the router identifies a unicast alternate to the PLR that avoids the failure-candidate node, creates local multicast group state, and forwards the backup join to that alternate's next-hop. Col. 13, Lines [46-65]-Atlas discloses LFA module 122 may compute and select loop-free alternate (LFA) next-hops ... With LFA, there is no need to tunnel unicast traffic, whether IP or LDP. Col. 15, Lines [7-10]-Atlas discloses with LDP unicast forwarding, regardless of whether topology-identification label or encoding topology in label is used, no additional loopbacks per router are required as are required in the IP unicast forwarding case. Col. 15, Lines [37-38]-Atlas discloses a network device 100 may tunnel IP packets via an LDP LSP. Col. 32, Lines [27-28]-Atlas discloses the backup tree may be the merged set of unicast alternates).
Atlas is considered to be analogous because it is in the same field of computer networks, dealing with forwarding network traffic within computer networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim, in view of Casey and Wijnands, to incorporate the teachings of Atlas on loop-free alternate backup path, with a motivation to route packets of the point-to-multipoint dataflow, and guarantee restoring a failure occurring on a multiprotocol label switching (MPLS) network, (Kim, Para. [0003).
Regarding claims 21 and 22, Kim in view of Atlas and Casey teaches the router of claim 1, while Kim in view of Atlas, Casey and Wijnands teaches the non-transitory machine-readable medium of claim 11 respectively,
Kim fails to teach responsive to the identifying the network failure, determining that the preexisting unicast backup Label Switched Path is a remote loop free alternate backup path; and responsive to the determining that the preexisting unicast backup Label Switched Path is the remote loop free alternate backup path, pushing a first unicast transport label and a second unicast transport label onto a packet label stack of a packet of the point-to-multipoint dataflow to tunnel the packet to a PQ node.
However, Atlas teaches responsive to the identifying the network failure, determining that the preexisting unicast backup Label Switched Path is a remote loop free alternate backup path (Fig. 6, Col. 17, Lines [52-56]-Atlas discloses LFA module 122 of source node 12B may also select a loop-free alternate (LFA) next-hop to use for reaching destination node 12G, for potential use in the event of a failure associated with neighbor node 12D (150). Col. 17, Lines [4-5]-Atlas discloses remote destinations may not be advertising additional IP loopback addresses for the MRTs. Col. 32, Lines [4-8]-Atlas discloses each router along the path, including the originating router, determines which of an LFA {Loop Free Alternative}, the Blue MRT or the Red MRT to use for its next-hops. When a router receives a backup join and is not the destination PLR, the router identifies a unicast alternate to the PLR that avoids the failure-candidate node, creates local multicast group state, and forwards the backup join to that alternate's next-hop. Col. 13, Lines [46-65]-Atlas discloses LFA module 122 may compute and select loop-free alternate (LFA) next-hops ... With LFA, there is no need to tunnel unicast traffic, whether IP or LDP. Col. 15, Lines [7-10]-Atlas discloses with LDP unicast forwarding, regardless of whether topology-identification label or encoding topology in label is used, no additional loopbacks per router are required as are required in the IP unicast forwarding case. Col. 15, Lines [37-38]-Atlas discloses a network device 100 may tunnel IP packets via an LDP LSP. Col. 32, Lines [27-28]-Atlas discloses the backup tree may be the merged set of unicast alternates); and
responsive to the determining that the preexisting unicast backup Label Switched Path is the remote loop free alternate backup path, pushing a first unicast transport label and a second unicast transport label onto a packet label stack of a packet of the point-to-multipoint dataflow to tunnel the packet to a PQ node (Fig. 6, Col. 17, Lines [52-56]-Atlas discloses LFA module 122 of source node 12B may also select a loop-free alternate (LFA) next-hop to use for reaching destination node 12G, for potential use in the event of a failure associated with neighbor node 12D (150). Col. 17, Lines [4-13]-Atlas discloses remote destinations may not be advertising additional IP loopback addresses for the MRTs. In that case, a router attached to a proxy-node, which represents destinations outside the local island, must advertise IP addresses associated with that proxy-node. Packets sent to an address associated with a proxy-node will have their outer IP header removed by the router attached to the proxy-node and be forwarded by the router along the outgoing interface on the MRT towards a router outside the local island that was represented by the proxy-node. Col. 32, Lines [4-8]-Atlas discloses each router along the path, including the originating router, determines which of an LFA {Loop Free Alternative}, the Blue MRT or the Red MRT to use for its next-hops. When a router receives a backup join and is not the destination PLR, the router identifies a unicast alternate to the PLR that avoids the failure-candidate node, creates local multicast group state, and forwards the backup join to that alternate's next-hop. Col. 13, Lines [46-65]-Atlas discloses LFA module 122 may compute and select loop-free alternate (LFA) next-hops ... With LFA, there is no need to tunnel unicast traffic, whether IP or LDP. Col. 15, Lines [7-10]-Atlas discloses with LDP unicast forwarding, regardless of whether topology-identification label or encoding topology in label is used, no additional loopbacks per router are required as are required in the IP unicast forwarding case. Col. 15, Lines [37-38]-Atlas discloses a network device 100 may tunnel IP packets via an LDP LSP. Col. 32, Lines [27-28]-Atlas discloses the backup tree may be the merged set of unicast alternates. Claim [11]-Atlas discloses multicast Label Distribution Protocol (mLDP) label map message having a first Point to Multipoint (P2MP) Forwarding Equivalence Class (FEC) element that specifies the first multicast tree using a first multi-topology identifier).
Atlas is considered to be analogous because it is in the same field of computer networks, dealing with forwarding network traffic within computer networks.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim, in view of Casey and Wijnands, to incorporate the teachings of Atlas on loop-free alternate backup path, with a motivation to route packets of the point-to-multipoint dataflow, and guarantee Internet Protocol (IP) and Label Distribution Protocol (LDP) fast reroute for unicast and multicast traffic, (Atlas, Col. 2, Lines [7-9]).
Response to Arguments
Applicant's Arguments/Remarks, filed on 09/03/2026, with respect to the 35 USC § 102 and 103 rejection of claims 1-6, 8-16 and 18-22 have been fully considered. Applicant’s arguments are not persuasive.
In the remarks, on page 11, Lines [25-32], Applicant argues that, “…Kim's disclosure is directed to constructing and using backup LSPs for multicast traffic, including NHDB-based selection and signaling, but does not disclose the claimed approach of maintaining continuity of the existing point-to-multipoint forwarding toward the same mLDP nexthop after unicast reconvergence by adding a unicast transport label to the label stack of subsequent packets. Accordingly, as amended, claim 1 is not anticipated by Kim. Moreover, the cited portions of Atlas and Casey fail to suggest the missing teaching of amended claim 1.” Examiner respectfully disagrees for the following reasons:
With regards to the referenced limitation, “…determining that the data network has reconverged following the network failure; receiving new unicast primary routes based on a reconvergence of the data network; receiving subsequent packets of the point-to-multipoint dataflow; adding a unicast transport label to a packet label stack of the subsequent packets, wherein the unicast transport label is associated with the nexthop router; receiving an update to a multicast Label Distribution Protocol tree for routing the plurality of packets in the data network, the update based on the reconvergence of the data network; and subsequently, forwarding received packets to the point-to-multipoint receivers according to the update,” as recited in the incumbent claim 1 (and similarly in claim 11), in Para. [0000]-Agiwal discloses ….
Kim et al. (US 20060159009 A1) teaches receiving subsequent packets of the point-to-multipoint dataflow (Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur {EXAMINER'S REEMARKS: Corressponding to packet trasmission after convergence}, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets); unicast transport label to a packet label stack (Para. [0033-0035]-Kim discloses MPLS (Multi-Protocol Label Switching) unicast {EXAMINER'S REMARKS: Corresponding to the referenced unicast transport label} to thereby be applied to MPLS multicast ... For the MPLS fast rerouting, the backup LSP is established at a position where an original LSP can be branched off in order to protect any link or node at which a failure may occur. The original LSP is called "protected LSP," and the LSP established for use as a rerouting path is called "backup path." The MPLS fast rerouting makes use of an MPLS label stack, and the backup LSP may cross the protected LSP.), subsequently, forwarding received packets to the point-to-multipoint receivers according to the update (Fig. 5, Para. [0056]-Kim discloses a process where R2 transmits a packet through a backup LSP, particularly when a failure occurs at a link between R2 and R3. R2 transmits a packet to R4 rather than R3 through a backup LSP (a.k.a., a bypass tunnel). When a failure does not occur, R2 will switch traffic received from R1 and transmit a packet, which is received from R1 into a label 12, and then R3 transmits the packet to R4 after it changes the label 12 of the packet into a label 14. In contrast, when a failure occurs, R2 transmits the packet, which is received from R1, to R6 after it changes a label 37 of the packet into a label 14 and pushes label 17. That is, the label 37 will be swapped for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto a label-stack of the redirected packets) while
Atlas et al. (US 8958286 B1) teaches determining that the data network has reconverged following the network failure (Col. 18, Lines [43-44]-Atlas discloses source node 12B determines that the network has converged (e.g., based on signaling or a time-out)); receiving new unicast primary routes based on a reconvergence of the data network (Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure); receiving subsequent packets of the point-to-multipoint dataflow (Fig. 10, Col. 28, Lines [7-10]-Atlas discloses to forward the packet into Area 304 instead of area 302; this is what would occur after convergence in area 302 when node 306C sends IP packets on the SPT towards ABR 310A); adding a unicast transport label to a packet label stack of the subsequent packets (Col. 31, Lines [40-42]-Atlas discloses PLR tunnels the multicast traffic in unicast (either IP or LDP), where the outer IP address or LDP label {EXAMINER'S REMARKS: Corresponding to the referenced unicast transport label} indicates that MP and the appropriate topology. Col. 14, Lines [36-48]-Atlas discloses LDP module 116D uses the label-stacking ability of multi-protocol label switching (MPLS) {EXAMINER'S REMARKS: Corresponding to a transport label} ... When receiving a packet with a topology-id label, LDP module 116D pops the topology-id label and uses the topology-id label to guide the next-hop selection in combination with the next label in the stack. For example, LDP module 116D does a lookup within FIB 114 on the next inner label or the IP address of the packet (in the case of IP), and that lookup returns a set of sets of next-hops. Fig. 10, Col. 28, Lines [7-10]-Atlas discloses to forward the packet into Area 304 instead of area 302; this is what would occur after convergence in area 302 when node 306C sends IP packets on the SPT towards ABR 310A), receiving an update to a multicast Label Distribution Protocol tree for routing the plurality of packets in the data network (Col. 12, Lines [36-41 and 58-66]-Atlas discloses routing component 104 periodically updates RIB 110 to accurately reflect the topology of the network and other entities. RIB 110 may describe a topology of the computer network in which network device 100 resides, and may also include routes through the shared trees in the computer network ... routing protocols 116 include ..., and Label Distribution Protocol (LDP) 116D, for exchanging routing information with other routing devices and for updating RIB {Rounting Information Base} 110. In addition, routing protocols 116 include Multicast Label Distribution Protocol (mLDP) 116E and Protocol Independent Multicast (PIM) 116N for routing traffic through a computer network with other routing devices conceptually formed into shared multicast trees. Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure), the update based on the reconvergence of the data network (Col. 35-36, Lines [64-67 and 1-5]-Atlas discloses to converge, first all routers in the area update the broken MRT color for each multicast source (or unicast destination). Then, once all routers in the area are known to have updated the broken MRT color, whether that is determined by a timer, signaling or some other mechanism, all of the routers update the unbroken MRT color. Once all routers in the area have also updated their unbroken MRT color, the multicast trees are using the new MRTs and are prepared for another single failure. Col. 18, Lines [38-47]-Atlas discloses after calculation of the primary and alternate next-hops is completed (176), source node 12B will handle other messages received from neighbor devices (178), e.g., routing updates. Source node 12B begins forwarding subsequently received packets using the new primary next-hop (180). Once source node 12B determines that the network has converged (e.g., based on signaling or a time-out), and so it can reasonably be assumed that the network traffic is no longer being carried on the MRT, then source node 12B installs the new MRT next-hops); and
Liam Casey (US 20030142674 A1) teaches adding a unicast transport label to a packet label stack of the subsequent packets (Para. [0077]-Casey discloses if it is a unicast packet ... then use the SET label to index into the SET to Core (S2C) Label Mapping to retrieve the new label stack and outgoing core i/f. Swap service labels, add transport label and forward over the outgoing i/f currently associated with the transport LSP), the unicast transport label is associated with the nexthop router (Figs. 3-6, Para. [0077]-Casey discloses if it is a unicast packet (SET dest. MAC address is that of Core-PE and the SET label has a valid value in the low order bits) then use the SET label to index into the SET to Core (S2C) Label Mapping to retrieve the new label stack and outgoing core i/f. Swap service labels, add transport label and forward over the outgoing i/f currently associated with the transport LSP).
In the remarks, on page 13, Lines [21-27], Applicant argues that, “…Atlas does not teach the claimed ILM/FTN-gated stopping condition for mLDP tree update. Atlas generally discusses MRT-based fast reroute and convergence timing, but it does not disclose continuing to forward P2MP traffic to a prior mLDP nexthop router after unicast reconvergence by adding a unicast transport label until a multicast-tree update is detected in the form of an ILM/FTN update, and then stopping the addition. Further, Casey's transport-label addition is in a VPLS label-control context and does not address mLDP P2MP tree continuity during reconvergence.” Examiner respectfully disagrees for the following reasons:
With regards to the referenced limitation, “…determining that an update has been received for an Incoming Label Map (ILM) or a Forwarding Table Next (FTN) corresponding to a multicast Label Distribution Protocol tree for the point-to-multipoint dataflow; and responsive to the determining that the update has been received for the ILM or the FTN, stopping the adding of the unicast transport label to the packet label stack of the subsequent packets,” as recited in the incumbent claim 11, additional search shows that:
Wijnands et al. (US 20150078378 A1) teaches determining that an update has been received for an Incoming Label Map (ILM) or a Forwarding Table Next (FTN) corresponding to a multicast Label Distribution Protocol tree for the point-to-multipoint dataflow (Para. [0114-0117]-Wijnands discloses multicast data packet is forwarded along the P2P LSP using unicast MPLS ... BIER-enabled nodes can forward multicast data packets using inherently loop-free topologies ... example of such a loop-free topology is a point-to-multipoint label switched path (P2MP LSP). Para. [0104]-Wijnands discloses BIER-enabled node then updates the copy of the multicast data packet by removing the multicast data packet's top label (e.g., the label that was on top of the multicast data packet's MPLS label stack when the packet was received by the BIER-enabled node). Para. [0037-0039]-Wijnands discloses the multicast forwarding table includes information identifying each interface of multicast-enabled node 110 that is connected to a multicast distribution tree (MDT) to one or more receivers for the multicast group ... the process traditionally used in multicast of setting up MDTs and updating multicast forwarding tables for each group results in considerable amounts of state information within the network); and responsive to the determining that the update has been received for the ILM or the FTN, stopping the adding of the unicast transport label to the packet label stack of the subsequent packets (Para. [0114-0117]-Wijnands discloses multicast data packet is forwarded along the P2P LSP using unicast MPLS ... BIER-enabled nodes can forward multicast data packets using inherently loop-free topologies ... example of such a loop-free topology is a point-to-multipoint label switched path (P2MP LSP). Para. [0104]-Wijnands discloses BIER-enabled node then updates the copy of the multicast data packet by removing the multicast data packet's top label (e.g., the label that was on top of the multicast data packet's MPLS label stack when the packet was received by the BIER-enabled node). Para. [0037-0039]-Wijnands discloses the multicast forwarding table includes information identifying each interface of multicast-enabled node 110 that is connected to a multicast distribution tree (MDT) to one or more receivers for the multicast group ... the process traditionally used in multicast of setting up MDTs and updating multicast forwarding tables for each group results in considerable amounts of state information within the network).
In the remarks, on page 14, Lines [3-5], Applicant argues that, “…even if these disparate references could be combined in the manner proposed, which is not conceded, combination lacks a teaching, suggestion, or motivation for the claimed coordination.” Examiner respectfully disagrees for the following reasons:
Kim et al. (US 20060159009 A1), Atlas et al. (US 8958286 B1), Liam Casey (US 20030142674 A1) and Wijnands et al. (US 20150078378 A1) are considered to be analogous to the claimed invention because they are in the same field of communication networks, dealing with Multiprotocol Label Switching. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the Kim in view of Atlas and Casey to incorporate the teachings of Wijnands on MLDP tree, with a motivation to stop unicast transport label upon receiving updates for incoming label map, and guarantee improved network performance, (Wijnands, Para. [0003]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLADIRAN GIDEON OLALEYE whose telephone number is (571)272-5377. The examiner can normally be reached Monday - Friday: 07:30am - 05:30pm to.
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 SPE, NICHOLAS A. JENSEN can be reached on (571) 270-5443. 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.
/OO/
Examiner, Art Unit 2472
/NICHOLAS A JENSEN/Supervisory Patent Examiner, Art Unit 2472
