DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to Applicant’s communication filed on 07/25/2024. Claims 1-20 have been examined.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 07/25/2024. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of Patent No. US 12,120,027 in view of Tulumello.
Although the conflicting claims are not identical, they are not patentably distinct from each other because:
See Below for analysis
Claims 1-20 of Instant application
Claims 1 -20 of Patent No. 12,120,027
Claim 1
A method comprising:
receiving, by a first network controller, a request from a second network controller, the request is associated with sending a packet from a first node of a first network to a second node of the first network via a second network disposed between the first node and the second node;
determining, by the first network controller and based at least in part on a parameter included in the request, a path through the second network that is optimized for sending the packet from the first node to the second node;
determining, by the first network controller, a destination address for sending the packet along the path from the first node to the second node,
the destination address including: segment routing headers (SRHs) corresponding to segments of the path in the second network that are configured to steer the packet through the second network and along the path, and
trailing bits representing a portion of an address that corresponds with the second node; and
sending, by the first network controller the destination address to the second network controller, the destination address to be used to send the packet from the first node to the second node along the path through the second network.
Claim 1
A method comprising:
receiving, by an underlay network controller, a request from an overlay network controller, the request is associated with sending a packet from a first node of an overlay network to a second node of the overlay network via an underlay network disposed between the first node and the second node;
determining, by the underlay network controller and based at least in part on a parameter included in the request, a path through the underlay network that is optimized for sending the packet from the first node to the second node;
determining, by the underlay network controller, a destination address for sending the packet along the path from the first node to the second node,
the destination address including: micro segment identifiers (uSIDs) corresponding to segments of the path in the underlay network that are configured to steer the packet through the underlay network and along the path, and
trailing bits representing a portion of an address that corresponds with the second node; and
sending, by the underlay network controller the destination address to the overlay network controller, the destination address to be used to send the packet from the first node to the second node along the path through the underlay network.
Claims 2,10,17
wherein the parameter included in the request is at least one of a policy parameter or a performance parameter associated with sending the packet from the first node to the second node.
Claims 2,10,17
wherein the parameter included in the request is at least one of a policy parameter or a performance parameter associated with sending the packet from the first node to the second node..
Claims 3,18
wherein the first network is a software-defined wide area network and the second network is at least one of a service provider network or a transport network.
Claims 3,18
wherein the overlay network is a software-defined wide area network and the underlay network is at least one of a service provider network or a transport network.
Claim 4,12,19
wherein the path through the second network is determined based at least in part on at least one of a network topology or performance data associated with the second network.
Claims 4,12, 19
wherein the path through the underlay network is determined based at least in part on at least one of a network topology or performance data associated with the underlay network.
Claims 5,13,20
determining a topology graph associated with the second network, the topology graph indicative of a topology of the second network and connections between one or more data plane nodes of the first network and one or more edge nodes of the second network.
Claims 5,13,20
determining a topology graph associated with the underlay network, the topology graph indicative of a topology of the underlay network and connections between one or more data plane nodes of the overlay network and one or more edge nodes of the underlay network.
Claim 6
wherein the destination address is a 128-bit internet protocol version six (IPv6) destination address and the SRHs are associated with a segment routing over IPv6 (SR v6) protocol.
Claim 6
wherein the destination address is a 128-bit internet protocol version six (IPv6) destination address and the uSIDs are associated with a segment routing over IPv6 (SRv6) protocol.
Claim 7
wherein multiple underlay nodes are disposed along the path through the second network, and wherein the destination address includes a respective SRH for each one of the multiple underlay nodes disposed along the path.
Claim 7
wherein multiple underlay nodes are disposed along the path through the underlay network, and wherein the destination address includes a respective uSID for each one of the multiple underlay nodes disposed along the path.
Claims 8,15
wherein the segments represent a plurality of underlay network nodes.
Claims 8,15
wherein the segments represent a plurality of underlay network nodes.
Claims 9,16
A system /medium comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions that, when executed, cause the one or more processors to perform operations comprising:
receiving, by a first network controller, a request from a second network controller, the request is associated with sending a packet from a first node of a first network to a second node of the first network via a second network disposed between the first node and the second node;
determining, by the first network controller and based at least in part on a parameter included in the request, a path through the second network that is optimized for sending the packet from the first node to the second node;
determining, by the first network controller, a destination address for sending the packet along the path to the second node, the destination address including a first portion that precedes a second portion, the first portion including segment routing headers (SRHs) corresponding to segments of the path in the second network that is configured to steer the packet through the second network and along the path, the second portion including multiple bits representing a portion of an address that corresponds with the second node; and
sending, by the first network controller, the destination address to the second network controller, the destination address to be used to send the packet from the first node to the second node along the path through the second network.
Claims 9,16
A system/medium comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions that, when executed, cause the one or more processors to perform operations comprising:
receiving, by an underlay network controller, a request from an overlay network controller, the request is associated with sending a packet from a first node of the overlay network to a second node of the overlay network via an underlay network disposed between the first node and the second node;
determining, by the underlay network controller and based at least in part on a parameter included in the request, a path through the underlay network that is optimized for sending the packet from the first node to the second node;
determining, by the underlay network controller, a destination address for sending the packet along the path to the second node, the destination address including a first portion that precedes a second portion, the first portion including micro segment identifiers (uSIDs) a corresponding to segments of the path in the underlay network that is configured to steer the packet through the underlay network and along the path, the second portion including multiple bits representing a portion of an address that corresponds with the second node; and
sending, by the underlay network controller, the destination address to the overlay network controller, the destination address to be used to send the packet from the first node to the second node along the path through the underlay network.
Claim 11
wherein the first network is an overlay network and the second network is an underlay network.
Claim 11
wherein the overlay network is a software-defined wide area network and the underlay network is at least one of a service provider network or a transport network.
Claim 14
wherein an underlay node of the second network, upon receiving the packet, shifts the first portion and second portion of the destination address such that the destination address represents an entire portion of the address that corresponds with the second node.
Claim 14
wherein an underlay node of the underlay network, upon receiving the packet, shifts the first portion and second portion of the destination address such that the destination address represents an entire portion of the address that corresponds with the second node.
With regards to claims 1, 3,4,5,7,9,11,12,13,14,16,18,19, the Patent No. US 12,120,027 teaches the first network controller as an underlay network controller, second network controller as the overlay network controller, the first network as an overlay network and second network as underlay network (See Claims 1, 3,4,5,7,9,11,12,13,14,16,18,19).
With regards to claim 1, the Patent No. US 12,120,027 does not explicitly teach that the destination address includes segment routing headers (SRHs). However, Tulumello teaches the destination address includes segment routing headers (SRHs) (Section I & III).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patent No. US 12,120,027 to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
With regards to claim 6, the Patent No. US 12,120,027 does not explicitly teach that the SRHs are associated with a segment routing over IPv6 (SR-V6) protocol . However, Tulumello teaches the SRHs are associated with a segment routing over IPv6 (SR-V6) protocol (Section I & Abstract).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patent No. US 12,120,027 to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
With regards to claim 7, the Patent No. US 12,120,027 does not explicitly teach that the destination address includes a respective SRH for each one of the multiple underlay nodes . However, Tulumello teaches the destination address includes a respective SRH for each one of the multiple underlay nodes (Abstract, Fig.2 & Section III, IV).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patent No. US 12,120,027 to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
With regards to claims 9,16, the Patent No. US 12,120,027 does not explicitly teach that the destination address includes a first portion and that the first portion includes segment routing headers (SRHs). However, Tulumello teaches the destination address includes a first portion and that the first portion includes segment routing headers (SRHs) (Section I & III).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patent No. US 12,120,027 to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 1, the claim recites “the destination address including: segment routing headers (SRHs) corresponding to segments of the path in the second network that are configured to steer the packet through the second network and along the path,”.
The specification does not support the claim limitation as indicated above. The closest recitation in the published specification US 2024/0380697 A1 stated:
¶0015 - By combining underlay steering bits and overlay termination bits in a single 128-bit destination address allows for the functionality to be able to "steer the underlay" without incurring the overhead of a multiple segment list segment routing header (SRH).
¶0021 - However, it would be inefficient and burdensome to have the overlay data plane element ( overlay tunnel headend node) impose a full SRv6 SRH with so many 128-bit SIDs on outbound packets. Instead, the SRv6 uSID calculator may derive a single 128-bit IPv6 destination address by plucking out the necessary micro-segment (uSID) bits from each 128-bit segment identifier. As such, and continuing the above example, the SRv6 uSID calculator may analyze the provided SRv6 SID list as follows
¶0048 - FIG. 2 illustrates an example 200 in which nodes of an underlay network shift a destination address of a packet to steer the packet through the underlay fabric. For instance, when the overlay node 106(1) receives the packet, the packet includes a payload 202. Because the overlay node 106(1) has been programmed by the overlay network controller to steer the packet through a specific path of the underlay, the overlay node 106(1) encapsulates the packet with a destination address 204 which is embedded with (i) one or more SRv6 uSIDs corresponding with the underlay node 104(3) and 104( 4)
Therefore, the above specification does not describe “the destination address including: segment routing headers (SRHs) corresponding to segments of the path in the second network that are configured to steer the packet through the second network and along the path”.
Regarding claim 6, the claim recites “the SRHs are associated with a segment routing over IPv6 (SR v6) protocol,”.
The specification does not support the claim limitation as indicated above. The closest recitation in the published specification US 2024/0380697 A1 stated:
¶0015 - By combining underlay steering bits and overlay termination bits in a single 128-bit destination address allows for the functionality to be able to "steer the underlay" without incurring the overhead of a multiple segment list segment routing header (SRH).
¶0021 - However, it would be inefficient and burdensome to have the overlay data plane element ( overlay tunnel headend node) impose a full SRv6 SRH with so many 128-bit SIDs on outbound packets. Instead, the SRv6 uSID calculator may derive a single 128-bit IPv6 destination address by plucking out the necessary micro-segment (uSID) bits from each 128-bit segment identifier. As such, and continuing the above example, the SRv6 uSID calculator may analyze the provided SRv6 SID list as follows
Therefore, the above specification does not describe “the SRHs are associated with a segment routing over IPv6 (SR v6) protocol”.
Regarding claim 7, the claim recites “wherein the destination address includes a respective SRH for each one of the multiple underlay nodes”.
The specification does not support the claim limitation as indicated above. The closest recitation in the published specification US 2024/0380697 A1 stated:
¶0048 - FIG. 2 illustrates an example 200 in which nodes of an underlay network shift a destination address of a packet to steer the packet through the underlay fabric. For instance, when the overlay node 106(1) receives the packet, the packet includes a payload 202. Because the overlay node 106(1) has been programmed by the overlay network controller to steer the packet through a specific path of the underlay, the overlay node 106(1) encapsulates the packet with a destination address 204 which is embedded with (i) one or more SRv6 uSIDs corresponding with the underlay node 104(3) and 104( 4)
Therefore, the above specification does not describe ““wherein the destination address includes a respective SRH for each one of the multiple underlay nodes”.
Regarding claims 9,16, the claims recite “the destination address including a first portion that precedes a second portion, the first portion including segment routing headers (SRHs) corresponding to segments of the path in the second network that is configured to steer the packet through the second network,”.
The specification does not support the claim limitation as indicated above. The closest recitation in the published specification US 2024/0380697 A1 stated:
¶0015 - By combining underlay steering bits and overlay termination bits in a single 128-bit destination address allows for the functionality to be able to "steer the underlay" without incurring the overhead of a multiple segment list segment routing header (SRH).
¶0021 - However, it would be inefficient and burdensome to have the overlay data plane element ( overlay tunnel headend node) impose a full SRv6 SRH with so many 128-bit SIDs on outbound packets. Instead, the SRv6 uSID calculator may derive a single 128-bit IPv6 destination address by plucking out the necessary micro-segment (uSID) bits from each 128-bit segment identifier. As such, and continuing the above example, the SRv6 uSID calculator may analyze the provided SRv6 SID list as follows
¶0037 - the method may also include determining a destination address for sending the packet along the path to the second node, the destination address including a first portion that precedes a second portion, the first portion including one or more micro segment identifiers (uSIDs) corresponding with one or more respective underlay nodes disposed along the path through the underlay network, the second portion including multiple bits representing a portion of an address that corresponds with the second node
Therefore, the above specification does not describe “the destination address including a first portion that precedes a second portion, the first portion including segment routing headers (SRHs) corresponding to segments of the path in the second network that is configured to steer the packet through the second network”.
Note: The Examiner contacted the Attorney of record – Blake A. Impecoven – Reg. No. 77990 to discuss the support for the limitations above. The examiner did not receive a call back.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1,2,4-17,19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dong et al. Publication No. US 2023/0015960 A1 ( Dong hereinafter) in view of Tulumello et al. “Micro SIDs : a solution for Efficient Representation of Segment IDs in SRv6 Networks” dated in 07/28/2020. (Tulumello hereinafter).
Regarding claim 1,
Dong teaches a method comprising:
receiving, by a first network controller, a request from a second network controller, the request is associated with sending a packet from a first node of a first network to a second node of the first network via a [..] network disposed between the first node and the second node (¶130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node - ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow. ¶ 0007 -improve data forwarding efficiency on the SRv6 network, the FlexE cross-connected path may be established on the SRv6 network Note: Fig.2 &¶ 0007 shows that the first network and second network are SRv6 network in which the packet is sent from first node of the SRV6 network to the second node of the SRV6 network via the same SRv6 network – the examiner also interprets a request as a message received by a control node that indicate resource information which triggers the determination of path information);
determining, by the first network controller and based at least in part on a parameter included in the request, a path through the [..] network that is optimized for sending the packet from the first node to the second node (¶ 130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node – ¶ 0131 - The network node is any network node in a data transmission system. A transmission resource of an interface may be a transmission bandwidth of the interface or a slot resource of the interface. A transmission resource of an interface may include a total transmission bandwidth of the interface or a total quantity of slots of the interface. A relationship between the total transmission bandwidth and the total quantity of slots is the total transmission bandwidth is a product of a transmission bandwidth corresponding to a single slot and the total quantity of slots. An unallocated transmission resource of an interface is a transmission resource that is of the interface and that is not allocated to a forwarding path, ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow);
determining, by the first network controller, a destination address for sending the packet along the path from the first node to the second node [..] (¶ 0120 - A data packet on an SRv6 network is described as follows. The data packet may include an IPv6 header, an SRH, and a payload. The IPv6 header is used to store a source address and a destination address of the data packet. The SRH may include an SID list, a , The plurality of SIDs are arranged in the SID list in a reverse order of locations of the network nodes on the forwarding path. For example, if a forwarding path I is a node I _,.a node 2_,.a node 3, and SIDs of the node I to the node 3 are respectively SIDI to SID3, an SID list corresponding to the forwarding path I is SID3, SID2, and SIDI. The SL is used to record a quantity of network nodes that the data packet further needs to pass through to reach an egress network node on the forwarding path. The egress network node on the forwarding path is a network node indicated by the first SID in the SID list, namely, the last network node on the forwarding path - ¶ 0158 - The data transmission system may support a segment routing policy (SR-Policy) mechanism. The control node may send an SR-Policy that carries the path information to the ingress network node. The forwarding path may be a forwarding path indicated by an SID list having the highest weight in an active candidate path (active CP) in the SR-Policy. To enable the SR-Policy to indicate to establish the forwarding path, the control node may extend an existing type-length-value (tag-length-value, TLV) of the SR-Policy, and a path type field, a path identifier (path ID) field, and a resource requirement field may be newly added to the TLV – ¶ 0160 - After the ingress network node receives the SR-Policy sent by the control node, if the SR-Policy includes the foregoing extended TLV, and the extended TLV indicates to establish the forwarding path, the ingress network node may obtain the path information from the SR-Policy, and establish the forwarding path based on the path information);
sending, by the first network controller the destination address to the second network controller, the destination address to be used to send the packet from the first node to the second node along the path through the [..] network( ¶ 0158 - The control node may send an SR-Policy that carries the path information to the ingress network node. The forwarding path may be a forwarding path indicated by an SID list having the highest weight in an active candidate path (active CP) in the SR-Policy. To enable the SR-Policy to indicate to establish the forwarding path, the control node may extend an existing type-length-value (tag-length-value, TLV) of the SR-Policy, and a path type field, a path identifier (path ID) field, and a resource requirement field may be newly added to the TLV – ¶ 0160 - After the ingress network node receives the SR-Policy sent by the control node, if the SR-Policy includes the foregoing extended TLV, and the extended TLV indicates to establish the forwarding path, the ingress network node may obtain the path information from the SR-Policy, and establish the forwarding path based on the path information).
However, Dong does not explicitly teach that
sending a packet from a first node of a first network to a second node of the first network via a second network disposed between the first node and the second node;
the destination address including: segment routing headers (SRHs) corresponding to segments of the path in the second network that are configured to steer the packet through the second network and along the path, and trailing bits representing a portion of an address that corresponds with the second node and
send the packet from the first node to the second node along the path through the second network
However, Tulumello teaches
sending a packet from a first node of a first network to a second node of the first network via a second network disposed between the first node and the second node (Fig.2, Section IV – A: Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk). ;
the destination address including: segment routing headers (SRHs) corresponding to segments of the path in the second network that are configured to steer the packet through the second network and along the path and trailing bits representing a portion of an address that corresponds with the second node (Section I - SRv6 leverages the Segment Routing Header (SRH) [4] to encode the packet processing program in the IPv6 packet headers as a Segment List, together with optional metadata – Section III - In this case a /32 prefix is chosen as Locator Block for the Micro SIDs (referred to as uSID block). All routers in the topology are assigned a /48 prefix from this micro SID block: fcbb:bbbb::/32. The ingress router R1 applies the Micro SID policy by encoding the address fcbb:bbbb:0800:0700:0200:f00d:: into the outer IPv6 header. This results into a source routing policy that routes the packet through the path R8 ! R7 ! R2, respectively identified by the micro SIDs 0x0800, 0x0700 and 0x0200 and then executes a decap operation. Thus, R1 sends the packet to R8. The packet will cross R4 and R5 that in this case enforce “base” IPv6 forwarding. As soon as R8 receives the packet, it “consumes” its Micro SID identifier in the destination address: (i) the 0x0800 Micro SID is popped from the destination address; (ii) the remaining micro SID list is shifted left by 16 bits; (iii) the End of Container identifier (0x0000) is inserted in the last 16 bits. The resulting IPv6 destination address is fcbb:bbbb:0700:0200:f00d - Since R2 is the last SRv6 router in the path, the destination address of the packet matches the FIB entry with destination fcbb:bbbb:0200:f00d::/64. This rule includes the terminator micro SID f00d which triggers the final End ).
send the packet from the first node to the second node along the path through the second network (Fig.2, Section IV – A: Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 2,
Dong further teaches
wherein the parameter included in the request is at least one of a policy parameter or a performance parameter associated with sending the packet from the first node to the second node (¶ 130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node – ¶ 0131 - The network node is any network node in a data transmission system. A transmission resource of an interface may be a transmission bandwidth of the interface or a slot resource of the interface. A transmission resource of an interface may include a total transmission bandwidth of the interface or a total quantity of slots of the interface. A relationship between the total transmission bandwidth and the total quantity of slots is the total transmission bandwidth is a product of a transmission bandwidth corresponding to a single slot and the total quantity of slots. An unallocated transmission resource of an interface is a transmission resource that is of the interface and that is not allocated to a forwarding path, ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow).
Regarding claim 4,
Dong further teaches
wherein the path through the [..] second network is determined based at least in part on at least one of a network topology or performance data associated with the [..] network(¶ 130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node – ¶ 0131 - The network node is any network node in a data transmission system. A transmission resource of an interface may be a transmission bandwidth of the interface or a slot resource of the interface. A transmission resource of an interface may include a total transmission bandwidth of the interface or a total quantity of slots of the interface. A relationship between the total transmission bandwidth and the total quantity of slots is the total transmission bandwidth is a product of a transmission bandwidth corresponding to a single slot and the total quantity of slots. An unallocated transmission resource of an interface is a transmission resource that is of the interface and that is not allocated to a forwarding path, ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow).
However, Dong does not explicitly teach that the network is a second network.
Tulumello teaches
the path through the second network(Fig.2, Section IV – A: Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 5,
Dong does not explicitly teach
determining a topology graph associated with the second network, the topology graph indicative of a topology of the second network and connections between one or more data plane nodes of the first network and one or more edge nodes of the second network
However, Tulumello teaches
determining a topology graph associated with the second network, the topology graph indicative of a topology of the second network and connections between one or more data plane nodes of the first network and one or more edge nodes of the second network (Fig.2 shows a topology graph showing connections between edge routers and various underlay connection such as Metro Left (ML) , Core (c ) and Metro Right (MR) – Section IV – Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk). The SR Policy ends with a SID that instructs the egress edge router 4 to decapsulate the packet and forward it towards host 2).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 6,
Dong does not explicitly teach
wherein the destination address is a 128-bit internet protocol version six (IPv6) destination address and the SRHs are associated with a segment routing over IPv6 (SR v6) protocol.
However, Tulumello teaches
wherein the destination address is a 128-bit internet protocol version six (IPv6) destination address and the SRHs are associated with a segment routing over IPv6 (SR v6) protocol ( Abstract - In SRv6 (Segment Routing over IPv6 data plane) the segments are represented with IPv6 addresses, which are 16 bytes long. There are some SRv6 service scenarios that may require to carry a large number of segments in the IPv6 packet headers Section I - THE SRv6 (Segment Routing over IPv6) Network Programming framework [1] extends the Segment Routing architecture [2], [3]. According to [1], a packet processing program can be expressed with a sequence of instructions called segments. Each instruction is encoded in a Segment ID (SID) which is 16-byte long (128 bits, the same size of an IPv6 address). SRv6 leverages the Segment Routing Header (SRH) [4] to encode the packet processing program in the IPv6 packet headers as a Segment List, together with optional metadata).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 7,
Dong does not explicitly teach
wherein multiple underlay nodes are disposed along the path through the second network, and wherein the destination address includes a respective SRH for each one of the multiple underlay nodes disposed along the path.
However, Tulumello teaches
wherein multiple underlay nodes are disposed along the path through the second network, and wherein the destination address includes a respective SRH for each one of the multiple underlay nodes disposed along the path (Fig.2 shows a topology graph showing connections between edge routers and various underlay connection such as Metro Left (ML) , Core (c ) and Metro Right (MR) – Section IV – Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk). The SR Policy ends with a SID that instructs the egress edge router 4 to decapsulate the packet and forward it towards host 2 – Section III - The ingress router R1 applies the Micro SID policy by encoding the address fcbb:bbbb:0800:0700:0200:f00d:: into the outer IPv6 header. This results into a source routing policy that routes the packet through the path R8 ! R7 ! R2, respectively identified by the micro SIDs 0x0800, 0x0700 and 0x0200 and then executes a decap operation. Thus, R1 sends the packet to R8. The packet will cross R4 and R5 that in this case enforce “base” IPv6 forwarding. As soon as R8 receives the packet, it “consumes” its Micro SID identifier in the destination address: (i) the 0x0800 Micro SID is popped from the destination address; (ii) the remaining micro SID list is shifted left by 16 bits; (iii) the End of Container identifier (0x0000) is inserted in the last 16 bits. The resulting IPv6 destination address is fcbb:bbbb:0700:0200:f00d – Abstract - The Segment Routing (SR) architecture is based on loose source routing. A list of instructions, called segments can be added to the packet headers, to influence the forwarding
and the processing of the packets in an SR enabled network. In SRv6 (Segment Routing over IPv6 data plane) the segments are represented with IPv6 addresses, which are 16 bytes long. There are some SRv6 service scenarios that may require to carry a large number of segments in the IPv6 packet headers).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 8,
Dong does not explicitly teach
wherein the segments represent a plurality of underlay network nodes.
However, Tulumello teaches
wherein the segments represent a plurality of underlay network nodes (Abstract - The Segment Routing (SR) architecture is based on loose source routing. A list of instructions, called segments can be added to the packet headers, to influence the forwarding and the processing of the packets in an SR enabled network. In SRv6 (Segment Routing over IPv6 data plane) the segments are represented with IPv6 addresses, which are 16 bytes long. There are some SRv6 service scenarios that may require to carry a large number of segments in the IPv6 packet headers – Section I - packet processing program can be expressed with a sequence of instructions called segments. Each instruction is encoded in a Segment ID (SID) which is 16-byte long (128 bits, the same size of an IPv6 address). SRv6 leverages the Segment Routing Header (SRH) [4] to encode the packet processing program in the IPv6 packet headers as a Segment List - Section II - The simplest SRv6 behavior is the End behavior, which is used to enforce a topological waypoint in the path of a packet towards its final destination. In the example shown in Fig. 1, a packet coming from Site A enters the SR domain in node R1, where it is encapsulated in an IPv6 outer packet. Starting from node R1, the packet needs to cross R8, then R7, then it needs to reach R2 where it will be decapsulated and sent to Site B – Section IV – A - When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk). The SR Policy ends with a SID that instructs the egress edge router 4 to decapsulate the packet and forward it towards host 2).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 9,
Dong teaches a system comprising:
one or more processors; and one or more non-transitory computer-readable media storing instructions that, when executed, cause the one or more processors to perform operations comprising: receiving, by a first network controller, a request from a second network controller, the request is associated with sending a packet from a first node of a first network to a second node of the first network via a [..] network disposed between the first node and the second node; (¶130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node - ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow. ¶ 0007 -improve data forwarding efficiency on the SRv6 network, the FlexE cross-connected path may be established on the SRv6 network Note: Fig.2 &¶ 0007 shows that the first network and second network are SRv6 network in which the packet is sent from first node of the SRV6 network to the second node of the SRV6 network via the same SRv6 network – the examiner also interprets a request as a message received by a control node that indicate resource information which triggers the determination of path information);
determining, by the first network controller and based at least in part on a parameter included in the request, a path through the [..] network that is optimized for sending the packet from the first node to the second node; (¶ 130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node – ¶ 0131 - The network node is any network node in a data transmission system. A transmission resource of an interface may be a transmission bandwidth of the interface or a slot resource of the interface. A transmission resource of an interface may include a total transmission bandwidth of the interface or a total quantity of slots of the interface. A relationship between the total transmission bandwidth and the total quantity of slots is the total transmission bandwidth is a product of a transmission bandwidth corresponding to a single slot and the total quantity of slots. An unallocated transmission resource of an interface is a transmission resource that is of the interface and that is not allocated to a forwarding path, ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow).
determining, by the first network controller, a destination address for sending the packet along the path from the first node to the second node (¶ 0120 - A data packet on an SRv6 network is described as follows. The data packet may include an IPv6 header, an SRH, and a payload. The IPv6 header is used to store a source address and a destination address of the data packet. The SRH may include an SID list, a , The plurality of SIDs are arranged in the SID list in a reverse order of locations of the network nodes on the forwarding path. For example, if a forwarding path I is a node I _,.a node 2_,.a node 3, and SIDs of the node I to the node 3 are respectively SIDI to SID3, an SID list corresponding to the forwarding path I is SID3, SID2, and SIDI. The SL is used to record a quantity of network nodes that the data packet further needs to pass through to reach an egress network node on the forwarding path. The egress network node on the forwarding path is a network node indicated by the first SID in the SID list, namely, the last network node on the forwarding path - ¶ 0158 - The data transmission system may support a segment routing policy (SR-Policy) mechanism. The control node may send an SR-Policy that carries the path information to the ingress network node. The forwarding path may be a forwarding path indicated by an SID list having the highest weight in an active candidate path (active CP) in the SR-Policy. To enable the SR-Policy to indicate to establish the forwarding path, the control node may extend an existing type-length-value (tag-length-value, TLV) of the SR-Policy, and a path type field, a path identifier (path ID) field, and a resource requirement field may be newly added to the TLV – ¶ 0160 - After the ingress network node receives the SR-Policy sent by the control node, if the SR-Policy includes the foregoing extended TLV, and the extended TLV indicates to establish the forwarding path, the ingress network node may obtain the path information from the SR-Policy, and establish the forwarding path based on the path information );
sending, by the first network controller the destination address to the second network controller, the destination address to be used to send the packet from the first node to the second node along the path through the [..] network( ¶ 0158 - The control node may send an SR-Policy that carries the path information to the ingress network node. The forwarding path may be a forwarding path indicated by an SID list having the highest weight in an active candidate path (active CP) in the SR-Policy. To enable the SR-Policy to indicate to establish the forwarding path, the control node may extend an existing type-length-value (tag-length-value, TLV) of the SR-Policy, and a path type field, a path identifier (path ID) field, and a resource requirement field may be newly added to the TLV – ¶ 0160 - After the ingress network node receives the SR-Policy sent by the control node, if the SR-Policy includes the foregoing extended TLV, and the extended TLV indicates to establish the forwarding path, the ingress network node may obtain the path information from the SR-Policy, and establish the forwarding path based on the path information).
However, Dong does not explicitly teach
sending a packet from a first node of a first network to a second node of the first network via a second network disposed between the first node and the second node;
destination address for sending the packet along the path to the second node, the destination address including a first portion that precedes a second portion, the first portion including segment routing headers (SRHs) corresponding to segments of the path in the second network that is configured to steer the packet through the second network and along the path, the second portion including multiple bits representing a portion of an address that corresponds with the second node;
send the packet from the first node to the second node along the path through the second network
However, Tulumello teaches
sending a packet from a first node of a first network to a second node of the first network via a second network disposed between the first node and the second node (Fig.2, Section IV – A: Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk). ;
destination address for sending the packet along the path to the second node, the destination address including a first portion that precedes a second portion, the first portion including segment routing headers (SRHs) corresponding to segments of the path in the second network that is configured to steer the packet through the second network and along the path, the second portion including multiple bits representing a portion of an address that corresponds with the second node (Section I - SRv6 leverages the Segment Routing Header (SRH) [4] to encode the packet processing program in the IPv6 packet headers as a Segment List, together with optional metadata – Section III - In this case a /32 prefix is chosen as Locator Block for the Micro SIDs (referred to as uSID block). All routers in the topology are assigned a /48 prefix from this micro SID block: fcbb:bbbb::/32. The ingress router R1 applies the Micro SID policy by encoding the address fcbb:bbbb:0800:0700:0200:f00d:: into the outer IPv6 header. This results into a source routing policy that routes the packet through the path R8 ! R7 ! R2, respectively identified by the micro SIDs 0x0800, 0x0700 and 0x0200 and then executes a decap operation. Thus, R1 sends the packet to R8. The packet will cross R4 and R5 that in this case enforce “base” IPv6 forwarding. As soon as R8 receives the packet, it “consumes” its Micro SID identifier in the destination address: (i) the 0x0800 Micro SID is popped from the destination address; (ii) the remaining micro SID list is shifted left by 16 bits; (iii) the End of Container identifier (0x0000) is inserted in the last 16 bits. The resulting IPv6 destination address is fcbb:bbbb:0700:0200:f00d - Since R2 is the last SRv6 router in the path, the destination address of the packet matches the FIB entry with destination fcbb:bbbb:0200:f00d::/64. This rule includes the terminator micro SID f00d which triggers the final End ).
send the packet from the first node to the second node along the path through the second network (Fig.2, Section IV – A: Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 10,
Dong further teaches
wherein the parameter included in the request is at least one of a policy parameter or a performance parameter associated with sending the packet from the first node to the second node (¶ 130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node – ¶ 0131 - The network node is any network node in a data transmission system. A transmission resource of an interface may be a transmission bandwidth of the interface or a slot resource of the interface. A transmission resource of an interface may include a total transmission bandwidth of the interface or a total quantity of slots of the interface. A relationship between the total transmission bandwidth and the total quantity of slots is the total transmission bandwidth is a product of a transmission bandwidth corresponding to a single slot and the total quantity of slots. An unallocated transmission resource of an interface is a transmission resource that is of the interface and that is not allocated to a forwarding path, ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow).
Regarding claim 11,
Dong does not explicitly teach
wherein the first network is an overlay network and the second network is an underlay network.
However, Tulumello teaches
wherein the first network is an overlay network and the second network is an underlay network (Fig.2, Section IV – A: Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 12,
Dong further teaches
wherein the path through the [..] network is determined based at least in part on at least one of a network topology or performance data associated with the [..] network(¶ 130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node – ¶ 0131 - The network node is any network node in a data transmission system. A transmission resource of an interface may be a transmission bandwidth of the interface or a slot resource of the interface. A transmission resource of an interface may include a total transmission bandwidth of the interface or a total quantity of slots of the interface. A relationship between the total transmission bandwidth and the total quantity of slots is the total transmission bandwidth is a product of a transmission bandwidth corresponding to a single slot and the total quantity of slots. An unallocated transmission resource of an interface is a transmission resource that is of the interface and that is not allocated to a forwarding path, ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow).
However, Dong does not explicitly teach that the network is a second network.
Tulumello teaches
the path through the second network(Fig.2, Section IV – A: Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 13,
Dong does not explicitly teach
determining a topology graph associated with the second network, the topology graph indicative of a topology of the second network and connections between one or more data plane nodes of the first network and one or more edge nodes of the second network
However, Tulumello teaches
determining a topology graph associated with the second network, the topology graph indicative of a topology of the second network and connections between one or more data plane nodes of the first network and one or more edge nodes of the second network (Fig.2 shows a topology graph showing connections between edge routers and various underlay connection such as Metro Left (ML) , Core (c ) and Metro Right (MR) – Section IV – Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk). The SR Policy ends with a SID that instructs the egress edge router 4 to decapsulate the packet and forward it towards host 2).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 14,
Dong does not explicitly teach
wherein an underlay node of the second network, upon receiving the packet, shifts the first portion and second portion of the destination address such that the destination address represents an entire portion of the address that corresponds with the second node.
However, Tulumello teaches
wherein an underlay node of the second network, upon receiving the packet, shifts the first portion and second portion of the destination address such that the destination address represents an entire portion of the address that corresponds with the second node (Section III - . As soon as R8 receives the packet, it “consumes” its Micro SID identifier in the destination address: (i) the 0x0800 Micro SID is popped from the destination address; (ii) the remaining micro SID list is shifted left by 16 bits; (iii) the End of Container identifier (0x0000) is inserted in the last 16 bits. The resulting IPv6 destination address is fcbb:bbbb:0700:0200:f00d:).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 15,
Dong does not explicitly teach
wherein the segments represent a plurality of underlay network nodes.
However, Tulumello teaches
wherein the segments represent a plurality of underlay network nodes (Abstract - The Segment Routing (SR) architecture is based on loose source routing. A list of instructions, called segments can be added to the packet headers, to influence the forwarding and the processing of the packets in an SR enabled network. In SRv6 (Segment Routing over IPv6 data plane) the segments are represented with IPv6 addresses, which are 16 bytes long. There are some SRv6 service scenarios that may require to carry a large number of segments in the IPv6 packet headers – Section I - packet processing program can be expressed with a sequence of instructions called segments. Each instruction is encoded in a Segment ID (SID) which is 16-byte long (128 bits, the same size of an IPv6 address). SRv6 leverages the Segment Routing Header (SRH) [4] to encode the packet processing program in the IPv6 packet headers as a Segment List - Section II - The simplest SRv6 behavior is the End behavior, which is used to enforce a topological waypoint in the path of a packet towards its final destination. In the example shown in Fig. 1, a packet coming from Site A enters the SR domain in node R1, where it is encapsulated in an IPv6 outer packet. Starting from node R1, the packet needs to cross R8, then R7, then it needs to reach R2 where it will be decapsulated and sent to Site B – Section IV – A - When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk). The SR Policy ends with a SID that instructs the egress edge router 4 to decapsulate the packet and forward it towards host 2).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 16,
Dong teaches one or more non-transitory computer-readable media storing instructions that, when executed, cause one or more processors to perform operations comprising:
receiving, by a first network controller, a request from a second network controller, the request is associated with sending a packet from a first node of a first network to a second node of the first network via a [..] network disposed between the first node and the second node; (¶130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node - ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow. ¶ 0007 -improve data forwarding efficiency on the SRv6 network, the FlexE cross-connected path may be established on the SRv6 network Note: Fig.2 &¶ 0007 shows that the first network and second network are SRv6 network in which the packet is sent from first node of the SRV6 network to the second node of the SRV6 network via the same SRv6 network – the examiner also interprets a request as a message received by a control node that indicate resource information which triggers the determination of path information));
determining, by the first network controller and based at least in part on a parameter included in the request, a path through the [..] network that is optimized for sending the packet from the first node to the second node; (¶ 130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node – ¶ 0131 - The network node is any network node in a data transmission system. A transmission resource of an interface may be a transmission bandwidth of the interface or a slot resource of the interface. A transmission resource of an interface may include a total transmission bandwidth of the interface or a total quantity of slots of the interface. A relationship between the total transmission bandwidth and the total quantity of slots is the total transmission bandwidth is a product of a transmission bandwidth corresponding to a single slot and the total quantity of slots. An unallocated transmission resource of an interface is a transmission resource that is of the interface and that is not allocated to a forwarding path, ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow).
determining, by the first network controller, a destination address for sending the packet along the path to the second node (¶ 0120 - A data packet on an SRv6 network is described as follows. The data packet may include an IPv6 header, an SRH, and a payload. The IPv6 header is used to store a source address and a destination address of the data packet. The SRH may include an SID list, a , The plurality of SIDs are arranged in the SID list in a reverse order of locations of the network nodes on the forwarding path. For example, if a forwarding path I is a node I _,.a node 2_,.a node 3, and SIDs of the node I to the node 3 are respectively SIDI to SID3, an SID list corresponding to the forwarding path I is SID3, SID2, and SIDI. The SL is used to record a quantity of network nodes that the data packet further needs to pass through to reach an egress network node on the forwarding path. The egress network node on the forwarding path is a network node indicated by the first SID in the SID list, namely, the last network node on the forwarding path - ¶ 0158 - The data transmission system may support a segment routing policy (SR-Policy) mechanism. The control node may send an SR-Policy that carries the path information to the ingress network node. The forwarding path may be a forwarding path indicated by an SID list having the highest weight in an active candidate path (active CP) in the SR-Policy. To enable the SR-Policy to indicate to establish the forwarding path, the control node may extend an existing type-length-value (tag-length-value, TLV) of the SR-Policy, and a path type field, a path identifier (path ID) field, and a resource requirement field may be newly added to the TLV – ¶ 0160 - After the ingress network node receives the SR-Policy sent by the control node, if the SR-Policy includes the foregoing extended TLV, and the extended TLV indicates to establish the forwarding path, the ingress network node may obtain the path information from the SR-Policy, and establish the forwarding path based on the path information ).
sending, by the first network controller the destination address to the second network controller, the destination address to be used to send the packet from the first node to the second node along the path through the [..] network( ¶ 0158 - The control node may send an SR-Policy that carries the path information to the ingress network node. The forwarding path may be a forwarding path indicated by an SID list having the highest weight in an active candidate path (active CP) in the SR-Policy. To enable the SR-Policy to indicate to establish the forwarding path, the control node may extend an existing type-length-value (tag-length-value, TLV) of the SR-Policy, and a path type field, a path identifier (path ID) field, and a resource requirement field may be newly added to the TLV – ¶ 0160 - After the ingress network node receives the SR-Policy sent by the control node, if the SR-Policy includes the foregoing extended TLV, and the extended TLV indicates to establish the forwarding path, the ingress network node may obtain the path information from the SR-Policy, and establish the forwarding path based on the path information).
However, Dong does not explicitly teach that
sending a packet from a first node of a first network to a second node of the first network via a second network disposed between the first node and the second node;
destination address for sending the packet along the path to the second node, the destination address including a first portion that precedes a second portion, the first portion including segment routing headers (SRHs) corresponding to segments of the path in the second network that is configured to steer the packet through the second network and along the path, the second portion including multiple bits representing a portion of an address that corresponds with the second node;
send the packet from the first node to the second node along the path through the second network
However, Tulumello teaches
sending a packet from a first node of a first network to a second node of the first network via a second network disposed between the first node and the second node (Fig.2, Section IV – A: Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk). ;
destination address for sending the packet along the path to the second node, the destination address including a first portion that precedes a second portion, the first portion including segment routing headers (SRHs) corresponding to segments of the path in the second network that is configured to steer the packet through the second network and along the path, the second portion including multiple bits representing a portion of an address that corresponds with the second node (Section I - SRv6 leverages the Segment Routing Header (SRH) [4] to encode the packet processing program in the IPv6 packet headers as a Segment List, together with optional metadata – Section III - In this case a /32 prefix is chosen as Locator Block for the Micro SIDs (referred to as uSID block). All routers in the topology are assigned a /48 prefix from this micro SID block: fcbb:bbbb::/32. The ingress router R1 applies the Micro SID policy by encoding the address fcbb:bbbb:0800:0700:0200:f00d:: into the outer IPv6 header. This results into a source routing policy that routes the packet through the path R8 ! R7 ! R2, respectively identified by the micro SIDs 0x0800, 0x0700 and 0x0200 and then executes a decap operation. Thus, R1 sends the packet to R8. The packet will cross R4 and R5 that in this case enforce “base” IPv6 forwarding. As soon as R8 receives the packet, it “consumes” its Micro SID identifier in the destination address: (i) the 0x0800 Micro SID is popped from the destination address; (ii) the remaining micro SID list is shifted left by 16 bits; (iii) the End of Container identifier (0x0000) is inserted in the last 16 bits. The resulting IPv6 destination address is fcbb:bbbb:0700:0200:f00d - Since R2 is the last SRv6 router in the path, the destination address of the packet matches the FIB entry with destination fcbb:bbbb:0200:f00d::/64. This rule includes the terminator micro SID f00d which triggers the final End ).
send the packet from the first node to the second node along the path through the second network (Fig.2, Section IV – A: Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 17,
Dong further teaches
wherein the parameter included in the request is at least one of a policy parameter or a performance parameter associated with sending the packet from the first node to the second node (¶ 130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node – ¶ 0131 - The network node is any network node in a data transmission system. A transmission resource of an interface may be a transmission bandwidth of the interface or a slot resource of the interface. A transmission resource of an interface may include a total transmission bandwidth of the interface or a total quantity of slots of the interface. A relationship between the total transmission bandwidth and the total quantity of slots is the total transmission bandwidth is a product of a transmission bandwidth corresponding to a single slot and the total quantity of slots. An unallocated transmission resource of an interface is a transmission resource that is of the interface and that is not allocated to a forwarding path, ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow).
Regarding claim 19,
Dong further teaches
wherein the path through the [..] network is determined based at least in part on at least one of a network topology or performance data associated with the [..] network(¶ 130 A network node sends available transmission resource information to a control node, where the available transmission resource information indicates an unallocated transmission resource of each interface of the network node – ¶ 0131 - The network node is any network node in a data transmission system. A transmission resource of an interface may be a transmission bandwidth of the interface or a slot resource of the interface. A transmission resource of an interface may include a total transmission bandwidth of the interface or a total quantity of slots of the interface. A relationship between the total transmission bandwidth and the total quantity of slots is the total transmission bandwidth is a product of a transmission bandwidth corresponding to a single slot and the total quantity of slots. An unallocated transmission resource of an interface is a transmission resource that is of the interface and that is not allocated to a forwarding path, ¶ 0132 -The control node receives the available transmission resource information from the network node – ¶ 0135 - The control node determines path information of a to-be-established forwarding path based on a service requirement of a service flow).
However, Dong does not explicitly teach that the network is a second network.
Tulumello teaches
the path through the second network(Fig.2, Section IV – A: Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Regarding claim 20,
Dong does not explicitly teach
determining a topology graph associated with the second network, the topology graph indicative of a topology of the second network and connections between one or more data plane nodes of the first network and one or more edge nodes of the second network
However, Tulumello teaches
determining a topology graph associated with the second network, the topology graph indicative of a topology of the second network and connections between one or more data plane nodes of the first network and one or more edge nodes of the second network (Fig.2 shows a topology graph showing connections between edge routers and various underlay connection such as Metro Left (ML) , Core (c ) and Metro Right (MR) – Section IV – Let us consider a service provider offering a VPN service with underlay optimization. The reference topology is depicted in Fig. 2. Hosts 1 and 2 are located in two different sites of a VPN customer. When host 1 sends a packet to host 2, the SR domain ingress router 3 steers it to the egress edge router 4 via an SR Policy that enforces a path through a number of underlay waypoints in Metro L (ML1..MLi), Core (C1..Cj), and Metro R (MR1..MRk). The SR Policy ends with a SID that instructs the egress edge router 4 to decapsulate the packet and forward it towards host 2).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong to include the teachings of Tulumello. The motivation for doing so is to allow the system to reduce the protocol overhead by providing a compact representation of the segment list encoded in the IPv6 routing headers (Tulumello – Section I & IX).
Claims 3,18 are rejected under 35 U.S.C. 103 as being unpatentable over Dong in view of Tulumello further in view of Scholz et al. Publication No. US 2023/0116163 A1 (Scholz hereinafter).
Regarding claim 3,
Dong in view of Tulumello does not explicitly teach
wherein the first network is a software-defined wide area network and the second network is at least one of a service provider network or a transport network.
However, Scholz teaches
wherein the first network is a software-defined wide area network and the second network is at least one of a service provider network or a transport network (¶ 0027 - service provider network 150 provides SD-WAN connectivity to customer networks 140A-140B ("customer networks 140"). A Wide-Area Network (WAN) typically provides connectivity to geographically separate customer networks. An SD-WAN extends Software-Defined Networking (SDN) capabilities to a WAN. SDN allows service provider network 150 to decouple underlying physical network infrastructure from virtualized network infrastructure and applications such that the service provider network 150 may be configured and managed in a flexible and scalable manner – See ¶ 0076).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong in view of Tulumello to include the teachings of Scholz. The motivation for doing so is to allow the system to allow service provider network to decouple underlying physical network infrastructure from virtualized network infrastructure and applications such that the service provider network may be configured and managed in a flexible and scalable manner (Scholz – ¶ 0027).
Regarding claim 18,
Dong in view of Tulumello does not explicitly teach
wherein the first network is an overlay network configured as a software-defined wide area network and the second network is an underlay network configured as at least one of a service provider network or a transport network.
However, Scholz teaches
wherein the first network is an overlay network configured as a software-defined wide area network and the second network is an underlay network configured as at least one of a service provider network or a transport network.. (¶ 0027 - service provider network 150 provides SD-WAN connectivity to customer networks 140A-140B ("customer networks 140"). A Wide-Area Network (WAN) typically provides connectivity to geographically separate customer networks. An SD-WAN extends Software-Defined Networking (SDN) capabilities to a WAN. SDN allows service provider network 150 to decouple underlying physical network infrastructure from virtualized network infrastructure and applications such that the service provider network 150 may be configured and managed in a flexible and scalable manner – See ¶ 0076).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Dong in view of Tulumello to include the teachings of Scholz. The motivation for doing so is to allow the system to allow service provider network to decouple underlying physical network infrastructure from virtualized network infrastructure and applications such that the service provider network may be configured and managed in a flexible and scalable manner (Scholz – ¶ 0027).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Cheng et al. “ Compressed SRv6 Segment List Encoding in SRH”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 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, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445