OAM monitoring and reporting

Multiplier

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.

Window integrity

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 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.

Threshold

The following types of thresholds are supported.

• absolute: a specified increase or decrease in microseconds.

• relative: a specified percentage increase or decrease.

When LAG micro-sessions are disabled, thresholding compares the completed measurement-window result for the interface’s single session with the delay measurement most recently reported at the end of a successful measurement window. Threshold evaluation and reporting occur a single time per threshold, per completed measurement window. If multiple thresholds are met for the same measurement window, only one threshold triggers an update to the routing engine.

When LAG micro-sessions are enabled, each LAG member session maintains its own sample-window and aggregate-sample-window. When a member’s sample window completes and meets the window-integrity requirements, its result is added to an internal comparison table containing the latest integral completed result for each member. The configured delay metric is then calculated across all entries currently in the table and used for threshold comparison. Member sample windows do not need to complete simultaneously.

Results that do not meet the requirements for an integral result are not added to the comparison table. Instead, the member’s entry is set to null. A null entry is used only for threshold comparison and does not, by itself, clear the delay measurement last reported to the routing engine.

A member’s comparison entry is set to null when any of the following conditions occur.

• The configured window-integrity percentage is not achieved.

• Window integrity is not configured and the member receives no responses.

• The member meets the window-integrity requirement, but its LAG member port is operationally down when the sample window closes.

With LAG micro-sessions enabled, a completed sample window can later transition to a reported state, such as sw-reported, when a subsequent comparison identifies that window as the source of a new report. On-change telemetry notifies subscribers when the window state changes.

When a new delay value is reported to the routing engine for a link-measurement interface, the aggregate sample windows for that interface’s measurement context terminate and restart.

With LAG micro-sessions enabled, the routing engine continues to receive a single last-reported dynamic delay value per link-measurement interface. This value is derived from the configured delay metric applied across the LAG member sessions.

Reporting

Reporting is enabled by default and the routing engine is informed of threshold events. The notification process uses the reporting command and threshold configurations. 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 a value was previous reported, the reported value is cleared, and the process returns to the initial reporting phase.

STAMP and TWAMP Light

Support for STAMP using the defined TLVs in RFC9534 and TWAMP Light RFC9533, only the definition of the micro-session-id fields is supported.

The session-reflector function supports STAMP and TWAMP Light processing. When the session sender transmits TWAMP Light PDUs for LAG micro-sessions configure the session reflector must be identify the corresponding fields.

On the session reflector, enable oam stamp session-reflector network-instance twamp-light-extensions lag-micro-sessions true to parse bytes 17–18 and 19–20 as RFC 9533 micro-session identifiers.

When LAG micro-sessions are enabled, each STAMP session uses a unique SSID for each LAG member. STAMP reflectors that support RFC 9534 process micro-session TLVs without additional reflector configuration.

Source UDP port

--{ + candidate shared default }--[  ]--
# info oam ippm
    oam {
        ippm {
            source-udp-port-pools {
                port 64374 {
                    application-assignment oam-pm-ip
                }
            }
        }
    }

IPv6 destination discovery

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-state command.
• Configuring the discovery-interval command. 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 to restart the discovery process.

Return path

By default, the 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 for the return path. 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. In this case, the return-path link command can be configured as true. 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.

IPv4 address auto-discovery

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-ip and destination-ip 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

IPv6 address auto-discovery

oam link-measurement measurement-template ip ipv6-destination-discovery

Session types and operational states

The operational state of a session is influenced by:

• session type

• session administrative state

In a proactive session, the operational state is up when the administrative state is enabled. The operational state is down when the administrative state is disabled. A proactive test session starts immediately after the oam performance-monitoring ip session stamp admin-state command is set to enable. A proactive test session stops immediately after the oam performance-monitoring ip session stamp admin-state command is set to disable. The operational state of a proactive session mirrors the administrative state of the session.

Delay metrics

By default, the average for all delay metrics includes all the results within the measurement interval. However, it is possible to exclude the measurements using exclude-from-average for a specified direction. The results are binned but the delay values included in the exclude option are not included in the average computation.

Loss metrics

SR Linux supports the following loss metrics:

Duration

The measurement interval durations are as follows:

• 1-min

• 5-min

• 15-min

• 1-hour

• 1-day

Boundary type

The boundary-type parameter defines the start of the measurement interval and can be aligned to the local time-of-day clock, with or without an optional offset. By default, the start boundary is clock-aligned without an offset. When this configuration is deployed, the measurement interval establishes non-overlapping time-based windows which complete at the specified time. The boundary-type parameter can be aligned using the test-aligned option, which means that the start of the measurement interval coincides with the activation of the test and the length of the measured interval determines the completion.

Clock aligned

When a boundary is clock-aligned and clock-offset option is configured, a specified amount of time is applied to the measurement interval. Offsets are configured on a per-measurement interval basis and only applicable to clock-aligned measurement intervals. Only offsets less than the measurement interval duration are allowed. The following table lists examples of the start times of each measurement interval.

Test aligned

Although test-aligned approaches may seem beneficial for simplicity, there are some drawbacks that need to be considered. The goal of the time-based and well-defined collection windows allows for the comparison of measurements across common windows of time throughout the network and for relating different tests or sessions. On-demand tests are typically used for troubleshooting or short term monitoring that does not require alignment or comparison to other PM data and may make better use of the test-aligned boundary.

Intervals stored

The statistical data collected and the computed results from each measurement interval are maintained in volatile system memory . The number of intervals stored is configurable per measurement interval. Different measurement intervals have different defaults and ranges. The interval-stored parameter defines the number of completed individual test runs to store in volatile memory. There is an additional allocation to account for the active measurement interval.

If the retained test data for a measurement interval consumes the final entry, any subsequent entries cause the removal of the oldest data.

Threshold events

The following are the two types of threshold events:

Delay event

Each of these delay threshold events are raised a single time in a measurement interval immediately after the threshold is reached.

Loss events

The types of loss events are as follows:

Loss event template

The loss event template is created using the oam performance-monitoring ip loss loss-events-template command. All of the loss events are configured using this template. During loss measurement, the loss event template is referenced by a performance monitoring session.

The following considerations apply to loss event templates:

• A loss event template cannot be deleted if it is referenced by a performance monitoring session.

• A loss event template can be modified even if it is referenced by a performance monitoring session without disrupting the ongoing session.

• The reference changes that include, adding a new reference or deleting an existing reference within a loss test session can be done without impacting the performance monitoring session or the loss test session.

• The configuration changes made to loss event templates affect only the loss event function ensuring that performance monitoring continues seamlessly.

• The operational states of the loss events transition based on the configuration changes and the timing of measurement intervals.

Bin type

There are three types of binnable delay metrics:

• frame delay (FD)

• inter-frame delay variation (IFDV)

• frame delay range (FDR)

All bin types are available in the forward, backward, and round-trip directions. Each of these metrics can have up to ten bin groups configured to group the results.

Bin boundary

Bin groups are configured by indicating a lower boundary. Bin 0 has a lower boundary that is always zero and is not configurable. The microsecond range of the bins is the difference between the adjacent lower boundaries.

The last bin configured represents the bin that collects all the results at and above that lower-bound value. Not all ten bins have to be configured.

Each delay type requires their own values for the bin groups. It is not possible to configure a bin with different values for round-trip, forward, and backward. Consider the configuration of the boundaries that represent the important statistics for that specific requirement.

Bin group 1 is the default bin group. Every session requires a bin group to be assigned. By default, bin group 1 is assigned to every performance monitoring session that does not have a bin group explicitly configured. Bin group 1 cannot be modified. Bin group 1 is an automatically crated object and not visible in the configuration. If the bin-group 1 is added to the configuration only the mandatory default configuration values may be added. It bin-group 1 is added to the configuration its behavior will non default bin-groups.

Bin group behaviour