ON THIS PAGE
Configuring MEP Interfaces on Switches to Support Ethernet Frame Delay Measurements (CLI Procedure)
Configuring One-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
Triggering an Ethernet Frame Delay Measurement Session on a Switch
Configuring Two-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
Ethernet Frame Delay
SUMMARY This section describes how performance management depends on the accurate measurement of service-level agreement (SLA) objective parameters, such as bandwidth and reliability.
Understanding Ethernet Frame Delay Measurements on Switches
In many cases, a service provider could be subject to penalties imposed by regulation, statute, or contract if network performance is not within the bounds established for the service. One key performance objective is delay, along with its close relative, delay variation (often called jitter). Some applications (such as bulk file transfer) will function just as well with high delays across the network and high delay variations, while other applications (such as voice) can function only with low and stable delays. Many networks invoke protocols or features available at Layer 3 (the packet layer) or higher to measure network delays and jitter link by link. However, when the network consists of many Ethernet links, there are few protocols and features available at Layer 2 (the frame layer) that allow routers and switches to measure frame delay and jitter. This is where the ability to configure and monitor Ethernet frame delay is helpful.
This topic includes:
Ethernet Frame Delay Measurements
You can perform Ethernet frame delay measurements (referred to as ETH-DM in Ethernet specifications) on Juniper Networks EX Series Ethernet Switches. This feature allows you to configure on-demand Operation, Administration, and Maintenance (OAM) statements for the measurement of frame delay and frame delay variation (jitter). You can configure Ethernet frame delay measurement in either one-way or two-way (round-trip) mode to gather frame delay statistics simultaneously from multiple sessions. Ethernet frame delay measurement provides fine control to operators for triggering delay measurement on a given service and can be used to monitor SLAs.
Ethernet frame delay measurement also collects other useful information, such as worst and best case delays, average delay, and average delay variation. It supports software-assisted timestamping in the receive direction for delay measurements. It also provides runtime display of delay statistics when two-way delay measurement is triggered. Ethernet frame delay measurement records the last 100 samples collected per remote maintenance association end point (MEP) or per connectivity fault management (CFM) session. You can retrieve the history at any time using simple commands. You can clear all Ethernet frame delay measurement statistics and PDU counters. Ethernet frame delay measurement is fully compliant with the ITU-T Y.1731 (OAM Functions and Mechanisms for Ethernet-based Networks) specification.
Ethernet frame delay measurement uses the IEEE 802.1ag CFM infrastructure.
Generally, Ethernet frame delay measurements are made in a peer fashion from one MEP or CFM session to another. However, these measurements are not made to maintenance association intermediate points (MIPs).
For a complete description of Ethernet frame delay measurement, see the ITU-T Y.1731 Ethernet Service OAM topics in the Junos OS Network Interfaces Library for Routing Devices.
Types of Ethernet Frame Delay Measurements
There are two types of Ethernet frame delay measurements:
One-way
Two-way (round-trip)
For one-way Ethernet frame delay measurement, either MEP can
send a request to begin a one-way delay measurement to its peer MEP.
However, the statistics are collected only at the receiver MEP. This
feature requires the clocks at the transmitting and receiving MEPs
to be synchronized. If these clocks fall out of synchronization, only
one-way delay variation and average delay variation values are computed
correctly (and will, therefore, be valid). Use the show
commands at the receiver MEP to display one-way delay statistics.
For two-way (round-trip) Ethernet frame delay measurement, either MEP can send a request to begin a two-way delay measurement to its peer MEP, which responds with timestamp information. Run-time statistics are collected and displayed at the initiator MEP. The clocks do not need to be synchronized at the transmitting and receiving MEPs. Junos OS supports timestamps in delay measurement reply (DMR) frames to increase the accuracy of delay calculations.
Use the show
commands at the initiator MEP to display
two-way delay statistics, and at the receiver MEP to display one-way
delay statistics.
You can create an iterator profile to periodically transmit SLA measurement packets in the form of ITU-Y.1731-compliant frames for delay measurement or loss measurement.
Limitations
The following are some limitations with regard to using Ethernet frame delay measurement:
Ethernet frame delay measurements are available only when distributed periodic packet management (PPM) is enabled.
The statistics collected are lost after a graceful Routing Engine switchover (GRES).
You can monitor only one session to the same remote MEP or MAC address.
Accuracy is compromised when the system configuration changes (such as from reconfiguration). We recommend performing Ethernet frame delay measurements on a stable system.
Configuring MEP Interfaces on Switches to Support Ethernet Frame Delay Measurements (CLI Procedure)
Ethernet frame delay measurement is a useful tool for providing performance statistics or supporting or challenging service-level agreements (SLAs). By default, Ethernet frame delay measurement uses software for timestamping and delay calculations. You can configure an EX Series switch to perform and display Ethernet frame delay measurements on Ethernet interfaces. The switches support software-assisted timestamping.
Before you can begin configuring MEP interfaces to support Ethernet frame delay measurements on switches, ensure that you have:
Configured Operation, Administration, and Maintenance (OAM) connectivity fault management (CFM) correctly
Enabled distributed periodic packet management (PPM) (distributed PPM is enabled by default)
To configure MEP interfaces on switches to support Ethernet frame delay measurements:
Optionally, you can also specify the following parameters:
Number of frames to send to the peer MEP (count count)
Number of seconds to wait between sending frames (wait time)
Priority value of the delay measurement request frame (priority value)
Size of the data in the data TLV of the request packet (size value)
Suppression of the insertion of the session ID TLV in the request packet (no-session-id-tlv)
user@switch> monitor ethernet delay-measurement maintenance-domain md-name maintenance-association ma-name one-way mep remote-mep-id count count wait time priority value size value no-session-id-tlv
Configuring One-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
Ethernet frame delay measurement is a useful tool for providing performance statistics or supporting or challenging service-level agreements (SLAs). You can configure the frame delay measurements in either a one-way mode or a two-way (round-trip) mode to gather frame delay statistics. For one-way Ethernet frame delay measurement, clocks at the local and remote MEPs need to be synchronized. However, clock synchronization is not required for two-way Ethernet frame delay measurement.
Before you begin configuring one-way Ethernet frame delay measurements on two EX Series switches, ensure that you have:
Configured Operation, Administration, and Maintenance (OAM) connectivity fault management (CFM) correctly on both the switches
Synchronized the system clocks of both the switches
To configure one-way Ethernet frame delay measurements:
You can view the result on the other switch:
user@switch> show oam ethernet connectivity-fault-management delay-statistics maintenance-domain md-name maintenance-association ma-name local-mep mep-id remote-mep mep-id
Configuring an Iterator Profile on a Switch (CLI Procedure)
Ethernet frame delay measurement provides fine control to operators for triggering delay measurement on a given service and can be used to monitor service-level agreements (SLAs). You can create an iterator profile with its parameters to periodically transmit SLA measurement packets in the form of ITU-Y.1731-compliant frames for two-way delay measurement.
To create an iterator profile:
Triggering an Ethernet Frame Delay Measurement Session on a Switch
To trigger Ethernet frame delay measurement, use the monitor ethernet delay-measurement operational command and specify the following values:
Either one-way (
one-way
) or two-way (two-way
) measurementEither the MAC address (
remote-mac-address
) or the MEP ID (mep
) of the remote hostThe maintenance domain (
maintenance-domain
)The maintenance association (
maintenance-association
)(Optional) Any or all of these options:
count
,size
,wait
, no-session-id-tlv,priority
For example:
user@switch> monitor ethernet delay-measurement one-way 00:05:85:73:39:4a maintenance-domain md6 maintenance-association ma6 count 10 size 50 wait 5 no-session-id-tlv priority 1
Configuring Two-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
Ethernet frame delay measurement is a useful tool for providing performance statistics or supporting or challenging service-level agreements (SLAs). You can configure the frame delay measurements in either a one-way mode or a two-way (round-trip) mode to gather frame delay statistics. For one-way Ethernet frame delay measurement, clocks at the local and remote MEPs need to be synchronized. However, clock synchronization is not required for two-way Ethernet frame delay measurement.
Before you begin configuring two-way Ethernet frame delay measurements on two EX Series switches, ensure that you have:
Configured Operation, Administration, and Maintenance (OAM) connectivity fault management (CFM) correctly on both the switches
To configure two-way Ethernet frame delay measurements:
You can view the result on the other switch:
user@switch> show oam ethernet connectivity-fault-management delay-statistics maintenance-domain md-name maintenance-association ma-name local-mep mep-id remote-mep mep-id