Patent Application
20210399964
A wide area network (WAN) may extend across multiple network sites (e.g. geographical, logical). Sites of the WAN are interconnected so that devices at one site can access resources at another site. In some topologies, many services and resources are installed at core sites (e.g. datacenters, headquarters), and many branch sites (e.g. regional offices, retail stores) connect client devices (e.g. laptops, smartphones, internet of things devices) to the WAN. These types of topologies are often used by enterprises in establishing their corporate network.
Each network site has its own local area network (LAN) that is connected to the other LANs of the other sites to form the WAN. Networking infrastructure, such as switches and routers are used to forward network traffic through each of the LANs, through the WAN as a whole, and between the WAN and the Internet. Each network site's LAN is connected to the wider network (e.g. to the WAN, to the Internet) through a gateway router. Branch gateways (BGs) connect branch sites to the wider network, and head-end gateways (also known as virtual internet gateways) connect core sites to the wider network.
Often, WANs are implemented using software defined wide area network (SD-WAN) technology. SD-WAN may simplify the management and operation of a WAN by decoupling (separating) the networking hardware from its control mechanism. SD-WAN solutions may employ centrally managed WAN edge devices placed in branch offices to establish logical connections with other branch edge devices across a physical WAN.
For a more complete understanding of the present disclosure, examples in accordance with the various features described herein may be more readily understood with reference to the following detailed description taken in conjunction with the accompanying drawings, where like reference numerals designate like structural elements, and in which;
A BG may include multiple uplinks to the broader WAN for sending application traffic based on the application's requirement. These uplinks may provide diversity across technology (e.g. MPLS versus DSL), provider, and geography (based on the provider's network). The uplinks also provide high availability (redundancy if a subset of the uplinks go down) and increase total bandwidth. If an uplink goes down, the applications may switchover to other uplinks in order to maintain uninterrupted service.
BG may periodically evaluate each uplink, in the SD-WAN, to assess their health and ensure quality of service (QoS) as network conditions change. If an uplink is not healthy enough to meet a service level agreement (SLA) between BG and an application, that describes minimum health for good operation of the application, the uplink may be determined to be failed. In such instances, the application may migrate to a healthier uplink in order to maintain uninterrupted service.
In order to gauge an uplink's health, BG actively probes the uplink by sending probe packets through the uplink. Generally, probing uses a predefined probe profile (e.g., a static probe profile) that defines a number of probes (including retries), probe interval and a wait time. A probe interval may be a time interval between two probes such that no intervening probe is sent between the two probes. That is, expiration of probe interval may trigger sending the probe again. The duration of the probe interval may vary, for example, from milliseconds to minutes. A response may be received in reply to a probe within the probe interval. For each probe, network parameters of the uplink may be determined in order to keep a track of the health of the uplink. Examples of the network parameters that may be determined may include jitter, RTT, latency, packet-loss, throughput and bandwidth. A probe retry value may define a number of times probes may be sent before declaring failure of the uplink. Wait time may define a total time elapsed (or a time limit) in performing probing as per a probe profile before detecting failure of the uplink.
BG may confirm that an uplink's health is good when a response to probing is received within a wait time while performing probing. When BG does not receive a response to probing, BG may assess the uplink's health to be bad (i.e., not good enough to meet an application's SLA) and the uplink is detected as failed.
Since the static probe profile may not adapt to an uplink's changing health, available detection methods may not get a sense of accurate uplink's health. For example, in a scenario, BG may not receive response to probing within the wait time as per the static probe profile, due to traffic congestion in certain times of day or week, and detected failure of the uplink. This detection of uplink's failure may cause unnecessary migration of applications among uplinks, which may be detrimental for the operation of the applications and reduce QoS.
In the present disclosure, BG may estimate, using a predicted probe profile, whether an uplink in an SD-WAN is failed. A SD-WAN device may dynamically determine the predicted probe profile based on the learnings of the behavior of the uplink in a predetermined period of time. In the examples described herein, the SD-WAN device may determine the predicted probe profile based on predicted RTT values of the uplink using a machine learning algorithm. SD-WAN device may gather RTT values of the uplink for a predetermined period of time such as hours, days or weeks and generate predicted RTT values based on the gathered RTT values. BG may receive the predicted probe profile and perform probing of the uplink using the predicted probe profile for estimating whether the uplink is failed. For example, BG may determine whether a response to the probing is not received in a predicted wait time in accordance with the predicted probe profile to estimate that the uplink is failed.
Then, BG may compute a confidence level value based on one or more network parameters including RTT, jitter or packet loss of the uplink. The confidence level value may represent accuracy of the estimated failure of the uplink. In an example, BG computes the confidence level value based on baseline values of RTT and jitter. Based on the confidence level value, BG may determine whether the estimated failure of the uplink is acceptable to detect a status of the uplink. For example, BG may determine that the estimated failure of the uplink is acceptable when the confidence level value is higher than a predetermined threshold value of confidence level for an application, and thereby detect that a status of the uplink is failed. In another example, BG may determine that the estimated failure of the uplink is not acceptable when the confidence level value is lower than a predetermined threshold value of confidence level for an application, and thereby detect that the status of the uplink is not failed.
BG may periodically receive predicted probe profile and estimate, using the predicted probe profile, whether the uplink is failed. In response to estimating that the uplink is failed, BG computes a confidence level value that represents accuracy of the estimated failure of the uplink and thereby detect a status of the uplink. Thus, the present disclosure advantageously provide more accurate status of an uplink as compared to available detection methods.
BG 102 may communicate with the headend gateway 104 over a computer network. The computer network may be a wireless or wired network. The computer network may include, for example, a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a Storage Area Network (SAN), a Campus Area Network (CAN), or the like. Further, the computer network may be a public network (for example, the Internet) or a private network
The headend gateway 104 may transceive data relating to one or more applications, which are transported in SD-WAN 100 through the uplink 110. The headend gateway 104 may be referred to as a destination endpoint that receive the data. In an example, the headend gateway 104 may be an endpoint for an SD-WAN device Layer 3 Virtual Private Network (L3VPN) overlay based on Internet Protocol Security (IPsec) tunneling. In order to establish a secure communication channel between the BG 102 and the headend gateway 104, a protocol, such as Internet Protocol Security (IPsec) may be used.
IPsec is a network protocol suite that authenticates and encrypts the packets of data sent over a network. IPsec, for example, may extend private networks through creation of encrypted tunnels which secure site to site connectivity across untrusted networks. IPsec may protect data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. An IPsec tunnel may allow encrypted IP traffic to be exchanged between the participating entities.
In an example, headend gateway 104 may be a part of a datacenter network or a campus network. In an example, the headend gateway 104 may act as a VPN concentrator (VPNC) and run at the headend in hub-and-spoke and multi hub-and-spoke topologies. A VPN concentrator may provide a secure creation of VPN connections and delivery of messages between VPN nodes. The headend gateway 104 may act as a terminating point for IPsec VPN tunnels. The headend gateway 104 may be located, for example, at headquarter or a data center of an enterprise.
BG 102 may communicate with the headend gateway 104 through the uplink 110 as illustrated in
BG 102 may provide the functionality to detect a status of the uplink 110. In an example, the BG 102 may be capable of detecting status of the uplink 110 at a real-time basis. The status detection functionality of the BG 102 may be described in detail with reference to the
BG 102 may include a processing circuitry 112 and a memory 114 communicatively coupled through a system bus. Processing circuitry 112 may be any type of Central Processing Unit (CPU), microprocessor, or processing logic that interprets and executes machine-readable instructions stored in memory 114. Memory 114 may be a random access memory (RAM) or another type of dynamic storage device that may store information and machine-readable instructions that may be executed by processing circuitry 112. For example, memory 114 may be Synchronous DRAM (SDRAM), Double Data Rate (DDR), Rambus DRAM (RDRAM), Rambus RAM, etc. or storage memory media such as a floppy disk, a hard disk, a CD-ROM, a DVD, a pen drive, and the like. In an example, memory 114 may be a non-transitory machine-readable medium.
In an example, memory 114 may store machine-readable instructions (i.e. program code) 122, 124, and 126 that, when executed by the processing circuitry 112, may at least partially implement some or all functions of BG 102.
Instructions 122 may be executed by BG 102 to receive a predicted probe profile determined based on predicted RTT values, of the uplink 110, generated using a machine learning algorithm. In an example, the predicted probe profile may be received from a management device present in SD-WAN 100 or a cloud system coupled to the SD-WAN 100. The management device may include any combination of hardware and programming to implement the functionalities of the management device as described herein. In an example, the management device may store and execute machine-executable instructions stored in a processing circuitry communicatively coupled to a memory. Memory may be a non-transitory, computer-readable medium including instructions that, when executed by processing circuitry, cause the device to undertake certain actions. In some examples, the management device may be a service or application executing on one or more computing devices in SD-WAN or cloud computing device(s). The management device may be provided to the SD-WAN 100 as a service (aaS).
Cloud system may be a private cloud, a public cloud, or a hybrid cloud. The cloud system may be used to provide or deploy various types of cloud services. These may include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), and so forth.
The management device may receive or gather information that includes network parameters of the uplink 110 over a predetermined period of time. The predetermined period of time may range from hours or days defined by an administrator. The predetermined period of time may be defined depending on peak hours or off-peak hours, deployment type based on geolocations, topology, QoS, sensitivity of applications etc. The data so gathered may be referred to as “training data” and leveraged to predict a probe profile (i.e., predicted probe profile). The gathered data (or training data) may include one or more network parameters determined during probing over the predetermined period of time. The network parameter(s) determined during probing may include jitter, RTT, and packet-loss. Packet-loss may represent a number of packets that are lost or a response to which is not received w.r.t a total number of packets sent during probing. Packet-loss may also be represented in terms of packet received i.e. a number of packets received w.r.t. a total number of packets sent during probing.
Once data is gathered about RTT values, the management device may use a machine learning algorithm to generate predicted RTT values. In an example, the machine learning algorithm may be a time series model. Examples of the time series model may include Long-Short Term Memory neural set (LSTM) model, Auto Regressive Integrated Moving Average (ARIMA) model, Gated Recurrent Unit (GRU) model etc. In certain examples, the predicted RTT values may be determined using LSTM model.
The management device may generate a number of predicted RTT values equal to the probe retry value as defined in probe profile used while probing the uplink 110 in the predetermined period of time.
Based on the predicted RTT values, the device may determine a predicted wait time. In an example, the predicted wait time may be calculated using equation 1.
Predicted wait time=Number of predicted RTT values×Max predicted RTT value Equation 1
Where, Max predicted RTT value is a maximum RTT value observed out of the predicted RTT values.
In some examples, a predicted probe retry value may be determined depending on the probe interval. The predicted probe retry value may be calculated using equation 2.
Predicted probe retry value=Predicted Wait time/probe interval Equation 2
By tailoring probe interval, the predicted probe retry value may be adjusted for the predicted probe profile to be used for probing.
Once the information about the predicted probe profile is received by BG 102, instructions 124 may be executed by BG 102 to estimate, using the predicted probe profile, whether the uplink 110 is failed. In order to estimate whether the uplink 110 is failed, BG 102 may perform probing using the predicted probe profile and determine whether a response to probing the uplink 110 is received in accordance with the predicted probe profile. Performing probing may include sending probes through the uplink 110 in accordance with the predicted probe profile. For example, BG 102 may perform probing as per calculated probe retry value (equation 2). BG 102 may perform probing until the expiration of the predicted wait time. BG 102 may determine whether a response to probing the uplink 110 is received in the predicted wait time (as calculated using equation 1). In instances when a response to probing is received in the predicted wait time, BG 102 does not estimate failure of the uplink 110. In instances when no response to probing is received in the predicted wait time, BG 102 estimates that the uplink 110 is failed.
Upon expiration of the predicted wait time, BG 102 may receive a successive predicted probe profile generated based on training data gathered for a successive period of time from a time stamp of the expiration of the previous predicted wait time. In an example, the successive probe profile may be predicted at an instant of time, when probing initiates according to successive predicted probe profile. The successive predictive probe profile may continue until the expiration of the successive predictive wait time.
A predetermined period of time may be measured from an instant of time (e.g., a first instant of time) when probing initiates (or immediately before the probing initiates) according to the predicted probe profile.
In response to estimating failure of the uplink 110, instructions 126 may be executed by BG 102 to compute a confidence level value. The confidence level value may represent accuracy of the estimated failure of the uplink 110. The confidence level value may be computed based on one or more network parameters. The network parameters may include RTT, jitter, latency, packet-loss, bandwidth-utilization, etc. In an example, BG 102 may compute a confidence level value based on packet-loss, RTT and jitter.
BG 102 may calculate the confidence level value using a baseline value of the one or more network parameter(s). In the examples described herein, the confidence level value may be computed using baseline values of RTT (i.e., RTT baseline value) and jitter (i.e., jitter baseline value).
A baseline value of a network parameter may be determined using a baselining algorithm. In an example, the baselining algorithm may be based on factors, for example, mean, median, most frequent value, maximum value, or one-class support vector machine. In an example, the baselining algorithm may use values observed over a period of time for a network parameter with respect to an uplink. The baselining algorithm may use a dataset comprising values of the network parameter recorded over a period of time to get baseline value of that network parameter. For example, baseline values may be determined for network parameters jitter and RTT by running the baselining algorithm over the data gathered in a week. When a value of a network parameter is in negative deviation with the baseline value of that network parameter, the health of the uplink may be determined to be good.
In an example, the baseline value of a network parameter may be updated by executing the baselining algorithm at a regular interval which may vary, for example, from an hour to a week, or it may include another duration, as determined by a user. The values observed over a period of time for a network parameter with respect to an uplink may be stored, for example, on BG 102 and may be used for updating the baseline values of the network parameters at a regular interval.
In an example, BG 102 may calculate the confidence level value using equation 3.
Confidence level value=0.7×packet received (%)+0.2×RTT values in negative deviation (%)+0.1×Jitter values in negative deviation (%) Equation 3
Where, packet-received (%) represents percentage of probes to which a response is received while probing. Packet received (%) may be calculated using equation 4.
RTT values in negative deviation (%) represents percentage of a number of probes to which RTT value is in negative deviation with RTT baseline value. RTT values in negative deviation (%) may be calculated using equation 5.
Jitter values in negative deviation (%) represents percentage of a number of probes to which jitter value is in negative deviation with the jitter baseline value. Jitter values in negative deviation (%) may be calculated using equation 6.
Although the algorithm described in equation 3 is not the only way to determine a confidence level value for an uplink, equation 3 generates a confidence level value based on RTT and jitter of the uplink.
The confidence level value may be high or low. A high or low confidence level value for an uplink may be defined with respect to a predetermined threshold value of confidence level for an application. A predetermined threshold value of confidence level for an application may be a measure of the confidence level value for that application to estimate whether the uplink is failed (i.e., uplink' health is not good enough to meet application's SLA) for functioning that application through the uplink.
Once the confidence level value is calculated, instructions 128 may be executed by BG 102 to determine whether the estimated failure of the uplink 110 is acceptable based on the confidence level value to detect a status of the uplink 110. That is, a status of the uplink 110 may be detected based on the confidence level value. In some examples, the instructions 128 may further include instructions executed by BG 102 to determine whether the computed confidence level value is higher than a predetermined threshold value of confidence level for an application. Upon determining that the computed confidence level value is high (i.e., higher than the predetermined threshold value of confidence level for an application), BG 102 may determine that the estimated failure of the uplink 110 for that application is acceptable. In these instances, BG 102 may detect that a status of the uplink is failed. In such instances, the uplink 110 for the application may be declared dead and the application may be migrated to another uplink.
In some other examples, upon determining that the computed confidence level value is low (i.e., lower than the predetermined threshold value of confidence level), BG 102 may determine that the estimated failure of the uplink 110 for that application is not acceptable. In these instances, BG 102 may detect that a status of the uplink 110 is not failed. In such instances, the uplink 110 for the application may not be declared dead and the application may continue using the uplink 110. BG 102 may continue sending probes as per successive predicted probe profiles through the uplink 110 until the confidence level value reaches to the predetermined threshold value of confidence level for that application.
As shown in
Instructions 406 may be executed to receive a predicted probe profile determined based on predicted RTT values, of an uplink in an SD-WAN, generated using a machine learning algorithm such as a time series model. In some examples, the predicted RTT values may be generated, using a time series model, based on data gathered Including RTT values of the uplink in a predetermined period of time. A predicted wait time and/or a predicted probe retry value may be determined based on the predicted RTT values using equations 1 and 2, respectively, to define the predicted probe profile.
Instructions 408 may be executed to estimate, using the predicted probe profile, whether the uplink 110 is failed. In some examples, instructions 408 may be executed to perform probing of the uplink using the predicted probe profile and determine whether a response to probing the uplink is received in the predicted wait time. When a response to probing the uplink is received in the predicted wait time, it may be estimated that the uplink is failed.
In response to estimated failure of the uplink, instructions 410 may be executed to compute a confidence level value. The confidence level value may be computed based on network parameters including RTT, jitter and packet-loss. In an example, the confidence level value may be calculated using equation 3.
Instructions 412 may be executed to determine whether the estimated failure of the uplink is acceptable based on the confidence level value to detect a status of the uplink. In instances when the confidence level value is high (i.e., higher than a predetermined threshold value of confidence level for an application), the estimated failure of the uplink is acceptable. In these examples, the status of the uplink is detected “failed.” In instances when the confidence level value is low (i.e., lower than a predetermined threshold value of confidence level for an application), the estimated failure of the uplink is not acceptable. In such examples, the status of the uplink 110 is detected “not failed.”
The instructions 406-412 may include various instructions to execute at least a part of the method described in
In block 502, a predicted probe profile that is determined based on predicted RTT values of an uplink is received. The predicted RTT values of the uplink may be generated using a machine learning algorithm based on training data gathered over a predetermined period of time. A predicted wait time and/or a predicted probe retry value may be determined based on the predicted RTT values using equations 1 and 2, respectively, to define the predicted probe profile. In an example, the predicted probe profile may be received from another device present in the SD-WAN or a cloud system.
In block 504, it may be estimated, using the predicted probe profile, whether the uplink is failed. In some examples, probing of the uplink may be performed using the predicted probe profile, and it may be determined whether a response to probing is received in accordance with the predicted probe profile. In an example, it may be determined whether a response to probing is received in a predicted wait time. In some examples, upon determining that a response to probing is received in accordance with the predicted probe profile, the failure of the uplink 110 is not estimated (‘NO’ at block 506). In these instances, probing of the uplink may continue using predicted probe profiles (generated periodically) for tracking a status of the uplink. In other examples, upon determining that no response to probing is received in accordance with the predicted probe profile, the failure of the uplink is estimated (‘YES’ at block 506).
In response to estimating failure of the uplink, in block 508, a confidence level value may be computed based on one or more network parameters. In an example, the confidence level value may be computed based on RTT, jitter and packet-loss. In an example, the confidence level value may be calculated using equation 3.
In block 510, it may be determined whether the estimated failure of the uplink is acceptable based on the confidence level value to detect a status of the uplink. In some examples, it may be determined whether the confidence level value is high (i.e., higher than a predetermined threshold value of confidence level for an application). In instances when the confidence level value is high (‘YES’ at block 512), it may be determined that the estimated failure of the uplink is acceptable, in block 514. Accordingly, a status of the uplink is detected “failed.” In instances when the confidence level value is not high (‘NO’ at block 512), the estimated failure of the uplink is not acceptable, in block 516. In such examples, a status of the uplink 110 is detected “not failed.”
A software defined wide area network (SD-WAN) is a SDN that controls the interaction of various sites of a WAN. Each site may have one or more LANs, and LANs connect to one another via WAN uplinks. Some WAN uplinks are dedicated lines (e.g. MPLS), and others are shared routes through the Internet (e.g. DSL, T1, LTE, 5G, etc.). An SD-WAN dynamically configures the WAN uplinks and data traffic passing through the WAN uplinks to effectively use the resources of the WAN uplinks.
Branch gateways are network infrastructure devices that are placed at the edge of a branch LAN. Often branch gateways are routers that interface between the LAN and a wider network, whether it be directly to other LANs of the WAN via dedicated network links (e.g. MPLS) or to the other LANs of the WAN via the Internet through links provided by an Internet Service Provider connection. Many branch gateways can establish multiple uplinks to the WAN, both to multiple other LAN sites, and also redundant uplinks to a single other LAN site. Branch gateways also often include network controllers for the branch LAN. In such examples, a branch gateway in use in a SD-WAN may include a network controller that is logically partitioned from an included router. The network controller may control infrastructure devices of the branch LAN, and may receive routing commands from a network orchestrator.
An administrator is a person, network service, or combination thereof that has administrative access to network infrastructure devices and configures devices to conform to a network topology. In an example, the administrator is a person expert in the domain.
Processing circuitry is circuitry that receives instructions and data and executes the instructions. Processing circuitry may include application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), microcontrollers, central processing units (CPUs), graphics processing units (GPUs), microprocessors, or any other appropriate circuitry capable of receiving instructions and data and executing the instructions. Processing circuitry may include one processor or multiple processors. Processing circuitry may include caches. Processing circuitry may interface with other components of a device, including memory, network interfaces, peripheral devices, supporting circuitry, data buses, or any other appropriate component. Processors of a processing circuitry may communicate to one another through shared cache, interprocessor communication, or any other appropriate technology.
Memory is one or more non-transitory computer-readable medium capable of storing instructions and data. Memory may include random access memory (RAM), read only memory (ROM), processor cache, removable media (e.g. CD-ROM, USB Flash Drive), storage drives (e.g. hard drive (HDD), solid state drive (SSD)), network storage (e.g. network attached storage (NAS)), and/or cloud storage. In this disclosure, unless otherwise specified, all references to memory, and to instructions and data stored in memory, can refer to instructions and data stored in any non-transitory computer-readable medium capable of storing instructions and data or any combination of such non-transitory computer-readable media.
The features of the present disclosure can be implemented using a variety of specific devices that contain a variety of different technologies and characteristics. As an example, features that include instructions to be executed by processing circuitry may store the instructions in a cache of the processing circuitry, in random access memory (RAM), in hard drive, in a removable drive (e.g. CD-ROM), in a field programmable gate array (FPGA), in read only memory (ROM), or in any other non-transitory, computer-readable medium, as is appropriate to the specific device and the specific example implementation. As would be dear to a person having ordinary skill in the art, the features of the present disclosure are not altered by the technology, whether known or as yet unknown, and the characteristics of specific devices the features are implemented on. Any modifications or alterations that would be required to implement the features of the present disclosure on a specific device or in a specific example would be obvious to a person having ordinary skill in the relevant art.
Although the present disclosure has been described in detail, it should be understood that various changes, substitutions and alterations can be made without departing from the spirit and scope of the disclosure. Any use of the words “may” or “can” in respect to features of the disclosure indicates that certain examples include the feature and certain other examples do not include the feature, as is appropriate given the context. Any use of the words “or” and “and” in respect to features of the disclosure indicates that examples can contain any combination of the listed features, as is appropriate given the context.
Phrases and parentheticals beginning with “e.g.” or “i.e.” are used to provide examples merely for the purpose of clarity. It is not intended that the disclosure be limited by the examples provided in these phrases and parentheticals. The scope and understanding of this disclosure may include certain examples that are not disclosed in such phrases and parentheticals
The foregoing description of various examples has been presented for purposes of illustration and description. The foregoing description is not intended to be exhaustive or limiting to the examples disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of various examples. The examples discussed herein were chosen and described in order to explain the principles and the nature of various examples of the present disclosure and its practical application to enable one skilled in the art to utilize the present disclosure in various examples and with various modifications as are suited to the particular use contemplated. The features of the examples described herein may be combined in all possible combinations of methods, apparatus, modules, systems, and computer program products.
| Number | Date | Country | Kind |
|---|---|---|---|
| IN 202041026001 | Jun 2020 | IN | national |
