Enhanced Bidirectional Active Measurement Protocol

Abstract

Embodiments of the present disclosure relate to an enhanced two-way active measurement protocol. Techniques for an enhanced two-way active measurement protocol (TWAMP) are described for measuring the network performance of links and / or network paths in a fully converged software-defined wide area network (SD-WAN) using a single TWAMP instance. In one example, a first network device that executes a TWAMP session sender may send test packets embedded with one or more metrics to a TWAMP session reflector executed by another network device, and the TWAMP session reflector returns the test packets embedded with one or more metrics to the TWAMP session sender. The TWAMP session sender may further return test packets embedded with one or more additional metrics to the TWAMP session reflector so that the network devices can independently perform network performance calculations using the metrics embedded in the test packets exchanged within a single TWAMP instance.

Description

[0001] This application is a divisional application of the invention patent application with the application date of September 25, 2019, the priority date of May 31, 2019, the Chinese national application number 201910912332.X, and the invention title of "Enhanced Bidirectional Active Measurement Protocol". Technical Field

[0002] This disclosure relates to computer networks. Background Art

[0003] A computer network is a collection of interconnected computing devices that can exchange data and share resources. The One-Way Active Measurement Protocol (OWAMP) can be used to measure the one-way metrics of network performance between two network devices. OWAMP can be used to measure the one-way metrics in both directions between two network devices, but OWAMP is not suitable for bidirectional or round-trip measurements. The Two-Way Active Measurement Protocol (TWAMP) is based on OWAMP and adds the ability to measure the bidirectional or round-trip metrics of network performance between two network devices. For example, TWAMP can be used to measure bidirectional and one-way network performance metrics such as latency, delay (inter-frame gap), jitter, packet loss, throughput, etc. (referred to as "Service Level Agreement (SLA) metrics").

[0004] The TWAMP measurement architecture includes at least two network devices, also referred to as hosts or endpoints, each of which supports TWAMP and performs specific roles to initiate a test session and exchange test packets through the test session. The TWAMP control message passing used to initiate, start, and stop the test session occurs between the TWAMP control client and the TWAMP server. The TWAMP data or test message passing used to exchange test packets to measure network performance occurs between the TWAMP session sender and the TWAMP session reflector. In an example network architecture, the logical roles of the TWAMP control client and the TWAMP session sender can both be performed by the first endpoint, and the logical roles of the TWAMP server and the TWAMP session reflector can both be performed by the second endpoint. In other example architectures, each of the logical roles can be performed on different hosts. Summary of the Invention

[0005] In general, the present disclosure describes techniques for an Enhanced Two-Way Active Measurement Protocol (TWAMP) for measuring network performance of links and / or network paths in a fully converged Software Defined Wide Area Network (SD-WAN) using a single TWAMP instance. The disclosed techniques include extending TWAMP such that network devices of a fully converged SD-WAN that support Enhanced TWAMP can each perform dual roles during a single instance of TWAMP. For example, a first network device may be configured to perform a TWAMP control client and a TWAMP session sender (referred to as a "TWAMP controller" or "TWAMP client"), while a second network device may be configured to perform a TWAMP server and a TWAMP session reflector (referred to as a "TWAMP responder" or "TWAMP server"). The controller-responder pair of network devices can act as responder-controller simultaneously during the same TWAMP instance.

[0006] In one implementation, a first network device that performs a TWAMP session sender may send test packets embedded with one or more metrics to a TWAMP session reflector performed by another network device, and the TWAMP session reflector returns the test packets embedded with one or more metrics to the TWAMP session sender. The TWAMP session sender may further return test packets embedded with one or more additional metrics to the TWAMP session reflector so that network devices can independently perform network performance calculations using the metrics embedded in the test packets exchanged within a single TWAMP instance.

[0007] The disclosed techniques also include extending TWAMP such that network devices can share network performance calculations. For example, in response to receiving a test packet reflected from a TWAMP session reflector, the TWAMP session sender may calculate a network performance measurement and share the calculated network performance measurement with the TWAMP session reflector, such that the network device performing the TWAMP session reflector can obtain the calculated network performance measurement without having to establish a second TWAMP instance to measure network performance. Moreover, the disclosed techniques also include extending TWAMP such that network devices can send incremental calculation times (such as the time from when a network device receives a test packet to when the network device sends a test packet), rather than sending test packets embedded with received timestamps and responder timestamps.

[0008] The described techniques can provide one or more technical advantages that provide at least one practical application. For example, by implementing enhanced TWAMP, network devices of a fully integrated SD-WAN can improve SD-WAN application SLA identification and best link selection. For example, by implementing enhanced TWAMP, network devices can independently perform round-trip network performance calculations during a single instance of TWAMP, which reduces the number of TWAMP instances required to calculate round-trip network performance at each end of the SD-WAN. The reduction in the number of TWAMP instances reduces the number of control session packets and test session packets being exchanged (e.g., by 50%), thus reducing the bandwidth consumption and computational overhead of computing devices that use TWAMP to determine which links and / or network paths meet the SLA requirements for forwarding network traffic. Also, by sending the incremental calculation time (ΔT) instead of the received timestamp and responder timestamp, fewer bytes (e.g., 6 bytes) are required when exchanging test packets, thus reducing the amount of computing resources and processing required to execute a TWAMP instance. Additionally, by selecting network devices with more robust system resources available for executing the TWAMP control client, the performance of enhanced TWAMP can be dynamically offloaded to network devices with more robust system resources. This may be useful, for example, in the case of a computing resource crisis.

[0009] In one example, a method includes: controlling a first network device of a TWAMP control client by executing a Two-Way Active Measurement Protocol (TWAMP) to establish a control connection between the TWAMP control client and a TWAMP server executed on a second network device, where the control connection is used to negotiate a test session between a TWAMP session sender executed on the first network device and a TWAMP session reflector executed on the second network device. The method further includes: sending, by the TWAMP session sender executed on the first network device, one or more TWAMP test packets for the test session to the TWAMP session reflector, where each TWAMP test packet of the one or more TWAMP test packets includes a first metric embedded within the one or more TWAMP test packets. The method further includes: receiving, by the TWAMP session sender executed on the first network device, one or more TWAMP test packets returned from the TWAMP session reflector, where each TWAMP test packet of the one or more TWAMP test packets includes a second metric embedded within the one or more TWAMP test packets. Additionally, the method includes: sending, by the TWAMP session sender executed on the first network device and during the test session, one or more TWAMP test packets back to the TWAMP session reflector to cause the second network device to calculate at least one active round-trip network performance metric for a link between the first network device and the second network device, where each TWAMP test packet of the one or more TWAMP test packets includes a third metric embedded within the one or more TWAMP test packets.

[0010] In another example, a method includes: by a first network device that executes a two-way active measurement protocol (TWAMP) server, a control connection between the TWAMP server and a TWAMP control client that is executed on a second network device is established, where the control connection is used to negotiate a test session between a TWAMP session reflector executed by the first network device and a TWAMP session sender executed by the second network device. The method further includes: by the TWAMP session reflector executed on the first network device, receiving, from the TWAMP session sender, one or more TWAMP test packets for the test session, where each TWAMP test packet among the one or more TWAMP test packets includes a first metric embedded within the one or more TWAMP test packets. The method further includes: by the TWAMP session reflector executed on the first network device, sending the one or more TWAMP test packets back to the TWAMP session sender, where each TWAMP test packet among the one or more TWAMP test packets includes a second metric embedded within the one or more TWAMP test packets. Additionally, the method includes: by the TWAMP session reflector executed on the first network device, and during the test session, receiving one or more TWAMP test packets returned from the TWAMP session sender, where each TWAMP test packet among the one or more TWAMP test packets includes a third metric embedded within the one or more TWAMP test packets. The method further includes: calculating, by the first network device, at least one active round-trip network performance metric for a link between the first network device and the second network device.

[0011] In yet another example, the first network device includes a memory. The first network device includes one or more processors that communicate with the memory and execute a Two-Way Active Measurement Protocol (TWAMP) control client and a TWAMP session sender. The one or more processors are configured to establish a control connection between the TWAMP control client and a TWAMP server executed by a second network device, wherein the control connection is used to negotiate a test session between the TWAMP session sender executed on the first network device and a TWAMP session reflector executed on the second network device. The one or more processors are further configured to: send one or more TWAMP test packets for the test session to the TWAMP session reflector, each of the one or more TWAMP test packets including a first metric embedded within the one or more TWAMP test packets. The one or more processors are further configured to: receive one or more TWAMP test packets returned from the TWAMP session reflector, each of the one or more TWAMP test packets including a second metric embedded within the one or more TWAMP test packets. The one or more processors are further configured to: during the test session, send one or more TWAMP test packets back to the TWAMP session reflector to cause the second network device to calculate at least one active round-trip network performance metric for the link between the first network device and the second network device, each of the one or more TWAMP test packets including a third metric embedded within the one or more TWAMP test packets.

[0012] In yet another example, the first network device includes a memory. The first network device includes one or more processors that communicate with the memory and execute a Two-Way Active Measurement Protocol (TWAMP) server and a TWAMP session reflector. The one or more processors are configured to: establish a control connection between the TWAMP server and a TWAMP control client executed by a second network device, where the control connection is used to negotiate a test session between the TWAMP session reflector executed by the first network device and a TWAMP session initiator executed by the second network device. The one or more processors are further configured to: receive, from the TWAMP session initiator, one or more TWAMP test packets for the test session, each of the one or more TWAMP test packets including a first metric embedded within the one or more TWAMP test packets. The one or more processors are further configured to: send the one or more TWAMP test packets back to the TWAMP session initiator, each of the one or more TWAMP test packets including a second metric embedded within the one or more TWAMP test packets. Moreover, the one or more processors are configured to: during the test session, receive one or more TWAMP test packets returned from the TWAMP session initiator, each of the one or more TWAMP test packets including a third metric embedded within the one or more TWAMP test packets. The one or more processors are further configured to: calculate at least one active round-trip network performance metric for the link between the first network device and the second network device.

[0013] In yet another example, a system includes a first network device that executes a Two-Way Active Measurement Protocol (TWAMP) control client and a TWAMP session sender for a test session. The system also includes a second network device that executes a TWAMP server and a TWAMP session reflector for the test session. The TWAMP session sender is configured to exchange one or more TWAMP test packets for the test session between the TWAMP session sender and the TWAMP session reflector, wherein, to exchange one or more TWAMP test packets for the test session, the TWAMP session sender is configured to: send back to the TWAMP session reflector one or more TWAMP test packets received from the TWAMP session reflector during the test session; and compute at least one active round-trip network performance metric for a link between the first network device and the second network device. The TWAMP session reflector is configured to exchange one or more TWAMP test packets for the test session between the TWAMP session reflector and the TWAMP session sender, wherein, to exchange one or more TWAMP test packets for the test session, the TWAMP session reflector is configured to: receive one or more TWAMP test packets transmitted back from the TWAMP session sender; and compute at least one active round-trip network performance metric for a link between the first network device and the second network device.

[0014] Details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a block diagram illustrating an example network system in accordance with one or more aspects of the techniques described in this disclosure that provides an enhanced Two-Way Active Measurement Protocol (TWAMP) for measuring network performance of links and / or network paths of a fully converged SD-WAN.

[0016] Figure 2 is a block diagram illustrating an example TWAMP architecture in accordance with one or more aspects of the techniques described herein, the example TWAMP architecture including network devices configured to implement enhanced TWAMP to enable network devices to independently measure network performance of a fully converged SD-WAN using test packets exchanged during a single TWAMP instance.

[0017] Figure 3is a flowchart illustrating an example operation of a network device in accordance with one or more aspects of the techniques described herein, the network device being configured to implement enhanced TWAMP such that the network device can independently measure the network performance of a fully converged SD-WAN using test packets exchanged during a single TWAMP session.

[0018] Figure 4 is a block diagram illustrating another example TWAMP architecture in accordance with one or more aspects of the techniques described herein, the another example TWAMP architecture including a network device configured to implement enhanced TWAMP that facilitates sharing round-trip network performance calculations.

[0019] Figure 5 is a flowchart illustrating an example operation of a network device in accordance with one or more aspects of the techniques described herein, the network device being configured to implement enhanced TWAMP that facilitates sharing round-trip network performance calculations.

[0020] Figure 6 is a block diagram illustrating another example TWAMP architecture in accordance with one or more aspects of the techniques described herein, the another example TWAMP architecture including a network device configured to implement enhanced TWAMP that sends incremental calculation times.

[0021] Figure 7 is a flowchart illustrating an example operation of a network device in accordance with one or more aspects of the techniques described herein, the network device being configured to implement enhanced TWAMP that sends incremental calculation times.

[0022] Figure 8 is a block diagram illustrating an example network device in accordance with one or more aspects of the techniques described herein, the example network device being configured to provide enhanced TWAMP to measure the network performance of the links and / or network paths of a fully converged SD-WAN using a single TWAMP session. Detailed Description

[0023] Figure 1 is a block diagram illustrating an example network system in accordance with one or more aspects of the techniques described in this disclosure, the example network system providing enhanced Two-Way Active Measurement Protocol (TWAMP) to measure the network performance of a fully converged SD-WAN. Figure 1An example network system includes a service provider network 2 that operates as a private network to provide packet-based network services to subscriber devices 16. That is, the service provider network 2 provides authentication and establishment of network access for the subscriber devices 16 such that the subscriber devices can begin exchanging data packets with a public network 12, which can be a packet-based internal or external network such as the Internet.

[0024] In Figure 1 the example, the service provider network 2 includes an access network 6 that provides a connection to the public network 12 via a service provider software-defined wide area network 7 (hereinafter referred to as "SD-WAN 7") and a router 8. SD-WAN 7 and the public network 12 provide packet-based services that can be requested and used by the subscriber devices 16. For example, SD-WAN 7 and / or the public network 12 can provide bulk data delivery, Voice over Internet Protocol (VoIP), Internet Protocol Television (IPTV), Short Message Service (SMS), Wireless Application Protocol (WAP) services, or customer-specific application services. The public network 12 can include, for example, a Local Area Network (LAN), a Wide Area Network (WAN), the Internet, a Virtual LAN (VLAN), an enterprise LAN, a Layer 3 Virtual Private Network (VPN), an Internet Protocol (IP) intranet operated by the service provider operating the access network 6, an enterprise IP network, or some combination thereof. In various examples, the public network 12 is connected to a public WAN, the Internet, or other networks. The public network 12 implements one or more Packet Data Protocols (PDPs), such as IP (IPv4 and / or IPv6), X.25, or Point-to-Point Protocol (PPP), to enable packet-based delivery of the public network 12 services.

[0025] Generally, the subscriber device 16 is connected to the gateway router 8 via the access network 6 to receive a connection to a subscriber service for an application hosted by the subscriber device 16. The subscriber can represent, for example, an enterprise, a residential subscriber, or a mobile subscriber. The subscriber device 16 can be, for example, a personal computer, a laptop computer, or other types of computing devices located behind the customer equipment (CE) 11, which can provide local routing and switching functions. Each subscriber device in the subscriber device 16 can run multiple software applications, such as word processing and other office support software, web browsing software, software supporting voice calls, video games, video conferencing, and email, etc. For example, the subscriber device 16 can be a variety of network-enabled devices, commonly referred to as "Internet of Things" (IoT) devices, such as cameras, sensors (S), televisions, facilities, etc. Additionally, the subscriber device 16 can include mobile devices that access data services of the service provider network 2 via the radio access network (RAN) 6. Example mobile subscriber devices include mobile phones, laptops or desktop computers with, for example, 3G wireless cards, netbooks with wireless capabilities, video game devices, pagers, smart phones, personal data assistants (PDAs), etc.

[0026] The network service provider operates or in some cases leases elements of the access network 6 to provide packet transfer between the subscriber device 16 and the router 8. The access network 6 represents a network that aggregates data traffic from one or more subscriber devices 16 for transfer to / from the service provider's SD-WAN 7. The access network 6 includes network nodes that execute communication protocols to transfer control and user data to facilitate communication between the subscriber device 16 and the router 8. The access network 6 can include a broadband access network, a wireless LAN, a public switched telephone network (PSTN), a customer premise equipment (CPE) network, or other types of access networks, and can include or otherwise provide connectivity to a cellular access network (such as a radio access network (RAN) (not shown)). Examples include the following networks: those compliant with the Universal Mobile Telecommunications System (UMTS) architecture, the evolution of UMTS known as Long-Term Evolution (LTE), Mobile IP standardized by the Internet Engineering Task Force (IETF), and other standards proposed by the Third Generation Partnership Project (3GPP), the Third Generation Partnership Project 2 (3GGP / 2), and the WiMAX Forum.

[0027] Router 18 can be a customer edge (CE) router, a provider edge (PE) router, or other network device between access network 6 and SD-WAN 7. SD-WAN 7 provides packet-based connectivity to subscriber devices 16 attached to access network 6 to access a public network 12 (e.g., the Internet). SD-WAN 7 can represent a public network owned and operated by a service provider to interconnect multiple networks, which can include access network 6. SD-WAN 7 can implement Multiprotocol Label Switching (MPLS) forwarding, and in such instances, can be referred to as an MPLS network or an MPLS backbone. In some instances, SD-WAN 7 represents multiple interconnected autonomous systems, such as the Internet, which provides services from one or more service providers. SD-WAN 7 can include different WAN links, such as a WAN link coupling router 18 to an MPLS network, a WAN link coupling router 18 to the Internet, a WAN link coupling router 18 to a Long-Term Evolution (LTE) network, or any other link of any suitable type for transmitting data streams between subscriber services. SD-WAN 7 can include multiple network devices that form a fully meshed (i.e., full-mesh) network. For example, a full-mesh SD-WAN network is a type of deployment where all SD-WAN-aware nodes are directly interconnected with each other in the Internet / intranet via multiple links or are interconnected with each other using overlays. That is, in a full-mesh network, each of the multiple network devices is connected to each other. Because each of the multiple network devices of SD-WAN 7 is connected to each other, the path from router 18 to router 8 is the same as the path from router 8 to router 18.

[0028] Public network 12 can represent the Internet. Public network 12 can represent an edge network coupled to SD-WAN 7 via a transport network 22 and one or more network devices (e.g., customer edge devices such as customer edge switches or routers). Public network 12 can include data centers. Router 8 can exchange packets with service node 10 via virtual network 20, and router 8 can forward packets to public network 12 via transport network 22.

[0029] In an example of network 2 that includes a wired / broadband access network, router 8 may represent a broadband network gateway (BNG), a broadband remote access server (BRAS), an MPLS PE router, a core router or gateway, or a cable modem termination system (CMTS). In an example of network 2 that includes a cellular access network as access network 6, router 8 may represent a mobile gateway, e.g., 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 8 may be implemented in a switch, a service card, or another network element or component. In some examples, router 8 itself may be a service node.

[0030] A network service provider that manages at least part of network 2 typically provides services to subscribers associated with devices (e.g., subscriber device 16) that access service provider network 2. The services provided may include, for example, traditional Internet access, VoIP, video and multimedia services, and security services. As described above with respect to access network 6, SD-WAN 7 may support multiple types of access network infrastructure that connect to a service provider network access gateway to provide access to the services provided. In some instances, the network system may include subscriber device 16 attached to multiple different access networks 6 having different architectures.

[0031] Generally, any one or more of subscriber devices 16 may request authorization and data services by sending a session request to a gateway device such as router 18 or router 8. In turn, router 18 may access a central server (not shown), such as an authentication, authorization, and accounting (AAA) server, to authenticate one of subscriber devices 16 that requests network access. Once authenticated, any one of subscriber devices 16 may send subscriber data traffic to SD-WAN 7 to access and receive services provided by public network 12, and such packets may traverse router 8 as part of at least one packet flow. In some examples, router 18 may forward all authenticated subscriber traffic to public network 12, and if subscriber traffic requires services on service node 10, router 8 may apply service 15 and / or direct specific subscriber traffic to data center 9. Applications (e.g., service applications) to be applied to subscriber traffic may be hosted on service node 10.

[0032] As described herein, service provider network 2 includes a data center 9 having a cluster of service nodes 10 that provides an execution environment for most virtualized network services. In some examples, each service node in service nodes 10 represents a service instance. Each service node in service nodes 10 can apply one or more services. As an example, service nodes 10 can 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 of packet flows, counting, statistics, billing, and / or load balancing, or other types of services applied to network traffic.

[0033] Although illustrated as part of data center 9, service nodes 10 can be network devices coupled by one or more switches or virtual switches of SD-WAN 7. In one example, each service node in service nodes 10 can run as a VM in a virtual computing environment. Moreover, the computing environment can include a scalable cluster of general-purpose computing devices (such as x86 processor-based servers). As another example, service nodes 10 can include a combination of general-purpose computing devices and specialized facilities. As virtualized network services, the individual network services provided by service nodes 10 can be horizontally scaled by allocation of virtualized memory, processor utilization, storage, and network policies, and by adding additional load balancing VMs, just as in modern data centers. In other examples, service nodes 10 can be gateway devices or other routers. In other examples, the functions described for each service node in service nodes 10 can be implemented in switches, service cards, or other network elements or components.

[0034] Router 8 can direct subscriber packet flows through a defined set of services provided by service nodes 10. That is, in some examples, each subscriber packet flow can be forwarded through a specific ordered combination provided by service nodes 10, and each ordered set is referred to herein as a "service chain". In Figure 1 the example, subscriber packet flows can be directed along a service chain that includes any of the service nodes in service nodes 10. A particular service node 10 can support multiple service chains. Once processing has been performed at the terminal node of the service chain (i.e., the last service node 10) to apply the service to the packets flowing along a particular service path, the terminal node can direct the traffic back to router 8 for further processing and / or forwarding to public network 12. For example, a traffic engineering service path can start and end with router 8.

[0035] In Figure 1In the example, service provider network 2 includes a software-defined network (SDN) and a network function virtualization (NFV) architecture. The SDN controller device 14 can provide an advanced controller for configuring and managing the routing and switching infrastructure of service provider network 2. The NVV coordinator device 13 can provide an advanced coordinator for configuring and managing the virtualization of network services in service nodes 10 entering data center 9. In some instances, the SDN controller 14 manages the deployment of virtual machines (VMs) within the operating environment of data center 9. For example, the SDN controller 14 can interact with a provider edge (PE) router 8 to specify service chain information. For example, the service chain information provided by the SDN controller 14 can specify any combination and ordering of services provided by service nodes 10, traffic engineering information for tunneling or otherwise transporting packet flows along the service path, rate limiting, type of service (TOS) marking, or a packet classifier specifying criteria for matching a packet flow to a particular service chain. Further example details of the SDN controller are described in PCT International Patent Application PCT / US13 / 44378, filed on June 5, 2013, the entire content of which is incorporated herein by reference.

[0036] In some examples, service nodes 10 can implement a service chain using an internally configured forwarding state that guides packets of a packet flow along the service chain for processing according to an identified set of service nodes 10. Such a forwarding state can specify tunnel interfaces for tunneling between service nodes 10 using network tunnels such as IP or Generic Routing Encapsulation (GRE) tunnels, Network Virtualization using GRE (NVGRE), or by using VLANs, Virtual Extensible LAN (VXLAN), MPLS technology, etc. In some instances, physical or virtual switches, routers, or other network elements interconnecting service nodes 10 can be configured to direct a packet flow to service nodes 10 according to the service chain.

[0037] Users can expect applications and services with an acceptable level of quality (commonly referred to as quality of experience (QoE)) to be provided by a service provider. QoE can be measured based on various metrics, including latency, delay (inter-frame gap), jitter, packet loss, throughput, etc. A user can define an expected level for one or more of the metrics of QoE in a service contract (e.g., service level agreement (SLA)) with the service provider.

[0038] Service provider network 2 provides the Two-Way Active Measurement Protocol (TWAMP) to measure one-way and two-way or round-trip metrics of network performance between network devices (also referred to as hosts or endpoints), such as SLA metrics. Network devices can use TWAMP to perform application SLA identification and / or best link selection. That is, network devices can use TWAMP to determine the network performance of the link between network devices and / or the application traffic on the network path, and / or select the link and / or network path that best meets the SLA parameters to forward network traffic from the application. Generally, the TWAMP measurement architecture includes at least two network devices, each of which supports TWAMP and performs a specific role to exchange control session packets (or simply "control packets") to establish and start a TWAMP test session and exchange test session packets (or simply "test packets") for the TWAMP test session. In Figure 1 the example, TWAMP can be used to measure the network performance (e.g., WAN link performance) between router 18 and router 8. In this example, router 18 can be configured to perform the TWAMP control client and the TWAMP session sender (referred to as the "TWAMP session controller" or "TWAMP client"), while router 8 can be configured to perform the TWAMP server and the TWAMP session reflector (referred to as the "TWAMP responder" or "TWAMP server"). In an alternative TWAMP architecture, each of the logical roles can be performed on different hosts or endpoints.

[0039] The TWAMP control client executed on router 18 and the TWAMP server executed on router 8 establish a control connection and exchange TWAMP control packets to initiate, start, and stop the TWAMP test session 24. Once the TWAMP test session 24 is established, the TWAMP session sender executed on router 18 and the TWAMP session reflector executed on router 8 exchange TWAMP test packets for test session 24, which carry one or more metrics for measuring the network performance between router 18 and router 8. Although in Figure 1 the example only one test session 24 is illustrated, in other examples, multiple test sessions can be established between two TWAMP-enabled endpoints. In some examples, each of the multiple test sessions can be associated with different network performance metrics.

[0040] In some examples, the metrics carried by TWAMP test packets can include one or more of the following: timestamps for sending or receiving test packets, error estimates for sending or receiving test packets, keepalive packet data units (PDUs), and / or counts of packets, bytes, or subscribers. One-way and two-way network performance measurements can include keepalive or path connectivity, round-trip time (RTT), path delay, packet jitter, packet reordering, packet loss, latency measurements, or load measurements based on received metrics. Other examples of TWAMP are described in more detail in “A Two-Way Active Measurement Protocol (TWAMP)”, by Hedayat et al., “Internet Engineering Task Force (IETF), Network Working Group, Request for Comments 5357”, October 2008, the entire content of which is incorporated herein by reference.

[0041] In some instances, multiple TWAMP instances are implemented to measure the round-trip network performance at two endpoints. For example, to measure the network performance at a first network device, the first network device may be configured in a first TWAMP instance to perform a TWAMP controller (e.g., a TWAMP control client and a TWAMP session sender), while a second network device may be configured to perform a TWAMP responder (e.g., a TWAMP server and a TWAMP session reflector). The first network device may measure the network performance based on metrics carried by TWAMP test packets exchanged in the first TWAMP instance. To measure the performance at the second network device, the second network device may be configured in a second TWAMP instance to perform a TWAMP controller, while the first network device is configured to perform a TWAMP responder. If the network devices are in a fully meshed network, the path from the first network device to the second network device is the same as the path from the second network device to the first network device. In such a case, the implementation of multiple TWAMP instances to measure the network performance at each of the network devices wastes bandwidth and computing resources. For example, to measure the network performance of each TWAMP instance in a TWAMP instance, each TWAMP instance in the TWAMP instance requires the exchange of TWAMP control packets and TWAMP test packets. For an SD-WAN full mesh network with "N" nodes, each node having "X" applications, and "Y" links between each of the nodes at one end, this results in X*(N - 1)*Y test packets being run at each SD-WAN node in the full mesh network. For example, each TWAMP instance may exchange 12 control packets and 2 test packets. In such an example, 14 packets are exchanged for each TWAMP instance.

[0042] According to the techniques described herein, the service provider network 2 may provide enhanced TWAMP to measure the network performance of the fully meshed SD-WAN 7 using test packets exchanged during a single TWAMP instance. In Figure 1 the illustrated example, the network devices (e.g., routers 8 and 18) of the fully meshed SD-WAN 7 may support enhanced TWAMP as described herein and may run a single instance of a TWAMP control and test session to measure the network performance of the links and / or network paths of the SD-WAN 7.

[0043] As an example, routers 8 and 18 that support enhanced TWAMP can each perform dual roles as a TWAMP controller and a TWAMP responder. For example, routers 8 and 18 can act as a controller-responder pair respectively, and can also act as a responder-controller pair simultaneously. Routers 8 and 18 can select a primary device to execute the TWAMP control client, and one or more non-selected devices operate as auxiliary devices that execute the TWAMP server. As further described herein, one of routers 8 and 18 is selected to execute the primary TWAMP control client based on a network device with more robust system resource usage (e.g., hardware capabilities) or load. In Figure 1 the example, the logical role of the TWAMP control client is executed by router 18, while the logical role of the TWAMP server is executed by router 8. As further described herein, router 18 can execute the TWAMP control client to establish, start, and stop a TWAMP test session. For example, the TWAMP control client executed by router 18 can establish a control connection with the TWAMP server executed by router 8. The TWAMP control client and the TWAMP server exchange control packets through the control connection to negotiate the TWAMP test session 24.

[0044] Router 18 can also execute the TWAMP session sender, while router 8 can execute the TWAMP session reflector for the TWAMP test session 24. In this example, router 18 can operate as a TWAMP controller, while router 8 can operate as a TWAMP responder. When the TWAMP test session 24 is established, the TWAMP session sender executed by router 18 can generate test packets and send them to the TWAMP session reflector executed by router 8, which returns the test packets to the TWAMP session sender executed by router 18. When test packets are exchanged between the TWAMP session sender and the TWAMP session reflector, the TWAMP session sender and the TWAMP session reflector can be embedded with corresponding metrics (e.g., timestamps) to indicate transmission time, reception time, and / or responder time.

[0045] As Figure 2 and Figure 3As further described in [reference], router 18 can further return the test packet to the TWAMP session reflector executed by router 8 in response to receiving the test packet reflected from the TWAMP session reflector. That is, router 18 can also execute the TWAMP responder, while router 8 can also execute the TWAMP controller at different times during the test packet exchange in the same TWAMP instance. By further returning the test packet to the TWAMP session reflector executed by router 8, each of routers 8 and 18 can use the metrics embedded in the test packets exchanged during a single TWAMP instance to independently calculate network performance measurements of the application traffic on the links and / or network paths of SD-WAN 7, such as round-trip latency time (RTT), jitter, etc., which are used to determine whether to forward traffic on the link and / or network path or select a different link and / or network path to forward traffic.

[0046] Additionally or alternatively, in some examples, routers 8 and 18 can share the round-trip network performance calculation. As Figure 4 and Figure 5 further described in [reference], the TWAMP session sender executed by router 18 can calculate network performance measurements based on the metrics embedded in the exchanged test packets in response to receiving the test packet reflected from the TWAMP session reflector executed by router 8, and share the calculated network performance measurements to the TWAMP session reflector executed by router 8. In this way, router 8 can obtain the calculated network performance measurements without having to establish a second TWAMP instance to measure network performance.

[0047] Additionally or alternatively, in some examples, routers 8 and 18 can send the incremental calculation time (ΔT) (alternatively referred to herein as "processing time"), which indicates the time from when the test packet is received by the router to when the router sends the test packet. As Figure 6 and Figure 7As further described in, the TWAMP session reflector executed by router 8 can receive test packets from the TWAMP session sender executed by router 18. The TWAMP session reflector can calculate and send a first incremental calculation time (ΔT1), rather than embedding test packets with a receive timestamp and a responder timestamp. Similarly, the TWAMP session sender executed by router 18 can receive test packets, calculate, and send a second incremental calculation time (ΔT2), rather than the received timestamp and the responder timestamp. In this way, routers 8 and 18 can exchange test packets with incremental calculation times using fewer bytes (e.g., 6 bytes), rather than exchanging larger test packets embedded with both the received timestamp and the responder timestamp. The incremental calculation time spent on processing TWAMP test packets can avoid any time synchronization issues between nodes (e.g., which can occur by using the Network Time Protocol (NTP) or the Precision Time Protocol (PTP)).

[0048] The described techniques can provide one or more technical advantages, which provide at least one practical application. For example, by implementing enhanced TWAMP, network devices of a fully converged SD-WAN can improve SD-WAN application SLA identification and best link selection. For example, by implementing enhanced TWAMP, network devices can independently perform round-trip network performance calculations during a single instance of TWAMP, which reduces the number of TWAMP instances required to calculate round-trip network performance at each end of the SD-WAN. The reduction in the number of TWAMP instances reduces the number of control session packets and test session packets exchanged (e.g., by 50%), thus reducing the bandwidth consumption and computational overhead of computing devices that use TWAMP to determine which links and / or network paths meet the SLA requirements for forwarding network traffic. Moreover, by sending the incremental calculation time (ΔT) rather than the received timestamp and the responder timestamp, fewer bytes (e.g., 6 bytes) are required when exchanging test packets, thus reducing the amount of computing resources and processing required to execute TWAMP instances. Additionally, by selecting network devices with more robust system resources available for executing the TWAMP control client, the performance of enhanced TWAMP can be dynamically offloaded to network devices with more robust system resources. For example, this may be useful in the case of a computing resource crisis.

[0049] Figure 2FIG. 0 is a block diagram of an example TWAMP architecture 200 that illustrates one or more aspects of the techniques described herein. The example TWAMP architecture 200 includes a network device configured to implement enhanced TWAMP such that the network device can independently measure the network performance of a fully converged SD-WAN using test packets exchanged during a single instance of TWAMP. In this example, the TWAMP architecture 200 includes a first network device 228 and a second network device 230. The first network device 228 may represent Figure 1 router 18, and the second network device 230 may represent Figure 1 router 8. Alternatively, the first network device 228 and the second network device 230 may represent any network device of a fully converged SD-WAN that supports enhanced TWAMP.

[0050] In Figure 2 the example, the first network device 228 and the second network device 230 may select which network device is to execute the primary TWAMP control client. In some instances, the network device with more robust system resources and / or the least load is selected to execute the primary TWAMP control client. For example, the first network device 228 and the second network device 230 may exchange control messages including current system resource usage (such as CPU, memory, etc.) and / or current load (e.g., the number of currently active control clients running between network devices). In some instances, the control message may also include a flag to indicate that the network device is interested in executing the primary TWAMP control client without comparing to the system resource usage of a remote network device.

[0051] As an example, the first network device 228 initiates a control connection and shares its system resource usage (e.g., 80% CPU, 100 active control connections, interest-flag = Yes). In the case where the second network device 230 receives the system resource usage of the first network device 228 before the second network device 230 initiates a control connection, the second network device 230 may compare the system resource usage of the first network device 228 with its own system resource usage. If the system resource usage of the second network device 230 is more robust (e.g., higher CPU capacity and / or less load), the second network device 230 sends a TCP reset (RST) to the first network device 228 to reset the control connection initiated by the first network device 228. In response, the second network device 230 executes the primary TWAMP control client and initiates a control connection 242.

[0052] As another example, both the first network device 228 and the second network device 230 can initiate a control connection in parallel. In this example, the first network device 228 initiates a control connection and shares its system resource usage (e.g., 70% CPU, 50 active control connections, interest - flag = Yes), and the second network device 230 initiates a control connection in parallel and shares its system resource usage (e.g., 80% CPU, 100 active control connections, interest - flag = Yes). If the first network device 228 receives the system resource usage of the second network device 230 before receiving the system resource usage of the first network device 228, the first network device 228 can compare the system resource usage of the network devices and determine that the first network device 228 has a lower load (e.g., fewer active control connections). In response, the first network device 228 sends a TCP reset to the second network device 230 to reset the control connection initiated by the second network device 230. Then, the first network device 228 executes the main TWAMP control client and initiates a control connection 242. Although the selection of the network device to execute the main TWAMP control client can be based on the network device with more robust system resource usage, the selection of the network device to execute the TWAMP control client can be user - configured.

[0053] The primary selection process can occur periodically. For example, network devices can periodically exchange system resource usage and / or load information. In this way, the performance of the enhanced TWAMP can be dynamically offloaded to the network device with more robust system resources.

[0054] In Figure 2 the example, the first network device 228 is configured to execute the TWAMP controller, i.e., both the TWAMP control client 232 and the TWAMP session sender 234. The second network device 230 is configured to execute the TWAMP responder, i.e., both the TWAMP server 238 and the TWAMP session reflector 240. As further described below, the first network device 228 can also execute the TWAMP responder, while the second network device 230 can also execute the TWAMP controller at different time points during the TWAMP instance.

[0055] The TWAMP control client 232 and the TWAMP server 238 can establish a control connection 242. The control connection 242 can include a Transmission Control Protocol (TCP) connection such that the control packets transmitted over the control connection 242 include TCP packets. The TWAMP control client 232 and the TWAMP server 238 exchange control packets over the control connection 242 to negotiate (e.g., establish, start, and stop) a test session 250 between the TWAMP session sender 234 and the TWAMP session reflector 240.

[0056] The TWAMP control client 232 and the TWAMP session sender 234 can be connected via a communication link 246. In the illustrated example, where the TWAMP control client 232 and the TWAMP session sender 234 are executed on the same host (e.g., the first network device 228), the communication link 246 can include an internal communication link such as a memory or a bus. In other examples, where the TWAMP control client 232 and the TWAMP session sender 234 are executed on different hosts, the communication link 246 can include an external communication link. Similarly, the TWAMP server 238 and the TWAMP session reflector 240 can be connected via a communication link 248. In some examples, different TWAMP logical roles or entities can communicate over either of the communication links 246, 248 using an Extensible Messaging and Presence Protocol (XMPP) interface or any other communication protocol.

[0057] Once the TWAMP control client 232 starts a test session 250, the TWAMP session sender 234 and the TWAMP session reflector 240 can perform a three-way handshake process to exchange test packets including metrics used to measure network performance. For example, the TWAMP session sender 234 sends a test packet 252A including a transmission timestamp (T1) via the test session 250. The TWAMP session reflector 240 receives the test packet 252A via the test session 250 and marks the test packet with the received timestamp (T2). The TWAMP session reflector 240 can mark the test packet with a responder timestamp (T3) and send the test packet (illustrated as test packet 252B) via the test session 250. The TWAMP session sender 234 receives the test packet 252B via the test session 250 and marks the test packet with the received timestamp (T4). In accordance with one or more aspects of the techniques described herein, the first network device 228 can also perform the TWAMP responder, while the second network device 230 can perform the TWAMP controller (e.g., the TWAMP session sender) at different times during the same TWAMP instance. For example, the TWAMP session reflector 234 executed by the first network device 228 marks the test packet with a responder timestamp (T5) and sends the test packet (illustrated as test packet 252C) via the test session 250. The TWAMP session sender 240 executed by the second network device 240 receives the test packet 252C via the test session 250 and marks the test packet with the received timestamp (T6).

[0058] The TWAMP control client 232 and the TWAMP server 238 (or some other module executed by a network device) can each use the received metrics (e.g., timestamps) to calculate network performance measurements between the first network device 228 and the second network device 230. For example, the TWAMP control client 232 and the TWAMP server 238 can respectively extract the timestamps (e.g., T1 - T6) embedded within the test packets exchanged during a single TWAMP instance and independently calculate the round-trip performance.

[0059] For example, the TWAMP control client 232 can calculate the round-trip time (RTT) based on the time from when the test packet 252A is transmitted from the first network device 238 to when the first network device 228 receives the response test packet 252B, excluding the processing time of the second network device 230 (e.g., the time from when the second network device 230 receives the test packet 252A to when the second network device 230 sends the response test packet 252B), as follows:

[0060] RTT = (T4 – T1) – (T3 – T2)

[0061] The TWAMP server 238 can also calculate the RTT based on the time from when the test packet 252B is transmitted from the second network device 230 to when the response test packet 252C is received by the second network device 230, excluding the processing time of the first network device 228 (e.g., the time from when the test packet 252B is received by the first network device 228 to when the response test packet 252C is sent by the first network device 228), as follows:

[0062] RTT = (T6 – T3) – (T5 – T4)

[0063] The TWAMP control client 232 can additionally or alternatively use the T1, T2, T3, and T4 timestamps between consecutive packets to calculate the jitter. For example, the jitter is measured as the difference between two consecutive round-trip times (RTT). For example, the TWAMP control client 232 derives a first RTT (RTT1) calculated from a first set of test packets, a second RTT (RTT2) calculated from a second set of test packets, a third RTT (RTT3) calculated from a third set of test packets, and so on (e.g., the RTT calculated from the Nth set of test packets N ). The TWAMP control client can derive the RTT by sending a set of test packets between the TWAMP session sender and the TWAMP session reflector, and vice versa. The first jitter (JITTER1) can be calculated based on the difference between RTT2 and RTT1, the second jitter (JITTER2) is calculated based on the difference between RTT3 and RTT2, and so on (JITTERN = RTTN - RTTN-1). Similarly, the TWAMP server 238 can additionally or alternatively use the T3, T4, T5, and T6 timestamps between consecutive packets to calculate the jitter.

[0064] Figure 3 is a flowchart illustrating an example operation of a network device according to one or more aspects of the techniques described herein, the network device being configured to implement enhanced TWAMP so that the network device can use test packets exchanged during a single TWAMP instance to independently measure the network performance of a fully converged SD-WAN. Regarding the enhanced TWAMP pair Figure 2 implemented by the first network device and the second network device described in Figure 3 is described.

[0065] In Figure 3In the example, the TWAMP session sender 234 executed by the first network device 238 sends a test packet 252A (302) including a transmission timestamp (T1) through the test session 250. The TWAMP session reflector 240 executed by the second network device 230 receives the test packet 252A through the test session 250 and marks the test packet with the received timestamp (T2) (304). The TWAMP session reflector 240 may mark the test packet with a responder timestamp (T3) and send the test packet through the test session 250 (illustrated as test packet 252B) (306). The TWAMP session sender 234 receives the test packet 252B through the test session 250 and marks the test packet with the received timestamp (T4) (308).

[0066] The TWAMP session reflector 234 executed by the first network device 228 marks the test packet with a responder timestamp (T5) and sends the test packet through the test session 250 (illustrated as test packet 252C) (310). The TWAMP session sender 240 executed by the second network device 230 receives the test packet 252C through the test session 250 and marks the test packet with the received timestamp (T6) (312).

[0067] The first network device 228 may calculate network performance measurements using the metrics included in the test packet (314). For example, the first network device 228 may extract timestamps T1 - T4 to calculate the RTT and / or jitter. Similarly, the second network device 230 may calculate network performance measurements using the metrics included in the test packet (316). For example, the second network device 230 may extract timestamps T3 - T6 to calculate the RTT and / or jitter.

[0068] Figure 4 is a block diagram illustrating an example TWAMP architecture 400 according to one or more aspects of the techniques described herein. The example TWAMP architecture 400 includes network devices configured to implement an enhanced TWAMP that facilitates sharing of round - trip network performance calculations. In this example, similar to Figure 2 the first network device 228 and the second network device 230 of Figure 4 the first network device 428 and the second network device 430 may select a primary TWAMP control client but operate the test session in a different manner as described below.

[0069] Once the primary TWAMP control client selection is complete (e.g., in this example, the first network device 428 is selected), the TWAMP session sender 434 executed by the first network device 428 sends a test packet 452A for the test session 450, which includes a transmission timestamp (T1). The TWAMP session reflector 440 executed by the second network device 430 receives the test packet 452A via the test session 450 and marks the test packet with the received timestamp (T2). The TWAMP session reflector 440 marks the test packet with a responder timestamp (T3) and sends the test packet (illustrated as test packet 452B) via the test session 450. The TWAMP session sender / reflector 434 may receive the test packet 452B via the test session 450 and mark the test packet with the received timestamp (T4).

[0070] The first network device 428 calculates the round-trip performance (e.g., RTT or jitter) as described above using the timestamps T1 - T4. In this example, the TWAMP session sender 4,34 sends a test packet 452D with the round-trip network performance calculation to the TWAMP session reflector 440. The TWAMP session reflector 440 receives the test packet 452D via the test session 450 and can obtain the calculated network performance measurement computed by the TWAMP control client 432 without having to establish a second TWAMP instance to measure the network performance (measure the round-trip performance).

[0071] Figure 5 is a flowchart illustrating an example operation of a network device in accordance with one or more aspects of the techniques described herein, the network device being configured to implement an enhanced TWAMP that facilitates sharing of round-trip network performance calculations. Regarding the enhanced TWAMP implemented by Figure 4 the first network device and the second network device described in Figure 5 is described.

[0072] In Figure 5In the example, the TWAMP session sender 434 executed by the first network device 438 sends a test packet 452A (502) including a transmission timestamp (T1) through the test session 450. The TWAMP session reflector 440 executed by the second network device 430 receives the test packet 452A through the test session 450 and marks the test packet with the received timestamp (T2) (504). The TWAMP session reflector 440 may mark the test packet with a responder timestamp (T3) and send the test packet (illustrated as test packet 452B) through the test session 450 (506). The TWAMP session sender 434 receives the test packet 452B through the test session 450 and marks the test packet with the received timestamp (T4) (508).

[0073] The first network device 428 may calculate a network performance measurement using the metrics included in the test packet (510). For example, the first network device 428 may extract the timestamps T1 - T4 to calculate the RTT and / or jitter. The TWAMP session sender 434 executed by the first network device 428 sends a test packet including the network performance calculation to the TWAMP session reflector 440 through the test session 450 (512). The TWAMP session reflector receives the test packet including the network performance calculation through the test session 450 (514) and stores the network performance calculation (516).

[0074] Figure 6 is a block diagram illustrating an example TWAMP architecture 600 according to one or more aspects of the techniques described herein, the example TWAMP architecture 600 including network devices configured to implement an enhanced TWAMP that sends incremental calculation times. In this example, similar to the first network device 228 and the second network device 230 of Figure 2 Figure 6 the first network device 628 and the second network device 630 of

[0075] ​Once the primary TWAMP control client selection is complete (e.g., in this example, the first network device 628 is selected), the TWAMP session sender 634 can send a test packet 652A including a transmission timestamp (T1) via the test session 650. The session reflector 640 can receive the test packet 652A and calculate an incremental calculation time (ΔT1), which is the time from when the test packet is received by the TWAMP session reflector 640 to the time when the TWAMP session reflector 640 sends the test packet back to the TWAMP session sender 634. For example, the TWAMP session reflector 640 can calculate the difference between the time when the TWAMP session reflector 640 sends the test packet back to the TWAMP session sender 634 (response time) and the time when the TWAMP session reflector 640 receives the test packet 652A. Instead of sending a test packet with the received timestamp and the responder timestamp, the TWAMP session reflector 640 can send a test packet 652B including the incremental calculation time (ΔT1), and can mark the test packet 652B with the transmission timestamp (T2) (to calculate the two-way metric for the second network device 630). The TWAMP session sender 634 receives the test packet 652B via the test session 650 and marks the test packet 652B with the received timestamp (T3). The TWAMP session sender 634 can calculate the incremental calculation time (ΔT2) spent on receiving the test packet and sending it back to the TWAMP session reflector 640. Instead of sending a test packet with the received timestamp and the responder timestamp, the TWAMP session sender 634 can send a test packet 652E including the incremental calculation time (ΔT2) via the test session 650. The TWAMP session reflector 640 receives the test packet 652E via the test session 650 and marks the test packet with the received timestamp (T4).

[0076] The TWAMP control client 632 and the TWAMP server 638 (or some other module executed by the network device) can use the received metrics to calculate the network performance measurement between the first network device 628 and the second network device 630. For example, the TWAMP control client 632 and the TWAMP server 638 can respectively extract the timestamps (e.g., T1 - T4, ΔT1, ΔT2) embedded in the test packets during the round trip, thus allowing the first network device 628 and the second network device 630 to perform the round-trip performance calculation within a single TWAMP instance.

[0077] For example, the TWAMP control client 632 can calculate the RTT based on the time from when the test packet 652A is sent by the first network device 628 to when the response test packet 652B is received by the first network device 628, excluding the incremental calculation time (ΔT1) calculated by the second network device 630, as follows:

[0078] RTT = (T3 – T1) – [ΔT1]

[0079] The TWAMP server 638 can also calculate the RTT based on the time from when the test packet 652B is transmitted by the second network device 630 to when the response test packet 652D is received by the second network device 630, excluding the incremental calculation time (ΔT2) calculated by the first network device 628, as follows:

[0080] RTT = (T4 – T2) – [ΔT2]

[0081] The TWAMP control client / server 632 and the TWAMP server / control client 638 can additionally or alternatively use the continuously measured RTT to calculate the jitter (as described above).

[0082] By sending the incremental calculation time (ΔT) instead of the received timestamp and the responder timestamp, the TWAMP session sender or the TWAMP session reflector can send test packets (e.g., test packets 652B and 652E) with fewer bytes (e.g., 6 bytes).

[0083] Figure 7 is a flowchart illustrating an example operation of a network device according to one or more aspects of the techniques described herein, the network device being configured to perform enhanced TWAMP that sends the incremental calculation time. Regarding the enhanced TWAMP implemented by Figure 6 the first network device and the second network device described in Figure 7 is described.

[0084] In Figure 7 example, the TWAMP session sender 634 executed by the first network device 628 sends a test packet 652A (702) including a transmission timestamp (T1) through the test session 650. The TWAMP session reflector 640 executed by the second network device 630 receives the test packet 652A (704) through the test session 650.

[0085] The TWAMP session reflector 640 can calculate the incremental calculation time (ΔT1) (e.g., the time from when the TWAMP session reflector 640 receives a test packet to when the TWAMP session reflector 640 sends the test packet back to the TWAMP session sender 634). The TWAMP session reflector 640 sends a test packet (706) including the incremental calculation time (ΔT1) and the transmission timestamp (T2) through the test session 650. The TWAMP session sender 634 receives the test packet 652B through the test session 650 and marks the test packet with the received timestamp (T3) (708).

[0086] The TWAMP session sender 634 can calculate the incremental calculation time (ΔT2) (e.g., the time from when the TWAMP session sender 634 receives a test packet to when the TWAMP session sender 634 sends the test packet back to the TWAMP session reflector 640). The TWAMP session sender 634 sends a test packet (710) including the incremental calculation time (ΔT2) to the TWAMP session reflector 640 through the test session 650. The TWAMP session reflector 640 receives the test packet and marks the test packet with the received timestamp (T4).

[0087] The first network device 628 can use the metrics and the incremental calculation time (ΔT1) included in the test packet to calculate network performance measurements (714). For example, the first network device 628 can extract the timestamps T1, T3, and ΔT1 to calculate the RTT and / or jitter. Similarly, the second network device 630 can use the metrics and the incremental calculation time (ΔT2) included in the test packet to calculate network performance measurements (716). For example, the second network device 630 can extract the timestamps T2, T4, and ΔT2 to calculate the RTT and / or jitter.

[0088] Figure 8 is a block diagram illustrating an example network device according to one or more aspects of the techniques described herein, the example network device being configured to use a single TWAMP instance to provide enhanced TWAMP to measure the network performance of links and / or network paths of a fully converged SD-WAN. Figure 8 The network device 800 can represent Figure 1 either router 8 or router 18 of Figure 2 , Figure 4 and Figure 6 any of the network devices in any of the figures of.

[0089] Network device 800 includes a control unit 802, which includes a routing engine 804, and the control unit 802 is coupled to a forwarding engine 806 (also referred to herein as "forwarding unit 806"). The forwarding engine 806 is associated with one or more interface cards 832A - 832N ("IFC 832") that receive packets via inbound links 858A - 858N ("inbound links 858") and send packets via outbound links 860A - 860N ("outbound links 860"). The IFC 832 is typically coupled to links 858, 860 via a number of interface ports (not shown). The interfaces of the inbound links 858 and the outbound links 860 may represent physical interfaces, logical interfaces, or some combination thereof. The interfaces of the links 858, 860 may represent the local interfaces of the network device 800 for the WAN links of the network device for SD - WAN 7 to Figure 1 The local interface of the network device 800 for the WAN links of the network device for SD - WAN 7 to

[0090] Generally speaking, the control unit 802 may represent hardware, or a combination of hardware and control software, which implements one or more protocols 820 to learn and maintain routing information 834. The routing information 834 may include information defining the topology of a network such as Figure 1 Network 2 such as a service provider network. For example, the routing information may define routes (e.g., a series of next hops) to destinations / prefixes within the network through the network learned via a distance - vector routing protocol (e.g., BGP 824), or define the network topology of interconnected links learned with a link - state routing protocol (e.g., ISIS or OSPF) using IGP 822. The protocol 820 interacts, for example, via API calls with a kernel ( Figure 8 Not shown in) executing on the control unit 802 to update the routing information 834 based on routing protocol messages received by the network device 800. The kernel of the control unit 802 executes one or more main microprocessors 814 and may include, for example, a UNIX operating system derivative such as Linux or Berkeley Software Distribution (BSD). The kernel provides libraries and drivers through which user - level processes can interact with the underlying system. Execution is loaded from a storage device ( Figure 8 Not shown in) into the main memory ( Figure 8The microprocessor 814 that executes program instructions (not shown in ) in order to execute the software stack includes a kernel and processes that execute on the operating environment provided by the kernel. The microprocessor 814 may represent one or more general-purpose or special-purpose processors, such as a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or any other equivalent logic device. Thus, the term "processor" or "controller" as used herein may refer to any one or more of the foregoing structures or any other structure operable to execute the techniques described herein.

[0091] The kernel processes kernel calls from the routing protocol 802 to generate forwarding information 808 based on the network topology represented in the routing information 834. Generally, the forwarding information 808 is generated in the form of a radix or other lookup tree to map packet information (e.g., header information with destination information and / or label stack) to the next hop and ultimately to the interface port of the IFC 832 associated with the forwarding engine 806. The forwarding information 808 may associate, for example, a network destination with a specific next hop and the corresponding IFC 832. For MPLS-related traffic forwarding, the forwarding information 808 stores label information that includes an incoming label, an outgoing label, and the next hop of the packet. Then, the control unit 802 may program the forwarding engine 806 of the network device data plane with the forwarding information 808, which installs the forwarding information, for example, within an application-specific integrated circuit (ASIC) ( Figure 8 not shown).

[0092] Figure 8The architecture of the network device 800 illustrated is shown for illustrative purposes only. The present disclosure is not limited to this architecture. In other examples, the network device 800 can be configured in a variety of ways. In one example, some functions of the control unit 802 can be distributed within the IFC 832. The control unit 802 can be implemented in software only, or in hardware, or can be implemented as a combination of software, hardware, or firmware. For example, the control unit 802 can include one or more of the following: a processor, a programmable processor, a general-purpose processor, a digital signal processor (DSP), an integrated circuit, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or any type of hardware unit capable of implementing the techniques described herein. The control unit 802 can also include one or more processors that execute software instructions stored, implemented, or encoded in a computer-readable medium, such as a computer-readable storage medium. The instructions embedded or encoded in the computer-readable medium can cause the programmable processor or other processor to execute the method, e.g., when the instructions are executed. The computer-readable storage medium can include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), non-volatile random access memory (NVRAM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette tape, a solid-state drive, a magnetic medium, an optical medium, or other computer-readable media. In some instances, the computer-readable storage medium can include instructions that cause the programmable processor to execute the techniques described herein.

[0093] In Figure 8 an example, the routing engine 804 provides an operating environment for one or more traffic engineering protocols to establish tunnels for forwarding subscriber packets through an ordered set of service nodes 10 associated with different service chains. For example, the Resource Reservation Protocol with Traffic Engineering extensions (RSVP-TE) 826 can exchange traffic engineering information, such as MPLS labels for enabling label-based packet forwarding. As another example, the routing engine 804 can use GRE or an IP-based tunneling protocol (not shown) to establish traffic engineering tunnels. The routing engine 804 can maintain, for example, a Traffic Engineering Database (TED) ( Figure 8 not shown in Figure 8 to store traffic engineering data. Although Figure 8 not shown in

[0094] The routing engine 804 provides an operating environment for the TWAMP 828. For example, the routing engine 804 can use the TWAMP 828 to perform one or more TWAMP logical roles, such as a TWAMP control client, a TWAMP server, a TWAMP session sender, and a TWAMP session reflector. According to the techniques described in the present invention, the TWAMP 828 can be extended to enable a network device to independently perform network performance calculations, share network performance calculations, and / or send incremental calculation times with a single TWAMP instance. The network device 800 is described herein as being configured as a first endpoint that performs a TWAMP control client and / or an associated TWAMP session sender, or as being configured as a second endpoint that performs a TWAMP server and / or an associated TWAMP session reflector. In some examples, the network device 800 can serve as a first endpoint for a first TWAMP session and also as a second endpoint for a second TWAMP session. For example, at a given time, the network device 800 can operate as a primary TWAMP control client selected for one endpoint of a first TWAMP session and can also operate as a secondary TWAMP server for the other endpoint of a second TWAMP session.

[0095] The disclosed techniques include extending the TWAMP 828 to select a network device to perform the primary TWAMP control client. For example, the network device 800 can indicate its interest in being selected to perform the primary TWAMP control client. The network device 800 can initiate a control connection and share system resource usage and / or load information with the other endpoint of the TWAMP. For example, the network device 800 can share system resource usage and / or load information using TCP. In some examples, the network device 800 can receive a TCP reset from the other endpoint to reset the control connection initiated by the network device 800. In these examples, the other endpoint of the TWAMP can determine, based on a comparison of the system resource usage and / or load information, that the other endpoint has more robust system resources and / or load. The other endpoint sends a TCP reset and then performs as a TWAMP control client and / or a TWAMP session sender.

[0096] In some examples, network device 800 may initiate a control connection in parallel with the other endpoint of TWAMP. In these examples, network device 800 shares system resource usage and / or load information with the other endpoint and may receive system resource usage and / or load information from the other endpoint. If network device 800 receives system resource usage and / or load information from an endpoint before receiving the system resource usage and / or load information of network device 800 at the endpoint, network device 800 may compare the system resource usage and / or load information and determine whether network device 800 has a more robust system resource usage and / or load. If network device 800 determines that it has a more robust system resource and / or load, network device 800 sends a TCP reset to the endpoint at the other end of TWAMP to reset the control connection initiated by the endpoint. Then, network device 800 executes the primary TWAMP control client and initiates a control connection.

[0097] The disclosed techniques include extending TWAMP 828 to enable a network device to independently measure the network performance of a fully converged SD-WAN using test packets exchanged during a single instance of TWAMP. For example, network device 800 operating as a TWAMP session sender may send test packets including a transmission timestamp (T1) through a test session with the other endpoint, where the other endpoint operates as a TWAMP session reflector. When operating as a TWAMP session sender (e.g., in forwarding engine 806), network device 800 may receive a test packet returned from the TWAMP session reflector, which includes a received timestamp (T2) and a responder timestamp (T3) embedded within the test packet. Network device 800 may mark the test packet with the received timestamp (T4). Network device 800 may also operate as a TWAMP session reflector to return the test packet to the other endpoint. For example, when operating as a TWAMP session reflector, network device 800 may mark the test packet with the responder timestamp (T5) and send the test packet to the other endpoint through the test session. Network device 800 may extract the embedded metrics (e.g., timestamps) and perform network performance calculations (e.g., RTT, jitter, etc.).

[0098] In other examples, a network device 800 operating as a TWAMP session reflector can receive, via a test session, a test packet including a transmission timestamp (T1) from the other endpoint operating as a TWAMP session sender. When operating as a TWAMP session reflector, the network device 800 can tag the received test packet with the received timestamp (T2) and send the test packet back to the TWAMP session sender including a responder timestamp (T3). The network device 800 can also operate as a TWAMP session sender to receive the test packet returned from the other endpoint. For example, when operating as a TWAMP session sender, the network device 800 can receive a test packet with a responder timestamp (T5) and tag the test packet with the received timestamp (T6). The network device 800 can extract the embedded metrics (e.g., timestamps) and perform network performance calculations (e.g., RTT, jitter, etc.).

[0099] The disclosed techniques additionally or alternatively include extending TWAMP 828 to enable a network device to send network performance calculations. For example, a network device 800 operating as a TWAMP session sender can send, via a test session with the other endpoint, a test packet including a transmission timestamp (T1), where the other endpoint operates as a TWAMP session reflector. When operating as a TWAMP session sender, the network device 800 can receive the test packet returned from the TWAMP session reflector, which includes the received timestamp (T2) and the responder timestamp (T3) embedded within the test packet. The network device 800 can tag the test packet with the received timestamp (T4). The network device 800 can extract the embedded metrics (e.g., timestamps) and perform network performance calculations (e.g., RTT, jitter, etc.). The network device 800 can send the network performance calculations to the other endpoint via the test session.

[0100] In other examples, a network device 800 operating as a TWAMP session reflector can receive, via a test session, a test packet including a transmission timestamp (T1) from the other endpoint operating as a TWAMP session sender. When operating as a TWAMP session reflector, the network device 800 can tag the received test packet with the received timestamp (T2) and send the test packet including the responder timestamp (T3) back to the TWAMP session sender. The network device 800 can receive a test packet returned from the other endpoint including the network performance calculations and store the network performance calculations.

[0101] The disclosed techniques additionally or alternatively include extending TWAMP 828 to enable network devices to send incremental computation times. For example, a network device 800 operating as a TWAMP session sender can send a test packet including a transmission timestamp (T1) through a test session with another endpoint, where the other endpoint operates as a TWAMP session reflector. When operating as a TWAMP session sender, the network device 800 can receive a test packet returned from the TWAMP session reflector, which includes a transmission timestamp (T2) and an incremental computation time (ΔT1), where the incremental computation time is the time from when the TWAMP session reflector receives the test packet to when the TWAMP session reflector sends the test packet back to the TWAMP session sender. The network device 800 receives the test packet through the test session and marks the test packet with the received timestamp (T3). The TWAMP session sender can calculate the incremental computation time (ΔT2) taken to receive the test packet and send the test packet back to the TWAMP session reflector. The network device 800 can extract the timestamps (e.g., T1, T3) and the incremental computation time (ΔT1) to calculate network performance measurements.

[0102] In other examples, a network device 800 operating as a TWAMP session reflector can receive, through a test session, a test packet including a transmission timestamp (T1) from another endpoint operating as a TWAMP session sender. When operating as a TWAMP session reflector, the network device 800 can calculate the incremental computation time (ΔT1) taken to receive the test packet and send the test packet back to the TWAMP session sender. The network device 800 can send a test packet including the incremental computation time (ΔT2) and the transmission timestamp (T2) to the TWAMP session reflector. The network device 800 can receive a test packet including the incremental computation time (ΔT2) calculated by the TWAMP session sender and mark the test packet with the received timestamp (T4). The network device 800 can extract the timestamps (e.g., T2, T4) and the incremental computation time (ΔT2) to calculate network performance measurements.

[0103] The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, aspects of the described techniques may be implemented within one or more processors, which include one or more microprocessors, DSPs, ASICs, FPGAs, or any other equivalent integrated or discrete logic circuitry, as well as any combination of such components. The term “processor” or “processing circuitry” generally may refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit including hardware may also perform one or more of the techniques of this disclosure.

[0104] Such hardware, software, and firmware may be implemented within the same device or in separate devices to support the various operations and functions described in this disclosure. Additionally, any of the described units, modules, or components may be implemented together or separately as discrete but interoperable logic devices. Describing different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that these modules or units must be implemented by separate hardware or software components. Instead, the functions associated with one or more modules or units may be performed by separate hardware or software components or integrated in common or separate hardware or software components.

[0105] The techniques described in this invention may also be implemented or encoded in a computer-readable medium (e.g., a computer-readable storage medium) containing instructions. The instructions embedded or encoded in the computer-readable medium may cause a programmable processor or other processor to execute the method, e.g., when the instructions are executed. The computer-readable medium may include non-transitory computer-readable storage media and transient communication media. Tangible computer-readable storage media and non-transitory computer-readable storage media may include RAM, ROM, PROM, EPROM, EEPROM, flash memory, hard disks, CD-ROMs, floppy disks, cassette tapes, magnetic media, optical media, or another computer-readable storage medium. It should be understood that the term "computer-readable storage medium" refers to a physical storage medium and not a signal, carrier, or other transient medium.

Claims

1. A method for a computer network, comprising: Establishing a Two - Way Active Measurement Protocol (TWAMP) session between a first network device and a second network device, wherein the TWAMP session includes a single test session between a TWAMP session sender executed on the first network device and a TWAMP session reflector executed on the second network device, and between a TWAMP session sender executed on the second network device and a TWAMP session reflector executed on the first network device; Exchanging a plurality of TWAMP test packets carrying one or more metrics via the single test session between the TWAMP session sender executed on the first network device and the TWAMP session reflector executed on the second network device, and between the TWAMP session sender executed on the second network device and the TWAMP session reflector executed on the first network device; And Calculating, by the first network device or the second network device, at least one active round - trip network performance metric for a link between the first network device and the second network device based on the one or more metrics carried by the plurality of TWAMP test packets.

2. The method according to claim 1, wherein exchanging the TWAMP test packets via the single test session comprises: Sending, by the TWAMP session sender executed on the first network device, a first TWAMP test packet of the plurality of TWAMP test packets to the TWAMP session reflector executed on the second network device, the first TWAMP test packet carrying at least a first metric of the one or more metrics; In response to receiving the first TWAMP test packet from the TWAMP session sender executed on the first network device, sending, by the TWAMP session reflector executed on the second network device, a second TWAMP test packet of the plurality of TWAMP test packets back to the TWAMP session sender executed on the first network device, the second TWAMP test packet carrying at least a second metric of the one or more metrics; And In response to receiving the second TWAMP test packet from the TWAMP session reflector executed on the second network device, sending, by the TWAMP session reflector executed on the first network device, a third TWAMP test packet of the plurality of TWAMP test packets back to the TWAMP session sender executed on the second network device, the third TWAMP test packet carrying at least a third metric of the one or more metrics.

3. The method according to claim 2, wherein the first metric at least includes a transmission timestamp indicating the time when the first TWAMP test packet is initially sent from the TWAMP session sender executed on the first network device to the TWAMP session reflector executed on the second network device; wherein the second metric includes a first responder timestamp indicating the time when the second TWAMP test packet is sent back from the TWAMP session reflector executed on the second network device to the TWAMP session sender executed on the first network device, and a reception timestamp indicating the time when the TWAMP session reflector executed on the second network device receives the first TWAMP test packet from the TWAMP session sender executed on the first network device; and wherein the third metric includes a second responder timestamp indicating the time when the third TWAMP test packet is sent back from the TWAMP session reflector executed on the first network device to the TWAMP session sender executed on the second network device, and a reception timestamp indicating the time when the TWAMP session reflector executed on the first network device receives the second TWAMP test packet from the TWAMP session reflector executed on the second network device.

4. The method according to any one of claims 2 or 3, wherein calculating the at least one active round-trip network performance metric for the link between the first network device and the second network device includes one or more of the following: calculating, by the first network device, the at least one active round-trip network performance metric based on the first metric and the second metric; calculating, by the second network device, the at least one active round-trip network performance metric based on the second metric and the third metric.

5. The method according to claim 2, wherein the first metric at least includes a transmission timestamp indicating the time when the first TWAMP test packet is sent from the TWAMP session sender executed on the first network device to the TWAMP session reflector executed on the second network device; wherein the second metric includes a first responder timestamp indicating the time when the second TWAMP test packet is sent back from the TWAMP session reflector executed on the second network device to the TWAMP session sender executed on the first network device, and a reception timestamp indicating the time when the TWAMP session reflector executed on the second network device receives the second TWAMP test packet from the TWAMP session sender executed on the first network device; The third metric includes at least one active round-trip network performance metric for the link between the first network device and the second network device, and the at least one active round-trip network performance metric is calculated by the first network device based on the first metric and the second metric.

6. The method according to any one of claims 2 or 5, wherein calculating the at least one active round-trip network performance metric for the link between the first network device and the second network device includes: calculating, by the first network device, the at least one active round-trip network performance metric based on the first metric and the second metric; sending, by the first network device, the at least one active round-trip network performance metric to the second network device as the third metric.

7. The method according to claim 2, wherein the first metric at least includes a transmission timestamp indicating the time when the first TWAMP test packet is sent from the TWAMP session sender executed on the first network device to the TWAMP session reflector executed on the second network device; wherein the second metric at least includes a first incremental calculation time, and the first incremental calculation time indicates the time when the TWAMP session reflector executed on the second network device receives the first TWAMP test packet to the time when the TWAMP session reflector executed on the second network device sends the second TWAMP test packet back to the TWAMP session sender executed on the first network device; and wherein the third metric at least includes a second incremental calculation time, and the second incremental calculation time indicates the time when the TWAMP session sender executed on the first network device receives the second TWAMP test packet to the time when the TWAMP session sender executed on the first network device sends the third TWAMP test packet back to the TWAMP session reflector executed on the second network device.

8. The method according to claim 7, wherein calculating the at least one active round-trip network performance metric for the link between the first network device and the second network device includes one or more of the following: calculating, by the first network device, the at least one active round-trip network performance metric based on the second metric including at least the first incremental calculation time; or calculating, by the second network device, the at least one active round-trip network performance metric based on the third metric including at least the second incremental calculation time.

9. A system for a computer network, comprising: a first network device that executes a two-way active measurement protocol TWAMP session sender and a TWAMP session reflector for a single test session; and a second network device that executes a TWAMP session reflector and a TWAMP session sender for the single test session; wherein the first network device and the second network device are each configured to: A TWAMP session is established between the first network device and the second network device, where the TWAMP session includes a single test session between the TWAMP session sender executed on the first network device and the TWAMP session reflector executed on the second network device, and between the TWAMP session sender executed on the second network device and the TWAMP session reflector executed on the first network device; Via the single test session between the TWAMP session sender executed on the first network device and the TWAMP session reflector executed on the second network device, and between the TWAMP session sender executed on the second network device and the TWAMP session reflector executed on the first network device, a plurality of TWAMP test packets carrying one or more metrics are exchanged; And Based on the one or more metrics carried by the plurality of TWAMP test packets, at least one active round-trip network performance metric for the link between the first network device and the second network device is calculated.

10. The system according to claim 9, wherein in order to exchange the TWAMP test packets via the single test session, the first network device is further configured to: Send a first TWAMP test packet of the plurality of TWAMP test packets, the first TWAMP test packet carrying at least a first metric of the one or more metrics; In response to receiving a second TWAMP test packet from the TWAMP session reflector executed on the second network device, send a third TWAMP test packet of the plurality of TWAMP test packets back to the TWAMP session sender executed on the first network device, the third TWAMP test packet carrying at least a third metric of the one or more metrics; and wherein in order to exchange the plurality of TWAMP test packets via the single test session, the second network device is further configured to: In response to receiving the first TWAMP test packet from the TWAMP session sender executed on the first network device, send the second TWAMP test packet back to the TWAMP session sender executed on the first network device, the second TWAMP test packet carrying at least a second metric of the one or more metrics; And Receive the third TWAMP test packet carrying the third metric from the TWAMP session reflector executed on the first network device.

11. The system according to claim 10, wherein the first metric at least includes a transmission timestamp indicating the time when the first TWAMP test packet was initially sent from the TWAMP session sender executed on the first network device to the TWAMP session reflector executed on the second network device; wherein the second metric includes a first responder timestamp indicating the time at which the second TWAMP test packet is sent back from the responder of the TWAMP session executed on the second network device to the sender of the TWAMP session executed on the first network device, and a reception timestamp indicating the time at which the responder of the TWAMP session executed on the second network device receives the first TWAMP test packet from the sender of the TWAMP session executed on the first network device; and wherein the third metric includes a second responder timestamp indicating the time at which the third TWAMP test packet is sent back from the responder of the TWAMP session executed on the first network device to the sender of the TWAMP session executed on the second network device, and a reception timestamp indicating the time at which the sender of the TWAMP session executed on the first network device receives the second TWAMP test packet from the responder of the TWAMP session executed on the second network device.

12. The system according to any one of claims 10 or 11, wherein, in order to calculate at least one active round-trip network performance metric for the link between the first network device and the second network device, the first network device is further configured to: calculate a first part of the at least one active round-trip network performance metric based on the first metric and the second metric; and wherein, in order to calculate at least one active round-trip network performance metric for the link between the first network device and the second network device, the second network device is further configured to: calculate a second part of the at least one active round-trip network performance metric based on the second metric and the third metric.

13. The system according to claim 10, wherein the first metric at least includes a transmission timestamp indicating the time at which the first TWAMP test packet is sent from the sender of the TWAMP session executed on the first network device to the responder of the TWAMP session executed on the second network device; wherein the second metric includes a first responder timestamp indicating the time at which the second TWAMP test packet is sent back from the responder of the TWAMP session executed on the second network device to the sender of the TWAMP session executed on the first network device, and a reception timestamp indicating the time at which the responder of the TWAMP session executed on the second network device receives the first TWAMP test packet from the sender of the TWAMP session executed on the first network device; and wherein the third metric includes the at least one active round-trip network performance metric for the link between the first network device and the second network device, wherein the at least one active round-trip network performance metric is calculated by the first network device based on the first metric and the second metric.

14. The system according to any one of claims 10 or 13, wherein, in order to calculate at least one active round-trip network performance metric for the link between the first network device and the second network device, the first network device is further configured to: calculate the at least one active round-trip network performance metric based on the first metric and the second metric; and send the at least one active round-trip network performance metric to the second network device as the third metric.

15. The system according to claim 10, wherein the first metric at least includes a transmission timestamp indicating the time when the first TWAMP test packet is sent from the TWAMP session sender executed on the first network device to the TWAMP session reflector executed on the second network device; wherein the second metric at least includes a first incremental calculation time, the first incremental calculation time indicating the time from when the TWAMP session reflector executed on the second network device receives the first TWAMP test packet to the time when the TWAMP session reflector executed on the second network device sends the second TWAMP test packet back to the TWAMP session sender executed on the first network device; and wherein the third metric at least includes a second incremental calculation time, the second incremental calculation time indicating the time from when the TWAMP session sender executed on the first network device receives the second TWAMP test packet to the time when the TWAMP session reflector executed on the first network device sends the third TWAMP test packet back to the TWAMP session sender executed on the second network device.

16. The system according to claim 15, wherein, in order to calculate at least one active round-trip network performance metric for the link between the first network device and the second network device, the first network device is further configured to: calculate the at least one active round-trip network performance metric based on the second metric including at least the first incremental calculation time; in order to calculate at least one active round-trip network performance metric for the link between the first network device and the second network device, the second network device is further configured to: calculate the at least one active round-trip network performance metric based on the third metric including at least the second incremental calculation time.

17. A non-transitory computer-readable medium, including instructions for causing at least one programmable processor of a first network device to include: establish a TWAMP session between the first network device and a second network device, wherein the TWAMP session includes a single test session between the TWAMP session sender executed on the first network device and the TWAMP session reflector executed on the second network device and between the TWAMP session sender executed on the second network device and the TWAMP session reflector executed on the first network device; Exchange a plurality of TWAMP test packets carrying one or more metrics between the TWAMP session sender executed on the first network device and the TWAMP session reflector executed on the second network device, and between the TWAMP session sender executed on the second network device and the TWAMP session reflector executed on the first network device through the single test session; And Calculate at least one active round-trip network performance metric for the link between the first network device and the second network device based on the one or more metrics carried by the plurality of TWAMP test packets.

18. The non-transitory computer-readable medium according to claim 17, wherein the instructions further cause the at least one programmable processor of the first network device to: Send a first TWAMP test packet of the plurality of TWAMP test packets, the first TWAMP test packet carrying at least a first metric of the one or more metrics; In response to receiving a second TWAMP test packet of the plurality of TWAMP test packets from the TWAMP session reflector, send a third TWAMP test packet of the plurality of TWAMP test packets back to the TWAMP session reflector, the third TWAMP test packet carrying at least a third metric of the one or more metrics, wherein the second TWAMP test packet includes at least a second metric of the one or more metrics.

19. The non-transitory computer-readable medium according to claim 18, Wherein the first metric at least includes a transmission timestamp indicating the time when the first TWAMP test packet is initially sent from the TWAMP session sender executed on the first network device to the TWAMP session reflector executed on the second network device; Wherein the second metric includes a first responder timestamp indicating the time when the second TWAMP test packet is sent back from the TWAMP session reflector executed on the second network device to the TWAMP session sender executed on the first network device, and a reception timestamp indicating the time when the TWAMP session reflector executed on the second network device receives the first TWAMP test packet from the TWAMP session sender executed on the first network device; and Wherein the third metric includes a second responder timestamp indicating the time when the third TWAMP test packet is sent back from the TWAMP session reflector executed on the first network device to the TWAMP session sender executed on the second network device, and a reception timestamp indicating the time when the TWAMP session reflector executed on the first network device receives the second TWAMP test packet from the TWAMP session reflector executed on the second network device.

20. The non-transitory computer-readable medium according to claim 18, Wherein the first metric at least includes a transmission timestamp indicating the time when the first TWAMP test packet is sent from the TWAMP session sender executed on the first network device to the TWAMP session reflector executed on the second network device; Wherein the second metric includes a first responder timestamp indicating the time when the second TWAMP test packet is sent back from the TWAMP session reflector executed on the second network device to the TWAMP session sender executed on the first network device, and a reception timestamp indicating the time when the TWAMP session reflector executed on the second network device receives the first TWAMP test packet from the TWAMP session sender executed on the first network device; and Wherein the third metric includes the at least one active round-trip network performance metric for the link between the first network device and the second network device, and the at least one active round-trip network performance metric is calculated by the first network device based on the first one or more metrics and the second one or more metrics.

Images