Patent Description:
Over the last few decades, the Internet has grown exponentially from a small network comprising of few nodes to a worldwide pervasive network that services more than a billion users. Today, individual subscribers are not limited to running a few network sessions with voice and / or data downloads over the network. Instead, the extent of services used by subscribers varies widely from multimedia gaming, audio and video streaming, web services, voice over IP (VoIP), and the like. With new technology penetration, such as increased utilization of Internet of Things (IoT) and M2M (machine to machine) communications, the network services and the software applications that a given subscriber may require also varies from a few sessions to multiple sessions having concurrent flows. This number is growing rapidly as subscribers increasingly run multiple applications, services, transactions simultaneously. The increased amount and variety of subscriber sessions and packet flows create challenges for network service providers with respect to network performance, such as latency, delay, and jitter.

<CIT> relates to a 'Selective and dynamic application-centric network measurement infrastructure". <CIT> relates to 'Diagnostic testing'. <CIT> does not disclose, at least, the in response to detecting that the data flow is no longer being received by the network device, ceasing the probing process for the data flow on the first link feature of the present independent claims.

In general, the disclosure describes techniques for evaluating traffic flows for a particular application and initiating a corresponding synthetic probing process when the traffic flow for the particular application is received, with the probing process generating various Quality of Experience (QoE) metrics for the link on which the traffic flow will be transmitted. Similarly, when a Software-Defined Wide Area Networks (SD-WAN) appliance that implements the techniques described herein detects that the traffic flow for the particular application is completed, or that the SD-WAN appliance otherwise is not receiving the traffic flow, the SD-WAN appliance may cease the synthetic probing process that corresponds to the application.

In some SD-WANs, the SD-WAN routing appliance may specify a path for data flows between client devices and application servers. These paths are typically selected using service-level agreement (SLA) parameters and various metrics of the WAN links. While the SLA parameters may be more static in nature, or at least predetermined prior to the SD-WAN appliance receiving the flow, the metrics of the various WAN links may be more dynamic, as the metrics describing the capabilities of the particular WAN link may vary based on various current aspects of the network. These metrics are obtained by sending probe packets on the various links and analyzing the results of the transmission, where probe packets having the same size as the data packets in the data flow reasonably measure how the particular WAN link could handle the data flow.

Instead of sending one or more preconfigured probe packets over each WAN link to continuously have all of the necessary QoE metrics for every link, the techniques described herein may only initiate a probing process on the links that are currently receiving traffic. To amplify the benefits of these techniques, rather than sending a set of pre-configured probe packets whenever any traffic is flowing over a link, the SD-WAN appliance described herein may only utilize a subset of one or more of those probe packets that will provide valuable QoE metrics for the particular application associated with the traffic being received and transmitted.

If, during the middle of the transmission of the traffic flow, the traffic flow is to be moved to a different link, the SD-WAN appliance described herein may cease the probing process on the previous link and initiate the probing process on the new link. Traffic flows change links for any variety of reasons, including switching from a default WAN link to an optimal equal-cost multi-path (ECMP) link based on the QoE metrics and the SLA metrics for the application. Another reason may be that the SLA metrics for the application are no longer being met by the original link, but the SLA metrics would be satisfied by moving the traffic to the second link.

These techniques may also be extended within queues of the respective links. For instance, a singular WAN link may include multiple different queues. Rather than send the one or more probe packets over each queue of the WAN link, the SD-WAN appliance may only send the one or more probe packets over the particular queue that is experiencing the traffic. This additional level of granularity may increase the benefits of the techniques described herein.

There may be one or more advantages to using the techniques described herein. As one example, because the techniques of this disclosure may send probe packets on an as-needed basis, SD-WAN networks that implement the techniques described herein may be more scalable, enabling such networks to include more potential links and more client devices without correspondingly increasing the overhead caused by the probing processes. For systems having the same amount of links and client devices, an SD-WAN that implements the techniques described herein may consume fewer computing resources than previous systems, such as bandwidth, memory, and battery power. This may increase efficiency of the SD-WAN systems in general, as the SD-WAN that implements the techniques described herein may consume less bandwidth and decrease the processing time for generating QoE metrics. Overall, the techniques describe herein may decrease the load on an SD-WAN appliance by decreasing an amount of storage and processing of service level agreement (SLA) results, logs, etc..

In one example of the techniques described herein, a method according to claim <NUM> is described.

In another example of the techniques described herein, a network device according to claim <NUM> is described.

In another example of the techniques described herein, a computer-readable medium according to claim <NUM> is described.

<FIG> is a block diagram illustrating an example software-defined wide area network system that performs an on-demand active synthetic probing process, in accordance with the techniques of this disclosure.

The example network system of <FIG> includes a service provider network <NUM> that operates as a private network to provide packet-based network services to subscriber devices <NUM>. That is, service provider network <NUM> provides authentication and establishment of network access for subscriber devices <NUM> such that a subscriber device may begin exchanging data packets with public network <NUM>, which may be an internal or external packet-based network such as the Internet.

In the example of <FIG>, service provider network <NUM> comprises access network <NUM> that provides connectivity to public network <NUM> via service provider software-defined wide area network <NUM> (hereinafter, "SD-WAN <NUM>") and router <NUM>. SD-WAN <NUM> and public network <NUM> provide packet-based services that are available for request and use by subscriber devices <NUM>. As examples, SD-WAN <NUM> and/or public network <NUM> may provide bulk data delivery, voice over Internet protocol (VoIP), Internet Protocol television (IPTV), Short Messaging Service (SMS), Wireless Application Protocol (WAP) service, or customer-specific application services. Public network <NUM> may comprise, for instance, a local area network (LAN), a wide area network (WAN), the Internet, a virtual LAN (VLAN), an enterprise LAN, a layer <NUM> virtual private network (VPN), an Internet Protocol (IP) intranet operated by the service provider that operates access network <NUM>, an enterprise IP network, or some combination thereof. In various examples, public network <NUM> is connected to a public WAN, the Internet, or to other networks. Public network <NUM> executes one or more packet data protocols (PDPs), such as IP (IPv4 and/or IPv6), X. <NUM> or Point-to-Point Protocol (PPP), to enable packet-based transport of public network <NUM> services.

In general, subscriber devices <NUM> connect to gateway router <NUM> via access network <NUM> to receive connectivity to subscriber services for applications hosted by public network <NUM> or router <NUM>. A subscriber may represent, for instance, an enterprise, a residential subscriber, or a mobile subscriber. Subscriber devices <NUM> may be, for example, personal computers, laptop computers or other types of computing devices positioned behind customer equipment (CE) <NUM>, which may provide local routing and switching functions. Each of subscriber devices <NUM> may run a variety of software applications, such as word processing and other office support software, web browsing software, software to support voice calls, video games, video conferencing, and email, among others. For example, subscriber device <NUM> may be a variety of network-enabled devices, referred generally to as "Internet-of-Things" (IoT) devices, such as cameras, sensors (S), televisions, appliances, etc. In addition, subscriber devices <NUM> may comprise mobile devices that access the data services of service provider network <NUM> via a radio access network (RAN) <NUM>. Example mobile subscriber devices include mobile telephones, laptop or desktop computers having, e.g., a <NUM> wireless card, wireless-capable netbooks, video game devices, pagers, smart phones, personal data assistants (PDAs) or the like.

A network service provider operates, or in some cases leases, elements of access network <NUM> to provide packet transport between subscriber devices <NUM> and router <NUM>. Access network <NUM> represents a network that aggregates data traffic from one or more of subscriber devices <NUM> for transport to/from SD-WAN <NUM> of the service provider. Access network <NUM> includes network nodes that execute communication protocols to transport control and user data to facilitate communication between subscriber devices <NUM> and router <NUM>. Access network <NUM> may include a broadband access network, a wireless LAN, a public switched telephone network (PSTN), a customer premises equipment (CPE) network, or other type of access network, and may include or otherwise provide connectivity for cellular access networks, such as a radio access network (RAN) (not shown). Examples include networks conforming to a Universal Mobile Telecommunications System (UMTS) architecture, an evolution of UMTS referred to as Long Term Evolution (LTE), mobile IP standardized by the Internet Engineering Task Force (IETF), as well as other standards proposed by the <NUM>rd Generation Partnership Project (3GPP), <NUM>rd Generation Partnership Project <NUM> (3GGP/<NUM>) and the WiMAX forum.

SD-WAN appliance <NUM> may be a customer edge (CE) router, a provider edge (PE) router, or other network device between access network <NUM> and SD-WAN <NUM>. SD-WAN <NUM> offers packet-based connectivity to subscriber devices <NUM> attached to access network <NUM> for accessing public network <NUM> (e.g., the Internet). SD-WAN <NUM> may represent a public network that is owned and operated by a service provider to interconnect a plurality of networks, which may include access network <NUM>. In some examples, SD-WAN <NUM> may implement Multi-Protocol Label Switching (MPLS) forwarding and in such instances may be referred to as an MPLS network or MPLS backbone. In some instances, SD-WAN <NUM> represents a plurality of interconnected autonomous systems, such as the Internet, that offers services from one or more service providers. Public network <NUM> may represent the Internet. Public network <NUM> may represent an edge network coupled to SD-WAN <NUM> via a transit network <NUM> and one or more network devices, e.g., a customer edge device such as customer edge switch or router. Public network <NUM> may include a data center. Router <NUM> may exchange packets with service nodes <NUM> via virtual network <NUM>, and router <NUM> may forward packets to public network <NUM> via transit network <NUM>.

In examples of network <NUM> that include a wireline/broadband access network, router <NUM> may represent a Broadband Network Gateway (BNG), Broadband Remote Access Server (BRAS), MPLS PE router, core router or gateway, or Cable Modem Termination System (CMTS). In examples of network <NUM> that include a cellular access network as access network <NUM>, router <NUM> may represent a mobile gateway, for example, a Gateway General Packet Radio Service (GPRS) Serving Node (GGSN), an Access Gateway (aGW), or a Packet Data Network (PDN) Gateway (PGW). In other examples, the functionality described with respect to router <NUM> may be implemented in a switch, service card or another network element or component. In some examples, router <NUM> may itself be a service node.

A network service provider that administers at least parts of network <NUM> typically offers services to subscribers associated with devices, e.g., subscriber devices <NUM>, that access service provider network <NUM>. Services offered may include, for example, traditional Internet access, VoIP, video and multimedia services, and security services. As described above with respect to SD-WAN <NUM>, SD-WAN <NUM> may support multiple types of access network infrastructures that connect to service provider network access gateways to provide access to the offered services. In some instances, the network system may include subscriber devices <NUM> that attach to multiple different access networks <NUM> having varying architectures.

In general, any one or more of subscriber devices <NUM> may request authorization and data services by sending a session request to a gateway device such as SD-WAN appliance <NUM> or router <NUM>. In turn, software-defined wide area network ("SD-WAN") appliance <NUM> may access a central server (not shown) such as an Authentication, Authorization and Accounting (AAA) server to authenticate the one of subscriber devices <NUM> requesting network access. Once authenticated, any of subscriber devices <NUM> may send subscriber data traffic toward SD-WAN <NUM> to access and receive services provided by public network <NUM>, and such packets may traverse router <NUM> as part of at least one packet flow. In some examples, SD-WAN appliance <NUM> may forward all authenticated subscriber traffic to public network <NUM>, and router <NUM> may apply services <NUM> and/or steer particular subscriber traffic to a data center <NUM> if the subscriber traffic requires services on service nodes <NUM>. Applications (e.g., service applications) to be applied to the subscriber traffic may be hosted on service nodes <NUM>.

For example, when forwarding subscriber traffic, router <NUM> may direct individual subscriber packet flows through services <NUM> executing on one or more service cards installed within router <NUM>. In addition, or alternatively, service provider network <NUM> includes a data center <NUM> having a cluster of service nodes <NUM> that provide an execution environment for the mostly virtualized network services. In some examples, each of service nodes <NUM> represents a service instance. Each of service nodes <NUM> may apply one or more services to traffic flows. As such, router <NUM> may steer subscriber packet flows through defined sets of services provided by service nodes <NUM>. That is, in some examples, each subscriber packet flow may be forwarded through a particular ordered combination of services provided by service nodes <NUM>, each ordered set being referred to herein as a "service chain. " As examples, services <NUM> and/or service nodes <NUM> may apply stateful firewall (SFW) and security services, deep packet inspection (DPI), carrier grade network address translation (CGNAT), traffic destination function (TDF) services, media (voice/video) optimization, Internet Protocol security (IPSec)/virtual private network (VPN) services, hypertext transfer protocol (HTTP) filtering, counting, accounting, charging, and/or load balancing of packet flows, or other types of services applied to network traffic.

In the example of <FIG>, subscriber packet flows may be directed along a service chain that includes any of services <NUM> and/or services applied by service nodes <NUM>. Once processed at a terminal node of the service chain, i.e., the last service to be applied to packets flowing along a particular service path, the traffic may be directed to public network <NUM>.

Whereas a "service chain" defines one or more services to be applied in a particular order to provide a composite service for application to packet flows bound to the service chain, a "service tunnel" or "service path" refers to a logical and/or physical path taken by packet flows processed by a service chain along with the forwarding state for forwarding packet flows according to the service chain ordering. Each service chain may be associated with a respective service tunnel, and packet flows associated with each subscriber device <NUM> flow along service tunnels in accordance with a service profile associated with the respective subscriber. For example, a given subscriber may be associated with a particular service profile, which in turn is mapped to a service tunnel associated with a particular service chain. Similarly, another subscriber may be associated with a different service profile, which in turn is mapped to a service tunnel associated with a different service chain. In some examples, after SD-WAN appliance <NUM> has authenticated and established access sessions for the subscribers, SD-WAN appliance <NUM> or router <NUM> may direct packet flows for the subscribers along the appropriate service tunnels, thereby causing data center <NUM> to apply the requisite ordered services for the given subscriber. In some examples, SDN controller <NUM> may also provide a forwarding rule set to SD-WAN appliance <NUM> or router <NUM> for managing the forwarding path. In some examples, SDN controller <NUM> manages the forwarding path through all elements in data center <NUM> starting at router <NUM>.

In some examples, service nodes <NUM> may implement service chains using internally configured forwarding state that directs packets of the packet flow along the service chains for processing according to the identified set of service nodes <NUM>. Such forwarding state may specify tunnel interfaces for tunneling between service nodes <NUM> using network tunnels such as IP or Generic Route Encapsulation (GRE) tunnels, Network Virtualization using GRE (NVGRE), or by using VLANs, Virtual Extensible LANs (VXLANs), MPLS techniques, and so forth. In some instances, real or virtual switches, routers or other network elements that interconnect service nodes <NUM> may be configured to direct the packet flow to the service nodes <NUM> according to service chains.

In the example of <FIG>, service provider network <NUM> comprises a software defined network (SDN) and network functions virtualization (NFV) architecture. SDN controller device <NUM> may provide a high-level controller for configuring and managing the routing and switching infrastructure of service provider network <NUM>. NFV orchestrator device <NUM> may provide a high-level orchestrator for configuring and managing virtualization of network services into service nodes <NUM> of data center <NUM>. In some instances, SDN controller <NUM> manages deployment of virtual machines (VMs) within the operating environment of data center <NUM>. For example, SDN controller <NUM> may interact with provider edge (PE) router <NUM> to specify service chain information, described in more detail below. For example, the service chain information provided by SDN controller <NUM> may specify any combination and ordering of services provided by service nodes <NUM>, traffic engineering information for tunneling or otherwise transporting packet flows along service paths, rate limits, Type of Service (TOS) markings or packet classifiers that specify criteria for matching packet flows to a particular service chain. Further example details of an SDN controller are described in PCT International Patent Application <CIT>, the entire content of which is incorporated herein by reference.

Although illustrated as part of data center <NUM>, service nodes <NUM> may be network devices coupled by one or more switches or virtual switches of SD-WAN <NUM>. In one example, each of service nodes <NUM> may run as VMs in a virtual compute environment. Moreover, the compute environment may comprise a scalable cluster of general computing devices, such as x86 processor-based servers. As another example, service nodes <NUM> may comprise a combination of general purpose computing devices and special purpose appliances. As virtualized network services, individual network services provided by service nodes <NUM> can scale just as in a modern data center through the allocation of virtualized memory, processor utilization, storage and network policies, as well as horizontally by adding additional load-balanced VMs. In other examples, service nodes <NUM> may be gateway devices or other routers. In further examples, the functionality described with respect to each of service nodes <NUM> may be implemented in a switch, service card, or another network element or component.

As described herein, elements within network system <NUM>, such as SD-WAN appliance <NUM>, perform application data monitoring using various application quality of experience (QoE) metric functions, such as real-time performance monitoring (RPM) or two-way active measurement protocol (TWAMP), for example. That is, RPM and TWAMP may be used within service provider network <NUM> to measure both one-way and two-way or round-trip metrics of network performance, such as path connectivity, path delay, packet jitter, packet loss, packet re-ordering, and the like, e.g., on a per-subscriber basis between network devices, also referred to as hosts or endpoints. In general, a QoE measurement architecture includes network devices that each support the used protocol and perform specific roles to start data sessions and exchange test packets for the data sessions. In the example network architecture illustrated in <FIG>, SD-WAN appliance <NUM> is configured to perform the QoE metric predictions. SD-WAN appliance <NUM> allows for load sharing across connections and adjusts traffic flows based on network conditions to improve performance.

In SD-WAN topology, there may be many "hubs and spokes" consisting of subscriber devices <NUM> and services <NUM> connected to each other. To measure the QoE metrics for each of these connections, SD-WAN appliance <NUM> may control the transmission of probe packets designed to measure these QoE metrics based on the transmission process across each of the respective connections, also called paths or links. However, all of the paths might not be experiencing traffic at a given time, meaning that continuing to transmit the probe packets over these links may provide limited benefit and only lead to degradation of the links or unnecessary central processing unit (CPU) usage on the devices transmitting and receiving the links. The probe packets may have actual sizes similar to the sizes of actual application traffic, meaning that the probe packets can consume a considerable amount of bandwidth when transmitted. Rather than continuously performing the synthetic probing on all those paths, the techniques described herein may streamline the process such that the probing process is only completed on the paths experiencing traffic. Once the traffic on that particular path stops, the probing process would also stop.

SD-WAN appliance <NUM>, which performs the path selection algorithms, also determine QoE metrics, such as service level agreement (SLA) metrics that include round-trip time (RTT), jitter, and packet loss, which were influenced by applications' real-time parameters like packet size, queues and burst of packets to determine the best path. However, different applications have different packet sizes in their data flows. Furthermore, when a link in the network is not transmitting a data flow for a particular application received from services <NUM> and router <NUM>, if active probe packets corresponding to that particular application are transmitted over the same link to determine the SLA metrics, there may be unnecessary traffic over those links that could consume valuable bandwidth that could be used for other data flows. As described below with respect to <FIG> and <FIG>, the techniques described herein show how SD-WAN appliance <NUM> can implement a machine learning algorithm to determine when traffic flows for particular applications are received, matching these traffic flows to particular configurations of probe packets, and beginning a synthetic probing process that is only active while the traffic flows for that particular application continue to be received.

In accordance with the techniques described herein, SD-WAN appliance <NUM> may not be performing a probing process on a first link of a plurality of links. Some time later, SD-WAN appliance <NUM> may receive an application data packet of a data flow for an application. In response to receiving the application data packet, SD-WAN appliance <NUM> may assign the data flow to the first link and initiate the probing process for the data flow on the first link to determine one or more QoE metrics for the first link. After the data flow is complete, or otherwise interrupted such that SD-WAN appliance <NUM> is no longer receiving the data flow, SD-WAN appliance <NUM> may detect that the data flow is no longer being received. In response to detecting that the data flow is no longer being received, SD-WAN appliance <NUM> may cease the probing process for the data flow on the first link. The probing process described herein may include either sending a group of pre-configured probe packets over the link regardless of the type of traffic received. In other instance, the probing process described herein may include only transmitting a singular probe packet or a smaller group of two or more probe packets that are designed specifically to gather QoE metrics that would be applicable to the application transmitting the data flow, based on variables such as the packet sizes in the data flow, burst presence or size within the data flow, packet sizes of the probe packets, and burstiness of the probe packets. A burst flow, measured by burstiness, involves data packets sent intermittently in bursts rather than as a continuous stream.

In some examples, the metrics carried by QoE probe packets transmitted during the probing process may include one or more of timestamps for sending or receiving a test packet, error estimates for sending or receiving the test packet, a sequence number for sending the test packet, a time-to-live (TTL) value for the test packet, a keepalive packet data unit (PDU), and/or a count of serviced packets, bytes, or subscribers. The one-way and two-way network performance measurements may include keepalive or path connectivity, round trip time (RTT), path delay, packet jitter, packet re-ordering, packet loss, service latency measurements, or service load measurements based on the received metrics.

<FIG> is a block diagram illustrating an example SD-WAN <NUM>, in accordance with one or more techniques of this disclosure. In the example described herein, SD-WAN <NUM> includes three different WAN links: a first WAN link <NUM> coupling SD-WAN appliance <NUM> to a Multi-Protocol Layer Switching (MPLS) network <NUM>, a second WAN link <NUM> coupling SD-WAN appliance <NUM> to Internet <NUM>, and a third WAN link <NUM> coupling SD-WAN appliance <NUM> to long-term evolution (LTE) network <NUM>. In other examples, SD-WAN <NUM> may include any number of links of any suitable type for transmitting data flows between the client side (e.g., client device <NUM> and SD-WAN appliance <NUM>) and the application side (e.g., SD-WAN appliance <NUM> and application server <NUM>).

In accordance with the techniques described herein, SD-WAN appliance <NUM> may receive an application data packet traffic flow for a particular application. For instance, client device <NUM> may begin executing an application locally. The execution of the application may include communicating with application server <NUM>, and SD-WAN appliance <NUM> may be configured to forward the data flow from client device <NUM> to application server <NUM> via any of links <NUM>, <NUM>, and <NUM>.

Upon receiving the data flow for the application from client device <NUM>, SD-WAN appliance <NUM> assigns the data flow to a default link, for example one of links <NUM>, <NUM>, <NUM>. SD-WAN appliance <NUM> may perform this assignment based on the link being the default link for the system, the link being the default link for the application, or the link being an optimal link at the time based on QoE metrics for each of the links. For instance, SD-WAN appliance <NUM> may assign the data flow to internet link <NUM>. In addition to assigning the data flow, SD-WAN appliance <NUM> may also initiate a probing process on internet link <NUM> by beginning to send one or more probe packets over internet link <NUM> to determine one or more QoE metrics for internet link <NUM>.

SD-WAN appliance <NUM> may, at a later time, detect that the traffic flow for the particular application has ended, either by completion or some other form of interruption. In response to this determination, SD-WAN appliance <NUM> may cease the synthetic probing process by refraining from sending additional probes corresponding to the particular application.

In some instances, SD-WAN appliance <NUM> may perform these techniques for multiple queues, or overlay paths, in each of WAN links <NUM>, <NUM>, and <NUM>. For instance, Internet link <NUM> may include eight different queues or overlay links that are available to handle the data flow. Rather than generically send the plurality of probe packets to internet link <NUM>, SD-WAN appliance <NUM> may send the probe packets for the particular probing process only on the queues within internet link <NUM> that is actually transmitting the data flow to obtain, in a more fine-grained sense, metrics for the queue in internet link <NUM>. Throughout this disclosure, any technique performable on a per-link basis may also be performed on a per-queue basis within the respective link, including re-assigning data flows to other queues within the same link or re-assigning data flows from a queue in one link to a queue in a different link.

SD-WAN appliance <NUM> may configure a single default overlay link until the traffic is received. Once traffic is transmitted towards a particular node N1, node N1 can inform SD-WAN appliance <NUM>, and SD-WAN appliance <NUM> can retrieve configurations (e.g., policies, synthetic probes that suit the application, etc.) for all links of that ECMP. From this point, the active probing starts. Until the SLA result of the synthetic probe is available, the traffic is placed on a default link. Once the result is available, based on the SLA metrics, the traffic is sent on links which meet the SLA.

<FIG> is a block diagram illustrating an example software-defined wide area network appliance <NUM> configured to execute one or more on-demand active synthetic probing functions using a traffic engine <NUM>, in accordance with the techniques of this disclosure. SD-WAN appliance <NUM> may be described herein within the context of service provider network <NUM> of <FIG>, and may represent any of routers <NUM> or SD-WAN appliance <NUM>, for example. Moreover, while described with respect to a particular network device, e.g., a router, the techniques may be implemented by any network device that may operate as an SD-WAN appliance, such as a client device, a Layer <NUM> (L3) or L2/L3 switch, or server.

In this example, SD-WAN appliance <NUM> is divided into three logical or physical "planes" to include a control plane <NUM> that performs control operations for the device, a data plane <NUM> for forwarding transit network traffic and a service plane <NUM> for application of one or more network services <NUM> to transit packet flows that are forwarded by the router. That is, router <NUM> implements three separate functionalities (e.g., the routing/control, forwarding data and network service functionalities), either logically, e.g., as separate software instances executing on the same set of hardware components, or physically, e.g., as separate physical dedicated hardware components that either statically implement the functionality in hardware or dynamically execute software or a computer program to implement the functionality. In this example, a high-speed internal switch fabric <NUM> couples control plane <NUM>, service plane <NUM>, and data plane <NUM> to deliver data units and control messages among the units. Switch fabric <NUM> may represent an internal switch fabric or cross-bar, bus, or link.

In the example of <FIG>, control plane <NUM> includes control unit <NUM> having master microprocessor(s) <NUM>, which executes device management services, subscriber authentication and control plane routing functionality of SD-WAN appliance <NUM>. Microprocessor <NUM> may comprise one or more general- or special-purpose processors such as a digital signal processor (DSP), an ASIC, a field programmable gate array (FPGA), or any other equivalent logic device. Accordingly, the terms "processor" or "controller," as used herein, may refer to any one or more of the foregoing structures or any other structure operable to perform techniques described herein. Executables, such as traffic engine <NUM> and services <NUM>, may be operable by microprocessor <NUM> to perform various actions, operations, or functions of SD-WAN appliance <NUM>. For example, microprocessor <NUM> of SD-WAN appliance <NUM> may retrieve and execute instructions stored by various data stores that cause microprocessor <NUM> to perform the operations of traffic engine <NUM> and services <NUM>.

One or more storage components (e.g., RIB <NUM>) within SD-WAN appliance <NUM> may store information for processing during operation of SD-WAN appliance <NUM> (e.g., SD-WAN appliance <NUM> may store data accessed by traffic engine <NUM> and services <NUM> during execution at SD-WAN appliance <NUM>). In some examples, the storage component is a temporary memory, meaning that a primary purpose of the storage component is not long-term storage. Storage components on SD-WAN appliance <NUM> may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.

Storage components, in some examples, also include one or more computer-readable storage media. Storage components in some examples include one or more non-transitory computer-readable storage mediums. Storage components may be configured to store larger amounts of information than typically stored by volatile memory. Storage components may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage components may store program instructions and/or information (e.g., data) associated with traffic engine <NUM> and services <NUM>. Storage components <NUM> may include a memory configured to store data or other information associated with traffic engine <NUM> and services <NUM>.

In general, control unit <NUM> represents hardware or a combination of hardware and software of control that implements control plane protocols 89A-89N ("routing protocols <NUM>") to learn and maintain routing information within routing information base <NUM> ("RIB <NUM>"). RIB <NUM> may include information defining a topology of a network, such as service provider network of <FIG>. Routing protocols <NUM> interact with kernel <NUM> (e.g., by way of API calls) executing on control unit <NUM> to update RIB <NUM> based on routing protocol messages received by SD-WAN appliance <NUM>. Kernel <NUM> may resolve the topology defined by routing information in RIB <NUM> to select or determine one or more routes through the network. For example, the kernel may generate forwarding information in the form of forwarding information bases 103A-103N ("FIBs <NUM>") based on the network topology represented in RIB <NUM>, i.e., perform route resolution. Typically, kernel <NUM> generates FIBs <NUM> in the form of radix or other lookup trees to map packet information (e.g., header information having destination information and/or a label stack) to next hops and ultimately to interface ports of IFCs <NUM> associated with respective forwarding units <NUM>. Each of FIBs <NUM> may associate, for example, network destinations with specific next hops and corresponding IFCs <NUM>. For MPLS-related traffic forwarding, FIBs <NUM> stores, for a given FEC, label information that includes an incoming label, an outgoing label, and a next hop for a packet. Control unit <NUM> may then program forwarding units <NUM> of data plane <NUM> with FIBs <NUM>, which installs the FIBs within lookup ASICs <NUM>.

Data plane <NUM>, in this example, is a decentralized data plane in that data plane functionality and packet forwarding functionality is distributed among a plurality of forwarding units 112A-112N ("forwarding units <NUM>"). In the example of SD-WAN appliance <NUM>, data plane <NUM> includes forwarding units <NUM> that provide high-speed forwarding of network traffic received by interface cards 114A-114N ("IFCs <NUM>") via inbound links 116A-116N to outbound links 118A-118N. Forwarding units <NUM> may each comprise one or more packet forwarding engine ("PFE") coupled to respective interface cards <NUM> and may represent, for example, a dense port concentrator (DPC), modular port concentrator (MPC), flexible physical interface card (PIC) concentrator (FPC), or another line card, for example, that is insertable within a chassis or combination of chassis of SD-WAN appliance <NUM>.

As shown in the example of <FIG>, each of forwarding units <NUM> includes a respective one of lookup ASICs 106A-106N ("lookup ASICs <NUM>") that receives control and data session traffic via IFC cards <NUM>, performs route lookups and, based on routes installed to FIBs <NUM>, forwards the traffic either to control unit <NUM> (control traffic destined for SD-WAN appliance <NUM>) or to one of forwarding units <NUM> (transit data traffic) for output via an interface to one of output links <NUM>. In one example, lookup ASICs <NUM> are microcode-controlled chipsets programmably configured by a slave microprocessor (not shown) executing on each of forwarding units <NUM>. Specifically, in this example, each of ASICs <NUM> may be controllable by internal microcode programmed by a slave microprocessor.

When forwarding packets, control logic within each lookup ASICs <NUM> traverses the respective FIB <NUM> and, upon reaching a FIB entry for the packet (e.g., a leaf node), the microcode-implemented control logic automatically selects one or more forwarding next hops (FNHs) for forwarding the packet. In this way, ASICs <NUM> of forwarding units <NUM> process packets by performing a series of operations on each packet over respective internal packet forwarding paths as the packets traverse the internal architecture of SD-WAN appliance <NUM>. Operations may be performed, for example, on each packet based on any of a corresponding ingress interface, an ingress PFE <NUM>, an egress PFE <NUM>, an egress interface or other components of SD-WAN appliance <NUM> to which the packet is directed prior to egress, such as one or more service cards. Forwarding units <NUM> each include forwarding structures that, when executed, examine the contents of each packet (or another packet property, e.g., incoming interface) and on that basis make forwarding decisions, apply filters, and/or perform accounting, management, traffic analysis, and load balancing, for example.

In one example, each of forwarding units <NUM> arranges forwarding structures as next hop data that can be chained together as a series of "hops" along an internal packet forwarding path for the network device. In many instances, the forwarding structures perform lookup operations within internal memory of ASICs <NUM>, where the lookup may be performed against a tree (or trie) search, a table (or index) search. Other example operations that may be specified with the next hops include filter determination and application, or a rate limiter determination and application. Lookup operations locate, within a lookup data structure (e.g., a lookup tree), an item that matches packet contents or another property of the packet or packet flow, such as the inbound interface of the packet. The result of packet processing in accordance with the operations defined by the next hop forwarding structure within ASICs <NUM> determines the manner in which a packet is forwarded or otherwise processed by forwarding units <NUM> from its input interface on one of IFCs <NUM> to its output interface on one of IFCs <NUM>.

Lookup ASICs <NUM> may be implemented using forwarding application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. Each of forwarding units <NUM> may include substantially similar components to perform substantially similar functionality.

Service plane <NUM> of SD-WAN appliance <NUM> includes a plurality of service units 113A-<NUM> ("service units <NUM>") that may be, as examples, removable service cards, which are configured to apply network services to packets flowing through data plane <NUM>. That is, when forwarding packets, forwarding units <NUM> may steer packets to service plane <NUM> for application of one or more network services <NUM> by service units <NUM>. In this example, each of service units <NUM> includes a microprocessor <NUM> configured to execute hypervisor <NUM> to provide an operating environment for a plurality of network services <NUM>. As examples, service units <NUM> may apply firewall and security services, carrier grade network address translation (CG-NAT), media optimization (voice/video), IPSec/VPN services, deep packet inspection (DPI), HTTP filtering, counting, accounting, charging, and load balancing of packet flows or other types of services applied to network traffic. Each of services <NUM> may be implemented, for example, as virtual machines or containers executed by hypervisor <NUM> and microprocessor <NUM>.

In the example of <FIG>, control unit <NUM> provides an operating environment for traffic engine <NUM>. In some examples, control unit <NUM> may use traffic engine <NUM> to execute one or more TWAMP or RPM logical roles, such as a control client, a server, a sessions sender, and a session reflector.

If there are N number of nodes in the SD-WAN network that includes SD-WAN appliance <NUM>, each node may be connected to another by multiple equal cost overlay paths called a path group. If M is the number of overlay paths between any two given nodes, and P is the number of SLA probes with different probe types and/or probe parameters, the number of flows to be maintained in a normal case would be: <MAT>.

At a given time, if the traffic may only actually being transmitted on X links of the N * (N-<NUM>)/<NUM> total links. As such, the number of flows to be maintained by SD-WAN appliance <NUM> is only: <MAT>.

Traffic engine <NUM> may be configured to perform the techniques described throughout this disclosure. For instance, in accordance with the techniques described herein, traffic engine <NUM> may not be performing a probing process on a first link of a plurality of links. Sometime later, traffic engine <NUM> may receive an application data packet of a data flow for an application.

In response to receiving the application data packet, traffic engine <NUM> may assign the data flow to the first link and initiate the probing process for the data flow on the first link to determine one or more QoE metrics for the first link. In some instances, initiating the probing process for the data flow includes sending one or more synthetic probe packets over the first link to determine the one or more QoE metrics for the first link. These synthetic probe packets may simply be a plurality of probe packets that each have a unique, default configuration, and this plurality of probe packets may be independent of any particular characteristics of the application or the data flow.

In other instances, traffic engine <NUM> may perform application-specific probing in addition to the link-specific probing described throughout this disclosure. For example, in response to traffic engine <NUM> receiving the application data packet of the data flow for the application, traffic engine <NUM> determines an application signature of the application data packet, such as through the use of deep packet inspection (DPI). Traffic engine <NUM> may then determine, based on the application signature, a probe packet configuration for the data flow. This probe packet configuration may be such that the packet size and/or burstiness of the probe packets sent over the first link are similar to the packet size and/or burstiness of the application traffic that is being processed by traffic engine <NUM>. Traffic engine <NUM> may use the DPI to determine this information in real-time, or may use DPI to determine this information, store indications of the application signature and this information in a database, and then traffic engine <NUM> may retrieve that information when the application sends additional traffic at a later time. In these instances, initiating the probing process for the data flow would include traffic engine <NUM> sending one or more probe packets configured according to the probe packet configuration over the first link to determine the one or more QoE metrics for the first link.

The plurality of links are a plurality of equal-cost multi-path (ECMP) links. Initiating the probing process for the data flow includes, in response to receiving the application data packet of the data flow for the application, traffic engine <NUM> determining an application signature of the application data packet, such as by using DPI. Traffic engine <NUM> then determines, based on the application signature, a set of one or more service level agreement (SLA) metrics for the application and a destination of the data flow. While traffic engine <NUM> determines the optimal link for the data flow towards the destination, traffic engine <NUM> assigns the data flow to a default link of the plurality of ECMP links. Traffic engine <NUM> may then send one or more probe packets on each of the plurality of links to determine respective QoE metrics for each ECMP link of the plurality of ECMP links. Now having the QoE metrics for each ECMP link and the SLA metrics, traffic engine <NUM> determines which ECMP link has QoE metrics that satisfy the SLA metrics for the application. Traffic engine <NUM> then re-assigns the data flow from the default link to the ECMP link that satisfies the SLA metrics for the application, refraining from sending additional probe packets on each link of the plurality of ECMP links other than the first link.

In some further instances, the techniques described herein may be performed on a queue level as opposed to a whole link level. For instance, when the first link includes a plurality of queues, traffic engine <NUM> may assign the data flow to the first link by assigning the data flow to a first queue of the plurality of queues of the first link. When initiating the probing process for the data flow, traffic engine <NUM> may send the one or more probe packets it would typically send over the entire link over only the first queue of the first link to determine the one or more QoE metrics for the first queue, as opposed to over every queue in the link.

After the data flow is complete, or otherwise interrupted such that traffic engine <NUM> is no longer receiving the data flow, traffic engine <NUM> may detect that the data flow is no longer being received. To account for potentially momentary lapses in the data packet transmission, in some instances, traffic engine <NUM> may detect that no more data packets are being received in the data flow and wait a threshold amount of time to determine if any additional data packets are received. If additional data packets are received within the threshold amount of time, traffic engine <NUM> may continue the probing process for the data flow on the first link. Otherwise, if no additional data packets are received after the threshold amount of time passes, traffic engine <NUM> may confirm that the data flow is no longer being received.

In response to detecting that the data flow is no longer being received, traffic engine <NUM> may cease the probing process for the data flow on the first link. In some instances, ceasing the probing process for the data flow includes refraining from sending additional synthetic probe packets over the first link, whether those packets be the default packets or the specifically configured data packets, and whether the probe packets are being sent over the link in general or on a particular queue.

Sometime after initiating the probing process for the data flow, other traffic may be received or some other incident may occur causing the one or more QoE metrics for the first link to fail to satisfy service level agreement (SLA) metrics for the application. Once traffic engine <NUM> determines this to be the case, traffic engine <NUM> may send one or more probe packets over a second link of the plurality of links to determine one or more QoE metrics for the second link. Traffic engine <NUM> may send the one or more probe packets over the links one-by-one until a satisfactory link is found, or may, approximately simultaneously, send each of the one or more probe packets over each of the plurality of links that reach the intended destination to determine the QoE metrics for each link at the same time.

Regardless, once traffic engine <NUM> determines that the one or more QoE metrics for the second link satisfy the SLA metrics for the application, traffic engine <NUM> may re-assign the first data flow from the first link to the second link. Traffic engine <NUM> may then cease the probing process for the data flow on the first link and continue the probing process for the data flow on the second link.

Traffic engine <NUM> may handle additional data flows in a similar manner, ensuring that the probing process is only occurring over the links that are currently experiencing traffic. For instance, traffic engine <NUM> may receive a second application data packet of a second data flow for a second application while the first data flow is still being transmitted over the first link. In response to receiving the second application data packet, traffic engine <NUM> may assign the second data flow to a second link of a plurality of links, the second link being different than the first link. Traffic engine <NUM> may then initiate a probing process for the second data flow on the second link to determine one or more QoE metrics for the second link. At this point, traffic engine <NUM> would be probing only two links of the plurality of links as opposed to every link of the plurality of links. In a similar way as for the traffic received for the first link, traffic engine <NUM> may detect that the second data flow is no longer being received by the network device. In response to detecting that the second data flow is no longer being received, traffic engine <NUM> may cease the probing process for the second data flow on the second link.

An optional addition to the techniques described herein may be to run the pre-configured synthetic probes that suit the application type. In some basic examples, traffic engine <NUM> may run all of the pre-configured synthetic probes upon traffic flows being transmitted over a particular link.

In some other instances, traffic engine <NUM> may perform the on-demand probing techniques at the overlay path level, providing even more granularity to the system. The techniques described herein may help in scaling up the nodes in the mesh network. In SD-WAN environments, these probes go on overlays which may be MPLS, GRE, IPSEC, or combined MPLS/GRE/IPSEC based.

Traffic engine <NUM> may continue this process cyclically, initiating probing processes for applications as they are received and assigned to particular links, and ceasing to probe links that are no longer receiving application traffic. In this way, traffic engine <NUM> may be more scalable, enabling such networks to include more potential links and more client devices without correspondingly increasing the overhead caused by the probing processes. For systems having the same amount of links and client devices, traffic engine <NUM> consume fewer computing resources over the SD-WAN than previous systems, such as bandwidth, memory, and battery power. This may increase efficiency the efficiency of the SD-WAN systems in general, as traffic engine <NUM> may consume less bandwidth and decrease the processing time for generating QoE metrics. Overall, the techniques describe herein may decrease the load on traffic engine <NUM> by decreasing the processing of service level agreement (SLA) results, logs, etc..

<FIG> is a flow diagram illustrating an example technique for a software-define wide area network system that performs on-demand active synthetic probing functions, in accordance with the techniques of this disclosure. The example operation may be performed by traffic engine <NUM> executed on SD-WAN appliance <NUM> from <FIG>. The following are steps of the process, although other examples of the process performed in the techniques of this disclosure may include additional steps or may not include some of the below-listed steps.

In accordance with the techniques described herein, SD-WAN appliance <NUM> may not initially be performing a probing process on a first link of a plurality of links. Sometime later, traffic engine <NUM> may receive an application data packet of a data flow for an application (<NUM>). In response to receiving the application data packet, traffic engine <NUM> may assign the data flow to the first link (<NUM>) and initiate the probing process for the data flow on the first link to determine one or more QoE metrics for the first link (<NUM>). After the data flow is complete, or otherwise interrupted such that SD-WAN appliance <NUM> is no longer receiving the data flow, traffic engine <NUM> may detect that the data flow is no longer being received (<NUM>). In response to detecting that the data flow is no longer being received, traffic engine <NUM> may cease the probing process for the data flow on the first link (<NUM>).

The probing process described herein may include either sending a group of pre-configured probe packets over the link regardless of the type of traffic received. In other instance, the probing process described herein may include only transmitting a singular probe packet or a smaller group of two or more probe packets that are designed specifically to gather QoE metrics that would be applicable to the application transmitting the data flow, based on variables such as the packet sizes in the data flow, burst presence or size within the data flow, packet sizes of the probe packets, and burstiness of the probe packets. A burst flow, measured by burstiness, involves data packets sent intermittently in bursts rather than as a continuous stream.

If implemented in hardware, this disclosure may be directed to an apparatus such as a processor or an integrated circuit device, such as an integrated circuit chip or chipset. Alternatively or additionally, if implemented in software or firmware, the techniques may be realized at least in part by a computer-readable data storage medium comprising instructions that, when executed, cause a processor to perform one or more of the methods described above. For example, the computer-readable data storage medium may store such instructions for execution by a processor.

A computer-readable medium may form part of a computer program product, which may include packaging materials. A computer-readable medium may comprise a computer data storage medium such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), Flash memory, magnetic or optical data storage media, and the like. In some examples, an article of manufacture may comprise one or more computer-readable storage media.

In some examples, the computer-readable storage media may comprise non-transitory media. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in RAM or cache).

In other examples, the computer-readable medium may be a transitory medium such as a carrier signal or transmission media.

The code or instructions may be software and/or firmware executed by processing circuitry including one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. In addition, in some aspects, functionality described in this disclosure may be provided within software modules or hardware modules.

Various examples have been described. These and other examples are within the scope of the appended claims.

Claim 1:
A method comprising:
in response to receiving (<NUM>), by a software-defined wide area network, SD-WAN, network device, an application data packet of a data flow for an application, assigning (<NUM>), by the network device, the data flow to a default link of a plurality of links, wherein the plurality of links comprise a plurality of equal-cost multi-path, ECMP, links;
in response to receiving the application data packet of the data flow, initiating (<NUM>), by the network device, a probing process for the data flow, wherein initiating the probing process for the data flow comprises:
in response to receiving, by the network device, the application data packet of the data flow for the application, determining, by the network device, an application signature of the application data packet;
determining, by the network device and based on the application signature, a set of one or more service level agreement, SLA, metrics for the application and a destination of the data flow;
sending, by the network device, one or more probe packets on each of the plurality of links to determine respective QoE metrics for each ECMP link of the plurality of ECMP links;
determining, by the network device and based on the respective QoE metrics for each link of the plurality of ECMP links, that the QoE metrics for a first link of the plurality of ECMP links satisfy the SLA metrics for the application;
re-assigning, by the network device, the data flow from the default link to the first link; and
refraining, by the network device, from sending additional probe packets on each ECMP link of the plurality of ECMP links other than the first link;
detecting (<NUM>), by the network device, that the data flow is no longer being received by the network device; and
in response to detecting that the data flow is no longer being received by the network device, ceasing (<NUM>), by the network device, the probing process for the data flow on the first link.