TWAMP Light is an optional model included in the TWAMP standard RFC5357 that uses standard TWAMP test packets but provides a lightweight approach to gathering ongoing IP delay and synthetic loss performance data for base router and per VPRN statistics. Full details are described in Appendix I of RFC 5357 (Active Two Way Measurement Protocol). The SR OS implementation supports the TWAMP Light model for gathering delay and loss statistics.
For TWAMP Light, the complete TWAMP model is replaced with a simple session-sender session-reflector.
TWAMP Light maintains the TWAMP test packet exchange but eliminates the TWAMP TCP control connection with local configurations; however, not all negotiated control parameters are replaced with local configuration. For example, CoS parameters communicated over the TWAMP control channel are replaced with a reply-in-kind approach. The reply-in-kind model reflects back the received CoS parameters, which are influenced by the reflector’s QoS policies.
The reflector function is configured under the config>router>twamp-light command hierarchy for base router reflection, and under the config>service>vprn>twamp-light command hierarchy for per VPRN reflection. The TWAMP Light reflector function is configured per context and must be activated before reflection can occur; the function is not enabled by default for any context. The reflector requires the operator to define the TWAMP Light UDP listening port that identifies the TWAMP Light protocol and the prefixes that the reflector accepts as valid sources for a TWAMP Light request. Before Release 13.0r4, if the configured TWAMP Light reflector UDP listening port was in use by another application on the system, a minor OAM message was presented indicating the UDP port was unavailable and that activation of the reflector is not allowed.
If the source IP address in the TWAMP Light packet arriving on the responder does not match a configured IP address prefix, the packet is dropped. Multiple prefix entries may be configured per context on the responder. Configured prefixes can be modified without shutting down the reflector function. An inactivity timeout under the config>oam-test>twamp>twamp-light command hierarchy defines the amount of time the reflector keeps the individual reflector sessions active in the absence of test packets. A responder requires CPM3 and beyond hardware.
Launching TWAMP Light test packets is under the control of the OAM Performance Monitoring (OAM-PM) architecture and therefore adheres to those rules. This functionality is not available through interactive CLI or interactive SNMP, it is only available under the OAM-PM configuration construct. OAM-PM reports TWAMP Light delay and loss metrics. The OAM-PM architecture includes the assignment of a Test-ID. This protocol does not carry the 4-byte test ID in the packet. This is for local significance and uniformity with other protocols under the control of the OAM-PM architecture.
The OAM-PM construct allows various test parameters to be defined. These test parameters include the IP session-specific information which allocates the test to the specific routing instance, the source and destination IP address, the destination UDP port (which must match the UDP listening port on the reflector), the source UDP port and a number of other parameters that allow the operator to influence the packet handling. The source UDP port should only be configured when TWAMP distributed mode is being deployed. The probe interval and TWAMP Light packet padding size can be configured under the specific session. The pad size, the size of the all 0's pad, can configured to ensure that the TWAMP packet is the same size in both directions. The session-sender role facilitated by the OAM-PM TWAMP Light testing only sets the multiplier bits in the Error Estimate field contained in the TWAMP test packet. The 8-bit multiplier field is set to 00000001. The preceding 8 bits of the Error Estimate field composed of S (1 bit - Time Sync), Z (1 bit MBZ) and Scale (6 bits) are set to 0.
TWAMP Session Reflector and TWAMP-Light through the OAM-PM infrastructure allow for the configuration of the allow-ipv6-udp-checksum-zero command to accept and process IPv6 TWAMP test packets that arrive with a UDP checksum of zero.
TWAMP Test uses a single packet to gather both delay and loss metrics. This means there is special consideration over those approaches that use a specific tool per metric type.
In the TWAMP-Light case the interval parameter, which defines the probe spacing, is a common option applicable to all metrics collected under a single session. This requires the parameter to be removed from any test specific configurations, like the timing parameter associated with loss, specifically availability. Packet processing marks all fields in the PDU to report both delay and loss. The record-stats option can be used to refine which fields to process as part of the OAM-PM architecture. The default collection routine includes delay field processing only, record-stats delay. This is to ensure backward compatibility with previous releases that only supported the processing delay fields in the PDU. Enabling the processing of loss information requires the modification of the record-stats parameter. Adding loss to an active test requires the active test to be shutdown, modified and activate with the no shutdown command.
The record-stats setting do not change the configuration validation logic when a test is activated with the no shutdown command. Even if the loss metrics are not being processed and reported the configuration logic must ensure that the TWAMP test parameters are within the acceptable configuration limits, this includes default loss configuration statements. An operator has the ability to configure a TWAMP Light interval of 10s (10000ms) and record only delay statistics. The default timing parameter, used to compute and report availability and reliability, should allow for the activation of the test without a configuration violation. This requires the frame-per-delta-t frames default value of 1. An availability window cannot exceed 100s regardless of the record-stats setting. Computing the size of the availability window is a product of (interval*frames-per-delta-t*consec-delta-t).
The statistics display for the session with show all statistics that are being collected based on the record-stats configuration. If either of the metrics is not being recorded the statistics display ‟NONE” for the excluded metrics.
Multiple tests sessions between peers are allowed. These test sessions are unique entities and may have different properties. Each test generates TWAMP packets specific to their configuration.
TWAMP Light is supported on deployments that use IPv4 or IPv6 addressing, which may each have their own hardware requirements. All IP addressing must be unicast. IPv6 addresses cannot be a reserved or a link local address. Multiple test sessions may be configured between the same source and destination IP endpoints. The tuple Source IP, Destination IP, Source UDP, and Destination UDP provide a unique index for each test point.
The OAM-PM architecture does not validate any of the TWAMP Light test session information. A test session is allowed to be activated regardless of the validity of session information. For example, if the source IP address configured is not local within the router instance that the test is allocated, the session controller starts sending TWAMP Light test packets but does not receive any responses.
See OAM Monitoring and Reporting for more information about the integration of TWAMP Light and the OAM-PM architecture, including hardware dependencies.