Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
This office action is responsive to communication filed on 12/08/2023. Claims 1-3, and 7-13 are pending for examination.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Duncan et al. (US20180324090A1) in view of Filsfils et al. (US20210021513A1), and further in view of in view of Seth et al. (US20200313915A1).
As per claim 1. Duncan disclose A computer-implemented method for use by a router on a multicast tree, the computer-implemented method comprising: receiving, by the router, a control plane message from a downstream router on the multicast tree, wherein the control plane message includes a label and a tree identifier identifying the multicast tree; (par0010-0012, a multicast method for Segment Routing receiving, at a node, a multicast packet including an outer label including a Multiprotocol Label Switching (MPLS) source node identifier defining a source-rooted broadcast tree and an inner label including a service identifier defining a service specific multicast tree)
Duncan does not explicitly disclose b) constructing, by the router, an SRv6 SID in a LOC:FUNCT:ARG form, wherein the LOC part is a locator of the downstream router and the FUNCT part is the label included in the control plane message received; using the SRv6 SID.
Filsfils however disclose b) constructing, by the router, an SRv6 SID in a LOC:FUNCT:ARG form, wherein the LOC part is a locator of the downstream router and the FUNCT part is the label included in the control plane message received; using the SRv6 SID (par0037-0048, As shown in FIG. 1, the first SID may comprise [constructing, by the router] C3::2:16004:16005 for example. An SRv6 SID may have the form LOC:FUN:ARGs, where the Locator (LOC) may comprise a prefix routable up to a given router in the network; the Function (FUN) may comprise the local function that may be executed at such router; and the Arguments (ARGs) may comprise an optional value used to convey arguments specific to that flow to the specific function. In the case of the first SID, the Locator may comprise C3, the Function may comprise 2, and the Arguments may comprise 16004:16005.)
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of b) constructing, by the router, an SRv6 SID in a LOC:FUNCT:ARG form, wherein the LOC part is a locator of the downstream router and the FUNCT part is the label included in the control plane message received; using the SRv6 SID, as taught by Filsfils, in the system of Duncan, in order to permit hierarchical address allocation processes that facilitate route aggregation across the Internet, and thus limit the expansion of routing tables, see Filsfils par0003.
Duncan and Filsfils do not explicitly disclose c) creating an entry in a forwarding table of the router so that the router replicates received traffic of this multicast tree to the downstream node.
Seth however discloses c) creating an entry in a forwarding table of the router so that the router replicates received traffic of this multicast tree to the downstream node. (par0006, The router may also create a multicast forwarding entry (or add another next-hop to an existing multicast forwarding entry) in a multicast forwarding table to cause the router to replicate multicast packets, received for the multicast distribution tree, to the downstream router).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of when a packet label has no matching label entry, identifying a destination address in another header of the received packet and forwarding the packet for egress via the set of interfaces according to the destination address, as taught by Seth, in the system of Duncan and Filsfils, so in the event of network failure or failure of one of the redundant multicast sources, routing converges around the failure and the network builds a new multicast distribution tree to distribute the multicast packets, see Seth par0005.
As per claim 2. Duncan, Filsfils and Seth disclose the computer-implemented method of claim 1.
Duncan disclose further comprising: d) receiving, by the router, a second control plane message from a second downstream router on the multicast tree, wherein the control plane message includes a second label and a tree identifier identifying the multicast tree (par0010-0012, a multicast method for Segment Routing receiving, at a node, a multicast packet including an outer label including a Multiprotocol Label Switching (MPLS) source node identifier defining a source-rooted broadcast tree and an inner label including a service identifier defining a service specific multicast tree…. can be divided into a plurality of mutually exclusive subset trees with each subset rooted on a different intermediate node, and wherein the forwarding for each of the plurality of mutually exclusive subset trees can include pushing, at a source node, an outer label including a Segment Routing destination label corresponding to a different intermediate node on top of the MPLS source node identifier; forwarding the multicast packet to the different intermediate node based on the outer destination label; and popping, at the different intermediate node, the outer label and forwarding the multicast packet on a subset tree rooted on the different intermediate node.)
Duncan does not explicitly disclose e) constructing, by the router, a second SRv6 SID in the LOC:FUNCT:ARG form, wherein the LOC part is a locator of the second downstream router and the FUNCT part is the second label included in the second control plane message received; and using the both the SRv6 SID and the second SRv6 SID.
Filsfils however disclose e) constructing, by the router, a second SRv6 SID in the LOC:FUNCT:ARG form, wherein the LOC part is a locator of the second downstream router and the FUNCT part is the second label included in the second control plane message received; and using the both the SRv6 SID and the second SRv6 SID (par0037,0048, 0065-0069, As shown in FIG. 1, the first SID may comprise [constructing, by the router] C3::2:16004:16005 for example. An SRv6 SID may have the form LOC:FUN:ARGs, where the Locator (LOC) may comprise a prefix routable up to a given router in the network; the Function (FUN) may comprise the local function that may be executed at such router; and the Arguments (ARGs) may comprise an optional value used to convey arguments specific to that flow to the specific function. In the case of the first SID, the Locator may comprise C3, the Function may comprise 2, and the Arguments may comprise 16004:16005…..SRv6 SIDs from the same domain may share the initial part of the Locator because all of them may come from the SP prefix block. A Locator may be divided in between SP_prefix and NodeID…..the following segments in the label stack <401, 501> may be translated into <C4::1, C5::1>. Edge node 316 may pop the first domain label stack and insert second domain header 352 (e.g., an IPv6 header) and SR header 354 with the corresponding SIDs <C4::1, C5::1> to create packet)
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of e) constructing, by the router, a second SRv6 SID in the LOC:FUNCT:ARG form, wherein the LOC part is a locator of the second downstream router and the FUNCT part is the second label included in the second control plane message received; and using the both the SRv6 SID and the second SRv6 SID, as taught by Filsfils, in the system of Duncan, in order to permit hierarchical address allocation processes that facilitate route aggregation across the Internet, and thus limit the expansion of routing tables, see Filsfils par0003.
Duncan and Filsfils do not explicitly disclose f) updating the entry in a forwarding table of the router so that the router replicates received traffic of this multicast tree to the downstream node.
Seth however discloses f) updating the entry in a forwarding table of the router so that the router replicates received traffic of this multicast tree to the downstream node. (par0006, The router may also create a multicast forwarding entry (or add another next-hop to an existing multicast forwarding entry) in a multicast forwarding table to cause the router to replicate multicast packets, received for the multicast distribution tree, to the downstream router).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of f) updating the entry in a forwarding table of the router so that the router replicates received traffic of this multicast tree to the downstream node, as taught by Seth, in the system of Duncan and Filsfils, so in the event of network failure or failure of one of the redundant multicast sources, routing converges around the failure and the network builds a new multicast distribution tree to distribute the multicast packets, see Seth par0005.
As per claim 3. Duncan, Filsfils and Seth disclose the computer-implemented method of claim 1.
Duncan does not explicitly disclose further comprising: - provisioning the router to treat a signaled label as the FUNCT bits of an SRv6 SID instead of as a real MPLS label for MPLS data planes.
Filsfils however disclose further comprising: - provisioning the router to treat a signaled label as the FUNCT bits of an SRv6 SID instead of as a real MPLS label for MPLS data planes. (par0068, edge node 316 corresponds to the interworking function, a second domain header and a Segment Routing Header (SRH) onto the packet. The second domain header and the SRH may be based on labels in the first domain label stack after the next label corresponding to the interworking function. For example, the function 19001 may be pre-configured with an SP Prefix of C::/64. Hence, the following segments in the label stack <401, 501> may be translated into <C4::1, C5::1>.).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of further comprising: - provisioning the router to treat a signaled label as the FUNCT bits of an SRv6 SID instead of as a real MPLS label for MPLS data planes, as taught by Filsfils, in the system of Duncan, in order to permit hierarchical address allocation processes that facilitate route aggregation across the Internet, and thus limit the expansion of routing tables, see Filsfils par0003.
As per claim 9. Duncan disclose A computer-implemented method for use by a router on a multicast tree, the computer-implemented method comprising: (2) a tree identifier identifying the multicast tree; b) generating a control plane message (par0010, a multicast method for Segment Routing receiving, at a node, a multicast packet including an outer label including a Multiprotocol Label Switching (MPLS) source node identifier defining a source-rooted broadcast tree and an inner label including a service identifier defining a service specific multicast tree)
Duncan does not explicitly disclose a) constructing, an SRv6 SID in a LOC: FUNCT: ARG form for the multicast tree, wherein the LOC is a locator of the router and the FUNCT is to be signaled to an upstream router as a label; including (1) the FUNCT part of the SRv6 SID as a label.
Filsfils however disclose a) constructing, an SRv6 SID in a LOC: FUNCT: ARG form for the multicast tree, wherein the LOC is a locator of the router and the FUNCT is to be signaled to an upstream router as a label; including (1) the FUNCT part of the SRv6 SID as a label (par0037-0048, 0068, As shown in FIG. 1, the first SID may comprise [constructing] C3::2:16004:16005 for example. An SRv6 SID may have the form LOC: FUN: ARGs, where the Locator (LOC) may comprise a prefix routable up to a given router in the network; the Function (FUN) may comprise the local function that may be executed at such router; and the Arguments (ARGs) may comprise an optional value used to convey arguments specific to that flow to the specific function. In the case of the first SID, the Locator may comprise C3, the Function may comprise 2, and the Arguments may comprise 16004:16005….. edge node 316 corresponds to the interworking function, a second domain header and a Segment Routing Header (SRH) onto the packet. The second domain header and the SRH may be based on labels in the first domain label stack after the next label corresponding to the interworking function. For example, the function 19001 may be pre-configured with an SP Prefix of C::/64. Hence, the following segments in the label stack <401, 501> may be translated into <C4::1, C5::1>.).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of a) constructing, an SRv6 SID in a LOC:FUNCT:ARG form for the multicast tree, wherein the LOC is a locator of the router and the FUNCT is to be signaled to an upstream router as a label; including (1) the FUNCT part of the SRv6 SID as a label, as taught by Filsfils, in the system of Duncan, in order to permit hierarchical address allocation processes that facilitate route aggregation across the Internet, and thus limit the expansion of routing tables, see Filsfils par0003.
Duncan and Filsfils do not explicitly disclose c) transmitting the control plane message generated to an upstream router on the multicast tree.
Seth however discloses c) transmitting the control plane message generated to an upstream router on the multicast tree. (par0006, The router may also create a multicast forwarding entry (or add another next-hop to an existing multicast forwarding entry) in a multicast forwarding table to cause the router to replicate multicast packets, received for the multicast distribution tree, to the downstream router).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of c) transmitting the control plane message generated to an upstream router on the multicast tree, as taught by Seth, in the system of Duncan and Filsfils, so in the event of network failure or failure of one of the redundant multicast sources, routing converges around the failure and the network builds a new multicast distribution tree to distribute the multicast packets, see Seth par0005.
Claims 7 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Duncan in view of Filsfils further in view of in view of Seth, and further in view of in view of Bidgoli et al. (US20200007358A1).
As per claim 7. Duncan, Filsfils and Seth disclose the computer-implemented method of claim 1.
Duncan, Filsfils and Seth do not explicitly disclose wherein the multicast tree is an mLDP P2MP tree, and wherein the control plane message received is an mLDP Label Mapping message for the mLDP P2MP tree, and the tree identifier is the mLDP FEC for the multicast tree.
Bidgoli however discloses wherein the multicast tree is an mLDP P2MP tree, andwherein the control plane message received is an mLDP Label Mapping message for the mLDP P2MP tree, and the tree identifier is the mLDP FEC for the multicast tree. (par0048-0-049, 0072-0073, The MPLS router (illustratively, MPLS router 114-4) associated with the multicast host (illustratively, MH 120) that is requesting to join the multicast group (S,G) of the P2MP LSP…. he MPLS signaling may be an mLDP control packet or other suitable control packet. The MPLS signaling information may be a combination of a FEC and an associated action (e.g., label mapping, label withdraw, or the like) which may be denoted as <FEC, Action> for the P2MP LSP. It will be appreciated that the FEC may be a basic opaque FEC (e.g., for a single IGP area) or may be a recursive opaque FEC (e.g., for seamless MPLS). In FIG. 2, the sending of the MPLS signaling information to the IBBR of the BIER domain is indicated by message 210. For example, the message 210 may include mLDP FEC (root, opaque<lspID1>, label1), mLDP FEC (root, opaque<lspID2>, label2), or the like….. the message 220 may include mLDP FEC (root, opaque<lspID1>) where message 210 includes <mLDP FEC (root, opaque<lspID1>, label1)>, mLDP FEC (root, opaque<lspID2>) where message 210 includes <mLDP FEC (root, opaque<lspID2>, label2)>….. the message 350 may include <mLDP FEC (root, opaque<lspID1>, label3)> where message 310 includes <mLDP FEC (root, opaque<lspID1>, label1)>, <mLDP FEC (root, opaque<lspID1>, label4)> where message 310 includes <mLDP FEC (root, opaque<lspID2>, label2)>, or the like. It will be appreciated that, while primarily presented in FIG. 3 within the context of handling of a specific type of action for the multicast tree (namely, a label mapping action in which the MPLS router 114 is joining the multicast tree), various embodiments of FIG. 3 may be adapted for use in handling other types of actions).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the multicast tree is an mLDP P2MP tree, andwherein the control plane message received is an mLDP Label Mapping message for the mLDP P2MP tree, and the tree identifier is the mLDP FEC for the multicast tree, as taught by Bidgoli, in the system of Duncan, Filsfils and Seth.
As per claim 10. Duncan, Filsfils and Seth disclose the computer-implemented method of claim 9.
Duncan, Filsfils and Seth do not explicitly disclose wherein the multicast tree is an mLDP P2MP tree, andwherein the control plane message received is an mLDP Label Mapping message for the mLDP P2MP tree, and the tree identifier is the mLDP FEC for the multicast tree.
Bidgoli however discloses wherein the multicast tree is an mLDP P2MP tree, andwherein the control plane message received is an mLDP Label Mapping message for the mLDP P2MP tree, and the tree identifier is the mLDP FEC for the multicast tree. (par0048-0-049, 0072-0073, The MPLS router (illustratively, MPLS router 114-4) associated with the multicast host (illustratively, MH 120) that is requesting to join the multicast group (S,G) of the P2MP LSP…. he MPLS signaling may be an mLDP control packet or other suitable control packet. The MPLS signaling information may be a combination of a FEC and an associated action (e.g., label mapping, label withdraw, or the like) which may be denoted as <FEC, Action> for the P2MP LSP. It will be appreciated that the FEC may be a basic opaque FEC (e.g., for a single IGP area) or may be a recursive opaque FEC (e.g., for seamless MPLS). In FIG. 2, the sending of the MPLS signaling information to the IBBR of the BIER domain is indicated by message 210. For example, the message 210 may include mLDP FEC (root, opaque<lspID1>, label1), mLDP FEC (root, opaque<lspID2>, label2), or the like….. the message 220 may include mLDP FEC (root, opaque<lspID1>) where message 210 includes <mLDP FEC (root, opaque<lspID1>, label1)>, mLDP FEC (root, opaque<lspID2>) where message 210 includes <mLDP FEC (root, opaque<lspID2>, label2)>….. the message 350 may include <mLDP FEC (root, opaque<lspID1>, label3)> where message 310 includes <mLDP FEC (root, opaque<lspID1>, label1)>, <mLDP FEC (root, opaque<lspID1>, label4)> where message 310 includes <mLDP FEC (root, opaque<lspID2>, label2)>, or the like. It will be appreciated that, while primarily presented in FIG. 3 within the context of handling of a specific type of action for the multicast tree (namely, a label mapping action in which the MPLS router 114 is joining the multicast tree), various embodiments of FIG. 3 may be adapted for use in handling other types of actions).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the multicast tree is an mLDP P2MP tree, andwherein the control plane message received is an mLDP Label Mapping message for the mLDP P2MP tree, and the tree identifier is the mLDP FEC for the multicast tree, as taught by Bidgoli, in the system of Duncan, Filsfils and Seth.
Claims 8 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Duncan in view of Filsfils further in view of in view of Seth, and further in view of in view of Aggarwal et al. (US20090161675A1).
As per claim 8. Duncan, Filsfils and Seth disclose the computer-implemented method of claim 1.
Duncan, Filsfils and Seth do not explicitly disclose wherein the multicast tree is an RSVP P2MP tree, and wherein the control plane message received is an RSVP Resv Message for the RSVP P2MP tree, and the tree identifier is the RSVP P2MP session object for the multicast tree.
Aggarwal however discloses wherein the multicast tree is an RSVP P2MP tree, and wherein the control plane message received is an RSVP Resv Message for the RSVP P2MP tree, and the tree identifier is the RSVP P2MP session object for the multicast tree. (par0066-0068, Next, processing logic determines whether the identified receivers belong to an existing P2MP LSP (decision box 504). In one embodiment, the determination is made by searching the identifiers of existing P2MP LSPs (P2MP LSP ID). In one embodiment, each P2MP LSP ID is composed of a unique combination of the address of a source edge router initiating the P2MP LSP, a tunnel ID that identifies the type of the traffic (e.g., video, voice, etc.) traveling along the P2MP LSP, and the identifier of the session. In one embodiment, a new P2MP LSP session RSVP-TE object is introduced to carry the elements of the P2MP LSP ID. FIG. 5B illustrates the format of an exemplary P2MP LSP session object 550, which contains the address of the source edge router (e.g., a 32-bit IPv4 (Internet Protocol version 4) address), the tunnel ID is a 16-bit identifier and the P2MP ID is a 32-bit identifier.).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the multicast tree is an RSVP P2MP tree, and wherein the control plane message received is an RSVP Resv Message for the RSVP P2MP tree, and the tree identifier is the RSVP P2MP session object for the multicast tree, as taught by Aggarwal, in the system of Duncan, Filsfils and Seth, in order to establish traffic engineered that can be automatically routed away from network failures, congestion and bottlenecks and satisfy various other policies related to network performance optimization, see Aggarwal par0006.
As per claim 11. Duncan, Filsfils and Seth disclose the computer-implemented method of claim 9.
Duncan, Filsfils and Seth do not explicitly disclose wherein the multicast tree is an RSVP P2MP tree, and wherein the control plane message received is an RSVP Resv Message for the RSVP P2MP tree, and the tree identifier is the RSVP P2MP session object for the multicast tree.
Aggarwal however discloses wherein the multicast tree is an RSVP P2MP tree, and wherein the control plane message received is an RSVP Resv Message for the RSVP P2MP tree, and the tree identifier is the RSVP P2MP session object for the multicast tree. (par0066-0068, Next, processing logic determines whether the identified receivers belong to an existing P2MP LSP (decision box 504). In one embodiment, the determination is made by searching the identifiers of existing P2MP LSPs (P2MP LSP ID). In one embodiment, each P2MP LSP ID is composed of a unique combination of the address of a source edge router initiating the P2MP LSP, a tunnel ID that identifies the type of the traffic (e.g., video, voice, etc.) traveling along the P2MP LSP, and the identifier of the session. In one embodiment, a new P2MP LSP session RSVP-TE object is introduced to carry the elements of the P2MP LSP ID. FIG. 5B illustrates the format of an exemplary P2MP LSP session object 550, which contains the address of the source edge router (e.g., a 32-bit IPv4 (Internet Protocol version 4) address), the tunnel ID is a 16-bit identifier and the P2MP ID is a 32-bit identifier.).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein the multicast tree is an RSVP P2MP tree, and wherein the control plane message received is an RSVP Resv Message for the RSVP P2MP tree, and the tree identifier is the RSVP P2MP session object for the multicast tree, as taught by Aggarwal, in the system of Duncan, Filsfils and Seth, in order to establish traffic engineered that can be automatically routed away from network failures, congestion and bottlenecks and satisfy various other policies related to network performance optimization, see Aggarwal par0006.
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Duncan in view of Filsfils.
As per claim 12. Duncan disclose A computer-implemented method for use with a router, the computer-implemented method comprising: a) processing first label information in a first control plane message from a first downstream router as an MPLS label (par0010-0012, a multicast method for Segment Routing receiving, at a node, a multicast packet including an outer label including a Multiprotocol Label Switching (MPLS) source node identifier defining a source-rooted broadcast tree and an inner label including a service identifier defining a service specific multicast tree…. can be divided into a plurality of mutually exclusive subset trees with each subset rooted on a different intermediate node, and wherein the forwarding for each of the plurality of mutually exclusive subset trees can include pushing, at a source node, an outer label including a Segment Routing destination label corresponding to a different intermediate node on top of the MPLS source node identifier; forwarding the multicast packet to the different intermediate node based on the outer destination label; and popping, at the different intermediate node, the outer label and forwarding the multicast packet on a subset tree rooted on the different intermediate node.)
Duncan does not explicitly disclose b) processing second label information in a second control plane message from a second downstream router as FUNCTION bits of an SRv6 SID.
Filsfils however disclose b) processing second label information in a second control plane message from a second downstream router as FUNCTION bits of an SRv6 SID (par0048, 0067-0069, edge node 316 corresponds to the interworking function, a second domain header and a Segment Routing Header (SRH) onto the packet. The second domain header and the SRH may be based on labels in the first domain label stack after the next label corresponding to the interworking function. For example, the function 19001 may be pre-configured with an SP Prefix of C::/64. Hence, the following segments in the label stack <401, 501> may be translated into <C4::1, C5::1>….. all the SRv6 SIDs from the same domain may share the initial part of the Locator because all of them may come from the SP prefix block. A Locator may be divided in between SP_prefix and NodeID. Accordingly, the necessary amount of NodeIDs and functions necessary in that limited domain may be encode in 20-bits. However, two MPLS labels per SRv6 SID may be used to provide 40-bits for the NodeID+Function information….. edge node 316 corresponds to the interworking function, a second domain header and a Segment Routing Header (SRH) onto the packet. The second domain header and the SRH may be based on labels in the first domain label stack after the next label corresponding to the interworking function. For example, the function 19001 may be pre-configured with an SP Prefix of C::/64. Hence, the following segments in the label stack <401, 501> may be translated into <C4::1, C5::1>. Edge node 316 may pop the first domain label stack and insert second domain header 352 (e.g., an IPv6 header) and SR header 354 with the corresponding SIDs <C4::1, C5::1> to create packet third state 322).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of b) processing second label information in a second control plane message from a second downstream router as FUNCTION bits of an SRv6 SID, as taught by Filsfils, in the system of Duncan, in order to permit hierarchical address allocation processes that facilitate route aggregation across the Internet, and thus limit the expansion of routing tables, see Filsfils par0003.
As per claim 13. Duncan and Filsfils disclose the computer-implemented method of claim 12.
Duncan does not explicitly disclose c) sending third label information in a third control plane message to a first upstream router that is configured to treat the third label information in the third control plane message as a label for MPLS traffic replication, and d) sending fourth label information in a fourth control plane message to a second upstream router that is configured to treat the fourth information in the fourth control plane message as part of an SRv6 SID for SRv6 traffic replication, wherein the router and the first upstream router belong to a first multicast tree, and wherein the router and the second upstream router belong to a second multicast tree.
Filsfils however disclose c) sending third label information in a third control plane message to a first upstream router that is configured to treat the third label information in the third control plane message as a label for MPLS traffic replication, and d) sending fourth label information in a fourth control plane message to a second upstream router that is configured to treat the fourth information in the fourth control plane message as part of an SRv6 SID for SRv6 traffic replication, wherein the router and the first upstream router belong to a first multicast tree, and wherein the router and the second upstream router belong to a second multicast tree (par0061-0069, the SID list corresponding to the SR policy in stage 420, method 400 may continue to stage 430 where start node 308 in first domain 302 may route the packet to intermediate node 310 in first domain 302 according to a first domain label stack on the packet. The first domain label stack may correspond to the SID list. For example, the packet routed from start node 308 to intermediate node 310 may comprise packet first state 318. The first domain label stack of packet first state 318 may comprise first domain label 326 (e.g., 16002), second first domain label 328 (e.g., 16003), third first domain label 330 (e.g., 19001), fourth first domain label 332 (e.g., 401), and fifth first domain label 334 (e.g., 501). First domain label 326 and second first domain label 328 may respectively correspond to first domain intermediate node 310 and edged node 316. Fourth first domain label 332 and fifth first domain label 334 may respectively correspond to second domain intermediate node 312 and second domain end node 314….. From stage 440, where intermediate node 310 in first domain 302 updates the packet by removing the label corresponding to intermediate node 310 from the first domain label stack, method 400 may advance to stage 450 where intermediate node 310 in first domain 302 may route the packet to edge node 316 between first domain 302 and second domain 304 according to the first domain label stack on the packet. For example, the packet in packet second state 320 may be routed over the shortest path in first domain 302 up to a node corresponding to first domain label 340 (e.g., 16003 corresponding to edge node 316)….. he function 19001 may be pre-configured with an SP Prefix of C::/64. Hence, the following segments in the label stack <401, 501> may be translated into <C4::1, C5::1>. Edge node 316 may pop the first domain label stack and insert second domain header 352 (e.g., an IPv6 header) and SR header 354 with the corresponding SIDs <C4::1, C5::1> to create packet third state 322 for example.).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of c) sending third label information in a third control plane message to a first upstream router that is configured to treat the third label information in the third control plane message as a label for MPLS traffic replication, and d) sending fourth label information in a fourth control plane message to a second upstream router that is configured to treat the fourth information in the fourth control plane message as part of an SRv6 SID for SRv6 traffic replication, wherein the router and the first upstream router belong to a first multicast tree, and wherein the router and the second upstream router belong to a second multicast tree, as taught by Filsfils, in the system of Duncan, in order to permit hierarchical address allocation processes that facilitate route aggregation across the Internet, and thus limit the expansion of routing tables, see Filsfils par0003.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent are -
• Zhang et al. (US12309064B2) – Related art in the area of a method for forwarding a packet in an SRv6 service function chain, an SFF, and an SF device, and belongs to the field of communication technologies.
• Wei. (WO2021068641A1) – Related art in the area of a virtual private network multicast method based on an IPv6 network, an electronic device, and a computer-readable storage medium.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONISHWAR MOHAN whose telephone number is (571)272-2907. The examiner can normally be reached Monday - Thursday 7:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, William Trost can be reached on (571) 272-7872. 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.
/M.M./Examiner, Art Unit 2442
/WILLIAM G TROST IV/Supervisory Patent Examiner, Art Unit 2442
Prosecution Insights