OAM monitoring and reporting

General configuration command options influence probe frequency, the delay metric type to monitor, and retention of the delay measurement last reported.

The notification process uses the reporting command and threshold configurations. By default, reporting is enabled and the routing engine is informed of threshold events. At least one threshold must be configured to report to the routing engine. Disabling reporting allows the function to execute but prevents the reporting of threshold events to the routing engine. If this value is toggled and previously recorded, the reported value is cleared and the process returns to the initial reporting phase.

The probe frequency, configured using the interval command, defines the transmission rate of the test packet.

The delay command configures the delay metric (minimum, maximum, or average) that is used for comparison against any configured thresholds. This metric is the same for both types of measurement windows, the sample-window and aggregate-sample-window.

The unidirectional-measurement CLI command specifies the method used to compute the unidirectional delay. If the clock synchronization between nodal clocks used by the OAM timestamp function is not synchronized to near exact accuracy, the derived option must be used. Specifying this option calculates the unidirectional measurement using the roundtrip delay divided by two computation. If synchronization can meet near exact accuracy, the actual option can be used. Specifying this option calculates the forward delay using the forward direction timestamps, T2-T1 computation.

When the operational state of the link measurement test transitions to down, the OAM function instructs the routing engine to clear the last reported delay value at the expiration of the last-reported-delay-hold. A previously reported delay is considered valid for the duration of this period and is cleared if the timer reaches zero. If the operational state returns to up before the timer expires, no action is taken to clear the previous value. The counter is reset to the configured value, waiting for the next operational down event.

The operation state for the interface delay test is determined by administrative actions and system events. The administrative events that determine the operational state are:

• administratively disabling the measurement template associated with the interface

• administratively disabling the active IP protocol that is being used to generate the test packet under the following context.

  configure router interface if-attribute delay dynamic-delay

The resource issue system events that drive the operational state are:

• unavailability of the UDP port

• internal errors

The aging timer does not start a count to zero for failure conditions that do not affect the interface delay test operational state. The delay measurement last reported is maintained when conditions external to the interface delay test, such as fault conditions on the port, IP interface, routing changes, and so on, occur. If the last-reported-delay-timer is set to zero, previously reported delay values from that test are cleared when the operational state changes to down without any additional time.

The collection and reporting parameters define the length of the sample-window and aggregate-sample-window and the thresholds that trigger reporting. Two measurement windows are provided to support use cases that require a reporting hierarchy. Both measurement windows include the same configuration options. The threshold values determine when the measurement window is able to update the reported delay value.

The measurement windows use the multiplier command to determine the length of time that the measurement window remains open. The sample window length is multiples of the interval. This window stores the results of individual test probes for a total length of the interval multiplied by the multiplier value. The aggregate sample window multiplier length is the number of sample windows. This window stores the number of results passed from individual sample windows. In the aggregate sample window, the minimum, maximum, and average calculations are based on the results received from the sample window. For example, if the delay metric of interest is the average, the aggregate sample is a collection of averages passed from the sample window. The reporting in the aggregate sample window is as follows:

• The minimum is the minimum value for all the averages received.

• The maximum is the maximum value from all the averages received.

• The average is the average of all the averages received.

The comparison to thresholds and reporting decisions occurs at the end of the measurement window if it completes without termination and is deemed integral based on the window-integrity command configuration. Integrity is a percentage-based calculation that determines the number of samples that must be present in the measurement window for that window to be considered integral. If the number of samples in the window equals or exceeds the number of required samples, the result produced is treated as representative and follows normal post-measurement window processing. However, if the number of samples in the window does not achieve integrity, the result is not considered representative and is only recorded for historical purposes, but is otherwise ignored and not processed. By default, integrity checking is disabled and all results from a measurement window are treated as integral and compared to the configured thresholds.

There are two types of thresholds:

• a microsecond increase or decrease, configured using the absolute command

• a percentage increase or decrease, configured using the relative command

Thresholding compares the measurement window result to the delay measurement last reported at the end of the successful (completed) measurement window. Reporting is on a per-threshold, per-measurement window basis. If multiple thresholds are reached for a completed measurement window, only one threshold triggers an update to the routing engine. The reporting trigger is recorded with a structure of <Window‟Threshold”threshold>. For example, SampleThrehsoldAbsolute indicates that the absolute threshold in the sample window triggered the report. The report is accompanied by a timestamp and last reported value. When a sample window triggers a new delay measurement, the current aggregate sample window is restarted, preempting any possible reporting from the aggregate sample window. This allows both measurement window types to use the delay measurement last reported as the new benchmark.

Configuration of the measurement windows depends on the specific solution requirements. The two measurement windows collect information regardless of configured thresholds. Both types of measurement windows support their own threshold and integrity configuration. By default, thresholds for both measurement windows are disabled; that is, neither window can report any values to the routing engine.

The protocol parameters influence the format of the test packet, processing, QoS handling, and IPv6 discovery, which influences the return path.

TWAMP Light, also called Simple Two-way Activation Monitoring Protocol (STAMP), is the test packet used to gather IP link measurement delay information. The link measurement request source is the session-sender.

configure router twamp-light reflector

The session-sender and the session-reflector must agree on the UDP port used to identify TWAMP Light test packets. The SR OS configuration of the session-sender (configured using the dest-udp-port command) and session-reflector (configured using the udp-port command) must match.

The TWAMP Light test packet was first introduced to support the Network Time Protocol (NTP) encoding of the timestamp in the packet. Updates since the initial standardization of TWAMP Light support the use of the truncated Precision Time Protocol (PTP) timestamp format. A bit in the TWAMP Light test packet header is repurposed to indicate the timestamp format encoded by the session-sender and the session-reflector.

This change leads to some interoperability considerations. The timestamp format should be consistent with the session-sender and session-reflector behavior. The link measurement session-sender can be configured to encode NTP (default) or PTP and set the ‟z-bit” in the Error Estimate field accordingly. This bit indicates the timestamp format carried in the packet. If the session-reflector sets the ‟z-bit” in the Error Estimate field to indicate the timestamp format of the reply, the link measurement session-sender can perform the necessary conversion (format and epoch) to produce the correct results. However, if the session-reflector only reflects the original ‟z-bit” it received from the session-sender and uses a different timestamp format in the packet, the delay calculations are not reliable because of the misinterpretation of the returned timestamp format.

SR OS session-reflectors running Release 21.5 and earlier always reflect the ‟z-bit” received from the session-sender. Regardless of the ‟z-bit”, these session-reflectors always encode an NTP timestamp format in the packet.

When these session-reflectors receive a TWAMP Light test packet with the PTP timestamp format, there is a mismatch between the actual timestamp format and the timestamp it has encoded. There is no mechanism for the session-reflector to detect this mismatch and report the correct delay.

To ensure accurate delay measurements, any session-sender sending TWAMP Light test packets to an SR OS TWAMP Light reflector that is running Release 21.5 and earlier, must use a timestamp format of NTP. Release 21.7 session-reflectors reply in kind for the timestamp format and properly set the timestamp format bit to match the timestamp encoded by the session-reflector.

IPv6 packets arriving with a UDP checksum of zero are discarded. However, recent work in the IETF suggests that selected protocols may register on the local router to accept and process IPv6 packets with a UDP checksum of zero. To provide interoperability, the allow-ipv6-udp-checksum-zero command allows the session-sender and the session-reflector to process IPv6 TWAMP Light test packets that arrive with a UDP checksum of zero. This is specific to the link measurement template session-sender and session-reflector and only for the specific UDP ports for TWAMP Light test packets.

IPv6 destination address discovery allows the discovery of a single directly-connected IPv6 peer. When this option is enabled, a bootstrap function using an ICMPv6 echo request with a destination ff02::2 is generated. When the directly-connected peer responds, the link measurement function uses the source address of the ICMPv6 echo response as the destination address for the link measurement test packets.

The process has four main components:

• Enabling the functions using admin-enable, set to disabled by default.
• Configuring the discovery-interval value. This is the initial timer used by the discovery process to discover the peer. This interval is used for the duration of the discovery-timer.
• Implementing the discovery phase. If the timer expires or the peer is discovered before the expiration of the discovery-timer, the process reverts back to the update-interval.
• Implementing the update-interval. This is an optional maintenance component of the peer address that runs at a slower rate. This option is not required and can be disabled in environments where the peer address is unlikely to change. If the peer is not discovered during the discovery-timer and with the update-interval disabled, the peer fails to be discovered. Disable and then enable the IPv6 protocol using the following context to restart the discovery process.

  configure router interface if-attribute delay dynamic twamp-light ipv6

By default, the TWAMP light reflection and the base TWAMP Light session-reflectors use routing to return the response packet to the session-sender. There are instances when it may be beneficial to be selective about the IP interface used to return the packet. For example, when multiple tests are executed on different interfaces between the same pair of nodes, and using non-directly connected interface addresses, and ECMP exists between the two nodes and the unidirectional-measurement actual command is used. In this case, the return-path link command can be configured under the measurement-template twamp-light context.

This includes the return path TLV and link sub TLV in the test packet. This configuration instructs the session-reflector to send the response out to the same IP interface on which it was received. The destination IP address for the response packet must be installed in the forwarding table and reachable from that interface. If the routing engine determines that the prefix is not reachable from that interface, the response packet is dropped at the reflector.

SR OS supports the configuration modification of active measurement templates. That is, administratively disabling a measurement template that IP interfaces are actively referencing is not required. Modifying existing parameters causes interface delay tests that were referencing the modified template to terminate the current sample and aggregate measurement windows, and to start new measurement windows using the updated template parameters. The previous historical results are maintained, but the State field of the measurement window coinciding with the change indicates ‟Terminated”. Changing the description or the last-reported-delay-hold configuration does not cause a termination of the current sample and aggregate measurement windows.

A measurement template cannot be removed if interfaces are referencing that template.

The following show commands are available to display the link measurement templates:

• The show>test-oam>link-measurement measurement-template reports the measurement templates and the number of total and active interface references.

• The show>test-oam>link-measurement measurement-template-using command reports the measurement template, associated router interfaces and the protocols.

• The show>test-oam>link-measurement measurement-template template-name command reports the specific measurement template and the associated configuration parameters, with the number of active interfaces and total references to this templates.

To enable dynamic measurements for the interface, the user must configure a link measurement template and enable the test protocol using the ipv4 or ipv6 command. The link measurement template does not include interface-specific requirements, such as the IP protocol encapsulating the test packet or IP source and destination addressing. It is possible to enable the IPv4 or IPv6 protocol under the dynamic twamp-light context without including any source or destination information.

When the IPv4 protocol is enabled with no addressing configured, the source address is automatically assigned to the primary IPv4 address of the IP interface. The destination address is automatically assigned if the primary IPv4 address has a prefix length of 30 or 31. In other cases, such as shorter prefix lengths or unnumbered interfaces, the destination address cannot be resolved and must be configured manually. The source and destination commands take precedence over the auto-assigned addressing; the IPv4 addresses must be unicast.

IPv4 auto-assigned addressing is not updated for operationally up interface delay tests when the IP addressing associated with that interface is changed. Nokia suggests the following options to update the auto-assigned addressing:

• administratively disable and enable the protocol used for the interface delay test

• disable and enable the IP interface under which the IP address has changed

configure test-oam link-measurement measurement-template twamp-light ipv6-destination-discovery

The source and destination can be globally routable unicast addresses of the link identifying the directly-connected peers or the link local addresses connecting the peers. The link local address must follow the format fe80::/64, as described in RFC 4291, IP Version 6 Addressing Architecture.

TWAMP Light test packets consult the routing table to determine how to reach the destination. The test should be configured to use local IP interface source and directly connected IP peer interface destination addressing to ensure the packet egresses and returns over the same IP interface. The destination must be reachable from the IP interface where the interface delay test is configured. Using indirect IP addressing, such as unnumbered interfaces, does not guarantee that the measurement is reporting the delay for the expected interface.

Only one protocol, IPv4 or IPv6, can be enabled for an interface delay test at any time.

Interfaces defined as loopback do not support interface delay tests and are an invalid interface type. The configuration exists under these interfaces, but a detectable transmission error prevents the sending of packets.

The system interface does not support interface delay tests and the configuration is hidden.

When the link measurement template is assigned to an IP interface, the audit process determines the operational state of the test. The interface delay test transitions to operationally up if the following conditions are met:

• the associated measurement template is administratively enabled

• there is an administratively enable test protocol, configured using the ipv4 or ipv6 command

• the system resources are available to start the test

Further validation determines if there are any underlying conditions that are considered detectable transmission errors, which are listed in the following table.

When all audit conditions successfully pass, the delay collection begins. When no thresholds are configured, the test collects delay information as history, but without at least one configured threshold value, reporting updates to the routing engine are disabled. If at least one threshold is configured, the interface enters the first report phase. Because no previous delay value has been reported, the first measurement window with a configured threshold that completes with integrity triggers the delay measurement report. After this benchmark is set, all subsequent thresholds use the delay measurement last reported as the comparison.

Active interface delay tests retain 50 sample windows and 20 aggregate sample windows in history. The current measurement windows and historical results are not maintained across CPM switchovers. The delay measurement last reported is maintained after a CPM switchover to retain the baseline. The interface does not enter the first reporting phase following a CPM switchover.

Several states exist to indicate the state of the measurement window:

• InProgress

  The measurement window is open and collecting results.

• Completed

  This state indicates natural completion of the delay test.

• Terminated

  A configuration change to the measurement template being referenced, or an administrative action or system event caused the operational state to change to down, consequently preempting and causing an abnormal termination.

• SwReported

  The sample window has triggered a delay measurement last report.

• AswReported

  The aggregate sample window has triggered a delay measurement last report.

SR OS supports the configuration of static and dynamic delay measurement, and provides a configuration parameter to determine precedence. The dynamic delay measurements use the link measurement templates and interface delay test packets to gather results. The static delay is a configured value. Both static delay and dynamic delay can be configured under the same interface. Both are reported to the routing engine based on their own rules. The routing engine must be informed on how to interpret this condition and which metric to advertise. The delay selection, configured using the delay-selection command, provides four options to customize the handling. The configuration options allow for only one to be considered (using the static or dynamic options) or which is to be preferred should both exist (using the static-preferred or dynamic-preferred options). There may be an amount of time between the interface initialization and the reporting of a valid dynamic delay value. This case may require some deployments to configure a static delay value to fill the time gap while waiting for the link measurement first report. In this case, preferring dynamic allows the routing engine to advertise the static value until the dynamic delay report is made.

The user can use show commands to display the link measurement templates.

Use the following command with the detail, aggregate, sample, or debug-counters options to display the interface-specific delay test information, including:

• operational data
• reporting information
• historical results for sample and aggregate sample windows
• count of unexpected conditions for response packets

show test-oam link-measurement interface

Use the following command to report a list of all interfaces that are configured with link-measurement.

show test-oam link-measurement interfaces

The report includes all the basic operational summaries, including:

• interface name
• operational state
• protocol
• errors
• reporting
• delay metric of interest
• last delay
• timestamp of the last delay

General configuration command options influence probe frequency and the administrative state of the template.

The probe frequency, configured using the interval command, defines the transmission rate of the test packet.

The operation state for the interface delay test is determined by administrative actions and system events. The administrative events that determine the operational state are:

• administratively disabling the measurement template associated with the interface

• administratively disabling the active IP protocol that is being used to generate the test packet under the following context.

  configure router interface if-attribute delay dynamic-delay

The resource issue system events that drive the operational state are:

• UDP port unavailability

• internal errors

The collection and reporting parameters define the length of the sample-window.

The measurement window uses the multiplier command to determine the length of time that the measurement window remains open. The sample window length is multiples of the interval. This window stores the results of individual test probes for a total length of the interval multiplied by the multiplier value.

The protocol parameters influence the format of the test packet, processing, and QoS handling. These tests are expected to be executed directly on connected peers for IP interfaces that have a LAG component, and all performance information passed to a northbound system for processing. The configurable options available for link measurement on LAG are a subset of those available for link measurement.

TWAMP Light is the test packet used to gather IP link measurement delay information for the LAG member ports. The link measurement request source is the Session-Sender.

configure router twamp-light reflector

The reflector, which is referred to as the Session-Reflector, is the responder to the request. Processing the newly defined micro-session ID fields in the TWAMP Light test frame is not enabled by default on the Session-Reflector. Use the following command to enable and disable the reflectors ability to process these frame types:

• MD-CLI

  configure router "Base" twamp-light reflector lag-ip-measurement true

• classic CLI

  configure router "Base" twamp-light reflector lag-ip-measurement

The Session-Sender and the Session-Reflector must agree on the UDP port used to identify TWAMP Light test packets. The SR OS configuration of the Session-Sender (configured using the dest-udp-port command) and Session-Reflector (configured using the udp-port command) must match.

The TWAMP Light test packet was first introduced to support the NTP encoding of the timestamp in the packet. Updates since the initial standardization of TWAMP Light support the use of the truncated PTP timestamp format. A bit in the TWAMP Light test packet header is repurposed to indicate the timestamp format encoded by the Session-Sender and the Session-Reflector.

This change leads to some interoperability considerations. The timestamp format should be consistent with the Session-Sender and Session-Reflector behavior. The link measurement Session-Sender can be configured to encode NTP (default) or PTP and set the ‟z-bit” in the Error Estimate field accordingly. This bit indicates the timestamp format carried in the packet. If the Session-Reflector sets the ‟z-bit” in the Error Estimate field to indicate the timestamp format of the reply, the link measurement Session-Sender can perform the necessary conversion (format and epoch) to produce the correct results. However, if the Session-Reflector only reflects the original ‟z-bit” it received from the Session-Sender and uses a different timestamp format in the packet, the delay calculations are not reliable because of the misinterpretation of the returned timestamp format.

SR OS Session-Reflectors running Release 21.5 and earlier always reflect the ‟z-bit” received from the Session-Sender. Regardless of the ‟z-bit”, these Session-Reflectors always encode an NTP timestamp format in the packet.

When these Session-Reflectors receive a TWAMP Light test packet with the PTP timestamp format, there is a mismatch between the actual timestamp format and the timestamp it has encoded. There is no mechanism for the Session-Reflector to detect this mismatch and report the correct delay.

To ensure accurate delay measurements, any Session-Sender sending TWAMP Light test packets to an SR OS TWAMP Light reflector that is running Release 21.5 and earlier, must use a timestamp format of NTP. Release 21.7 Session-Reflectors reply in kind for the timestamp format and properly set the timestamp format bit to match the timestamp encoded by the Session-Reflector.

IPv6 packets arriving with a UDP checksum of zero are discarded. However, recent work in the IETF suggests that selected protocols may register on the local router to accept and process IPv6 packets with a UDP checksum of zero. To provide interoperability, the allow-ipv6-udp-checksum-zero command allows the Session-Sender and the Session-Reflector to process IPv6 TWAMP Light test packets that arrive with a UDP checksum of zero. This is specific to the link measurement template Session-Sender and Session-Reflector and only for the specific UDP ports for TWAMP Light test packets.

SR OS supports the configuration modification of active measurement templates. That is, administratively disabling a measurement template that IP interfaces are actively referencing is not required. Modifying existing parameters causes interface delay tests that are referencing the modified template to terminate the current sample and aggregate measurement windows, and to start new measurement windows using the updated template parameters. The previous historical results are maintained, but the state field of the measurement window coinciding with the change indicates ‟Terminated”.

A measurement template cannot be removed if interfaces are referencing that template.

The following command reports the measurement templates and the number of total and active interface references.

show test-oam lag-ip-measurement lag-ip-measurement-template

To enable dynamic measurements for the interface, the user must configure a link measurement template and enable the test protocol using the ipv4 or ipv6 command. The link measurement on a LAG template does not include interface-specific requirements, such as the IP protocol encapsulating the test packet or IP source and destination addressing. It is possible to enable the IPv4 protocol under the dynamic twamp-light context without including any source or destination information.

When the IPv4 protocol is enabled with no addressing configured, the source address is automatically assigned to the primary IPv4 address of the IP interface. The destination address is automatically assigned if the primary IPv4 address has a prefix length of 30 or 31. In other cases, such as shorter prefix lengths or unnumbered interfaces, the destination address cannot be resolved and must be configured manually. The source and destination commands take precedence over the auto-assigned addressing; the IPv4 addresses must be unicast.

IPv4 auto-assigned addressing is not updated for operationally up interface delay tests when the IP addressing associated with that interface is changed. Nokia recommends the following options to update the auto-assigned addressing:

• administratively disable and enable the protocol used for the interface delay test

• disable and enable the IP interface under which the IP address has changed

The IPv6 protocol source requires the configuration of the destination IP address. There is no discovery of the peer address.

The source and destination can be globally routable unicast addresses of the link identifying the directly-connected peers or the link local addresses connecting the peers. The link local address must follow the format fe80::/64, as described in RFC 4291, IP Version 6 Addressing Architecture.

TWAMP Light test packets consult the routing table to determine how to reach the destination. The test should be configured to use local IP interface source and directly connected IP peer interface destination addressing to ensure the packet egresses and returns over the same IP interface. The destination must be reachable from the IP interface where the interface delay test is configured. Using indirect IP addressing, such as unnumbered interfaces, does not guarantee that the measurement is reporting the delay for the expected interface.

Only one protocol, IPv4 or IPv6, can be enabled for an interface delay test at any time.

Interfaces defined as loopback do not support interface delay tests and are an invalid interface type. The configuration exists under these interfaces, but a detectable transmission error prevents the sending of packets.

The system interface does not support interface delay tests and the configuration is hidden.

When the link measurement on a LAG template is assigned to an IP interface, the audit process determines the operational state of the test. The interface delay test transitions to operationally up if the following conditions are met:

• the associated measurement template is administratively enabled

• there is an administratively enabled test protocol configured using the ipv4 or ipv6 command

• system resources are available to start the test

Further validation determines if there are any underlying conditions that are considered detectable transmission errors. The following table lists these errors.

Each LAG member port is checked for the operational state. Individual port operational conditions do not impact the operation state of the overall session. However, individual port states are reported. When the session is operationally down, the port state represents the last available port state when the session was operational.

When all audit conditions for the session successfully pass, the delay collection begins on LAG member ports that are operationally up.

Active delay tests retain 50 sample windows in history. The current measurement windows and historical results are not maintained across CPM switchovers.

Several states exist to indicate the state of the measurement window:

• InProgress

  The measurement window is open and collecting results.

• Completed

  This state indicates natural completion of the delay test.

• Terminated

  A configuration change to the referenced measurement template, or an administrative action or system event caused the operational state to change to down, consequently preempting and causing an abnormal termination.

  Results are computed and published after the end of the sample window. No results are presented while the session is in progress.

show test-oam lag-ip-measurement interfaces

When configured, this command includes the following information:

• interface name
• operational state
• configured IP protocol
• detectable transmission errors for the session

The report includes all the basic operational summaries, including:

• interface name
• operational state
• protocol
• errors
• number of LAG member ports under the test

The following command displays a summary of the IP interface.

show test-oam link-measurement interface 

The report provides a comprehensive view of the IP interface session and ports operational information, including:

• session
  • LAG template name
  • operational state
  • LAG reference
  • LAG member count
  • source and destination IP and UDP
  • errors
  • number of lag member ports under test
• ports
  • port identifier
  • errors
  • summary of latest completed results with timestamp

The following command displays a summary about the individual LAG member ports.

show test-oam link-measurement interface port

The report provides detailed information about the individual LAG member port under test and a summary of the historical results:

• port information:
  • sender micro-session ID
  • reflector micro-session ID
  • errors and discards