CN117652133A

CN117652133A - Ingress gateway with data flow classification functionality

Info

Publication number: CN117652133A
Application number: CN202280046991.XA
Authority: CN
Inventors: R·朗格莱
Original assignee: Avidros Systems
Current assignee: Avidros Systems
Priority date: 2021-04-30
Filing date: 2022-04-28
Publication date: 2024-03-05

Abstract

A computerized method for providing network policy based routing of data flows is described. After obtaining the attributes associated with the incoming data stream, the first gateway is configured to determine one or more network policies based on the attributes associated with the incoming data stream and assign a classification identifier based on the one or more network policies. The classification identifier is configured to affect a routing path through the at least one cloud network, wherein the classification identifier is encapsulated into content of the incoming data stream to generate a classified data stream for routing from the source to the destination through the at least one cloud network.

Description

Ingress gateway with data flow classification functionality

Cross Reference to Related Applications

The present application claims priority from U.S. application Ser. No.17/727,884, to U.S. provisional patent application Ser. No.63/182,686, filed on 4/30 of 2021, the entire contents of both of which are incorporated herein by reference.

Technical Field

Embodiments of the present disclosure relate to the field of networking. More particularly, one embodiment of the present disclosure relates to a cloud network infrastructure that reliably associates applications belonging to cloud instances to data streams that propagate over a cloud network.

Background

In the past few years, cloud computing provided infrastructure as a service (IaaS), where resources were provided as part of a public cloud network and made accessible to tenants as a service. One of these services allows a tenant to run software components (e.g., virtual machine instances such as virtual servers) residing within a public cloud network. Thus, migration of this software functionality results in increased use of virtual private cloud networks (VPCs), i.e., on-demand configurable pools of shared resources, that are allocated within the public cloud network and provide a degree of isolation between different organizations or other entities (hereinafter "users") that use the resources. However, increased usage of public cloud network resources results in greater data traffic and adds complexity to cloud network management.

Recently, some software platforms have been developed and deployed with the ability to monitor and manage cloud networking independent of the selected one or more public cloud providers. For example, one software platform features a controller and a set of gateways deployed as software components of a VPC and communicatively coupled to each other. For the software platform, the controller and gateway may be configured to support data streaming (e.g., routing of data packets) over the cloud network, wherein packets associated with the data stream are routed from a source (e.g., a first application) to a destination (e.g., a second application).

With this conventional network architecture, due to the increased cloud complexity, it becomes very difficult to determine which applications are related to the data streams that are propagated over the network in order to determine how to process the data streams to meet the different requirements of the applications. Conventionally, each application is assigned an Internet Protocol (IP) address included in each packet of the data stream. However, as IP addresses become more and more transient, their use in identifying applications that are sources of data streams becomes more and more unreliable. In other words, as the resources within the cloud network identified by IP addresses grow exponentially, these IP addresses will need to become more transient, and thus relying on IP addresses for source identification will become less reliable over time.

Furthermore, as the magnitude of data traffic grows, as more and more enterprises migrate software components into the cloud network, the operational complexity required by each gateway to monitor and manage the routing of data traffic increases accordingly. This operational complexity may result from the need to update changes to the routing configuration more frequently, which is time consuming and disrupts ongoing communications. As more companies migrate their networking operations to public cloud networks, convergence (stabilization) of the networks and avoidance of data traffic disruption within VPCs deployed as part of the public cloud networks are necessary. A technique for implementing network convergence through policy-based routing and more accurate data flow is described and desired below.

Drawings

Embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements and in which:

FIG. 1 is an exemplary embodiment of a cloud network infrastructure performing policy-based data flow classification;

fig. 2A is a more detailed representation of the cloud network infrastructure of fig. 1.

Fig. 2B is a logical representation of the operation of the cloud network infrastructure of fig. 1 to generate class IDs (classids).

FIG. 2C is an exemplary decision tree structure illustrating the determination of one or more network policies associated with an analyzed data flow.

Fig. 3A is a first exemplary embodiment of a logical architecture of the ingress gateway of fig. 2A.

Fig. 3B is a second exemplary embodiment of the logical architecture of the ingress gateway of fig. 2A.

Fig. 4 is an exemplary embodiment illustrating the general logical operation of the ingress gateway of fig. 2A-2B.

Fig. 5 is a flow chart of an exemplary embodiment of the operability of the cloud network infrastructure throughout fig. 1 in classifying data flows transmitted between applications that are part of cloud instances deployed in different virtual private cloud networks (VPCs).

Detailed Description

Embodiments of systems and methods for an improved cloud network infrastructure based on policy-based data traffic management schemes are described. The cloud network infrastructure supports policy-based routing of data flows (e.g., messages or a series of messages) between network devices. Herein, a first network device, referred to as a gateway, is configured to operate with a controller to assign a classification identifier to each data stream traveling over a cloud network infrastructure. The class identifier (hereinafter "class ID") identifies the type of data flow, wherein such identification is based on which user-defined network policy (or which group of two or more network policies) comprises requirements regarding forwarding of the data flow, which requirements are met by certain attributes associated with the source and/or destination of the data flow, as well as the attributes of the flow itself. In this context, class IDs may correspond to a determined network policy (e.g., a one-to-one mapping between each class ID and the corresponding network policy), or class IDs may correspond to some group (combination) of network policies. The use of class IDs will provide a more reliable association between applications and the data streams they propagate over the cloud network as well as the context of the data streams themselves.

One embodiment of a cloud network infrastructure may include a collection of software components maintained within a public cloud network, where the software components operate as (i) a virtual private cloud network at the edge of the cloud network (hereinafter "edge VPC") and (ii) a virtual private cloud network that supports the propagation of data traffic from one VPC to another (hereinafter "transit VPC"). Herein, according to this embodiment, the first edge VPC may include at least one gateway (hereinafter "ingress gateway") communicatively coupled to one or more cloud instances. Each cloud instance may support one or more cloud-based applications. The second edge VPC may include at least one gateway (hereinafter "egress gateway") communicatively coupled to one or more different cloud instances. The ingress gateway and egress gateway may be communicatively coupled to a set of (e.g., two or more) gateways (hereinafter "transit gateways") deployed within the transit VPC via one or more peer-to-peer communication links that operate in accordance with a secure network protocol, such as, for example, an internet protocol security (IPSec) tunnel. Each of these gateways may be accessed according to a unique classless inter-domain routing (CIDR) routing address to propagate messages through the network.

As described below, each ingress gateway is configured to assign a class ID to an incoming data stream based on attributes associated with the data stream that conforms to and thereby meets certain requirements of one or more network policies defined for the cloud network infrastructure by an administrator of a particular user (e.g., company, federation, etc.). In this context, a network policy generally specifies a desired state, which may be represented by a set of requirements governing data flow (message) forwarding between network devices. These network devices may be physical network devices or virtual network devices (e.g., software constructs that operate as specific network devices).

In this context, a class ID may be represented as a 24-bit or 32-bit value, which may be assigned a "local" granularity (e.g., the class ID relates only to segments of data flows between neighboring network devices of the communication session), or may be assigned a "global" granularity (e.g., the class ID is unique and relates to a particular data flow for any communication throughout the private cloud network), in accordance with one embodiment of the present disclosure. The "global" class ID reduces the complexity of the flow analysis (e.g., sampling the propagation of specific messages) and improves overall network efficiency because the rate of change of class IDs is reduced, thereby reducing the frequency of gateway configuration changes by the controller to account for class ID changes, and as will be discussed below.

According to this embodiment of the present disclosure, the attributes associated with the data stream may be based at least in part on static and dynamic attributes. Assuming that the ingress gateway is co-located with the application of the cloud instance that is the source of the data stream, the static attributes associated with the data stream may be clarified from the information associated with the ingress gateway. Examples of static attributes may include, but are not limited or restricted to, location-based attributes (e.g., same cloud region, same cloud zone, same geographic location, such as country, state, city, community or other geographic region, same cloud provider, etc.). Instead, dynamic properties may be obtained from the contents of the data stream, such as by using the source address of the data stream as an index into an address-to-property mapping data store, as described below.

As another example, class IDs may be determined by a decision tree structure that may assign a resulting class ID based on which network policy or combination of network policies is most closely related to certain attributes associated with the data flow. Alternatively, the class ID may be at the controller level, where the data flow associated with each application is classified, and the controller provides a mapping table of IP addresses to class IDs to each ingress gateway. Independent of the type of class ID determination process, the number of class IDs may correspond to the number of network policies such that the class IDs change only when the requirements associated with a particular network policy change.

Additional details logically associated with one embodiment of a fully meshed network system architecture for load balancing are described below:

example net: the edge VPC may support multiple real world wide networks such that the cloud real world wide from a particular real world wide networkThe data stream of the instance is forwarded to the selected ingress gateway.

Yun Shili: a set of software components configured to receive an incoming data stream (one or more messages) and/or transmit an outgoing data stream within a cloud network. As an illustrative example, a cloud instance may be comprised of a virtual web server, a plurality of applications handled by the virtual web server, and a database maintained by the virtual web server. For this and other configurations, cloud instances may generate (and transmit) different types of data streams that are classified differently depending on their attributes. For example, a data stream initiated by a backup agent that is a first of the applications operating on the web server will be classified differently than a browser application that is one of the plurality of applications associated with the same cloud instance.

Gateway (GW): multiple gateways may be deployed in one or more VPCs to control the routing of data flows from cloud instances (including source applications) to cloud instances (including destination applications). With a similar logical architecture, gateways may be identified differently based on their location/operability within a cloud network. The "ingress" gateway is configured to interact with cloud instances including applications, while the "transit" gateway is configured to further facilitate propagation of data streams (e.g., one or more messages) directed to the ingress gateway within another edge VPC.

IPSec tunnel: a secure peer-to-peer communication link is established between gateways, which may be located within the same VPC or within different neighboring VPCs. The peer-to-peer communication link is protected by a secure network protocol suite known as "internet protocol security" (IPSec). Regarding one embodiment of a full mesh network deployment, as an illustrative example, where an edge VPC may include "M" gateways (e.g., M.gtoreq.1) and a neighboring (transit) VPC has N gateways (N.gtoreq.1), M N IPSec tunnels may be created between the edge VPC and the transit VPC. These IPSec tunnels are represented in the gateway by Virtual Tunnel Interfaces (VTIs), and tunnel states are represented by VTI states.

Gateway routing: in the gateway routing table of the gateway device,the routing path between the gateway and the tunnel-terminated IP-addressable destination (e.g., another gateway, an on-pre computing device, etc.) is identified, for example, by the VTI, and may be governed, at least in part, by a class ID generated at the ingress gateway. The routing path may be further managed based at least in part on analysis of certain information associated with the data traffic (e.g., 5-tuple-source IP address, destination IP address, source port, destination port, selected transport protocol). If any IPSec tunnel state is changed or disabled (or re-activated), the corresponding VTI may be removed (or added) from consideration regarding the termination point of the selected routing path.

I. Terminology

In the following description, certain terminology is used to describe features of the invention. In some cases, each of the terms "logic," "component," and "device" represents hardware, software, or a combination thereof that is configured to perform one or more functions. As hardware, logic (or components/devices) may constitute control logic, which may include circuitry with data processing or storage functionality. Examples of such control circuitry may include, but are not limited to, a processor (e.g., a microprocessor, one or more processor cores, a microcontroller, a controller, a programmable gate array, an application specific integrated circuit, etc.), a wireless receiver, a transmitter and/or transceiver, a semiconductor memory, or combinational logic.

Alternatively or in combination with the hardware circuitry described above, the logic (or components/devices) may be software in the form of one or more software modules. The software module(s) may include executable applications, application Programming Interfaces (APIs), subroutines, functions, procedures, applets, servlets, routines, source code, shared/dynamic load libraries, or one or more instructions. The software module(s) may be encoded as a processor, i.e., a virtual processor.

The software module(s) may be stored in any type of suitable non-transitory storage medium or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals). Examples of non-transitory storage media may include, but are not limited to, programmable circuitry; a semiconductor memory; non-persistent memory, such as volatile memory (e.g., any type of random access memory "RAM"); persistent storage such as non-volatile memory (e.g., read-only memory "ROM", power-backed RAM, flash memory, phase-change memory, etc.), solid-state drive, hard drive, optical drive, or portable memory device. As software, the logic may operate as firmware stored in persistent storage.

The term "computerized" generally means that any corresponding operations are performed by hardware in combination with software.

The term "gateway" may be interpreted as a virtual or physical network device. For example, as an illustrative example, a gateway may correspond to a virtual network device in the form of a software component, such as a Virtual Machine (VM) based data routing component, that is assigned a private IP address within a range of IP addresses associated with a VPC that includes the gateway. The gateway allows Cloud Service Providers (CSPs) and enterprises to enable data center and cloud network traffic routing between virtual and physical networks including public networks (e.g., the internet). Alternatively, in some embodiments, the gateway may correspond to a physical network device, such as an electronic device communicatively coupled to a network and assigned a hardware (MAC) address and an IP address.

The term "cloud network infrastructure" generally refers to a combination of software components (e.g., instances) generated based on execution of particular software by hardware associated with a public cloud network. Each software component (or combination of software components) may constitute a virtual network resource associated with a public cloud network, such as a virtual switch, virtual gateway, or the like.

The term "message" generally refers to information having a prescribed format and transmitted according to a suitable delivery protocol. Thus, each message may be in the form of one or more packets, frames, or any other bit sequence having a prescribed format. A "data stream" generally refers to one or more messages transmitted from a source (e.g., a first application instance or other software component) maintained within a cloud network to a destination (e.g., a second application instance or other software component).

The term "communication link" may be construed as a physical or logical communication path between two or more network devices. For example, as a physical communication path, wired and/or wireless interconnects in the form of wires, optical fibers, cables, bus traces, or wireless channels using infrared, radio Frequency (RF) may be used. As a logical communication path, the communication link may be an Application Programming Interface (API) or other software construct that provides for the transfer of information between two software components that make up two network devices in a logical representation.

Finally, the terms "or" and/or "as used herein should be interpreted as inclusive, or meaning any one or any combination. As an example, "A, B or C" or "A, B and/or C" means "any of the following: a, A is as follows; b, a step of preparing a composite material; c, performing operation; a and B; a and C; b and C; A. b and C). An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.

As this invention is susceptible of embodiment in many different forms, this disclosure is to be taken in the purview of illustrating the principles of the invention and not intended to limit the invention to the specific embodiments shown and described.

General system architecture

Referring to fig. 1, an exemplary embodiment of a cloud network infrastructure 110 is deployed within a public cloud network 100 and is accessible to users associated with a particular enterprise. Herein, cloud network infrastructure 110 includes a collection of virtual private cloud networks (VPCs) that support reliable communications between one or more cloud instances residing in different VPCs. The cloud network infrastructure 110 may be configured to operate as a fully meshed network for load balancing, as described in U.S. patent application No.17/079,399 entitled "Active Mesh Network System and Method," filed 10-23 in 2020, the entire contents of which are incorporated herein by reference.

According to this embodiment of the present disclosure, as shown, the cloud network infrastructure 110 may be configured to support communications between a first VPC (hereinafter "first edge VPC") 120 and a second edge VPC130 communicatively coupled together via a third VPC (hereinafter "transit VPC") 140. Although two edge VPCs 120 and 130 are illustrated in fig. 1 for clarity, it is contemplated that the cloud network infrastructure 110 may deploy additional edge VPCs and multiple transit VPCs.

As shown, the first edge VPC 120 is configured with one or more real example networks 150 (hereinafter "subnets"), where each of these real example networks 150 may include one or more cloud instances. As shown, each cloud instance (e.g., yun Shili 155) within instance subnet 150 is configured to exchange data streams with class assignment routing logic 160. Class assignment routing logic 160 may be configured to (i) analyze content (e.g., data, meta information, etc.) of an incoming data stream 165 (e.g., one or more messages) from a cloud instance, (ii) assign a class identifier (class ID) 170 to the data stream 165, and (iii) encapsulate the class ID 170 into a message (or each message) associated with the data stream 165.

Herein, according to one embodiment of the present disclosure, the content of the data stream 165 is analyzed to identify certain attributes 167 associated with the data stream 165. Based on these attributes 167, class assignment routing logic 160 may determine a user-defined network policy 180 for this type of data flow 165. Class ID 170 is based on which network policy 180 (and its requirements) is associated with (and satisfied by) identification attribute 167 of data stream 165. Thereafter, the encapsulation scheme used to encapsulate class ID 170 into message(s) associated with data stream 165 may depend on the transport protocol supported by cloud network infrastructure 110, which results in classified data stream 175. In general, class ID 170 may be encapsulated into the IPSec header of each of the message(s) to form classification data stream 175.

Transit VPC 140 forwards classified data stream 175 through a different gateway, where forwarding may be affected by class ID 170. The rerouting logic 185, which is a component of the second edge VPC130, may be configured to remove the class ID 170 from the classified data stream 175 and direct the content of the originally transmitted data stream 165 to the target destination cloud instance 190, which is part of the instance subnet 195 supported by the second edge VPC 130.

Referring now to fig. 2A, a more detailed representation of an exemplary embodiment of a cloud network infrastructure 110 is shown, the cloud network infrastructure 110 comprising a first edge VPC 120 and a second edge VPC130 communicatively coupled via a transit VPC 140. Herein, the first edge VPC 120 is configured with instance subnet(s) 150, wherein cloud instances 155 within instance subnet 150 are configured to exchange data streams with class assignment routing logic 160, i.e., gateway set 200 (e.g., two or more) maintained in the first edge VPC 120 ₁ -200 _M The gateway in (M.gtoreq.2). In this context, these gateways 200 ₁ -200 _M Referred to as an "ingress gateway" 200 ₁ -200 _M 。

More specifically, the controller 115 for the cloud network infrastructure 110 is configured to manage the instance subnet(s) 150 and ingress gateway set 200 by using the VPC routing table 210 ₁ -200 _M Communication between, the VPC routing table 210 is initially configured to identify which ingress gateway 200 ₁ .. or 200 _M Is responsible for interacting with which instance network 150 or cloud instance. According to one embodiment of the present disclosure, each cloud instance may include a plurality of software components that operate together as virtual resources. For example, as described above, cloud instance 155 may correspond to a virtual web server configured to execute a plurality of applications 205, where the applications 205 may generate and output different types of data streams 165.

Still referring to fig. 2A, according to one embodiment of the present disclosure, the cloud network infrastructure 110 may pass through a set of ingress gateways 200 that will be deployed within the first edge VPC 120 ₁ -200 _M To wait until it may be referred to as a "transit gateway" 220 ₁ -220 _N Is deployed within transit VPC 140 ₁ -220 _N (N is more than or equal to 2). For ease of illustration, ingress gateway set 2001-200M is shown as first ingress gateway 200 ₁ And a second ingress gateway 200 ₂ Although it is possible to locate at the edge VPC1Three or more ingress gateways are deployed within 20. Similarly, transit gateway set 220 ₁ -220 _N Is routed through the first transit gateway 220 ₁ And a second transit gateway 220 ₂ It is shown that three or more transit gateways may be deployed within transit VPC 140.

As shown, ingress gateway 2001 is configured for communication with transit gateway 220 via peer-to-peer communication link 230 ₁ -220 ₂ And (5) communication. In particular, according to one embodiment of the present disclosure, an ingress gateway (e.g., ingress gateway 200 ₁ ) May be communicatively coupled to each transit gateway 220 via a plurality of active peer-to-peer communication links ₁ -220 ₂ . Similarly, transit gateway 220, as shown for illustrative purposes ₁ -220 ₂ Gateway set 240, which may be maintained in second edge VPC130 via peer-to-peer communication link 232 and/or via peer-to-peer communication link 234 ₁ -240 _P (P.gtoreq.2) communicatively coupled to other transit gateways (e.g., transit gateway 220 ₃ -220 ₄ ). In this context, these gateways 240 ₁ -240 _P Referred to as an "egress gateway" 240 ₁ -240 ₂ . Further, peer-to-peer communication links 230, 232, and/or 234 may constitute a cryptographically secure tunnel, such as an IPSec tunnel. Management of IPSec tunnels 230, 232, and 234 may be performed by respective gateways 200 ₁ -200 ₂ 、220 ₁ -220 ₄ And 240 (V) ₁ -240 ₂ Is implemented by a gateway routing table (not shown) maintained by each of the servers.

In terms of operation, the first edge VPC 120 is configured with one or more real example networks 150 that include a plurality of cloud instances including cloud instance 155. Yun Shili 155 are configured to direct to ingress gateway 200 ₁ A data stream 165 is provided. Ingress gateway 200 ₁ Is configured to analyze the content of the data stream 165 and assign it a class ID 170. Class ID 170 is based on which network policy from the set of network policies 250 includes a requirement that it has a high correlation with the properties of incoming data stream 165. For example, according to one embodiment of the present disclosure, class ID 170 may be based at least in part on which network policy 180 from the set of user-defined network policies 250 is by the genus with data flow 165The requirements of the correlation are composed.

More specifically, as shown in both fig. 2A-2B, after network policy 250 is formulated and incoming data stream 165 is received, ingress gateway 200 ₁ Is configured to analyze the content of the data stream 165 by determining the attributes 167 of the data stream 165. These attributes 167 may include static attributes 260 and dynamic attributes 265.

According to one embodiment of the present disclosure, ingress gateway 200 is based on ₁ And cloud instance 155, static properties 260 may be determined from the relationship with ingress gateway 200 ₁ The associated attributes are available. Examples of static properties 260 may include information associated with a location of cloud instance 155, cloud instance 155 including a source application of data stream 165, which location of cloud instance 155 is to be with ingress gateway 200 ₁ The same location (e.g., cloud provider, cloud area, cloud zone, geographic location, such as country, state, city, community, or other sub-area). Dynamic attribute 265 may be available to ingress gateway 200 through IP address to attribute mapping 270 provided by controller 115 ₁ . Map 270 identifies attributes that may be suitable for the source application. These attributes may include, but are not limited or restricted to, the following attributes set forth in table a:

table A

Thereafter, class ID 170 may be determined based at least in part on the values of some or all of these attributes 260 and 265.

According to other embodiments of the present disclosure, class ID 170 may be determined, at least in part, by a decision tree analysis that associates values of particular attributes with decisions that will represent correlations with network policy requirements. As an illustrative example, a decision tree structure 280 for use in determining one or more network policies associated with the data flow 165 is shown in fig. 2C. In this context, the decision tree structure 280 may be characterized by a decision 285 based on the presence (or absence) of particular attributes and/or the values of those attributes. For the purpose ofAs an illustrative example, the result of first decision 290 may identify that data flow 165 is associated with first network policy 291 or is subject to second decision 292. Similarly, based on the second decision 292, a result is generated that identifies that the data stream 165 is associated with the second network policy 293 or is subject to the third decision 294. Upon identifying the network policy associated with the data flow 165, the ingress gateway 200 ₁ A class ID may be assigned that corresponds to a network policy or group of network policies to which the attributes of the data stream 165 are highly correlated.

As described above, the manner in which class IDs 170 are encapsulated into data stream 165 to produce categorized data stream 175 may depend on the transport protocols supported by cloud network infrastructure 110. For example, where the data stream 165 constitutes one or more UDP-based IP packets, the class ID 170 may be implemented with an encapsulated portion of the message (e.g., a message body with an encapsulated security protocol "ESP" header, a message body with a Wireguard header, etc.) that classifies the data stream 175.

Referring back to fig. 2A, transit VPC 140 passes through a different transit gateway 220 ₁ -220 ₄ Forwarding classified data stream 175, where forwarding may be affected by class ID 170. For example, class ID 170 may be used to determine that a classified data stream is being routed to egress gateway 240 ₁ Which communication link 232 is used. Additionally, transit gateway 220 ₁ -220 ₄ May be configured to perform a filtering operation based at least in part on class ID 170 in lieu of conventional firewall techniques that rely on the source or destination IP address. As an example, a transit gateway (e.g., transit gateway 220 ₁ ) Traffic limiting operations may be performed by eliminating data streams exceeding a certain size (in bytes), exceeding a certain burst size or burst length, exceeding a bandwidth threshold, constituting certain types of data streams that are completely prohibited from transmission (either to a certain application or to a certain edge VPC), etc.

The egress gateway 240 as a component of the second edge VPC130 ₁ Is responsible for removing class IDs 170 from the classified data stream 165 and directing the content of the data stream 165 to the target destination cloud instance 190 as part of the subnet 195 supported by the second edge VPC 130.

General gateway architecture

Referring now to FIG. 3A, an ingress gateway 200 is shown ₁ Is described herein, is a first exemplary embodiment of a logic architecture of (1). Herein, ingress gateway 200 ₁ Including interface 300, control logic 310, queues 320, and non-transitory storage media (e.g., data storage) 330. Data store 330 has queue monitoring and selection logic 340, class ID analysis logic 350, message reconfiguration logic 360, and network policy 250. Ingress gateway 200 ₁ Is configured to receive the data stream 165 (e.g., one or more messages) via the interface 300 and generate a class ID 170 associated with the data stream 165 for transmission from the interface 300 as part of the data stream 165.

As shown, queue 320 may be an incoming queue 322 and/or an outgoing queue 324. For example, after receipt via interface 300, content associated with data stream 165 may be temporarily maintained within incoming queue 322 prior to analysis by class ID analysis logic 350. Outgoing queue 324 may also serve as a temporary storage for classified data stream 175 awaiting transmission from ingress gateway 2001. The outgoing queue 324 may be structured according to a classification priority, wherein transmissions of the classified data stream 175 may be prioritized based on the assigned class ID. In general, the queuing policy may be based at least in part on the class ID assigned to the data stream 165.

More specifically, queue monitoring and selection logic 340 (e.g., one or more processors) executed by control logic 310 may detect storage of content associated with data stream 165 within incoming queue 322 and signal class ID analysis logic 350 accordingly. Class ID analysis logic 350 is configured to (i) determine which network policy 250 applies to data stream 165, and (ii) assign class ID 170 according to the determined network policy. Class ID 170 may be selected, for example, by determining which requirements of network policy 250 are associated with attributes 167 of data stream 165 based on those attributes 167. Class ID 170 may correspond to a network policy or group of network policies that have requirements that best correlate with the attributes of data stream 165.

Additionally, the message reconfiguration logic 360 is adapted to appropriately package the class ID 170 into the data stream 165 to generate classification dataStream 175 is used to direct the transmission to the target cloud instance. Additionally, message reconfiguration logic 360 may include route prediction logic to select a particular transit gateway and communication link to receive the classified data stream. Such selection may be based at least in part on class IDs 170 encapsulated into the categorized data stream 175. For example, classified data stream 175 may be routed to a particular transit gateway 220 ₂ The particular transit gateway 220 ₂ Is configured with the particular security policies required for a particular data stream (e.g., transit gateway 220 in the case where classified data stream 175 is credit card information ₂ Support the payment card industry data security standard "PCI DSS").

Simultaneously with (e.g., at least partially overlapping in time) or subsequent to the above-described operation of message reconfiguration logic 360, queue monitoring and selection logic 340, which is executed by control logic 310, may select one outgoing queue 324 based on class ID 170 associated with data stream 165. The outgoing queue 324 may be assigned a priority such that the classified data stream 175 associated with a particular class ID may be transmitted before the classified data stream 175 associated with another class ID.

Referring to FIG. 3B, an ingress gateway 200 is shown ₁ Is described in the second exemplary embodiment of the logic architecture of (a). Herein, ingress gateway 200 ₁ Including interface 300, control logic 310, queues 320, and non-transitory storage media (e.g., data storage) 330, as illustrated in fig. 3A. However, instead of class ID analysis logic 350, data store 330 includes class ID assignment logic 380 that operates in combination with attribute-to-network policy data store 385, gateway characteristic data store (for static attributes) 390, and network policy-to-class ID data store 395. Herein, class ID assignment logic 380 is configured to determine network policies 180 applicable to data stream 165 from network policies 250 by accessing at least static attributes from gateway characteristics data store 390 and dynamic attributes from the content of data stream 165. In general, certain attributes (e.g., static, dynamic, or a combination of static and dynamic attributes) may be used to determine which network policies 250 apply to the data flow 165. Thereafter, class ID assignment logic 380 accesses the network policy to class ID data store 395 to determine and derive fromClass ID 170 associated with data stream 165 of cloud instance 155. Of course, as an alternative embodiment (not shown), class ID assignment logic 380 may simply access a specified table based on the relationship of attributes to class IDs.

Referring now to fig. 4, an exemplary embodiment of the general logical operation of ingress gateway 2001 of fig. 2A is shown. In this context, ingress gateway 2001 includes class ID determination logic 400 (e.g., class ID analysis logic 350 or class ID assignment logic 380 and the required resources); route prediction logic 420; flow restrictor logic 440; and queue selection logic 460. Herein, the incoming data stream 165 is received by the class ID determination logic 400, which class ID determination logic 400 assigns a class ID to the data stream 165 based on which network policy(s) are applicable to the data stream 165. Class IDs are encapsulated within the data stream 165 to generate a categorized data stream 175. Classified data stream 175 is provided to route prediction logic 420.

Route prediction logic 420 is configured to determine a particular transit gateway and corresponding communication link to receive classified data stream 175 for routing to a target application. The determination may be based at least in part on the selected class ID 170 included as part of the classification data stream 175. Traffic limiter logic 440 is configured to receive classified data stream 175 and "shape" the traffic by filtering the propagation of the control classified data stream. Queue selection logic 460 determines which outgoing queues 324 receive classified data streams 175, particularly when different outgoing queues 324 are assigned different priorities.

Operational flow

Referring now to fig. 5, fig. 5 is a flow chart of an exemplary embodiment of operability throughout the cloud network infrastructure of fig. 1 when classifying data flows transmitted between applications that are part of cloud instances deployed in different virtual private cloud networks (VPCs). Herein, according to one embodiment of the present disclosure, a data stream is received by a first virtual network device (block 500). The first virtual network device captures context information associated with the data stream, i.e., attributes associated with the data stream (block 510). These attributes may be directed to the source application from which the data stream originated, such as location attributes, workload attributes, identity attributes, or other attributes as identified in table a.

Based on these attributes, the first virtual network device determines a network policy (or network policy group) appropriate for the selected attribute of the data flow and selects a classification identifier (class ID) for the data flow based on the determined network policy (or network policy group) (blocks 520 and 530). Thereafter, the class ID is encapsulated into a portion of the data stream to form a categorized data stream (block 540). The first virtual network device outputs a classified data stream that the other virtual network device performs an action on before being received by an application that the source application is targeted to receive the data stream (block 550). These actions may include, but are not limited or restricted to, predictive routing based at least in part on class IDs, differentiated services (e.g., quality of service "QoS" or security), traffic restriction (e.g., filtering, etc.).

Embodiments of the invention may be embodied in other specific forms without departing from the spirit of the disclosure. The described embodiments are to be considered in all respects only as illustrative and not restrictive.

Claims

1. A computerized method for providing network policy based routing of data flows, comprising:

obtaining attributes associated with the incoming data stream;

determining one or more network policies based on attributes associated with the incoming data stream;

assigning a classification identifier based on the one or more network policies, wherein the classification identifier is configured to affect a routing path through at least one cloud network; and

the classification identifier is encapsulated into the content of the incoming data stream to generate a classified data stream for routing from a source to a destination over the at least one cloud network.

2. The computerized method of claim 1, wherein the source is a first cloud instance and the destination is a second cloud instance.

3. The computerized method of claim 2, wherein the first cloud instance is deployed within a first public cloud network and the second cloud instance is deployed within a second public cloud network different from the first public cloud network.

4. The computerized method of claim 1, wherein obtaining attributes associated with an incoming data stream comprises obtaining static attributes associated with the data stream based on characteristics associated with an ingress gateway receiving the incoming data stream.

5. The computerized method of claim 4, wherein the static attribute associated with the data stream comprises a location of an ingress gateway corresponding to a location of a cloud instance operating as a source of the data stream.

6. The computerized method of claim 1, wherein obtaining attributes associated with an incoming data stream comprises obtaining dynamic attributes associated with a data stream obtained based on a mapping between (i) a network address associated with a source of the incoming data stream and (ii) attributes associated with the source.

7. The computerized method of claim 1, wherein the determining of the one or more network policies comprises at least identifying one or more network policies related to the attribute.

8. The computerized method of claim 1, wherein the determining of the one or more network policies comprises performing a decision tree analysis by determining whether the incoming data stream includes a first selected one of the attributes, determining that the incoming data stream is associated with a first network policy based on the incoming data stream featuring the first selected attribute, and performing an iterative analysis with respect to attributes identifying data streams associated with a particular network policy.

9. The computerized method of claim 1, wherein assigning a classification identifier comprises identifying a classification identifier corresponding to one or more network policies determined to be associated with an incoming data flow.

10. The computerized method of claim 2, further comprising:

based on the classification identifier encapsulated into the content of the incoming data stream, it is determined which communication link or links are to be used in routing the data stream from the first gateway to the second gateway.

11. The computerized method of claim 10, further comprising:

after the second gateway receives the data stream, the classification identifier is removed and the content of the data stream is directed to the second cloud instance.

12. The computerized method of claim 11, wherein the first cloud instance is part of a first virtual private cloud network and the second cloud instance is part of a second virtual private cloud network.

13. The computerized method of claim 12, wherein the first virtual private cloud network is deployed within a first public cloud network and the second virtual private cloud network is deployed within a second public cloud network different from the first public cloud network.

14. A computing platform, comprising:

a controller; and

a first virtual private cloud network communicatively coupled to the controller, the first virtual private cloud network including at least a first gateway configured to assign a classification identifier to an incoming data stream,

wherein the first gateway is configured to (i) obtain attributes associated with a data flow of the incoming data flow, (ii) determine one or more network policies based on the attributes associated with the data flow, (iii) assign a classification identifier based on the one or more network policies, the classification identifier configured to affect a routing path through at least one cloud network, and (iv) encapsulate the classification identifier into content of the data flow to generate a classified data flow for routing from the first gateway to a second gateway.

15. The computing platform of claim 14, wherein the first gateway of the first virtual private cloud network is communicatively coupled to a first cloud instance operating as a source of the data stream.

16. The computing platform of claim 15, wherein the first virtual private cloud network is deployed within a first public cloud network and the second gateway is implemented within a second virtual private cloud network deployed within a second public cloud network different from the first public cloud network.

17. The computing platform of claim 14, wherein the attributes comprise one or more static attributes associated with the data stream based on characteristics associated with the first gateway.

18. The computing platform of claim 17, wherein the one or more static attributes associated with the data stream include a location of the first gateway corresponding to a location of a cloud instance operating as a source of the data stream.

19. The computing platform of claim 17, wherein the attributes further comprise one or more dynamic attributes associated with the data stream obtained from a mapping between (i) a network address associated with a source of the data stream and (ii) the attributes associated with the source.

20. The computing platform of claim 14, wherein the first gateway is configured to determine one or more network policies by at least identifying one or more network policies related to the attribute.

21. The computing platform of claim 14, wherein the first gateway is further configured to determine which communication link or links to use in routing the data stream from the first gateway to the second gateway based on the classification identifier encapsulated into the content of the data stream.

22. The computing platform of claim 21, further comprising:

after the data stream is received by the second gateway, the classification identifier is removed and the content of the data stream is directed to a second cloud instance operating as a destination of the data stream.