Two-Way Active Measurement Protocol

The Two-Way Active Measurement Protocol, defined in RFC 5357, specifies an industry standard for measuring round-trip performance between two devices that support the TWAMP protocols. TWAMP defines two protocols; the TWAMP-Control protocol and the TWAMP-Test protocol. The TWAMP-Control protocol is used to setup test sessions. The test sessions use the TWAMP-Test protocol to transmit and reflect performance measurement packets. The TWAMP-Control protocol utilizes TCP for communication, while the TWAMP-Test protocol utilizes UDP.


Only the TWAMP-Test protocol is supported.

The test sessions are setup via the ‘Request-Session‘ command message, sent from the Control-Client to the Server. The Server replies with an ‘Accept Session‘ message, which indicates if the Server is capable of accommodating the request or not. The Control-Client may send several ‘Request-Session‘ command messages to setup multiple test sessions. To begin the tests, the Control-Client transmits a ‘Start-Session‘ command message. The Server replies with a ‘Start-Ack‘ message. The Control-Client does not begin its test until it receives the ‘Start-Ack‘ message. This allows the Server ample time to configure the test sessions. The Control-Client will stop the test sessions with a ‘Stop-Sessions‘ message. The Server does not respond to this message.

The ExtremeXOS 16.1 implementation of TWAMP consists of the development of the TWAMP logical role of the Session-Reflector. The user is required to configure endpoints, which define the destination of TWAMP-Test packets generated by the client. An endpoint receiving a new TWAMP-test packet creates a test session consisting of the following four-part tuple; client IP address, client UDP port, endpoint IP address, and endpoint UDP port. The tuple does not include the VR because it requires the default VR for the first phase. A session timeout value, configured globally, determines the amount of time test sessions exist after the last reception of a TWAMP-Test packet. Test sessions are used to keep track of the session data, such as the sequence number. The Session-Reflector will still respond to TWAMP-Test packets that do not match an existing test session or if a new test session cannot be created due to lack of resources.