Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Understand Two-Way Active Measurement Protocol

The Two-Way Active Management Protocol (TWAMP), described in RFC 5357, is an extension of the One-Way Active Management Protocol (OWAMP) that supplies two-way or round-trip measurements instead of unidirectional capabilities. Two-way measurements are helpful because round-trip delays do not require host clock synchronization and remote support might be a simple echo function. However, the Internet Control Message Protocol (ICMP) Echo Request/Reply (used by ping) for this purpose has several shortcomings. TWAMP defines an open protocol for measuring two-way or round-trip metrics with greater accuracy than other methods by using time-stamps (processing delays can be factored as well).

Usually, TWAMP operates between interfaces on two devices playing specific roles. TWAMP is often used to check Service Level Agreement (SLA) compliance, and the TWAMP feature is often presented in that context. TWAMP uses two related protocols, running between several defined elements:

  • TWAMP-Control—Initiates, starts, and ends test sessions. The TWAMP-Control protocol runs between a Control-Client element and a Server element.

  • TWAMP-Test—Exchanges test packets between two TWAMP elements. The TWAMP-Test protocol runs between a Session-Sender element and a Session-Reflector element.

The four elements are shown in Figure 1:

Figure 1: Four Elements of TWAMP Four Elements of TWAMP

Although four different TWAMP devices can perform the four logical roles of TWAMP Control-Client, Server, Session-Sender, and Session-Reflector, different devices can play different roles. A common implementation combines the roles of Control-Client and Session-Sender in one device (known as the TWAMP controller or TWAMP client) and the roles of Server and Session-Reflector in the other device (known as the TWAMP responder or TWAMP server). In this case, each device runs both the TWAMP-Control (between Control-Client and Server) and TWAMP-Test (between Session-Sender and Session-Reflector) protocols.

The TWAMP client-server architecture as implemented looks like this:

  • TWAMP client

    • Control-Client sets up, starts and stops the TWAMP test sessions.

    • Session-Sender creates TWAMP test packets that are sent to the Session-Reflector in the TWAMP server.

  • TWAMP server

    • Session-Reflector sends back a measurement packet when a test packet is received, but does not maintain a record of such information.

    • Server manages one or more sessions with the TWAMP client and listens for control messages on a TCP port.

The packaging of these elements into TWAMP client and TWAMP server processes is shown in Figure 2.

Figure 2: The Elements of TWAMP Implemented as Client (Left) and Server (Right). The Elements of TWAMP Implemented as Client (Left) and Server (Right).

Table 1 provides information about TWAMP and related timestamp support on MPC, MS-MIC/MPC, and Routing Engine:

Table 1: TWAMP and related timestamp support

Feature

Role

IP Version

Support (Y/N)

Timestamp on Routing Engine

Timestamp on MPC (hardware-timestamp)

Timestamp on MPC (si-interface)

Timestamp on MS-MIC/MPC (delegate-probes)

TWAMP

Client

IPv4

Y

N

Y (µsec)

500 maximum probes

Y (µsec)

500 maximum probes

N

IPv6

N

N

N

N

N

Server

IPv4

Y

N

Y (µsec)

500 maximum probes

Y (µsec)

500 maximum probes

N

IPv6

N

N

N

N

N

Table 2 provides information about support for TWAMP Light, as defined in Appendix I of RFC 5357, which defines a light version of the TWAMP protocol, a stateless version of TWAMP where test parameters are predefined instead of negotiated. All test packets received by the server on a test port are reflected back and forgotten right away.

Support for IPv6 target addresses for TWAMP Light test sessions is introduced in Junos OS Release 21.3R1.

Table 2: TWAMP Light Support
Device Supported In
ACX7100 Series Junos OS Evolved Release 21.2R1
MX Series Junos OS Release 21.1R1
PTX Series running Junos OS Junos OS Release 21.1R1
PTX10001-36MR Junos OS Evolved Release 21.1R1
PTX10003 Junos OS Evolved Release 20.3R1
PTX10004 Junos OS Evolved Release 21.2R1
PTX10008 (with the JNP10008-SF3 and either the JNP10K-LC1201 or JNP10K-LC1202-36MR line card) Junos OS Evolved Release 21.1R1
QFX10002, QFX10008, and QFX10016 Junos OS Release 21.3R1

TWAMP on MX Series Routers and QFX10000 Series Switches

Both the control client and session sender (the TWAMP client) reside on the same Juniper Networks router. However, the TWAMP client does not require that the server and the session reflector to be on the same system. Therefore, the Juniper TWAMP client is capable of working with a third-party server implementation.

Note:

TWAMP is not supported when you enable Next Gen Services on an MX Series router.

TWAMP on PTX Series routers

The TWAMP-Control protocol is used to set up performance measurement sessions between a TWAMP client and a TWAMP server, and the TWAMP-Test protocol is used to send and receive performance measurement probes. The destination interface si-x/y/z attribute, which is meant for enabling inline services, is not supported on PTX Series routers for TWAMP client configurations.

For Junos OS, TWAMP is configured at the [edit services rpm twamp] hierarchy level. For Junos OS Evolved, TWAMP is configured at the [edit services monitoring twamp] hierarchy level. Table 3 provides information about support for TWAMP.

Table 3: PTX Series TWAMP Support
Device Supported In
PTX Series running Junos OS Junos OS Release 19.2R1
PTX10001-36MR Junos OS Evolved Release 21.1R1
PTX10003 Junos OS Evolved Release 20.3R1
PTX10004 Junos OS Evolved Release 21.2R1
PTX10008 (with the JNP10008-SF3 and either the JNP10K-LC1201 or JNP10K-LC1202-36MR line card) Junos OS Evolved Release 21.1R1

The Junos OS Evolved support for TWAMP is limited to the following:

  • IPv4 traffic only for control sessions and test sessions

  • Probe statistics and history

  • Control and test session status

  • Test session probe generation and reception, as well as reflection

  • Timestamps set by the Routing Engine or the Packet Forwarding Engine

  • Error reporting through system log messages and SNMP traps only

  • Unauthenticated mode only

TWAMP on ACX Series routers

In Junos OS, TWAMP is supported for ACX routers, but only for reflection, not generation. For Junos OS, TWAMP is configured at the [edit services rpm twamp] hierarchy level.

In Junos OS Evolved, TWAMP is supported for ACX routers, for both reflection and generation. Starting in Junos OS Evolved 21.2R1, TWAMP (including TWAMP Light) is supported for the ACX7100 Series routers. For Junos OS Evolved, TWAMP is configured at the [edit services monitoring twamp] hierarchy level. The Junos OS Evolved support for TWAMP is limited to the following:

  • IPv4 traffic only for control sessions and test sessions

  • Probe statistics and history

  • Control and test session status

  • Test session probe generation and reception, as well as reflection

  • Timestamps set by the Routing Engine or the Packet Forwarding Engine

  • Error reporting through system log messages only

  • Unauthenticated mode only