OAM monitoring and reporting
OAM fault and performance tools monitor and report information about the network infrastructure and the services that rely on that infrastructure.
Link measurement
Network elements use routing protocols to exchange information about local links, which can influence routing decisions. These interface attributes are typically static in nature. By using tools specifically designed to measure IP performance, dynamic unidirectional delay can be included in the advertised link attributes. A link measurement test is one such method for measuring and reporting delay information for directly connected IP peers. Link measurement uses the STAMP protocol defined in RFC 8762 to measure delay for an IP interface
The following figure shows directly connected IP interfaces and the link measurement interaction with routing.
Link measurement template
Creation of a link measurement template is the first step of a link measurement test. The link measurement template is created by configuring the common test parameters using the oam link-measurement command. After the measurement template is created, an SR Linux interface references the link measurement template using the oam link-measurement interface dynamic-measurement link-measurement-template command. When the association between the interface and the template is established, the interface executes a process to determine the operational state of the test and detect any defect conditions that may prevent test execution. If no underlying conditions are present, the IP interface delay measurements are collected in measurement windows, compared with the configured thresholds, and reported to the routing engine for further processing when required.
Link measurement template parameters
The parameters that are configured using the oam link-measurement interface dynamic-measurement link-measurement-template command define the test criteria used by the test. Conceptually, the test criteria are divided into the following groups:
Modifying a link measurement template
SR Linux supports the modification of active link measurement templates. That includes administratively disabling a link measurement template that IP interfaces are actively referencing. Modifying existing parameters causes interface delay tests that reference the modified template to terminate the current sample, and aggregate measurement windows, and 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.
Deleting a link measurement template
A link measurement template cannot be deleted if interfaces are referencing that template.
General configuration
The general configurations included in the oam link-measurement measurement-template command influence probe frequency, the delay metric type to monitor, and retention of the delay measurement last reported.
-
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 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 round trip 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 value. 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. 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.
An operational state is up for a test if:
-
the measurement template is administratively up
-
the source UDP port is available
-
an IPv4 or IPv6 protocol is administratively up
-
there are no internal errors that prevent the test from initializing
-
-
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.
Collection and reporting
The collection and reporting parameters define the following:
-
length of the sample-window and aggregate-sample-window. Two measurement windows are provided to support use cases that require a reporting hierarchy and both include the same configuration options.
-
thresholds that trigger reporting. The threshold values determine when the measurement window updates the reported delay value.
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
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.
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.
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.
Protocol
The oam link-measurement measurement-template stamp command parameters influence the format of the test packet, processing, QoS handling, IPv6 discovery, and return path.
Source UDP port
By default, link measurement uses dynamic source UDP ports. However, a specific source UDP port can be configured if required, from a range of source UDP ports allocated to STAMP which is, 64374 to 64383. The UDP port must previously be allocated to the link measurement application. See Allocating source UDP port to link measurement for more information about steps to allocate a source UDP port to the link measurement application.
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.
Interface assignment
The test criteria-specific link measurement is configured in the link measurement template. The delay test is executed from the network instance with the type default and requires and interface that is part of the network instance oam link-measurement interface 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.
IP addressing
To enable dynamic measurements for the interface, configure a link measurement template and enable the test protocol using the oam link-measurement interface dynamic-measurement stamp ipv4 or oam link-measurement interface dynamic-measurement stamp ipv6 command. 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.
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 stamp ipv6-destination-discoveryTest initialization
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 enabled 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.
| Detectable transmit error | Description | Prevents transmission |
|---|---|---|
|
none |
No detectable errors |
No |
|
subinterface-down |
The link measurement test is configured on an IP interface with an operationally down state |
Yes |
|
unexpected-error |
Router resources not available |
No |
|
no-route |
The routing lookup has failed to resolve the destination as reachable from the interface where the test is configured. The packet is transmitted out of the interface resolved by the routing engine. |
No |
|
source-ip-not-local |
The source IP address configured for the test is not local to the system |
No |
|
invalid-dest-ip |
The destination IP address is not valid. This may occur because of a configuration error or an attempt to use auto-assignment in conditions that are not supported. |
Yes |
|
subinterface-type-not-supported |
The link measurement test is configured under an interface that does not support these test types (such as loopback interfaces) |
Yes |
|
same-source-ip-destination-ip |
A configuration error that indicates the source and destination IP addresses are the same |
Yes |
When all audit conditions successfully pass, the test 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.
History and results
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.
The results can be viewed using the info from state oam link-measurement interface command.
Allocating source UDP port to link measurement
To allocate a source UDP port to link measurement, you specify the UDP port number in the oam ippm source-udp-port-pools port command and select link-measurement option in the application-assignment parameter.
Allocating source USP port to link measurement
This example allocates a source UDP port to perform the link measurement test.
--{ + candidate shared default }--[ ]--
# info oam ippm
oam {
ippm {
source-udp-port-pools {
port 64374 {
application-assignment link-measurement
}
}
}
}Performing link measurement test
Perform the following steps to carry out the link measurement test:
-
Create a link measurement template. Perform the following steps:
-
Assign an interface to the link measurement template. Perform the following
steps:
- When the link measurement template is assigned to an IP interface, the audit process determines the operational state of the test. Further validation determines if there are any underlying conditions that are considered detectable transmission errors. When all audit conditions successfully pass, the delay collection begins.
-
Use the info from state oam link-measurement interface
command to view the results of the link measurement test as shown in the
following example.
Displaying link measurement test results
--{ +!* candidate shared default }--[ ]-- # info from state oam link-measurement interface lm001 oam { link-measurement { interface lm001 { oper-state down detectable-transmit-error invalid-dest-ip operational-source-address 2001:db8::2 source-ip-auto-assigned false operational-destination-address 2001:db8::1 destination-ip-auto-assigned false in-use-source-udp-port 64374 in-use-destination-udp-port 862 stamp-session-sender-id 0 reporting false last-reported-dynamic-delay none report-timestamp 1970-01-01T00:00:00.000Z report-triggered-by none aggregate-newest-index 1 sample-newest-index 2 operational-failure [ no-protocol ] interface-ref { interface ethernet-1/22 subinterface 1 } dynamic-measurement { link-measurement-template test stamp { ipv4 { admin-state disable destination-ip 192.168.0.1 source-ip 192.168.0.2 } ipv6 { admin-state enable destination-ip 2001:db8::1 source-ip 2001:db8::2 } } } statistics { aggregate-sample-window { index 1 { end-timestamp-utc 2024-06-13T02:15:56.000Z window-state terminated sample-window-count 1 minimum 0 maximum 0 average 0 result 0 integrity false } } sample-window { index 1 { end-timestamp-utc 2024-06-13T02:15:55.000Z window-state completed transmitted-packets 10 received-packets 8 minimum 3128 maximum 3828 average 3444 integrity true error-count 0 stamp-unrecognized-flag-count 0 stamp-malformed-flag-count 0 zero-or-negative-delay-count 0 duplicate-packet-count 0 } index 2 { end-timestamp-utc 2024-06-13T02:15:56.000Z window-state terminated transmitted-packets 1 received-packets 1 minimum 0 maximum 0 average 0 integrity false error-count 0 stamp-unrecognized-flag-count 0 stamp-malformed-flag-count 0 zero-or-negative-delay-count 0 duplicate-packet-count 0 } } } } } }
Performance monitoring
Performance monitoring encompasses a variety of tools and protocols designed to measure, report, analyze, and optimize network performance, allowing network administrators to detect and resolve issues proactively. This chapter provides information about delay and loss measurement as part of STAMP OAM performance monitoring.
STAMP OAM performance monitoring
The STAMP OAM performance monitoring architecture for gathering and computing Key Performance Indicators (KPIs) using standard protocols and a robust collection model consists of the following foundational components:
-
session: This is the overall collection of the test parameters, measurement intervals, thresholds and storage of results. It is the overall container that defines the attributes of the session.
-
standard performance monitoring packets: SR Linux supports STAMP to measure performance metrics such as delay and packet loss. See Session sender packet format and Session reflector packet format in the STAMP chapter for more information about STAMP test packets.
-
measurement interval: These are time-based non-overlapping windows that capture results that are received in that window of time.
-
data structures: These are the unique counters and measurement results that represent the specific protocol.
-
bin group: These are ranges in microseconds that count the results that fit into the range.
The following figure shows the hierarchy of the architecture. This figure intends to show the relationship between the components and not to depict all the details of the required parameters.
Session
The session is the overall collection of test information fields. The session can be viewed as the single container that combines all aspects of individual tests and the various OAM performance monitoring components. The session command includes parameters such as:
-
session-type: The session type is either proactive or on-demand. The session type setting influences the individual test timing parameters.
-
test-id: The test identifier is a configured as a numerical value or using the auto keyword. An automatically assigned test identifier is released when the test is deleted. Any action that causes the test to be deleted and recreated releases the original test identifier and allocates a new one. These test identifiers are not persistent and not maintained across CPM switchovers. New test identifiers are allocated in the case of CPM switchover.
-
test parameters: These include start time, stop time, ability to activate a test, and ability to deactivate a test.
-
measurement-interval: This is the assignment of collection windows to the session with the appropriate configuration parameters .
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.
-
the completion of the test-duration configured using the oam performance-monitoring ip session session-type on-demand stamp test-duration command
-
the execution of the tools oam performance-monitoring ip session on-demand-action stop command
Standard performance monitoring packets
-
session sender packet. Test request packets that the session sender transmits to the session reflector.
-
session reflector packet. Test response packets that the session reflector sends to the session sender.
Data structures
There are two main metrics that are the focus of OAM performance monitoring: delay and loss.
Delay metrics
-
Frame Delay (FD): This measures the time taken for a packet to traverse the network. Any negative FD values are set to zero for binning purposes.
-
Frame Delay Range (FDR): This represents the difference between the FD and the lowest FD recorded within a measurement interval. For the first interval, the minimum delay is set to zero. For subsequent intervals, the minimum delay of the previous measurement interval is used as the reference. Negative FD values are set to zero before calculating FDR.
-
Inter-Frame Delay Variation (IFDV): Also known as jitter, IFDV measures the variation in delay between adjacent test frames. The absolute difference between the current and previous delay values is calculated, even if the previous delay was negative.
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:
-
out loss: This metric measures the difference between the packets that the session reflector receives and those that the session sender transmits.
-
in loss: This metric calculates the difference between the packets that the session sender receives and those that the session reflector transmits.
-
Frame Loss Ratio (FLR): This percentage metric represents the ratio of lost packets during times of availability. FLR is not incremented during periods of unavailability.
-
available: The number of delta-ts that are recorded as available. These delta-ts do not exceed the FLR threshold and do not follow an unavailable state. If the available delta-ts follow an unavailable state, they need to fill the availability window before transitioning to available.
-
unavailable: The number of delta-ts that are recorded as unavailable. These delta-ts exceed the FLR threshold and do not follow an available state. If the unavailable delta-ts follow and available state, they need to fill the unavailability window before transitioning to unavailable.
-
undetermined availability: This counter increments when packets are lost and there is no explicit information about the fate of the packet. This occurs after timeouts and follows an available state.
-
undetermined unavailability: Similar to undetermined availability, this counter increments after packet timeouts following an available state when there is no explicit information about the fate of the packet.
-
High Loss Interval (HLI): This increments when individual delta-ts reach or exceed the FLR configuration. By default, this is calculated during the availability periods. Executing the oam performance-monitoring ip session stamp loss hli-force-count command and configuring the true option increments the HLI regardless of the availability state.
-
Consecutive High Loss Interval (CHLI): This increments when consecutive HLI intervals meet or exceed a specified threshold within the sliding window. CHLI increments only a single time for each availability window.
Measurement intervals
A measurement interval is a window of time that compartmentalizes the gathered measurements for an individual test that has occurred during that time. Allocation of measurement intervals, which equates to system memory, is based on the metrics being collected. This means that when both delay and loss metrics are collected, they allocate their own set of measurement intervals.
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-relative 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.
| Offset | 1-min | 5-min | 15-min | 1-hour | 1-day |
|---|---|---|---|---|---|
|
0 (default) |
0, 1, 2, 3, ... |
00, 05, 10, 15, ... |
00, 15, 30, 45 |
00 (top of the hour) |
midnight |
|
10 minutes |
rejected |
rejected |
10, 25, 40, 55 |
10 min after the hour |
10 min after midnight |
|
30 minutes |
rejected |
rejected |
rejected |
30 min after the hour |
30 min after midnight |
|
60 minutes |
rejected |
rejected |
rejected |
rejected |
01:00 AM |
Test relative
Although test-relative 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 performance monitoring data and may make better use of the test-relative 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:
-
stateless. The stateless threshold events are:
-
autonomous. Each measurement interval operates independently without carrying forward any information about events from previous intervals.
-
self-contained. The events are evaluated and triggered within the confines of a single measurement interval.
-
enacted when clear-threshold is unset.
-
-
stateful. The stateful threshold events are:
-
persistent. The events remain active until specific clear-threshold conditions are met at the end of a subsequent interval.
-
enacted when the clear-threshold is set within the configured range. A value of zero indicates the event clears if no results fall within the specified range in a subsequent interval.
-
Delay event
-
Frame Delay (FD)
-
Frame Delay Range (FDR)
-
Inter-Frame Delay Variation (IFDV)
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:
-
counter-based events. These are simple counts that compare to the raise-threshold for raising and the clear-threshold for clearing. The standard directions, forward and backward as well as a mathematical aggregate that is computed by summing the forward and backward values, are supported. Each of these loss threshold events are raised a maximum of one time in a measurement interval when the count in the specified bin or bins reach the raise-threshold.
-
High Loss Interval (HLI) event
-
Consecutive High Loss Interval (CHLI) event
-
unavailability event
-
undetermined availability event
-
undetermined unavailability event
-
-
Average Frame Loss Ratio (Avg-FLR) event. Unlike other loss events, the Avg-FLR event is raised only at the end of the measurement interval. This event does not support aggregated computation. It supports forward and backward directions.
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 group
A bin group is a collection of bins where each bin represents a range of delay values. When a delay measurement is performed, the delay results are stored in appropriate bins based on its value. This process is known as binning and it allows for a structured and aggregated view of delay performance over time. Bin groups are created using the oam performance-monitoring ip delay bin-group command and referenced by the session using the oam performance-monitoring ip session stamp delay bin-group command.
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.
-
bin 0 captures all frame delay statistics results between 0 and 1 ms
-
bin 1 captures all results above 1 ms and below the bin 2 lower boundary. Bin 2 is not shown.
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 created 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. If bin-group 1 is added to the configuration it behaves as non-default bin-groups.
Bin group behaviour
-
Bin groups cannot be deleted if referenced by a performance monitoring session.
-
Bin groups cannot be disabled if referenced by a delay test with the admin-state parameter set to enable.
- Bin groups can be modified even if referenced by a delay test regardless of the admin-state parameter setting. Delay results for the performance monitoring session referencing a changed bin-group is deleted and a new set of bins start recording results.
-
Bin group that is excluded from average can be modified even if referenced by a delay test with the admin-state parameter set to enable.
- Any changes to the attributes of the oam performance-monitoring ip delay bin-group bin-type delay-event command do not affect the performance monitoring session or test sessions.
Configuring STAMP OAM performance monitoring session
To configure a STAMP OAM performance monitoring session, use the oam performance-monitoring ip session command and configure the parameters as shown in Configuring a STAMP OAM performance monitoring session.
To allocate a source UDP port to the OAM STAMP application, use the oam ippm source-udp-port-pools port 64374 application-assignment oam-pm-ip command and configure the parameters as shown in Allocating source UDP port to OAM performance monitoring application. Configuration of the source UDP port should only be used when explicitly required. If not configured, the source UDP port is dynamically allocated from the dynamic UDP port range by the OAM performance monitoring application.
Configuring a STAMP OAM performance monitoring session
This example configures a STAMP OAM performance monitoring session.
--{ + candidate shared default }--[ ]--
# info oam performance-monitoring ip session ip-sess-1
oam {
performance-monitoring {
ip {
session ip-sess-1 {
session-type proactive
destination-ip 192.168.1.2
destination-udp-port 862
source-ip 192.168.1.1
network-instance net-inst-default
dscp EF
profile in
measurement-interval 1-minute {
boundary-type clock-aligned
clock-offset 0
intervals-stored 32
threshold-alerts {
loss-event enable
delay-event enable
}
}
stamp {
admin-state enable
test-id auto
interval 100ms
delay {
bin-group 2
}
loss {
flr-threshold 5
hli-force-count true
loss-event loss-1
timing {
frames-per-delta-t 10
consecutive-delta-t 10
chli-threshold 5
}
}
}
}
}
}
}Allocating source UDP port to OAM performance monitoring application
This example allocates a source UDP port to the OAM performance monitoring application.
--{ + candidate shared default }--[ ]--
A:srl1# info oam ippm source-udp-port-pools
oam {
ippm {
source-udp-port-pools {
port 64374 {
application-assignment oam-pm-ip
}
}
}
}Performing delay measurement
Perform the following steps to measure packet delay as part of STAMP OAM performance monitoring:
-
Configure a bin group. Use the oam performance-monitoring ip delay
bin-group command and specify the parameters as shown in the
following example.
Configuring a bin group
--{ + candidate shared default }--[ ]-- # info oam performance-monitoring ip delay bin-group gp2 oam { performance-monitoring { ip { delay { bin-group gp2 { admin-state enable } } } } } -
Configure the bin type and delay measurement parameters. Use the oam
performance-monitoring ip delay bin-group bin-type command and
specify the bin-type and delay-event
parameters.
Configuring a bin type
--{ + candidate shared default }--[ ]-- # info oam performance-monitoring ip delay bin-group 2 bin-type fd oam { performance-monitoring { ip { delay { bin-group 2 { bin-type fd { bin 0 { lower-bound 0 } bin 1 { lower-bound 500 } bin 2 { lower-bound 1000 } bin 3 { lower-bound 1500 } bin 4 { lower-bound 2000 } bin 5 { lower-bound 2500 } bin 6 { lower-bound 3000 } bin 7 { lower-bound 3500 } bin 8 { lower-bound 4000 } bin 9 { lower-bound 4500 } delay-event round-trip { lowest-bin 8 raise-threshold 10 clear-threshold 0 exclude-lowest-bin 9 } } } } } } } -
Configure the session type. Perform one of the following:
-
Enable STAMP and associate the bin group that has the delay measurement
parameters configured. Use the info oam performance-monitoring ip
session stamp command and specify the STAMP parameters and
associate the bin group.
Configuring STAMP parameters for delay measurement
--{ +* candidate shared default }--[ ]-- # info oam performance-monitoring ip session ip-sess-1 stamp oam { performance-monitoring { ip { session ip-sess-1 { stamp { admin-state enable test-id auto test-duration 60 interval 100ms delay { bin-group 2 } } } } } } -
Start delay measurement. Perform one of the following:
-
Stop delay measurement. Perform one of the following:
Performing loss measurement
Perform the following steps to measure packet loss as part of STAMP OAM performance monitoring:
-
Configure a loss events template. Use the oam performance-monitoring
ip loss loss-events-template command and specify the loss event
parameters as shown in the following example.
Configuring a loss events template
--{ +* candidate shared default }--[ ]-- # info oam performance-monitoring ip loss loss-events-template loss-1 oam { performance-monitoring { ip { loss { loss-events-template loss-1 { hli-event aggregate { raise-threshold 12 clear-threshold 6 } } } } } } -
Configure the session type. Perform one of the following:
-
Enable STAMP and associate the loss events template that has the loss
measurement parameters configured. Use the oam performance-monitoring
ip session stamp command and specify the parameters as shown in
the following example.
Configuring STAMP parameters for loss measurement
--{ +* candidate shared default }--[ ]-- # info oam performance-monitoring ip session ip-sess-1 stamp oam { performance-monitoring { ip { session ip-sess-1 { stamp { admin-state enable test-id auto test-duration 60 interval 100ms delay { bin-group 2 } loss { flr-threshold 5 hli-force-count true loss-event loss-1 timing { frames-per-delta-t 10 consecutive-delta-t 10 chli-threshold 5 } } } } } } } -
Start loss measurement. Perform one of the following:
-
Stop delay measurement. Perform one of the following:
Displaying delay and loss measurement results
To display the results of delay and loss measurement, use the info from state oam performance-monitoring ip session command.
Displaying the results of delay and loss measurement
This example displays the delay and loss measurement results.
--{ + candidate shared default }--[ oam performance-monitoring ip ]--
# info from state
session-type proactive
destination-ip 192.168.1.2
destination-udp-port 862
source-ip 192.168.1.1
source-udp-port 44000
network-instance net-inst-default
dscp EF
profile in
ttl 255
measurement-interval 1-minute {
boundary-type clock-aligned
clock-offset 0
intervals-stored 32
threshold-alerts {
loss-event enable
delay-event enable
}
}
stamp {
admin-state enable
oper-state up
detected-tx-error none
test-id auto
test-id-in-use 2147483650
test-duration 0
pad-tlv-size 0
interval 100ms
statistics {
stamp-unrecognized-flag-received 0
stamp-malformed-flag-received 0
}
delay {
bin-group 2
bin-group-binning active
measurement-result 1-minute {
newest-index 2
index 1 {
oper-state in-progress
suspect-status true
start-time 2024-07-05T19:11:54.000Z
elapsed-time 6
statistics {
frames-transmitted 55
frames-received 55
bin-type fd {
forward {
minimum 145
maximum 303
average 208
}
backward {
minimum 115
maximum 241
average 170
}
round-trip {
minimum 290
maximum 499
average 379
}
bin 0 {
forward-measurements 55
backward-measurements 55
round-trip-measurements 55
}
bin 1 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 2 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 3 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 4 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 5 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 6 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 7 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 8 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 9 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
}
bin-type fdr {
forward {
minimum 0
maximum 157
average 51
}
backward {
minimum 0
maximum 121
average 43
}
round-trip {
minimum 0
maximum 181
average 68
}
bin 0 {
forward-measurements 55
backward-measurements 55
round-trip-measurements 55
}
bin 1 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
}
bin-type ifdv {
forward {
minimum 0
maximum 158
average 43
}
backward {
minimum 0
maximum 95
average 27
}
round-trip {
minimum 4
maximum 130
average 54
}
bin 0 {
forward-measurements 50
backward-measurements 54
round-trip-measurements 44
}
bin 1 {
forward-measurements 4
backward-measurements 0
round-trip-measurements 10
}
bin 2 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 3 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 4 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 5 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 6 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 7 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 8 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 9 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
}
}
}
index 2 {
oper-state in-progress
suspect-status false
start-time 2024-07-05T19:12:00.000Z
elapsed-time 3
statistics {
frames-transmitted 32
frames-received 32
bin-type fd {
forward {
minimum 158
maximum 268
average 219
}
backward {
minimum 98
maximum 281
average 172
}
round-trip {
minimum 294
maximum 512
average 391
}
bin 0 {
forward-measurements 32
backward-measurements 32
round-trip-measurements 30
}
bin 1 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 2
}
bin 2 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 3 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 4 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 5 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 6 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 7 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 8 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 9 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
}
bin-type fdr {
forward {
minimum 13
maximum 123
average 74
}
backward {
minimum 0
maximum 183
average 72
}
round-trip {
minimum 4
maximum 222
average 101
}
bin 0 {
forward-measurements 32
backward-measurements 32
round-trip-measurements 32
}
bin 1 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
}
bin-type ifdv {
forward {
minimum 1
maximum 97
average 24
}
backward {
minimum 0
maximum 109
average 51
}
round-trip {
minimum 4
maximum 174
average 62
}
bin 0 {
forward-measurements 32
backward-measurements 29
round-trip-measurements 28
}
bin 1 {
forward-measurements 0
backward-measurements 3
round-trip-measurements 4
}
bin 2 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 3 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 4 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 5 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 6 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 7 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 8 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 9 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
}
}
}
}
measurement-result raw {
newest-index 1
index 1 {
oper-state in-progress
suspect-status true
start-time 2024-07-05T19:11:54.000Z
elapsed-time 9
statistics {
frames-transmitted 87
frames-received 87
bin-type fd {
forward {
minimum 145
maximum 303
average 212
}
backward {
minimum 98
maximum 281
average 171
}
round-trip {
minimum 290
maximum 512
average 383
}
bin 0 {
forward-measurements 87
backward-measurements 87
round-trip-measurements 85
}
bin 1 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 2
}
bin 2 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 3 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 4 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 5 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 6 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 7 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 8 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 9 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
}
bin-type fdr {
forward {
minimum 0
maximum 157
average 60
}
backward {
minimum 0
maximum 183
average 53
}
round-trip {
minimum 0
maximum 222
average 80
}
bin 0 {
forward-measurements 87
backward-measurements 87
round-trip-measurements 87
}
bin 1 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
}
bin-type ifdv {
forward {
minimum 0
maximum 158
average 36
}
backward {
minimum 0
maximum 109
average 36
}
round-trip {
minimum 4
maximum 174
average 57
}
bin 0 {
forward-measurements 82
backward-measurements 83
round-trip-measurements 72
}
bin 1 {
forward-measurements 4
backward-measurements 3
round-trip-measurements 14
}
bin 2 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 3 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 4 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 5 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 6 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 7 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 8 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
bin 9 {
forward-measurements 0
backward-measurements 0
round-trip-measurements 0
}
}
}
}
}
delay-events fd direction round-trip {
last-tca-time 1970-01-01T00:00:00.000Z
oper-state not-active
}
delay-events ifdv direction round-trip {
last-tca-time 1970-01-01T00:00:00.000Z
oper-state not-active
}
}
loss {
flr-threshold 5
hli-force-count true
loss-event loss-1
timing {
frames-per-delta-t 10
consecutive-delta-t 10
chli-threshold 5
}
measurement-result 1-minute {
newest-index 2
index 1 {
oper-state in-progress
suspect-status true
start-time 2024-07-05T19:11:54.000Z
elapsed-time 6
statistics {
frames-transmitted 55
frames-received 55
forward {
out-loss 0
available 0
unavailable 0
undetermined-available 0
undetermined-unavailable 0
high-loss-intervals 0
consecutive-high-loss-intervals 0
minimum-frame-loss-ratio 0
maximum-frame-loss-ratio 0
average-frame-loss-ratio 0
}
backward {
in-loss 0
available 0
unavailable 0
undetermined-available 0
undetermined-unavailable 0
high-loss-intervals 0
consecutive-high-loss-intervals 0
minimum-frame-loss-ratio 0
maximum-frame-loss-ratio 0
average-frame-loss-ratio 0
}
}
}
index 2 {
oper-state in-progress
suspect-status false
start-time 2024-07-05T19:12:00.000Z
elapsed-time 3
statistics {
frames-transmitted 32
frames-received 32
forward {
out-loss 0
available 0
unavailable 0
undetermined-available 0
undetermined-unavailable 0
high-loss-intervals 0
consecutive-high-loss-intervals 0
minimum-frame-loss-ratio 0
maximum-frame-loss-ratio 0
average-frame-loss-ratio 0
}
backward {
in-loss 0
available 0
unavailable 0
undetermined-available 0
undetermined-unavailable 0
high-loss-intervals 0
consecutive-high-loss-intervals 0
minimum-frame-loss-ratio 0
maximum-frame-loss-ratio 0
average-frame-loss-ratio 0
}
}
}
}
measurement-result raw {
newest-index 1
index 1 {
oper-state in-progress
suspect-status true
start-time 2024-07-05T19:11:54.000Z
elapsed-time 9
statistics {
frames-transmitted 87
frames-received 87
forward {
out-loss 0
available 0
unavailable 0
undetermined-available 0
undetermined-unavailable 0
high-loss-intervals 0
consecutive-high-loss-intervals 0
minimum-frame-loss-ratio 0
maximum-frame-loss-ratio 0
average-frame-loss-ratio 0
}
backward {
in-loss 0
available 0
unavailable 0
undetermined-available 0
undetermined-unavailable 0
high-loss-intervals 0
consecutive-high-loss-intervals 0
minimum-frame-loss-ratio 0
maximum-frame-loss-ratio 0
average-frame-loss-ratio 0
}
}
}
}
loss-events hli direction aggregate {
last-tca-time 1970-01-01T00:00:00.000Z
oper-state not-active
}
}
}
}