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.

Contents
 Why Do We Need NQA?

 NQA Fundamentals

 Processing Mechanism of NQA Tests

 Typical Applications of NQA

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:

1. A client constructs a UDP packet with a TTL of 1 and sends the packet to the
destination.

2. 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.

3. 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.

4. 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.

5. 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.