What Is NQA?
Network Quality Analysis (NQA) is a technology to measure network performance in real time and collect statistics on network indicators, such as the delay, jitter, and packet loss rate. It helps administrators learn network service quality in real time and effectively diagnose and locate network faults.
Why Do We Need NQA?
As value-added services develop, users and carriers demand higher quality of service (QoS). Especially after voice and video services are provisioned on conventional IP networks, carriers and users reach service level agreements (SLAs) to implement QoS guaranteed services.
To provide committed bandwidth for users, carriers need to collect statistics about network indicators such as the delay, jitter, and packet loss rate, and analyze the statistics to obtain network performance. Conventional network performance analysis methods (such as ping and tracert) cannot meet carriers' requirements for real-time monitoring on diverse services.
Against this backdrop, NQA can be deployed to accurately test the network running status and export statistics. NQA can measure the performance of various protocols running on the network. This facilitates real-time collection of different network performance indicators, such as the total HTTP connection delay, TCP connection delay, DNS resolution delay, file transfer rate, FTP connection delay, and DNS resolution error rate. Carriers control these indicators to provide users with network services of various grades. Additionally, NQA is an effective tool to diagnose and locate faults on the network.
NQA Fundamentals
NQA client and server
In an NQA test, devices at two ends are an NQA client and an NQA server, which are also known as the source and destination. To initiate an NQA test, a client constructs a packet in compliance with a certain protocol based on the test instance type, adds a timestamp to the packet, and sends the packet to a specified server.
An NQA server listens to the NQA test packets with the specified IP address and port number and responds to the test accordingly. The client then calculates performance indicators, such as the connectivity, delay, and packet loss rate, based on statistics about the sent and received packets.
Processing Mechanism of NQA Tests
- ICMP test
In an ICMP test, ICMP packets are sent to check reachability of the destination and calculate the network response time and packet loss rate.
A source constructs an ICMP Echo Request packet and sends it to a destination. When receiving the packet, the destination returns an ICMP Echo Reply packet to the source.
Upon receipt of the ICMP Echo Reply packet, the source calculates the time between when it sends the ICMP Echo Request packet and when it receives the ICMP Echo Reply packet. The test result reflects network performance and connectivity.
- Trace test
A trace test monitors the forwarding path from a source to a destination and collects statistics such as delay about each device (hop) along the path.
The process of a trace test is as follows:
- A client constructs a UDP packet with a TTL of 1 and sends the packet to the destination.
- When receiving the packet, the first-hop device decrements the TTL value to 0. As a result, the device discards the packet and returns an ICMP Time Exceeded packet.
- Upon receipt of the ICMP Time Exceeded packet, the client records the IP address of the first-hop device, and sends a UDP packet with a TTL of 2.
- When receiving the packet, the second-hop device decrements the TTL value to 0. As a result, the device discards the packet and returns an ICMP Time Exceeded packet.
- The client continues to send UDP packets, with the TTL value incrementing by 1 each time a new packet is sent. This process is repeated until the packet reaches the last-hop device (destination), which returns an ICMP Port Unreachable packet to the client.
Based on the ICMP packets received from each hop, the client collects information about the forwarding path and statistics about each device along the path.
- TCP test
A TCP test measures the time taken by a TCP client and a TCP server to set up a TCP connection through a three-way handshake.
The client calculates the time between when it sends a TCP SYN packet and when it receives a TCP SYN ACK packet and the time between when it receives a TCP SYN ACK packet and when it sends an ACK packet. As a result, it obtains the time taken to set up a TCP connection with the TCP server through a three-way handshake. The test result reflects TCP performance on the network.
- UDP test
Many services on the network are carried by UDP. Users cannot determine whether the quality deterioration of a service is caused by the service itself or UDP performance. NQA UDP tests can help resolve this problem by measuring UDP performance on the network.
A source sends a constructed UDP packet to a destination, which returns a response packet. Upon receipt of the response packet, the source calculates the time between when it sends the UDP packet and when it receives the response packet. The test result reflects UDP performance on the network.
- DNS test
A DNS test is performed using UDP packets. An NQA client functions a DNS client to send a DNS request to a specified DNS server. This test helps determine whether the DNS server is available and measure the DNS resolution time.
- FTP test
An FTP test is performed using TCP packets. It checks whether a client can set up a connection with a specified FTP server, and measures the time taken to download a specified file from or upload a specified file to the FTP server.
- HTTP test
An HTTP test checks whether a client can set up a connection with a specified HTTP server and measures the time taken to set up such a connection.
- SNMP test
An SNMP test is performed using UDP packets. The test checks SNMP connectivity between a host and an SNMP agent, and measures the time taken for communication between them.
A source constructs a request packet and sends it to an SNMP agent, which returns a response packet. Upon receipt of the response packet, the source calculates the time between when it sends the request packet and when it receives the response packet. The test result reflects SNMP performance on the network.
- LSP ping test
A label switched path (LSP) ping test checks reachability of Label Distribution Protocol (LDP) LSPs and traffic engineering (TE) LSPs.
A source constructs an MPLS Echo Request packet whose destination IP address in the IP header is on the network segment 127.0.0.0/8. The source then searches for the corresponding LSP based on the configured remote label switching router (LSR) ID, and forwards the packet through this LSP in the MPLS domain. The destination monitors port 3503 and returns an MPLS Echo Reply packet.
Upon receipt of the MPLS Echo Reply packet, the source calculates the time between when it sends the request and when it receives the reply. The test result reflects MPLS network connectivity.
- LSP trace test
An LSP trace test detects the forwarding paths of LDP LSPs or TE LSPs, and collects statistics about each device along the forwarding paths.
A source constructs a UDP MPLS Echo Request packet whose destination IP address in the IP header is on the network segment 127.0.0.0/8, and searches for the corresponding LSP. This MPLS Echo Request packet contains the downstream mapping TLV, which carries downstream information (such as the next hop address and outgoing label) about the LSP on the current node.
The MPLS Echo Request packet is forwarded through the specified LSP in the MPLS domain. Upon receipt of this packet, the first-hop device discards it because the TTL of this packet is 1. Then, the first-hop device returns an MPLS Echo Reply packet. The source continues to send MPLS Echo Request packets, with the TTL value incrementing by 1 each time a new packet is sent. This process is repeated until all LSRs along the LSP respond to the MPLS Echo Request packets.
Based on the reply packets received from each LSR along the LSP, the source collects information about the LSP from the source to the destination and statistics about each LSR.
- PWE3 ping test
A Pseudowire Emulation Edge-to-Edge (PWE3) ping test checks reachability of MPLS-based pseudowire (PWs).
A source sends an MPLS Echo Request packet through a PW. When receiving the packet, the remote PE returns an MPLS Echo Reply packet. Upon receipt of the MPLS Echo Reply packet, the source calculates the time between when it sends the request and when it receives the reply. The test result reflects connectivity of the PW.
- PWE3 trace test
A PWE3 trace test detects an MPLS-based PW and collects statistics about each device along the PW.
A source sends MPLS Echo Request packets with the TTL value starting from 1 and incrementing by 1 each time a new packet is sent, until each node along the forwarding path returns an MPLS Echo Reply packet. Based on the received reply packets, the source collects information about the PW from the source to the destination and statistics about each device along the path.
Typical Applications of NQA
NQA for Static Routes
Static routes do not have a dedicated detection mechanism. If an indirect link fails, a network administrator must manually delete the corresponding static route from the IP routing table. This process delays link switchover and causes service interruption for a significant amount of time.
This problem requires an effective solution to detect faults in links for static routes. BFD for static routes can resolve this problem, but it is applicable only in situations where both communicating devices support it. In contrast, if either of the two communicating devices supports NQA, NQA for static routes can be used to detect link faults.
NQA for static routes
An NQA test instance is used to detect the link status of a static route. Based on the NQA test result, the system determines whether the static route is active, preventing communication interruption and ensuring service quality.
In the preceding figure, there are a primary link and a backup link between RouterA and RouterD. RouterA serves as an NQA client to detect the status of the links to RouterD.
- If the NQA test instance detects a fault of the primary link, RouterA sets the corresponding static route to inactive.
- If the NQA test instance detects that the primary link recovers, RouterA sets the corresponding static route to active.
- Author： Gao Yangyang
- Updated on： 2021-09-30
- Views： 7180
- Average rating：
