Multi-segment SD-WAN through cloud DC transit nodes

Abstract

A method implemented by a first cloud gateway (GW). The method includes receiving, from a first customer premises edge device (CPE) over a software defined wide area network (SD-WAN) path, a data packet including an outer layer internet protocol (IP) header and a generic network virtualization encapsulation (GENEVE) header. The GENEVE header includes one or more sub-type length values (TLVs). The method also includes extracting a destination address from the one or more sub TLVs within the GENEVE header. And the method further comprises the steps of updating the destination IP address in the outer-layer IP header to the extracted destination address, and forwarding the data packet to a second CPE according to the updated destination IP address.

Description

Cross Reference to Related Applications

[0001] This patent application claims priority to U.S. Provisional Patent Application No. 63 / 499,850, filed May 3, 2023, entitled “Multi-Segments SD-WAN Via Cloud DCs Transit Nodes” by Linda Dunbar, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0002] The present application relates generally to Software-Defined Wide Area Network (SD-WAN), and more particularly to optimizing stitching of multiple SD-WAN segments via cloud gateways / transit nodes across cloud data centers (DCs). BACKGROUND

[0003] SD-WAN provides a simplified and efficient way for enterprise’s local customer premises equipment (CPE) and private virtual private network (VPN) to establish connectivity to services in cloud DCs. Various methods such as Segment Routing over IPv6 (SRv6) or Multiprotocol Label Switching (MPLS) - Traffic Engineering (TE) can be used to direct traffic through specified nodes. These traffic direction methods are effective when the entire network domain is under one administrative control. However, traffic from local CPE to cloud gateways (GWs) over public internet relies solely on forwarding based on the destination address of the data packet. SUMMARY

[0004] The disclosed aspects / embodiments provide methods for SD-WAN CPE that encapsulate Internet Protocol Security (IPsec) encrypted packets with generic network virtualization encapsulation (GENEVE) encapsulation and direct the IPsec encrypted packets to the nearest cloud GW. These cloud GWs are able to determine whether the packets should traverse the cloud backbone by inspecting the type length value (TLV) in the GENEVE header without decryption. Once it is determined that the packets are to traverse the backbone, the IPsec encrypted payload is directed through the cloud backbone without decryption to the optimal egress cloud GW. These gateways then forward the original IPsec encrypted payload to the destination CPE. The disclosed methods facilitate multiple segments of SD-WAN to connect through the cloud backbone without the cloud GWs decrypting and re-encrypting the payload.

[0005] Further, by directing encrypted traffic to the cloud backbone without decryption and subsequent re-encryption at the cloud GWs, the processing requirements of these GWs can be significantly reduced. This simplified approach maintains the integrity of the encrypted traffic, optimizes processing resources, and improves the overall efficiency of the cloud infrastructure.

[0006] A first aspect relates to a method implemented by a first cloud gateway (gateway, GW), the method comprising: receiving, from a first customer premises edge (CPE) on a Software-Defined Wide Area Network (SD-WAN) path, a packet comprising an outer Internet Protocol (IP) header and a generic network virtualization encapsulation (GENEVE) header, wherein the GENEVE header comprises one or more type length value (TLV); extracting a destination address from the one or more sub-TLVs within the GENEVE header; updating a destination IP address in the outer IP header to the extracted destination address; and forwarding the packet to a second CPE according to the updated destination IP address.

[0007] Optionally, in any of the above aspects, another implementation of the aspect provides that the one or more sub-TLVs include an SD-WAN endpoint sub-TLV, wherein the SD-WAN endpoint sub-TLV includes a destination address of the second CPE.

[0008] Optionally, in any of the above aspects, another implementation of the aspect further includes updating a source IP address in the outer IP header to an address of the first cloud GW based on the determination to forward the data packet to the second CPE, and forwarding the data packet to the second CPE according to the updated source IP address and the updated destination IP address.

[0009] Optionally, in any of the above aspects, another implementation of the aspect provides that the method further includes determining to forward the data packet to a second cloud GW according to a policy of a cloud operator before forwarding the data packet to the second CPE.

[0010] Optionally, in any of the above aspects, another implementation of the aspect further includes determining whether the one or more sub-TLVs include an egress GW sub-TLV, extracting a second destination address of the second cloud GW from the egress GW sub-TLV based on the determination that the one or more sub-TLVs include the egress GW sub-TLV, updating a source IP address in the outer IP header to an address of the first cloud GW, and forwarding the data packet to the second cloud GW according to the updated source IP address and the second destination address.

[0011] Optionally, in any of the above aspects, another implementation of the aspect provides that the first CPE encapsulates the data packet using a GENEVE encapsulation, wherein the data packet is an Internet Protocol Security (IPsec) encrypted data packet.

[0012] Optionally, in any of the above aspects, another implementation of the aspect further includes establishing a bidirectional Internet Protocol Security (IPsec) tunnel between the second cloud GW and the second CPE to forward the data packet to the second CPE.

[0013] Optionally, in any of the above aspects, another implementation of the aspect provides that the GENEVE header is encapsulated in a user datagram protocol (UDP) header.

[0014] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the GENEVE header includes a variable length options field, wherein the variable length options field includes an option class field, a type field, and a variable options data field.

[0015] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the option class field includes a multi-segment SD-WAN option class, and wherein the type field indicates a type of the multi-segment SD-WAN.

[0016] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the variable length options field includes the one or more sub-TLVs, wherein the one or more sub-TLVs include an SD-WAN endpoint sub-TLV and an optional sub-TLV, and wherein the optional sub-TLV includes an SD-WAN tunnel initiator sub-TLV and / or an egress GW sub-TLV.

[0017] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the SD-WAN endpoint sub-TLV includes a length field and a Time to live (TTL) field, the TTL field indicating a number of cloud GWs the data packet has passed through.

[0018] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the SD-WAN tunnel initiator sub-TLV indicates an IP address of the first CPE.

[0019] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the egress GW sub-TLV indicates an address of the second cloud GW used to reach the second CPE.

[0020] Optionally, in any of the preceding aspects, another implementation of the aspect further includes authenticating the data packet using a preconfigured authentication method.

[0021] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first cloud GW is located at a first cloud data center and the second cloud GW is located at a second cloud data center.

[0022] A second aspect relates to a method implemented by a first customer premises edge (CPE), the method comprising: receiving a data packet, wherein the data packet is an Internet Protocol Security (IPsec) encrypted data packet; encapsulating the data packet using a generic network virtualization encapsulation (GENEVE) encapsulation to generate an encapsulated data packet, wherein the encapsulated data packet includes a GENEVE header that includes one or more sub-type length values (TLVs); and forwarding the encapsulated data packet to a second CPE over a Software-Defined Wide Area Network (SD-WAN) path through a cloud gateway (GW).

[0023] Optionally, in any of the above aspects, another implementation of the aspect provides that the one or more sub-TLVs include an SD-WAN endpoint sub-TLV, and wherein the SD-WAN endpoint sub-TLV includes a destination address of the second CPE.

[0024] Optionally, in any of the above aspects, another implementation of the aspect further includes enabling the cloud GW to extract the destination address of the second CPE from the one or more sub-TLVs within the GENEVE header.

[0025] Optionally, in any of the above aspects, another implementation of the aspect provides that the one or more sub-TLVs include an SD-WAN tunnel initiator sub-TLV or an egress GW sub-TLV, wherein the SD-WAN tunnel initiator sub-TLV indicates an address of the first CPE.

[0026] Optionally, in any of the above aspects, another implementation of the aspect provides that the encapsulated data packet further includes an outer IP header, and wherein the outer IP header includes a destination address that indicates an address of a first cloud.

[0027] Optionally, in any of the above aspects, another implementation of the aspect further includes establishing an Internet Protocol Security (IPsec) tunnel between the first CPE and the second CPE to forward the data packet to the second CPE.

[0028] A third aspect relates to a cloud gateway comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the cloud gateway to perform the method of the first aspect.

[0029] A fourth aspect relates to a non-transitory computer-readable medium comprising a computer program product for use by a cloud gateway (GW), the computer program product comprising computer-executable instructions stored in the non-transitory computer-readable medium such that when executed by one or more processors cause the cloud gateway (GW) to perform the method of the first aspect.

[0030] A fifth aspect relates to a cloud gateway (GW) comprising one or more means for performing the method of the first aspect.

[0031] A sixth aspect relates to a first customer premises edge (CPE) comprising: a memory for storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the first customer premises edge (CPE) to perform the method of the second aspect.

[0032] A seventh aspect relates to a non-transitory computer-readable medium comprising a computer program product for use by a first customer premises edge (CPE), the computer program product comprising computer-executable instructions stored in the non-transitory computer-readable medium such that when executed by one or more processors cause the first customer premises edge (CPE) to perform the method of the second aspect.

[0033] An eighth aspect relates to a first customer premises edge (CPE) comprising one or more means for performing the method of the second aspect.

[0034] For clarity, any of the above embodiments can be combined with any one or more of the other embodiments described above to create new embodiments within the scope of the present application.

[0035] These and other features and advantages will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims. BRIEF DESCRIPTION OF DRAWINGS

[0036] For a more complete understanding of the present application, reference is made to the following description taken in conjunction with the accompanying drawings and specific embodiments in which like reference numerals indicate like parts.

[0037] Figure 1A is a schematic diagram of exemplary multi-segment SD-WAN stitching by a single cloud GW provided by embodiments of the present application.

[0038] Figure 1A is a schematic diagram of exemplary multi-segment SD-WAN stitching by a cloud backbone provided by embodiments of the present application.

[0039] Figure 2A is a schematic diagram of the format of a GENEVE packet for a single-hop cloud GW provided by embodiments of the present application.

[0040] Figure 2B is a schematic diagram of the format of a GENEVE packet for a multi-hop cloud GW provided by embodiments of the present application.

[0041] Figure 3 is a schematic diagram of the format of a GENEVE header provided by embodiments of the present application.

[0042] Figure 4 is a schematic diagram of the format of a multi-segment SD-WAN option class provided by embodiments of the present application.

[0043] Figure 5 is a schematic diagram of the format of a SD-WAN endpoint sub-TLV provided by embodiments of the present application.

[0044] Figure 6A is a schematic diagram of the format of a SD-WAN tunnel source endpoint sub-TLV provided by embodiments of the present application.

[0045] Figure 6B is a schematic diagram of the format of a SD-WAN egress GW sub-TLV provided by embodiments of the present application.

[0046] Figure 7A is a flowchart of a method performed by a cloud GW provided by embodiments of the present application.

[0047] Figure 7B is a flowchart of a method performed by a first CPE provided by embodiments of the present application.

[0048] Figure 8 is a schematic diagram of network elements provided by embodiments of the present application. DETAILED DESCRIPTION

[0049] It should be understood at the outset that, although illustrative implementations of one or more embodiments are provided below, the disclosed systems and / or methods can be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including exemplary design and implementations set forth in this description, but can be modified in various ways.

[0050] SD-WAN is a convenient and efficient way to connect local CPEs to services in a cloud DC. Enterprises have multiple options to connect to a cloud DC, such as: (1) a direct interconnection model, (2) a direct interconnection model with virtual appliances in the cloud for the enterprise, (3) an indirect interconnection model over an SD-WAN path, and (4) a managed hybrid WAN model using the enterprise’s existing VPN connections. For an enterprise branch that utilizes private VPN circuits to connect to a cloud GW over an internet exchange point (IXP), there is no need to establish an IPsec path between the local CPE and the cloud GW to enable extension to the cloud DC. SD-WAN can establish multiple links (also referred to as paths) from the same SD-WAN branch CPE to the cloud GW, where each link represents a dual-tunnel connection from a unique public IP of the SD-WAN CPE to two different instances of the cloud GW. Using the cloud GW to interconnect these local CPEs eliminates the need to manage multiple ISP’s links / paths between the CPEs.

[0051] To ensure security, traffic between the enterprise’s internal CPEs remains encrypted and inaccessible to outside parties, including the cloud DC. To enable encrypted packets to pass through the cloud DC, the packet header includes information indicating the intended routing of the packet. Since the IPsec security association (SA) between CPEs is only maintained between the CPEs, the cloud GW has no access to the IPsec SA, so encrypted packets need to go through a tunnel between the source CPE and the ingress cloud GW. This tunnel can involve an additional IPsec layer, which adds processing overhead to the cloud GW to only decrypt the outer IPsec tunnel for the purpose of directing the encrypted payload.

[0052] The present disclosure presents techniques for integrating or stitching multiple SD-WAN segments through a transit node across a cloud DC. Embodiments of the stitching architecture are implemented by CPEs that encapsulate IPsec encrypted packets with GENEVE encapsulation and direct the IPsec encrypted packets to the nearest cloud GW. These gateways are able to determine whether a packet should traverse the cloud backbone by inspecting the sub-TLV in the GENEVE header without the need for decryption. Once it is determined that a packet is to traverse the backbone, the IPsec encrypted payload is directed through the cloud backbone without decryption and to the optimal egress cloud GW. These gateways then forward the original IPsec encrypted payload to the destination CPE. The disclosed methods facilitate multiple segments of SD-WAN to be connected through a cloud backbone without the need for the cloud GWs to decrypt and re-encrypt the payload.

[0053] Furthermore, by directing encrypted traffic to the cloud backbone without the need for decryption and subsequent re-encryption at the cloud GWs, the processing requirements of these GWs can be significantly reduced. This simplified approach maintains the integrity of encrypted traffic, optimizes processing resources, and improves the overall efficiency of the cloud infrastructure.

[0054] Figure 1A is a schematic diagram of an exemplary multi-segment SD-WAN stitching through a single cloud GW provided by embodiments of the present disclosure. As shown, the SD-WAN network 100A includes multiple CPEs 102-110, a VPN 112, an edge GW 114, and a cloud DC 116 (often referred to as a data center or cloud) that includes a cloud GW 118 (often referred to as a transit node) that connects to a cloud service 119 (e.g., a virtual network (VNet) or a virtual private cloud (VPC). While five CPEs 102-110 are shown in the network 100A, more or fewer CPEs can be included in actual applications. For ease of discussion, all of the CPEs 102-110 are assigned alphabetical names. For example, the first CPE 102 is named CPE1, the second CPE 104 is named CPE2, the third CPE 106 is named CPE3, the fourth CPE 108 is named CPE4, and the fifth CPE 110 is named CPE5. In one embodiment, CPE1-CPE5 can be network devices (e.g., routers or client gateway devices) located at a customer’s (e.g., an end user’s) site or various branch offices of an enterprise that connect to the cloud DC 116 to provide certain functionality, namely IPsec encryption, routing functionality, and / or SD-WAN functionality.

[0055] In one embodiment, the edge GW 114 can be connected to the cloud GW 118 through one or more secure connections. In one embodiment, one or more CPEs (CPE1-CPE5) can be connected to the edge GW 114 and the VPN 112 through one or more provider networks. Alternatively, in one embodiment, one or more CPEs (CPE1-CPE5) can be connected to the VPN 112 through the public Internet using secure tunnels (e.g., using Internet Protocol Security (IPsec)) to establish secure connections with the VPN 112. Although Figure 1A Although only one edge GW 114 and VPN 112 are shown in the middle, the cloud DC 116 can have multiple edge GWs and VPNs. The edge GW 114 serves as a termination point for VPN connections initiated from the CPEs 102-110, provides routing functionality, and provides Quality-of-Service (QoS) for packets coming in and out of the VPN 112.

[0056] In one embodiment, VPN 112 communicates with CPEs 102-110 over IXP to connect the CPEs to cloud GW 118. For example, cloud GW 118 connects client traffic from CPE1 to CPE2 via VPN 112 over an IPsec tunnel. In another embodiment, cloud GW 106 connects client traffic from CPE1 to CPE2 directly over an IPsec tunnel. IPsec tunnels can be established between CPEs 102-110, edge GW 114, or cloud GW 118 to create secure communication channels. These IPsec tunnels encrypt data traffic between endpoints. To ensure confidentiality, integrity, and availability of communications between CPEs 102-110, traffic between CPEs 102-110 should be encrypted by an IPsec Security Association (SA) when traversing the public Internet. In one embodiment, IPsec tunnel is a bidirectional IPsec tunnel 120 between CPE1 and cloud GW 118, where traffic from CPE1 to cloud GW 118 uses a first IPsec SA1 and traffic from cloud GW 118 to CPE1 uses a second IPsec SA2. In one embodiment, IPsec tunnel is a bidirectional IPsec tunnel 122 between CPE2 and cloud GW 118, where traffic from CPE2 to cloud GW 118 uses a third IPsec SA3 and traffic from cloud GW 118 to CPE2 uses a fourth IPsec SA4. In one embodiment, when a data packet / client traffic with a source CPE1 address prefix of 11.1.1.x needs to be transmitted to a destination CPE2 with an address prefix of 10.1.1.x, CPE1 and CPE2 can use a fifth IPsec SA5 to establish a bidirectional IPsec tunnel for CPE1 to CPE2 traffic and a sixth IPsec SA6 to establish a bidirectional IPsec tunnel for CPE2 to CPE1 traffic.

[0057] From the above, it should be understood that communications between CPEs are encrypted using IPsec SAs when traversing the public Internet to maintain confidentiality, integrity, and availability. Therefore, if cloud GW 118 does not need to decrypt and re-encrypt transiting IPsec encrypted traffic between CPEs, the processing burden on cloud GW 118 can be significantly reduced when traffic between CPEs of an enterprise does not terminate within cloud DC 116. The present disclosure describes mechanisms for IPsec encrypted traffic between CPEs 102-110 to traverse cloud GW 118 without decryption and re-encryption by cloud GW 118.

[0058] For ease of discussion, assume that all CPEs 102-110 are under one Internal Border Gateway Protocol (iBGP) administrative domain to enable more efficient and effective routing decisions and better control of traffic flow and security. In one embodiment, a Route Reflector (RR) controller can be used to provide route exchange among the CPEs.

[0059] Figure 1B is a schematic diagram of an exemplary multi-segment SD-WAN stitching over a cloud backbone network provided by embodiments of the present application. As Figure 1B illustrated, geographically distant enterprise branches (e.g., CPEs) establish SD-WAN paths within SD-WAN network 100B to connect to their corresponding cloud GWs to access cloud services in different geographical locations or cloud DC sites. These branches can be interconnected together with a cloud backbone network. The reason for interconnecting these branches with a cloud backbone network is similar to interconnecting multiple branches through a single cloud GW as described above. As Figure 1B illustrated, SD-WAN network 100B includes multiple cloud data centers, e.g., 116A and 116B. Each cloud data center 116A and 116B has a corresponding cloud GW1 118 and cloud GW2 124. Although two cloud DCs 116A and 116B are shown in network 100B, more or less cloud DCs can be included in actual applications. Figure 1B The behavior of the components of SD-WAN network 100B as illustrated is similar to the behavior of the components of SD-WAN network 100A as illustrated. For brevity, detailed descriptions of these elements are not repeated here. Figure 1A The behavior of the components of SD-WAN network 100B as illustrated is similar to the behavior of the components of SD-WAN network 100A as illustrated. For brevity, detailed descriptions of these elements are not repeated here.

[0060] In one embodiment, traffic to and from geographically distant CPEs (e.g., CPE1 and CPE10) can traverse multiple cloud GWs through a cloud backbone network. As Figure 1BAs shown, IPsec tunnels can be established between CPEs 102-108 and CPE 110B, edge GW 114 or cloud GWs 118 and 124 to create secure communication channels. Local CPEs are aware of each other's addresses and the address of the nearest cloud GW. Intermediate cloud GWs within the cloud DC that cannot reach the local CPEs can be hidden from the CPEs. IPsec tunnels can be established between CPEs. These IPsec tunnels encrypt data traffic between the endpoints. To ensure confidentiality, integrity, and availability of communication between CPEs, traffic between CPEs should be encrypted by IPsec SAs when traversing the public Internet. In one embodiment, the IPsec tunnel is a bidirectional IPsec tunnel 120 between CPE1 and cloud GW 118, where traffic from CPE1 to cloud GW 118 uses a first IPsec SA1 and traffic from cloud GW 118 to CPE1 uses a second IPsec SA2. In one embodiment, the IPsec tunnel is a bidirectional IPsec tunnel 126 between CPE10 and cloud GW2 124, where traffic from CPE10 to cloud GW 124 uses a third IPsec SA3 and traffic from cloud GW 124 to CPE10 uses a fourth IPsec SA4. In one embodiment, when a data packet / client traffic from source CPE1 with address prefix 11.1.1.x is transmitted to destination CPE2 with address prefix 10.1.1.x, CPE1 and CPE10 can establish a bidirectional IPsec tunnel for CPE1 to CPE10 traffic using a fifth IPsec SA5 and for CPE10 to CPE1 traffic using a sixth IPsec SA6. As shown, traffic from CPE1 to CPE10 enters cloud DC 116A through cloud GW1 118 and exits cloud DC 116A through cloud GW2 124 destined for CPE10. The multiple cloud GWs between cloud GW1 and cloud GW2 are not visible to the CPEs. Figure 2B As shown, traffic from CPE1 to CPE10 enters cloud DC 116A through cloud GW1 118 and exits cloud DC 116A through cloud GW2 124 destined for CPE10. The multiple cloud GWs between cloud GW1 and cloud GW2 are not visible to the CPEs.

[0061] For ease of discussion, assume that all CPEs 102-108 and CPE 110B are under one iBGP administrative domain for more efficient and effective routing decisions and better control of traffic flow and security. In one embodiment, a Route Reflector (RR) controller can be used to provide route exchange between CPEs. CPEs inform the peer of their corresponding cloud GW addresses.

[0062] Generally, for Cloud GW 118 and Cloud GW 124, correctly labeling packet headers is crucial to distinguish between packets requiring decryption for internal hosts / services and relay packets to be forwarded to the destination branch CPE. In this invention, the GENEVE encapsulation, widely supported by most cloud service providers, is chosen as the encapsulation header so that the Cloud GW can route IPsec encrypted packets between CPEs without decryption. In one embodiment, other types of encapsulation headers (e.g., Segment Routing Header (SRH), UDP Options Header, etc.) may be available for the Cloud GW to route IPsec encrypted packets between CPEs without decryption.

[0063] Figure 2A This is a schematic diagram of the data packet header 200A for a single-hop cloud GW provided in an embodiment of the present invention. Cloud GW 118 (e.g.) Figure 1A The GENEVE tunneling protocol (as shown) can understand the packet header 200A but does not initiate or terminate packets. Only the tunnel endpoints encapsulate and decapsulate packets (e.g., Ethernet frames or IP datagrams) in the GENEVE header. As described in the disclosed method, the GENEVE tunneling protocol aims to achieve control plane independence between tunnel endpoints in a virtualized network environment. The protocol can include metadata encoded in TLV format as an option header, providing flexibility for current and future networks. Figure 1A As shown, the cloud GW 118 connects client traffic from CPE1 to CPE2 via an IPsec tunnel, or forwards data packets from CPE1 to CPE2. CPE1 initiates communication by generating GENEVE-encapsulated data packets destined for CPE2.

[0064] like Figure 2AAs shown, when CPE1 initiates communication with CPE2, CPE1 encapsulates the received IP packet to generate an encapsulated packet. The encapsulated packet includes outer IP header 202, outer user datagram protocol (UDP) header 204, GENEVE header 206, a variable length options set field 208 immediately following, encapsulating security payload (ESP) header 210, and authentication data 212 as it traverses the SD-WAN network (e.g., network 100A). Outer IP header 202 includes a source IP address, a destination IP address, and a protocol, where the source IP address indicates the IP address of the sender, the destination IP address indicates the IP address of the intended recipient, and the protocol indicates the protocol used in the data portion of the packet. As such, CPE1 sets its own IP address as the source IP address, sets the IP address of CPE2 as the destination IP address, and specifies the protocol in outer IP header 202 as UDP with a value of 17. The value of 17 indicates that the data portion of the packet communicates using the UDP protocol. Outer IP header is followed by outer UDP header 204. Outer UDP header 204 includes a destination port and a source port selected by the initiating tunnel endpoint (i.e., CPE1). The source port should be the same for all packets belonging to a single encapsulation flow to prevent reordering due to use of different paths. The destination port is assigned port number 6081 to indicate that the packet is GENEVE encapsulated. By assigning port number 6081 to the destination port, the cloud GW can identify that the incoming packet is GENEVE encapsulated and process the packet accordingly. GENEVE header 206 is encapsulated in UDP header 204 based on IP version 4 (IPv4) or IP version 6 (IPv6).

[0065] GENEVE header 206 is a tunnel header that includes fields including a variable length options class and a protocol type. As Figure 2AAs shown, the variable length option class includes a new GENEVE option class dedicated for multi-segment SD-WAN, i.e., a multi-segment SD-WAN option class indicating multi-segment SD-WAN related sub-TLVs are encoded in the GENEVE header 206. The protocol type includes a value of 50, indicating that the ESP header 210 is to be processed next. Subsequently, the GENEVE header 206 is followed by a variable length option set field 208 in TLV format. Each option consists of a 4-byte option header and a variable number of option data interpreted according to the type. A new sub-TLV, SD-WAN endpoint sub-TLV, is described herein for indicating the destination of the IPsec tunnel. For example, for an SD-WAN IPsec SA from CPE1 to CPE2, the SD-WAN endpoint sub-TLV 208 of the GENEVE header 206 has the IP address of the destination CPE2 (e.g., CPE2 in Figure 1A The standard format of the GENEVE header is described in more detail in Internet Engineering Task Force (IETF) Request for Comments (RFC) 8926, entitled “GENEVE: Generic Network Virtualization Encapsulation,” by J. Gross et al., published November 2020.

[0066] Subsequently, the GENEVE header is further encrypted using the ESP protocol. The ESP header 210 is inserted between the outer IP header 202 and the encrypted payload IP header. The ESP header 210 includes a Security Parameters Index (SPI) field and a sequence number field. The packet header 200A also includes a payload IP header and a TCP header, which includes the encrypted data. The authentication data 212 is a variable length field including an integrity check value (ICV) computed by subtracting the authentication data from the ESP packet. The standard format of the ESP header is described in more detail in Internet Engineering Task Force (IETF) Request for Comments (RFC) 4303, entitled “IP Encapsulating Security Payload (ESP),” by S. Kent et al., published December 2005.

[0067] Description of traffic flow from CPE1 to CPE2 In one embodiment, sender CPE 1 checks the destination address in outer IP header 202 of the data packet, consults its routing table to determine the next hop, and forwards the data packet over IPsec tunnel 120 to cloud GW 118 as shown. In one embodiment, upon receiving a GENEVE encapsulated packet of GENEVE protocol type = 50 (ESP), cloud GW 118 authenticates the packet using a preconfigured authentication method. After authentication, cloud GW 118 terminates outer IP header 202 and verifies the address encoded in SD-WAN endpoint sub-TLV 208 within GENEVE header 206. In one embodiment, when the address in SD-WAN endpoint sub-TLV 208 is reachable without another cloud GW / transit node, cloud GW 118 replaces the destination address in outer IP header 202 with the address encoded in the sub-TLV (i.e., CPE2 address), updates the source IP address in outer IP header 202 to the address of the first cloud GW, and forwards the data packet to the destination CPE2 over IPsec tunnel 122 according to the updated source IP address and updated destination IP address as shown. Figure 1A Figure 1A

[0068] In one embodiment, when cloud operator’s internal policy determines that another transit node is needed, cloud GW 118 changes the destination IP address in outer IP header 202 to the address pointing to the next cloud GW / transit node (e.g., cloud GW2 124 as shown). The process and policy of selecting the next cloud GW / transit node are internal matters of the cloud operator. Figure 1B

[0069] Data authentication and integrity check of cloud GW / transit node Since the IPsec SA has encrypted the client payload between CPEs, the cloud GW does not need to decrypt and re-encrypt the payload when relaying the payload to the destination CPE. However, since the traffic goes through an untrusted network, data authentication and integrity check are needed, and the cloud GW will perform integrity check or digital signature on the GENEVE header portion. In one embodiment, cloud GW 118 can discard all data packets whose source address or value in the sub-TLV of GENEVE header is not recognized or registered to prevent unauthorized users from using the cloud service. Cloud GW 118 can confirm the value of the SD-WAN endpoint sub-TLV and discard the data packet if the value of the SD-WAN endpoint sub-TLV is an unpayed (or unregistered) address.

[0070] Explanation of traffic from private VPN to IPsec tunnel ​​​In one embodiment, cloud GW 118 connects client traffic from CPE1 to CPE2 via private VPN 112 through an IPsec tunnel. If the destination is within VPN 112, CPE1 forwards the packet to cloud GW through VPN 112. Here, the packet is not encrypted. VPN 112 forwards packet 200A to edge GW 114. Edge GW 114 inspects the received packet 200A and performs deep packet inspection. Once the packet is processed and deemed safe, edge GW 114 forwards the packet to cloud GW 118. Upon receiving the GENEVE encapsulated packet with multi-segment SD-WAN option 208, cloud GW 118 extracts the destination CPE from GENEVE header 206 and encrypts the packet using IPsec SA2 to forward to the destination (i.e., CPE2). GENEVE header 206 is carried to CPE2.

[0071] Figure 2B is a diagram illustrating a format of a packet header 200B for multi-hop cloud GWs provided by embodiments of the present disclosure. The disclosed method for SD-WAN CPE encapsulates IPsec encrypted packets using GENEVE encapsulation and sends the IPsec encrypted packets to their nearest cloud GW, which can direct the IPsec encrypted payload through the cloud backbone and onward to the egress cloud GW without decryption, and then the egress cloud GW forwards the original IPsec encrypted payload to the destination CPE. As shown in Figure 1B cloud GW 118 and cloud GW 124 connect client traffic from CPE1 to CPE10, or forward packets from CPE1 to CPE10, through IPsec tunnels. CPE1 initiates communication by generating a GENEVE encapsulated packet destined for CPE10.

[0072] As shown in Figure 2B When CPE1 initiates communication with CPE2, CPE1 encapsulates the received IP packet, which includes outer IP header 214, GENEVE header 216, a variable length options set field 218 and 220 immediately following, encapsulating security payload (ESP) header 222, and authentication data 224, as the packet traverses the SD-WAN network (e.g., SD-WAN network 100B). CPE1 sets its own IP address as the source IP address, sets cloud GW1 118 as the destination IP address, and specifies the protocol as UDP with a value of 17 in outer IP header 214. The value of 17 indicates that the data portion of the packet communicates using the UDP protocol. GENEVE header 216 is encapsulated in the UDP header based on IPv4 or IPv6.

[0073] The GENEVE header 216 is a tunnel header that includes fields including a variable length option class and a protocol type. The variable length option class includes a new GENEVE option class, i.e., a multi-segment SD-WAN option class indicating that multi-segment SD-WAN related sub-TLVs are encoded in the GENEVE header 216. The protocol type includes a value 50 to indicate that the ESP header 222 is to be processed next. Subsequently, the GENEVE header 216 is followed by a variable length option set field in TLV format. Each option consists of a 4-byte option header and a variable number of option data interpreted according to the type. A new sub-TLV type is described here, i.e., the SD-WAN endpoint sub-TLV 218, to indicate the destination of the IPsec tunnel. For example, the SD-WAN endpoint sub-TLV 218 has the address of CPE10. In one embodiment, for the multi-segment SD-WAN scenario over the cloud backbone network as shown in Figure 2B The initiator CPE1 can use the egress GW sub-TLV to specify the egress cloud GW for reaching the destination CPE10, in one embodiment. The initiator CPE1 can use the SD-WAN tunnel source endpoint sub-TLV to indicate the initiating CPE of the IPsec tunnel, in one embodiment. The SD-WAN tunnel source endpoint sub-TLV in the GENEVE header can assist the cloud transit node to apply the appropriate policy when forwarding the packet 200B. However, it is optional to include the egress GW sub-TLV and the tunnel source endpoint sub-TLV in the GENEVE header. The standard format of the GENEVE header is described in more detail in the IETF document RFC 8926, “GENEVE: Generic Network Virtualization Encapsulation,” by J. Gross et al., November 2020.

[0074] Subsequently, the GENEVE header is further encrypted using the ESP protocol. The ESP header 222 includes a Security Parameters Index (SPI) field, a sequence number field, a payload IP header field, and a TCP header field. The payload IP header field and the TCP header field include encrypted data. The authentication data 224 is a variable length field that includes an integrity check value (ICV) computed by subtracting the authentication data from the ESP packet. For brevity, these fields are not described in detail again here. The standard format of the ESP header is described in more detail in IETF document RFC 4303, entitled “IP Encapsulating Security Payload (ESP)”, by S. Kent et al., published in December 2005.

[0075] Explanation of traffic flow from CPE1 to CPE10 through the cloud backbone In one embodiment, the sender CPE1 checks the destination address in the outer IP header 214 of the packet header 200B, consults its routing table to determine the next hop, and forwards the packet through the IPsec tunnel 120 to the cloud GW 118 as shown. Figure 1B In one embodiment, upon receiving the GENEVE encapsulated packet of GENEVE protocol type = 50 (ESP), the cloud GW 118 authenticates the packet using a pre-configured authentication method. After authentication, the cloud GW 118 terminates the outer IP header 214 and verifies the address encoded in the SD-WAN endpoint sub-TLV 218 within the GENEVE header 216.

[0076] In one embodiment, the cloud GW 118 decides whether to forward the packet to another cloud GW or directly to the destination CPE based on the address encoded in the SD-WAN endpoint sub-TLV 218. When the cloud GW 118 decides to send the packet directly to the destination CPE2, the cloud GW 118 forwards the IPsec encapsulated packet from CPE1 to CPE2.

[0077] In another embodiment, when the cloud GW 118 decides to send the packet to a second cloud GW 124, or when the internal policy of the cloud operator determines that another transit node is needed, the cloud GW 118 determines whether an egress GW sub-TLV exists in the GENEVE header.

[0078] In one embodiment, when the egress GW sub-TLV is present in the GENEVE header, the cloud GW 118 performs the following operations: (1) constructs an inner encapsulation header of the cloud backbone, which can be GENEVE or a proprietary encapsulation header of the cloud backbone, (2) extracts the destination address of the cloud backbone encapsulation header, i.e., the destination address of the egress GW (e.g., cloud GW2), from the egress GW sub-TLV, (3) forwards the packet with the inner encapsulation header of the cloud backbone to the egress GW. In one embodiment, the encapsulation header of the cloud backbone can construct its own encapsulation header or optionally include the original outer header sent from the initiating CPE (i.e., CPE1). In one embodiment, the egress GW removes the cloud backbone encapsulation header and sends the IPsec encapsulated packet from CPE1 to CPE2. The process and policy of selecting the next cloud GW / transit node are internal matters of the cloud operator. The GENEVE header 216 remains unchanged.

[0079] In one embodiment, the source CPE1 can specify a list of logical cloud GW / transit nodes. These logical transit nodes do not have to be directly connected. There can be multiple cloud-internal transit nodes that are not visible to the CPEs.

[0080] Figure 3 is a schematic diagram of the format of the GENEVE header 300 provided by embodiments of the present application. The GENEVE header 300 includes a version field 302, an option length field 304, an O field 306, a C field 308, a reserved field 310, a protocol type field 312, a virtual network identifier (VNI) field 314, a reserved field 316, and a variable length option field 318. The version field 302 refers to the version information of the GENEVE header 300. The option length field 304 refers to the length of the variable length option field 318. The O field 306 refers to OAM packets, including control messages. The C field 308 refers to the presence of critical options. The reserved field 310 refers to a reserved field that is set to zero on transmission and ignored on reception. The protocol type field 312 refers to the type of protocol data unit that appears after the GENEVE header 300. For example, as shown in FIG. 2, the GENEVE header 202 includes a value of 50 in its protocol type field, indicating that the ESP header is to be processed next. The VNI field 314 refers to an identifier of a unique element of a virtual network. The reserved field 316 refers to a reserved field that is set to zero on transmission and ignored on reception. The variable length option field 318 is presented in a type length value (TLV) format. Each option consists of a 4-byte option header and a variable number of option data interpreted according to the type. For example, as shown in FIG. 2, the GENEVE header 202 includes a sub-TLV 206 that includes a type field 208, a length field 210, and a value field 212. The type field 208 refers to the type of the sub-TLV 206. The length field 210 refers to the length of the value field 212. The value field 212 refers to the value of the sub-TLV 206. For example, as shown in FIG. 2, the value field 212 of the sub-TLV 206 includes a value of 1, indicating that the sub-TLV 206 is an egress GW sub-TLV. Figure 2A or Figure 2BAs shown, the GENEVE header 202 is followed by a new sub-TLV indicating the destination of the IPsec tunnel, namely the SD-WAN endpoint sub-TLV. For example, as shown in Figure 2A As shown, the SD-WAN endpoint sub-TLV 208 has the address of CPE2, as Figure 2B As shown, the SD-WAN endpoint sub-TLV 218 has the address of CPE10. The GENEVE header is described in more detail in IETF document RFC 8926, “GENEVE: Generic Network Virtualization Encapsulation,” by J. Gross et al., November 2020.

[0081] Figure 4 is a schematic diagram of a format 400 of a multi-segment SD-WAN option class provided by embodiments of the present invention. As shown, the format 400 includes an option field 402, a type field 404, an R field 406, a length field 408, and a variable length option data field. The option field 402 includes a new GENEVE option class, namely a multi-segment SD-WAN option class indicating that multi-segment SD-WAN related sub-TLVs are encoded in the GENEVE header. The type field 404 indicates the format of the data included in the option field 402. The type field 404 indicates various types of multi-segment SD-WAN. For example, a type field 404 with a value of 1 indicates a single-hop transit SD-WAN, a type field 404 with a value of 2 indicates a multi-hop transit SD-WAN with an explicitly specified egress cloud GW, and a type field 404 with a value of 3 indicates a multi-hop transit SD-WAN without a specified egress cloud GW. The R field 406 is 3 bits indicating control flags reserved for future use. The R field 406 can be zeroed on transmission and ignored on reception. The length field 408 indicates the length of the option field 402. The variable length option data field can be interpreted according to the type field 404. The variable length option data field can include an SD-WAN tunnel endpoint sub-TLV type 410 and / or a plurality of optional sub-TLVs, such as an SD-WAN tunnel initiator sub-TLV type 412, an egress GW sub-TLV 414, and optional TLV objects (variable) 416. These GENEVE options are primarily for initiation and processing by the tunnel endpoints (e.g., CPEs). However, these options can also be processed by transit devices / cloud GWs along the tunnel path.

[0082] Figure 5is a diagram of a format 500 of an SD-WAN endpoint sub-TLV provided by embodiments of the present application. As shown, the format 500 includes an SD-WAN endpoint field 502, a length field 504, a reserved field 506, a time to live (TTL) field 508, an SD-WAN destination address family field 510, and an SD-WAN point address field 512. The SD-WAN endpoint field 502 indicates the destination CPE of the IPsec tunnel. For example, as shown in Figure 2A for an SD-WAN IPsec SA from CPE1 to CPE2, the tunnel endpoint sub-TLV 208 of the GENEVE header 206 has the IP address of CPE2. The TTL field 508 is set by the SD-WAN tunnel initiator (e.g., CPE1). Each transit node or transit region / zone (i.e., visible to the CPEs) can decrement the TTL field 508 so that the destination CPE can know the number of logical transit nodes (cloud regions or zones) that the packet has passed through. The TTL field 508 can also be used by the enterprise to set a maximum number of transit nodes / regions that the packet can pass through.

[0083] Figure 6A is a diagram of a format 600A of an SD-WAN tunnel source endpoint sub-TLV provided by embodiments of the present application. As shown, the format 600 includes an SD-WAN source end field 602, a length field 604, a reserved field 606, an SD-WAN source address family field 608, and an SD-WAN tunnel source endpoint address field 610. The SD-WAN source end field 602 indicates the initiating CPE of the IPsec tunnel. For example, for an SD-WAN tunnel between CPE1 and CPE10, the tunnel initiator sub-TLV of the GENEVE header indicates the address pointing to CPE1. The tunnel source endpoint sub-TLV in the GENEVE header can assist the cloud transit nodes in applying the appropriate policies when forwarding the packet. However, the inclusion of the tunnel source endpoint sub-TLV in the GENEVE header is optional.

[0084] Figure 6B is a diagram of a format 600B of an SD-WAN egress GW sub-TLV provided by embodiments of the present application. As shown, the format 600B includes an SD-WAN egress GW field 612, a length field 614, a reserved field 616, an egress GW address family field 618, and an egress GW address field 620. For a multi-segment SD-WAN scenario through a cloud backbone, the initiator CPE can use the egress GW sub-TLV to specify the egress cloud GW to be used to reach the destination CPE.

[0085] Control plane implementation in SD-WAN Control Plane for CPE: Embodiments of control plane implementation in SD-WAN are disclosed herein. The control plane enables SD-WAN edges to discover their attributes and additional routes. A local CPE and its virtual CPE (vCPE) or virtual appliance within a cloud DC can be controlled by one internal BGP (iBGP) instance. An IETF document titled “BGP UPDATE for SD-WAN Edge Discovery” by Linda Dunbar et al. published in October 2023 describes a mechanism for SD-WAN edges to discover each other’s attributes. In one embodiment, IPsec key exchange between a local CPE and a vCPE is conducted via iBGP update by a RR.

[0086] Control Plane between CPE and Cloud GW: In a BGP-enabled SD-WAN, an external BGP (eBGP) session is typically established between an enterprise CPE and a cloud GW. An enterprise-owned vCPE can establish an eBGP session with a cloud VPN GW for accessing workloads hosted in a cloud DC. If an IPsec tunnel is required between the cloud GW and the vCPE, then IPsec internet key exchange version 2 (IKEv2) protocol must be exchanged between the vCPE and the cloud GW.

[0087] In some alternative embodiments, when implementing end-to-end IPsec tunnel, the packet header can include a payload and an outer IP header. The payload can include a source: C-PE3 and a destination: C-PE1, a protocol number 6 corresponding to a transmission control protocol (TCP), and a protocol number 17 corresponding to a UDP. The outer IP header can include a source: C-PE3 and a destination: C-PE1, a protocol number 50 corresponding to ESP, and a protocol number 51 corresponding to an authentication header (AH). In one embodiment, SR policy is used to ensure that the packet from C-PE3 is directed through the transit node C-PE2. In one embodiment, since the packet is going through public internet, a digital signature (or HMAC) can be used to verify that the packet received by the transit node is not tampered. In another alternative embodiment, when all IPsec tunnels terminate at the transit node, the transit node decrypts the received payload and encrypts the payload into a new tunnel. The payload can include a source: C-PE3 and a destination: C-PE1, a protocol number 6 corresponding to a TCP, and a protocol number 17 corresponding to a UDP. The outer IP header can include a source: C-PE3 and a destination: C-PE2, a protocol number 50 corresponding to ESP, and a protocol number 51 corresponding to AH. The payload can be encapsulated by GENEVE, which includes a next tunnel identifier.

[0088] Use Cases Enterprises connected to cloud DCs can achieve significant benefits when utilizing cloud backbones to transport traffic between CPEs. These benefits include: (1) leveraging the robust and high-performance infrastructure provided by cloud service providers, utilizing diverse paths, and leveraging the scalability and global coverage of cloud backbones to reduce the risk of downtime or disruption, (2) being able to efficiently handle growth in data traffic due to the scalability of cloud backbones, (3) simplifying network management through the centralized management and orchestration capabilities of cloud backbones, enabling organizations to streamline operations and effectively respond to changing business demands; (4) providing more reliable connections for network paths from CPEs to cloud GWs, and continuous monitoring through sophisticated network functions, compared to the limited bandwidth, unpredictable connections, or susceptibility to cyber attacks that can exist on public internet between branches; (5) facilitating the use of cloud-based security functions, such as firewalls, Distributed Denial of Service (DDoS), etc., to enforce consistent policies for workloads / services within the cloud and between branches; (6) facilitating the use of cloud-based tools and Software as a Service (SaaS) to collect and analyze traffic threats.

[0089] Figure 7Ais a flowchart of a method 700A for optimizing stitching of multiple SD-WAN segments through a transit node across cloud DCs provided by embodiments of the present disclosure. The method 700 can be implemented by a first cloud gateway (gateway, GW) (e.g., cloud gateway 118) in an SD-WAN network (e.g., network 100A, 100B).

[0090] In block 702, the first cloud gateway receives a packet including an outer Internet Protocol (IP) header and a generic network virtualization encapsulation (GENEVE) header on an SD-WAN path, where the GENEVE header includes one or more sub-type length values (TLVs). In one embodiment, the one or more sub-TLVs include an SD-WAN endpoint sub-TLV, where the SD-WAN endpoint sub-TLV includes a destination address of a second CPE.

[0091] In block 704, the first cloud gateway extracts the destination address from the one or more sub-TLVs within the GENEVE header.

[0092] In block 706, the first cloud gateway updates a destination IP address in the outer IP header to the extracted destination address.

[0093] In block 708, the first cloud gateway forwards the packet to the second CPE according to the updated destination IP address. The method 700 can further include: when determining to forward the packet to a second cloud GW, determining whether the one or more sub-TLVs include an egress GW sub-TLV; based on determining that the one or more sub-TLVs include the egress GW sub-TLV, extracting a second destination address of the second cloud GW from the egress GW sub-TLV; updating a source IP address in the outer IP header to an address of the first cloud GW; and forwarding the packet to the second cloud GW according to the updated source IP address and the second destination address.

[0094] Figure 7B is a flowchart of a method 700B provided by embodiments of the present disclosure. The method 700B can be implemented by a first customer premises edge (CPE) (e.g., CPE 102) in an SD-WAN network (e.g., network 100A, 100B).

[0095] In block 712, the first CPE receives a packet. In one embodiment, the packet is an Internet Protocol Security (IPsec) encrypted packet.

[0096] In block 714, the first CPE encapsulates the data packet using a generic network virtualization encapsulation (GENEVE) encapsulation to generate an encapsulated data packet, wherein the encapsulated data packet includes a GENEVE header including one or more sub-type length values (TLVs); In block 716, the first CPE forwards the encapsulated data packet to the second CPE through a cloud gateway (GW) over a Software-Defined Wide Area Network (SD-WAN) path. In one embodiment, the one or more sub-TLVs include an SD-WAN endpoint sub-TLV, wherein the SD-WAN endpoint sub-TLV includes a destination address of the second CPE.

[0097] Figure 8 A schematic diagram of a network element 800 is shown, which is provided by embodiments of the present application. The network element 800 is suitable for implementing the disclosed embodiments as described herein. The network element 800 includes an ingress port 810 and a receive unit (Rx) 820 or receive means for receiving data, a processor, logic unit, central processing unit (CPU) 830 or processing means for processing data, a transmit unit (Tx) 840 or transmit means and an egress port 850 for transmitting data, and a memory 860 or data storage means for storing data. The routing device 800 can further include optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the ingress port 810, receive unit 820, transmit unit 840 and egress port 850 for the ingress and egress of optical or electrical signals.

[0098] The processor 830 is implemented by hardware and software. The processor 830 can be implemented as one or more CPU chips, one or more cores (e.g., implemented as a multi-core processor), one or more field-programmable gate arrays (FPGAs), one or more application specific integrated circuits (ASICs), and one or more digital signal processors (DSPs). The processor 830 is in communication with the ingress port 810, the receive unit 820, the transmit unit 840, the egress port 850, and the memory 860. The processor 830 includes an SD-WAN module 870. The network element 800 is capable of implementing one or more of the above-described embodiments or actions. For example, the SD-WAN module 870 implements, processes, prepares, or provides various functions disclosed herein. Thus, the inclusion of the SD-WAN 870 results in a substantial improvement in the functioning of the network element 800 and effects a transformation of the network element 800 to a different state. Alternatively, the network element 800 is implemented as instructions stored in the memory 860 and executed by the processor 830.

[0099] The network element 800 can also include input and / or output (I / O) devices 880 for communicating data to and from the user and for receiving input from and providing output to a network administrator. The I / O devices 880 can include output devices such as a display for displaying video data, speakers for outputting audio data, etc. The I / O devices 880 can also include input devices such as a keyboard, mouse, trackball, etc., and / or corresponding interfaces for interacting with these output devices.

[0100] The memory 860 includes one or more disks, one or more tape machines, and one or more solid-state drives, and can serve as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data read from the memory 860 when such data are loaded for execution. The memory 860 can be volatile and / or non-volatile, and can be read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and / or static random-access memory (SRAM).

[0101] While several embodiments have been provided in the present disclosure, it is understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to limit the disclosure to the details given, since the present disclosure can be implemented in other specific forms without departing from the spirit or essential character thereof. For instance, various elements or components can be combined or integrated within another system, or certain features can be omitted or not implemented. One of ordinary skill in the art having the benefit of details from this disclosure would understand other implementations.

[0102] Additionally, the various embodiments described and illustrated herein can be implemented in any of numerous ways, as the disclosed examples are not limited to any particular manner of implementation. Examples of specific implementations and applications are provided for illustrative purposes only. The disclosed systems and methods can be implemented in hardware, software, or a combination thereof. For example, various features can be implemented in hardware, and other similar features can be implemented in software. Further, the disclosure can be implemented by localized as well as distributed systems, components and / or circuits. In one embodiment, the systems and methods disclosed herein can be implemented in conjunction with a general purpose computer, a special purpose computer, or any other programmable data processing system. In another embodiment, the systems and methods disclosed herein can be implemented in a mobile device, a mobile phone, a smart phone, a personal digital assistant, a personal computer, a laptop computer, a tablet computer, a server, a server farm, a distributed system, or any other programmable data processing system. In another embodiment, the systems and methods disclosed herein can be implemented in a mobile device, a mobile phone, a smart phone, a personal digital assistant, a personal computer, a laptop computer, a tablet computer, a server, a server farm, a distributed system, or any other programmable data processing system.

Claims

1. A method implemented by a first cloud gateway (GW), characterized in that, The method includes: On a Software-Defined Wide Area Network (SD-WAN) path, a data packet is received from a first Customer Premises Edge (CPE) device, comprising an outer Internet Protocol (IP) header and a Geneve General Network Virtualization Encapsulation (GENEVE) header, wherein the GENEVE header includes one or more Subtype Length Values ​​(TLVs). Extract the destination address from the one or more sub-TLVs within the GENEVE header; Update the destination IP address in the outer IP header to the extracted destination address; and The data packet is forwarded to the second CPE based on the updated destination IP address.

2. The method according to claim 1, characterized in that, The one or more sub-TLVs include an SD-WAN endpoint sub-TLV, wherein the SD-WAN endpoint sub-TLV includes the destination address of the second CPE.

3. The method according to claim 1 or 2, characterized in that, Also includes: Update the source IP address in the outer IP header to the address of the first cloud GW; as well as The data packet is forwarded to the second CPE based on the updated source IP address and the updated destination IP address.

4. The method according to any one of claims 1 to 3, characterized in that, Before forwarding the data packet to the second CPE, the method further includes: determining, according to the cloud operator's policy, to forward the data packet to the second cloud GW.

5. The method according to any one of claims 1 to 4, characterized in that, Also includes: Determine whether the one or more sub-TLVs include an export GW sub-TLV; Based on the determination that the one or more sub-TLVs include the egress GW sub-TLV, the second destination address of the second cloud GW is extracted from the egress GW sub-TLV; Update the source IP address in the outer IP header to the address of the first cloud GW; and The data packet is forwarded to the second cloud GW based on the updated source IP address and the second destination address.

6. The method according to any one of claims 1 to 5, characterized in that, The data packet is an Internet Protocol Security (IPsec) encrypted data packet.

7. The method according to any one of claims 1 to 6, characterized in that, The GENEVE header is encapsulated in the User Datagram Protocol (UDP) header.

8. The method according to any one of claims 1 to 7, characterized in that, The GENEVE header also includes a variable-length option field, which includes an option class field, a type field, and a variable option data field.

9. The method according to any one of claims 1 to 8, characterized in that, The option class field includes a multi-segment SD-WAN option class, wherein the type field indicates the type of multi-segment SD-WAN.

10. The method according to any one of claims 1 to 9, characterized in that, The variable length option field includes the one or more sub-TLVs, wherein the one or more sub-TLVs include an SD-WAN endpoint sub-TLV and an optional sub-TLV, and wherein the optional sub-TLV includes an SD-WAN tunnel initiator sub-TLV and / or an egress GW sub-TLV.

11. The method according to any one of claims 1 to 10, characterized in that, The SD-WAN endpoint sub-TLV includes a length field and a time-to-live (TTL) field, the TTL field indicating the number of cloud gateways the packet traverses.

12. The method according to any one of claims 1 to 11, characterized in that, The SD-WAN tunnel initiator TLV indicates the IP address of the first CPE.

13. The method according to any one of claims 1 to 12, characterized in that, The exit GW sub-TLV indicates the address used to reach the second cloud GW of the second CPE.

14. The method according to any one of claims 1 to 13, characterized in that, Also includes: The data packet is authenticated using a pre-configured authentication method.

15. The method according to any one of claims 1 to 14, characterized in that, The first cloud GW is located in the first cloud data center, and the second cloud GW is located in the second cloud data center.

16. A method implemented by a first customer premises edge device (CPE), characterized in that, The method includes: Receive data packets, wherein the data packets are Internet Protocol Security (IPsec) encrypted data packets; The data packet is encapsulated using Geneve Network Virtualization Encapsulation (GENEVE) to generate an encapsulated data packet, wherein the encapsulated data packet includes a GENEVE header, the GENEVE header including one or more Subtype Length Values ​​(TLVs); and The encapsulated data packets are forwarded to the second CPE via a cloud gateway (GW) on the software-defined wide area network (SD-WAN) path.

17. The method according to claim 16, characterized in that, The one or more sub-TLVs include an SD-WAN endpoint sub-TLV, and wherein the SD-WAN endpoint sub-TLV includes the destination address of the second CPE.

18. The method according to claim 16 or 17, characterized in that, Also includes: This enables the cloud GW to extract the destination address of the second CPE from one or more sub-TLVs within the GENEVE header.

19. The method according to any one of claims 16 to 18, characterized in that, The one or more sub-TLVs include an SD-WAN tunnel initiator sub-TLV or an egress GW sub-TLV, wherein the SD-WAN tunnel initiator TLV indicates the address of the first CPE.

20. The method according to any one of claims 16 to 19, characterized in that, The encapsulated data packet also includes an outer IP header, wherein the outer IP header includes a destination address indicating the address of the first cloud.

21. The method according to any one of claims 16 to 20, characterized in that, Also includes: An Internet Protocol Security (IPsec) tunnel is established between the first CPE and the second CPE to forward the data packets to the second CPE.

22. A cloud gateway (GW), characterized in that, include: Memory, used to store instructions; as well as One or more processors are coupled to the memory and used to execute the instructions to cause the cloud GW to perform the method according to any one of claims 1 to 15.

23. A non-transitory computer-readable medium, characterized in that, The non-transitory computer-readable medium includes a computer program product for use by a cloud gateway (GW), the computer program product including computer-executable instructions stored in the non-transitory computer-readable medium, which, when executed by one or more processors, cause the cloud GW to perform the method of any one of claims 1 to 15.

24. A cloud gateway (GW), characterized in that, It includes one or more means for performing the method according to any one of claims 1 to 15.

25. A first customer premises edge device (CPE), characterized in that, include: Memory, used to store instructions; as well as One or more processors are coupled to the memory and used to execute the instructions to cause the first CPE to perform the method according to any one of claims 16 to 21.

26. A non-transitory computer-readable medium, characterized in that, The non-transitory computer-readable medium includes a computer program product for use by a first customer premises edge device (CPE), the computer program product including computer-executable instructions stored in the non-transitory computer-readable medium, which, when executed by one or more processors, cause the first CPE to perform the method of any one of claims 16 to 21.

27. A first customer premises edge device (CPE), characterized in that, Includes one or more means for performing the method according to any one of claims 16 to 21.

Images