TWAMP Extensions for Direct Loss Measurement

The Two-Way Active Measurement Protocol (TWAMP) is an extension of the One-Way Active Measurement Protocol (OWAMP) . The TWAMP is a well-defined protocol which is widely used for measurement of two-way or round-trip metrics, in addition to the one-way metrics of OWAMP. When TWAMP or OWAMP is used for measurement of metric loss, it actually measures the loss of test packets, so it's a kind of "synthetic" loss measurement. In some cases, considering the IP traffic loss characteristics of short-time burst loss, it's expected to get more accurate loss measurement results when measuring the direct loss of IP traffic instead of test packets. To address this, this document describes an optional and simple feature for TWAMP, which allows TWAMP-Test protocol to be used for direct loss measurement of IP traffic.

DSCP: Differentiated Services Code Point IPPM: IP Performance Metrics TWAMP: Two-Way Active Measurement Protocol OWAMP: One-Way Active Measurement Protocol UDP: User Datagram Protocol

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

TWAMP connection establishment follows the procedure defined in Section 3.1 of and Section 3.1 of where the Modes field is used to identify and select specific communication capabilities. At the same time, the Modes field is recognized and used as an extension mechanism . The new feature requires a new flag, Direct Loss Measurement flag, to identify the ability of both Session-Sender and Session-Reflector to perform direct loss measurement, and to support the new Session-Sender packet format and the new Session-Reflector packet format in the TWAMP-Test protocol. See Section 6 for details on the assigned bit position.

The Server sets the Direct Loss Measurement flag in the Modes field of the Server Greeting message to indicate its capability and willingness to perform it. If the Control-Client agrees to perform direct loss measurement on some or all test sessions invoked with this control connection, it MUST set the Direct Loss Measurement flag in the Modes field in the Setup Response message.

The TWAMP-Test protocol is similar to the OWAMP test protocol with the exception that the Session-Reflector transmits test packets to the Session-Sender in response to each test packet it receives. TWAMP, see Section 4 of , defines two additional test packet formats for packets transmitted by the Session-Reflector. The appropriate format depends on the security mode chosen. The new mode specified in this document adds counter(s) of IP traffic packets into each test packet format. When the Server and Control-Client have agreed to use the direct loss measurement mode during control connection setup, then the Session-Sender and the Session-Reflector SHOULD all conform to the requirements of that mode, as identified below.

Formats of the test packet transmitted by the Session-Sender in unauthenticated, authenticated, and encrypted modes have been defined in Section 4.1.2 of (as indicated in Section 4.1.2 of ). For the Session-Sender that supports direct loss measurement, these formats are displayed in Figures 1 and 2. For unauthenticated mode:

For authenticated and encrypted modes:

The Sender Tx Counter (S_TxC) is set to the number of IP packets of the particular monitored flow transmitted towards the Reflector. Section 4 provides operational guide on how to determine the scope of IP traffic packets that need to be counted. Note that the Sender test packets are not counted. In authenticated and encrypted modes, the S_TxC is followed by a new 12 octets MBZ (MUST be zero) field to make it 16-octet aligned, which is required for authentication and encryption. The intention of embedding S_TxC in the Session-Sender test packets is for the Session-Sender to calculate direct loss of IP traffic, and the loss calculation algorithm is described in Section 3.3. The new direct loss measurement mode defined in this document and the two extended TWAMP modes defined in can be selected simultaneously. When the Symmetrical Size mode defined in is also selected, S_TxC SHOULD be embedded in the Session-Sender Packet formatted in Section 5.1.4 of , with the same position as depicted in Figure 1. When the Reflect Octets mode defined in is also selected, S_TxC SHOULD be embedded in the Session-Sender Packet formatted in Section 5.1.2 of , with the same position as depicted in Figure 1. When both the Symmetrical Size mode and the Reflect Octets mode are also selected, S_TxC SHOULD be embedded in the Session-Sender Packet formatted in Section 5.1.5 of , with the same position as depicted in Figure 1.

Formats of the test packet transmitted by the Session-Reflector in unauthenticated, authenticated, and encrypted modes have been defined in Section 4.2.1 of . For the Session-Reflector that supports direct loss measurement, these formats are displayed in Figures 3 and 4. For unauthenticated mode:

For authenticated and encrypted modes:

The Sender Tx Counter (S_TxC) is copied from the received Sender Test Packet. The Reflector Rx Counter (R_RxC) is set to the number of IP traffic packets received by the Reflector. Section 4 provides operational guide on how to determine the scope of IP traffic packets that need to be counted. Note that the Sender test packets are not counted. The Reflector Tx Counter (R_TxC) is set to the number of IP traffic packets transmitted towards the Sender. Section 4 provides operational guide on how to determine the scope of IP traffic packets that need to be counted. Note that the Reflector test packets are not counted. In authenticated and encrypted modes, the S_TxC, R_RxC and R_TxC are respectively followed by a new 12 octets MBZ (MUST be zero) field to make it 16-octet aligned, which is required for authentication and encryption. The intention of embedding S_TxC, R_RxC and R_TxC in the Session-Reflector test packets is for the Session-Sender to calculate direct loss of IP traffic, and the loss calculation algorithm is described in Section 3.3. When the Symmetrical Size mode defined in is also selected, basing on what's specified in Section 5.2.2 of , the Session-Reflector packet format would follow Figure 3. When the Reflect Octets mode defined in is also selected, S_TxC, R_RxC and R_TxC SHOULD be embedded in the Session-Reflector Packet formatted in Section 5.2.1 of , with the same position as depicted in Figure 3. When both the Symmetrical Size mode and the Reflect Octets mode are also selected, S_TxC, R_RxC and R_TxC SHOULD be embedded in the Session- Reflector Packet formatted in Section 5.2.1 of , with the same position as depicted in Figure 3.

Upon receiving a Reflector Test Packet, the Session-Sender uses the following values to make loss calculation: o Received S_TxC, R_RxC and R_TxC values embedded in Reflector Test Packet and local counter S_RxC value at the time this Reflector Test Packet was received. These values are represented as S_TxC[n], R_RxC[n], R_TxC[n], and S_RxC[n], where n is the reception time of the current Reflector Test Packet. o Previous Received S_TxC, R_RxC and R_TxC values embedded in Reflector Test Packet and local counter S_RxC value at the time the previous Reflector Test Packet was received. These values are represented as S_TxC[n-1], R_RxC[n-1], R_TxC[n-1], and S_RxC[n-1], where n-1 is the reception time of the previous Reflector Test Packet. The formulas for calculating the far-end loss, near-end loss, far-end loss rate and near-end loss rate are as following: o Far-end loss: F_Loss[n-1,n] = (S_TxC[n]-S_TxC[n-1])-(R_RxC[n]-R_RxC[n-1]) o Near-end loss: N_Loss[n-1,n] = (R_TxC[n]-R_TxC[n-1])-(S_RxC[n]-S_RxC[n-1]) o Far-end loss rate: F_LossRate[n-1,n] = F_Loss[n-1,n]/(S_TxC[n]-S_TxC[n-1]) o Near-end loss rate: N_LossRate[n-1,n] = N_Loss[n-1,n]/(R_TxC[n]-R_TxC[n-1]) Here far-end means the direction from the Session-Sender to the Session-Reflector and near-end means the direction from the Session-Reflector to the Session-Sender.

In order to make meaningful loss measurement, in general, the scope of IP traffic packets that need to be counted, i.e. the IP traffic packets counting rules, should be provisioned before starting Test Sessions, and the provisioned arguments usually include ingress port, source IP address, destination IP address, IP DSCP and UDP port number. For the scenarios where the exact source/destination IP address and IP DSCP of IP traffic can be known, such as mobile backhaul, the Test Packets should use the same source/destination IP address and IP DSCP as IP traffic, and it shall result in more accurate measurements.

Use of direct loss measurement in a test session does not appear to introduce any additional security threat to hosts that communicate with TWAMP as defined in . The security considerations that apply to any active measurement of live networks are relevant here as well. See the Security Considerations sections in and .

In the TWAMP-Modes registry defined in , a new Direct Loss Measurement Capability is requested from IANA as follows: Bit Pos Description Semantics Definition Reference 10 Direct Loss Measurement Capability Section 2 This Document

The authors would like to thank Greg Mirsky and Guo Jun for their valuable comments.