Communication Model

The TWAMP Light model consists of the Controller and Responder, which are different from the standard TWAMP model in terms of architecture.

TWAMP Light Communication Model

In Figure 1, TWAMP-Test packets function as probes for measuring receive and transmit performance and carry the IP address, UDP port number, and fixed TTL value 255 predefined for the test session between the Controller and Responder. The Controller sends a TWAMP-Test packet to the Responder, and the Responder reflects it to the Controller. The Controller collects TWAMP statistics.

TWAMP Light defines two types of TWAMP-Test packets: Test-request packets and Test-response packets.

Session-Sender test packets are sent from the Controller to the Responder.
Session-Reflector test packets are replied by the Responder to the Controller.

The Controller collects performance statistics based on TWAMP-Test packets and reports the results to the NMS, which provides the statistics to users.

The transmission of TWAMP-Test packets is affected by link loads and congestion.
The default DSCP value of TWAMP-Test packets is 0. In other words, the default scheduling priority is BE. You can configure a DSCP value when creating a test session on the Controller.

Figure 1 Basic communication model of TWAMP Light

Comparison Between TWAMP Light and TWAMP

TWAMP is an IP performance monitoring (IPPM) protocol and has two versions: standard version and light version. TWAMP consists of a standard version and a light version (TWAMP Light).

As shown in Figure 2, TWAMP uses the client/server model and defines four logical entities:

Control-Client: establishes, initiates, and terminates TWAMP sessions and collects the statistical results.
Session-Sender: proactively sends probes to collect performance statistics after being notified by the Control-Client.
Server: responds to the Control-Client's request to establish, initiate, or terminate a test session.
Session-Reflector: replies to the probes sent by the Session-Sender after being notified by the Server.

Figure 2 TWAMP architecture

Figure 3 TWAMP Light architecture

As shown in Figure 3, TWAMP Light moves the control plane from the Responder to the Controller. The Controller functions as the Control-Client and Session-Sender, and the Responder only functions as the Session-Reflector. Therefore, TWAMP Light skips the process of establishing a control session in the TWAMP architecture during performance measurement.

TWAMP Light simplifies TWAMP's communication model, enabling TWAMP control modules to be deployed only on the Controller. TWAMP Light also significantly reduces requirements on the Responder performance, enabling rapid deployment and plug-and-play of the Responder. The Controller and Responder function as follows:

Controller: establishes, initiates, and terminates a test session, receives and sends packets over the test session, collects and calculates performance statistics, and reports the results to the NMS.
Responder: responds to the packets transmitted over a test session.

Different from TWAMP, TWAMP Light has parameters statically configured for a test session. You can configure the IP address and UDP port number on the Responder using MIBs. After a test session is created, TWAMP-Test packets are transmitted over the test session to help calculate the performance statistics, such as the packet loss rate, delay, and jitter. Therefore, TWAMP Light does not need any control protocol for parameter negotiation. TWAMP Light simplifies the working process of protocols and is easier to be deployed in real world situations.