TWAMP Light was introduced as part of RFC 5357, A Two-Way Active Measurement Protocol (TWAMP), Appendix I (Informational). The RFC appendix defined a single-ended test without the requirement to use the TCP control channel over which the Control-Client and server negotiate test parameters. Using this approach, configuration on both entities, the Session-Sender and the Session-Reflector, replaces the control channel and provides the application-specific handling information required to launch and reflect test packets. In other words, TWAMP Light uses the TWAMP test packet for gathering IP performance information, but eliminates the need for the TWAMP TCP control channel. However, not all negotiated control parameters are replaced with local configuration. For example, QoS parameters communicated over the TWAMP control channel are replaced with a reply-in-kind approach for TWAMP Light. The reply-in-kind model reflects back the received QoS parameters, which can be influenced by the QoS policies of the Session-Reflector.
This informational work formed the baseline for standardization of TWAMP Light by RFC 8762, Simple Two-Way Active Measurement Protocol (STAMP). The STAMP standard defined by RFC 8762 is backward compatible, as described in the RFC 5357 appendix. As the STAMP work in the IETF continues to evolve, the backward compatibility has remained largely unchanged. However, RFC 8972, Simple Two-Way Active Measurement Protocol Optional Extension, introduces advanced capabilities to the base version of the protocol. This creates areas to consider.
The handling of some functions that were open to interpretation in the original TWAMP Light appendix is formalized in RFC 8972. To properly handle these mismatches, the SR OS uses a function that allows the user to define the wanted behavior for the Session-Reflector. The validation configuration options are performed, and inconsistent configuration based on protocol handling is blocked.
The following describes PDU padding and the identification of STAMP TLVs.
The TWAMP Light test packet request and response sizes are asymmetrical by default. The Session-Sender packet and the Session-Reflector packets are different sizes. To allow for symmetrical packets on the wire and packet size manipulation, the Session-Sender can configure the pad-size octets command to increase the size of the packet. These octets are added directly to the base packet. The default pattern of the padding is all zeros which can be changed using the pattern command.
The STAMP packet request and response sizes are symmetrical by default. RFC 8762 defines a structured packet that ensures this behavior. To allow for general packet size manipulation, the STAMP Optional Extensions RFC 8972 defines a PAD TLV. This TLV is added after the base packet. STAMP padding uses the pad-tlv-size octets command to increase the size of the packet. An all-zero PAD pattern must be used for the PAD TLV.
The Session-Reflector uses configuration option type twamp-light | stamp to determine its processing behavior for the test packet received from the Session-Sender. For backward compatibility, the default processing behavior is twamp-light. This type performs no TLV processing, treating any non-base packet octets as padding. If the required behavior for the Session-Reflector is to parse and process STAMP TLVs, type stamp must be used. Using this configuration, the Session-Reflector can accommodate both TWAMP Light and STAMP Session-Senders, processing the packet based on the TLV rules defined by the STAMP Optional Extensions RFC 8972. Any Session-Sender that is transmitting TWAMP Light-formatted test packets with additional padding must use an all-zero pattern to avoid ambiguity on the Session-Reflector.
SR OS was an early adopter of IP Performance Measurement (IP PM) under the OAM Performance Monitoring (OAM-PM) architecture implementing TWAMP Light RFC 5357 Appendix I behavior. However, subsequent features introduced to the SR OS have adopted the standardized version STAMP and STAMP Optional Extensions.
In Link Measurement, the Session-Sender uses STAMP formatted packets.
In OAM-PM, the Session-Sender uses TWAMP Light formatted packets.